Auditorias e Documentação

Visão geral: o que “auditorias e documentação” significam em IA

Em governança de IA, auditorias são avaliações estruturadas para verificar se um sistema de IA atende a requisitos definidos (legais, contratuais, de políticas, de segurança, de proteção, de justiça/eqüidade, ou de qualidade). Documentação é o conjunto de artefatos que torna essas avaliações possíveis: ela registra o que foi construído, por que, como, com quais dados, como foi testado e como é monitorado e alterado ao longo do tempo.

“Prontidão para auditoria” é a capacidade operacional de responder a perguntas como:

• Que problema este modelo resolve, e o que ele explicitamente não resolve?
• Quais dados foram usados, sob quais direitos/consentimentos, com qual pré-processamento?
• Como o modelo foi treinado, avaliado e aprovado para lançamento?
• Quais são as limitações, riscos, mitigações e risco residual conhecidos?
• O que acontece quando o sistema falha, sofre deriva ou é abusado?
• Quem pode alterar o modelo, os prompts ou as políticas, e como as mudanças são revisadas e registradas?

Este artigo foca em cartões de modelo (model cards), práticas de documentação e prontidão para auditoria, e como elas se encaixam em programas de IA Responsável sob Governança, Risco e Conformidade (GRC).

Aprofundamentos relacionados: Cartões de Modelo, Cartões de Sistema, Avaliações de Risco, Relato de Incidentes e Transparência, Política de Conteúdo e Moderação e Estrutura de Gestão de Riscos de IA do NIST (NIST AI Risk Management Framework).

Por que a documentação é um controle de governança (não papelada)

Às vezes, a documentação é tratada como um “entregável” no fim de um projeto. Para fins de auditabilidade, ela deve ser tratada como um controle de engenharia que viabiliza:

• Responsabilização: responsáveis claros, aprovadores e registros de decisões.
• Rastreabilidade: capacidade de vincular um modelo implantado ao código, aos dados, às avaliações e às aprovações.
• Reprodutibilidade: capacidade de reproduzir o treinamento/avaliação (ou explicar por que a reprodução exata é impossível).
• Gestão de riscos: identificação e mitigação explícitas de danos e modos de falha.
• Transparência: comunicação precisa para partes interessadas internas, clientes e reguladores.
• Segurança operacional: monitoramento bem definido, resposta a incidentes, rollback e procedimentos de descontinuação.

Um bom modelo mental: a documentação é evidência estruturada de que seu ciclo de vida de IA é controlado, e não ad hoc.

O que auditorias procuram: critérios, evidências e escopo

Uma auditoria de IA normalmente tem três ingredientes:

1. Critérios (as “regras”): leis, padrões, políticas internas, compromissos contratuais ou estruturas.
   • Exemplos: política interna de IA, SDLC seguro (secure SDLC), política de privacidade, gestão de risco de modelo, Estrutura de Gestão de Riscos de IA do NIST, regras setoriais (saúde, finanças) ou regulamentação emergente (por exemplo, obrigações do EU AI Act para certos sistemas).
2. Escopo (a “coisa”): um modelo, um sistema, um processo de negócio ou um produto ponta a ponta.
3. Evidência (a “prova”): documentação, logs, tickets, relatórios de avaliação, histórico de mudanças, controles de acesso, painéis de monitoramento e registros de incidentes.

Tipos comuns de auditoria na prática:

• Auditorias internas (equipes de risco/conformidade validam aderência a controles internos)
• Auditorias externas (terceira parte independente)
• Due diligence de cliente/fornecedor (compradores corporativos solicitam evidências)
• Inquéritos regulatórios (comprovar conformidade com a lei)
• Auditorias de segurança/privacidade (foco em controle de acesso, tratamento de dados e resposta a incidentes)

Boa documentação reduz a “dor” da auditoria ao tornar a recuperação de evidências rotineira, e não heroica.

Artefatos centrais de documentação (o que produzir)

Um programa de IA maduro geralmente mantém um pequeno conjunto de artefatos padronizados. Os nomes variam, mas a intenção é consistente.

Documentação no nível do modelo (o “modelo como ativo”)

• Cartão de modelo: finalidade, usuários pretendidos, uso fora de escopo, resumo dos dados de treinamento, avaliação, limitações, considerações éticas e orientação operacional. Veja Cartões de Modelo.
• Relatório de avaliação: métricas completas, análise por recortes (slice analysis), verificações de robustez, calibração (quando aplicável) e comparação com baselines.
• Registro de treinamento: versão do código de treinamento, hiperparâmetros, ambiente de computação, sementes aleatórias (quando viável) e quaisquer notas sobre o processo de rotulagem humana.
• Resumo e proveniência dos dados: fontes de dados, datas de coleta, base de licenciamento/consentimento, pré-processamento e retenção.
• Avaliação de risco: danos, probabilidade/impacto, mitigações, risco residual e aprovações (sign-offs). Veja Avaliações de Risco.

Documentação no nível do sistema (o “modelo em contexto”)

A maioria dos incidentes reais acontece na fronteira do sistema (UX, prompts, recuperação, políticas, integrações), não dentro dos pesos. A documentação do sistema deve incluir:

• Cartão de sistema: arquitetura, jornadas do usuário, mitigações de segurança e restrições operacionais. Veja Cartões de Sistema.
• Modelo de ameaças: casos de abuso, comportamento adversarial, injeção de prompt (prompt injection), exfiltração de dados, riscos de inversão de modelo (model inversion) etc.
• Política de conteúdo (para sistemas generativos): o que é permitido/proibido, abordagem de enforcement e recursos/contestação. Veja Política de Conteúdo e Moderação.
• Runbooks operacionais: como responder a incidentes, fazer rollback, desativar funcionalidades e comunicar mudanças. Veja Relato de Incidentes e Transparência.

Documentação de processo (o “como trabalhamos”)

Auditores frequentemente se importam tanto com processos repetíveis quanto com o desempenho de um modelo individual:

• Fluxo de aprovação: quem revisa o quê, gates obrigatórios e segregação de funções.
• Gestão de mudanças: como prompts/modelos/pipelines de dados são atualizados, testados e lançados.
• Política de controle de acesso: quem pode acessar dados de treinamento, ferramentas de rotulagem, segredos, logs de produção e chaves de implantação.
• Política de monitoramento: o que é monitorado (qualidade, segurança, deriva), limiares e caminhos de escalonamento.
• Gestão de fornecedores: se usar modelos/APIs de terceiros, qual due diligence e quais controles contratuais se aplicam.

Cartões de modelo: como é “bom” em termos de auditoria

Um cartão de modelo é mais útil quando ele é:

• Específico (nomeia a versão exata do modelo e o contexto de implantação)
• Mensurável (reporta métricas, limiares e intervalos de confiança quando relevante)
• Honesto sobre limitações (modos de falha conhecidos, incerteza e lacunas)
• Operacional (como usá-lo com segurança, monitorá-lo e quando não usá-lo)
• Versionado e vinculado a evidências (links para execuções de avaliação, conjuntos de dados e aprovações)

Um esqueleto mínimo de cartão de modelo, amigável a auditoria (YAML), poderia ser assim:

model:
  name: "credit-risk-xgb"
  version: "2.3.1"
  owner: "Risk Modeling Team"
  last_updated: "2026-01-03"
  status: "production"

intended_use:
  primary_use: "Assist loan underwriting decisions"
  users: ["Underwriters", "Automated decision service (with human override)"]
  out_of_scope: ["Non-consensual profiling", "Use outside approved geographies"]

data:
  training_sources:
    - name: "Applications 2022-2025"
      lawful_basis: "contract"
      retention: "7 years"
  sensitive_attributes:
    collected: ["age_group"]
    not_collected: ["race", "religion"]
  preprocessing: ["missing value imputation", "winsorization", "one-hot encoding"]

evaluation:
  overall_metrics:
    auc: 0.83
    brier_score: 0.14
  fairness_slices:
    by_age_group:
      disparity_metric: "equal opportunity difference"
      value: 0.03
  robustness:
    drift_tests: ["PSI < 0.2 on key features"]
  limitations:
    - "Performance degrades for thin-file applicants"
    - "Not validated for self-employed applicants"

risk_and_controls:
  key_risks: ["proxy discrimination", "feedback loops"]
  mitigations: ["fairness constraints", "human review for borderline cases"]
  residual_risk: "medium"

operations:
  monitoring: ["weekly calibration check", "monthly fairness audit"]
  rollback_plan: "revert to 2.2.0 within 30 minutes"
  contact: "oncall-risk@company.example"

Isso não substitui documentos mais profundos (relatório de avaliação, linhagem de dados), mas fornece um ponto único de entrada que um auditor ou revisor pode usar para navegar pelas evidências.

Prontidão para auditoria ao longo do ciclo de vida de IA

A prontidão para auditoria é mais fácil quando é incorporada a cada fase do ciclo de vida.

1) Delimitação do problema e requisitos

Capture:

• Uso pretendido e não-objetivos
• Partes interessadas impactadas
• Classificação de risco por nível (por exemplo, decisões de alto impacto)
• Critérios de aceitação (desempenho, justiça/eqüidade, segurança, latência)
• Requisitos de supervisão humana (quando humanos devem revisar/substituir)

Dica prática: trate isso como requisitos testáveis, e não como declarações aspiracionais.

2) Aquisição de dados e governança

Evidências que auditores frequentemente solicitam:

• Inventário de dados: fontes, responsáveis, esquemas
• Base de consentimento/licenciamento e restrições (especialmente para dados de terceiros)
• Justificativa de minimização de dados
• Política de retenção e exclusão
• Proveniência/linhagem: como dados brutos viram dados de treinamento

Se você opera no Brasil ou lida com titulares de dados brasileiros, considerações práticas da LGPD (base legal, limitação de finalidade, atendimento de direitos) devem ser capturadas e mapeadas para controles; veja LGPD (Brasil) para Sistemas de IA.

3) Treinamento e experimentação

Práticas de treinamento prontas para auditoria incluem:

• Código e configurações com controle de versão
• Rastreamento de experimentos (quem executou o quê, com quais parâmetros)
• Versionamento de conjuntos de dados (hashes, snapshots, partições)
• Ambientes reprodutíveis (imagens de contêiner, travas de dependências)
• Diretrizes de rotulagem documentadas e QA se usar rótulos humanos

Um “registro de execução de treinamento” leve pode ser registrado automaticamente:

# Pseudocode: log training metadata to an experiment tracker / metadata store
run = start_run(project="fraud-model")
run.log_params({
  "model_type": "lightgbm",
  "num_leaves": 64,
  "learning_rate": 0.05,
  "seed": 1337
})
run.log_artifact("training_code_git_sha", get_git_sha())
run.log_artifact("train_dataset_hash", sha256_file("train.parquet"))
run.log_metrics({"auc_valid": 0.921, "fpr@tpr=0.95": 0.08})
run.end()

O objetivo não é “reprodutibilidade perfeita” em todos os casos, mas rastreabilidade defensável.

4) Avaliação, validação e decisões de lançamento

Evidências fortes incluem:

• Avaliação em dados representativos (e lacunas explícitas)
• Métricas baseadas em recortes (por região, classe de dispositivo, idioma, proxies demográficos quando lícito e apropriado)
• Testes de robustez (ruído, mudanças de distribuição, entradas adversariais)
• Testes de segurança para sistemas generativos (red teaming baseado em políticas)
• Um checklist de lançamento assinado por papéis responsáveis

Para IA generativa, a avaliação frequentemente inclui análise qualitativa e testes de conformidade com políticas; isso deve se conectar diretamente à sua abordagem de Política de Conteúdo e Moderação.

5) Implantação e operações

Prontidão operacional para auditoria requer:

• Entradas no registro de modelos (model registry) (qual versão está implantada e onde)
• Infraestrutura como código (infrastructure-as-code) e logs de implantação
• Painéis de monitoramento e histórico de alertas
• Documentação de testes A/B (se usados)
• Logs de incidentes, postmortems e comunicações aos usuários; veja Relato de Incidentes e Transparência

Um esquema simples e auditável de log de inferência (tenha cuidado com privacidade) pode capturar:

-- Example fields for an inference event log (avoid logging sensitive raw inputs)
CREATE TABLE inference_events (
  event_time TIMESTAMP,
  request_id STRING,
  user_segment STRING,
  model_name STRING,
  model_version STRING,
  policy_version STRING,
  prompt_template_version STRING,
  features_hash STRING,
  output_class STRING,
  output_score FLOAT,
  decision STRING,
  latency_ms INT,
  safety_action STRING,         -- e.g., "blocked", "allowed", "human_review"
  explanation_id STRING         -- pointer to stored explanation, if applicable
);

Princípio-chave: registre o suficiente para investigar e auditar decisões sem coletar dados pessoais desnecessários.

6) Gestão de mudanças e aposentadoria

Auditorias frequentemente revelam controles fracos em torno de mudanças “pequenas”, como:

• Edições de prompt
• Mudanças de limiar de política de segurança
• Atualizações de índice de recuperação
• Ajustes de engenharia de atributos
• Ajuste fino (fine-tuning) em novos dados

Trate essas mudanças como lançamentos de primeira classe, com:

• Versionamento
• Revisão/aprovação
• Reavaliação direcionada
• Capacidade de rollback
• Plano de descontinuação e arquivamento da documentação final

Mapeando documentação para frameworks de risco e controles

Estruturas como a Estrutura de Gestão de Riscos de IA do NIST são úteis porque incentivam um mapeamento consistente entre:

• Riscos (o que pode dar errado)
• Controles (o que você faz para prevenir/detectar/responder)
• Evidências (o que prova que o controle existe e é eficaz)

Um exemplo prático de mapeamento:

• Risco: resultados danosos ou enviesados em um domínio de alto impacto

  • Controle: avaliação de justiça/eqüidade pré-lançamento + monitoramento periódico de justiça/eqüidade
  • Evidência: relatório de avaliação + painéis de monitoramento + notas de reuniões de revisão + seção do cartão de modelo sobre justiça/eqüidade

• Risco: violações de direitos sobre dados

  • Controle: inventário de dados + documentação da base legal + enforcement de retenção
  • Evidência: entradas no catálogo de dados + logs de jobs de retenção + notas de DPIA/avaliação de impacto (quando aplicável)

• Risco: injeção de prompt / jailbreaks (para sistemas de LLM)

  • Controle: filtragem de entrada, hierarquia de instruções, restrições de acesso a ferramentas, testes de red team
  • Evidência: modelo de ameaças + resultados de red team + cartão de sistema + simulações de incidentes

Exemplo prático 1: documentação pronta para auditoria para um assistente de suporte ao cliente com LLM

Cenário: Uma empresa implanta um assistente baseado em LLM que responde FAQs, elabora respostas e pode acionar ações (reembolso, alterações de conta) via ferramentas.

Conjunto de documentação relevante para auditoria:

• Cartão de sistema: arquitetura (LLM + recuperação + ferramentas), papéis de usuário e limites de segurança (Cartões de Sistema)
• Política de conteúdo: conteúdo proibido (autoagressão, ódio, conteúdo sexual, aconselhamento regulado), estilo de recusa, escalonamento para humano (Política de Conteúdo e Moderação)
• Análise de risco de ferramental: quais ferramentas existem, quais permissões, como o agente é restringido
• Pacote de avaliação:
  • Testes de acurácia de recuperação (groundedness)
  • Taxa de alucinação em intenções-chave
  • Suíte de red team de segurança (injeção de prompt, exfiltração de dados)
  • Verificações de desempenho multilíngue, se relevante
• Plano operacional:
  • Monitoramento (taxas de recusa, taxas de escalonamento, reclamações de usuários)
  • Fluxo de resposta a incidentes (Relato de Incidentes e Transparência)
  • Gestão de mudanças para templates de prompt e versões de política

O que auditores costumam perguntar:

• Como você impede que o assistente vaze dados pessoais?
• O que acontece quando o modelo está incerto ou quando o usuário solicita orientação proibida?
• Como chamadas de ferramentas são autorizadas e registradas?
• Como você garante que a documentação continue atual conforme os prompts mudam?

Uma resposta robusta inclui templates de prompt versionados, versionamento de políticas, listas de permissão de ferramentas (allowlists) e logs estruturados que vinculam cada resposta a uma versão de modelo/política/prompt.

Exemplo prático 2: documentação pronta para auditoria para um modelo de decisão de crédito

Cenário: Um modelo de gradiente impulsionado (gradient-boosted) prevê risco de inadimplência para apoiar a análise de crédito.

Artefatos-chave:

• Cartão de modelo com uso pretendido e limitações claros (Cartões de Modelo)
• Proveniência dos dados: quais dados do solicitante são usados, como são obtidos, regras de retenção
• Análise de justiça/eqüidade:
  • Quais atributos são usados (e por quê)
  • Quais atributos sensíveis são medidos (se lícito/disponível)
  • Discussão de risco de proxy (CEP, histórico de emprego)
• Relatório de validação:
  • Calibração e estabilidade ao longo do tempo
  • Testes de estresse sob mudanças macroeconômicas
  • Plano de monitoramento de deriva e degradação de desempenho
• Aprovações de governança:
  • Aprovação do comitê de risco de modelo
  • Limiares documentados para quando a revisão humana é obrigatória
• Monitoramento pós-implantação:
  • Desempenho por segmento
  • Taxas de override
  • Taxas de reclamações e tratamento de disputas

Aqui também é onde uma prática estruturada de Avaliações de Risco é essencial: a expectativa de auditoria não é “risco zero”, mas propriedade explícita do risco e mitigação.

Documentação “como código”: mantendo artefatos atualizados

A documentação falha em auditorias quando está desatualizada, inconsistente ou desconectada da realidade implantada. Equipes fortes tratam documentação como software:

• Armazenar templates em controle de versão
• Exigir atualizações via pull requests
• Vincular documentos a entradas do registro de modelos
• Gerar partes automaticamente (métricas, hashes de conjuntos de dados, detalhes de ambiente)
• Usar verificações em CI para impor completude

Exemplo: uma verificação simples de CI que bloqueia a implantação se campos obrigatórios estiverem ausentes:

# Pseudocode: fail build if model card lacks required sections
python check_model_card.py model_card.yaml \
  --require model.name \
  --require model.version \
  --require intended_use.primary_use \
  --require evaluation.overall_metrics \
  --require operations.monitoring

O objetivo é tornar “fazer a coisa certa” o fluxo de trabalho padrão.

Achados comuns em auditorias (e como preveni-los)

Cartões de modelo desatualizados ou genéricos

Sintoma: o cartão de modelo parece um template; as métricas não correspondem à versão implantada.
Correção: vincular cartões de modelo a artefatos de lançamento (IDs de versão no registro de modelos) e exigir atualizações durante o gate de lançamento.

Sem linhagem entre dados, código e modelo implantado

Sintoma: não consegue responder “quais dados treinaram esta versão?”
Correção: versionamento de conjuntos de dados, rastreamento de experimentos e um registro que armazena referências a conjuntos de dados de treinamento e SHAs de código.

Mudanças informais de prompt e política em produção (IA Gen)

Sintoma: edições de prompt feitas diretamente em um console; sem trilha de revisão.
Correção: tratar prompts/políticas como configuração versionada com aprovações e registro automático de “prompt_template_version”.

Evidência operacional ausente

Sintoma: monitoramento existe, mas não é documentado; alertas não são revisados.
Correção: documentar responsabilidade do monitoramento, limiares e manter logs de revisão de alertas e runbooks de incidentes.

Lacunas de privacidade e retenção em logs

Sintoma: logs contêm entradas brutas do usuário ou dados sensíveis sem justificativa.
Correção: minimizar conteúdo registrado, aplicar hash/tokenização quando possível, definir retenção e documentar a justificativa e salvaguardas (especialmente relevante sob LGPD (Brasil) para Sistemas de IA).

Checklist de prontidão para auditoria (prático)

Use isto como uma revisão interna leve de pré-auditoria.

• Inventário e escopo
  • Lista de sistemas de IA implantados e versões de modelos (responsável, finalidade, status)
  • Limites claros: o que é o “sistema” vs. dependências externas
• Documentação do modelo
  • Cartão de modelo completo, específico e versionado
  • Relatório de avaliação com métricas por recortes e limitações
  • Registro de treinamento: versão do código, versão do conjunto de dados, ambiente
• Documentação do sistema
  • Cartão de sistema inclui arquitetura, mitigações e condições de operação
  • Modelo de ameaças e casos de abuso considerados
  • Política de conteúdo e fluxo de moderação (para sistemas generativos)
• Risco e governança
  • Avaliação de risco com mitigações e aceitação de risco residual
  • Aprovadores nomeados e logs de decisão para lançamento
• Operações
  • Monitoramento, alertas e detecção de deriva definidos e com responsáveis
  • Playbooks de resposta a incidentes e plano de transparência
  • Gestão de mudanças para modelos, prompts, políticas e pipelines de dados
• Privacidade e segurança
  • Controles de acesso para dados, modelos e logs
  • Logging minimizado para privacidade com regras de retenção
  • Dependências de fornecedores documentadas e avaliadas

Como este artigo se encaixa com o restante da documentação de GRC

• Se você precisa do “o que entra no cartão de modelo”, comece com Cartões de Modelo.
• Se você está documentando um produto ponta a ponta (LLM + recuperação + UI + políticas), use Cartões de Sistema.
• Se você está formalizando identificação de riscos e mitigações, use Avaliações de Risco.
• Se você precisa planejar divulgação, postmortems e comunicação com stakeholders, veja Relato de Incidentes e Transparência.
• Se você está operando um sistema generativo com saídas voltadas ao usuário, veja Política de Conteúdo e Moderação.
• Se você quer uma estrutura orientada a controles para estruturar seu programa, veja Estrutura de Gestão de Riscos de IA do NIST.

Principal conclusão

A prontidão para auditoria não é alcançada ao produzir um único documento pouco antes da revisão. Ela é alcançada ao projetar o ciclo de vida de IA de modo que evidências sejam produzidas naturalmente: cada modelo/versão tem linhagem rastreável, cada lançamento tem avaliações e aprovações registradas, cada sistema tem políticas e mitigações documentadas, e as operações geram continuamente logs e registros de incidentes que demonstram a eficácia dos controles.

---