Que Es un Model Card de IA? Y Por Que la Ley de IA de la UE los Hace Obligatorios

Un model card es un documento estructurado que describe un modelo de IA -- para que fue disenado, como fue entrenado, que datos uso, como se desempena en diferentes grupos y tareas, y cuales son sus limitaciones conocidas.

El concepto fue introducido en un articulo de 2019 por Margaret Mitchell y colegas en Google. En los siete anos desde entonces, los model cards han pasado de ser una propuesta academica a una practica de la industria y, en la UE, un requisito legal. Este articulo explica que contiene un model card, por que importa operacionalmente y que significa el Anexo IV de la Ley de IA de la UE para las organizaciones que despliegan IA en contextos regulados.

Por Que los Model Cards Importan Operacionalmente

El caso de cumplimiento para los model cards es real, pero el caso operacional es mas inmediatamente persuasivo.

El ingeniero de ML que entreno el modelo no estara ahi en 18 meses. El proveedor que suministro el modelo podria no estar ahi en 3 anos. El contexto de negocio en el que se desplego el modelo evolucionara. Cuando algo salga mal -- o cuando alguien necesite auditar, actualizar o reemplazar el modelo -- el conocimiento institucional que existia al momento del entrenamiento se habra ido.

Un model card es la memoria institucional que permite a alguien entender el modelo sin empezar desde cero. Responde las preguntas que una investigacion de incidentes o una auditoria de cumplimiento hara: con que fue entrenado este modelo? Contra que poblacion fue evaluado? Que modos de falla se identificaron? Que sabia el equipo original sobre donde deberia y no deberia usarse este modelo?

Sin un model card, estas preguntas se responden mediante reconstruccion -- lo cual toma tiempo, es incompleto y puede ser imposible si el equipo original ya no esta disponible. Con un model card, se responden en minutos.

Que Debe Contener un Model Card

1. Detalles del Modelo

Nombre, version, tipo de modelo (clasificacion, regresion, generativo, etc.), equipo u organizacion propietaria, fecha de entrenamiento, fecha de ultima actualizacion, licencia, informacion de contacto del equipo responsable.

Esta es la informacion de encabezado que permite a alguien identificar que esta viendo y a quien llamar.

2. Uso Previsto

Para que fue disenado el modelo. Para que explicitamente no fue disenado. Quienes son los usuarios previstos. Para que contextos de despliegue fue disenado el modelo.

La seccion "no fue disenado para" es tan importante como el uso previsto. Un modelo disenado para asistir a agentes de servicio al cliente no esta disenado para tomar decisiones autonomas. Un modelo entrenado con entradas en ingles no esta disenado para despliegue multilingue. Documentar exclusiones explicitas reduce la probabilidad de despliegue inapropiado.

3. Datos de Entrenamiento

Datasets fuente, rango de fechas cubierto, pasos de preprocesamiento y limpieza aplicados, sesgos o brechas conocidas en los datos de entrenamiento, tamano total del conjunto de entrenamiento.

Esta seccion es la base para cualquier analisis posterior de por que el modelo se comporta como lo hace. Si el modelo exhibe sesgo, la investigacion comenzara aqui. Si el modelo se desempena mal en una poblacion especifica, la seccion de datos de entrenamiento mostrara si esa poblacion estuvo representada.

4. Datos de Evaluacion

Que datasets se usaron para evaluar el modelo. Como se recolectaron los datos de evaluacion y como difieren de los datos de entrenamiento. La justificacion para usar estos conjuntos de evaluacion especificos.

Los datos de evaluacion y los datos de entrenamiento no deben ser identicos -- un modelo evaluado solo en su distribucion de entrenamiento dice muy poco sobre como se desempenara en produccion. Documenta la diferencia.

5. Metricas de Rendimiento

Precision, recall, F1, AUC, o cualquier metrica relevante para la tarea del modelo. Estas deben reportarse sobre el conjunto de evaluacion, no sobre el conjunto de entrenamiento.

Criticamente: las metricas de rendimiento deben desglosarse por grupo demografico, region geografica u otros segmentos relevantes para el caso de uso. Un modelo con 94% de precision agregada puede tener 82% de precision para un grupo demografico especifico. Las metricas agregadas solas no son suficientes para ningun modelo que tome decisiones que afecten a personas.

6. Limitaciones Conocidas

Que tipos de entradas el modelo maneja mal. Que errores tiende a cometer. Que condiciones causan degradacion del rendimiento. En que no fue probado el modelo.

Esta es la seccion mas comunmente sub-escrita en la practica -- las organizaciones son reacias a documentar limitaciones de una manera que podria usarse en su contra. Este razonamiento es erroneo. Las limitaciones documentadas permiten a los implementadores disenar supervision humana apropiada. Las limitaciones no documentadas se descubren a traves de fallas en produccion. El riesgo de litigio es sustancialmente mayor en el segundo caso.

7. Consideraciones Eticas

Danos potenciales por errores o mal uso del modelo. Medidas de mitigacion implementadas. Grupos que pueden verse desproporcionadamente afectados por errores del modelo. A quien se consulto -- interna y externamente -- en el desarrollo del modelo.

8. Advertencias y Recomendaciones

Que deben saber los implementadores antes de desplegar el modelo. Supervision humana requerida. Condiciones ambientales requeridas para que el rendimiento se mantenga. Practicas de monitoreo recomendadas.

Anexo IV de la Ley de IA de la UE: De Mejor Practica a Requisito Legal

Para sistemas de IA de alto riesgo bajo la Ley de IA de la UE -- lo cual incluye IA usada en empleo, credito, educacion, aplicacion de la ley, migracion y otros dominios especificados -- el Anexo IV especifica un requisito de documentacion tecnica obligatorio. El requisito de 11 elementos cubre:

Descripcion general del sistema de IA
Descripcion de los componentes del sistema y proceso de desarrollo
Informacion detallada sobre los datos de entrenamiento
Descripcion de las medidas de supervision humana
Descripcion de las capacidades y limitaciones del sistema
Descripcion de los procesos de gestion de riesgos
Descripcion de los cambios realizados a lo largo del ciclo de vida
Estandares aplicados
Declaracion de conformidad de la UE
Informacion para el implementador
Descripcion del sistema de monitoreo post-mercado

Los elementos 1 a 6 se mapean directamente a campos del model card. Para sistemas de alto riesgo, el model card no es un artefacto de mejores practicas -- es un documento legal. Un model card incompleto significa un sistema no conforme.

Articulo 13 de la Ley de IA de la UE: Obligaciones de Transparencia

El Articulo 13 requiere que los sistemas de IA de alto riesgo sean suficientemente transparentes para que los implementadores y usuarios puedan entender las capacidades y limitaciones del sistema. Esto incluye:

Informacion sobre el proposito previsto del sistema
El nivel de precision, robustez y ciberseguridad alcanzado
Cualquier circunstancia conocida o previsible que pueda afectar la precision y el rendimiento
Medidas apropiadas de supervision humana

Un operador no puede proporcionar esta informacion a los implementadores si el operador no la tiene. La transparencia del Articulo 13 requiere, como prerequisito, que el operador haya documentado esta informacion en primer lugar. El model card es esa documentacion.

Model Cards para Modelos Fine-Tuned

Cuando haces fine-tuning de un modelo base, necesitas un model card para la version fine-tuned. Un enlace al model card del modelo base no es suficiente.

El model card del modelo fine-tuned debe documentar:

Que contenia el dataset de fine-tuning y para que estaba destinado a entrenar
Que capacidad cambio como resultado del fine-tuning y cual era la intencion
Como cambio el rendimiento en los benchmarks del modelo base -- incluyendo benchmarks que el fine-tuning no apunto. El fine-tuning en un dominio especifico puede degradar el rendimiento en tareas generales.
Que evaluacion se ejecuto en la version fine-tuned especificamente

Esto importa porque el modelo fine-tuned es un modelo diferente del base. Su comportamiento es el resultado del entrenamiento base y el fine-tuning combinados. Documentar solo las caracteristicas del modelo base deja las contribuciones del fine-tuning -- y sus limitaciones introducidas -- sin documentar.

La Conexion con la Pista de Auditoria

Un model card es un documento de un punto en el tiempo. Describe el modelo tal como existia cuando se escribio la tarjeta. Los modelos cambian: se reentrenan, actualizan, ajustan y a veces revierten. Un model card que describia con precision la version 1.0 puede ser enganoso para la version 1.3.

El model card necesita mantenerse junto con el modelo. Para organizaciones que gestionan multiples versiones de modelos, esto significa un proceso de model card versionado: cada version del modelo tiene una version correspondiente del model card, y el historial de cambios se rastrea.

El inventario de modelos -- un registro de todos los modelos de IA desplegados en la organizacion, sus versiones y su estado operativo -- es la infraestructura que hace esto manejable. El model card es la documentacion por modelo; el inventario es la vista a nivel organizacional.

Linaje de Datos como Fundamento para Model Cards

Las secciones "Datos de entrenamiento" y "Datos de evaluacion" de un model card son tan precisas como la documentacion de tu pipeline de datos. Si no puedes rastrear que datos entraron en un modelo -- cuales fueron sus fuentes, que preprocesamiento se aplico, que se excluyo y por que -- no puedes escribir un model card preciso.

Las organizaciones que procesan datos de entrenamiento a traves de un pipeline estructurado con transformaciones registradas, IDs de operador y marcas de tiempo tienen esta documentacion automaticamente. El registro de linaje de datos es la fuente de verdad para la seccion de datos de entrenamiento del model card. Las organizaciones que ensamblan datos de entrenamiento de manera informal -- descargando archivos, ejecutando scripts sin registro, aplicando transformaciones en notebooks -- tipicamente no pueden reconstruir una narrativa precisa de datos de entrenamiento.

Este es uno de los argumentos practicos a favor de infraestructura de datos estructurada antes del entrenamiento del modelo, no despues. Para cuando necesitas el model card, la documentacion de datos de entrenamiento existe o no existe.

Para un contexto mas amplio de gobernanza, consulta Gobernanza de Modelos de IA en Produccion. Para la infraestructura de pista de auditoria que sustenta el linaje de datos del model card, consulta Pistas de Auditoria de IA Empresarial: Que Registrar. Para los requisitos de sistemas de alto riesgo de la Ley de IA de la UE en detalle, consulta Requisitos de Sistemas de Alto Riesgo de la Ley de IA de la UE.

Agenda una llamada de descubrimiento con Ertas