Documentación técnica: Guía práctica para equipos SaaS

La documentación técnica de un sistema de IA no es un resumen de arquitectura preparado al final del proyecto. Es el paquete controlado de evidencias que explica qué debe hacer el sistema, cómo se construyó, qué datos y modelos utiliza, cómo rinde, qué riesgos se identificaron, qué controles los abordan y cómo se gestionan los cambios posteriores al lanzamiento.

Para los proveedores de sistemas de IA de alto riesgo, el artículo 11 del AI Act exige crearla antes de introducir el sistema en el mercado o ponerlo en servicio, mantenerla actualizada y redactarla con claridad suficiente para que autoridades y organismos notificados evalúen la conformidad. El anexo IV fija el contenido mínimo. Por eso, el equipo debe construir el expediente durante el desarrollo a partir de registros de producto, ingeniería, datos, seguridad, legal y calidad, no reconstruirlo durante una auditoría.

La obligación no se aplica automáticamente a toda función con IA. El alcance depende de la clasificación y del papel de la empresa. El primer paso es documentar ambos y ajustar el expediente a las obligaciones y al riesgo reales.

Por qué importa en la práctica

Una buena documentación permite comprobar que las pruebas corresponden a la finalidad prevista, rastrear respuestas a clientes hasta evidencias controladas y decidir si un cambio de modelo, datos, umbral o flujo exige una nueva evaluación. También ofrece a un evaluador un relato coherente en lugar de capturas sin contexto.

Debe conectar requisitos de producto, diagramas, model cards, linaje de datos, evaluaciones, registro de riesgos, pruebas de seguridad, supervisión humana, logs, incidentes, aprobaciones de releases y seguimiento poscomercialización. Un índice central puede enlazar estos registros; no es necesario duplicarlos todos.

Este trabajo respalda las nuevas expectativas de gobernanza de IA para proveedores SaaS y hace coherentes las respuestas de ventas, seguridad, legal y producto.

Confirma el alcance antes de crear el expediente

Determina si el software es un sistema de IA, si es de alto riesgo y qué papel desempeña la empresa. Quien desarrolla y comercializa bajo su nombre puede ser proveedor. Quien utiliza el sistema de otro proveedor puede ser responsable del despliegue, aunque un cambio sustancial, un rebranding o una nueva finalidad pueden alterar ese análisis.

La clasificación de alto riesgo puede surgir por el artículo 6.1 y el anexo I para productos regulados o componentes de seguridad, o por un caso de uso del anexo III bajo el artículo 6.2. La Comisión publicó en mayo de 2026 directrices provisionales de clasificación: son material interpretativo útil, pero no derecho vinculante.

Los plazos también cambiaron. El Reglamento (UE) 2026/1744 dispone que las secciones 1, 2 y 3 del capítulo III, incluido el artículo 11, se apliquen desde el 2 de diciembre de 2027 a sistemas del anexo III y desde el 2 de agosto de 2028 a sistemas del anexo I. Otras leyes, contratos, reglas de producto o compromisos con clientes pueden exigir evidencias similares antes.

No confundas este expediente con las obligaciones separadas de los proveedores de modelos de IA de propósito general del artículo 53 y anexo XI. La información del proveedor del modelo es un insumo; el proveedor SaaS debe explicar el sistema completo, su integración, finalidad, controles y rendimiento evaluado.

Qué espera el anexo IV

Conviene usarlo como mapa de cobertura:

1. Identidad y finalidad: proveedor, nombre, versión, usuarios, finalidad, modalidad de entrega, interfaces, dependencias y UI.
2. Desarrollo: métodos, componentes de terceros o preentrenados, selección de modelo, objetivos, supuestos y decisiones clave.
3. Arquitectura: componentes, interacción, recursos computacionales y justificación de decisiones técnicas.
4. Datos: procedencia, selección, etiquetado, limpieza, gobierno, limitaciones y datos de entrenamiento, validación, prueba o recuperación.
5. Capacidades y límites: métricas, precisión, robustez, ciberseguridad, resultados no deseados previsibles y condiciones de degradación.
6. Pruebas: protocolos, datos, métricas, umbrales, fechas, versiones, resultados, fallos y correcciones.
7. Riesgo y supervisión: gestión de riesgos, mitigaciones, riesgo residual, supervisión humana e instrucciones.
8. Ciclo de vida: versiones, logging, cambios, mantenimiento, incidentes y seguimiento poscomercialización.
9. Conformidad: normas, especificaciones, declaración UE de conformidad y documentación del organismo notificado cuando corresponda.

Cada afirmación debe llevar a una evidencia. “El sistema es robusto” no basta; sí resulta auditable una referencia a un informe, métrica aprobada, dataset, versión y limitación residual concretos.

Flujo operativo

1. Crea un índice controlado

Incluye una fila por elemento del anexo IV con requisito, aplicabilidad, artefacto fuente, responsable, versión, aprobación, última revisión y próximo disparador. Un “no aplicable” necesita justificación y aprobación. El control de acceso, historial y referencias estables importa más que la herramienta.

2. Asigna la evidencia a quien la genera

Producto debe cubrir finalidad, usuarios, contexto y usos indebidos previsibles. Ingeniería, arquitectura, dependencias, versiones e historial. Datos o ML, linaje, desarrollo, evaluaciones y límites. Seguridad, amenazas, acceso, resiliencia y vulnerabilidades. Legal y compliance, clasificación, roles, mapeo regulatorio y gobierno documental. Una persona coordina el expediente sin reescribir hechos técnicos que no puede verificar.

3. Fija la línea base antes de probar

Define finalidad y versión antes de aceptar resultados. Registra modelos, prompts o instrucciones relevantes, fuentes de recuperación, feature flags, umbrales, dependencias y entorno. En sistemas probabilísticos, conserva la versión del dataset, método, umbral de aceptación, fecha y resultados reproducibles; explica las limitaciones con claridad.

4. Conecta riesgos, controles y pruebas

Cada riesgo material debe enlazar con una mitigación, un responsable y evidencia de eficacia. Si el control es la revisión humana, documenta quién revisa, qué información recibe, si puede anular la salida, cómo escala excepciones y cómo se verifica que la revisión ocurre.

5. Integra la documentación en releases

Todo release material debe evaluar su impacto documental. Cambios de finalidad, modelo, datos, umbral, usuarios, geografía, integraciones, supervisión o controles pueden exigir nuevas pruebas y actualizar riesgos, instrucciones y análisis de conformidad. El registro de release debe indicar qué cambió y qué siguió siendo válido.

Lista mínima de evidencias

Antes de una revisión formal, el equipo debe recuperar:

• descripción, finalidad, papel y clasificación aprobados
• diagramas actuales de arquitectura y flujo de datos con versiones
• registro de modelos, librerías, APIs y dependencias relevantes
• procedencia y gobierno de datos de entrenamiento, validación, prueba y recuperación
• planes de evaluación, métricas, umbrales, resultados, límites y decisiones
• riesgos vinculados a controles, pruebas, responsables y aceptación residual
• diseño de supervisión humana y evidencia de funcionamiento
• registros de seguridad, robustez, logging, incidentes y monitorización
• instrucciones y límites coherentes con el sistema probado
• historial de releases, evaluaciones de cambios y conformidad

Errores frecuentes

Partir de una plantilla vacía suele producir texto genérico sin evidencia. Una model card no describe el flujo SaaS completo. Los documentos del proveedor son insumos, no sustituyen la evaluación de la integración. Ocultar limitaciones es menos defendible que explicarlas con controles. Las revisiones por calendario no bastan: releases, incidentes, nuevos datos, usos y cambios regulatorios son disparadores. Por último, cuestionarios, páginas de producto, instrucciones, riesgos y expediente deben describir el mismo sistema.

Ejemplo: selección de candidatos asistida por IA

Si una función SaaS clasifica solicitudes de empleo para reclutadores, el expediente debe incluir finalidad, usos no admitidos, flujo del cliente, personas afectadas, datos, lógica de ranking, versiones, grupos evaluados, métricas, umbrales, revisión humana, logging, seguridad y monitorización.

Si una evaluación detecta menor recall para un grupo relevante, conserva resultado, análisis, mitigación, nueva prueba y decisión de riesgo residual. Un cambio posterior de modelo o umbral debe reabrir las evaluaciones, riesgos, supervisión e instrucciones relacionadas.

FAQ

¿Toda empresa SaaS necesita un expediente del anexo IV?

No. El artículo 11 y el anexo IV se refieren a sistemas de alto riesgo y la obligación principal recae en el proveedor. Aun así, un registro proporcionado ayuda en gobernanza, revisión de proveedores y assurance de clientes.

¿Se pueden reutilizar documentos de ingeniería?

Sí. Utiliza registros controlados y actuales, con un índice que demuestre cobertura. Evita copias que puedan divergir.

¿Quién debe ser responsable?

Una persona debe coordinar el expediente, mientras producto, ingeniería, ML/datos, seguridad, legal y compliance conservan la propiedad de sus evidencias.

¿Cuándo se actualiza?

Cuando cambien finalidad, versiones, datos, integraciones, usuarios, rendimiento, riesgos, controles o resultados de monitorización; también antes de releases materiales y después de incidentes.

¿Está disponible el formulario simplificado para pymes?

El artículo 11 prevé un formulario simplificado. Verifica siempre los materiales oficiales actuales antes de usar una plantilla. Mientras no exista un formulario aplicable, mantén un mapa completo del anexo IV con evidencias proporcionales.

Fuentes

• Reglamento (UE) 2024/1689, especialmente artículos 6, 9–17 y 43, y anexo IV.
• Reglamento (UE) 2026/1744 y los nuevos plazos de aplicación.
• Proyecto de directrices de la Comisión sobre clasificación de sistemas de alto riesgo, mayo de 2026.
• Directrices de la Comisión para proveedores de modelos de IA de propósito general.