Cartões de Modelo

O que são Cartões de Modelo?

Cartões de modelo (Model Cards) são documentos estruturados que descrevem o propósito, o uso pretendido, os resultados de avaliação, as limitações e os riscos de um modelo de aprendizado de máquina (machine learning, ML) — para que as pessoas possam tomar decisões informadas sobre se e como usá-lo. A ideia central é simples: um modelo não é apenas um artefato (pesos (weights) + código). Ele é uma capacidade com contexto, e seu comportamento depende de dados, condições de implantação e interações dos usuários.

O termo foi popularizado por “Model Cards for Model Reporting” (Mitchell et al., 2019). Hoje, cartões de modelo são uma prática comum de governança em aprendizado de máquina em produção (production ML), especialmente quando sistemas afetam pessoas ou operam em contextos sensíveis a segurança ou conformidade.

Cartões de modelo são mais úteis quando são:

  • Específicos (não linguagem genérica de marketing)
  • Baseados em evidências (incluem metodologia e resultados de avaliação)
  • Acionáveis (orientação clara para uso seguro, não apenas ressalvas)
  • Mantidos ao longo do tempo (versionados, atualizados após incidentes e mudanças)

Nesta taxonomia do wiki, cartões de modelo fazem parte da governança operacional e da prontidão para auditoria, estando intimamente relacionados a Avaliações de Risco (Risk Assessments), Cartões de Sistema (System Cards), Relato de Incidentes e Transparência (Incident Reporting & Transparency) e à Estrutura de Gestão de Risco de IA do NIST (NIST AI Risk Management Framework).

Por que Cartões de Modelo são importantes

Alinhando o comportamento do modelo com o uso no mundo real

Um modelo pode ter bom desempenho em métricas offline (offline metrics), mas falhar na prática devido a:

  • Mudanças nas distribuições de dados (data distributions) (novos usuários, novos idiomas, novos dispositivos)
  • Objetivos desalinhados (otimizar acurácia quando os custos são assimétricos)
  • Dependências ocultas (pré-processamento (preprocessing), limiares (thresholds), prompts (prompts), configuração de recuperação (retrieval configuration))
  • Efeitos de interação (ciclos de retroalimentação (feedback loops), rótulos seletivos (selective labels), comportamento adversarial (adversarial behavior))

Um cartão de modelo torna essas suposições explícitas e reduz os “desconhecidos desconhecidos” (“unknown unknowns”) para usuários downstream.

Viabilizando responsabilização e governança

Cartões de modelo apoiam:

  • Revisão interna (risco, jurídico, segurança, privacidade, ética)
  • Auditorias externas (reguladores, clientes, parceiros)
  • Passagens operacionais (de pesquisa para produto/operações de aprendizado de máquina)
  • Aprendizado pós-incidente (o que mudou, o que quebrou, o que corrigir)

Eles também podem fornecer evidências para programas de conformidade (por exemplo, mapeando controles para processos de gestão de risco, como a Estrutura de Gestão de Risco de IA do NIST).

Prevenindo uso indevido

Muitas falhas acontecem porque um modelo é aplicado fora do seu escopo pretendido. Declarações claras de “não usar” e limitações documentadas podem reduzir materialmente danos, especialmente em domínios sensíveis (saúde, emprego, educação, crédito, policiamento).

Cartões de Modelo vs. documentação relacionada

Cartões de modelo se situam entre uma família de artefatos de documentação:

  • Cartão de modelo: Documentação no nível do modelo (o que o modelo é, em que foi avaliado, onde funciona/não funciona).
  • Documentação de dados (frequentemente chamada de “fichas técnicas (datasheets)” ou “cartões de dados (data cards)”): Quais dados foram usados, de onde vieram, rotulagem, consentimento, representatividade, problemas conhecidos. (Veja também: Conjuntos de Dados se o seu wiki tiver; muitas organizações mantêm um “cartão de conjunto de dados” em paralelo.)
  • Cartão de sistema: Documentação do sistema ponta a ponta (end-to-end), incluindo experiência do usuário (UX), processos de humano no ciclo (human-in-the-loop), monitoramento e mitigações. Isso é essencial para produtos de IA generativa (generative AI), em que o sistema (prompts, recuperação, ferramentas, políticas) molda os resultados. Veja Cartões de Sistema.
  • Avaliação de risco / avaliação de impacto: Identificação estruturada de danos, partes interessadas afetadas e planos de mitigação. Veja Avaliações de Risco.
  • Documentação de incidentes: O que aconteceu, impacto no usuário, causa raiz, ações corretivas. Veja Relato de Incidentes e Transparência.
  • Documentação de políticas: Regras sobre o que o sistema deve ou não deve fazer (especialmente relevante para IA generativa). Veja Política de Conteúdo e Moderação (Content Policy & Moderation).

Uma regra prática: um cartão de modelo descreve o que o modelo faz; um cartão de sistema descreve o que seu produto faz com ele.

Quem usa Cartões de Modelo?

Um bom cartão de modelo é escrito para múltiplos públicos:

  • Engenheiros e pesquisadores de ML: arquitetura, regime de treinamento, detalhes de avaliação
  • Donos de produto: uso pretendido, limitações conhecidas, orientação de rollout
  • Risco/conformidade/jurídico: avisos de uso sensível, requisitos de monitoramento, evidências para auditoria
  • Operações / engenharia de confiabilidade de sites (site reliability engineering, SRE) / operações de aprendizado de máquina (MLOps, Machine Learning Operations): dependências, restrições em tempo de execução, sinais de monitoramento
  • Integradores downstream (downstream integrators): APIs, limiares, calibração, entradas suportadas
  • Partes interessadas externas (às vezes): relatórios de transparência, garantia ao cliente

Para atender a esses públicos, cartões de modelo devem evitar jargão quando possível, definir termos quando necessário e incluir detalhe técnico suficiente para reproduzir avaliações.

Seções centrais de um Cartão de Modelo (e como é o “bom”)

A seguir está uma estrutura prática que se adapta bem tanto a modelos tradicionais de ML quanto a modelos fundamentais modernos.

1) Visão geral do modelo

Inclua:

  • Nome do modelo e identificador único
  • Versão (versionamento semântico (semantic versioning) é comum: major.minor.patch)
  • Tipo de modelo (por exemplo, árvores com boosting de gradiente (gradient-boosted trees), rede neural convolucional (CNN), transformador (transformer))
  • Tarefa (classificação, ranqueamento, detecção, geração)
  • Entradas/saídas (esquema (schema) e restrições)
  • Dono/mantenedores e ponto de contato

Bons cartões de modelo também incluem uma descrição curta em linguagem simples, por exemplo: “prevê se um ticket de suporte é sobre cobrança para encaminhá-lo à fila de cobrança”.

2) Uso pretendido e usos fora de escopo

Esta costuma ser a seção mais importante.

  • Usuários primários pretendidos (agentes internos, usuários finais, clínicos, moderadores)
  • Contextos pretendidos (idiomas, geografias, tipos de dispositivo, canais)
  • Papel na decisão: assistivo vs. automatizado; revisão humana é obrigatória?
  • Fora de escopo: casos explícitos de “não usar”

Exemplo de declaração fora de escopo:

  • Não use este modelo para tomar decisões automatizadas de elegibilidade para emprego ou crédito. Ele não foi validado para esses cenários e pode incorporar viés histórico.

3) Dados de treinamento e proveniência (em alto nível)

Normalmente você não precisa publicar dados brutos, mas deve registrar:

  • Fontes de dados e período de coleta
  • Processo de rotulagem (quem rotulou, diretrizes, checagens de qualidade)
  • Lacunas conhecidas (grupos sub-representados, idiomas, casos de borda)
  • Restrições de licenciamento/consentimento (quando aplicável)
  • Retenção de dados e ponteiros de governança (links internos)

Esta seção ajuda a explicar por que um modelo se comporta como se comporta e dá suporte à avaliação de risco por equipes downstream.

4) Dados e metodologia de avaliação

Documente a avaliação com clareza suficiente para que outro profissional possa replicá-la:

  • Conjuntos de dados offline usados (e como diferem do treinamento)
  • Estratégia de divisão (aleatória, por tempo, por grupo)
  • Métricas e limiares
  • Intervalos de confiança ou estimativas de variância (quando viável)
  • Testes de estresse (stress tests): mudanças de distribuição (distribution shifts), entradas adversariais (adversarial inputs), ruído (noise), dados ausentes (missing data)
  • Protocolos de avaliação humana (human evaluation) (para tarefas generativas)

Para sistemas generativos ou interativos, considere incluir resultados de testes de equipe vermelha (red teaming) e testes de uso indevido (misuse testing) e, então, conectar mitigações no nível do sistema em um Cartões de Sistema.

5) Métricas de desempenho (gerais e por fatia)

Forneça:

  • Desempenho geral (por exemplo, acurácia, F1, ROC-AUC)
  • Desempenho por fatias (slices) em subgrupos ou condições relevantes:
    • Idioma, região, tipo de dispositivo
    • Demografia (quando coletada legalmente e apropriado)
    • Categorias de conteúdo (toxicidade, consultas médicas, gírias)
    • Classes raras / comportamento de cauda longa (long-tail)

É aqui que cartões de modelo frequentemente se cruzam com trabalho de equidade (fairness) (veja Equidade no Aprendizado de Máquina (Fairness in Machine Learning) se estiver disponível no seu wiki).

Uma prática-chave: relatar tanto a métrica quanto o limiar de decisão (decision threshold) usado na implantação (ou explicar por que o modelo não usa limiar, por exemplo, ranqueamento).

6) Limitações, modos de falha e ressalvas

Documente fraquezas conhecidas com exemplos concretos:

  • Padrões sistemáticos de erro (falsos positivos (false positives) em determinados dialetos)
  • Fragilidade (brittleness) (erros de reconhecimento óptico de caracteres (OCR), imagens com pouca luz)
  • Excesso de confiança (calibração (calibration) ruim)
  • Sensibilidade a prompts ou formatação (para classificadores baseados em modelos de linguagem de grande porte (large language models, LLMs))
  • Suscetibilidade a manipulação adversarial (adversarial manipulation)

Torne esta seção acionável: inclua estratégias de mitigação (regras de fallback, abstenção, revisão humana, alertas de monitoramento).

7) Considerações éticas, de segurança e de proteção

Dependendo do domínio, inclua:

  • Danos potenciais (por exemplo, impacto desigual, difamação, vazamento de privacidade (privacy leakage))
  • Cenários de abuso (spam, injeção de prompt (prompt injection), evasão (evasion))
  • Mitigações de segurança (comportamentos de recusa (refusal behaviors), barreiras de segurança (guardrails), limites de taxa (rate limits))
  • Postura de segurança (security posture) (risco de extração de modelo (model extraction), considerações sobre envenenamento de dados (data poisoning))

Esta seção frequentemente se beneficia do alinhamento com as Avaliações de Risco da sua organização.

8) Detalhes de implantação e plano de monitoramento

Um cartão de modelo deve ajudar operadores a executar o modelo com segurança:

  • Ambiente de execução (runtime environment) e dependências
  • Expectativas de latência (latency) e vazão (throughput)
  • Sinais de monitoramento (monitoring signals) (deriva de dados (data drift), deriva de calibração (calibration drift), taxas de erro por fatia)
  • Limiares de alerta e caminhos de escalonamento
  • Gatilhos e cadência de retreinamento
  • Procedimentos de reversão (rollback)

Este também é um bom lugar para declarar quando o cartão de modelo deve ser atualizado (por exemplo, ao retreinar, ao mudar um limiar, após um incidente).

9) Versionamento, registro de mudanças e aprovações

Inclua:

  • O que mudou vs. a versão anterior (dados, arquitetura, limiares)
  • Mudanças esperadas de comportamento (por exemplo, recall melhor, precisão pior)
  • Aprovações formais (sign-offs) de revisão (risco, privacidade, produto, conforme necessário)
  • Links para artefatos de avaliação (painéis (dashboards), relatórios, IDs de experimento (experiment IDs))

Isso torna o cartão de modelo útil para auditorias e para rastreabilidade de engenharia no dia a dia.

Um modelo “mínimo viável” prático de Cartão de Modelo

Muitas equipes falham por buscar perfeição. Uma boa abordagem é padronizar um modelo leve e evoluí-lo.

Aqui está um modelo compacto semelhante a YAML (YAML-like) que você pode adaptar:

model:
  name: "ticket-router-v2"
  version: "2.1.0"
  owner: "ml-platform@company.com"
  task: "multi-class text classification"
  inputs:
    - field: "subject"
      type: "string"
    - field: "body"
      type: "string"
  outputs:
    - field: "queue"
      type: "string"
    - field: "confidence"
      type: "float"

intended_use:
  in_scope:
    - "Routing inbound support tickets to the correct internal queue"
    - "Assistive suggestion to human agents"
  out_of_scope:
    - "Automated denial of service or account actions"
    - "Use on user-generated content outside support context"

data:
  training:
    sources: ["Support tickets (Jan 2023 - Oct 2024)"]
    labeling: "Historical queue assignment; manually audited sample"
    known_gaps: ["Low volume for Portuguese tickets", "Few enterprise customers in train set"]
  evaluation:
    datasets: ["Held-out time-based split (Nov-Dec 2024)", "Manual audit set (n=2000)"]

evaluation:
  metrics_overall:
    macro_f1: 0.86
    accuracy: 0.89
  slices:
    language:
      en_macro_f1: 0.88
      es_macro_f1: 0.84
      pt_macro_f1: 0.76

limitations:
  - "Lower performance on Portuguese due to limited training data"
  - "Confuses billing vs refunds when users include multiple issues in one ticket"

deployment:
  thresholding: "Route automatically if confidence >= 0.80; otherwise send to triage"
  monitoring:
    - "Weekly label audit for confidence>=0.80 auto-routed tickets"
    - "Drift monitoring on language distribution"

governance:
  approvals: ["Product", "Support Ops", "Risk/Compliance"]
  last_updated: "2025-01-15"
  changelog:
    - version: "2.1.0"
      changes: ["Added Portuguese samples", "Adjusted threshold from 0.85 to 0.80"]

Isso muitas vezes é suficiente para tornar o modelo mais seguro e reutilizável, além de criar uma base para documentação mais profunda depois.

Exemplo trabalhado (trecho): Cartão de Modelo para um classificador de toxicidade (toxicity classifier)

A seguir há um exemplo de trecho mostrando o nível de especificidade que ajuda em implantações reais.

Uso pretendido

  • Em escopo: Pontuação de pré-moderação (pre-moderation) de comentários de usuários para priorizar filas de revisão humana.
  • Supervisão humana: Obrigatória para ações de aplicação (enforcement actions) (remoções, banimentos).
  • Fora de escopo:
    • Aplicação totalmente automatizada sem revisão
    • Uso em mensagens privadas (não avaliado; expectativas de privacidade diferentes)
    • Uso para avaliar indivíduos (por exemplo, “este usuário é tóxico?”)

Destaques de avaliação

  • Conjunto de dados: 50k comentários amostrados dos últimos 90 dias; estratificado (stratified) por idioma.
  • Métricas: PR-AUC, FPR em TPR fixo e taxas de erro por fatia.
  • Achados:
    • Forte desempenho em inglês e espanhol
    • Maior taxa de falsos positivos em características de dialeto semelhantes ao African American English (requer mitigações)

Limitações e mitigações

  • Modo de falha: Sinaliza xingamentos ressignificados (reclaimed slurs) e linguagem intragrupo (in-group language) como tóxicos.
  • Mitigação:
    • Enviar para revisão em vez de remoção automática (auto-removal)
    • Adicionar fatias de avaliação sensíveis a dialetos
    • Incorporar resultados de recursos (appeal outcomes) ao monitoramento
    • Atualizar diretrizes de rotulagem e re-rotular um conjunto direcionado

Este exemplo mostra como um cartão de modelo pode conectar métricas a decisões operacionais — e não apenas publicar números.

Cartões de Modelo para modelos fundamentais e modelos de linguagem de grande porte

Para modelos fundamentais (foundation models) de linguagem de grande porte e modelos fundamentais multimodais (multimodal), um “cartão de modelo” frequentemente precisa de detalhes adicionais porque o comportamento depende fortemente do contexto:

  • Prompting e instruções de sistema (system instructions)
  • Uso de ferramentas / chamada de função (function calling)
  • Geração aumentada por recuperação (retrieval-augmented generation, RAG) e sua configuração
  • Camadas de segurança (safety layers) (filtros (filters), políticas de recusa (refusal policies))
  • Ajuste fino (fine-tuning) e otimização de preferências (preference optimization) (por exemplo, métodos no estilo aprendizado por reforço com feedback humano (reinforcement learning from human feedback, RLHF))

Na prática, equipes frequentemente mantêm:

  • Um Cartão de modelo para o modelo base ou o modelo ajustado
  • Um Cartão de sistema para a aplicação implantada, documentando a pilha completa e mitigações (veja Cartões de Sistema)

Para modelos de linguagem de grande porte, considere adicionar:

  • Capacidades e não capacidades (o que ele consegue/não consegue fazer de forma confiável)
  • Comportamento de alucinação (hallucination behavior) e orientação de mitigação (por exemplo, exigir citações via recuperação)
  • Suscetibilidade a quebra de salvaguardas (jailbreak) e injeção de prompt (e defesas recomendadas)
  • Avaliação de segurança (safety evaluation) por categorias de dano relevantes para seu domínio
  • Riscos de ferramentas (por exemplo, ações inseguras se ferramentas executarem código ou chamarem APIs externas)

Se o modelo for usado em um produto com conteúdo gerado por usuários ou políticas de segurança, conecte a documentação a Política de Conteúdo e Moderação.

Como operacionalizar Cartões de Modelo (processo, não apenas um documento)

Trate o cartão de modelo como um “artefato de entrega” (shipping artifact)

Um padrão prático é: sem implantação em produção sem um cartão de modelo (mesmo que mínimo). Vincule isso ao seu pipeline de release (release pipeline):

  • Modelo de solicitação de pull (pull request) exige atualização do cartão de modelo
  • Checklist de release inclui revisão/aprovação do cartão de modelo
  • Links de rastreamento de experimentos (IDs de execução (run IDs), conjuntos de dados, configurações)
  • Armazenamento versionado ao lado dos artefatos do modelo

Incorpore cartões de modelo aos fluxos de trabalho de MLOps

Pontos comuns de integração:

  • Registro de modelos (model registry): Armazene metadados do cartão de modelo ao lado da versão do modelo.
  • Integração contínua/entrega contínua (CI/CD, continuous integration/continuous delivery): Valide que seções obrigatórias estão presentes antes da promoção.
  • Painéis de monitoramento: Vincule métricas em tempo real às afirmações no cartão.
  • Resposta a incidentes (incident response): Atualize limitações/registro de mudanças após problemas (veja Relato de Incidentes e Transparência).

Alinhe com estruturas de gestão de risco

Cartões de modelo se mapeiam naturalmente à governança de risco. Por exemplo, ao seguir a Estrutura de Gestão de Risco de IA do NIST:

  • Atividades de “Mapear (Map)” e “Medir (Measure)” produzem evidências de avaliação
  • Atividades de “Gerenciar (Manage)” impulsionam mitigações, monitoramento e responsabilização
  • O cartão de modelo se torna um registro durável dessas decisões

Mantenha detalhes sensíveis com escopo apropriado

Algumas informações podem ser inadequadas para publicação externa (por exemplo, vulnerabilidades adversariais, conjuntos de dados proprietários). Uma prática comum é manter:

  • Um cartão de modelo interno (detalhes completos)
  • Um cartão de modelo externo (redigido, seguro para clientes)

Armadilhas comuns (e como evitá-las)

  • Uso pretendido vago: “Classificador de propósito geral” não ajuda. Especifique escopo, usuários e decisões.
  • Apenas métricas agregadas: A avaliação por fatias é frequentemente onde danos se escondem.
  • Sem comparação de linha de base (baseline): Inclua a versão anterior do modelo ou uma linha de base heurística simples quando possível.
  • Documentação desatualizada: Se o cartão não é atualizado após retreinamento, mudanças de limiar ou incidentes, ele se torna enganoso.
  • Confundir modelo vs. sistema: Se os resultados dependem de prompts, recuperação ou UI, coloque isso em um Cartões de Sistema e faça o link.

Um checklist de revisão para Cartões de Modelo de alta qualidade

Use isto como um gate antes da implantação:

  • Propósito e escopo estão claros; usos fora de escopo são explícitos
  • Entradas/saídas e restrições estão documentadas
  • Dados de treinamento e avaliação são descritos com proveniência e lacunas conhecidas
  • Métricas incluem desempenho por fatias quando relevante
  • Limiares e pontos de operação estão documentados (incluindo trade-offs)
  • Limitações conhecidas incluem exemplos concretos e mitigações
  • Monitoramento e gatilhos de retreinamento estão definidos
  • Versionamento e registro de mudanças são mantidos
  • Contatos de responsáveis e escalonamento estão incluídos
  • Existem links para avaliação de risco e documentação no nível do sistema quando aplicável (veja Avaliações de Risco e Cartões de Sistema)

Resumo

Um cartão de modelo é uma ferramenta prática de governança que transforma um modelo treinado em um componente documentado, revisável e mais seguro para implantar. Quando bem feito, ele captura não apenas alegações de desempenho, mas também contexto: uso pretendido, metodologia de avaliação, limitações e salvaguardas operacionais. Na IA moderna — especialmente com modelos fundamentais — cartões de modelo funcionam melhor como parte de um programa mais amplo de documentação e risco que inclui Avaliações de Risco, Cartões de Sistema e um sólido Relato de Incidentes e Transparência.