Sexta-feira, seis da tarde. Um analista precisa entregar uma proposta e cola o contrato do cliente dentro de uma ferramenta de IA para resumir as cláusulas. A resposta vem em oito segundos, redondinha. Ele monta a proposta, manda para o cliente e vai para casa.
Não tocou alarme nenhum. Não teve bloqueio, não teve aviso, não ficou registro daquela consulta em lugar nenhum. Na segunda-feira, se alguém perguntar o que aconteceu com aquele contrato, ninguém tem como responder.
Agora me diz uma coisa: o erro foi de quem perguntou ou de quem desenhou o acesso?
O dado que muda a conversa
Eu venho pensando nisso desde que li o Cost of a Data Breach 2026, da IBM. O estudo olhou 602 organizações que sofreram violação de dados. Dessas, 21% tiveram um incidente envolvendo um modelo ou uma aplicação de IA. No ano anterior esse número era 13%.
E aqui vem a parte que mais me interessou. Entre as organizações que tiveram incidente com IA, 92% não tinham controle de acesso adequado. E 68% de toda a amostra não tinha política de governança de IA, sendo 35% sem nada no papel e 33% com uma política ainda em construção.
Tem mais um número que eu não consigo tirar da cabeça. Incidentes envolvendo ferramenta de IA não aprovada, o famoso shadow AI, saltaram de 20% para 43% em um ano. Custo médio de 5,39 milhões de dólares cada um.
Repara numa coisa: nenhum desses números fala de gente distraída. Todos falam de controle que não existia.
O que um livro de 1990 tem a ver com isso
Em 1990 o psicólogo britânico James Reason publicou Human Error, pela Cambridge University Press. Virou leitura obrigatória em aviação, em usina nuclear e em centro cirúrgico, e eu acho que virou também para quem está colocando IA dentro de empresa. A tese dele é fácil de entender e desconfortável de aceitar: procurar o culpado de um acidente é a maneira mais rápida de não descobrir a causa.
Reason separa duas coisas. Tem a falha ativa, que é o ato colado no incidente. O funcionário que cola o contrato na ferramenta errada, o desenvolvedor que dá permissão demais para um agente, o analista que aceita a resposta sem conferir a fonte. É o que aparece no relatório e o que dá um nome para colocar na ata.
E tem a condição latente, que é a fragilidade que já estava lá muito antes. Ninguém sabe quantas ferramentas de IA existem na empresa. A pasta compartilhada nasceu aberta lá em 2019. A chave de API foi criada para um teste e nunca foi revogada. O log não registra o que foi consultado. E não existe uma pessoa, com nome e sobrenome, responsável por aprovar uso de IA.
O funcionário comete o último erro visível. A empresa, sem querer, construiu o caminho até o dado.
Quando os furos se alinham
A imagem que ficou famosa a partir desse trabalho é a do queijo suíço. (A metáfora foi desenvolvida por vários autores depois dele, e tem gente boa apontando os limites dela, mas continua sendo a melhor imagem que eu conheço para explicar isso numa reunião de diretoria.)
Cada fatia é uma camada de defesa: política, inventário de IA, classificação de dado, identidade e acesso, escopo do agente, filtro na saída, revisão humana, log, monitoramento e resposta a incidente. Cada fatia tem furo, e furo é normal.
O incidente não acontece porque uma fatia falhou. Acontece quando os furos se alinham.
A ferramenta não aprovada é usada. A empresa não tem inventário. A conta enxerga uma pasta larga demais. A resposta não é filtrada por permissão. O log não guarda a consulta. Ninguém é avisado quando alguém extrai muita coisa de uma vez. Seis furos, uma trajetória, um vazamento. Culpar o usuário aqui é olhar para o último furo e ignorar os outros cinco.
Treinamento não conserta tudo
Reason ainda separa três tipos de falha, e essa parte muda o que você faz na segunda-feira. O slip é quando a intenção estava certa e a execução saiu diferente, tipo querer consultar um documento público e clicar na base confidencial. O lapse é esquecimento, como criar a chave de API para um teste e não revogar depois. E o mistake é quando o plano já estava errado desde o começo, quando a empresa decide que o mesmo modelo pode acessar contrato de todos os departamentos porque “o usuário já tem acesso ao sistema mesmo”.
Treinamento resolve parte dos slips e dos lapses. Treinamento nenhum conserta um mistake de arquitetura.
O que a IA fez com a escala do erro
Antes da IA, um erro de permissão expunha um arquivo. Hoje o mesmo erro vira resumo, busca em massa, código executável e decisão automatizada. A IA diminuiu o atrito entre a intenção da pessoa e a ação sobre o dado, e é por isso que escopo, identidade e autorização passaram a valer mais do que valiam.
E o modelo não entende as regras da sua empresa por bom senso. Se a pessoa não pode ler aquele contrato, a resposta gerada também não pode contar o que está escrito lá dentro. Isso precisa chegar até ele de forma técnica e verificável.
Uma confissão e cinco perguntas
Vou te confessar uma coisa. Durante um bom tempo eu fechei relatório de incidente com a frase “causa raiz: erro do usuário”. Era cômoda, encerrava a reunião e não custava nada. Só que não mudava absolutamente nada na semana seguinte. Hoje, quando essa frase aparece num relatório nosso, eu peço para refazer.
Se você for fazer uma coisa só depois de ler até aqui, leve estas cinco perguntas para a próxima reunião:
- Quem responde, com nome e sobrenome, por cada uso de IA aqui dentro?
- Qual é a lista de modelos, agentes e plugins em uso, incluindo os que ninguém aprovou?
- A resposta gerada respeita a mesma permissão do documento original?
- O que fica registrado: quem perguntou, o que foi recuperado, em que horário e por qual identidade?
- Como a gente descobre que um controle parou de funcionar?
O NIST organiza isso em quatro funções que não terminam nunca: governar, mapear, medir e gerenciar. Eu gosto dessa ideia porque ela mata a fantasia de que uma política assinada resolve o problema.
E não, eu não tenho todas essas respostas fechadas nem para a minha operação, e olha que esse é o meu ramo. A diferença entre uma empresa madura e as outras não está em nunca errar. Está em desenhar o caminho de um jeito que o erro previsível esbarre em alguma coisa antes de chegar no dado do cliente.
Volta comigo para a sexta-feira
Seis da tarde, o analista com a proposta atrasada. Ele não acordou naquele dia querendo vazar contrato de cliente. Ele queria entregar. E enquanto a nossa resposta para esse tipo de cena for marcar mais um treinamento de conscientização, com lista de presença assinada e certificado no fim, a chave de API vai continuar válida, a pasta vai continuar aberta e o log vai continuar sem registrar nada. Ninguém aprende em duas horas de sala a resistir a uma ferramenta que responde em oito segundos. Então fica a pergunta: na sua empresa, quem autorizou a IA?
Grande abraço,
Guedes
