Model cards de IA: como documentar sistemas na empresa

Um model card é um documento curto e padronizado que descreve um modelo de IA: para que ele serve, com quais dados foi treinado e avaliado, como se comporta, onde falha e quem responde por ele. Funciona como a bula do modelo. Na empresa, o model card (ou sua versão para sistemas inteiros, o system card) é o que transforma uma ferramenta de IA em algo auditável: sem ele, ninguém consegue provar para o comitê, para o auditor ou para o regulador o que o sistema deveria fazer. Este guia mostra os campos que importam, como adaptar o formato para três realidades corporativas (fornecedor, modelo próprio e agente) e como manter o documento vivo.

O que é um model card e para que serve na empresa

Um model card registra, em uma a duas páginas, a identidade e o comportamento esperado de um modelo de IA. A pergunta que ele responde é simples: "o que esse sistema promete fazer, e com que evidência?"

Na prática, o documento cumpre quatro funções de governança:

1. Linha de base para auditoria. A auditoria de IA precisa de algo contra o qual testar. O model card é a promessa; o teste verifica se ela se sustenta.
2. Insumo para a classificação de risco. Usos previstos, usos fora do escopo e limitações conhecidas alimentam a avaliação de impacto algorítmico.
3. Transferência de conhecimento. Quando o dono do sistema muda de área ou sai da empresa, o documento preserva o contexto de decisão.
4. Responsabilização. Todo model card tem dono e contato nomeados. Isso liga o sistema a uma pessoa, não a um departamento.

O que o model card não é: não substitui teste, monitoramento nem supervisão humana. Ele é o veículo da informação de que essas atividades dependem. Um documento bonito sobre um modelo que ninguém testa é só ornamento.

De onde vem o formato: o artigo de 2019 e as nove seções

O conceito foi proposto no artigo "Model Cards for Model Reporting", de Margaret Mitchell e coautores, apresentado em 2019. A ideia era importar para a IA o que outras indústrias já faziam: acompanhar todo componente com uma ficha de desempenho e condições de uso. Hoje, plataformas como a Hugging Face adotam o model card como o arquivo README.md de cada repositório de modelo, com metadados estruturados (licença, datasets, tarefa) mais texto descritivo.

A literatura de governança costuma resumir o formato em nove seções, conforme a síntese do Snowflake:

#	Seção	O que registra
1	Detalhes do modelo	Nome, versão, data, tipo, licença, responsável e contato
2	Uso pretendido	Finalidade, público-alvo e usos fora do escopo
3	Fatores	Condições que afetam o desempenho: idioma, região, tipo de entrada
4	Métricas	Como o desempenho é medido e quais limiares valem
5	Dados de avaliação	Com que dados o modelo foi testado
6	Dados de treinamento	Origem, pré-processamento e limitações
7	Análises quantitativas	Desempenho desagregado por grupo e por fator
8	Considerações éticas	Usos sensíveis, danos possíveis, vieses e mitigações
9	Ressalvas e recomendações	Limitações, monitoramento, supervisão humana e testes antes do uso

Duas seções merecem atenção especial porque são as que mais faltam nos documentos corporativos improvisados. A desagregação por grupo (seção 7) existe porque uma acurácia média pode esconder um desempenho muito pior para um subconjunto de casos; o tema é desenvolvido em viés algorítmico em IA. E os usos fora do escopo (seção 2) são o campo que mais evita incidentes: dizer explicitamente "este assistente não deve ser usado para decisão de crédito" vale mais do que três parágrafos de descrição.

Model card, system card e ficha interna: três níveis de documentação

O formato original foi pensado para quem treina o modelo. A maioria das empresas brasileiras não treina; contrata, configura e integra. Por isso, vale distinguir três níveis:

Nível	Quem é o autor	Exemplo	O que a empresa faz
Model card do fornecedor	Provedor do modelo	Documentação pública de um modelo de linguagem	Coleta, arquiva e lê criticamente
System card (ficha do sistema)	Time da empresa ou fornecedor do produto	Assistente de atendimento que combina modelo, base de conhecimento e regras	Escreve ou exige, descrevendo o sistema inteiro
Ficha de uso interno	Dono do caso de uso	Uso de um copiloto pelo jurídico para resumir contratos	Escreve, com escopo, dados permitidos e revisão humana

O termo system card circula, por exemplo, em um texto da Red Hat sobre AI system cards. A razão prática para ele existir é que o risco de um sistema de IA não está só no modelo: está no prompt, nos dados conectados, nas permissões e nas ferramentas que ele pode acionar. Um modelo seguro dentro de um sistema mal configurado continua sendo um sistema inseguro. Essa é a razão pela qual, para agentes de IA autônomos, a unidade de documentação deve ser o sistema, e não o modelo.

O model card do fornecedor é necessário, mas insuficiente. Ele descreve o modelo em condições de laboratório; só o system card descreve o que a sua empresa colocou em volta dele.

Os campos de um model card corporativo (modelo mínimo)

Para uma empresa que ainda não tem nenhum documento desse tipo, o modelo abaixo cabe em uma página e cobre o essencial. Cada campo existe por um motivo de governança:

1. Identificação: nome do sistema, versão, data da última revisão, fornecedor ou time construtor, ID no inventário de sistemas de IA.
2. Dono e contato: uma pessoa nomeada (não um departamento) e um substituto.
3. Finalidade: o problema de negócio resolvido, em uma frase.
4. Usos proibidos ou fora do escopo: lista explícita.
5. Dados: quais categorias de dado o sistema acessa, incluindo dados pessoais; origem dos dados de treinamento ou da base de conhecimento, quando conhecida.
6. Nível de autonomia: o sistema sugere, decide com aprovação humana ou age sozinho?
7. Como foi avaliado: conjunto de teste, métricas e resultado, com data. É aqui que entram os evals corporativos.
8. Limitações e falhas conhecidas: alucinação, idioma, tipos de documento em que o desempenho cai.
9. Controles em vigor: supervisão humana, filtros, registros de uso, limites de acesso.
10. Gatilhos de revisão: o que obriga a reabrir o documento (troca de versão do modelo, novo conjunto de dados, mudança de uso, incidente).

Um bom teste de qualidade: alguém de fora da área consegue, lendo só a ficha, decidir se o sistema pode ser usado em um caso novo? Se a resposta é "depende, pergunte ao João", o documento falhou.

Quem preenche, quem revisa e quando o documento muda

Model card que depende de uma pessoa lembrar de atualizar vira ficção em poucos meses. Três regras sustentam o ciclo:

• Quem usa preenche; quem governa revisa. O dono do caso de uso escreve a ficha porque é quem conhece a finalidade e os limites reais. O time de governança (ou o comitê) revisa consistência e risco, sem reescrever.
• A ficha é pré-requisito de liberação. Sistema sem ficha não entra em produção nem no inventário como "aprovado". Isso alinha a documentação à política de uso de IA, em vez de deixá-la como boa prática opcional.
• Gatilhos objetivos de revisão. Um card reflete o comportamento do modelo no momento em que foi escrito. Atualizações do fornecedor, novas fontes de dados ou uma mudança de uso podem alterar o comportamento sem que o documento perceba. Por isso o campo 10 acima não é burocracia: é o que faz o documento acompanhar o sistema.

Para fornecedores, a ficha entra na diligência de contratação: peça o model card (ou equivalente) como anexo e trate a recusa em fornecê-lo como informação sobre o risco, conforme o processo descrito em gestão de risco de fornecedores de IA.

Model cards, regulação e normas: o que cada uma pede

Model cards não são, por si, obrigação legal. O que existe são regimes que exigem documentação técnica de sistemas de IA, e o model card é uma forma prática de organizá-la.

O exemplo mais detalhado é o Anexo IV do AI Act europeu, que lista o conteúdo mínimo da documentação técnica de sistemas de alto risco. Entre os itens: finalidade pretendida e versão, descrição do desenvolvimento (dados de treino, validação e teste, medidas de supervisão humana, procedimentos e métricas de teste), capacidades e limitações com níveis de precisão por grupo de pessoas, sistema de gestão de risco e plano de monitoramento pós-comercialização. A correspondência com as nove seções do model card é grande, mas o Anexo IV é mais extenso: ele exige, por exemplo, o sistema de gestão de risco descrito em detalhe e a declaração de conformidade. Para o que isso significa para quem opera no Brasil, veja AI Act europeu e empresas brasileiras.

No Brasil, o Marco Legal da IA (PL 2338) ainda tramita, e a documentação é um dos eixos do debate sobre sistemas de alto risco. Mesmo sem lei sancionada, a empresa que já mantém fichas por sistema chega mais preparada a qualquer cenário e, no curto prazo, responde melhor a perguntas de clientes, auditores e do jurídico. O mesmo vale para a adoção de normas de gestão como a ISO/IEC 42001: a documentação por sistema é evidência recorrente em qualquer processo de certificação.

Cuidado com a leitura oposta: ter um model card não prova conformidade. Ele organiza a evidência; a conformidade depende de o sistema realmente se comportar como o documento diz.

Erros comuns ao documentar sistemas de IA

• Documentar o modelo e esquecer o sistema. A ficha descreve o modelo do fornecedor, mas ignora o prompt de sistema, as integrações e as permissões que a empresa adicionou.
• Métrica única sem desagregação. "92% de acurácia" não informa em que tipo de caso o sistema erra.
• Texto de marketing em vez de limitação. A seção de limitações vazia ou genérica ("o modelo pode errar") não ajuda ninguém a decidir.
• Documento sem dono. Sem pessoa nomeada, a ficha envelhece e ninguém se sente responsável por corrigi-la.
• Ficha escrita uma vez. Sem gatilhos de revisão, ela descreve um sistema que já não existe.
• Exigir o formato completo de todo mundo. Um uso de baixo risco de um copiloto não precisa de dez páginas. Proporcione o nível de detalhe ao risco da classificação do sistema.

Como começar em 30 dias

Um roteiro realista para quem parte do zero:

1. Semana 1: escolha o modelo mínimo de ficha (use a lista de dez campos acima) e aprove-o com jurídico, segurança e TI.
2. Semana 2: documente os três a cinco sistemas de maior risco ou maior uso, a partir do inventário. Priorize os que tocam dado pessoal ou decisão sobre pessoas.
3. Semana 3: peça aos fornecedores desses sistemas o model card ou equivalente e arquive junto à ficha interna.
4. Semana 4: transforme a ficha em pré-requisito de liberação para sistemas novos e defina a cadência de revisão.

A Jetpacks aplica uma lógica parecida dentro do método Flight Plan: o estágio de diagnóstico (Launchpad) produz o mapa do que existe e do que está em uso; o acompanhamento (Mission Control) mantém as métricas e os registros vivos depois da capacitação. Documentação que não acompanha o uso é a primeira a se perder.

FAQ

O que é um model card de IA?

É um documento padronizado que descreve um modelo de IA: finalidade, dados, desempenho, limitações, usos fora do escopo e responsável. Foi proposto no artigo "Model Cards for Model Reporting", de 2019, e funciona como a bula do modelo.

Model card é obrigatório por lei?

Não existe obrigação específica de "model card" na legislação brasileira. O que existe são regimes, como o AI Act europeu para sistemas de alto risco, que exigem documentação técnica, e o model card é uma forma prática de organizá-la. Vale confirmar com o jurídico caso a caso.

Qual a diferença entre model card e system card?

O model card documenta o modelo isoladamente. O system card documenta o sistema inteiro: modelo, prompt, dados conectados, permissões e ferramentas. Para a maioria das empresas, que contratam e integram em vez de treinar, o system card é o documento mais útil.

O que um model card deve incluir?

Identificação e versão, dono e contato, finalidade, usos fora do escopo, dados, métricas e resultados de avaliação, limitações conhecidas, considerações éticas e recomendações de supervisão. A lista de dez campos deste guia é um ponto de partida para o contexto corporativo.

Quem deve preencher o model card na empresa?

O dono do caso de uso, porque conhece a finalidade e os limites reais. O time de governança ou o comitê de IA revisa a consistência e o risco, mas não deve escrever no lugar de quem usa o sistema.

Com que frequência o model card deve ser atualizado?

Sempre que um gatilho ocorrer: troca de versão do modelo, nova fonte de dados, mudança de uso ou incidente. Além disso, uma revisão periódica (por exemplo, semestral) para sistemas de risco mais alto.

Preciso de model card para ferramentas como ChatGPT ou Copilot?

Para ferramentas de mercado, você coleta o model card ou a documentação pública do fornecedor e escreve uma ficha de uso interno: quais dados podem entrar, para que tarefas e com qual revisão humana. A ficha de uso interno é o que o fornecedor não pode escrever por você.

Conclusão: documentar é o que torna a governança verificável

Política, comitê e inventário dizem o que a empresa quer fazer com IA. O model card diz, sistema por sistema, o que cada um promete e com que evidência. Sem esse registro, a governança depende de memória e de boa vontade. Com ele, auditar, contratar e responder a um incidente deixam de ser reconstruções improvisadas.

O ponto de partida é pequeno: uma ficha de uma página, um dono nomeado e um gatilho de revisão para os primeiros sistemas de maior risco. Para entender onde sua empresa está hoje e qual documentação priorizar, comece pelo diagnóstico gratuito da Jetpacks e leia o panorama completo em governança de IA na prática.