Segundo o relatório Cost of a Data Breach 2025, da IBM, organizações levaram em média 241 dias para identificar e conter um incidente de segurança — o menor número em nove anos, e ainda assim quase oito meses até a empresa entender o que de fato aconteceu. O mesmo relatório traz um recorte específico sobre IA: entre as organizações que passaram por um incidente ligado a IA, 97% admitiram não ter controles de acesso adequados no momento em que o problema ocorreu.
O padrão por trás desse número é sempre o mesmo. Quando o uso de IA acontece em ferramentas pessoais, fora dos sistemas que a empresa administra, não sobra nada para reconstruir depois: nenhum registro de quem pediu o quê, com qual informação, sob qual autorização. A investigação não fica difícil — ela simplesmente não tem material para começar.
Para quem decide sobre tecnologia, essa lacuna costuma passar despercebida no dia a dia. Ela só aparece no dia em que alguém pergunta o que aconteceu, e a resposta é "não sabemos".
Quando o incidente chega, a pergunta é sempre a mesma
Toda investigação de incidente começa com as mesmas perguntas: o que aconteceu, quando, e por ordem de quem. A área jurídica pergunta isso para avaliar exposição. O seguro pergunta para decidir cobertura. O regulador pergunta para decidir se houve negligência. Sem resposta, a empresa não está apenas mal informada — está exposta em três frentes ao mesmo tempo.
O relatório da IBM, construído com dados de 600 organizações que sofreram incidentes envolvendo IA, mostra que essa exposição é hoje a regra, não a exceção: 63% dessas organizações não tinham nenhuma política de governança de IA em vigor. Sem política, raramente existe também o registro que uma política formal costuma exigir — e o resultado aparece direto na conta: o uso alto de IA fora do controle da empresa (o que o mercado chama de IA sombra) adicionou, em média, US$ 670 mil ao custo de cada incidente.
O guia de técnicas forenses do NIST (SP 800-86), referência americana para investigação de incidentes de segurança, é direto sobre o motivo: a capacidade de investigar depende de decisões tomadas antes do incidente — quais sistemas registram eventos, com que nível de detalhe e por quanto tempo. Um ambiente sem esse preparo não fica "mais difícil de investigar". Fica, na prática, sem condição de investigação nenhuma, porque a evidência que sustentaria uma reconstrução dos fatos nunca existiu.
É esse o ponto que costuma escapar da conversa sobre uso de IA no trabalho: o risco não é só o dado sensível que pode vazar em uma conversa com um assistente pessoal. É a ausência de qualquer trilha que permita, depois, dizer com segurança o que aconteceu e por quê.
Por que o controle comum não resolve nada
A resposta mais comum das empresas é uma política de uso aceitável: um documento dizendo o que pode e o que não pode ser feito com IA. É importante, mas resolve menos do que parece — porque uma política não gera registro. Ela declara uma intenção; não produz um dado consultável depois.
Em agosto de 2024, agências de segurança de nove países — lideradas pela Direção de Sinais da Austrália em conjunto com a CISA, o FBI e a NSA dos Estados Unidos, além de Reino Unido, Canadá, Nova Zelândia, Japão, Coreia do Sul e Singapura — publicaram uma orientação conjunta sobre registro de eventos. A frase de abertura do documento resume bem o ponto: registro de eventos "sustenta a continuidade das operações e melhora a segurança e a resiliência dos sistemas críticos ao permitir visibilidade da rede". Nove agências nacionais de segurança concordando em publicar, juntas, uma orientação sobre esse tema específico é um sinal de quanto ele é considerado crítico — e não apenas para grandes governos: o princípio vale para qualquer sistema que processe informação sensível, incluindo o uso corporativo de IA.
O problema é que a maioria das ferramentas de IA usadas hoje dentro das empresas não foi desenhada pensando nesse padrão. Um assistente em conta pessoal não informa ao empregador que ação foi tomada, com qual documento, ou se alguém aprovou aquilo antes de seguir adiante. A política existe no papel; o registro não existe em lugar nenhum.
O que precisa existir na prática
Um ambiente de IA preparado para ser investigado se define por mecanismos verificáveis, não por um documento de intenções.
Identidade corporativa, não conta pessoal. O acesso à IA vem do mesmo diretório que controla o acesso a e-mail e sistemas internos. Isso significa que toda ação fica associada a uma pessoa real, dentro da empresa, e não a uma conta que ninguém mais enxerga.
Acesso conforme o papel de cada pessoa. Quando o que cada pessoa e cada agente podem fazer é definido por papel, a lista de suspeitos de um incidente já nasce menor — e mais precisa.
Aprovação humana registrada antes de ações sensíveis. Documentos críticos podem exigir revisão e aprovação em duas etapas, com quem escreve separado de quem aprova, e com a decisão registrada no momento em que ela é tomada — não reconstruída de memória semanas depois.
Trilha de auditoria detalhada por área do sistema. Criar um agente, aprovar um documento, mudar uma permissão, executar uma ação sensível: cada evento desses fica registrado com quem, quando e o quê. É exatamente esse o material que faltou nos 97% de incidentes de IA sem controle de acesso adequado citados pela IBM.
É assim que a Skyller foi desenhada: identidade vinda do diretório da empresa, aprovação registrada e trilha de auditoria como padrão desde o primeiro dia de uso, não como configuração adicional para depois.
Da reconstrução em minutos à confiança da auditoria
O benefício mais óbvio de um registro completo aparece no pior momento possível — no meio de um incidente, quando a equipe de segurança precisa saber, rápido, o alcance do problema. Com trilha de auditoria, essa reconstrução leva minutos: buscar por pessoa, por documento ou por período e ver exatamente o que aconteceu.
Mas o benefício vai além do dia da crise. Uma auditoria externa, uma certificação de segurança ou uma exigência contratual de um cliente maior costumam pedir evidência de controle, não apenas a existência de uma política. Uma empresa que consegue mostrar identidade corporativa, permissão por papel e histórico completo de aprovações passa por esse processo com evidência concreta em mãos — em vez de explicar, depois do fato, por que o registro daquele período específico não existe.
Há ainda um efeito menos falado: quando a equipe sabe que o ambiente de IA é auditável, o uso tende a ficar mais responsável por si só, sem precisar de uma proibição para isso. Trilha de auditoria não é sobre desconfiar de quem trabalha — é sobre garantir que, se algo precisar ser explicado, a explicação existe.
Esse mesmo registro também simplifica a vida de quem decide sobre novas ferramentas. Em vez de aprovar um sistema de IA "na confiança" e torcer para que nada dê errado, a área de TI passa a ter um critério objetivo de avaliação: o sistema registra identidade, ação e aprovação de forma consultável, ou não registra? A pergunta é simples, e a resposta separa rapidamente o que está pronto para uso corporativo do que ainda é uma ferramenta de uso individual.
Três perguntas para levar à próxima reunião
Antes de assumir que a empresa está coberta neste ponto, vale responder com honestidade a três perguntas, junto com a área de TI e o jurídico:
- Se hoje precisássemos provar quem aprovou um documento usado pela IA há três meses, conseguiríamos? Se a resposta depender de perguntar às pessoas envolvidas, a empresa não tem trilha de auditoria — tem memória.
- Alguém fora da equipe de TI consegue consultar esse histórico sem pedir ajuda técnica? Um registro que só o time de engenharia sabe abrir não serve para uma investigação conduzida pelo jurídico ou por um auditor externo.
- Quanto tempo levaria para reconstruir o que aconteceu num incidente envolvendo IA, hoje? Se a resposta for medida em semanas, a empresa está no mesmo ponto de partida das organizações que a IBM mediu — 241 dias até entender o próprio incidente.
