Provar e desligar: trilha de auditoria, kill switch e rotina

O que uma trilha de auditoria precisa registrar?

O que foi tentado e o que foi executado, como dois fatos separados. Uma trilha que só guarda o que deu certo não mostra a tentativa bloqueada, e uma que só guarda o que o controle viu não mostra o que de fato rodou. Numa investigação, a pergunta que importa quase sempre está na diferença entre as duas: alguém, ou alguma IA, tentou algo que não devia? Passou? Por onde?

No nosso desenho, cada linha da trilha tem os mesmos campos: quando, quem, em que fase, com que ferramenta, contra que alvo, qual foi a decisão e qual regra decidiu. A linha nasce em dois lugares. O controle que fica antes da ação, como o guardrail, registra tudo o que viu e como decidiu, inclusive o que negou. O programa que executa a ação registra só o que de fato saiu. Quando as duas linhas existem, a tentativa virou ação. Quando só a primeira existe, o controle segurou.

Duas coisas ficam de fora da trilha de propósito. A primeira é o conteúdo. O alvo de um comando é mascarado antes de gravar, e tokens, chaves e trechos longos viram marcadores. O corpo de uma requisição não é registrado, porque payload de configuração costuma carregar credencial. A trilha diz o que foi revisado, nunca o valor que passou por ali. A segunda é o dado pessoal em claro, pelo mesmo motivo: uma trilha que guarda CPF vira, ela própria, o vazamento que deveria ajudar a investigar.

O erro comum é registrar só o que é fácil: o login, o deploy, o erro da aplicação. A ação da IA bloqueada de madrugada, a aprovação humana que liberou um comando arriscado e a avaliação do guardrail que ficou sem resposta são justamente as linhas que um auditor vai pedir. Se elas não existem, a resposta é "não sabemos", e "não sabemos" não é resposta.

O que fazer amanhã: pegue a última ação arriscada que a IA tentou no seu time, bloqueada ou aprovada, e tente reconstruí-la só pela trilha. Quem, quando, o quê, qual decisão, qual regra. Se faltar um desses campos, é por ele que a trilha começa.

O que a trilha não prova?

Ela prova o que registrou, do lugar onde registrou, e nada além disso. Os limites precisam estar escritos ao lado da trilha, porque quem a lê depois de um incidente tende a acreditar que ela é completa.

O primeiro limite é a identidade. Quando várias pessoas usam a mesma credencial para falar com um sistema, como um token da empresa distribuído pela configuração gerenciada, o servidor registra o token, não a pessoa. A atribuição passa a existir só na trilha local de cada máquina, que anota quem estava usando. Isso é mitigação, não equivalência: a trilha local é de cada máquina, quem controla a máquina pode alterá-la, e ela não é uma fonte auditável central. Duas consequências valem estar na mesa da diretoria. A rotação desse token afeta todo mundo ao mesmo tempo. E o escopo dele é o teto de privilégio de qualquer pessoa que o tenha.

O segundo limite é o caminho. A trilha de um controle só vê o que passa por ele. Uma leitura de arquivo que não aciona o guardrail, uma chamada feita por fora do programa que registra ou um comando digitado direto num servidor não aparecem ali. Por isso cada trilha diz o que cobre. "Tudo o que o controle viu" e "só o que passou pelo programa" são coberturas diferentes, e misturar as duas numa investigação leva a conclusões erradas.

O terceiro limite é a própria máquina. Quem compromete um servidor consegue editar a trilha que mora nele. Uma trilha que só existe no disco da máquina investigada serve para o dia a dia e quase nada para o incidente. É esse limite que responde à próxima pergunta.

O que fazer amanhã: escreva, no topo de cada trilha que a empresa mantém, uma linha dizendo o que ela cobre e o que não cobre. Quem for ler no dia do incidente agradece.

Por quanto tempo guardar a trilha, e onde?

Fora da máquina, antes do incidente, com duas retenções: uma curta para a telemetria de operação e uma de um ano para a trilha de auditoria. O lugar vem antes do prazo, porque uma trilha guardada por um ano dentro do servidor comprometido vale pouco no dia em que precisa valer.

Sair da máquina significa que cada evento é enviado, assim que acontece, para um destino central que a máquina de origem não consegue editar. Quando o destino cai, a máquina guarda os eventos numa fila em disco e reenvia depois, sem descartar. E a trilha de auditoria tem retenção própria, separada da telemetria: as métricas de memória da semana passada podem sumir em semanas, mas o registro de quem virou administrador e do que a IA executou fica um ano. O guia do NIST sobre gestão de logs, de 2006, já tratava a centralização e a proteção dos registros como infraestrutura, e não como detalhe.

Quando o destino é de um terceiro, a cópia sai cifrada. Quem tiver o acesso de escrita, ou o próprio fornecedor do armazenamento, vê bytes. A leitura exige uma chave que fica no cofre da empresa. É o que torna aceitável mandar para fora uma trilha que, mesmo mascarada, descreve a operação.

A LGPD, no artigo 37, manda o controlador e o operador manterem registro das operações de tratamento de dados pessoais que realizarem. A trilha de uma IA que lê dados de produção faz parte desse registro. O prazo de um ano é o nosso padrão de método; se uma norma do seu setor pede mais, vale a norma.

O erro comum é deixar a centralização para depois, porque a trilha local "já está funcionando". Ela funciona até o dia em que é a única cópia, no disco da máquina que precisa ser investigada. A análise de um incidente tem de começar pelo destino central, não pelo servidor suspeito, e isso só é possível se a decisão foi tomada antes.

Como se desliga a IA da empresa inteira?

Com um kill switch: um comando único, numa configuração central que toda instalação consulta, que faz a função de IA parar para todo mundo de uma vez. Não é remover um plugin máquina por máquina nem mandar um e-mail pedindo ao time que não use. É um estado, ligado ou revogado, que os clientes da ferramenta leem e respeitam.

O botão existe porque a pergunta "e se a IA começar a fazer mal?" não pode ter uma reunião como resposta. Um modelo que muda de comportamento numa atualização, uma instrução maliciosa espalhada por uma base de conhecimento, um fornecedor em incidente ou um custo que disparou pedem uma ação em minutos. O NIST trata isso como parte da gestão de risco de IA: o AI RMF pede mecanismos, com responsáveis definidos, para substituir, desengajar ou desativar sistemas de IA cujo desempenho fuja do uso pretendido.

Quem pode acionar é decidido antes e por escrito: poucas pessoas com perfil administrativo, pelo menos duas, para o botão não depender de alguém de férias. Quem aciona registra o motivo. Quem religa é quem responde pela ferramenta, depois de entender o que aconteceu. Desligar não precisa de licença. Religar precisa de explicação.

A confirmação é dupla porque esta é a mudança de maior impacto da ferramenta. A primeira é mecânica: toda alteração de configuração passa por um controle que pede aprovação antes de executar, sem exceção, e que não depende de o modelo lembrar de perguntar. A segunda é humana e em linguagem simples: antes de aprovar, quem aciona lê uma frase como "isto vai desligar o assistente para todo mundo". A primeira impede o acidente silencioso. A segunda impede a aprovação no automático de quem responde "sim" porque o controle sempre pergunta.

E o botão precisa ser testado como qualquer outro controle. Uma vez por trimestre, num horário combinado, alguém aciona, confere que a função parou em todas as pontas e religa. Um kill switch que nunca foi acionado é uma hipótese. Há também desligamentos menores, que são desenho e não falha: sem a chave, as funções de IA que leem dados caem, e revogar a credencial de um túnel corta uma entrada em segundos, sem tocar no servidor.

O que fazer amanhã: responda por escrito a três perguntas. Onde fica o botão que desliga a IA da empresa inteira? Quem pode apertá-lo? Quando foi a última vez que alguém apertou?

Qual é a rotina mínima que mantém a governança viva?

Quatro ritmos bastam. Todo dia, 5 minutos. Toda semana, 30. Todo mês, 2 horas. E todo trimestre, meio dia. É pouco de propósito: rotina pesada é a primeira coisa cortada num mês apertado, e governança sem rotina apodrece em silêncio. Uma ferramenta nova muda um padrão, uma pessoa sai e a conta fica, uma regra de rede é refeita e o vão do CI se abre.

Duas rotinas ficam fora do calendário curto. A rotação semestral dos segredos, em que cada troca é um PR com a data e sem o valor, como em segredo não passa pelo terminal. E a saída de uma pessoa, resolvida no mesmo dia: grupo de identidade, chaves de acesso e o segundo fator do administrador, se ela o conhecia.

A rotina também tem prova. O que é automático deixa um check verde ou vermelho. O que é humano deixa uma linha datada, como "revisão semanal feita, três PRs integrados, um alerta investigado". Sem a linha, a rotina não aconteceu, por mais que alguém se lembre de ter olhado.

O erro comum é a rotina que só olha e nunca age: revisar a lista de acesso sem remover ninguém, ler os alertas sem abrir nenhum chamado, ver há meses o check que só alerta e não promovê-lo a obrigatório. É o problema do gate que só alerta, agora no calendário. O time aprende que a rotina não muda nada e passa a pulá-la.

O que é entrega numa implantação de governança?

É a prova de cada controle, executada, registrada e assinada com data, e não o "subiu". Um guardrail instalado, um CI configurado ou um túnel no ar não são entrega. Entrega é o resultado do teste que mostra que o guardrail bloqueia, que o CI recusa o PR com segredo, que o runner não alcança produção e que o kill switch desliga.

No nosso método, cada fase de uma implantação termina com uma prova, e a fase só conta como feita quando a prova passa. No fim, um checklist de verificação percorre todos os controles que o desenho promete. Cada linha tem o teste, o resultado esperado, o resultado obtido, a data e quem executou.

1. Um PR com um segredo falso fica vermelho e não integra.
2. Um PR que publica uma porta em produção é recusado pelo validador de deploy.
3. Uma conexão do runner a um servidor de produção estoura o tempo.
4. Uma ação proibida pedida ao assistente é bloqueada e aparece na trilha, fora da máquina.
5. O acionamento do kill switch para a função em todas as pontas, e o religamento a devolve.

O quadro de estado que sai daí é o que a diretoria recebe: controle, estado, data, quem. Ele responde à pergunta "estamos protegidos?" com evidência, e não com confiança. E ele envelhece. Por isso o checklist inteiro volta a rodar a cada trimestre, e o quadro ganha uma coluna nova, em vez de ser reescrito. Mesmo checklist, mesmo critério, um ciclo depois: o que regrediu aparece antes de virar incidente.

Como as três camadas se fecham, e o que vem depois?

Com a prova e o botão atravessando as três. Na primeira camada, a de quem usa a IA, a regra escrita virou mecanismo, o guardrail decide cada ação e a configuração gerenciada não se desliga na máquina de ninguém. Na segunda, a do que a IA alcança, ela lê e não escreve dados de produção. Na terceira, a de por onde o código chega, produção nunca constrói, o gate bloqueia, o segredo não passa pelo terminal e quem roda código de PR não toca produção.

Cada controle responde às mesmas três perguntas: o que barra, como se prova que barra e o que acontece quando falha. A trilha responde à segunda em todas as camadas. O kill switch responde à terceira quando todo o resto falhar. A rotina impede que as respostas fiquem velhas.

Como dissemos no primeiro texto da série, a governança que funciona não tenta controlar o que a IA escreve. Ela estreita o caminho até produção, igual para pessoa e máquina, e deixa com as pessoas a revisão, a decisão de risco aceito e o botão de desligar. Com esse trilho de pé, provado e com botão, a pergunta muda de lugar. Agora que o trilho existe, a IA pode chegar ao cliente.