Model card de IA: de Hugging Face a evidencia legal

Una model card de IA es un documento breve y estructurado que acompaña a un modelo entrenado: para qué sirve, cómo se entrenó y evaluó, dónde falla. Nació en Google entre 2018 y 2019, y Hugging Face la convirtió en el README.md de cada repositorio de modelos. Desde el 2 de agosto de 2025, el Reglamento de IA exige a los proveedores de modelos una documentación parecida a una model card, pero más larga y jurídicamente exigible; desde el 2 de diciembre de 2027, los proveedores de sistemas de alto riesgo deberán presentar un expediente técnico que la ficha apenas inicia. Esta guía lee la model card como lo haría un auditor o una autoridad de vigilancia del mercado: qué contiene, qué omite, qué norma puede exigirla y cómo convertirla en evidencia.

Lo esencial

• Una model card es un formato voluntario con nueve secciones canónicas (Mitchell et al., 2019), no un documento legal.
• La plantilla de Hugging Face es el estándar de hecho, pero cubre cerca de la mitad del anexo XI y del Formulario de documentación del modelo.
• Desde el 2 de agosto de 2025, los proveedores de modelos de uso general documentan el modelo (anexo XI), informan a los proveedores posteriores (anexo XII) y publican un resumen del entrenamiento; el expediente de alto riesgo (anexo IV) llega el 2 de diciembre de 2027.
• La transparencia baja: media de 41 sobre 100 en el Foundation Model Transparency Index de diciembre de 2025 (17 menos que en 2024); en Hugging Face, lo menos cumplimentado es impacto ambiental, limitaciones y evaluación.
• Una model card es evidencia cuando está versionada, firmada por tres roles, escrita con los campos del regulador y vinculada a la ficha del sistema.

¿Qué es una model card?

En enero de 2019, en la conferencia FAT\* de Atlanta, un equipo de Google con Margaret Mitchell y Timnit Gebru presentó «Model Cards for Model Reporting» (arXiv, octubre de 2018): documentos cortos que acompañan a los modelos entrenados e informan de su rendimiento evaluado en distintas condiciones, por ejemplo entre grupos culturales, demográficos o fenotípicos. Dos ejemplos trabajados, un clasificador de sonrisas entrenado con CelebA y el modelo de toxicidad de Perspective API, y tres públicos: desarrolladores, responsables de políticas públicas y personas afectadas por el modelo. Hugging Face llevó la propuesta a la práctica: la model card es el README.md del repositorio, Markdown precedido de un bloque YAML con campos como license, language, datasets, base_model, pipeline_tag, library_name, resultados de evaluación estructurados y emisiones de CO2. La documentación sobre model cards y la plantilla anotada completan el cuadro, y la guía de redacción (Ozoani, Gerchick y Mitchell, 2022) precisa que cumplimentar bien una model card (la «ficha del modelo», si prefiere la traducción) exige tres perfiles: el desarrollador, el «sociotécnico» (jurista, especialista en ética, defensor de derechos) y el organizador del proyecto.

Model card, system card, data card: tres artefactos, tres objetos

La system card describe el producto desplegado: prompts de sistema, barreras de seguridad, herramientas conectadas, evaluaciones de seguridad. La popularizó OpenAI con la System Card de GPT-4 en marzo de 2023 y Anthropic la usa para sus modelos Claude. En agosto de 2025, OpenAI publicó una model card, no una system card, para sus modelos de pesos abiertos gpt-oss, porque lo que se liberaba eran los pesos. La data card, o datasheet, describe el conjunto de datos (Gebru et al., «Datasheets for Datasets», 2018). Regla: un artefacto por objeto; la model card describe los pesos.

Las nueve secciones de una model card y la pregunta que responde cada una

La tabla recoge las nueve secciones de Mitchell, la pregunta que responde cada una y su debilidad más frecuente. <table header-row=»true»> <tr> <td>Sección</td> <td>Pregunta que responde</td> <td>Debilidad típica</td> </tr> <tr> <td>Detalles del modelo</td> <td>¿Quién lo construyó, qué versión, fecha, tipo, licencia, contacto?</td> <td>Sin versión ni fecha</td> </tr> <tr> <td>Uso previsto</td> <td>¿Usos primarios, usuarios primarios, usos fuera de alcance?</td> <td>Marketing; sin usos excluidos</td> </tr> <tr> <td>Factores</td> <td>¿Qué grupos, instrumentos o entornos cambian el rendimiento?</td> <td>Nunca se desagregan</td> </tr> <tr> <td>Métricas</td> <td>¿Qué medidas, qué umbrales, cómo se informa de la variación?</td> <td>Sin umbrales</td> </tr> <tr> <td>Datos de evaluación</td> <td>¿Qué conjuntos, por qué, cómo se preprocesaron?</td> <td>Idénticos a los de entrenamiento</td> </tr> <tr> <td>Datos de entrenamiento</td> <td>¿Con qué aprendió, o por qué no puede revelarse?</td> <td>«Propietarios», sin categorías de procedencia</td> </tr> <tr> <td>Análisis cuantitativos</td> <td>¿Resultados unitarios e interseccionales?</td> <td>Una sola cifra agregada</td> </tr> <tr> <td>Consideraciones éticas</td> <td>¿Datos sensibles, riesgos para la vida humana, mitigaciones?</td> <td>Un descargo de responsabilidad</td> </tr> <tr> <td>Advertencias y recomendaciones</td> <td>¿Qué no cubrió la evaluación?</td> <td>Ausente o copiada</td> </tr> </table> La plantilla de Hugging Face reorganiza las nueve en una estructura más larga: Model Details; Uses (directo, posterior, fuera de alcance); Bias, Risks and Limitations con Recommendations; Training Details; Evaluation (datos de prueba, factores, métricas, resultados); Environmental Impact; Technical Specifications; Citation; Glossary; Authors; Contact; How to Get Started. La guía de redacción aporta tres definiciones que conviene adoptar en los procedimientos internos. Un sesgo es una desviación del rendimiento para determinadas subpoblaciones. Un riesgo es un problema socialmente relevante que el modelo podría causar. Una limitación es un modo de fallo probable, y las recomendaciones existen para tratarlas. Cuando una model card mezcla los tres en un párrafo, el auditor no distingue lo medido de lo temido.

Lo que una model card no es: voluntaria, autodeclarada, desigual

Ninguna ley exige el formato. Nadie lo verifica. Y es el autor quien decide qué medir, con qué datos y qué dejar fuera. La primera es el Foundation Model Transparency Index de diciembre de 2025, tercera edición del índice de Stanford: trece empresas, 100 indicadores, media de 41 puntos sobre 100, 17 por debajo de 2024. IBM alcanza 95; xAI y Midjourney se quedan en 14. La segunda es el análisis de Liang y sus coautores, de febrero de 2024, sobre 32.111 model cards alojadas en Hugging Face. La sección de entrenamiento es la que más se rellena; las menos cumplimentadas son impacto ambiental, limitaciones y evaluación, justamente las que más interesan a un auditor. El estudio añadió fichas detalladas a 42 modelos populares y observó una correlación moderada con el aumento de las descargas semanales. Consecuencia doble para un equipo de gobernanza. La model card que recibe de un proveedor es una afirmación, no una constatación: nadie la ha contrastado y los resultados son los que el autor decidió mostrar (benchmark de IA). La model card que usted publica es una declaración por la que se le pedirán cuentas. Y una ficha describe un modelo en una fecha concreta: seis meses después, con nuevos datos y nuevos usos, lo que describe puede haber dejado de existir (deriva del modelo).

Dónde se cruzan la model card y el Reglamento de IA

El Reglamento (UE) 2024/1689 no menciona la expresión model card, pero dos de sus bloques de obligaciones piden lo que una buena ficha debería contener.

Modelos de IA de uso general: artículo 53, anexo XI y Formulario de documentación del modelo

El artículo 53, apartado 1, se aplica desde el 2 de agosto de 2025 a todo proveedor de un modelo de IA de uso general: (a) documentación técnica (anexo XI como mínimo), actualizada, para la Oficina de IA y las autoridades nacionales; (b) documentación para los proveedores posteriores (anexo XII como mínimo); (c) una política de derechos de autor; (d) un resumen público del contenido de entrenamiento, con la plantilla que la Oficina de IA publicó el 24 de julio de 2025. El apartado 2 exime de (a) y (b) a los modelos libres y de código abierto con parámetros públicos, salvo riesgo sistémico (criterios en modelos de IA de uso general). La sección 1 del anexo XI se lee como una model card ampliada y enumera, en esencia, lo que el Formulario detalla más abajo; la sección 2, para los modelos con riesgo sistémico, añade estrategias y resultados de evaluación, pruebas adversarias y red teaming, y arquitectura del sistema. El Código de buenas prácticas (texto final del 10 de julio de 2025, refrendado por la Comisión y el Consejo de IA el 1 de agosto de 2025) lo traduce en un Formulario de documentación del modelo. Medida 1.1: documentar todos los campos al introducir el modelo en el mercado, actualizarlos y conservar las versiones anteriores diez años. Medida 1.2: publicar un punto de contacto, entregar a los proveedores posteriores sus campos en 14 días y facilitar a la Oficina de IA lo que solicite. Medida 1.3: control de calidad, integridad y protección frente a alteraciones. El Formulario es una model card con una tercera columna: para cada campo, tres casillas indican si la información va a la Oficina de IA, a las autoridades nacionales o, proactivamente, a los proveedores posteriores. Campos: identidad (razón social, fecha de comercialización en la Unión, hash o punto de acceso que acredite la autenticidad, dependencias: de qué modelo se ajustó), propiedades (parámetros con dos cifras significativas para la Oficina y por rangos, de 1 a 500 millones hasta más de un billón, para el resto; tamaños máximos de entrada y salida), uso (usos previstos en unas 200 palabras; tipos de sistemas de IA admitidos y excluidos), entrenamiento (proceso en unas 400 palabras con la justificación de las decisiones; procedencia de los datos por categorías: rastreo web, conjuntos privados de terceros, datos de usuarios, conjuntos públicos, datos sintéticos; medidas contra fuentes inadecuadas, incluido material de abuso sexual infantil e imágenes íntimas no consentidas, y contra sesgos identificables) y recursos (horas de reloj y días de hardware, FLOPs, megavatios hora, cómputo de inferencia medido con un benchmark). Lo que reciben las autoridades queda protegido como secreto comercial (artículo 78).

Sistemas de IA de alto riesgo: anexo IV, artículo 13 y la ficha del responsable del despliegue

El artículo 11 exige, antes de la comercialización, la documentación técnica del anexo IV, en nueve puntos: descripción general (finalidad prevista, proveedor, versiones, hardware, instrucciones de uso); desarrollo (métodos, modelos preentrenados de terceros, arquitectura, datos con su procedencia, etiquetado y limpieza, vigilancia humana, cambios predeterminados, validación con métricas de precisión, solidez e impacto discriminatorio, ciberseguridad); seguimiento y control (rendimiento por grupos, resultados no deseados previsibles, datos de entrada); justificación de las métricas; sistema de gestión de riesgos del artículo 9; cambios del ciclo de vida; normas armonizadas; declaración UE de conformidad; plan de vigilancia poscomercialización del artículo 72. El artículo 18 obliga a conservarla diez años. El artículo 13, apartado 3, describe lo que de hecho es la model card dirigida al responsable del despliegue: las instrucciones de uso: identidad del proveedor, finalidad prevista, precisión con sus métricas, solidez, ciberseguridad, riesgos de uso indebido, rendimiento por grupos, datos de entrada, cambios predeterminados, vigilancia humana, cómputo y hardware, vida útil y mantenimiento, registro de eventos. Las fechas cambiaron con el Ómnibus digital (Reglamento (UE) 2026/1744, Diario Oficial del 24 de julio de 2026, en vigor desde el 27 de julio de 2026): los sistemas autónomos del anexo III quedan sujetos desde el 2 de diciembre de 2027 y los integrados en productos del anexo I desde el 2 de agosto de 2028. Las pymes y ahora las pequeñas empresas de mediana capitalización pueden usar el formulario simplificado de la Comisión: las mismas nueve áreas con menos texto. Los responsables del despliegue (artículo 26) deben seguir las instrucciones y, en los casos del anexo III del sector público y algunos privados, realizar la evaluación de impacto relativa a los derechos fundamentales del artículo 27, que parte de esa ficha. Véase clasificación de alto riesgo, evaluación de la conformidad y documentación del sistema de IA.

Auditoría de brechas: la plantilla de Hugging Face frente a las listas de campos legales

Nuestra lectura, no una correspondencia oficial: la plantilla de Hugging Face frente al anexo IV, el anexo XI y el Formulario. <table header-row=»true»> <tr> <td>Sección de la plantilla</td> <td>Lo que pide el anexo IV, el anexo XI o el Formulario</td> <td>Brecha</td> </tr> <tr> <td>Model Details</td> <td>Razón social, fecha de comercialización en la Unión, hash de autenticidad, dependencias</td> <td>Falta</td> </tr> <tr> <td>Uses</td> <td>Política de uso aceptable; tipos de sistemas de IA admitidos y excluidos (200 a 300 palabras)</td> <td>Parcial</td> </tr> <tr> <td>Bias, Risks and Limitations</td> <td>Medidas para detectar fuentes inadecuadas y sesgos identificables (la plantilla registra resultados; el Formulario pide métodos)</td> <td>Falta</td> </tr> <tr> <td>Training Details</td> <td>Justificación de las decisiones, categorías de procedencia, número de puntos de datos, curación, medidas contra material de abuso infantil</td> <td>Falta</td> </tr> <tr> <td>Evaluation</td> <td>anexo XI sección 2 y anexo IV punto 2(g): estrategias de evaluación, pruebas adversarias, métricas de impacto discriminatorio, umbrales</td> <td>Parcial</td> </tr> <tr> <td>Environmental Impact</td> <td>El campo de CO2 se acerca; el Formulario quiere MWh con dos cifras significativas y la metodología</td> <td>Parcial</td> </tr> <tr> <td>Technical Specifications</td> <td>Parámetros, tamaño máximo de entrada y salida, FLOPs, tiempo de entrenamiento en días de hardware</td> <td>Parcial</td> </tr> <tr> <td>Nada en la plantilla</td> <td>anexo IV puntos 2(e) a 2(h) y 3 a 9: vigilancia humana, cambios predeterminados, ciberseguridad, gestión de riesgos, cambios del ciclo de vida, normas, declaración de conformidad, plan poscomercialización</td> <td>Falta</td> </tr> <tr> <td>Nada en la plantilla</td> <td>Artículo 13(3)(e) y (f): vida útil esperada, mantenimiento, registro de eventos</td> <td>Falta</td> </tr> </table> Balance incómodo: cinco filas faltan por completo y cuatro están a medias. La plantilla sirve para que un desarrollador entienda y reutilice un modelo; la ley, para que una autoridad reconstruya cada decisión. Ahora bien, lo que la plantilla tiene y la ley no pide (cita bibliográfica, glosario, sección «cómo empezar», autores) es justo lo que hace legible una model card. Conserve esas secciones y añada los campos legales debajo, en lugar de sustituir la ficha por un formulario. Una buena model card de IA se lee de corrido; el anexo XI se consulta.

Más allá de la UE: dónde más se espera una model card

Fuera de la UE, la model card aparece, con distinta fuerza vinculante, en:

• Estados Unidos, FDA. El borrador de guía del 7 de enero de 2025 sobre software con IA en dispositivos médicos trae en su apéndice E una model card de ejemplo para usuarios y profesionales sanitarios y en el apéndice F un resumen 510(k) con la ficha cumplimentada; la FDA aclara que no exige model card ni formato alguno, aunque cita estudios según los cuales aumenta la confianza del usuario. Sigue en borrador.
• California, SB 53. La Transparency in Frontier Artificial Intelligence Act, firmada el 29 de septiembre de 2025 y en vigor desde el 1 de enero de 2026, obliga a los desarrolladores de modelos de frontera (más de 10\^26 operaciones de entrenamiento) a publicar, a más tardar al desplegar, un informe de transparencia: fecha de lanzamiento, idiomas y modalidades, usos previstos, restricciones, contacto. Los grandes desarrolladores (más de 500 millones de dólares de ingresos) añaden resúmenes de sus evaluaciones de riesgo catastrófico. Hasta 1 millón de dólares por infracción, impuestos por el fiscal general. El esqueleto es el de una model card (ley de transparencia de IA de California).
• Nueva York, RAISE Act. Firmada el 19 de diciembre de 2025, modificada el 27 de marzo de 2026 y aplicable desde el 1 de enero de 2027: protocolos de seguridad publicados, incidentes notificados en 72 horas, sanciones de hasta 1 millón de dólares y 3 millones en reincidencia (notificación de incidentes de IA).
• NIST AI RMF. El Playbook, voluntario, incluye model cards y system cards entre las prácticas de documentación sugeridas (NIST AI RMF).
• Europa, fuera del Reglamento. La lista de comprobación para auditorías de IA encargada por el Comité Europeo de Protección de Datos (Gemma Galdon Clavell, enero de 2023) abre con una sección «Model Card» cruzada con artículos del RGPD. La AI Impact Assessment 2.0 del Ministerio de Infraestructuras neerlandés (diciembre de 2024) pregunta si existe una model card o documentación equivalente.
• Normas. ISO/IEC 42001 dedica controles de su anexo A a la documentación técnica del sistema de IA, a la documentación e información para los usuarios y a la procedencia de los datos; el auditor de certificación preguntará dónde vive y cómo se actualiza (ISO 42001).
• Cadena de suministro. CycloneDX 1.5, de junio de 2023, añadió una lista de materiales de aprendizaje automático (ML-BOM) con un componente «modelo» cuyos campos reflejan los de una model card: la ficha puede viajar dentro de un SBOM.

En España, la vigilancia del mercado corresponde a la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial) y la AEPD conserva su competencia sobre los datos personales de los conjuntos de entrenamiento. El sandbox impulsado por el Gobierno sirvió para ensayar con proveedores reales las plantillas de documentación técnica: quien ya mantiene sus model cards con los campos del anexo IV llega con los deberes hechos.

Cómo redactar una model card que supere una auditoría: seis pasos

Cada paso termina con el documento que debe quedar archivado.

1. Una model card por versión, inmutable una vez publicada. Cada versión recibe su ficha y un registro de cambios (datos, entrenamiento, evaluación, uso previsto), como piden el punto 6 del anexo IV y la medida 1.1 del Código, que conserva diez años. Documento resultante: el historial de versiones.
2. Escriba primero los campos legales, con el vocabulario del regulador. Razón social, fechas de lanzamiento y de comercialización en la Unión, dependencias, licencia, política de uso aceptable, usos previstos y excluidos, tipos de sistemas de IA admitidos; los nombres de campo del Formulario evitan traducir la ficha cuando llegue la solicitud. Documento resultante: el bloque de información general.
3. Evalúe de forma desagregada e informe de lo que pide el artículo 13. Precisión con métricas y umbrales, solidez, ciberseguridad, rendimiento por grupos; un número agregado no es una evaluación (criterios en benchmark de IA). Documento resultante: el informe de evaluación por grupo.
4. Documente los datos por categoría de procedencia. Rastreo web, conjuntos privados de terceros, datos de usuarios, conjuntos públicos, datos sintéticos, con el número de puntos de datos y las medidas de detección de fuentes inadecuadas y de sesgos. Documento resultante: la ficha de datos, coherente con su inventario de sistemas de IA.
5. Tres firmas, un responsable, una cadencia. Desarrollador, sociotécnico y organizador del proyecto firman; un responsable con nombre responde de la ficha; se revisa en cada versión y, como mínimo, una vez al año. Documento resultante: la hoja de aprobación y el calendario de revisión.
6. Vincule la ficha al expediente del sistema. Entrada del inventario, registro de riesgos, instrucciones de uso, registro de incidentes, contrato con el proveedor. A los proveedores pídales los campos del anexo XII y escriba en el contrato el plazo de 14 días y una actualización trimestral: una guía práctica para abogados propone una cláusula por la que el proveedor entrega model cards con arquitectura, procedencia de los datos, benchmarks de precisión, metodología de pruebas de sesgo y resultados de seguimiento, actualizadas al menos cada trimestre (due diligence de proveedores de IA). Documento resultante: la matriz de vínculos y el anexo contractual.

Seis pasos, seis documentos: el expediente que una autoridad puede pedirle hoy al amparo del artículo 53 y, desde diciembre de 2027, con el anexo IV en la mano.

Las model cards en el expediente del sistema de IA

Una model card habla de un modelo. Un regulador pregunta por un sistema: el que decide sobre personas o figura en el anexo III. El registro une ambas cosas. Cada ficha de sistema de IA enumera sus componentes de modelo; cada componente lleva los campos de su model card y su versión; y cualquier cambio en la ficha reabre la evaluación de riesgos y las instrucciones de uso, porque un modelo distinto es, a efectos legales, un sistema distinto. Esa es la lógica de nuestro registro de sistemas de IA. AI Sigil guarda la model card junto a los controles del marco aplicable, de modo que la respuesta a «muéstreme la documentación de este modelo» sea un informe, no una búsqueda. Empiece por el inventario de sistemas de IA.

Preguntas frecuentes

¿Qué es una model card, explicado de forma sencilla? Es una ficha breve y estructurada que acompaña a un modelo de IA entrenado y responde a nueve preguntas: autor y versión, usos previstos y excluidos, factores que cambian el rendimiento, métricas, datos de evaluación y de entrenamiento, resultados por grupos, riesgos éticos y límites de la evaluación. Piense en el prospecto de un medicamento: no sustituye al ensayo clínico, pero dice lo que hay que saber antes de usarlo. ¿Es obligatoria una model card? El formato, no. Lo obligatorio es lo que la ficha anticipa: desde el 2 de agosto de 2025, la documentación del artículo 53 y el anexo XI para los modelos de uso general; desde el 2 de diciembre de 2027, el expediente del anexo IV para el alto riesgo del anexo III; desde el 1 de enero de 2026, los informes de transparencia de la SB 53 en California (obligaciones de transparencia de IA). ¿Cuál es la diferencia entre una model card y una system card? El objeto. La model card describe los pesos: arquitectura, datos, resultados de evaluación. La system card describe el producto desplegado alrededor del modelo: prompts de sistema, barreras de seguridad, herramientas conectadas, evaluaciones del conjunto. OpenAI popularizó la segunda con la System Card de GPT-4 en marzo de 2023; al liberar los pesos de gpt-oss en agosto de 2025 publicó, con coherencia, una model card. ¿Una model card de Hugging Face cumple con el Reglamento de IA? No. Según nuestra lectura, la plantilla cubre aproximadamente la mitad de los campos del anexo XI y ninguno de los puntos de gobernanza del anexo IV: vigilancia humana, ciberseguridad, gestión de riesgos, declaración de conformidad, vigilancia poscomercialización. Faltan también razón social, fecha de comercialización en la Unión y hash de autenticidad. Completada con esos campos, puede ser la columna vertebral de la documentación del sistema de IA. ¿Quién debe redactar la model card? Tres perfiles, según la guía de Hugging Face: el desarrollador, que conoce arquitectura y datos; el sociotécnico (jurista o especialista en ética), que identifica riesgos; y el organizador del proyecto, que responde por el conjunto. En la empresa: un responsable con nombre y dos revisores. Si la model card la redacta solo el equipo técnico, el uso previsto será marketing; la auditabilidad de la IA empieza por saber quién firmó qué. ¿Con qué frecuencia debe actualizarse una model card? En cada versión del modelo: un cambio en los datos de entrenamiento, en el ajuste fino o en los usos previstos produce una ficha nueva, no una edición de la anterior. El Código de buenas prácticas exige además conservar las versiones previas diez años. Programe como mínimo una revisión anual, porque el contexto de uso cambia aunque el modelo no (gestión del riesgo de modelos).

Conclusión

La model card es el vocabulario más extendido para describir un modelo de IA. Nació para la transparencia, no para el cumplimiento normativo. Eso ha cambiado: el Reglamento de IA ha incorporado a la ley una versión más larga de la ficha para los proveedores de modelos de uso general y hará lo mismo con los proveedores de sistemas de alto riesgo en diciembre de 2027, y California y Nueva York piden informes de transparencia con el mismo esqueleto. El trabajo de un equipo de gobernanza no consiste en sustituir la model card, sino en completarla, versionarla, firmarla y conectarla al sistema al que sirve. AI Sigil guarda la ficha de cada modelo junto a su sistema de IA, sus riesgos y sus controles, de modo que la documentación que pide un regulador ya exista antes de que la pidan.