Registos de auditoria sem conteúdo: como provamos o que o modelo fez sem guardar prompts

Cada ação administrativa dentro do AI Suite produz uma linha de auditoria JSONL. A linha regista o timestamp, o email do ator, o verbo da ação, o recurso afetado, o X-App-Id do cliente originador e um hash estável que permite a um revisor correlacionar a linha com eventos posteriores. A linha não regista nada da entrada ou saída do modelo. Nem texto do prompt, nem texto da conclusão, nem conteúdo de documentos, nem entidades extraídas. Essa opção — sem conteúdo por desenho — é o que torna a linha de auditoria útil para os revisores de compras e de conformidade, e vale a pena explicar porquê.

O que está numa linha de auditoria, e o que não está

Uma linha representativa, ligeiramente redigida:

{"ts":"2026-06-05T09:14:22Z","actor":"[email protected]","action":"license.assign",
 "subject":"[email protected]","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

O que tem: metadados suficientes para responder às perguntas sobre obrigações do deployer que os auditores fazem — quem fez o quê, quando, sobre que recurso, a partir de que cliente. O que não tem: qualquer payload do fluxo de trabalho de IA. Se a ação tivesse invocado um modelo (não invocou neste exemplo, mas podia ter invocado), haveria uma linha a registar o evento de invocação, mas nenhum registo do prompt ou da resposta na nossa infraestrutura.

Essa separação é deliberada. A linha de auditoria é prova de que uma ação ocorreu. O conteúdo da ação — o prompt enviado ao modelo, a resposta devolvida — vive no próprio hardware do deployer, regido pela sua própria política de retenção. Nós nunca o vemos.

Porque é que o conteúdo fica de fora da linha

Duas razões, uma regulatória e outra operacional.

Regulatória: o EU AI Act exige aos deployers de IA de alto risco que conservem registos "por um período adequado", que monitorizem o funcionamento do sistema e que demonstrem conformidade quando solicitado ^[1]. A obrigação recai sobre o deployer, no sentido de evidenciar o que aconteceu. As APIs de LLM em nuvem respondem a isto armazenando o prompt e a resposta na infraestrutura do fornecedor, o que transfere o problema do tratamento de dados para o fornecedor — e cria um segundo perímetro de conformidade que o deployer não controla. A auditoria local sem conteúdo responde à mesma pergunta regulatória sem essa transferência: é o deployer que fica com o conteúdo, no seu próprio armazenamento, segundo as suas próprias regras de retenção.

Operacional: cada byte de conteúdo do modelo armazenado é um byte que tem de ser cifrado, sujeito a controlo de acesso, conservado, eliminado dentro do prazo e produzido em e-discovery. As linhas sem conteúdo são pequenas (algumas centenas de bytes), de forma fixa, apenas de adição, e trivialmente serializáveis para o SIEM existente do deployer. São a menor unidade probatória que ainda satisfaz a obrigação.

A que é que isto corresponde nos principais quadros

O NIST AI RMF 1.0 nomeia a auditabilidade como uma dimensão central da IA fiável e pede aos deployers que mantenham "registos das ações do sistema suficientes para reconstruir decisões" ^[2]. "Suficientes para reconstruir" é a expressão operativa: a linha tem de permitir a um revisor reconstruir o que aconteceu. Uma linha sem conteúdo faz isso para ações administrativas (foi emitida uma licença, foi alterada uma política, foi inscrito um servidor) sem reter o conteúdo de uma inferência. Para o lado do conteúdo da inferência da obrigação, é o armazenamento local do próprio deployer que responde à pergunta.

A orientação da ENISA sobre cibersegurança em IA enquadra isto a partir do ângulo da modelação de ameaças ^[3]: cada prompt e resposta armazenado na infraestrutura de um fornecedor alarga a superfície de ataque do deployer para incluir a do fornecedor. Remover o conteúdo do modelo do lado do fornecedor reduz essa superfície ao que o deployer já controla.

O formato em que entregamos — a UI do AI Admin Console, a auditoria JSONL do daemon aisuite-server e o hook de encaminhamento para SIEM por organização — concretiza isto diretamente. Cada evento administrativo aterra numa linha legível pelo deployer; nenhum conteúdo de prompt ou resposta sai jamais do perímetro do deployer.

Como isto se parece numa revisão de compras

A pergunta de compras que faz parar os fornecedores de IA em nuvem é: "onde vive o conteúdo da inferência, e pode a nossa equipa de conformidade produzi-lo a pedido?" A pergunta de compras a que a auditoria sem conteúdo responde é a mesma, com duas respostas limpas: o conteúdo vive no vosso hardware e a vossa equipa produ-lo porque já o tem. A linha de auditoria do nosso lado prova que a ação aconteceu; o conteúdo do vosso lado prova o que a ação fez.

Para o enquadramento mais amplo de compras — incluindo como liderar o questionário ao fornecedor com estas propriedades em vez de certificações do lado do fornecedor — veja Porque é que as implantações de IA on-prem ficam paradas em compras e o artigo sobre conformidade com o EU AI Act.

O que permanece da responsabilidade do deployer

A auditoria sem conteúdo é uma propriedade estrutural da implantação, não uma solução de conformidade ponta a ponta. O deployer continua a ser dono de:

• Definir o que "suficiente para reconstruir" significa para os seus próprios fluxos de trabalho — período de retenção, regras de mascaramento, postura de e-discovery.
• Operar o armazenamento local de conteúdo (o que o deployer escolher — sistema de ficheiros, base de dados de documentos, armazenamento cifrado de blobs) e encaminhar as linhas de auditoria do nosso lado para o SIEM onde as correlaciona com os seus próprios registos.
• Redigir o memorando das obrigações do deployer que aponta para esta arquitetura durante as compras.

O nosso lado entrega a arquitetura e o formato da linha de auditoria. Tudo o que está a jusante disso — incluindo a política de retenção sobre o conteúdo — é onde a equipa de conformidade do deployer aplica as suas próprias regras.

Referências

1. Comissão Europeia. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Acedido a 2026-06-03.
2. NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Acedido a 2026-06-03.
3. ENISA. "Artificial Intelligence Cybersecurity." enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Acedido a 2026-06-03.

Artigos relacionados

• AI Admin Console: o que cada uma das seis capacidades faz, na realidade
• Zero falhas de projeto desde 2007 — as regras de engenharia que sustentam o registo
• EU AI Act em 2026: o que a implantação on-prem altera em matéria de conformidade
• Porque é que as implantações de IA on-prem ficam paradas em compras (e o enquadramento que resolve a situação)
• Todos os artigos →