La ficha técnica del modelo que nadie lee

Anthropic publica una ficha técnica (model card) por cada versión de Claude. OpenAI publica una system card por cada versión de GPT. Google DeepMind publica informes técnicos para Gemini. Meta publica model cards para Llama. Mistral las publica para sus modelos. Son los documentos fuente primarios — escritos por las personas que construyeron los modelos — que describen exactamente lo que el modelo puede hacer, lo que no puede hacer, dónde falla y en qué condiciones no se debe confiar en sus resultados.

Casi nadie las lee.

La página de marketing recibe millones de visitas. La ficha técnica del modelo recibe miles. La entrada de blog anunciando el modelo se comparte en cada newsletter de IA y feed de LinkedIn. La ficha técnica — el documento que realmente te dice si este modelo es adecuado para tu caso de uso — se queda tranquilamente en un sitio de documentación, sin leer, sin citar, sin usar.

Es un problema. Concretamente, es el tipo de problema que cuesta dinero a las empresas, produce despliegues deficientes y erosiona la confianza en las herramientas de IA — todo porque el documento más importante que se distribuye con cada modelo se trata como un apéndice técnico en lugar de un manual operativo.

Qué contiene realmente una ficha técnica del modelo

El término “model card” proviene de un artículo de 2019 de Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji y Timnit Gebru. El artículo propuso un marco estandarizado de documentación para modelos de aprendizaje automático — análogo a una etiqueta nutricional para alimentos o una ficha de datos de seguridad para productos químicos.

El marco original especificaba: detalles del modelo, uso previsto, factores (demográficos o contextuales relevantes), métricas, datos de evaluación, datos de entrenamiento, análisis cuantitativos, consideraciones éticas, y advertencias y recomendaciones.

En la práctica, las fichas técnicas de los principales laboratorios de IA han evolucionado más allá de esta plantilla, pero el propósito central permanece: documentación honesta de las capacidades, limitaciones y casos de uso apropiados de un modelo, escrita por las personas que mejor lo conocen.

Las fichas técnicas de Claude de Anthropic, por ejemplo, contienen:

Evaluaciones de capacidad con benchmarks específicos. No “Claude es bueno en razonamiento” sino “Claude logra un X % en el benchmark MMLU, un Y % en HumanEval, un Z % en MATH”. Estos números son comparables entre modelos. Te dicen, específicamente, cómo rinde el modelo en pruebas estandarizadas de conocimiento, capacidad de programación y razonamiento matemático.

Limitaciones conocidas documentadas explícitamente. La ficha técnica declara dónde falla el modelo. Dónde alucina. Dónde no se debe confiar en sus resultados sin verificación humana. Esta información no está enterrada en descargos de responsabilidad — se presenta en primer plano como orientación operativa.

Evaluaciones de seguridad. Cómo se probó el modelo para outputs dañinos, sesgo y potencial de uso indebido. Qué mitigaciones se aplicaron. Qué riesgos residuales permanecen. Es la evaluación más honesta del perfil de seguridad de un modelo disponible en cualquier lugar — más honesta que un blog de marketing, más específica que el resumen de un periodista.

Casos de uso previstos y potencial de uso indebido. Para qué fue diseñado el modelo, para qué no fue diseñado, y qué usos los desarrolladores desaconsejan específicamente. Para una pyme que evalúa si desplegar este modelo para una tarea específica, esta sección es la pieza de orientación más valiosa que existe.

Las system cards de OpenAI proporcionan información equivalente en un formato diferente, con particular profundidad en su metodología de evaluación de seguridad — resultados de red-teaming, pipelines de evaluación automatizada y las categorías específicas de riesgo que prueban.

Estos documentos no son materiales de marketing. Son divulgaciones técnicas. Son lo más parecido que produce la industria de la IA a una autoevaluación honesta. Y se ignoran.

Por qué nadie las lee

Tres razones, todas estructurales.

Los documentos están escritos para investigadores, no para operadores. Las fichas técnicas usan el lenguaje de la investigación en aprendizaje automático: nombres de benchmarks, metodologías de evaluación, medidas estadísticas. Un director de compras que evalúa si desplegar Claude para clasificación de consultas de clientes no sabe qué significa MMLU, no tiene una referencia para interpretar una puntuación de HumanEval, y no sabe cómo traducir una evaluación de seguridad en una evaluación de riesgos operativos. La información es valiosa. La capa de traducción no existe.

El marketing es más fácil de consumir. Un artículo de blog anunciando un nuevo modelo son 1 500 palabras de prosa accesible con afirmaciones claras: “más rápido”, “más preciso”, “mejor programando”. La ficha técnica del modelo son 15 000 palabras de documentación técnica con matices, limitaciones y declaraciones condicionales. El blog confirma lo que quieres oír. La ficha técnica te dice lo que necesitas oír. Son públicos diferentes, y el marketing siempre gana la competición por la atención.

El trabajo de nadie incluye leer fichas técnicas de modelos. En una empresa de 200 personas que evalúa un despliegue de IA, nadie es responsable de leer la ficha técnica. El CTO puede tener la formación técnica pero no tiene el tiempo. El jefe de proyecto tiene el tiempo pero no la formación técnica. El consultor externo tiene una recomendación de modelo lista antes de que la ficha técnica se haya descargado. La ficha técnica cae en un vacío de responsabilidad — demasiado técnica para el decisor de negocio, demasiado operativa para el equipo de investigación, demasiado detallada para el calendario del consultor.

Lo que una ficha técnica te dice que nada más te dice

Voy a demostrarlo con un ejemplo específico. Recorreré tres categorías de información de las fichas técnicas que afectan directamente a si una pyme de la UE debe desplegar un modelo específico para un caso de uso específico.

Categoría 1: Variación del rendimiento por idioma

Las fichas técnicas incluyen benchmarks multilingües de rendimiento. Estos benchmarks revelan brechas de rendimiento entre idiomas que los materiales de marketing nunca mencionan.

Un modelo que puntúa un 89 % en comprensión en inglés puede puntuar un 72 % en alemán y un 58 % en portugués. La página de marketing dice “soporta más de 95 idiomas”. La ficha técnica te muestra el gradiente real de rendimiento — y para una pyme de la UE que opera en múltiples mercados, la diferencia entre 89 % y 58 % es la diferencia entre una herramienta útil y un pasivo.

Cuando un cliente portugués envía una consulta y la precisión de comprensión del modelo es 31 puntos porcentuales menor que para una consulta en inglés, la calidad del output se degrada. El cliente recibe una respuesta menos precisa. Si la respuesta implica una recomendación, una clasificación o una decisión, la brecha de precisión se convierte en una brecha de calidad, una brecha de equidad y potencialmente una brecha legal bajo el Artículo 22 del RGPD.

La ficha técnica te dice esto. El blog no.

Categoría 2: Tasas de alucinación por dominio

Las fichas técnicas reportan cada vez más tasas de alucinación — la frecuencia con que el modelo genera información que suena plausible pero es factualmente incorrecta. Estas tasas varían drásticamente por dominio.

Un modelo puede alucinar al 2 % en preguntas de conocimiento general y al 12 % en preguntas técnicas específicas del dominio. Para una pyme que despliega el modelo para responder consultas de clientes sobre una línea de productos especializada, la tasa de alucinación relevante es la específica del dominio, no el número de titular.

Más críticamente, las fichas técnicas describen los tipos de alucinaciones a los que el modelo es propenso. Algunos modelos alucinan detalles específicos (fechas, números, nombres) mientras aciertan la dirección general. Otros alucinan cadenas causales enteras — produciendo explicaciones que suenan autoritativas y son completamente fabricadas. El tipo de alucinación determina el tipo de supervisión humana requerida.

Un modelo que a veces se equivoca en fechas necesita una capa de verificación de hechos. Un modelo que fabrica explicaciones necesita un revisor experto en el dominio. La respuesta operativa es diferente. La ficha técnica te dice cuál es la necesaria.

Categoría 3: Resultados de evaluación de seguridad

Las fichas técnicas de laboratorios responsables incluyen resultados de red-teaming — los resultados de intentos sistemáticos de hacer que el modelo produzca outputs dañinos, sesgados o inapropiados.

Para una pyme de la UE, las consideraciones de seguridad relevantes son específicas: si el modelo genera outputs sesgados que puedan afectar a decisiones de empleo (relevante bajo el Artículo 22 del RGPD y el Artículo 6 de la Ley de IA de la UE), si produce contenido discriminatorio en aplicaciones de cara al cliente, y si filtra datos de entrenamiento que incluyan información personal.

La ficha técnica aborda estas preguntas con resultados de prueba específicos. No “probamos el sesgo” sino “probamos el sesgo demográfico en X categorías usando la metodología Y, y observamos un patrón Z de sesgo residual en las siguientes condiciones”.

Esta información es esencial para la evaluación de conformidad requerida por la Ley de IA de la UE para sistemas de IA de alto riesgo. El Artículo 9 requiere un sistema de gestión de riesgos que incluya la identificación y análisis de riesgos conocidos y previsibles. La ficha técnica del modelo es la fuente principal para riesgos conocidos. Ignorarla no es solo operativamente imprudente — puede ser legalmente insuficiente.

Cómo leer una ficha técnica del modelo

Para una pyme que evalúa un despliegue de IA, este es el enfoque operativo para leer una ficha técnica del modelo. Lleva aproximadamente dos horas, lo cual es menos que la reunión media de comité de dirección y produce información más útil.

Paso 1: Lee primero la sección de uso previsto. ¿Coincide el uso previsto con tu caso de uso? Si la ficha técnica dice que el modelo está “diseñado para asistencia conversacional y generación de contenido” y tú quieres usarlo para calificación crediticia automatizada, hay un desajuste. El desajuste no significa que el modelo no pueda hacerlo. Significa que los desarrolladores no lo han probado para ese fin, lo que significa que la responsabilidad de probarlo recae en ti.

Paso 2: Comprueba los benchmarks multilingües. Encuentra los números de rendimiento para cada idioma que tu despliegue usará. Si la brecha de rendimiento entre tu idioma principal y los idiomas secundarios supera los 10 puntos porcentuales, planifica una capa de aseguramiento de calidad en los idiomas de menor rendimiento.

Paso 3: Lee la sección de limitaciones completamente. Es la sección más valiosa. Los desarrolladores te están diciendo dónde falla su modelo. Lo saben porque lo probaron. Ignorar esta sección es el equivalente en IA de ignorar el informe del ingeniero de estructuras antes de construir en un terreno. La información está ahí. Las consecuencias de ignorarla son predecibles.

Paso 4: Revisa la evaluación de seguridad. Identifica las categorías de output dañino que se probaron y los riesgos residuales que permanecen. Vincúlalas a tu caso de uso. Si tu despliegue involucra poblaciones vulnerables (clientes que solicitan productos financieros, candidatos a empleo, pacientes), la evaluación de seguridad no es lectura complementaria. Es un requisito de cumplimiento.

Paso 5: Compara entre modelos. Las fichas técnicas son comparables. Los mismos benchmarks, las mismas categorías, las mismas metodologías de evaluación aparecen en las fichas de diferentes laboratorios. Lee tres fichas técnicas de modelos competidores y las diferencias de rendimiento — incluyendo las no obvias enterradas en los apéndices — se vuelven claras.

Categoría 4: Documentación de uso apropiado y uso indebido

Las fichas técnicas incluyen cada vez más listas explícitas de casos de uso previstos y escenarios de uso indebido documentados. Estas listas no son hipotéticas. Proceden del comportamiento observado de usuarios durante las pruebas y el despliegue.

Para una pyme que despliega un modelo de lenguaje para aplicaciones de cara al cliente, la documentación de uso indebido es operativamente crítica. La ficha técnica puede especificar: “Este modelo no está diseñado para diagnóstico médico, asesoramiento jurídico ni recomendaciones financieras”. Si tu despliegue usa el modelo para generar recomendaciones de productos financieros, la ficha técnica acaba de decirte — por escrito, de las personas que construyeron el modelo — que tu caso de uso está fuera del alcance previsto.

Esto no significa que el modelo no pueda realizar la tarea. Puede realizarla adecuadamente. Pero la documentación de uso indebido de la ficha técnica significa que los desarrolladores del modelo no han probado ni validado el modelo para esa aplicación específica. Las evaluaciones de seguridad no cubren tu caso de uso. Los benchmarks de rendimiento no están calibrados para tu dominio. La responsabilidad, en caso de un output dañino, recae enteramente en ti — porque la ficha técnica declaró explícitamente que tu uso no estaba previsto.

Para el cumplimiento de la Ley de IA de la UE, esta documentación es directamente relevante. El Artículo 13 requiere transparencia sobre el propósito previsto de un sistema de IA. Si la ficha técnica dice que el modelo no está previsto para tu caso de uso, y lo despliegas para ese caso, has creado una brecha de cumplimiento que ninguna documentación retrospectiva puede llenar.

La ficha técnica te lo dijo. Elegiste no leerla. La consecuencia es previsible.

El principio de la fuente primaria

Leo los informes del BCE, no lo que los periodistas dicen sobre los informes del BCE. Leo los conjuntos de datos de Eurostat, no lo que los comentaristas dicen sobre los conjuntos de datos de Eurostat. Leo los artículos de la Ley de IA de la UE, no lo que las consultoras dicen sobre los artículos de la Ley de IA de la UE.

La ficha técnica del modelo es la fuente primaria de lo que un modelo de IA puede y no puede hacer. Todo lo demás — el blog, el informe del analista, la recomendación del consultor, la opinión rápida de LinkedIn — es comentario. El comentario tiene sus usos. Pero el comentario introduce sesgo, compresión y agenda. La fuente primaria no.

La ficha técnica no es perfecta. Está escrita por el laboratorio que construyó el modelo, y los laboratorios tienen incentivos para presentar sus modelos favorablemente. Pero la ficha técnica está restringida por la reproducibilidad — los benchmarks pueden verificarse de forma independiente, las limitaciones pueden probarse de forma independiente y las evaluaciones de seguridad pueden replicarse de forma independiente. El marketing no está restringido por ninguna de estas.

Cuando evalúo un modelo de IA para un despliegue de Bluewaves, la ficha técnica es el primer documento que leo y el último que consulto. No el primero porque sea fácil — porque es honesto. No el último porque sea exhaustivo — porque las decisiones que tomamos sobre despliegue se anclan en lo que los desarrolladores realmente saben sobre su modelo, no en lo que su equipo de marketing quiere que creamos.

La implicación operativa

Para cada despliegue de IA en tu empresa, una persona debe leer la ficha técnica del modelo. Completamente. Sin ojear. No el resumen ejecutivo. El documento completo.

Esa persona debe traducir las evaluaciones técnicas de la ficha en tres documentos operativos:

Una evaluación de capacidades que declare, en lenguaje llano, lo que el modelo puede y no puede hacer para tu caso de uso específico, basada en los benchmarks y limitaciones de la ficha técnica.

Un registro de riesgos que vincule las evaluaciones de seguridad y limitaciones conocidas de la ficha técnica con tu contexto de despliegue específico, identificando qué riesgos son relevantes, qué mitigaciones se necesitan y qué riesgos residuales deben aceptarse.

Un plan de monitorización que especifique cómo verificarás, en producción, que el rendimiento real del modelo coincide con el rendimiento documentado en la ficha — porque los modelos pueden degradarse, los casos de uso pueden desviarse, y la única comprobación de las afirmaciones de la ficha técnica es tu propia observación.

Estos tres documentos le llevan a una persona aproximadamente cuatro horas en producir. No cuestan nada. Previenen los fallos más comunes y más costosos del despliegue de IA: desplegar un modelo para un caso de uso para el que nunca fue diseñado, desplegar en un idioma donde el rendimiento es materialmente inferior, y desplegar sin un sistema de monitorización que detecte la degradación antes que los usuarios.

La ficha técnica del modelo es gratuita. Leerla es gratuito. Actuar en consecuencia es gratuito.

El coste de no leerla es el despliegue que falla y el equipo que pierde la confianza en las herramientas de IA porque nadie leyó el documento que habría predicho el fallo.

Lee la ficha técnica del modelo.

La fuente primaria está disponible. La fuente primaria es gratuita. La fuente primaria contiene información que ninguna fuente secundaria — ningún blog, ningún informe de analista, ninguna recomendación de consultor — puede replicar.

La ficha técnica del modelo la escriben las personas que construyeron el modelo. Saben cosas sobre su comportamiento que nadie más sabe. Las documentaron — honestamente, específicamente, con benchmarks y matices — en un documento que está públicamente disponible y es sistemáticamente ignorado.

La brecha entre la página de marketing y la ficha técnica del modelo es la brecha entre lo que quieres oír y lo que necesitas saber. La ficha técnica es lo que necesitas saber.

Léela.