Por que a Inteligência Artificial Empresarial Quebra Após a Implantação – e o que Fazer a Respeito

Alerta: O Problema Não é o Modelo

Em 2023, a cidade de Nova York lançou o chatbot MyCity para ajudar as empresas a navegar por regulamentações complexas. A ideia era simples: tornar as informações legais mais fáceis de acessar.

Na prática, o sistema produziu respostas que não apenas estavam erradas, mas também eram enganosas do ponto de vista legal – desde regras de gorjetas até discriminação habitacional e leis de pagamento.

Uma auditoria posterior descobriu que 71,4% do feedback dos usuários era negativo. Em vez de corrigir os problemas subjacentes, a resposta foi adicionar avisos. O chatbot permaneceu em “beta” por mais de dois anos antes de ser desativado.

A falha não foi técnica. O sistema quebrou em produção porque não havia mecanismo para garantir a precisão, não havia responsabilidade clara e não havia como intervir quando as coisas davam errado.

Isso é o padrão por trás da inteligência artificial empresarial hoje: a tecnologia funciona, mas as organizações não estão preparadas para operá-la de forma confiável uma vez que está ao vivo.

Do Piloto à Produção: Onde Tudo se Desmorona

Construir um piloto é bastante direto – escolher um caso de uso, escolher um modelo, preparar dados, encontrar um patrocinador. Executar um sistema em produção é uma liga completamente diferente.

A lacuna é como a diferença entre pular em uma piscina e pular da estratosfera, como Felix Baumgartner fez em 2012. Mesma física básica, condições completamente diferentes – e consequências muito diferentes em caso de falha.

Em produção, a inteligência artificial entra em fluxos de tomada de decisão reais, interage com clientes e cria consequências legais e operacionais. É aí que as lacunas começam a aparecer – não no modelo, mas em como ele é governado.

A Europa torna isso visível mais cedo do que a maioria das regiões. Regulamentações como o Regulamento de IA da UE, o GDPR e o NIS2 não retardam a adoção – elas expõem se as organizações podem operar sistemas de IA sob restrições reais.

Em 2025, 55% das grandes empresas da UE já estavam usando IA. A adoção já está acontecendo em escala. O desafio é o que acontece após a implantação.

Nesse ponto, questões operacionais básicas começam a surgir. E, frequentemente, ninguém pode respondê-las: Quem é responsável pelos resultados da IA e decisões autônomas? O que acontece quando o sistema se comporta de maneira inesperada? E quem vai detectar antes que o dano alcance a mídia?

A responsabilidade recai sobre a empresa, não sobre a tecnologia. O chatbot da Air Canada deu a um cliente informações incorretas sobre tarifas de luto. O cliente confiou nisso e foi posteriormente negado um reembolso. Um tribunal decidiu que a companhia aérea era responsável – o chatbot não era uma entidade separada.

Mesmo problema, ângulo diferente: o sistema McHire da McDonald’s expôs dados sensíveis de quase 64.000 candidatos. A causa não foi um ataque sofisticado – o login do administrador usava “admin” e “123456”. O sistema parecia avançado. A falha foi elementar.

Quando você acopla a governança a um sistema ao vivo, já é tarde demais. Implantar um sistema é uma decisão técnica. Operá-lo de forma confiável é uma decisão organizacional. E é essa parte que a maioria das empresas subestima.

Quem Realmente Possui o Risco da IA? Ninguém.

Isso é o cerne do problema e, paradoxalmente, o menos discutido. O departamento de TI gerencia a infraestrutura. O departamento jurídico lida com a conformidade. As equipes de negócios impulsionam os casos de uso. Mas ninguém possui o risco da IA de ponta a ponta.

Isso cria dois problemas imediatos. A decisão de “ir” é retardada – porque ninguém quer assumir a responsabilidade. E a decisão de “parar” também é retardada – porque ninguém sabe quem pode.

Os dados refletem isso. Menos de 10% dos casos de uso da IA passam do piloto para a produção, e a maioria das organizações luta para gerar impacto comercial mensurável. Ao mesmo tempo, muitas já estão implantando IA – mas, de acordo com um relatório de maturidade de governança, apenas 7% tinham governança bem estruturada e consistentemente aplicada.

Por que isso acontece com tanta frequência? Porque a maioria dos quadros e políticas corporativas define o que deve acontecer – não quem é responsável quando importa. Quando um sistema começa a produzir saídas incorretas à meia-noite de uma sexta-feira, a pergunta não é teórica. Quem age? E quem tem a autoridade para decidir?

Isso só piora com a escala. Um sistema pode ser gerenciado informalmente. Quando você tem trinta, a responsabilidade se fragmenta em equipes, e ninguém tem a visão geral.

O Commonwealth Bank of Australia fornece um exemplo claro. O banco substituiu 45 trabalhadores de atendimento ao cliente por bots de voz de IA, esperando que a demanda diminuísse. Ela não diminuiu. O volume de chamadas aumentou, os gerentes intervieram para lidar com o excesso, e o banco teve que recontratar todos os 45 funcionários. Quando questionado, não pôde demonstrar que a automação havia reduzido a carga de trabalho.

Ninguém havia validado as suposições antes da implantação. Ninguém possuía o resultado quando essas suposições falharam. Isso é o que um vácuo de responsabilidade parece na prática.

Tendo Regras Não é O suficiente. Você Precisa de um Mecanismo

A maioria das organizações não falta políticas. Elas falta sistemas que funcionem quando algo dá errado.

Uma política define o que deve acontecer. Um mecanismo determina o que realmente acontece – quando um modelo produz saídas incorretas, quando um fornecedor muda algo em segundo plano ou quando um sistema começa a se comportar de maneira inesperada.

Essa diferença se torna visível em produção – quando decisões precisam ser tomadas em condições reais.

Essas falhas seguem uma dinâmica consistente. Em cada caso, as mesmas lacunas operacionais aparecem – apenas em formas diferentes.

Propriedade Vem em Primeiro

Todo sistema de IA implantado precisa de um proprietário claramente responsável – uma pessoa, não uma equipe ou departamento, com a autoridade para aprovar, pausar e desativar.

sem isso, nem a implantação rápida nem a intervenção segura são possíveis. Como visto no exemplo do Commonwealth Bank, a ausência de propriedade clara leva diretamente à falha operacional.

Dados e Clareza Jurídica Muitas Vezes Estão Faltando

Muitos sistemas vão ao ar sem fluxos de dados documentados, base legal verificada ou clareza sobre quais obrigações se aplicam uma vez que o sistema está em produção.

A ação do regulador italiano contra DeepSeek em 2025 ilustra isso claramente. O problema não era a qualidade do modelo – era a incapacidade de explicar como os dados pessoais eram tratados. O resultado foi uma interrupção repentina do serviço para os usuários europeus.

Testes Raramente Refletem o Uso no Mundo Real

Sistemas são frequentemente avaliados em cenários onde eles se saem bem, mas não nos casos em que a falha importaria mais.

O chatbot MyCity é um exemplo claro. Casos de bordo básicos – em torno de leis trabalhistas, discriminação habitacional ou regras de pagamento – não foram detectados antes da implantação. Uma vez exposto a usuários reais, essas falhas se tornaram públicas imediatamente.

Testar não é apenas sobre desempenho – é sobre identificar onde o sistema falha antes que os usuários, reguladores ou jornalistas o façam.

Intervenção é Incerta ou Lenta Demais

Mesmo quando os problemas são visíveis, frequentemente não há um gatilho claro ou autoridade para pausar ou desativar o sistema.

Zillow Offers demonstra isso em escala. O sistema usou um algoritmo para precificar e comprar casas. À medida que o mercado esfriou em 2021, o sistema continuou comprando a preços inflados. Não havia mecanismo para detectar a deriva a tempo, e não havia um ponto de decisão claro para pará-lo. O resultado foram perdas que ultrapassaram $880 milhões e o fechamento de toda a divisão.

Monitoramento Não é Propriedade

Monitoramento é frequentemente reduzido a painéis, mas isso não é o que impede as falhas.

O que importa é a responsabilidade definida: quem rastreia os sinais, o que dispara a escalada e quem é esperado para agir.

Deloitte Australia mostra o que acontece quando isso está faltando. Um relatório do governo incluiu citações alucinadas e referências legais incorretas porque ninguém era explicitamente responsável por verificar as saídas antes da entrega. O resultado foi um reembolso parcial e dano à reputação.

IA Agente: O que Vem a Seguir Será Ainda Mais Difícil

A IA geradora produz saídas. A IA agente toma ações. Isso muda completamente o risco.

Ao invés de uma única resposta para avaliar, uma instrução pode disparar uma cadeia de decisões em sistemas – chamadas de API, acesso a dados, transações, atualizações – frequentemente sem intervenção humana em cada etapa.

Quando algo dá errado, o problema não é mais a precisão. É a rastreabilidade. Qual etapa causou o problema? Quais dados foram usados? Quem autorizou a ação? Em muitos casos, essas perguntas são difíceis de responder após o fato.

É aí que as lacunas existentes se tornam críticas. A propriedade incerta, o monitoramento fraco e a falta de intervenção não apenas persistem – elas se multiplicam. Uma resposta errada pode ser corrigida. Uma ação errada pode criar consequências antes que alguém note.

Sinais precoces já apontam nessa direção. A Gartner estima que mais de 40% dos projetos de IA agente serão cancelados até 2027 – não devido a limitações do modelo, mas porque as organizações lutam para controlar custo, risco e resultados. Esse é o mesmo padrão que vemos com a IA geradora após a implantação. Apenas com apostas mais altas.

Os reguladores já estão respondendo com um princípio simples: a automação não remove a responsabilidade. Para as organizações, isso cria uma implicação clara: se a propriedade e o controle são incertos hoje, escalar para sistemas agente não resolverá o problema. Isso o amplificará.

Operar – Ou Perder

A IA não é mais o constrangimento. Os modelos são amplamente disponíveis, capazes e cada vez mais comoditizados. O verdadeiro diferenciador não é se uma organização pode construir IA – mas se pode operá-la de forma confiável uma vez que está ao vivo.

É aí que a maioria das falhas ocorre – em como os sistemas são executados, não em como são construídos. As organizações que terão sucesso não serão as que têm os modelos mais avançados. Serão as que têm as estruturas operacionais mais claras ao seu redor.

Isso pode ser testado diretamente. Pegue seu sistema de IA mais importante e responda a três perguntas:

• Quem pode desativá-lo?
• Como você sabe quando ele está falhando?
• O que acontece quando ele falha?

Se essas respostas são incertas, o sistema não está pronto para a produção.

O modelo pode estar. A organização não está.