¿Qué es una tarjeta de sistema?
Gobernanza, riesgo y aseguramiento
Una tarjeta de sistema es un documento de transparencia para un sistema de IA desplegado, no solo para el modelo que contiene. Por lo general, describe el propósito del sistema, su arquitectura, las pruebas de seguridad, las limitaciones conocidas, las medidas de mitigación, el razonamiento detrás de su lanzamiento y los compromisos de monitoreo, todo en el contexto en que las personas lo utilizarán realmente. Para los líderes, el valor es práctico: una tarjeta de sistema ayuda a evaluar no solo lo que un modelo puede hacer, sino cómo los controles del producto, las políticas, las herramientas y los flujos de trabajo que lo rodean modifican el riesgo en el mundo real.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Una tarjeta de sistema es el documento operativo ampliado de un sistema de IA. Si una tarjeta de modelo describe un modelo concreto, una tarjeta de sistema describe el sistema construido alrededor de ese modelo o esos modelos. Eso suele incluir el propio modelo, pero también la configuración de prompts, el uso de herramientas, los componentes de recuperación, las interfaces, los clasificadores de seguridad, los controles de acceso, los pasos de revisión humana y los límites de despliegue.
Esto importa porque las personas no suelen comprar ni utilizar un modelo desnudo. Usan un chatbot, un asistente de programación, un asistente de voz, un flujo de moderación u otro sistema empaquetado. El riesgo en el mundo real suele provenir de esa configuración completa, no solo de los pesos del modelo.
Un buen modelo mental es el siguiente. La tarjeta de modelo es la ficha técnica del motor. La tarjeta de sistema es el manual de vuelo para un modo de operación definido. Explica la máquina, las salvaguardas, las condiciones de uso y los principales riesgos conocidos.
También conviene señalar con claridad que las tarjetas de sistema siguen siendo una convención emergente a mediados de 2026. Los principales proveedores utilizan el término, pero no existe un estándar único y consolidado que todas las organizaciones sigan de la misma manera. Eso hace que el término sea útil, aunque también algo resbaladizo. Los líderes deben, por tanto, preguntar qué incluye un proveedor determinado en su tarjeta de sistema y qué queda fuera de ella.
Por qué importa
Las tarjetas de sistema importan porque la mayor parte del uso de IA de alto valor se produce a nivel de sistema, no a nivel de modelo. Un modelo puede parecer sólido de forma aislada, pero el sistema desplegado puede volverse inseguro o poco fiable debido a los permisos de herramientas, la calidad de la recuperación, el diseño de voz, las decisiones de interfaz de usuario, el comportamiento agéntico o una monitorización deficiente.
En materia de adquisición, esto significa que una tarjeta de modelo es necesaria pero no suficiente. Si se adquiere un asistente que puede navegar por la web, llamar a herramientas, generar código, interactuar con usuarios o actuar sobre información sensible, es necesario saber cómo se probó y restringió el sistema completo. Una tarjeta de sistema es uno de los pocos documentos públicos que puede mostrar esto de forma estructurada.
Para la gobernanza interna, una tarjeta de sistema contribuye a crear una comprensión compartida entre ingeniería, operaciones, riesgos, seguridad y dirección. Informa a las personas sobre qué se evaluó antes del lanzamiento, qué supuestos se incorporaron, qué mitigaciones están realizando un trabajo importante y qué limitaciones siguen requiriendo cautela operativa.
Cómo funciona
Una tarjeta de sistema suele comenzar definiendo el sistema y su alcance. Qué se está documentando. Qué modelo o modelos se incluyen. Qué interfaces o modalidades están dentro del alcance. Qué canal de lanzamiento se describe. Esto parece obvio, pero los límites del sistema suelen ser difusos. Si la tarjeta no define bien el alcance, resulta difícil determinar si un riesgo concreto fue realmente evaluado.
La siguiente parte suele describir la arquitectura a un nivel útil. No cada detalle propietario, pero sí lo suficiente para mostrar los componentes principales. Por ejemplo, una tarjeta de sistema puede explicar que un asistente conversacional utiliza un modelo base, una capa de política post-entrenada, modelos de moderación, recuperación, reglas de producto, registro y rutas de escalada humana. Aquí es donde empieza a diferenciarse claramente de una tarjeta de modelo.
A continuación viene la evaluación de capacidades y seguridad en contexto. Las tarjetas de sistema sólidas no se limitan a indicar que el modelo fue sometido a benchmarks. Explican cómo se probó el sistema desplegado. Eso puede incluir red teaming, pruebas de uso indebido, evaluaciones específicas por dominio, comprobaciones multimodales, pruebas de uso agéntico de herramientas y evaluaciones de terceros. Lo importante es que las pruebas están vinculadas a cómo se utilizará realmente el sistema, no solo a tareas genéricas de benchmark.
Las mitigaciones son otra sección central. Una tarjeta de sistema debe identificar qué salvaguardas importan en la práctica, como rechazos ajustados por política, filtros de contenido, control de acceso, monitorización, restricciones de prompts, limitaciones de herramientas, revisión humana, límites de velocidad o despliegue por fases. Esto es crucial para los líderes porque muestra si la seguridad aparente depende de un diseño de sistema por capas o únicamente del modelo. En muchos productos de IA modernos, la respuesta es el diseño por capas.
Una tarjeta de sistema útil también informa sobre las limitaciones conocidas, los riesgos residuales y lo que no se probó. Esta es una de sus funciones más valiosas. Si un proveedor indica que un sistema fue probado para texto, imagen y voz, ¿fue eso una prueba de calidad de lanzamiento completa en los tres casos, o principalmente texto con pruebas limitadas en los demás? Si un agente de programación fue evaluado en un entorno de pruebas, ¿qué ocurre cuando se conecta a herramientas de producción? Si un sistema puede usar interfaces de computadora, ¿cómo se gestiona la inyección de prompts? Una tarjeta madura debe ayudar al lector a ver estos límites.
La información sobre lanzamiento y monitorización suele seguir a continuación. Por qué se lanzó el sistema en su forma actual. Qué umbral o política interna se utilizó. Qué monitorización continúa tras el lanzamiento. Cómo se gestionan los incidentes o los riesgos recién descubiertos. Esto importa porque los sistemas de IA no permanecen estáticos. Una tarjeta de sistema no debe leerse como una afirmación atemporal de seguridad. Debe leerse como una evaluación fechada realizada bajo condiciones declaradas, con la expectativa de ser revisada.
Para los líderes, la estrategia práctica de lectura es sencilla. Conviene hacerse tres preguntas mientras se lee. Primera, ¿qué se está documentando exactamente? Segunda, ¿qué salvaguardas son esenciales para el comportamiento declarado? Tercera, ¿qué tan cercano es este sistema documentado al que se desplegará o adquirirá realmente? Si existe una brecha importante, también se necesita una evaluación propia a nivel de sistema.
Ejemplos
Un asistente de atención al cliente puede utilizar un modelo de lenguaje potente, pero el perfil de riesgo real depende del sistema de recuperación que lo rodea, las reglas de escalada, la moderación y las acciones que el asistente tiene permitido realizar. Una tarjeta de sistema es el lugar adecuado para documentar ese panorama combinado.
Un asistente de voz es otro ejemplo claro. El modelo subyacente puede ser multimodal, pero el sistema de voz desplegado también depende del procesamiento del habla, las restricciones del hablante, el comportamiento de rechazo en audio, las políticas de contenido y la monitorización del abuso. Estas son preguntas a nivel de sistema.
Un agente de programación u operaciones con uso de herramientas hace que la distinción sea aún más evidente. El modelo puede ser solo una parte del conjunto. La tarjeta de sistema debe cubrir los permisos de herramientas, el entorno de pruebas, la gestión de la inyección de prompts, el registro, los pasos de revisión y las circunstancias en que se restringe la acción autónoma.
Un producto de moderación puede combinar varios clasificadores, lógica de enrutamiento, umbrales, colas humanas y flujos de apelación. El artefacto de transparencia útil para ese servicio completo es una tarjeta de sistema, no solo un conjunto de tarjetas de modelo.
Malentendidos frecuentes
El malentendido más común es que una tarjeta de sistema es simplemente otro nombre para una tarjeta de modelo. No lo es. Una tarjeta de modelo es más específica y se centra en un único modelo. Una tarjeta de sistema cubre el sistema desplegado alrededor de uno o más modelos.
Otro malentendido es que una tarjeta de sistema publicada significa que el sistema está certificado o garantizado como seguro. No es así. Es documentación, no una garantía formal.
Un tercer malentendido es que las tarjetas de sistema solo son relevantes para los lanzamientos de laboratorios de frontera. En realidad, cualquier organización que despliegue un sistema de IA en flujos de trabajo relevantes puede beneficiarse de documentación a nivel de sistema, adaptada al riesgo y la complejidad.
Un cuarto malentendido es que las puntuaciones de benchmark cuentan la misma historia. No es así. Los benchmarks pueden decir algo sobre la capacidad. Dicen mucho menos sobre cómo un sistema en producción está restringido, monitorizado y es probable que falle en contexto.
Riesgos y límites
Las tarjetas de sistema varían considerablemente. Un proveedor puede producir un documento extenso y con gran carga evaluativa. Otro puede publicar un resumen breve. Dado que la convención sigue evolucionando, los líderes no deben asumir que dos tarjetas de sistema son directamente comparables línea por línea.
También pueden quedar desactualizadas. Una tarjeta de sistema puede describir un estado de lanzamiento concreto, mientras el sistema en producción sigue cambiando mediante actualizaciones de prompts, cambios de modelo, revisiones de política o nuevas herramientas. Si el control de versiones es deficiente, la tarjeta pierde valor rápidamente.
También existe un problema de divulgación selectiva. Los proveedores pueden describir las principales mitigaciones, pero no todas las dependencias, umbrales o debilidades operativas. Parte de ello puede estar justificado por razones de seguridad. Parte puede reflejar simplemente una práctica inmadura. En cualquier caso, los equipos de adquisición y aseguramiento deben leer las tarjetas de sistema como evidencia, no como el caso completo.
Y al igual que con las tarjetas de modelo, una tarjeta de sistema no reemplaza la revisión legal, de seguridad, de privacidad o específica del dominio. Debe alimentar esos procesos, no sustituirlos.
Qué hacer a continuación
En primer lugar, conviene preguntar si el proveedor puede facilitar tanto una tarjeta de modelo como una tarjeta de sistema, o equivalentes cercanos. Si solo proporciona documentación a nivel de modelo para un asistente o agente complejo, sigue existiendo una brecha importante de visibilidad.
En segundo lugar, hay que mapear el sistema documentado con el despliegue previsto. Se deben anotar los prompts adicionales, herramientas, fuentes de datos, grupos de usuarios o permisos del entorno propio que no estén cubiertos por la tarjeta publicada.
En tercer lugar, conviene leer detenidamente la sección de salvaguardas. Hay que determinar qué protecciones realizan la mayor parte del trabajo de seguridad y si esas protecciones seguirán existiendo en la implementación propia.
En cuarto lugar, se debe preguntar cómo se versiona y actualiza la tarjeta. Para un producto de IA que cambia rápidamente, la documentación sin fecha es documentación débil.
En quinto lugar, conviene utilizar la tarjeta de sistema para diseñar pruebas de aceptación para el piloto propio. Las limitaciones declaradas y los riesgos residuales deben convertirse en escenarios concretos que el equipo evaluará antes de un despliegue más amplio.
¿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 sistema es siempre pública?
No siempre. Algunas organizaciones las publican externamente, mientras que otras conservan versiones más completas para la gobernanza interna o la diligencia debida de los clientes. Lo importante es que la documentación a nivel de sistema exista y se mantenga actualizada.
¿Sigo necesitando una tarjeta de modelo si tengo una tarjeta de sistema?
Por lo general, sí. Los dos artefactos responden a preguntas distintas. La tarjeta de modelo explica el modelo. La tarjeta de sistema explica la configuración completa desplegada.
¿Qué ocurre si un proveedor dice que su producto es demasiado complejo para una tarjeta de sistema?
La complejidad suele ser una razón para contar con mejor documentación del sistema, no una excusa para evitarla. El formato puede variar, pero la necesidad de un alcance claro, pruebas, mitigaciones y límites se mantiene.
¿Las tarjetas de sistema son solo para sistemas de IA muy avanzados?
No. La profundidad debe variar según el riesgo y la complejidad, pero cualquier sistema de IA utilizado en flujos de trabajo relevantes se beneficia de una documentación clara del alcance, las salvaguardas y las limitaciones.
¿Cuál es lo más importante que hay que buscar?
Hay que comprobar si la tarjeta explica el contexto real de despliegue, incluidas las salvaguardas y los límites. Si se lee como un folleto del modelo en lugar de como una evaluación del sistema, probablemente no sea suficiente.
Fuentes
System Cards for AI-Based Decision-Making for Public Policy (arXiv). Primary academic source. Supported the point that system cards are broader accountability artefacts that can present audit and assessment information at data, model, code, and system level. cite.
Policy Alignment on AI Transparency (Partnership on AI). Secondary policy source. Supported the point that documentation and transparency are central to managing foundation model risk and that documentation frameworks are still developing across jurisdictions. cite.
Guidance for Safe Foundation Model Deployment (Partnership on AI). Secondary governance source. Supported the statement that system cards are treated as emerging best practice disclosures rather than a single universally fixed standard. cite.
The CLeAR Documentation Framework for AI Transparency (Harvard Shorenstein Center). Secondary framework source. Supported the article's emphasis that documentation for AI systems containing one or more models involves context, trade offs, and no one size fits all template. cite.
Artificial Intelligence Risk Management Framework Generative Artificial Intelligence Profile (NIST). Secondary standards source. Supported the procurement and assurance advice to review transparency artefacts such as system cards and model cards for third party models and systems. cite.