Investigações forenses em sistemas de inteligência artificial: rastreabilidade entre dados, modelos, prompts, agentes e infraestrutura

Introdução

Sistemas de inteligência artificial passaram a participar de decisões empresariais, classificação de documentos, atendimento, detecção de fraudes, desenvolvimento de software, controle de processos industriais e execução automatizada de tarefas. Quando ocorre uma resposta indevida, uma divulgação de informação, uma alteração suspeita de comportamento ou uma ação não autorizada, a investigação precisa responder a uma questão mais complexa do que identificar quem utilizou uma aplicação.

O resultado observado pode ter sido condicionado pelo conjunto de treinamento, pela versão do modelo, por um adaptador de ajuste fino, pelo prompt de sistema, pelo histórico da conversa, pelos documentos recuperados por uma arquitetura RAG, por filtros de segurança, por ferramentas concedidas a um agente, por alterações na infraestrutura ou por uma atualização realizada pelo fornecedor. Em sistemas probabilísticos, duas requisições aparentemente iguais ainda podem produzir respostas diferentes.

A perícia em inteligência artificial, portanto, deve reconstruir uma cadeia computacional distribuída. Essa cadeia começa na origem dos dados, atravessa treinamento, avaliação, registro e implantação do modelo, alcança a montagem do contexto de inferência e termina nas respostas, chamadas de ferramentas e efeitos produzidos em outros sistemas corporativos.

O objeto pericial não é apenas o modelo. É o sistema sociotécnico que seleciona dados, executa código, administra identidades, controla versões, formula instruções, recupera conteúdo, chama serviços e registra — ou deixa de registrar — cada etapa.

O que precisa ser demonstrado tecnicamente

Uma alegação como “a IA realizou a operação” é insuficiente para orientar um exame. A investigação deve convertê-la em proposições técnicas delimitadas. Dependendo do incidente, pode ser necessário determinar se:

1. uma requisição específica foi recebida pela aplicação em determinado momento;
2. o conteúdo atribuído ao usuário corresponde ao conteúdo efetivamente encaminhado ao modelo;
3. determinada versão do modelo, do prompt e da base de recuperação estava ativa;
4. a resposta preservada foi produzida naquela execução e não modificada posteriormente;
5. documentos recuperados, memórias ou mensagens anteriores influenciaram a geração;
6. uma chamada de ferramenta foi apenas proposta pelo modelo ou efetivamente executada;
7. a ação foi autorizada por usuário, identidade técnica, política ou aprovação humana;
8. dados ou pesos do modelo sofreram alteração antes do comportamento investigado;
9. informações confidenciais apareceram na saída por recuperação, contexto, treinamento, cache, ferramenta ou integração externa;
10. a hipótese de ataque é mais compatível com os vestígios do que falha de configuração, atualização legítima ou comportamento probabilístico esperado.

Essas proposições separam observação de inferência. Também impedem que termos como “alucinação”, “vazamento”, “envenenamento” ou “autonomia” sejam empregados como conclusões antes da reconstrução da arquitetura e da execução.

A unidade de análise é o sistema de IA

O NIST AI Risk Management Framework trata os riscos ao longo do projeto, desenvolvimento, implantação, uso e avaliação de sistemas de IA. Essa perspectiva é particularmente útil para a perícia porque o comportamento final não depende de um único artefato.

Uma arquitetura corporativa contemporânea pode conter:

• fontes de dados, processos de rotulagem e transformação;
• notebooks, código de treinamento e pipelines de MLOps;
• experimentos, checkpoints, adaptadores e registries de modelos;
• serviços de inferência próprios ou APIs de terceiros;
• prompts de sistema, templates e regras de orquestração;
• filtros de entrada e saída;
• bancos vetoriais, mecanismos de busca e bases RAG;
• memória de sessão ou memória persistente;
• agentes, ferramentas, plugins e funções;
• serviços de identidade, cofres de segredos e políticas de autorização;
• containers, clusters, GPUs, servidores e serviços de nuvem;
• sistemas de negócio que recebem as decisões ou ações resultantes.

A investigação deve representar essas relações antes de interpretar logs. O mesmo campo denominado model pode designar um nome comercial, um endpoint de implantação, uma versão registrada ou apenas um alias mutável. Da mesma forma, o “prompt” visto na interface pode ser apenas uma das mensagens incorporadas à requisição final.

Camadas de evidência e suas funções

O valor probatório cresce quando uma mesma ocorrência pode ser relacionada por identificadores independentes, como request_id, trace_id, run_id, digest do modelo, versão do prompt, identidade autenticada e identificador da operação produzida no sistema de destino.

Proveniência dos dados

Dados podem influenciar o comportamento durante pré-treinamento, ajuste fino, aprendizagem por preferência, avaliação, construção de embeddings ou recuperação em tempo de inferência. A primeira tarefa é identificar em qual estágio a informação ou padrão investigado poderia ter ingressado.

Conjuntos de treinamento e ajuste fino

Para reconstruir uma execução de treinamento, devem ser buscados:

• identificadores e snapshots dos conjuntos utilizados;
• hashes de arquivos, shards, tabelas e manifestos;
• origem, licença, período e responsável pela incorporação;
• regras de seleção, deduplicação, limpeza e filtragem;
• esquema e versões das transformações;
• histórico de rotulagem e revisão;
• divisão entre treinamento, validação e teste;
• amostragem, ponderação e balanceamento;
• dados sintéticos e respectivos geradores;
• registros de exclusão ou correção;
• controle de acesso e auditoria dos repositórios.

O conteúdo original deve ser preservado separadamente das representações processadas. Tokenização, normalização, anonimização, redimensionamento de imagens ou conversão de formatos podem remover metadados necessários para explicar a origem de um registro.

Uma linha encontrada no conjunto atual não demonstra automaticamente que integrou a execução histórica de treinamento. É necessário correlacioná-la com a versão do dataset, o manifesto do job, os logs de leitura e, quando possível, os artefatos resultantes. O inverso também é verdadeiro: a ausência na versão corrente não afasta presença em snapshot anterior que foi substituído ou removido.

Envenenamento e backdoors

O envenenamento de dados envolve interferência no conjunto ou no processo de aprendizagem para alterar o comportamento do modelo. Um backdoor pode associar um gatilho específico a uma resposta desejada sem degradar de modo evidente o desempenho geral. O NIST AI 100-2 organiza ataques de aprendizagem de máquina adversarial conforme estágios do ciclo de vida, objetivos, capacidades e conhecimento do atacante.

O exame pericial deve procurar, entre outros elementos:

• inserções ou alterações próximas ao treinamento relevante;
• concentrações incomuns de amostras, rótulos ou padrões;
• credenciais e identidades que escreveram nos repositórios;
• divergências entre o dataset aprovado e o efetivamente montado pelo job;
• scripts de transformação alterados;
• artefatos intermediários fora do fluxo oficial;
• comportamento condicionado a gatilhos reproduzíveis;
• checkpoints em que o comportamento surge;
• métricas globais que possam ter ocultado degradações localizadas.

A mera presença de amostras anômalas não basta para atribuir intenção. Erros de rotulagem, sincronização, corrupção, duplicação e mudanças legítimas de distribuição precisam ser testados como hipóteses alternativas.

Reconstrução do treinamento e do modelo

O modelo examinado deve ser tratado como um conjunto versionado de artefatos. Conforme a tecnologia, esse conjunto pode incluir:

• pesos e checkpoints;
• arquitetura e configuração;
• tokenizer, vocabulário e templates de chat;
• adaptadores LoRA ou outros componentes de ajuste eficiente;
• cabeças de classificação e limiares;
• arquivos de pré e pós-processamento;
• código customizado carregado com o modelo;
• versão do framework e bibliotecas;
• formato numérico, quantização e otimizações;
• model card, métricas e registros de avaliação;
• assinaturas, digests e metadados do registry.

Um sistema de registro pode documentar qual experimento e execução produziram cada versão. O MLflow Model Registry, por exemplo, mantém versões, aliases, tags e linhagem entre o modelo e a execução que o gerou. Para a perícia, porém, aliases como production ou champion devem ser resolvidos historicamente: eles são nomes operacionais que podem passar a apontar para outro artefato.

Elementos de uma execução de treinamento

Uma reprodução tecnicamente informada requer preservar:

• commit do código e estado do repositório;
• configuração integral e hiperparâmetros;
• dataset e transformações;
• seeds declaradas;
• versões de drivers, bibliotecas e frameworks;
• tipo de hardware e topologia distribuída;
• imagem de container e pacotes instalados;
• variáveis de ambiente relevantes;
• ordem e particionamento dos dados;
• logs, métricas e checkpoints intermediários;
• identidade que iniciou ou aprovou a execução;
• destino de publicação do modelo.

Mesmo com seeds fixas, algumas operações em GPU ou treinamento distribuído podem não ser determinísticas. Assim, uma reprodução que gere pesos diferentes não invalida automaticamente a documentação histórica. O objetivo pode ser reproduzir métricas e comportamentos dentro de tolerâncias definidas, além de verificar se as entradas e o procedimento são compatíveis com o artefato preservado.

Modelo próprio e modelo acessado por API

Quando a organização controla os pesos, é possível calcular hashes, examinar arquivos e preservar o ambiente de inferência. Em APIs gerenciadas, o cliente pode conhecer apenas um identificador lógico fornecido pelo serviço. A investigação deve então priorizar:

• identificador de modelo retornado ou solicitado;
• versão do endpoint e histórico de implantação;
• região, projeto, tenant e conta;
• parâmetros da requisição;
• identificadores de resposta e cabeçalhos;
• logs do gateway e do provedor;
• avisos de atualização ou descontinuação;
• políticas de retenção e uso de dados vigentes no período;
• cópias legítimas das entradas e saídas mantidas pelo cliente.

Se o provedor substitui silenciosamente o artefato por trás de um nome estável, pode ser impossível repetir exatamente a execução. Essa impossibilidade deve ser descrita como limitação de versionamento, e não compensada por suposições sobre o modelo utilizado.

A requisição real ao modelo

Em aplicações generativas, o texto digitado pelo usuário é apenas uma parte da entrada. A requisição pode ser formada por:

• instruções do sistema;
• template de prompt versionado;
• identidade, perfil e permissões do usuário;
• histórico da conversa;
• memória persistente;
• documentos e trechos recuperados;
• descrições de ferramentas e respectivos schemas;
• políticas de segurança;
• exemplos de referência;
• resultados de chamadas anteriores;
• parâmetros de geração.

O examinador precisa recuperar, na ordem original, as mensagens efetivamente transmitidas. Capturas de tela da interface são úteis para registrar o que foi exibido, mas normalmente não mostram instruções ocultas, conteúdo recuperado, truncamento de contexto, retries ou transformação realizada pelo middleware.

Parâmetros de inferência

Entre os parâmetros relevantes estão temperatura, top_p, top_k, número máximo de tokens, stop sequences, seed, penalidades, formato de resposta e opções de ferramenta. Também devem ser registrados modelo, endpoint, região, horário e versão da aplicação.

Parâmetros iguais não asseguram reprodução exata. Diferenças na implementação, paralelismo, versão do modelo, filtragem, roteamento e backend podem alterar o resultado. Por isso, uma tentativa de reprodução deve ser classificada como experimento sobre compatibilidade comportamental, salvo quando houver garantia técnica de execução determinística.

Sistemas RAG e memória

Arquiteturas de geração aumentada por recuperação introduzem uma cadeia adicional. Uma pergunta pode ser reescrita, convertida em embedding, pesquisada em um índice, combinada com filtros de acesso e reranqueada antes de os trechos serem inseridos no prompt.

Devem ser preservados:

• consulta original e consulta transformada;
• modelo e versão de embedding;
• versão e configuração do índice;
• documentos-fonte e seus hashes;
• método de segmentação e identificadores dos chunks;
• metadados e filtros de autorização;
• valores ou distâncias de similaridade;
• reranker e respectivos resultados;
• ordem dos trechos enviados ao modelo;
• template usado para incorporar o material;
• políticas de atualização e exclusão do índice.

Uma resposta que reproduz informação confidencial pode ter origem em documento recuperado, e não nos pesos do modelo. Essa distinção muda a direção da coleta: banco vetorial, serviço de busca, ACLs, repositório documental e logs de ingestão tornam-se fontes centrais.

Memórias persistentes também devem ser examinadas como bancos de dados. É necessário identificar chave de usuário ou sessão, conteúdo armazenado, algoritmo de resumo, data, origem e operações de exclusão. Resumos automáticos podem omitir ou transformar partes do histórico, razão pela qual não devem ser tratados como substitutos da conversa completa.

Injeção de prompt e manipulação de contexto

A injeção direta ocorre quando instruções fornecidas pelo usuário influenciam o modelo a desconsiderar regras pretendidas. A injeção indireta pode estar embutida em página, documento, e-mail, imagem processada por OCR, resultado de busca ou conteúdo recuperado por RAG. O OWASP descreve a injeção de prompt como manipulação capaz de alterar o comportamento, influenciar decisões ou induzir acesso indevido.

Para investigar a hipótese, não basta observar que a saída foi inadequada. Deve-se reconstruir:

1. o conteúdo externo efetivamente ingerido;
2. sua posição e delimitação no contexto;
3. as instruções de sistema e regras aplicáveis;
4. transformações realizadas por OCR, parser ou sanitização;
5. resposta intermediária do modelo;
6. decisão do orquestrador sobre ferramentas;
7. controles que deveriam impedir a ação;
8. efeitos confirmados em sistemas externos.

Trechos escondidos por CSS, caracteres Unicode, conteúdo fora da área visível, metadados e camadas de documentos podem ser relevantes. A aquisição deve preservar o objeto original e a representação processada pelo pipeline, pois o modelo pode ter recebido conteúdo diferente daquele visível a um observador humano.

Agentes e execução de ferramentas

Sistemas agentivos permitem que o modelo selecione funções, consulte bases, envie mensagens, execute código ou altere registros. O risco não reside apenas no conteúdo da resposta, mas na conversão de uma saída probabilística em ação operacional. O OWASP denomina de agência excessiva a concessão de funções e permissões além do necessário ao sistema baseado em modelo.

Uma investigação deve distinguir cinco eventos:

1. o modelo sugeriu uma ferramenta;
2. o orquestrador aceitou a sugestão;
3. os argumentos foram validados ou transformados;
4. a chamada foi autenticada e enviada;
5. o sistema de destino executou e confirmou o efeito.

O trace do agente pode registrar uma chamada como concluída mesmo quando o serviço de destino a rejeitou. Da mesma forma, o registro do destino comprova a operação, mas pode não explicar qual contexto levou o agente a solicitá-la. A correlação depende de IDs de trace, call ID, principal de serviço, timestamp, parâmetros, resposta HTTP, identificador transacional e logs do destino.

Vestígios específicos de agentes

• objetivo ou tarefa inicial;
• instruções de sistema e política do agente;
• decomposição em etapas;
• mensagens internas e memória;
• catálogo de ferramentas apresentado;
• schemas e versões das funções;
• argumentos propostos e argumentos efetivamente enviados;
• resultados devolvidos ao modelo;
• retries, loops e tratamento de erros;
• aprovações humanas e interfaces utilizadas;
• credenciais, scopes e política de autorização;
• sandboxes e limites de execução;
• efeito final em cada serviço conectado.

O MITRE ATLAS reúne táticas e técnicas observadas contra sistemas de IA, incluindo componentes generativos, prompts, contexto de recuperação, modelos e dados. Sua taxonomia pode auxiliar a formular hipóteses, mas a classificação do incidente deve decorrer dos vestígios coletados.

Telemetria, logs e privacidade

Logs de IA precisam permitir correlação sem criar um novo repositório indiscriminado de dados sensíveis. O registro integral de prompts e respostas melhora a capacidade de reconstrução, mas pode copiar segredos empresariais, dados pessoais, documentos confidenciais e credenciais.

Uma arquitetura equilibrada pode registrar por padrão:

• trace e request IDs;
• identidade ou pseudônimo correlacionável sob controle;
• modelo e versão;
• versão do prompt e da aplicação;
• parâmetros não sensíveis;
• digests de entradas e saídas preservadas em repositório segregado;
• documentos ou chunks por identificador;
• ferramentas, decisões e status;
• duração, tokens e códigos de erro;
• política e resultado de avaliação;
• referência ao conteúdo protegido, em vez de duplicá-lo no log operacional.

Quando o conteúdo integral é necessário, devem ser definidos finalidade, acesso, criptografia, segregação, retenção e procedimento de preservação. Redação ou tokenização irreversível pode proteger o uso cotidiano; uma fonte original, quando legitimamente necessária, pode ser mantida em repositório de acesso restrito.

As convenções semânticas de IA generativa do OpenTelemetry incluem atributos para modelo, instruções, mensagens de entrada e saída, ferramentas, fontes de dados e parâmetros. A padronização favorece a correlação, mas não garante que todos os campos estejam habilitados, íntegros ou completos.

Infraestrutura e cadeia de implantação

A resposta atribuída a um modelo pode decorrer de alteração na infraestrutura. Devem ser examinados:

• commits e pipelines de MLOps;
• imagens de container, manifests e digests;
• registros do cluster e do runtime;
• alterações de deployment, ConfigMaps e secrets;
• gateways, balanceadores e roteamento entre modelos;
• políticas IAM, tokens e identidades de workload;
• feature flags e experimentos A/B;
• serviços de cache;
• filas, bancos e object stores;
• eventos de rede e egress;
• endpoints de administração e notebooks.

Em Kubernetes, o log de auditoria forma um registro cronológico de ações produzidas por usuários, aplicações e pelo plano de controle, permitindo investigar o que ocorreu, quando e por qual identidade. Sua utilidade depende da política de auditoria, do nível registrado, da retenção e da proteção do backend.

Uma alteração de alias no registry, de variável no deployment ou de regra no gateway pode substituir o modelo efetivo sem modificar a aplicação cliente. Por isso, o valor enviado na requisição precisa ser correlacionado com a resolução feita pela infraestrutura no momento do evento.

Aquisição conforme o modelo de implantação

Modelos próprios ou open-weight

Preservam-se pesos, adaptadores, tokenizer, configuração, ambiente de inferência e registros de implantação. Arquivos grandes podem exigir inventário por objeto, hashes robustos e armazenamento que mantenha metadados. Deduplicação ou cópia entre object stores deve ser documentada.

Serviços gerenciados por API

A organização depende de logs do cliente, gateway e provedor. Solicitações de preservação precisam considerar os períodos de retenção, as regiões e os identificadores usados pelo serviço. Exportações administrativas devem registrar filtros, fuso, paginação, limites e campos omitidos.

Aplicações SaaS com IA incorporada

O modelo pode não ser exposto ao cliente. A coleta deve abranger auditoria do tenant, conversas exportáveis, integrações, identidade, políticas, conectores e sistemas de origem. Capturas de tela devem ser complementadas por exports ou APIs quando disponíveis.

IA executada no endpoint

Estações podem conter modelos baixados, caches, prompts, bancos locais, extensões, históricos, notebooks, ambientes virtuais e aceleração por GPU. A aquisição deve considerar memória volátil quando processos, chaves, conteúdo não gravado ou modelos carregados forem relevantes.

Ambientes de nuvem e multitenancy

A separação entre plano de controle, dados do tenant e infraestrutura do provedor impõe limites de acesso. O SWGDE recomenda documentar método, escopo, ferramenta, credenciais, filtros e limitações na aquisição de evidência de provedores de nuvem.

Preservação de estado volátil

Alguns vestígios podem desaparecer em minutos ou horas:

• pods e containers efêmeros;
• memória de processos e GPU;
• filas e resultados intermediários;
• traces com retenção curta;
• contexto de sessão e cache;
• índices reconstruídos continuamente;
• endpoints ou aliases substituídos;
• artefatos temporários de treinamento;
• links de download e respostas não persistidas.

A ordem de coleta deve priorizar essas fontes sem modificar desnecessariamente o sistema. Antes de reiniciar serviços, reexecutar prompts ou efetuar rollback, é recomendável registrar o estado corrente, preservar configurações, snapshots, logs e digests. A reprodução deve ocorrer em ambiente separado sempre que possível.

Metodologia pericial integrada

1. Definição do incidente e das proposições

Delimitam-se comportamento, período, usuários, sistemas afetados e efeitos empresariais. Termos genéricos são traduzidos em eventos verificáveis.

2. Mapeamento arquitetural

Documentam-se fluxos entre interface, orquestrador, modelo, RAG, agentes, ferramentas, identidade e sistemas de destino. Cada componente recebe proprietário, tecnologia, região e retenção conhecida.

3. Priorização e preservação

Fontes voláteis são adquiridas primeiro. Pesos, datasets, prompts, configurações, índices e logs são preservados com hashes, cadeia de custódia e descrição do método.

4. Normalização de identidades e tempos

Contas humanas, service accounts, chaves de API e identidades de workload são relacionadas. Timestamps são preservados com fonte, precisão, fuso e conversão.

5. Reconstrução da linhagem

Relacionam-se dataset, código, treinamento, checkpoint, registry, deployment, endpoint e modelo efetivo. Mudanças de alias ou configuração são representadas temporalmente.

6. Reconstrução da inferência

Recuperam-se mensagens, prompts, documentos RAG, parâmetros, filtros, respostas intermediárias, ferramentas e resultado final. Traces são confrontados com logs dos serviços de destino.

7. Testes controlados

Reproduções, testes de gatilho e avaliações contrafactuais são executados em cópias controladas. Devem ser registradas tentativas favoráveis e desfavoráveis, número de execuções e variabilidade observada.

8. Avaliação de hipóteses alternativas

Examinam-se atualização legítima, dados incorretos, mudança de distribuição, falha de integração, erro humano, configuração, cache, comportamento estocástico e ação adversarial.

9. Relato reproduzível

O relatório diferencia fatos observados, resultados experimentais e inferências. Lacunas de retenção, acesso ou versionamento são explicitadas.

Exemplo técnico: agente corporativo e instrução indireta

Considere um agente utilizado para analisar propostas comerciais recebidas por e-mail, consultar políticas internas e preparar solicitações de compra. Após processar um PDF enviado por fornecedor, o agente cria uma solicitação acima do limite esperado e encaminha informação interna ao endereço externo.

A interface mostra apenas que o documento foi analisado. A reconstrução revela uma cadeia mais extensa. O serviço de ingestão extraiu do PDF um trecho não visível na página renderizada. Esse texto continha instruções dirigidas ao sistema automatizado. O mecanismo RAG inseriu o trecho no contexto com alta prioridade, ao lado das políticas corporativas.

O trace do agente registrou uma chamada à ferramenta de consulta de orçamento e outra à API de compras. A descrição da ferramenta permitia criar solicitações sem limitar o valor, e a identidade técnica possuía escopo mais amplo do que o necessário. Não havia aprovação humana vinculante para aquela faixa de valor.

Os logs da API de compras confirmaram a criação e forneceram o identificador transacional. O gateway de e-mail confirmou o envio posterior. A correlação por trace ID, identidade técnica, timestamps e IDs de transação demonstrou que as ações foram executadas, e não apenas sugeridas pelo modelo.

Para testar alternativas, a perícia preservou a versão do modelo, o prompt, o PDF original, o texto extraído, o índice, o workflow e as políticas. Em ambiente isolado, múltiplas execuções com o trecho malicioso produziram chamadas semelhantes; com o trecho removido, o comportamento deixou de ocorrer nas condições testadas. O resultado sustenta uma relação técnica entre a instrução indireta, o contexto e as ações. A análise ainda deve registrar a variabilidade das execuções e não atribuir intenção ao fornecedor sem evidência adicional sobre a origem do conteúdo oculto.

Limitações e inferências que exigem cautela

• resposta semelhante não demonstra uso do mesmo modelo;
• nome comercial do modelo não identifica necessariamente a versão efetiva;
• captura de tela não contém todo o contexto enviado à API;
• log do agente não comprova sozinho a execução no sistema de destino;
• saída confidencial não demonstra automaticamente memorização no treinamento;
• presença de dado no dataset atual não prova participação em treinamento anterior;
• divergência em reprodução não afasta o evento original em sistema probabilístico;
• hash dos pesos não descreve prompt, RAG, filtros ou ferramentas;
• alerta de segurança classificado como prompt injection não substitui a reconstrução;
• conta técnica identifica a credencial usada, não necessariamente a pessoa que causou a operação;
• ausência de log pode decorrer da política de coleta e não da ausência do evento;
• explicação produzida pelo próprio modelo sobre sua decisão não equivale ao estado interno histórico.

Sistemas generativos podem oferecer justificativas plausíveis que não correspondem ao processo real que produziu a resposta. Explicações pós-hoc devem ser tratadas como nova saída do sistema, e não como depoimento confiável sobre a execução anterior.

Prontidão forense para sistemas de IA

Investigações futuras se tornam mais consistentes quando a arquitetura foi projetada para rastreabilidade. Medidas proporcionais incluem:

• inventário de modelos, datasets, aplicações, agentes e integrações;
• versionamento imutável de prompts, código, índices e configurações;
• digests para modelos, containers, datasets e artefatos;
• model registry com histórico de aliases e aprovações;
• rastreamento entre experimento, modelo, deployment e endpoint;
• trace IDs propagados até as ferramentas e sistemas de destino;
• registro de documentos RAG por identificador e versão;
• contas técnicas distintas, privilégios mínimos e credenciais de curta duração;
• aprovação humana para ações de maior impacto;
• retenção compatível entre aplicação, gateway, cluster e serviços conectados;
• repositório protegido para conteúdo sensível necessário à investigação;
• sincronização de tempo e documentação de precisão;
• snapshots e procedimento de preservação emergencial;
• testes de restauração e validação das exportações.

O NIST SP 800-218A amplia práticas de desenvolvimento seguro para modelos generativos e de uso dual ao longo do ciclo de vida. A ISO/IEC 42001:2023, por sua vez, especifica requisitos para estabelecer e melhorar um sistema de gestão de IA. Embora esses referenciais não sejam manuais de perícia, seus controles de inventário, responsabilidade, documentação e ciclo de vida podem elevar a qualidade dos vestígios disponíveis.

Estrutura do relatório técnico

Um relatório de investigação em IA deve conter:

1. questões técnicas e limites do exame;
2. descrição arquitetural e fluxo de dados;
3. fontes, métodos de aquisição e cadeia de custódia;
4. inventário e hashes dos artefatos;
5. versões de datasets, código, modelos, prompts e índices;
6. cronologia normalizada;
7. resolução de identidades humanas e técnicas;
8. reconstrução de treinamento, implantação e inferência;
9. análise de chamadas e efeitos em sistemas externos;
10. testes, quantidade de repetições e variabilidade;
11. hipóteses alternativas;
12. limitações de retenção, acesso e reprodutibilidade;
13. conclusões graduadas;
14. anexos com traces, tabelas, scripts e parâmetros.

Scripts utilizados para extrair logs, comparar datasets ou reproduzir chamadas devem ser preservados com dependências e parâmetros. Quando o exame envolver conteúdo sensível, o relatório pode referenciar anexos segregados por hash e identificador, evitando reproduzir desnecessariamente o material no corpo principal.

Conclusão

A perícia em sistemas de inteligência artificial exige reconstruir muito mais do que uma conversa. Dados, treinamento, pesos, adaptadores, prompts, recuperação, memória, filtros, agentes, ferramentas e infraestrutura formam uma cadeia dinâmica na qual cada camada pode alterar o resultado.

A investigação tecnicamente defensável começa pela arquitetura, preserva estados voláteis, identifica versões efetivas e correlaciona traces com os sistemas que receberam as ações. Ela reconhece a variabilidade dos modelos, evita atribuir ao treinamento aquilo que pode ter vindo do RAG e distingue uma ferramenta sugerida de uma operação realmente executada.

Quando há linhagem de dados, versionamento de modelos, telemetria contextual e identidades técnicas bem definidas, torna-se possível explicar como determinado comportamento emergiu e qual suporte os vestígios oferecem às hipóteses investigadas. Quando essas condições não existem, as lacunas também precisam integrar a conclusão — pois a ausência de rastreabilidade é, por si, uma limitação técnica relevante para decisões corporativas posteriores.

Referências técnicas

• NIST — Artificial Intelligence Risk Management Framework 1.0: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
• NIST — Generative Artificial Intelligence Profile: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
• NIST AI 100-2e2025 — Adversarial Machine Learning: https://csrc.nist.gov/pubs/ai/100/2/e2025/final
• NIST SP 800-218A — Secure Software Development Practices for Generative AI: https://csrc.nist.gov/pubs/sp/800/218/a/final
• MITRE ATLAS: https://atlas.mitre.org/
• ISO/IEC 42001:2023 — AI Management Systems: https://www.iso.org/standard/42001
• MLflow — Model Registry: https://mlflow.org/docs/latest/ml/model-registry
• MLflow — Experiment Tracking: https://mlflow.org/docs/latest/ml/tracking/
• OpenTelemetry — Generative AI attributes: https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/
• Kubernetes — Auditing: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
• OWASP — Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• OWASP — Excessive Agency: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
• SWGDE — Digital Evidence from Cloud Service Providers: https://www.swgde.org/documents/published-complete-listing/23-f-004-best-practices-for-digital-evidence-acquisition-preservation-and-analysis-from-cloud-service-providers/