¿Qué es la documentación técnica de IA?
Regulación de la IA: conceptos, instituciones y normas
La documentación técnica de IA es el conjunto estructurado de evidencias que explica qué es un sistema o modelo de IA, para qué está diseñado, cómo fue concebido, entrenado, probado, gobernado, desplegado y supervisado, y qué límites y controles se aplican. Suele ser mucho más amplia que una ficha de modelo o un resumen público. En el ámbito regulatorio y de aseguramiento, es el registro revisable que permite a operadores, compradores, auditores y autoridades verificar si un sistema de IA es legal, está controlado y es adecuado para el uso previsto.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
La documentación técnica de IA no suele ser un único documento. Es un conjunto de registros que se mantiene actualizado y acompaña al sistema de IA a lo largo del diseño, la adquisición, el desarrollo, el despliegue, la supervisión, los cambios y la retirada. Habitualmente incluye el propósito previsto, el historial de versiones, la arquitectura, la procedencia de los datos, las evidencias de pruebas, las instrucciones para usuarios, las medidas de supervisión, los registros de riesgos y los logs.
Algunas partes pueden ser públicas, como un registro de transparencia, una ficha de modelo o una ficha de sistema. El paquete completo suele ser interno o se comparte únicamente con clientes, auditores o autoridades en condiciones controladas. Su finalidad es hacer que el sistema sea revisable, no solo describible.
Una regla práctica sencilla: si una persona independiente necesitara entender qué hace el sistema, por qué se construyó de esa manera, qué evidencias lo respaldan, qué puede salir mal y quién es responsable, la documentación técnica es el material que debería poder inspeccionar.
Por qué importa
La gobernanza de la IA falla con frecuencia en el momento en que alguien solicita pruebas. Un consejo de administración quiere saber quién aprobó un caso de uso. Un comprador pide evidencias de las pruebas realizadas. Un regulador pregunta cómo se obtuvieron los datos, qué limitaciones se identificaron o qué cambió entre versiones. Si los únicos artefactos disponibles son presentaciones, eslóganes de política o materiales de marketing de proveedores, la organización dispone de muy pocas evidencias defendibles.
Una buena documentación técnica también facilita el control cotidiano. Apoya la diligencia debida en la adquisición, ayuda a los revisores humanos a comprender los límites del sistema, agiliza la respuesta ante incidentes y ofrece a los equipos de aseguramiento y auditoría algo concreto sobre lo que trabajar. Cuando un sistema se desvía, se vuelve a entrenar o es cuestionado por un usuario, el paquete de documentación suele marcar la diferencia entre una revisión manejable y una búsqueda costosa y urgente.
Cómo funciona
Es un paquete, no un artefacto único
En la gobernanza formal de la IA, la documentación técnica combina normalmente varias capas de evidencia: una descripción general del sistema, el propósito previsto, registros de versiones y dependencias, notas de arquitectura, métodos de desarrollo, procedencia de los datos, supuestos, evidencias de validación y pruebas, métricas de rendimiento, límites conocidos, diseño de supervisión humana, controles de seguridad, instrucciones para quienes despliegan el sistema, planes de supervisión, historial de cambios y registros de incidentes. La combinación exacta varía según el sistema y el sector, pero la idea rectora es estable: otra persona competente debe poder entender qué es el sistema, cómo funciona, qué evidencias lo respaldan, qué riesgos se consideraron y qué límites operativos se aplican.
La ley puede convertir el paquete en una obligación de cumplimiento específica
El ejemplo legal más claro es el EU AI Act. Para los sistemas de IA de alto riesgo, los proveedores deben elaborar documentación técnica suficientemente clara y completa para que las autoridades y los organismos notificados puedan evaluar el cumplimiento. El Anexo IV lo convierte en una estructura de archivo concreta que abarca el propósito previsto, las interfaces, las versiones de software, las decisiones de diseño, la obtención y curación de datos, la validación y las pruebas, la supervisión humana, la ciberseguridad, las métricas de rendimiento, la gestión de riesgos, los cambios en el ciclo de vida y la supervisión poscomercialización. El AI Act también vincula este archivo al mantenimiento de registros y logs. Los proveedores deben mantener la documentación técnica disponible durante 10 años tras la comercialización o puesta en servicio de un sistema de alto riesgo. Los sistemas de alto riesgo deben permitir el registro automático, y los logs deben conservarse en general durante al menos seis meses cuando estén bajo el control del proveedor o del responsable del despliegue. Los importadores deben verificar que la documentación existe, y los organismos notificados pueden solicitar evidencias adicionales, pruebas y, en algunos casos, acceso a los datos o modelos.
La misma disciplina alcanza ahora a los modelos de uso general
La obligación de documentación ya no se limita a las aplicaciones derivadas. En virtud del EU AI Act, los proveedores de modelos de IA de uso general deben mantener documentación técnica sobre el modelo, incluidos el entrenamiento, las pruebas y la evaluación, y también deben proporcionar documentación separada a los proveedores que integren el modelo en sus propios sistemas. Un resumen público sobre el contenido del entrenamiento es solo una capa. El archivo interno más amplio puede incluir políticas de uso aceptable, arquitectura, información sobre parámetros, procedencia de los datos, métodos de entrenamiento, cómputo utilizado, resultados de evaluación y, para los modelos con riesgo sistémico, pruebas de adversario internas o externas y detalles de adaptación del modelo. Esto importa porque una divulgación pública breve no es suficiente para respaldar el cumplimiento de los proveedores derivados ni la revisión por parte de las autoridades.
Los marcos y estándares utilizan la documentación para hacer real la rendición de cuentas
Fuera del ámbito de la legislación prescriptiva, los principales marcos y estándares tratan la documentación como un control fundamental. NIST considera que los requisitos legales, los roles y responsabilidades, los límites del sistema, los métodos de prueba, el linaje de los datos, la gestión de incidentes y la revisión continua son aspectos que deben documentarse a lo largo del ciclo de vida. Los Principios de IA de la OECD vinculan la rendición de cuentas a la trazabilidad de los conjuntos de datos, los procesos y las decisiones, de modo que las organizaciones puedan responder preguntas posteriormente y facilitar impugnaciones o investigaciones. Los estándares internacionales añaden la misma disciplina en una forma diferente, orientando a las organizaciones a documentar impactos, controles y mejora continua a lo largo del ciclo de vida. La lógica compartida es sencilla: la rendición de cuentas en IA no es creíble sin trazabilidad.
Genera evidencias en cada etapa del ciclo de vida
La documentación técnica comienza antes de que finalice el entrenamiento del modelo o la adquisición. Los registros iniciales suelen capturar el problema que se aborda, los usuarios previstos, la base legal, las restricciones, las necesidades de datos y el proceso de aprobación. Los registros posteriores recogen las decisiones de diseño, los detalles de entrenamiento o configuración, los métodos de prueba, las métricas, las comprobaciones de sesgo y robustez, los controles de seguridad, las instrucciones para usuarios y los planes de supervisión. Tras el despliegue, el paquete crece de nuevo con logs, registros de incidentes, excepciones, acciones correctivas, registros de cambios y decisiones de retirada. El proceso del gobierno federal de Canadá lo explicita: la Evaluación de Impacto Algorítmico se realiza durante el diseño, se repite antes de la puesta en producción, se publica y se revisa de nuevo cuando cambia la funcionalidad o el alcance. Las directrices de revisión por pares construyen entonces un paquete de apoyo más amplio en torno a esa evaluación, que incluye registros del sistema, pistas de auditoría, detalles de adquisición y evidencias sobre privacidad, seguridad y equidad.
Los artefactos de cara al público se sitúan sobre el archivo más profundo
Los artefactos de cara al público, como las fichas de modelo, las fichas de sistema y los registros de transparencia gubernamentales, son útiles, pero son resúmenes. Ayudan a usuarios, personas afectadas, compradores y al público en general a entender un sistema a alto nivel. Normalmente no contienen la evidencia técnica y de gobernanza completa necesaria para el aseguramiento, la auditoría, la adquisición, la respuesta ante incidentes o la revisión regulatoria. Una buena estrategia de documentación separa por tanto las capas: explicación pública, divulgación controlada para contrapartes y autoridades, y el paquete de evidencias internas más completo. En el sector público del Reino Unido, la política actual ilustra esta división. Los organismos de la administración central en el ámbito de aplicación deben utilizar el Algorithmic Transparency Recording Standard para la transparencia pública, y el AI Playbook también apunta a un inventario de sistemas de IA. Eso es útil para la apertura, pero no sustituye al archivo técnico más profundo.
La titularidad es compartida, aunque la responsabilidad esté asignada
Normalmente debe haber un responsable de alto nivel que rinda cuentas de la integridad y el mantenimiento del paquete, pero ningún equipo puede producirlo en solitario. Los equipos de ingeniería gestionan la arquitectura, el control de versiones y los registros de pruebas. Los equipos de datos gestionan la procedencia y los controles de calidad. Los equipos de seguridad gestionan las evidencias de amenazas y controles. Los equipos jurídicos y de cumplimiento hacen seguimiento de las obligaciones y aprobaciones. Los equipos operativos gestionan los logs, los incidentes y los registros de cambios. El paquete funciona mejor cuando esas contribuciones están bajo control de versiones, vinculadas y actualizadas a través de los procesos ordinarios de gobernanza, en lugar de ensamblarse con urgencia justo antes de una adquisición, auditoría o contacto con la autoridad supervisora. La responsabilidad ejecutiva importa, pero las evidencias siguen siendo distribuidas.
Ejemplos
Ejemplo de legislación vigente: una organización que comercializa en el mercado de la UE un sistema de IA de alto riesgo para la selección de personal necesita un expediente técnico antes de la comercialización o puesta en servicio. Ese expediente debe describir el propósito previsto, el diseño del sistema, los datos, las pruebas, la supervisión, la ciberseguridad, la gestión de riesgos y la supervisión poscomercialización, y debe mantenerse disponible durante 10 años. Si una evaluación de la conformidad implica a un organismo notificado, este puede solicitar evidencias adicionales, pruebas adicionales y, cuando sea necesario y esté legalmente justificado, acceso a los conjuntos de datos de entrenamiento, validación y prueba, e incluso a los modelos entrenados. El expediente técnico forma parte, por tanto, del mecanismo de conformidad, no es un documento de relaciones públicas.
Ejemplo de legislación vigente: un proveedor de un modelo de IA de uso general en la UE necesita al menos dos capas de documentación. Una es la documentación técnica para la Oficina de IA y las autoridades nacionales competentes. La otra es la documentación para los proveedores derivados, de modo que puedan comprender las capacidades y los límites del modelo y cumplir con sus propias obligaciones. Un resumen público de los datos de entrenamiento se sitúa junto a esos registros internos, no en su lugar. Para los modelos con riesgo sistémico, la estrategia de evaluación y los registros de pruebas de adversario también forman parte del expediente.
Ejemplo de política vigente: un departamento federal canadiense que introduce un sistema automatizado de decisiones administrativas completa una Evaluación de Impacto Algorítmico al inicio del diseño y de nuevo antes de la puesta en producción. Si al sistema se le asigna un nivel de impacto 2 o superior, debe someterse a revisión por pares, respaldada por documentación sobre roles, aprobaciones, funcionalidad del sistema, detalles del modelo, pistas de auditoría, procedencia de los datos, comprobaciones de equidad, privacidad, seguridad y adquisición. La revisión, o un resumen en lenguaje claro cuando la divulgación completa sea limitada, se publica antes de que el sistema entre en funcionamiento. Este es un ejemplo práctico de documentación que respalda el uso gubernamental, el escrutinio entre pares y la visibilidad pública.
Malentendidos frecuentes
La documentación técnica de IA es simplemente una ficha de modelo. No lo es. Una ficha de modelo es un artefacto de resumen, mientras que la documentación técnica es la base de evidencias más completa que subyace a ese resumen.
Solo los ingenieros necesitan preocuparse por ella. No es así. La documentación suele abarcar equipos de producto, datos, jurídico, cumplimiento, seguridad, adquisición y operaciones.
Solo importa si se construye un modelo propio. Es un error. Las organizaciones que compran o integran IA de terceros siguen necesitando evidencias suficientes para comprender las capacidades, los límites, los controles y los avisos de cambios.
Puede redactarse al final del proyecto. En la práctica, los registros más valiosos deben capturarse en el momento en que se toman las decisiones. La reconstrucción tras el lanzamiento es lenta, incompleta y a menudo imposible.
Si ninguna norma prescribe una plantilla, la cuestión es opcional. No realmente. Compradores, organismos públicos, auditores, aseguradoras, comités de revisión internos y supervisores sectoriales pueden seguir esperando un paquete de evidencias revisable aunque la ley no especifique un formato concreto.
Riesgos y límites
La documentación técnica no es una solución universal. Un sistema mal diseñado o ilegal no se vuelve aceptable por estar bien documentado. El paquete acredita lo que se hizo y facilita la revisión; por sí solo no justifica un caso de uso débil, datos deficientes o una supervisión humana inadecuada.
El paquete tampoco equivale a transparencia pública. Cierta información debe publicarse en lenguaje claro para que las personas puedan entender o impugnar las decisiones asistidas por IA. Otra información puede requerir acceso controlado por razones de privacidad, seguridad, secreto comercial o propiedad intelectual. La tarea práctica consiste en separar estas capas sin dejar lagunas para los equipos de aseguramiento o las autoridades.
El estatus legal también varía según el instrumento. El EU AI Act establece obligaciones de documentación vinculantes para determinados sistemas de alto riesgo y para los modelos de IA de uso general en su ámbito de aplicación. La Evaluación de Impacto Algorítmico y las normas de revisión por pares de Canadá se aplican en el contexto administrativo federal. Los registros de transparencia del sector público del Reino Unido se aplican en entornos del sector público definidos. NIST, OECD e ISO proporcionan lógica de gobernanza y disciplina de implementación, pero no son normas con fuerza de ley por sí mismos. Los detalles también pueden seguir evolucionando a medida que los reguladores publiquen orientaciones, códigos, estándares y formularios simplificados. Esto significa que las organizaciones deben tratar el paquete como un control vivo, no como una plantilla congelada que se copia una sola vez.
Las normas sectoriales específicas pueden añadir capas adicionales. La salud, las finanzas, el empleo, la administración pública y los productos de seguridad crítica pueden imponer obligaciones adicionales de registro, validación o conservación. Este artículo explica el concepto central duradero, no sustituye a una lista de verificación de cumplimiento específica para cada jurisdicción.
Qué hacer a continuación
Determinar qué usos de IA en la organización requieren un paquete de documentación formal, utilizando el riesgo, la exposición legal, el impacto en las personas y la dependencia de proveedores externos como criterios de activación.
Designar un responsable de alto nivel, pero hacer que el modelo de evidencias sea interfuncional. Los equipos de ingeniería, datos, seguridad, jurídico, cumplimiento, adquisición y operaciones deben ser propietarios de los registros que realmente generan.
Establecer una estructura mínima para cada uso material de IA: propósito previsto, límites de alcance, versiones y proveedores, procedencia de los datos, evidencias de pruebas, diseño de supervisión humana, controles de seguridad, plan de supervisión, logs, historial de cambios y plan de retirada o contingencia.
Separar las capas. Mantener un archivo técnico interno más completo, preparar un conjunto de evidencias listo para revisión y publicar resúmenes públicos proporcionados cuando las obligaciones de transparencia o las consideraciones de confianza lo justifiquen.
Incorporar activadores de actualización a las operaciones ordinarias. El reentrenamiento, los cambios de instrucciones o políticas, las actualizaciones de proveedores, los informes de incidentes, las reclamaciones relevantes y los cambios de alcance deben activar la revisión de la documentación.
Al adquirir IA, contratar evidencias, no solo acceso. Solicitar documentación utilizable sobre arquitectura, procedencia, pruebas, límites, gestión de incidentes, cambios relevantes y conservación.
¿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
¿La documentación técnica de IA es lo mismo que una ficha de modelo?
No. Una ficha de modelo suele ser un resumen explicativo conciso. La documentación técnica es el paquete más amplio de evidencias, registros y controles que subyace a ese resumen.
¿Quién debe ser responsable de la documentación técnica de IA?
Un responsable de alto nivel debe rendir cuentas de la integridad y el mantenimiento, pero el contenido en sí suele provenir de varios equipos, incluidos ingeniería, datos, jurídico, seguridad y operaciones.
¿Cuándo debe comenzar la documentación?
En la definición del problema o en la adquisición, no tras el lanzamiento. Muchos de los registros más importantes son las decisiones tempranas sobre propósito, base legal, datos, diseño y aprobación.
¿Todos los sistemas de IA necesitan la misma cantidad de documentación?
No. El paquete debe ser proporcional al riesgo, la sensibilidad, la escala, el sector y la exposición legal del sistema. Los usos de mayor riesgo requieren evidencias más profundas y una disciplina de actualización más rigurosa.
¿Qué ocurre si adquirimos IA de un proveedor externo?
Sigue siendo necesario contar con documentación suficiente para gobernar el sistema adecuadamente. Los contratos deben garantizar el acceso a evidencias de pruebas, límites conocidos, avisos de cambios, procesos de gestión de incidentes y otros registros relevantes.
¿Qué parte de la documentación debe ser pública?
La suficiente para respaldar la transparencia, la comprensión y la posibilidad de impugnación cuando corresponda. El archivo técnico más completo normalmente permanecerá como interno o se compartirá solo bajo acceso controlado.
¿Durante cuánto tiempo deben conservarse los registros?
Depende del régimen aplicable y del contexto del sistema. Por ejemplo, el EU AI Act exige que la documentación técnica de los sistemas de IA de alto riesgo se conserve durante 10 años, y ciertos logs durante al menos seis meses cuando estén bajo el control del actor correspondiente.
Fuentes
National Institute of Standards and Technology. Establishes documentation, accountability, documented roles and responsibilities, ongoing review, and lifecycle risk management as core governance practices for AI systems.
National Institute of Standards and Technology. Shows how documentation supports explainability, data and content lineage, impact documentation, incident logging, version history, change management and downstream integration in generative AI contexts.
EUR-Lex, European Union. Provides the binding EU duties on technical documentation for high-risk AI systems and general-purpose AI models, including Annex IV and Annex XI content, retention, logging, post-market monitoring and regulator access.
Treasury Board of Canada Secretariat, Government of Canada. Demonstrates a concrete public sector workflow in which AI impact assessment begins early, is updated before production, is published, and draws on broad project, system, algorithm, impact and data information.
Treasury Board of Canada Secretariat, Government of Canada. Shows the supporting documentation expected for peer review, including roles, approvals, system records, audit trails, data provenance, fairness analysis, security, procurement and publication of review material.
Organisation for Economic Co-operation and Development. Provides the intergovernmental principles on transparency, responsible disclosure, accountability and traceability of datasets, processes and decisions across the AI lifecycle.
International Organization for Standardization. Adds the standards perspective that organisations should identify, evaluate and document potential impacts throughout the AI system lifecycle to support transparency, accountability and trust.
UK Government, Department for Science, Innovation and Technology. Supports the distinction between public-facing transparency records and deeper internal governance evidence, including the requirement for in-scope bodies to use the Algorithmic Transparency Recording Standard and keep an AI systems inventory in addition.