Fichas de modelo para LLM: qué cubren y cuáles son sus limitaciones

Una ficha de modelo es un documento breve y estructurado que describe qué es un modelo, para qué se ha creado, cómo se ha evaluado y dónde no debe utilizarse. En el caso de los grandes modelos de lenguaje (LLM), una ficha útil abarca el uso previsto, la procedencia de los datos de entrenamiento, los resultados de evaluación, las limitaciones conocidas y las pruebas de seguridad. Documenta el modelo. No documenta el agente conversacional que su empresa desarrolla sobre ese modelo, y en esa laguna se concentra la mayor parte del riesgo de incumplimiento.

Esta guía explica qué debe incluir una ficha de modelo para un LLM, cómo interpretar ejemplos publicados, qué añade el EU AI Act y qué utilizar cuando una ficha no basta.

En resumen

• Una ficha de modelo describe el uso previsto, los datos, la evaluación y las limitaciones de un modelo. El formato se propuso en el artículo de 2019 «Fichas de modelo para la documentación de modelos», de Mitchell et al.
• Para los modelos de IA de uso general comercializados en la UE, el Reglamento de IA convierte la documentación del modelo de buena práctica en obligación legal para el proveedor.
• Una ficha describe un modelo en pruebas controladas. No muestra cómo se comporta un agente desplegado con clientes reales, incluidos la derivación, la información al usuario y la seguridad.
• Trate la documentación del modelo como un registro vivo con control de versiones y compleméntela con evidencias independientes procedentes de conversaciones reales.

Índice

• Qué es una ficha de modelo y quién la lee
• Qué debe contener una ficha de modelo para un LLM
• Cómo interpretar ejemplos de fichas de modelo
• Qué cambia con el EU AI Act
• Por qué una ficha de modelo no basta para un agente de IA
• De las fichas de modelo a las fichas de auditoría
• IA conversacional explicable: fichas frente a diálogo
• Nuestra perspectiva
• Una lista de comprobación práctica para su expediente de gobernanza
• Qué papel desempeña Lexic
• Preguntas frecuentes
• Fuentes

Qué es una ficha de modelo y quién la lee

Las fichas de modelo se propusieron como una forma de informar sobre el rendimiento de un modelo en distintas condiciones y grupos, y de especificar su contexto de uso previsto. La idea se inspira en las etiquetas nutricionales: un formato estándar que permite a los lectores comparar y decidir.

Los lectores son distintos, y ese es el primer problema de diseño:

• Los ingenieros necesitan conocer la arquitectura, la longitud de contexto, el enfoque de entrenamiento, los resultados de las pruebas de referencia y las condiciones de licencia.
• Los equipos jurídicos y de cumplimiento necesitan conocer la procedencia de los datos, la clasificación del riesgo, las pruebas de seguridad y las evidencias de que el documento está actualizado.
• Los responsables empresariales necesitan una respuesta en lenguaje claro a una pregunta: ¿es adecuado este modelo para este uso?

Una investigación del Aspen Institute sostiene que las fichas de modelo centradas en los ingenieros resultan demasiado complejas para los públicos del ámbito de las políticas públicas y la empresa, y que las fichas destinadas a responsables de políticas públicas deberían sintetizar los metadatos técnicos en un lenguaje claro. Si sus directivos no pueden comprender la ficha en la que se apoya su equipo, esta no cumple su función de gobernanza.

Qué debe contener una ficha de modelo para un LLM

La plantilla original se redactó pensando en los clasificadores. Los LLM necesitan más, porque son de uso general y sus respuestas no se limitan a categorías predefinidas. Una ficha fiable abarca lo siguiente.

Identidad y uso previsto

Nombre del modelo, versión, desarrollador, fecha de publicación y licencia. A continuación, los usos previstos y los que quedan fuera de su ámbito. «Atención al cliente» no es un ámbito preciso. «Redacción de respuestas revisadas por un agente humano» sí lo es.

Datos de entrenamiento y procedencia

Qué categorías de datos se utilizaron, cómo se recopilaron, cómo se filtraron y qué se sabe de sus lagunas. Muchas fichas publicadas ofrecen poca información en este apartado, lo que limita aquello que un usuario posterior puede verificar.

Arquitectura y método de entrenamiento

Familia del modelo, número de parámetros cuando se divulga, ventana de contexto y métodos de ajuste fino y alineación. Estos detalles son importantes al comparar proveedores o explicar un modelo a un regulador.

Resultados de evaluación

Pruebas de referencia, condiciones en las que se realizaron y subgrupos o idiomas evaluados. Una única puntuación destacada aporta poca información. Busque resultados desglosados por tarea, idioma y categoría de riesgo.

Pruebas de seguridad y limitaciones conocidas

Resultados de pruebas de ataque adversario, comportamiento de rechazo, modos de fallo conocidos, como la invención de hechos, y riesgos residuales. Una ficha que no enumera limitaciones es una señal de alerta.

Datos operativos

Hardware utilizado, consumo energético, frecuencia de actualización y contacto para notificar problemas. Según las normas de la UE que se explican más adelante, algunos de estos datos son obligatorios para determinados proveedores.

Cómo interpretar ejemplos de fichas de modelo

Quienes buscan ejemplos de fichas de modelo suelen querer una plantilla que copiar o una ficha publicada que estudiar. Ambas opciones existen y cumplen funciones distintas.

Fichas publicadas por los desarrolladores de modelos. Los principales desarrolladores publican fichas o documentos del sistema con cada modelo. Lea varias en paralelo y compare qué divulga cada una: detalle de los datos de entrenamiento, amplitud de la evaluación, pruebas de seguridad y limitaciones declaradas. Las diferencias de profundidad son informativas por sí mismas.

Plantillas abiertas para uso interno. El NIST AI RMF Cookbook en GitHub incluye un directorio de fichas de modelo con más de 130 fichas de los principales proveedores, y la versión publicada en Zenodo describe esquemas YAML para fichas de modelo, fichas de datos, evaluaciones de riesgos y correspondencias entre controles. La versión está marcada como alfa y es un proyecto comunitario, no una publicación oficial del NIST, por lo que debe tratarse como una estructura inicial que adaptar, no como una fuente de autoridad.

Al revisar cualquier ejemplo, plantee cinco preguntas:

1. ¿Indica para qué no debe utilizarse el modelo?
2. ¿Permite saber de qué categorías de datos aprendió el modelo?
3. ¿Describe las condiciones de evaluación con suficiente detalle para reproducirlas?
4. ¿Las limitaciones son específicas o genéricas?
5. ¿Incluye una versión y una fecha que permitan saber si la ficha sigue correspondiendo al modelo?

Las plantillas que normalizan la documentación también ayudan a los equipos de gobernanza, y los marcos estructurados para hacer que la documentación técnica sea útil para responsables de decisiones sin perfil técnico pueden facilitar la adaptación de la información entre ingeniería y negocio.

Qué cambia con el EU AI Act

Para las empresas que comercializan o despliegan modelos en Europa, la documentación ya no es opcional para una amplia categoría de modelos. Los proveedores de modelos de IA de uso general (GPAI) deben mantener documentación técnica que abarque la arquitectura, los métodos de entrenamiento, la procedencia de los datos, el consumo energético y los resultados de evaluación, como resume el marco COMPEL. La misma fuente señala que los modelos clasificados como modelos con riesgo sistémico están sujetos a requisitos adicionales, incluidas las pruebas adversarias. Añade que el formato habitual de ficha de modelo es un punto de partida útil, pero debe ampliarse para cubrir todo lo que exige el anexo del Reglamento.

Un resumen de un despacho de abogados sobre las obligaciones de los proveedores de GPAI describe cómo el Reglamento define estos modelos por su carácter general y su capacidad para integrarse en numerosos sistemas posteriores. Para una explicación en lenguaje claro de quién debe cumplirlo, consulte este resumen de lo que exige el EU AI Act.

Dos puntos prácticos para las empresas estadounidenses que acceden al mercado europeo:

• El proveedor del modelo asume las obligaciones relativas al modelo. Usted puede seguir asumiendo las relativas al despliegue. Si desarrolla un agente orientado al cliente sobre un LLM de terceros, la documentación del proveedor no le exime de sus propias obligaciones, como informar a las personas de que están hablando con una IA. Confirme su función con su asesoría jurídica.
• «Actualizada» forma parte del requisito. Las orientaciones de COMPEL recomiendan tratar la documentación como un elemento vivo con control de versiones y capturar automáticamente metadatos, como los hiperparámetros y el consumo energético, desde los flujos de entrenamiento, en lugar de redactarlos manualmente a posteriori.

Este artículo ofrece información general, no asesoramiento jurídico. La clasificación de un modelo o sistema conforme al Reglamento depende de las circunstancias, por lo que debe consultar a profesionales jurídicos cualificados en derecho de la UE antes de basarse en cualquier interpretación.

Por qué una ficha de modelo no basta para un agente de IA

Un agente de atención al cliente no es un modelo. Es un modelo más unas instrucciones de sistema, fuentes de recuperación de información, herramientas, mecanismos de protección, reglas de derivación, integraciones de canales y un proceso de transferencia a una persona. La ficha de modelo solo describe una de esas partes.

Los investigadores que trabajan en documentación de sistemas complejos señalan lo mismo. Un artículo sobre documentación dinámica para sistemas de IA sostiene que la documentación estática no refleja la naturaleza cambiante y marcada por la retroalimentación de los sistemas de aprendizaje automático. Los profesionales indican que, en los agentes modulares que combinan varios modelos, una única ficha no explica cómo interactúan los componentes para producir un comportamiento o un fallo sistémico.

De ello se derivan tres carencias.

1. Los resultados de laboratorio no son resultados de uso real. Una ficha informa sobre el rendimiento en pruebas de referencia. No permite saber si su agente, con sus instrucciones y su base de conocimientos, transfiere a un cliente angustiado a una persona. En las auditorías realizadas por Lexic, el 85% de los agentes de IA auditados no derivaron correctamente los problemas a representantes humanos. Ninguna ficha de modelo lo habría predicho, porque el fallo reside en el despliegue, no en el modelo.

2. Las fichas las redacta la parte descrita. La mayoría de los informes de evaluación y las fichas de modelo omiten contexto, como la trayectoria del auditor, los conflictos de intereses y el nivel de acceso al modelo, según la investigación sobre fichas de auditoría. Sin ese contexto, un regulador o un equipo de cumplimiento no puede valorar hasta qué punto confiar en el resultado.

3. Las fichas quedan desactualizadas. Una actualización del modelo sin aviso, un cambio en las instrucciones o una nueva fuente de recuperación de información pueden alterar el comportamiento mientras la ficha permanece igual.

La documentación generada añade su propio riesgo. Un estudio de un conjunto de datos sobre la generación automatizada de fichas de modelo constató que los generadores basados en LLM pueden inventar detalles, como la infraestructura de entrenamiento, basándose en la frecuencia con que algo aparece en el texto y no en la procedencia real del modelo. Si automatiza la redacción de fichas, verifique cada campo factual con un registro primario.

De las fichas de modelo a las fichas de auditoría

Los mismos autores que señalan estas omisiones proponen un complemento: la ficha de auditoría. Esta informa sobre la propia auditoría, incluido quién fue el auditor, cuál fue el alcance, qué métodos se utilizaron y qué mecanismos de revisión se aplicaron. La idea es que un resultado de evaluación significa poco si el lector no puede interpretarlo en su contexto.

En la práctica, un expediente de gobernanza para un agente de IA conversacional puede contener tres capas:

La tercera capa es la que falta en la mayoría de las organizaciones. También es la que puede defenderse ante un regulador, porque no depende de los datos facilitados por el proveedor. En otro contexto regulado, una nota sobre qué necesitan los auditores más allá de los registros del sistema muestra cómo funcionan en la práctica las expectativas sobre la pista de auditoría: las evidencias deben ser atribuibles, completas y revisables, un estándar que también debe cumplir un expediente de auditoría de IA.

IA conversacional explicable: fichas frente a diálogo

También se plantea cómo se aplica la explicabilidad a la IA conversacional. Son dos cuestiones distintas.

La primera es explicar un modelo a quienes lo gobiernan. En este caso, la interacción puede superar a los documentos estáticos. En las evaluaciones de TalkToModel, un sistema basado en el diálogo para explicar modelos de aprendizaje automático, el 85% de los profesionales del aprendizaje automático consideró que la interfaz conversacional era más fácil de usar que las explicaciones estáticas para comprender el comportamiento del modelo. Los usuarios podían preguntar por qué se había realizado una predicción o cómo cambiaría el resultado si se modificaban los datos de entrada.

La segunda es explicar qué hizo un agente en una conversación concreta con un cliente. Para ello se necesitan la transcripción, los puntos de decisión y la ruta de derivación, vinculados a un registro. La explicabilidad, en este sentido, son evidencias procedentes de las conversaciones, no una propiedad del modelo.

Nuestra perspectiva

Auditamos agentes de IA conversacional de cualquier proveedor y no desarrollamos ni operamos agentes propios. Esa independencia determina nuestra visión de las fichas de modelo.

Una ficha de modelo es un punto de partida necesario y una conclusión insuficiente. Indica lo que un desarrollador afirma sobre un modelo en condiciones de prueba. No permite saber si su agente desplegado informa de que es una IA, si filtra información ante instrucciones adversarias o si deriva una reclamación a una persona. Son comportamientos, y solo se manifiestan en conversaciones reales.

Recomendamos tres hábitos. Mantenga juntas la ficha de modelo, la documentación del sistema y las evidencias de auditoría, y gestione sus versiones de forma conjunta. Revise todas las conversaciones, no una muestra, porque los fallos importantes suelen ser poco frecuentes. Y haga que las evidencias las produzca alguien sin intereses en el éxito del agente, para que resistan el escrutinio cuando un regulador, un cliente o un miembro del consejo pregunte cómo lo sabe.

— Sergio Llorens

Una lista de comprobación práctica para su expediente de gobernanza

Utilice esta lista al documentar un agente basado en un LLM.

1. Registre el modelo. Enlace la ficha del proveedor, anote la versión exacta y configure un recordatorio para volver a comprobarla cuando el proveedor actualice el modelo.
2. Adapte su lenguaje. Redacte un resumen de una página en lenguaje claro para los directivos: uso previsto, principales limitaciones y nivel de riesgo.
3. Documente el sistema. Instrucciones, fuentes de datos, herramientas, mecanismos de protección, reglas de derivación y transferencia a una persona.
4. Capture los metadatos automáticamente. El historial de versiones y los cambios de configuración deben proceder de su flujo de trabajo, no de la memoria.
5. Realice pruebas en condiciones de producción. Revise conversaciones reales para evaluar la derivación, la información al usuario, la seguridad y la exactitud.
6. Añada contexto independiente. Adjunte a cada evaluación el alcance de la auditoría, el método y la identidad del auditor.
7. Establezca revisiones periódicas. Cualquier cambio en el modelo, las instrucciones o los conocimientos debe activar una revisión de la documentación.

Qué papel desempeña Lexic

Lexic ofrece auditorías independientes de agentes de IA conversacional de cualquier proveedor, contrastando su comportamiento real con criterios normativos, de seguridad, derivación e información al usuario. Lexic Compass es el producto de auditoría y gobernanza. Las modalidades de contratación, incluidas Flash Preview, Audit Sprint y Enterprise Continuous Trust, se describen en la página de contratación de auditorías. Para el análisis de todas las conversaciones con clientes en llamadas, chats, correos electrónicos y tickets, consulte Lexic Pulse.

Preguntas frecuentes

¿Qué es una ficha de modelo para un LLM?

Es un documento estructurado elaborado por el desarrollador de un modelo que describe el uso previsto, los datos de entrenamiento, los resultados de evaluación, las pruebas de seguridad y las limitaciones conocidas. Permite a compradores y reguladores valorar si un modelo es adecuado para una finalidad determinada. Describe únicamente el modelo, no los agentes o productos desarrollados sobre él.

¿Son obligatorias por ley las fichas de modelo?

En general, no como formato específico. Según el EU AI Act, los proveedores de modelos de IA de uso general deben mantener documentación técnica que abarque la arquitectura, el entrenamiento, la procedencia de los datos y la evaluación, y una ficha de modelo es un punto de partida habitual para ello. Los requisitos estadounidenses varían según el estado y el sector, por lo que debe consultar su situación con su asesoría jurídica.

¿Dónde puedo encontrar ejemplos de fichas de modelo?

Los desarrolladores de modelos publican fichas o documentos del sistema con sus versiones, y repositorios abiertos, como el proyecto NIST AI RMF Cookbook, recopilan plantillas y esquemas. Compare varias según la información que divulgan sobre datos, evaluación y limitaciones, y adapte una plantilla a su propio uso interno.

¿Demuestra una ficha de modelo que un agente de IA cumple la normativa?

No. Documenta un componente en condiciones de prueba. El cumplimiento de un agente orientado al cliente depende del comportamiento del sistema completo, incluidos la información al usuario, la derivación y la seguridad, lo que requiere evidencias procedentes de conversaciones reales.

¿Puede un LLM redactar su propia ficha de modelo?

Puede redactar un borrador, pero las investigaciones sobre generación automatizada muestran que estas herramientas pueden inventar detalles, como el hardware de entrenamiento. Utilice el texto generado solo como borrador y verifique cada dato con registros primarios.

Fuentes

• Aspen Institute: fichas de modelos de IA para responsables de políticas públicas
• vintagedon/nist-ai-rmf-cookbook en GitHub
• Versión de NIST AI RMF Cookbook publicada en Zenodo
• Marco COMPEL: obligaciones relativas a los modelos GPAI y riesgo sistémico
• Taylor Wessing: obligaciones de los proveedores de modelos GPAI
• Documentación dinámica para sistemas de IA
• Fichas de auditoría: contextualización de las evaluaciones de IA
• Comprender mejor los modelos: un conjunto de datos para la generación automatizada de fichas de modelo
• Explicación de modelos de aprendizaje automático con TalkToModel, Nature Machine Intelligence