¿Qué es una tarjeta de modelo?
Gobernanza, riesgo y aseguramiento
Una tarjeta de modelo es un documento breve y estructurado que explica un modelo concreto de IA o aprendizaje automático. Describe qué se supone que debe hacer el modelo, cómo fue entrenado y evaluado, qué rendimiento ofrece en condiciones relevantes, dónde es probable que falle y qué usos quedan fuera de su alcance. Para un directivo no especialista, es un documento de transparencia práctico que ayuda a determinar si un modelo se comprende lo suficientemente bien como para confiar en él, adquirirlo, adaptarlo o desplegarlo.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
En lenguaje claro, una tarjeta de modelo es la etiqueta y las notas de funcionamiento de un modelo concreto. No es el expediente técnico completo ni el manual de producto completo. Es la explicación concisa que debería acompañar al modelo para que otras personas puedan entender qué es, para qué fue creado y cuáles son sus limitaciones conocidas.
La expresión clave es "un modelo". Una tarjeta de modelo describe normalmente un único modelo entrenado, o una versión de modelo claramente definida dentro de una familia. Puede referirse a un clasificador, un modelo de voz, un modelo de predicción, un modelo de lenguaje grande o un modelo de imagen. Debe indicar qué tipo de entrada acepta el modelo, qué tipo de salida produce, qué datos de entrenamiento lo configuraron a grandes rasgos, qué evaluaciones se realizaron y qué advertencias son relevantes en la práctica.
Ese enfoque en un único modelo es lo que distingue una tarjeta de modelo de una tarjeta de sistema. La tarjeta de modelo trata sobre el modelo en sí. La tarjeta de sistema tiene un alcance más amplio: describe un sistema desplegado construido en torno a uno o más modelos, junto con los controles que lo rodean, como instrucciones, recuperación de información, políticas, controles de acceso, monitorización, red teaming y revisión humana. Si se está evaluando un asistente de IA para atención al cliente, la tarjeta de modelo explica el modelo subyacente. La tarjeta de sistema explica el asistente tal como opera realmente en el mundo real.
Un modelo mental útil es el siguiente. Si el modelo es un motor, la tarjeta de modelo indica el tipo de motor, las pruebas de rendimiento, los límites de servicio y los puntos débiles conocidos. Si el producto es un vehículo, la tarjeta de sistema explica el vehículo completo, incluida la dirección, los frenos, las características de seguridad, las condiciones de carretera en las que no debe utilizarse y cómo se espera que lo manejen las personas.
Las buenas tarjetas de modelo hacen que las afirmaciones vagas sean verificables. En lugar de escuchar que un modelo es "avanzado" o "listo para empresas", es posible formular preguntas más precisas: ¿listo para qué?, ¿probado frente a qué?, ¿sólido en qué idiomas o dominios?, ¿débil en qué casos límite?, ¿y actualizado cuándo?
Por qué importa
Los directivos suelen encontrarse con tarjetas de modelo en dos situaciones. La primera es al adquirir o aprobar IA de terceros. La segunda es al pedir a un equipo interno que documente un modelo antes de que pase de la fase experimental al uso en producción. En ambos casos aparece el mismo riesgo: sin documentación estructurada, es fácil confundir una demostración capaz con un componente fiable.
Una tarjeta de modelo facilita la adquisición porque ofrece algo concreto que revisar. Permite comparar el uso previsto con el uso real, comprobar si el entorno de evaluación se parece al entorno operativo propio y ver si las limitaciones conocidas generarían problemas operativos. Eso puede evitar que una mala elección se convierta en una integración costosa.
También contribuye a la garantía de calidad. Si un modelo afecta a las comunicaciones con clientes, los flujos de trabajo del personal, las decisiones financieras, los procesos de seguridad o los datos sensibles, es necesario contar con un registro de lo que se sabía en el momento de la aprobación. Una tarjeta de modelo no elimina el riesgo, pero crea un rastro de evidencia útil. Muestra si el equipo reflexionó seriamente sobre el propósito, las pruebas, las limitaciones y el control de versiones.
Hay otro aspecto práctico importante. Los modelos cambian. Los proveedores actualizan versiones, los equipos internos los ajustan, las afirmaciones sobre benchmarks evolucionan y los patrones de fallo se modifican. Una tarjeta de modelo proporciona una línea de base. Sin ella, cada conversación parte del lenguaje de marketing. Con ella, es posible rastrear los cambios entre versiones y preguntar si una nueva versión es realmente mejor para el caso de uso concreto.
Cómo funciona
Una tarjeta de modelo suele comenzar con información básica de identificación: cómo se llama el modelo, qué versión se describe, quién lo produjo, qué entradas acepta, qué salidas devuelve y dónde está disponible. Parece sencillo, pero importa. Muchas organizaciones acaban debatiendo sobre una familia de modelos en términos generales cuando lo único que realmente cuenta es la versión exacta que se utiliza en producción.
La siguiente parte es el propósito. Una buena tarjeta indica para qué está pensado el modelo y, con igual importancia, para qué no está pensado. Esta es una de las secciones más valiosas para un directivo, porque transforma una posibilidad amplia en un alcance claro. Un modelo de resumen puede ser adecuado para redactar notas, pero no para una revisión legal definitiva. Un clasificador de imágenes puede funcionar para enrutar controles de calidad, pero no para diagnóstico clínico. Si el uso previsto es vago, el resto de la tarjeta pierde utilidad porque la evaluación carece de un objetivo claro.
A continuación vienen los datos del modelo y la información de entrenamiento. No es necesario revelar todos los detalles propietarios, pero sí explicar lo suficiente para que el lector comprenda la forma del proceso de entrenamiento: qué tipos de datos informaron al modelo, si fue preentrenado, ajustado o adaptado a partir de un modelo base, y si hubo filtros, pasos de ajuste de seguridad o exclusiones relevantes. En los modelos abiertos, esta sección puede ser detallada. En los modelos comerciales, suele ser más limitada. Limitada no equivale a inútil, pero una descripción muy escueta debería reducir la confianza.
La evaluación suele ser el núcleo de la tarjeta. Es donde el desarrollador informa sobre el rendimiento del modelo en las pruebas. Las tarjetas sólidas van más allá de mostrar una única puntuación destacada: explican qué se midió, en qué benchmarks o conjuntos de prueba, en qué idiomas o dominios, bajo qué condiciones y con qué advertencias. Para el uso empresarial, esta es la sección en la que conviene detenerse. Un modelo puede parecer excelente en benchmarks generales y seguir siendo una mala elección para los documentos, la terminología, los clientes o el perfil de riesgo propios.
Las mejores tarjetas también incluyen resultados por segmentos o por contexto; es decir, no solo el rendimiento promedio, sino el rendimiento en condiciones que importan. Por ejemplo, los resultados pueden variar según el idioma, el acento, la calidad de la imagen, el tipo de tarea o la categoría de seguridad. Esta parte es relevante porque los fallos operativos graves suelen ocultarse dentro de los promedios. Una puntuación global alta puede encubrir un caso límite débil que aparece a diario en el flujo de trabajo.
Una tarjeta de modelo útil también expone con claridad las limitaciones conocidas y los modos de fallo. Esta sección debe describir dónde el modelo es frágil, dónde tiende a alucinar, dónde rechaza en exceso, dónde rinde peor o dónde el desarrollador carece de confianza. Los directivos a veces interpretan las limitaciones como una señal de alarma. En realidad, la ausencia de una sección de limitaciones suele ser la señal de alarma más importante. Los equipos maduros saben dónde es probable que su modelo tenga dificultades.
Las consideraciones sobre seguridad, sesgo y ética suelen aparecer hacia el final de la tarjeta. El formato exacto varía: algunas tarjetas abordan la seguridad del contenido y el uso indebido; otras tratan el rendimiento por subgrupos o el sesgo perjudicial; otras establecen restricciones de uso aceptable; y algunas también describen el consumo energético, la licencia o los requisitos para usos derivados. El formato difiere entre proveedores y la práctica actual sigue evolucionando, pero el punto práctico es el mismo: el desarrollador debe hacer visibles las concesiones y restricciones relevantes.
Por último, una tarjeta debe mantenerse actualizada, no redactarse una sola vez y olvidarse. Una tarjeta de modelo es más útil cuando está versionada, fechada y actualizada a medida que el modelo cambia. Si un proveedor lanza una nueva versión principal, ajusta el afinado de seguridad o modifica los canales de despliegue, cabe esperar que la tarjeta lo refleje. Si se desarrolla internamente, conviene tratar la tarjeta de modelo como un documento de control vivo, no como un añadido del día del lanzamiento.
Ejemplos
Un equipo de finanzas podría estar evaluando un modelo para la extracción de facturas. La tarjeta de modelo les ayuda a ver si el modelo fue probado con documentos escaneados, formularios multilingües, imágenes de baja calidad o únicamente con datos de benchmark limpios. Eso les indica si un piloto probablemente revelará brechas menores o mayores.
Un equipo de operaciones podría estar revisando un modelo de voz a texto para resúmenes de llamadas. La tarjeta de modelo puede mostrar si el modelo fue evaluado con distintos acentos, audio con ruido, habla en varios idiomas o vocabulario específico del dominio. Si la tarjeta no dice nada sobre esos aspectos, el equipo sabe que deberá probarlos por su cuenta antes del despliegue.
Un equipo de software podría ajustar un modelo de lenguaje interno para búsqueda de políticas o asistencia en la redacción. Su propia tarjeta de modelo se convierte en el documento compartido que explica qué cambió respecto al modelo base, qué datos internos se utilizaron, qué controles de seguridad se realizaron y en qué situaciones no debe confiarse en la versión ajustada. Eso facilita enormemente la transferencia, la auditoría y el mantenimiento futuro.
Malentendidos frecuentes
Un malentendido habitual es creer que una tarjeta de modelo demuestra que un modelo es seguro. No es así. Una tarjeta es evidencia de documentación, no una garantía de calidad.
Otro es pensar que una sola cifra de benchmark es suficiente. Rara vez lo es. El riesgo empresarial suele derivar de la discrepancia entre el entorno de prueba y el uso real, no de la falta de métricas destacadas.
Un tercer malentendido es que una tarjeta de modelo lo dice todo sobre el producto final. No es así. Si el modelo forma parte de un asistente o flujo de trabajo más amplio, también se necesita documentación a nivel de sistema.
Un cuarto malentendido es que las tarjetas de modelo son solo para modelos públicos o abiertos. Los modelos internos también las necesitan, a menudo más, porque los equipos internos tienden a apoyarse en supuestos compartidos que nunca se ponen por escrito.
Riesgos y límites
Las tarjetas de modelo tienen limitaciones. Algunas son escuetas, selectivas o redactadas principalmente con fines de relaciones públicas. Algunas describen toda una familia de modelos cuando lo que realmente se necesita son detalles sobre la versión específica que se va a utilizar. Algunas quedan obsoletas rápidamente tras un fine tuning, cambios de política o actualizaciones silenciosas del proveedor.
Tampoco sustituyen a las pruebas locales. Incluso una tarjeta excelente no puede indicar cómo se comportará un modelo con los documentos, los clientes, los idiomas, los flujos de trabajo o los controles propios. Debe reducir la carga de pruebas, no eliminarla.
También existe una concesión en materia de divulgación. Los proveedores pueden limitar legítimamente la información muy detallada sobre datos de entrenamiento, pesos o métodos de seguridad por razones de seguridad, propiedad intelectual o prevención del uso indebido. Es comprensible, pero significa que los directivos deben aprender a distinguir entre "no divulgado por una razón justificada" y "no divulgado porque nadie realizó el trabajo".
Por último, una tarjeta de modelo no constituye asesoramiento legal, de privacidad, de seguridad ni profesional. Si un modelo interviene en procesos regulados, decisiones de empleo, información sanitaria, juicios financieros o derechos significativos, debe integrarse en una revisión más amplia en lugar de sustituirla.
Qué hacer a continuación
En primer lugar, defina el uso empresarial exacto antes de solicitar documentación. Una tarjeta de modelo solo es útil cuando se sabe qué se quiere que haga el modelo, para quién y bajo qué nivel de riesgo.
En segundo lugar, solicite la tarjeta del modelo y la versión exactos que se proponen, no un folleto genérico de la familia. Si la respuesta es vaga, trátelo como una señal de alerta.
En tercer lugar, lea con detenimiento cuatro secciones: uso previsto, evaluación, limitaciones e historial de actualizaciones. Esas secciones suelen decir más que una larga lista de características.
En cuarto lugar, compare la tarjeta con sus propias condiciones operativas. Busque cobertura de idiomas, tipo de datos, contexto del flujo de trabajo, comportamiento de seguridad y debilidades conocidas que sean relevantes en su entorno. Donde la tarjeta guarde silencio, anote casos de prueba para su piloto.
En quinto lugar, si el modelo se va a desplegar dentro de un producto o asistente más amplio, solicite también documentación a nivel de sistema. Una tarjeta de modelo sólida sin una tarjeta de sistema sólida sigue dejando puntos ciegos importantes.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Una tarjeta de modelo es solo para expertos en aprendizaje automático?
No. Las mejores tarjetas de modelo están redactadas de forma que los no especialistas puedan entender el propósito, las pruebas, las limitaciones y el uso adecuado, al tiempo que ofrecen a los lectores técnicos suficiente detalle para profundizar.
¿Cuál es la diferencia entre una tarjeta de modelo y un informe de benchmark?
Un informe de benchmark se centra principalmente en las puntuaciones de las pruebas. Una tarjeta de modelo también debe cubrir el uso previsto, el contexto de los datos, las limitaciones, las consideraciones de seguridad y el contexto específico de la versión.
¿Debería tener todo modelo una tarjeta de modelo?
En la práctica, sí, pero la profundidad debe ser proporcional al riesgo e importancia del modelo. Un modelo interno de bajo impacto puede necesitar una tarjeta breve. Un modelo de alto impacto necesita una mucho más completa.
¿Puede un proveedor negarse a compartirla?
Sí, pero eso no elimina la necesidad de documentación. Si un proveedor no facilita una tarjeta de modelo adecuada o equivalente, conviene asumir que serán necesarias una validación adicional y comprobaciones contractuales más estrictas.
Si tengo una tarjeta de modelo, ¿sigo necesitando un piloto?
Casi siempre. La tarjeta debe ayudar a diseñar un piloto mejor mostrando qué hay que probar, no sustituir las pruebas reales en el entorno propio.
Fuentes
Model Cards for Model Reporting (arXiv and FAT* 2019). Primary source. Introduced the model card concept and defined model cards as short documents accompanying trained models, including intended use, evaluation, and limitations. cite.
Artificial Intelligence Risk Management Framework Generative Artificial Intelligence Profile (NIST). Secondary standards source. Supported the leadership guidance to review transparency artefacts for third party models and document sources, training processes, and adaptations. cite.
The CLeAR Documentation Framework for AI Transparency (Harvard Shorenstein Center). Secondary framework source. Supported the point that AI documentation practices vary by context and that documentation for models and systems is still evolving rather than fixed in one universal format. cite.