Expediente técnico de IA: qué es, qué debe incluir y cómo prepararlo antes de que sea obligatorio

El AI Act exige que todo sistema de IA de alto riesgo disponga de un expediente técnico completo. Te explicamos las 16 secciones que debe incluir, cómo se conecta con la FRIA y la DPIA, y una estrategia práctica para empezar a documentar tus sistemas hoy

Cuando se habla del AI Act, la conversación suele centrarse en la clasificación de riesgos o en las sanciones. Pero hay una obligación menos visible que va a exigir un esfuerzo operativo enorme a las empresas: el expediente técnico.

El expediente técnico es la documentación completa de un sistema de IA. No es un resumen ejecutivo ni una ficha de producto. Es un dossier exhaustivo que describe qué hace el sistema, cómo funciona, qué datos usa, cómo se evalúa, quién lo supervisa, cómo se asegura y qué pasa cuando falla. Para los sistemas de alto riesgo, tener este expediente actualizado no es una buena práctica: es una obligación legal.

El problema es que la mayoría de las empresas no documentan sus sistemas de IA con este nivel de detalle. Tienen código en repositorios, modelos en producción, configuraciones dispersas y conocimiento distribuido en la cabeza de sus ingenieros. Convertir todo eso en un expediente técnico estructurado requiere tiempo, proceso y una plantilla clara.

En este artículo te explicamos qué es el expediente técnico, por qué lo exige el AI Act, qué secciones debe incluir y cómo empezar a construirlo aunque tus sistemas ya estén en producción.

Qué es el expediente técnico y por qué lo necesitas

El expediente técnico es el documento central de la documentación de compliance de un sistema de IA. El AI Act lo exige para todos los sistemas de alto riesgo (tanto para proveedores como para deployers) y debe estar disponible para las autoridades de supervisión si lo solicitan.

Su objetivo es triple:

• Trazabilidad: Permite reconstruir cómo funciona el sistema, con qué datos fue entrenado o configurado, qué métricas se usan para evaluarlo y quién toma las decisiones sobre su despliegue.
• Rendición de cuentas: Documenta las decisiones técnicas y organizativas: por qué se eligió ese modelo, por qué se fijaron esos umbrales, quién aprobó el paso a producción.
• Continuidad operativa: Si el responsable del sistema cambia de puesto o de empresa, el expediente permite a cualquier persona con el perfil adecuado entender, mantener y auditar el sistema.

El expediente técnico no es un trámite. Es la memoria institucional de tu sistema de IA.

Las 16 secciones del expediente técnico

Basado en los requisitos del AI Act y las mejores prácticas de gobernanza IA, un expediente técnico completo incluye las siguientes secciones:

Bloque 1: Identificación y contexto (secciones 0-2)

1. Portada y metadatos. Nombre del sistema, versión, fecha, product owner, responsable de despliegue, proveedor, DPO, CISO. Estado del sistema (diseño, piloto, producción, retirado). Normativa aplicable: RGPD, AI Act, DSA, DMA, NIS2.
2. Finalidad y límites. Propósito del sistema, procesos soportados, población y canales incluidos y excluidos, supuestos de abstención. Uso previsto según las instrucciones del proveedor. Cambios sustanciales que requieren reevaluación.
3. Clasificación y rol AI Act. Rol de la organización (proveedor, deployer, importador, distribuidor). Clasificación del sistema (prohibido, alto riesgo Anexo III, alto riesgo embebido Anexo I, limitado, mínimo). Evaluaciones requeridas: DPIA sí/no, FRIA sí/no.

Bloque 2: Arquitectura y datos (secciones 3-5)

1. Arquitectura y entornos. Diagrama end-to-end del sistema. Descripción de componentes, dependencias externas y puntos de control. Endpoints por entorno (desarrollo, staging, producción). Modo degradado y continuidad: RTO, RPO, evidencia de ensayo.
2. Datos y gobernanza. Inventario de datasets: origen, si contienen datos personales o sensibles, base legal del tratamiento, representatividad, retención, transferencias, data owner. Enlaces a DPIA y acuerdos de tratamiento de datos (DPA).
3. Método y configuración del sistema. Técnica utilizada (modelo supervisado, RAG, agente, etc.), proveedor, ID/versión del modelo, parámetros clave, guardrails y políticas. Para sistemas RAG: top-k, reranking, ventanas contextuales, plantillas de prompt.

Bloque 3: Evaluación y supervisión (secciones 6-8)

1. Evaluación, métricas y umbrales. Métricas con fórmula, dataset de evaluación, objetivo, umbral y trigger operativo (revisión o rollback). Frecuencia de evaluación y responsable. Esto es el corazón técnico del expediente.
2. Supervisión humana. Puntos de control donde interviene un humano. Para cada punto: condición de activación, acción humana, nivel de autoridad, evidencia generada, SLA.
3. Logging y trazabilidad. Qué se registra en cada interacción: entrada, contexto, pasajes citados (si es RAG), salida, puntuaciones, decisión, usuario/agente. Retenciones, accesos y ubicación de los logs.

Bloque 4: Seguridad y transparencia (secciones 9-10)

1. Seguridad y continuidad (NIS2/DR-BCP). Controles de seguridad con evidencias, periodicidad, responsable y estado. RTO, RPO, resultados de ensayos de recuperación, modo degradado.
2. Transparencia e información al usuario. Textos de aviso de IA, detectabilidad de contenido sintético, páginas explicativas. Capturas y versiones de los avisos.

Bloque 5: Riesgos y cambios (secciones 11-14)

1. Riesgos y salvaguardas (resumen FRIA/DPIA). Resumen de riesgos identificados en la FRIA y la DPIA: riesgo, derecho afectado, severidad × probabilidad, medidas, riesgo residual, evidencia.
2. Gestión de cambios. Changelog con cada modificación relevante: ID, fecha, objeto del cambio, impacto esperado, evidencias de prueba, decisión.
3. Roles y responsabilidades (RACI). Matriz RACI para las actividades críticas: DPIA/FRIA, métricas, logging, seguridad, transparencia, changelog, deploy.
4. Incidentes y post-market monitoring. Registro de incidentes con fecha, descripción, severidad, acción correctiva, cierre. Enlace a post-mortems.

Bloque 6: Cierre (secciones 15-16)

1. Anexos y enlaces. Inventario de documentos vinculados: métricas, checklists, evidencias RAG, changelog, runbook de incidentes, DPA, DPIA, FRIA.
2. Aprobaciones. Firmas del product owner, data owner/ML, legal/DPO, seguridad/CISO y dirección. Fecha de aprobación y trigger de revisión.

Clave: El expediente debe completarse antes de la Puerta 2 (Gate 2, pre-despliegue) del sistema de gobernanza IA. Y debe actualizarse ante cambios sustanciales o tras la ventana de estabilización post go-live.

Ejemplo: qué incluiría el expediente de un chatbot RAG de atención al cliente

Para hacerlo tangible, veamos cómo se aplicaría el expediente a un chatbot RAG de atención al cliente en un ecommerce. Este sistema usa IA generativa para responder consultas de clientes sobre pedidos, devoluciones y productos, basado en una base de conocimiento interna.

• Clasificación: Riesgo limitado (no está en el Anexo III, pero interactúa directamente con consumidores). Requiere transparencia: el usuario debe saber que habla con una IA.
• Arquitectura: Base de conocimiento indexada (documentos de políticas, FAQ, catálogo de productos) → búsqueda vectorial (top-k=5) → reranking → LLM con prompt de sistema que incluye instrucciones de grounding → respuesta al usuario.
• Métricas clave: Faithfulness (fidelidad al contexto) ≥ 90%, tasa de alucinaciones < 5%, satisfacción del usuario (CSAT) ≥ 4,0/5, tasa de escalado a agente humano < 15%.
• Supervisión humana: Escalado automático cuando el chatbot detecta intención de reclamación formal, solicitud de reembolso superior a 200€ o tres preguntas consecutivas sin respuesta satisfactoria.
• Transparencia: Banner visible: «Este asistente usa inteligencia artificial. Para hablar con un agente, escribe AGENTE». Detectabilidad de contenido sintético si se generan imágenes o resúmenes.
• Seguridad: Prompt injection testing periódico, guardrails contra la generación de información sobre temas no relacionados con el negocio, filtrado de datos personales en los logs.

Aunque este sistema no sea de alto riesgo, documentarlo con el expediente técnico es una buena práctica que facilita el mantenimiento, la auditoría interna y la demostración de diligencia si surge un problema.

Los errores que más vemos al documentar sistemas de IA

• Documentación retrospectiva: El sistema lleva meses en producción y nadie ha documentado nada. Reconstruir el expediente desde cero es posible pero caro en tiempo y esfuerzo.
• Documentación estática: Se crea el expediente una vez y no se actualiza. Un expediente desactualizado es peor que no tenerlo, porque genera una falsa sensación de cumplimiento.
• Foco solo en el modelo: El expediente no es solo la ficha del modelo de IA. Incluye datos, seguridad, supervisión humana, transparencia, incidentes y gobernanza organizativa.
• Sin métricas ni umbrales: Un expediente sin métricas evaluables es un documento descriptivo, no un instrumento de control. Necesitas saber cuándo el sistema funciona bien y cuándo no.
• Desconectado de la FRIA: El expediente técnico y la FRIA deben estar vinculados. Los riesgos identificados en la FRIA deben reflejarse en la sección 11 del expediente con sus salvaguardas.

Estrategia práctica: cómo empezar sin paralizarte

No necesitas documentar todo de golpe. La estrategia más efectiva es progresiva:

1. Semana 1-2: Inventario. Lista todos los sistemas de IA en uso o en desarrollo. Para cada uno, identifica: nombre, responsable, estado (diseño/piloto/producción), clasificación AI Act preliminar.
2. Semana 3-4: Priorización. Clasifica cada sistema según el AI Act. Los de alto riesgo (Anexo III) necesitan expediente completo. Los de riesgo limitado, documentación proporcional.
3. Mes 2: Portada + Clasificación + Arquitectura. Completa las secciones 0-3 de los sistemas priorizados. Son las más fáciles porque la información ya existe, solo hay que estructurarla.
4. Mes 3: Datos + Método + Métricas. Completa las secciones 4-6. Esta es la parte técnica densa: requiere coordinación con los equipos de datos e ingeniería.
5. Mes 4: Supervisión + Seguridad + Transparencia. Secciones 7-10. Aquí entran los equipos de operaciones, seguridad y legal.
6. Mes 5: Riesgos + Gobernanza + Aprobaciones. Secciones 11-16. Vincula con la FRIA y la DPIA, establece el RACI y obtiene las aprobaciones.

Si empiezas hoy con esta cadencia, en 5 meses tienes los expedientes de tus sistemas críticos completos. Eso te deja margen antes de agosto de 2026.

El expediente dentro del marco de gobernanza IA

El expediente técnico no vive aislado. En el modelo de los 5 Pilares de la AI Transformación, es una pieza central del Pilar de Compliance y se conecta con todo el ecosistema de gobernanza:

• Gates (puertas de control): El expediente se inicia en la Gate 1 (aprobación del proyecto) y debe estar completo para la Gate 2 (pre-despliegue). En la Gate 3 (post-despliegue), se verifica que está actualizado.
• FRIA y DPIA: El expediente las integra en su sección 11 y las referencia en los anexos. No las sustituye: las complementa con la dimensión técnica.
• AI Steering Committee: El comité de IA revisa el expediente como parte de la decisión GO/FIX/KILL. Un expediente incompleto es argumento para un FIX.
• Política IA Lite: Los principios de observabilidad y reversibilidad de la política se operativizan en las secciones de logging (8) y modo degradado (9) del expediente.

Quién debe participar en la elaboración del expediente

Un error frecuente es asumir que el expediente técnico es responsabilidad exclusiva del equipo de datos o ingeniería. En realidad, requiere la participación coordinada de múltiples perfiles:

• Product Owner / responsable de negocio: Define la finalidad, los límites de uso y los criterios de éxito del sistema. Responsable de las secciones 1 y 2.
• Data Engineer / ML Engineer: Documenta la arquitectura, los datos, el método, las métricas y el logging. Secciones 3-6 y 8.
• Legal / DPO: Valida la clasificación AI Act, la FRIA, la DPIA y los requisitos de transparencia. Secciones 2, 10 y 11.
• Seguridad / CISO: Documenta los controles de seguridad, la continuidad y los ensayos de recuperación. Sección 9.
• Operaciones: Define y documenta los puntos de supervisión humana, el runbook de incidentes y el modo degradado. Secciones 7 y 14.

La matriz RACI (sección 13) formaliza estas responsabilidades y es clave para que el expediente se mantenga vivo después de su creación inicial.

Conclusión: documenta hoy lo que mañana será obligatorio

El expediente técnico es probablemente la obligación del AI Act que más esfuerzo operativo requiere. No se resuelve con un documento genérico: cada sistema necesita su propio expediente, con datos específicos, métricas reales y decisiones documentadas.

La buena noticia es que la mayor parte de la información ya existe en tu organización. El reto es estructurarla, centralizarla y mantenerla actualizada. Con la plantilla de 16 secciones y una cadencia progresiva, puedes tener tus expedientes listos antes de que la obligación entre en vigor.

Si necesitas ayuda para construir los expedientes técnicos de tus sistemas de IA, definir las métricas de evaluación o integrar la documentación en tu marco de gobernanza, en Impulsa3 tenemos la plantilla, la metodología y la experiencia para acompañarte.

impulsa3.com · Transformación Digital e IA para pymes y ecommerce · servicios@impulsa3.com