O Model Card Que Ninguém Lê

A Anthropic publica um model card para cada lançamento do Claude. A OpenAI publica um system card para cada lançamento do GPT. A Google DeepMind publica relatórios técnicos para o Gemini. A Meta publica model cards para o Llama. A Mistral publica-os para os seus modelos. São os documentos de fonte primária — escritos pelas pessoas que construíram os modelos — que descrevem exactamente o que o modelo consegue fazer, o que não consegue fazer, onde falha e em que condições os seus outputs não devem ser confiáveis.

Quase ninguém os lê.

A página de marketing recebe milhões de visitas. O model card recebe milhares. O blog post que anuncia o modelo é partilhado em todas as newsletters e feeds de LinkedIn sobre IA. O model card — o documento que realmente diz se este modelo é adequado para o vosso caso de uso — fica silenciosamente num site de documentação, não lido, não citado, não usado.

Isto é um problema. Especificamente, é o tipo de problema que custa dinheiro às empresas, produz implantações deficientes e erode a confiança em ferramentas de IA — tudo porque o documento mais importante que acompanha cada modelo é tratado como um apêndice técnico em vez de um manual operacional.

O Que um Model Card Realmente Contém

O termo “model card” vem de um artigo de 2019 de Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji e Timnit Gebru. O artigo propunha um enquadramento de documentação padronizado para modelos de aprendizagem automática — análogo a um rótulo nutricional para alimentos ou uma ficha de dados de segurança para químicos.

O enquadramento original especificava: detalhes do modelo, uso previsto, factores (factores demográficos ou contextuais relevantes), métricas, dados de avaliação, dados de treino, análises quantitativas, considerações éticas e ressalvas e recomendações.

Na prática, os model cards dos principais laboratórios de IA evoluíram para além deste modelo, mas o propósito central mantém-se: documentação honesta das capacidades, limitações e casos de uso apropriados de um modelo, escrita pelas pessoas que melhor o conhecem.

Os model cards do Claude da Anthropic, por exemplo, contêm:

Avaliações de capacidade com benchmarks específicos. Não “o Claude é bom a raciocinar” mas “o Claude atinge X% no benchmark MMLU, Y% no HumanEval, Z% no MATH.” Estes números são comparáveis entre modelos. Dizem, especificamente, como o modelo se comporta em testes padronizados de conhecimento, capacidade de programação e raciocínio matemático.

Limitações conhecidas documentadas explicitamente. O model card declara onde o modelo falha. Onde alucina. Onde os seus outputs não devem ser confiáveis sem verificação humana. Esta informação não está enterrada em disclaimers — é apresentada em primeiro plano como orientação operacional.

Avaliações de segurança. Como o modelo foi testado para outputs nocivos, enviesamento e potencial de uso indevido. Que mitigações foram aplicadas. Que riscos residuais permanecem. É a avaliação mais honesta do perfil de segurança de um modelo disponível em qualquer lado — mais honesta que um blog post de marketing, mais específica que o resumo de um jornalista.

Casos de uso previstos e potencial de uso indevido. Para que foi desenhado o modelo, para que não foi desenhado e que usos os criadores desaconselham especificamente. Para uma PME a avaliar se deve implementar este modelo para uma tarefa específica, esta secção é a peça de orientação mais valiosa que existe.

Os system cards da OpenAI fornecem informação equivalente num formato diferente, com profundidade particular na sua metodologia de avaliação de segurança — resultados de red-teaming, pipelines de avaliação automatizada e as categorias específicas de risco que testam.

Estes documentos não são materiais de marketing. São divulgações técnicas. São o que de mais próximo a indústria de IA produz de uma auto-avaliação honesta. E são ignorados.

Porque É Que Ninguém Os Lê

Três razões, todas estruturais.

Os documentos são escritos para investigadores, não para operadores. Os model cards usam a linguagem da investigação em aprendizagem automática: nomes de benchmarks, metodologias de avaliação, medidas estatísticas. Um director de compras a avaliar se deve implementar o Claude para classificação de pedidos de clientes não sabe o que MMLU significa, não tem uma base de referência para interpretar uma pontuação de HumanEval e não sabe como traduzir uma avaliação de segurança numa avaliação de risco operacional. A informação é valiosa. A camada de tradução está em falta.

O marketing é mais fácil de consumir. Um blog post que anuncia um novo modelo tem 1.500 palavras de prosa acessível com afirmações claras: “mais rápido”, “mais exacto”, “melhor a programar”. O model card tem 15.000 palavras de documentação técnica com ressalvas, limitações e afirmações condicionais. O blog post confirma o que querem ouvir. O model card diz o que precisam de saber. São audiências diferentes, e o marketing ganha sempre a competição pela atenção.

O trabalho de ninguém inclui ler model cards. Numa empresa de 200 pessoas a avaliar uma implantação de IA, ninguém é responsável por ler o model card. O CTO pode ter os conhecimentos técnicos mas não tem tempo. O gestor de projecto tem o tempo mas não tem os conhecimentos técnicos. O consultor externo tem uma recomendação de modelo pronta antes de o model card ter sido descarregado. O model card cai num vazio de responsabilidade — demasiado técnico para o decisor de negócio, demasiado operacional para a equipa de investigação, demasiado detalhado para o cronograma do consultor.

O Que um Model Card Diz Que Mais Nada Diz

Vou demonstrar com um exemplo específico. Vou percorrer três categorias de informação dos model cards que afectam directamente se uma PME europeia deve implementar um modelo específico para um caso de uso específico.

Categoria 1: Variância de Desempenho Linguístico

Os model cards reportam benchmarks de desempenho multilingue. Estes benchmarks revelam diferenças de desempenho entre línguas que os materiais de marketing nunca mencionam.

Um modelo que pontua 89% em question answering em inglês pode pontuar 72% em alemão e 58% em português. A página de marketing diz “suporta 95+ línguas”. O model card mostra o gradiente de desempenho real — e para uma PME europeia a operar em múltiplos mercados, a diferença entre 89% e 58% é a diferença entre uma ferramenta útil e uma responsabilidade.

Quando um cliente português submete um pedido e a exactidão de compreensão do modelo é 31 pontos percentuais inferior à de um pedido em inglês, a qualidade do output degrada-se. O cliente recebe uma resposta menos exacta. Se a resposta envolve uma recomendação, uma classificação ou uma decisão, a diferença de exactidão torna-se uma diferença de qualidade, uma diferença de equidade e, potencialmente, uma questão jurídica ao abrigo do Artigo 22 do RGPD.

O model card diz-nos isto. O blog post não.

Categoria 2: Taxas de Alucinação por Domínio

Os model cards reportam cada vez mais taxas de alucinação — a frequência com que o modelo gera informação que soa plausível mas é factualmente incorrecta. Estas taxas variam dramaticamente por domínio.

Um modelo pode alucinar a 2% em perguntas de conhecimento geral e a 12% em perguntas técnicas específicas de domínio. Para uma PME que implementa o modelo para responder a pedidos de clientes sobre uma linha de produtos especializada, a taxa de alucinação relevante é a específica do domínio, não o número de destaque.

Mais criticamente, os model cards descrevem os tipos de alucinações a que o modelo é propenso. Alguns modelos alucinam detalhes específicos (datas, números, nomes) mas acertam na direcção geral. Outros alucinam cadeias causais inteiras — produzindo explicações que soam autoritativas e são completamente fabricadas. O tipo de alucinação determina o tipo de supervisão humana necessária.

Um modelo que por vezes erra datas precisa de uma camada de verificação factual. Um modelo que fabrica explicações precisa de um revisor especialista no domínio. A resposta operacional é diferente. O model card diz qual é necessária.

Categoria 3: Resultados da Avaliação de Segurança

Os model cards de laboratórios de IA responsáveis incluem resultados de red-teaming — os resultados de tentativas sistemáticas de fazer o modelo produzir outputs nocivos, enviesados ou inapropriados.

Para uma PME europeia, as considerações de segurança relevantes são específicas: se o modelo gera outputs enviesados que possam afectar decisões de emprego (relevante ao abrigo do Artigo 22 do RGPD e do Artigo 6 da Lei da IA da UE), se produz conteúdo discriminatório em aplicações voltadas para o cliente e se divulga dados de treino que incluam informação pessoal.

O model card aborda estas questões com resultados de testes específicos. Não “testámos para enviesamento” mas “testámos para enviesamento demográfico em X categorias usando a metodologia Y e observámos o padrão Z de enviesamento residual nas seguintes condições.”

Esta informação é essencial para a avaliação de conformidade exigida pela Lei da IA da UE para sistemas de IA de alto risco. O Artigo 9 exige um sistema de gestão de risco que inclua identificação e análise de riscos conhecidos e previsíveis. O model card é a fonte primária para riscos conhecidos. Ignorá-lo não é apenas operacionalmente imprudente — pode ser juridicamente insuficiente.

Como Ler um Model Card

Para uma PME a avaliar uma implantação de IA, aqui está a abordagem operacional para ler um model card. Demora aproximadamente duas horas, o que é menos do que a reunião média de comité directivo e produz informação mais útil.

Passo 1: Leiam a secção de uso previsto primeiro. O uso previsto corresponde ao vosso caso de uso? Se o model card diz que o modelo é “desenhado para assistência conversacional e geração de conteúdo” e vocês querem usá-lo para avaliação automatizada de crédito, há um desajuste. O desajuste não significa que o modelo não o consiga fazer. Significa que os criadores não o testaram para esse propósito, o que significa que a responsabilidade de testar cai sobre vocês.

Passo 2: Verifiquem os benchmarks multilingues. Encontrem os números de desempenho para cada língua que a vossa implantação vai usar. Se a diferença de desempenho entre a vossa língua primária e as línguas secundárias excede 10 pontos percentuais, planeiem uma camada de garantia de qualidade nas línguas de menor desempenho.

Passo 3: Leiam a secção de limitações completamente. É a secção mais valiosa. Os criadores estão a dizer onde o modelo deles falha. Sabem, porque o testaram. Ignorar esta secção é o equivalente em IA a ignorar o relatório do engenheiro de estruturas antes de construir num terreno. A informação está lá. As consequências de a ignorar são previsíveis.

Passo 4: Revejam a avaliação de segurança. Identifiquem as categorias de output nocivo que foram testadas e os riscos residuais que permanecem. Mapeiem-nos para o vosso caso de uso. Se a vossa implantação envolve populações vulneráveis (clientes a candidatar-se a produtos financeiros, candidatos a emprego, pacientes), a avaliação de segurança não é leitura suplementar. É um requisito de conformidade.

Passo 5: Comparem entre modelos. Os model cards são comparáveis. Os mesmos benchmarks, as mesmas categorias, as mesmas metodologias de avaliação aparecem nos model cards de diferentes laboratórios. Leiam três model cards de modelos concorrentes e as diferenças de desempenho — incluindo as não óbvias enterradas nos apêndices — tornam-se claras.

Categoria 4: Documentação de Uso Apropriado e Uso Indevido

Os model cards incluem cada vez mais listas explícitas de casos de uso previstos e cenários documentados de uso indevido. Estas listas não são hipotéticas. São extraídas de comportamento de utilizadores observado durante testes e implantação.

Para uma PME que implementa um modelo linguístico para aplicações voltadas para o cliente, a documentação de uso indevido é operacionalmente crítica. O model card pode especificar: “Este modelo não foi desenhado para diagnóstico médico, aconselhamento jurídico ou recomendações financeiras.” Se a vossa implantação usa o modelo para gerar recomendações de produtos financeiros, o model card acabou de vos dizer — por escrito, das pessoas que construíram o modelo — que o vosso caso de uso está fora do âmbito previsto.

Isto não significa que o modelo não consiga desempenhar a tarefa. Pode desempenhá-la adequadamente. Mas a documentação de uso indevido do model card significa que os criadores do modelo não testaram nem validaram o modelo para essa aplicação específica. As avaliações de segurança não cobrem o vosso caso de uso. Os benchmarks de desempenho não estão calibrados para o vosso domínio. A responsabilidade, em caso de output nocivo, recai inteiramente sobre vocês — porque o model card declarou explicitamente que o vosso uso não era previsto.

Para conformidade com a Lei da IA da UE, esta documentação é directamente relevante. O Artigo 13 exige transparência sobre a finalidade prevista de um sistema de IA. Se o model card diz que o modelo não é previsto para o vosso caso de uso e vocês o implementam para esse caso de uso, criaram uma lacuna de conformidade que nenhuma quantidade de documentação post-hoc consegue preencher.

O model card avisou-vos. Escolheram não o ler. A consequência é previsível.

O Princípio da Fonte Primária

Leio relatórios do BCE, não o que jornalistas dizem sobre relatórios do BCE. Leio conjuntos de dados do Eurostat, não o que comentadores dizem sobre conjuntos de dados do Eurostat. Leio artigos da Lei da IA da UE, não o que consultorias dizem sobre artigos da Lei da IA da UE.

O model card é a fonte primária para o que um modelo de IA consegue e não consegue fazer. Tudo o resto — o blog post, o relatório de analista, a recomendação do consultor, a opinião rápida no LinkedIn — é comentário. O comentário tem os seus usos. Mas o comentário introduz enviesamento, compressão e agenda. A fonte primária não.

O model card não é perfeito. É escrito pelo laboratório que construiu o modelo, e os laboratórios têm incentivos para apresentar os seus modelos favoravelmente. Mas o model card é restringido pela reprodutibilidade — os benchmarks podem ser verificados de forma independente, as limitações podem ser testadas de forma independente e as avaliações de segurança podem ser replicadas de forma independente. O marketing não é restringido por nenhuma destas.

Quando avalio um modelo de IA para uma implantação da Bluewaves, o model card é o primeiro documento que leio e o último que referencio. Não o primeiro porque é fácil — porque é honesto. Não o último porque é abrangente — porque as decisões que tomamos sobre implantação estão ancoradas no que os criadores realmente sabem sobre o seu modelo, não no que a equipa de marketing deles quer que nós pensemos.

A Implicação Operacional

Para cada implantação de IA na vossa empresa, uma pessoa deve ler o model card. Completamente. Não a passar os olhos. Não o resumo executivo. O documento completo.

Essa pessoa deve traduzir as avaliações técnicas do model card em três documentos operacionais:

Uma avaliação de capacidade que declare, em linguagem simples, o que o modelo consegue e não consegue fazer para o vosso caso de uso específico, com base nos benchmarks e limitações do model card.

Um registo de risco que mapeie as avaliações de segurança e limitações conhecidas do model card para o vosso contexto de implantação específico, identificando que riscos são relevantes, que mitigações são necessárias e que riscos residuais devem ser aceites.

Um plano de monitorização que especifique como vão verificar, em produção, que o desempenho real do modelo corresponde ao desempenho documentado no model card — porque os modelos podem degradar-se, os casos de uso podem derivar e a única verificação das afirmações do model card é a vossa própria observação.

Estes três documentos demoram a uma pessoa aproximadamente quatro horas a produzir. Não custam nada. Previnem as falhas de implantação de IA mais comuns e mais caras: implementar um modelo para um caso de uso para o qual nunca foi desenhado, implementar numa língua onde o desempenho é materialmente inferior e implementar sem um sistema de monitorização que detecte a degradação antes dos utilizadores.

O model card é gratuito. Lê-lo é gratuito. Agir com base nele é gratuito.

O custo de não o ler é a implantação que falha e a equipa que perde confiança em ferramentas de IA porque ninguém leu o documento que teria previsto a falha.

Leiam o model card.

A fonte primária está disponível. A fonte primária é gratuita. A fonte primária contém informação que nenhuma fonte secundária — nenhum blog post, nenhum relatório de analista, nenhuma recomendação de consultor — consegue replicar.

O model card é escrito pelas pessoas que construíram o modelo. Sabem coisas sobre o seu comportamento que mais ninguém sabe. Documentaram essas coisas — honestamente, especificamente, com benchmarks e ressalvas — num documento que é publicamente disponível e sistematicamente ignorado.

A distância entre a página de marketing e o model card é a distância entre o que querem ouvir e o que precisam de saber. O model card é o que precisam de saber.

Leiam-no.