Cada ação administrativa dentro do AI Suite gera uma linha de auditoria JSONL. A linha regista o carimbo temporal, o email do ator, o verbo da ação, o recurso afetado, o X-App-Id do cliente originário, e um hash estável que permite a um revisor correlacionar a linha com eventos posteriores. A linha regista nenhum dado de entrada ou saída do modelo. Sem texto do prompt, sem texto da conclusão, sem conteúdo do documento, sem entidades extraídas. Essa escolha — sem conteúdo por design — é o que torna a linha de auditoria útil para revisores de compras e conformidade, e vale a pena explicar porquê.

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

Uma linha representativa, ligeiramente redigida:

{"ts":"2026-06-05T09:14:22Z","actor":"jane@bank.example","action":"license.assign",
 "subject":"user@bank.example","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 de obrigações do implementador que os auditores fazem — quem fez o quê, quando, contra qual recurso, a partir de qual cliente. O que não tem: qualquer carga útil do fluxo de trabalho de IA. Se a ação invocasse um modelo (não aconteceu neste exemplo, mas poderia ter acontecido), haveria uma linha a registar o evento de invocação, mas sem 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 retornada — permanece no hardware do próprio implementador, regido pela política de retenção do implementador. Nós nunca o vemos.

Por que o conteúdo fica fora da linha

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

Regulatória: o Regulamento de IA da UE exige que os implementadores de IA de alto risco mantenham registros "por um período apropriado", para monitorar a operação do sistema e demonstrar conformidade mediante solicitação [1]. A obrigação é do implementador para evidenciar o que aconteceu. APIs de LLM em nuvem respondem a isso 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 implementador não controla. Auditoria local sem conteúdo responde à mesma questão regulatória sem essa transferência: o implementador mantém o conteúdo, no armazenamento próprio do implementador, sob as regras de retenção do implementador.

Operacional: cada byte de conteúdo do modelo armazenado é um byte que precisa ser criptografado, controlado no acesso, retido, excluído conforme cronograma e produzido em processos de descoberta eletrônica. Linhas sem conteúdo são pequenas (algumas centenas de bytes), de formato fixo, somente acréscimo, e trivialmente serializáveis no SIEM existente do implementador. São a menor unidade probatória que ainda satisfaz a obrigação.

A que isso corresponde nos principais frameworks

O NIST AI RMF 1.0 nomeia a auditabilidade como uma dimensão central da IA confiável e pede que os implementadores mantenham "registros das ações do sistema suficientes para reconstruir decisões" [2]. "Suficientes para reconstruir" é a frase operativa: a linha deve permitir que um revisor reconstrua o que aconteceu. Uma linha sem conteúdo faz isso para ações administrativas (uma licença foi emitida, uma política foi alterada, um servidor foi registrado) 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 implementador é o que responde à questão.

A orientação de cibersegurança de IA da ENISA enquadra isso do ângulo da modelagem de ameaças [3]: cada prompt e resposta armazenados na infraestrutura de um fornecedor amplia a superfície de ataque do implementador para incluir a do fornecedor. Remover o conteúdo do modelo do lado do fornecedor reduz essa superfície para o que o implementador já controla.

A forma que entregamos — a AI Admin Console UI, o aisuite-server daemon JSONL de auditoria, e o gancho de encaminhamento SIEM por organização — implementam isso diretamente. Cada evento administrativo aparece em uma linha legível pelo implantador; no caminho local ou hospedado pelo cliente para inferência, o conteúdo do prompt e da resposta não vai para o plano de controle da Software Tailor.

Como isso se apresenta em uma revisão de compras

A pergunta de compras que trava os fornecedores de IA em nuvem é: "onde o conteúdo da inferência fica armazenado, e nossa equipe de conformidade pode produzi-lo sob demanda?" A auditoria sem conteúdo responde a essa mesma pergunta, com duas respostas claras: o conteúdo fica no seu hardware, e sua equipe o produz porque já o possui. A linha de auditoria do nosso lado prova que a ação ocorreu; o conteúdo do seu lado prova o que a ação realizou.

Para o enquadramento mais amplo da compra — incluindo como conduzir o questionário ao fornecedor com essas propriedades em vez de certificações do lado do fornecedor — veja Por que implantações de IA on-premises travam na compra e o artigo sobre conformidade com a EU AI Act.

O que permanece responsabilidade do implantador

A auditoria sem conteúdo é uma propriedade estrutural da implantação, não uma solução completa de conformidade. O implantador ainda é responsável por:

  • Definir o que significa "suficiente para reconstruir" para 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 (seja qual for a escolha do implantador — sistema de arquivos, banco de dados de documentos, armazenamento de blobs criptografados) e encaminhar as linhas de auditoria do nosso lado para o SIEM onde elas são correlacionadas com seus próprios logs.
  • Redigindo o memorando de obrigação do implantador que aponta para esta arquitetura durante a aquisição.

Nossa parte entrega a arquitetura e o formato da linha de auditoria. Tudo a jusante disso — incluindo a política de retenção do conteúdo — é onde a equipe de conformidade do implantador aplica suas próprias regras.

Referências

  1. Comissão Europeia. "AI Act — Quadro regulatório sobre IA." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Acesso em 2026-06-03.
  2. NIST. "AI Risk Management Framework (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Acesso em 2026-06-03.
  3. ENISA. "Cibersegurança em Inteligência Artificial." https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Acesso em 2026-06-03.