Uma model card de IA é um documento curto e estruturado que viaja com um modelo treinado: para que serve, como foi treinado e testado, onde falha. Nasceu na Google em 2018 e 2019; a Hugging Face fez dela o README.md de cada modelo. Desde 2 de agosto de 2025, o AI Act exige aos prestadores de modelos uma documentação parecida com uma model card, mas mais longa e juridicamente exigível; a partir de 2 de dezembro de 2027, os prestadores de sistemas de risco elevado devem um dossiê técnico que a ficha apenas começa. Este guia lê a model card como um auditor ou uma autoridade de fiscalização do mercado: o que contém, o que falta, que lei a exige, como a tornar prova.
O essencial
- Uma model card é um formato voluntário com nove secções canónicas (Mitchell et al., 2019), não um documento legal.
- O template da Hugging Face é o padrão de facto, mas cobre cerca de metade do
Anexo XIe do Formulário de Documentação do Modelo. - Desde 2 de agosto de 2025, os prestadores de modelos de finalidade geral mantêm documentação (
Anexo XI), partilham-na a jusante (Anexo XII) e publicam um resumo do treino; o dossiê de risco elevado (Anexo IV) segue em dezembro de 2027. - A transparência desce: média de 41 em 100 no Foundation Model Transparency Index de dezembro de 2025, 17 pontos abaixo de 2024; na Hugging Face, impacto ambiental, limitações e avaliação ficam por preencher.
- Uma model card vira prova quando é versionada, assinada por três perfis, escrita nos campos do regulador e ligada ao registo do sistema.
O que é uma model card?
A expressão nasce num artigo académico. Em outubro de 2018, Margaret Mitchell, Timnit Gebru e sete coautores publicaram no arXiv «Model Cards for Model Reporting» (1810.03993), apresentado em janeiro de 2019 na conferência FAT\*, em Atlanta. Em tradução livre: documentos curtos que acompanham modelos de aprendizagem automática treinados e apresentam uma avaliação comparada em várias condições, por exemplo entre grupos culturais, demográficos ou fenotípicos. Dois exemplos: um classificador de sorrisos treinado no CelebA e o modelo de toxicidade da Perspective API. Público: quem desenvolve, quem decide políticas públicas, quem é afetado (ver o que é um modelo de IA). No Hub da Hugging Face, a model card é o README.md do repositório: Markdown para o texto e um bloco YAML no topo, com campos como license, language, datasets, base_model, pipeline_tag, library_name, resultados de avaliação estruturados e emissões de CO2. A documentação das model cards mostra como estes metadados alimentam a pesquisa do Hub. O Guia de Model Cards (Ozoani, Gerchick e Mitchell, 2022) acrescenta o que as equipas técnicas esquecem: uma boa ficha exige três perfis, quem desenvolve o modelo, um perfil «sociotécnico» (jurista, especialista em ética, defensor de direitos) e quem organiza o projeto.
Model card, system card, data card: três artefactos, três objetos
A system card descreve o produto implantado: prompts de sistema, barreiras de proteção, ferramentas ligadas, avaliações de segurança do conjunto. A OpenAI popularizou o género com a System Card do GPT-4, em março de 2023; a Anthropic publica system cards para os modelos Claude. Em agosto de 2025, para os modelos de pesos abertos gpt-oss, a OpenAI publicou uma model card, não uma system card, porque o que circulou foram os pesos. A data card, ou datasheet, descreve o conjunto de dados: «Datasheets for Datasets», Gebru et al., 2018. Regra prática: um artefacto por objeto. A model card descreve os pesos.
As nove secções de uma model card e a pergunta a que cada uma responde
Mitchell et al. propõem nove secções; cada uma responde a uma pergunta e tem uma forma habitual de falhar. <table header-row=”true”> <tr> <td>Secção</td> <td>Pergunta a que responde</td> <td>Fraqueza típica</td> </tr> <tr> <td>Model Details</td> <td>Quem o construiu, versão, data, tipo, licença, contacto?</td> <td>Versão e data omitidas</td> </tr> <tr> <td>Intended Use</td> <td>Usos primários, utilizadores, usos fora do âmbito?</td> <td>Marketing; sem usos excluídos</td> </tr> <tr> <td>Factors</td> <td>Que grupos, instrumentos ou ambientes alteram o desempenho?</td> <td>Nunca desagregados</td> </tr> <tr> <td>Metrics</td> <td>Que medidas, que limiares, como se reporta a variação?</td> <td>Sem limiares</td> </tr> <tr> <td>Evaluation Data</td> <td>Que conjuntos, porquê, com que pré-processamento?</td> <td>Iguais aos de treino</td> </tr> <tr> <td>Training Data</td> <td>Com que dados aprendeu, ou porque não se divulgam?</td> <td>«Proprietários», sem proveniência</td> </tr> <tr> <td>Quantitative Analyses</td> <td>Resultados por fator isolado e em interseção?</td> <td>Só o agregado</td> </tr> <tr> <td>Ethical Considerations</td> <td>Dados sensíveis, riscos para a vida humana, mitigações?</td> <td>Ética como exoneração</td> </tr> <tr> <td>Caveats and Recommendations</td> <td>O que a avaliação não cobriu?</td> <td>Vazia ou copiada</td> </tr> </table> O template da Hugging Face reorganiza-as na ordem de quem publica: Model Details; Uses (direta, a jusante, fora do âmbito); Bias, Risks and Limitations, com Recommendations; Training Details; Evaluation (dados de teste, fatores, métricas, resultados); Environmental Impact; Technical Specifications; Citation; Glossary; Authors; Contact; How to Get Started. O template anotado explica cada campo. O guia fixa três definições úteis: um enviesamento é um desvio de desempenho para certas subpopulações; um risco é um problema socialmente relevante que o modelo pode causar; uma limitação é um modo de falha provável, ao qual as recomendações respondem. Quando uma model card mistura os três num parágrafo, o auditor não distingue o medido, o antecipado e o apenas receado.
O que uma model card não é: voluntária, autodeclarada, desigual
Nenhuma lei impõe o formato. Ninguém verifica o que lá está escrito. Quem escreve escolhe o que mede, em que dados e com que métrica. Duas medições mostram o estado da prática. O Foundation Model Transparency Index 2025 do Stanford CRFM, terceira edição, dezembro de 2025: 13 empresas, 100 indicadores, média de 41 em 100, 17 pontos abaixo de 2024; a IBM obtém 95, a xAI e a Midjourney 14. E a análise de Liang et al., fevereiro de 2024, sobre 32 111 model cards do Hub: treino é a secção mais preenchida; impacto ambiental, limitações e avaliação, as menos. Fichas pormenorizadas acrescentadas a 42 modelos populares correlacionaram-se moderadamente com mais descarregamentos semanais. Uma model card recebida de um fornecedor é uma alegação, não uma constatação: e um benchmark só serve de prova com dados, limiares e autor conhecidos. Uma model card publicada pela própria organização é uma declaração pela qual será responsabilizada. Há ainda o tempo: a ficha descreve um modelo numa data; a deriva do modelo começa no dia seguinte, e a auditabilidade depende menos do texto da ficha do que das versões, datas e assinaturas que a rodeiam.
Onde a model card encontra o AI Act
O AI Act (Regulamento (UE) 2024/1689) nunca escreve model card; as suas listas de campos leem-se como uma model card alargada.
Modelos de IA de finalidade geral: artigo 53.º, Anexo XI e o Formulário de Documentação do Modelo
O artigo 53.º, n.º 1, aplica-se desde 2 de agosto de 2025 aos prestadores de modelos de IA de finalidade geral: (a) documentação técnica com, pelo menos, os elementos do Anexo XI, atualizada e entregue a pedido ao Serviço para a IA e às autoridades nacionais; (b) documentação com os elementos do Anexo XII para os prestadores a jusante, para que percebam capacidades e limitações; (c) uma política de direitos de autor; (d) um resumo público do conteúdo de treino, no template publicado pelo Serviço para a IA a 24 de julho de 2025. O n.º 2 isenta de (a) e (b) os modelos livres e de código aberto com parâmetros públicos, salvo risco sistémico. A secção 1 do Anexo XI pede a identidade e a distribuição do modelo (arquitetura, parâmetros, modalidades, licença, sistemas de integração, utilização aceitável, lançamento), a conceção e o treino fundamentados, os dados (tipo, proveniência, curadoria, número de pontos, âmbito, deteção de enviesamentos), o cálculo em operações de vírgula flutuante, o tempo de treino e a energia; a secção 2, para risco sistémico, acrescenta avaliação, testes adversariais e red teaming, e a arquitetura do sistema. O Código de Práticas (texto final de 10 de julho de 2025, aprovado pela Comissão e pelo Comité para a IA a 1 de agosto de 2025; texto e signatários na página da Comissão) converte isto num Formulário de Documentação do Modelo. Medida 1.1: documentar cada campo na colocação no mercado, atualizar, guardar as versões anteriores dez anos. Medida 1.2: ponto de contacto público, campos aplicáveis aos prestadores a jusante em 14 dias, ao Serviço para a IA o que pedir. Medida 1.3: controlo de qualidade, integridade, proteção contra alterações. O Formulário é uma model card com uma terceira coluna: para cada campo, três caixas dizem se vai para o Serviço para a IA, para as autoridades nacionais ou para os prestadores a jusante. Pede nome legal do prestador, data de colocação no mercado da União, hash ou endpoint de autenticidade, dependências de outros modelos, número de parâmetros (dois algarismos significativos para o Serviço para a IA, um intervalo de 1 a 500 milhões até mais de 1 bilião para os demais), tamanhos máximos de entrada e saída, canais de distribuição, licença, política de utilização aceitável, utilizações previstas em cerca de 200 palavras, tipos de sistema de IA admitidos e excluídos, processo de treino em cerca de 400 palavras com a fundamentação das decisões, proveniência dos dados por categoria (recolha na web, conjuntos privados de terceiros, dados de utilizadores, conjuntos públicos, dados sintéticos), medidas de deteção de fontes inadequadas, incluindo CSAM e NCII, medidas contra enviesamentos identificáveis, tempo de treino em tempo de relógio e dias de hardware, cálculo em FLOPs, energia em megawatt-hora e um valor de referência do cálculo em inferência. O que segue para as autoridades fica sob os segredos comerciais do artigo 78.º.
Sistemas de IA de risco elevado: Anexo IV, artigo 13.º e a ficha do responsável pela implantação
Para os sistemas de IA de risco elevado, o artigo 11.º e o Anexo IV exigem a documentação técnica antes da colocação no mercado, em nove pontos: descrição geral (finalidade, prestador, versões, interações, hardware, instruções de utilização); desenvolvimento (métodos, modelos pré-treinados de terceiros, conceção, arquitetura, dados com proveniência, rotulagem e limpeza, supervisão humana, alterações predeterminadas, validação e testes com métricas de exatidão, solidez e impacto discriminatório, cibersegurança); acompanhamento e controlo (desempenho por grupos, efeitos não intencionais previsíveis, dados de entrada); adequação das métricas; gestão de riscos do artigo 9.º; alterações no ciclo de vida; normas harmonizadas; declaração UE de conformidade; plano pós-comercialização do artigo 72.º. O artigo 18.º manda conservar tudo dez anos; a avaliação da conformidade parte deste dossiê. O artigo 13.º, n.º 3, é a model card virada para quem implanta: as instruções de utilização indicam identidade do prestador, finalidade, exatidão e métricas, solidez, cibersegurança, riscos de utilização indevida previsíveis, desempenho para grupos específicos, especificações dos dados de entrada, alterações predeterminadas, medidas de supervisão humana, necessidades de cálculo e hardware, tempo de vida esperado e manutenção, mecanismos de registo de eventos. O Omnibus Digital (Regulamento (UE) 2026/1744, Jornal Oficial de 24 de julho de 2026, em vigor desde 27 de julho) fixou as datas: Anexo III a partir de 2 de dezembro de 2027, sistemas embutidos do Anexo I a partir de 2 de agosto de 2028. PME e, agora, pequenas empresas de média capitalização podem usar o formulário simplificado da Comissão: as mesmas nove áreas, menos texto. Quem implanta segue as instruções (artigo 26.º) e, nos casos do Anexo III no setor público e em alguns privados, parte dessa ficha para a avaliação de impacto sobre os direitos fundamentais do artigo 27.º. A montagem do dossiê está no guia de documentação de sistemas de IA.
Auditoria de lacunas: o template da Hugging Face face às listas de campos legais
A nossa leitura, não um mapeamento oficial: o template da Hugging Face face aos campos do Anexo IV, do Anexo XI e do Formulário. Explica porque uma model card bem preenchida não basta. <table header-row=”true”> <tr> <td>Secção do template</td> <td>O que pedem o Anexo IV, o Anexo XI ou o Formulário</td> <td>Lacuna</td> </tr> <tr> <td>Model Details</td> <td>Nome legal, data de colocação no mercado da União, hash de autenticidade, dependências</td> <td>Em falta</td> </tr> <tr> <td>Uses</td> <td>Política de utilização aceitável; tipos de sistema de IA admitidos ou excluídos (200 a 300 palavras)</td> <td>Parcial</td> </tr> <tr> <td>Bias, Risks and Limitations</td> <td>Medidas de deteção de fontes inadequadas e de enviesamentos identificáveis</td> <td>Em falta (o template regista resultados, não métodos)</td> </tr> <tr> <td>Training Details</td> <td>Fundamentação das decisões, categorias de proveniência, número de pontos de dados, curadoria, medidas CSAM e NCII</td> <td>Em falta</td> </tr> <tr> <td>Evaluation</td> <td>Anexo XI, secção 2, e Anexo IV, ponto 2(g): estratégias de avaliação, testes adversariais, impacto discriminatório, limiares</td> <td>Parcial</td> </tr> <tr> <td>Environmental Impact</td> <td>Energia em MWh com dois algarismos significativos e metodologia</td> <td>Parcial: o campo CO2 anda perto</td> </tr> <tr> <td>Technical Specifications</td> <td>Parâmetros, tamanhos máximos de entrada e saída, FLOPs, tempo de treino em dias de hardware</td> <td>Parcial</td> </tr> <tr> <td>Nada</td> <td>Anexo IV, pontos 2(e) a 2(h) e 3 a 9: supervisão humana, alterações predeterminadas, cibersegurança, gestão de riscos, ciclo de vida, normas, declaração de conformidade, plano pós-comercialização</td> <td>Em falta</td> </tr> <tr> <td>Nada</td> <td>Artigo 13.º, n.º 3, alíneas (e) e (f): tempo de vida esperado, manutenção, registo de eventos</td> <td>Em falta</td> </tr> </table> O que o template tem e a lei não pede (citação, glossário, como começar, autores) é o que torna uma model card legível por quem a encontra pela primeira vez. Substituí-la por um formulário jurídico é um erro: ninguém o lê e ninguém o atualiza. O caminho é manter a model card e acrescentar-lhe, por baixo, os campos legais com os nomes exatos dos anexos, para que o mesmo documento sirva o programador e o auditor.
Fora da UE: onde mais se espera uma model card
A Europa escreveu a versão mais longa; não é a única jurisdição que espera uma model card.
- Estados Unidos, FDA. O guia preliminar de 7 de janeiro de 2025 sobre software de dispositivos médicos com IA traz no Apêndice E um exemplo de model card para utilizadores e clínicos e no Apêndice F um resumo 510(k) com a ficha preenchida. A FDA não exige uma model card nem um formato específico, mas nota que a investigação associa a ficha a mais confiança do utilizador. Ainda é um projeto.
- Califórnia, SB 53. O Transparency in Frontier Artificial Intelligence Act, assinado a 29 de setembro de 2025 e em vigor desde 1 de janeiro de 2026, obriga quem desenvolve modelos de fronteira acima de 10\^26 operações de treino a publicar, antes ou no momento da implantação, um relatório de transparência: data de lançamento, línguas e modalidades, utilizações previstas, restrições, contacto. Acima de 500 milhões de dólares de receita anual juntam-se resumos das avaliações de risco catastrófico. Até 1 milhão de dólares por infração, pelo Procurador-Geral; ver a lei californiana.
- Nova Iorque, RAISE Act. Assinada a 19 de dezembro de 2025, alterada a 27 de março de 2026, em vigor a 1 de janeiro de 2027: protocolos de segurança publicados, incidentes comunicados em 72 horas, sanções até 1 milhão de dólares e 3 milhões em reincidência. O regime europeu de comunicação de incidentes segue a mesma lógica.
- NIST AI RMF. O Playbook lista model cards e system cards entre as práticas de documentação sugeridas; é voluntário, como todo o quadro do NIST.
- Europa fora do AI Act. A lista de verificação para auditoria de IA encomendada pelo Comité Europeu para a Proteção de Dados (Gemma Galdon Clavell, janeiro de 2023) abre com uma secção «Model Card» cruzada com o RGPD; a Avaliação de Impacto de IA v2.0 do ministério neerlandês das infraestruturas (dezembro de 2024) pergunta se existe uma model card ou equivalente.
- Normas. A
ISO/IEC 42001tem áreas de controlo para a documentação técnica do sistema de IA, a informação aos utilizadores e a proveniência dos dados; o auditor de certificação pergunta onde vive a documentação e como se atualiza (ver o guia da ISO 42001). - Cadeia de fornecimento. O CycloneDX 1.5, de junho de 2023, acrescentou um ML-BOM com um componente de tipo modelo cujos campos espelham uma model card; a ficha pode viajar dentro de um SBOM.
Em Portugal, o ponto de contacto já tem nome: a ANACOM, designada autoridade de fiscalização do mercado para o AI Act em setembro de 2025, é a quem um prestador nacional mostrará a documentação do Anexo IV ou do Anexo XI. A CNPD continua a perguntar por dados pessoais nos conjuntos de treino, e é a secção de proveniência da model card que lhe responde. A estratégia nacional de IA pede transparência nos sistemas públicos; uma ficha publicada é a forma mais barata de a dar.
Como escrever uma model card que sobrevive a uma auditoria: seis passos
- Uma model card por versão, imutável depois de lançada. Cada versão recebe a sua ficha e um registo de alterações que nomeia o que mudou nos dados, no treino, na avaliação ou na utilização prevista: o ponto 6 do
Anexo IVe os dez anos da Medida 1.1. Registo produzido: o histórico de versões. - Os campos legais primeiro, no vocabulário do regulador. Nome legal, datas de lançamento e de colocação no mercado da União, dependências, licença, política de utilização aceitável, utilizações previstas e fora do âmbito, tipos de sistema de IA admitidos, com os nomes dos anexos. Registo produzido: a secção de identificação legal da ficha.
- Avaliar de forma desagregada e reportar o que o artigo 13.º quer. Exatidão com métricas e limiares, solidez, cibersegurança, desempenho para grupos específicos. Um benchmark só entra na ficha com o conjunto de dados, a data e o protocolo. Registo produzido: o relatório de avaliação com resultados por fator.
- Documentar os dados por categoria de proveniência. As cinco categorias do Formulário, com o número de pontos de dados e as medidas de deteção de fontes inadequadas e de enviesamentos. É a parte que a CNPD lerá primeiro (ver documentação de sistemas de IA). Registo produzido: a ficha de dados de treino com proveniência.
- Três perfis assinam, um dono responde. Quem desenvolve, o perfil sociotécnico e quem organiza o projeto assinam; um nome fica como dono, com revisão a cada lançamento e, no mínimo, anual. Registo produzido: a página de assinaturas com a próxima revisão agendada.
- Ligar a ficha ao registo do sistema. Inventário de IA, registo de riscos, instruções de utilização, registo de incidentes, contrato com o fornecedor. Aos fornecedores pedem-se os campos do
Anexo XII, com o dever de entrega em 14 dias e uma atualização trimestral no contrato, cláusula que um guia prático para juristas já propõe (model cards com arquitetura, proveniência dos dados, benchmarks, testes de enviesamento e monitorização). A due diligence de fornecedores de IA lista as perguntas. Registo produzido: as ligações cruzadas no registo e a cláusula contratual.
Seis passos, seis registos: o dossiê que uma autoridade pode pedir hoje ao abrigo do artigo 53.º e, a partir de dezembro de 2027, ao abrigo do Anexo IV. Quem já gere o risco de modelo reconhecerá os artefactos.
As model cards no registo do sistema de IA
Uma model card fala de um modelo. Uma autoridade pergunta por um sistema: o produto que decide sobre pessoas. O registo liga os dois. Cada registo de sistema de IA lista os seus componentes de modelo; cada componente transporta os campos da sua ficha e a versão em uso; uma alteração na ficha reabre a avaliação de riscos e as instruções de utilização. É assim que o registo de IA do AI Sigil está construído: a ficha de cada modelo vive ao lado dos controlos do quadro aplicável, dos riscos e das evidências, para que a resposta a «mostre-me a documentação deste modelo» seja um relatório gerado, não uma pesquisa em pastas partilhadas. Sem um inventário de sistemas de IA completo, as melhores model cards ficam órfãs.
Perguntas frequentes
O que é uma model card, em termos simples? É a ficha de identidade de um modelo de IA: um documento curto que diz quem o construiu, para que serve, com que dados foi treinado, como foi avaliado e onde falha. Nasceu na Google em 2018 e 2019 e a Hugging Face fez dela o README.md de cada modelo publicado. Não substitui a documentação exigida por lei, mas é o ponto de partida habitual. Uma model card é obrigatória? O formato, não: nenhuma lei impõe as nove secções. O conteúdo, sim: o artigo 53.º do AI Act exige documentação do modelo aos prestadores de IA de finalidade geral desde 2 de agosto de 2025, o Anexo IV exige o dossiê de risco elevado a partir de 2 de dezembro de 2027 e a SB 53 californiana exige relatórios de transparência desde 1 de janeiro de 2026. Qual é a diferença entre uma model card e uma system card? A model card descreve os pesos: arquitetura, dados de treino, avaliação, limitações do modelo em si. A system card descreve o produto implantado em torno dele: prompts de sistema, barreiras de proteção, ferramentas ligadas, avaliações de segurança do conjunto. Um modelo pode viver em vários sistemas, e cada um merece a sua ficha. Por isso a OpenAI publicou uma model card, não uma system card, para os pesos abertos gpt-oss. Uma model card da Hugging Face satisfaz o AI Act? Não. O template cobre cerca de metade dos campos do Anexo XI e do Formulário de Documentação do Modelo, e nenhum dos pontos de governação do Anexo IV: supervisão humana, cibersegurança, gestão de riscos, alterações predeterminadas, plano pós-comercialização, declaração de conformidade. Faltam também nome legal, data de colocação no mercado da União, autenticidade, categorias de proveniência e deteção de fontes inadequadas. É uma boa base; não é o dossiê. Quem deve escrever a model card? Três perfis, segundo o guia da Hugging Face: quem desenvolveu o modelo, porque conhece os dados e as métricas; um perfil sociotécnico (jurista, especialista em ética, defensor de direitos), porque vê os riscos que o programador não vê; e quem organiza o projeto, porque sabe onde e para quê o modelo será usado. Um dos três fica como dono nomeado, com o dever de a rever. Com que frequência deve uma model card ser atualizada? A cada versão do modelo: uma alteração nos dados, no treino, na avaliação ou na utilização prevista gera uma nova ficha e uma entrada no registo de alterações. Entre versões, uma revisão anual confirma que limitações e contactos continuam válidos. O Código de Práticas para a IA de finalidade geral manda conservar as versões anteriores dez anos, logo cada ficha tem de ser imutável depois de publicada.
Conclusão
A model card é o vocabulário mais difundido para descrever um modelo de IA, e foi desenhada para a transparência, não para a conformidade. O AI Act escreveu agora na lei uma versão mais longa dela para os prestadores de modelos de finalidade geral e fará o mesmo, em dezembro de 2027, para os sistemas de risco elevado; a Califórnia e Nova Iorque pedem relatórios de transparência com o mesmo esqueleto. O trabalho de uma equipa de governação não é substituir a ficha: é completá-la, versioná-la, assiná-la e ligá-la ao sistema que serve. O AI Sigil guarda a model card de cada modelo ao lado do seu sistema de IA, dos seus riscos e dos seus controlos, para que a documentação que um regulador pede já exista.