Fichas de modelo para LLM: qué abarcan 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 creó, cómo se evaluó y dónde no debe utilizarse. Para los grandes modelos de lenguaje (LLM), una ficha útil recoge 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 construye sobre ese modelo, y en esa brecha se concentra la mayor parte del riesgo de incumplimiento normativo.

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

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 en una obligación legal del proveedor, y no solo en una buena práctica.
• Una ficha describe un modelo en pruebas controladas. No muestra cómo se comporta un agente desplegado con clientes reales, lo que incluye la derivación, la información al usuario y la seguridad.
• Trate la documentación del modelo como un registro vivo sujeto a control de versiones y acompáñela de evidencias independientes obtenidas de conversaciones reales.

Índice

• Qué es una ficha de modelo y quién la lee
• Qué debe contener la ficha de 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é aporta 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 declarar su contexto de uso previsto. La idea procede del etiquetado nutricional: 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 del contexto, el enfoque de entrenamiento, los resultados de las pruebas de referencia y las condiciones de licencia.
• Los equipos jurídicos y de cumplimiento normativo 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 directivos necesitan una respuesta en lenguaje claro a una pregunta: ¿es este modelo adecuado para este uso?

Una investigación del Aspen Institute sostiene que las fichas de modelo centradas en los ingenieros son demasiado complejas para los responsables de políticas públicas y de negocio, y que las fichas específicas para políticas públicas deberían sintetizar los metadatos técnicos en lenguaje claro. Si sus directivos no pueden interpretar la ficha en la que se apoya su equipo, esa ficha no está cumpliendo su función de gobernanza.

Qué debe contener la ficha de un LLM

La plantilla original se redactó pensando en clasificadores. Los LLM necesitan más, porque son de uso general y generan respuestas abiertas. Una ficha en la que se pueda confiar cubre los siguientes aspectos.

Identidad y uso previsto

Nombre del modelo, versión, desarrollador, fecha de lanzamiento y licencia. Después, los usos previstos y los que quedan fuera del alcance. «Atención al cliente» no es un alcance 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 carencias. Muchas fichas publicadas ofrecen poca información al respecto, lo que limita lo que puede verificar un usuario posterior.

Arquitectura y método de entrenamiento

Familia del modelo, número de parámetros cuando se divulgue, ventana de contexto y métodos de ajuste fino y alineación. Estos detalles importan 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 global aporta poca información. Busque resultados desglosados por tarea, idioma y categoría de riesgo.

Pruebas de seguridad y limitaciones conocidas

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

Datos operativos

Hardware utilizado, consumo energético, frecuencia de actualización y un contacto para comunicar problemas. Según las normas de la UE que se abordan más adelante, algunos de estos elementos 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 existen y cumplen funciones distintas.

Fichas publicadas por 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á etiquetada 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 referencia autorizada.

Al revisar cualquier ejemplo, plantéese cinco preguntas:

1. ¿Indica para qué no debe utilizarse el modelo?
2. ¿Permite identificar 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 no técnicos pueden facilitar la adaptación del lenguaje de ingeniería al de negocio.

Qué cambia con el EU AI Act

Para las empresas que comercializan o despliegan modelos en Europa, la documentación del modelo 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 cubra 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 de 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 de 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 entran en Europa:

• El proveedor del modelo asume las obligaciones relativas al modelo. Usted puede seguir asumiendo las relativas al despliegue. Si construye un agente de atención 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 jurídico.
• La actualización forma parte del requisito. Las orientaciones de COMPEL recomiendan tratar la documentación como un documento vivo sujeto a 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 a mano 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 un asesor cualificado 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 un prompt de sistema, fuentes de recuperación de información, herramientas, mecanismos de protección, reglas de derivación, integraciones con 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 para 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 de los sistemas de aprendizaje automático, con sus múltiples bucles de retroalimentación. Los profesionales señalan que, para 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 ahí se derivan tres carencias.

1. Los resultados de laboratorio no son resultados en condiciones reales. Una ficha informa del rendimiento en pruebas de referencia. No puede indicar si su agente, con sus prompts y su base de conocimiento, 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 las incidencias 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 que se describe. 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 esa información, un regulador o un equipo de cumplimiento normativo no puede valorar hasta qué punto confiar en el resultado.

3. Las fichas quedan desactualizadas. Una actualización del modelo sin aviso, un cambio de prompt 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 la 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 aporta 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, un artículo sobre lo que necesitan los auditores más allá de los registros del sistema muestra cómo se aplican en la práctica las expectativas sobre las pistas de auditoría: las evidencias deben ser atribuibles, completas y revisables, un criterio que también debe cumplir un expediente de auditoría de IA.

IA conversacional explicable: fichas frente a diálogo

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

La primera consiste en explicar un modelo a las personas responsables de su gobernanza. Aquí, la interacción puede superar a los documentos estáticos. En evaluaciones de TalkToModel, un sistema basado en diálogo para explicar modelos de aprendizaje automático, el 85% de los profesionales del aprendizaje automático consideraron más fácil utilizar la interfaz conversacional 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 cambiaran los datos de entrada.

La segunda consiste en explicar lo que hizo un agente en una conversación concreta con un cliente. Esto requiere la transcripción, los puntos de decisión y la ruta de derivación, vinculados a un registro. La explicabilidad, en este sentido, consiste en evidencias obtenidas de conversaciones, no en una propiedad del modelo.

Nuestra perspectiva

Auditamos agentes de IA conversacional de cualquier proveedor y no construimos 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 puede indicar si su agente desplegado informa de que es una IA, si filtra información ante prompts adversarios o si deriva una reclamación a una persona. Esos 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 conjuntamente. Revise todas las conversaciones, no una muestra, porque los fallos importantes suelen ser poco frecuentes. Y haga que las evidencias las genere alguien sin intereses en el éxito del agente, para que sean defendibles 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 establezca un recordatorio para volver a comprobarla cuando el proveedor actualice el modelo.
2. Adáptela. 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. Prompts, 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. Pruebe en condiciones de producción. Revise conversaciones reales para comprobar 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. Programe revisiones periódicas. Cualquier cambio en el modelo, los prompts o el conocimiento debe activar una revisión de la documentación.

Qué aporta Lexic

Lexic ofrece auditorías independientes de agentes de IA conversacional de cualquier proveedor y comprueba su comportamiento en condiciones reales frente a criterios normativos, de seguridad, de derivación y de 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 analizar todas las conversaciones con clientes en llamadas, chats, correos electrónicos y tickets, consulte Lexic Pulse.

Preguntas frecuentes

¿Qué es la ficha de 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 ni los productos construidos sobre él.

¿Son obligatorias por ley las fichas de modelo?

En general, no se exige ese formato concreto. Conforme al EU AI Act, los proveedores de modelos de IA de uso general deben mantener documentación técnica que cubra 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 un asesor jurídico.

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

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

¿Una ficha de modelo demuestra que un agente de IA cumple la normativa?

No. Documenta un componente en condiciones de prueba. El cumplimiento normativo de un agente de atención al cliente depende de cómo se comporta todo el sistema, incluida la información al usuario, la derivación y la seguridad, lo que requiere evidencias obtenidas de conversaciones reales.

¿Puede un LLM redactar su propia ficha de modelo?

Puede elaborar un borrador, pero la investigación sobre generación automatizada muestra 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 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: contextualizar las evaluaciones de IA
• Profundizar en el conocimiento de los modelos: un conjunto de datos para la generación automatizada de fichas de modelo
• Explicar modelos de aprendizaje automático con TalkToModel, Nature Machine Intelligence