Model cards de IA: buenas prácticas para seguridad

La mejor práctica para las model cards de IA es documentar cinco cosas antes de que un modelo se publique: uso previsto, pruebas de rendimiento, procedencia de los datos de entrenamiento, limitaciones conocidas y consideraciones éticas y de seguridad. Las model cards, presentadas por Mitchell et al. (2019) en Google, son hoy el formato estándar del sector exactamente para esto: un documento breve y estructurado que permite a un revisor decidir si un modelo es seguro para desplegar sin leer el código fuente. Para los equipos de seguridad, una buena model card es la diferencia entre una decisión de riesgo documentada y una caja negra sin auditar en producción.

Qué es una model card (y qué no es)

Una model card es una ficha técnica estandarizada de un modelo entrenado. Responde a «¿qué es esto, para qué se construyó y dónde falla?» de una forma sobre la que puede actuar alguien que no es su autor. No es una data sheet (que documenta el dataset) ni tampoco una system card (que documenta un producto completo como ChatGPT). Las model cards y system cards que OpenAI publicó para GPT-4 son referencias útiles, pero están cerca del marketing: las fichas internas de tus propios modelos deberían ser más directas sobre los modos de fallo.

Como mínimo, una ficha que siga el esquema de Mitchell et al. incluye:

• Detalles del modelo: responsable, versión, fecha, arquitectura, licencia.
• Uso previsto: casos de uso aprobados y usos explícitamente no contemplados.
• Rendimiento: métricas desglosadas por los subgrupos relevantes, no una única cifra agregada.
• Datos de entrenamiento: fuentes, procedencia y carencias conocidas.
• Consideraciones éticas y de seguridad: hallazgos de sesgo, exposición a la inyección de prompts, riesgo de PII.
• Limitaciones: condiciones de fallo documentadas.

Los cinco tipos de modelo que tu ficha debe nombrar

Cuando la gente pregunta por los «5 principales modelos de IA», normalmente se refiere a las grandes familias con las que te encontrarás: modelos lineales/de regresión, árboles de decisión y ensembles (por ejemplo, árboles con gradient boosting), redes neuronales, grandes modelos de lenguaje basados en transformers y modelos generativos/de difusión. Nombra la familia explícitamente en la ficha, porque el perfil de riesgo difiere mucho. Un modelo de fraude con gradient boosting necesita métricas de equidad por subgrupo; un LLM basado en transformers necesita pruebas de inyección de prompts y de jailbreak a las que un modelo basado en árboles nunca se enfrenta. Una ficha que solo dice «modelo de ML» no supera la auditoría porque el revisor no puede asociar controles a amenazas.

La «regla del 30 %» a la que se refiere la gente no es un estándar formal: es una heurística aproximada según la cual alrededor del 30 % de los errores reales de un modelo proceden de la deriva de los datos y de casos límite que el conjunto de entrenamiento nunca cubrió. Tómala como un recordatorio para documentar un desencadenante de monitorización y reentrenamiento en la sección de limitaciones, no como una métrica de la que informar.

Un ejemplo práctico

Esta es una ficha compacta y útil para seguridad de un modelo interno:

• Modelo: loan-risk-scorer v2.3 · árboles con gradient boosting · responsable: equipo de Risk ML · 2025-01
• Uso previsto: ordenar el riesgo de impago de los solicitantes para revisión humana. No contemplado: denegación automatizada sin un humano en el circuito; uso fuera del mercado de EE. UU.
• Rendimiento: AUC de 0,87 global; 0,83 para solicitantes menores de 25 años; 0,71 para solicitantes con poco historial crediticio (marcado como carencia).
• Datos de entrenamiento: registros de préstamos internos de 2019–2024, solo de EE. UU. Sin datos posteriores a 2024; comprobación de deriva obligatoria cada trimestre.
• Seguridad/ética: contiene variables derivadas de PII; acceso restringido según la política de clasificación de datos. Auditoría de sesgo realizada frente a las clases protegidas: consulta el anexo.
• Limitaciones: se degrada ante cambios macroeconómicos (la salvedad de los casos límite de ~30 %); desencadenante de reentrenamiento fijado en una caída del AUC > 0,03.

Fíjate en que cada campo corresponde a una decisión de control. Esa es la idea: quien aprueba lo lee en dos minutos y da el visto bueno o lo bloquea.

Automatización y dónde guardar las fichas

No escribas fichas a mano a escala. Usa un generador de model cards vinculado a tu pipeline de MLOps para que la ficha se produzca en la misma ejecución que entrenó el modelo: el Model Card Toolkit de Google y la plantilla de fichas de Hugging Face lo hacen. En AWS, conoce la distinción que busca la gente: las SageMaker Model Cards documentan modelos que entrenas tú y son artefactos de gobernanza que posees y editas; las AI Service Cards son documentos de transparencia publicados por AWS sobre servicios gestionados como Rekognition, que consultas pero no puedes cambiar. Si construyes sobre un servicio gestionado, cita su AI Service Card en tu propia ficha para que tu decisión de riesgo deje rastro documental.

Buena práctica: versiona la ficha junto al modelo, guárdala en el mismo registro y condiciona el despliegue a una ficha completa. Un campo de «limitaciones» vacío debería hacer fallar tu comprobación de CI, no colarse.

¿Quieres ver dónde las carencias de documentación de tus modelos exponen un riesgo real? El AI Model Risk Scanner gratuito de PlayCISO contrasta una model card con estos campos y señala los controles que faltan antes de que lo haga un auditor.

Preguntas frecuentes

¿Qué es una model card?

Una model card es una ficha técnica estandarizada de un modelo entrenado. Responde a «¿qué es esto, para qué se construyó y dónde falla?» de una forma sobre la que puede actuar alguien que no es su autor. No es una data sheet (que documenta el dataset) ni una system card (que documenta un producto completo como ChatGPT).

¿Qué cinco tipos de modelo debe nombrar una model card?

Cuando la gente pregunta por los «5 principales modelos de IA», normalmente se refiere a las grandes familias con las que te encontrarás: modelos lineales/de regresión, árboles de decisión y ensembles (por ejemplo, árboles con gradient boosting), redes neuronales, grandes modelos de lenguaje basados en transformers y modelos generativos/de difusión.

¿Cómo se automatizan las model cards y dónde deben guardarse?

No escribas fichas a mano a escala. Usa un generador de model cards vinculado a tu pipeline de MLOps para que la ficha se produzca en la misma ejecución que entrenó el modelo: el Model Card Toolkit de Google y la plantilla de fichas de Hugging Face lo hacen.