Secure AI é um problema de engenharia

A discussão pública sobre segurança de IA acontece quase toda no nível do modelo: o que ele pode dizer, o que foi treinado nele, o que acontece quando alguém o induz a sair da linha. É uma discussão legítima, e é a errada para quem precisa colocar um sistema desses em produção nesta semana.

Para quem opera, o modelo é um componente com interface definida: entram texto e contexto, saem texto e, cada vez mais, intenções de ação. O risco quase nunca está nesse componente. Está no caminho — no que o sistema deixa o modelo ler, no que o deixa fazer, sob a autoridade de quem ele age, quem confirma antes do efeito, como o efeito é aplicado e o que sobra registrado depois. São seis camadas, e todas as seis são engenharia comum feita com rigor incomum.

Contexto é superfície de entrada

No momento em que um sistema recupera documentos, tíquetes, mensagens ou páginas para compor um prompt, ele está colocando conteúdo não confiável dentro do canal de instrução. A separação entre dado e instrução — que a indústria levou décadas para construir em bancos de dados e navegadores — é desfeita aqui por padrão. Um documento pode conter uma frase endereçada ao modelo, e o modelo não tem como saber que aquela frase não veio de você.

O tratamento é de engenharia, não de redação de prompt. Proveniência é atributo do trecho recuperado, e não do repositório inteiro; níveis de confiança diferentes precisam produzir tratamentos diferentes; e o que pode ser recuperado precisa respeitar a mesma autorização do sistema de origem. Essa última parte é a que falha em silêncio: um índice construído com uma credencial ampla vira um caminho lateral que devolve, em linguagem natural e sem registro reconhecível, exatamente aquilo que o controle de acesso original recusaria.

Política precisa ser executável

Há uma diferença de natureza entre uma política escrita num documento, uma política escrita no prompt e uma política que roda. A primeira orienta pessoas. A segunda é um pedido feito a um sistema probabilístico — funciona na maioria das vezes, que é exatamente o regime em que um controle de segurança não pode operar. A terceira é um componente capaz de recusar.

Uma política que só existe dentro do prompt não é um controle. É um pedido educado feito a um sistema que às vezes discorda.

Política executável significa uma camada fora do modelo que avalia a ação proposta contra regras determinísticas antes de qualquer efeito: classe de operação, destino, escopo de dado, limite, janela de tempo, e a decisão de bloquear, exigir confirmação ou permitir. Significa também versionamento. Quando alguém perguntar por que uma ação passou há três meses, a resposta precisa ser a regra vigente há três meses, e não a de hoje — do contrário, o registro descreve um sistema que não existia.

Identidade: em nome de quem o sistema agiu

Sistemas de IA que agem precisam responder a uma pergunta antiga de segurança, e quase sempre a respondem mal por omissão. Dois modos de falha aparecem com frequência. No primeiro, o sistema carrega uma credencial de serviço ampla porque foi assim que se conseguiu fazer funcionar: o alcance de qualquer erro passa a ser a união de todas as permissões de todos os usuários, e o registro de auditoria aponta sempre o mesmo autor, o que equivale a não registrar. No segundo, o sistema atua indistinguível da pessoa, e ninguém consegue separar o que o usuário fez do que foi feito em nome dele.

O desenho correto é conhecido e sem graça: o agente é um principal distinto; recebe autoridade delegada, para um escopo e por um prazo; nunca acumula mais do que a interseção entre o que a tarefa exige e o que o usuário possui; e aparece no registro como ele mesmo, com a delegação anexada. Nada disso é específico de IA. É a mesma disciplina de identidade que já se aplicava a integrações, exercida sobre um componente que agora toma iniciativa.

Aprovação humana é um componente, não uma promessa

Humano no circuito é uma intenção até virar desenho. As perguntas que transformam a intenção em componente são poucas e específicas:

• —Quais classes de ação param e esperam — definidas pelo efeito que produzem, e não pela confiança declarada do modelo.
• —O que exatamente é mostrado a quem aprova: o efeito concreto que vai ocorrer, e não o resumo que o próprio sistema fez dele.
• —Qual é o comportamento padrão quando ninguém responde, e por que o padrão seguro raramente é executar.
• —Com que frequência as aprovações chegam, porque uma fila densa demais é aprovada sem leitura — e isso não é falha de disciplina, é falha de projeto.

A última é a mais subestimada. Um controle de aprovação que dispara para tudo se degrada sozinho até virar um clique, e um clique não é uma decisão. Escolher o que não para é parte do controle, e é uma decisão de engenharia que precisa ser justificada, revista periodicamente e registrada como qualquer outra.

Execução é onde o risco vira fato

Antes da execução, um erro é texto. Depois, é uma mensagem entregue, um registro alterado, um pagamento iniciado, um acesso revogado no meio do expediente. A camada de execução é onde a maior parte da engenharia de contenção realmente cabe, e ela tem propriedades verificáveis: ferramentas com capacidade estreita em vez de acesso geral; separação estrutural, e não apenas de nomenclatura, entre operações que leem e operações que escrevem; idempotência, para que uma repetição por retentativa não produza dois efeitos; e um modo de planejar antes de aplicar que seja de primeira classe, e não um argumento opcional que alguém pode esquecer de passar.

Reversibilidade é o resto do problema. Onde a ação é irreversível no mundo — dinheiro que saiu, mensagem que chegou, porta que abriu —, a reversibilidade precisa ser deslocada para antes: uma janela curta entre decidir e efetivar converte o irreversível em cancelável, e essa janela costuma ser a diferença entre um incidente e um susto.

O registro que sobrevive ao evento

Sistemas com modelo generativo não são reproduzíveis por repetição: rodar de novo não devolve o mesmo caminho e, portanto, não explica o que aconteceu. Isso muda o que o registro precisa conter. Não basta guardar entrada e saída. É preciso guardar qual contexto foi recuperado e de onde, qual versão de política avaliou a ação, sob qual identidade e delegação ela correu, quem aprovou, o que foi executado e qual foi o resultado observado. Reconstruir isso depois é impossível; capturar no momento é barato — e é a diferença entre um sistema auditável e um sistema sobre o qual só se pode ter opinião.

Escolher um modelo mais seguro não é uma arquitetura de segurança. É uma preferência sobre um dos componentes.

É por isso que tratamos Secure AI como engenharia e recusamos as duas versões fáceis do problema. A primeira promete um modelo confiável o bastante para dispensar as camadas ao redor, o que transfere para um fornecedor uma responsabilidade que continua sendo de quem opera. A segunda responde ao risco proibindo o uso, o que empurra a prática para fora do perímetro, onde ela continua acontecendo sem contexto controlado, sem política e sem registro. Nenhuma das duas é uma decisão de segurança. As duas são formas de não decidir.