Governança de modelos de IA: model cards, versionamento e o que ANPD pode pedir

TL;DR Em 2026, ANPD e auditores setoriais (BACEN, SUSEP, ANS) começam a pedir documentação formal sobre modelos de IA usados em decisão automatizada. Model card, versionamento, baseline de avaliação e plano de revisão deixam de ser "boa prática" para virar requisito. Receita prática para projetos Gemini Enterprise.

Empresa que usa Gemini, GPT, Claude ou Llama em produção corporativa tem uma "frota de modelos" — cada um com versão, comportamento, viés e custo próprios. Sem governança, ninguém sabe qual versão está rodando onde, e auditoria vira pesadelo.

O que é model card (e por que importa)

Model card é a "ficha técnica" do modelo. Inventado pelo Google em 2019, virou padrão de fato. Para cada modelo em produção, documente:

Identificação: nome, versão exata, provedor, snapshot date.
Uso pretendido: caso de uso, perfil de usuário, decisão suportada.
Uso fora do escopo: o que não é caso de uso aceito.
Dados de treinamento: o que se sabe sobre origem (no caso de modelo proprietário, o que o provedor publica).
Métricas de avaliação: gold set interno, benchmarks, baseline.
Limitações conhecidas: idiomas, domínios, vieses identificados.
Mitigação: prompt, guardrails, hand-off humano.
Owner técnico: quem mantém.
Owner de negócio: quem responde por decisões.
Data de revisão: ciclo de reavaliação.

Em Gemini Enterprise, model card é por agente + por modelo subjacente — pode ser arquivo Markdown no repositório do projeto.

Versionamento explícito

Pin de versão é mandatório. "Gemini Pro" não é versão — é família. "Gemini 2.5 Pro snapshot 2026-04" é versão.

Práticas:

API call sempre com versão explícita do modelo.
Mudança de versão = PR + reavaliação contra gold set.
Rollback documentado.
Notificação para owner de negócio antes de promover nova versão.

Sem isso, Google atualiza snapshot, comportamento muda, métrica regride — e ninguém entende por quê.

Baseline e drift

Toda nova versão é comparada com baseline (versão atual em produção). Métricas:

Faithfulness, relevance, completeness, safety (ver avaliação de agentes em produção).
Latência p50/p95.
Custo por execução.
Taxa de hand-off humano.
Distribuição de tools chamadas.

Regressão de qualquer métrica em mais de 5% = bloqueio para produção até investigação.

O que ANPD e auditores estão pedindo (2026)

Padrão emergente em fiscalizações setoriais (BACEN, SUSEP, ANS e outros publicaram orientações convergentes):

Inventário de sistemas de IA usados em decisão automatizada — lista viva com owner, status, criticidade.

Model card por sistema — ficha técnica com versão, limitações, mitigações.

RIPD com matriz de riscos LLM-específicos (ver RIPD para projetos Gemini Enterprise).

Avaliação de viés trimestral por segmento sensível (gênero, raça, região, idade).

Audit log capaz de reconstruir decisão individual — entrada, contexto, resposta, tools chamadas.

Direito de revisão humana operante — canal com SLA, não apenas cláusula no contrato.

Plano de descomissionamento: como desligar o modelo sem ruptura operacional.

Avaliação de viés: como fazer sem teatro

Viés em LLM é real e mensurável. Como auditar:

Definir segmentos sensíveis relevantes ao caso (ex.: em crédito: região, idade, gênero declarado).
Construir amostra balanceada de casos por segmento.
Rodar agente sobre amostra, comparar outcome e tom entre segmentos.
Métrica: statistical parity difference, equal opportunity difference.
Reportar trimestralmente para diretoria + comitê de risco.
Ação corretiva quando diferença excede threshold (típico: 10%).

O caso da decisão automatizada (Art. 20 LGPD)

Se o agente toma decisão com efeitos jurídicos ou relevantes (crédito negado, contrato recusado, atendimento negado), titular tem direito de:

Saber que decisão foi automatizada.
Ter explicação dos critérios.
Solicitar revisão por pessoa natural.

Operacionalmente:

UX deixa claro: "esta análise inicial é automatizada".
Justificativa entregue na decisão (não apenas "negado").
Canal explícito de revisão com SLA definido.
Treinamento dos revisores humanos.

Comitê interno de IA

Em organizações de médio/grande porte, recomenda-se comitê com:

DPO.
Jurídico (compliance regulatório do setor).
Owner técnico de cada agente.
Representante de RH (impacto em trabalho).
Representante de negócio.
Reuniões mensais para revisar inventário, métricas de viés, incidentes.

Sem fórum, decisão sobre IA fica solta entre TI e negócio — quando estoura, ninguém é responsável.

Plano de descomissionamento

Mais ignorado de todos, mas essencial:

Como desligar o agente sem ruptura de operação?
Em quanto tempo a operação manual escala?
Quem decide o desligamento?
Quanto tempo de retenção dos logs após desligamento?

Documento de 2 páginas. Custa nada. Salva em incidente.

Stack mínimo para governança

Inventário: planilha viva ou Notion/Confluence com cada agente, modelo, owner, status.
Model cards: arquivo MD por agente no repositório.
Versionamento: pin de versão no código, PR para mudança.
Avaliação contínua: pipeline gold set + dashboard de métricas.
Audit log: BigQuery/Cloud Logging com retenção compatível.
RIPD atualizado anualmente ou em mudança material.
Comitê com ata pública.

⚠️ Art. 20 LGPD não é opcional Se o agente toma decisão com efeitos jurídicos ou relevantes (crédito, contrato, atendimento negado), titular tem direito explícito de revisão por pessoa natural, explicação dos critérios e ciência de que a decisão foi automatizada. "Negado" sem justificativa não passa. Treine os revisores humanos — eles precisam entender o agente para contestar.

Governança de modelo não é teatro jurídico. É o que separa "tínhamos controle" de "descobrimos junto com o titular reclamante" quando algo dá errado.

Kit Governança IA

3 semanas para estar pronto para auditoria

Inventário + model cards + RIPD + comitê estruturado + pipeline de métricas de viés. Entrega em 3 semanas, paralelo à implementação técnica, com treinamento do DPO e comitê.

Solicitar kit → RIPD Gemini Enterprise