Registro y conservación: guía práctica para equipos SaaS

El registro y la conservación son controles de trazabilidad según el Reglamento de IA de la UE, no una orden de recopilar para siempre todos los datos posibles. Para los sistemas de IA de alto riesgo, el artículo 12 exige que el sistema permita técnicamente el registro automático de eventos durante todo su ciclo de vida. Proveedores y responsables del despliegue deben conservar los registros generados automáticamente bajo su control durante un periodo adecuado a la finalidad prevista y, por regla general, al menos seis meses, salvo que otra norma aplicable disponga lo contrario.

Estas obligaciones no se aplican automáticamente a toda función de IA ni a toda empresa SaaS. El equipo debe identificar primero el sistema, su finalidad prevista, su propio rol y si es de alto riesgo. También debe distinguir los registros controlados por el proveedor de aquellos controlados por un cliente o proveedor previo. Una vez delimitado el alcance, el objetivo es una cadena de evidencia proporcionada: un revisor autorizado debería poder conectar un evento material con la versión del sistema, el contexto de entrada y salida, la acción humana, el control y la decisión.

Aunque las disposiciones de alto riesgo todavía no sean aplicables, la misma disciplina apoya la investigación de incidentes, la supervisión de seguridad, las garantías a clientes, la gestión de cambios y decisiones de producto defendibles. La respuesta no es la vigilancia indiscriminada, sino un registro deliberado con finalidades, accesos, revisiones y límites de conservación definidos.

Empezar por el alcance, no por una plataforma de logs

Documente primero los límites del sistema: función de producto, modelos y servicios externos, finalidad, usuarios, personas afectadas, entradas, salidas, integraciones, entornos y decisiones influidas. Registrar solo la llamada a la API del modelo fundacional puede omitir datos de recuperación, reglas de negocio, anulaciones del usuario o acciones posteriores que definen el flujo SaaS completo.

Determine después el rol. Una empresa SaaS que desarrolla o comercializa un sistema de alto riesgo bajo su nombre puede ser proveedor. Un cliente que usa el sistema de otro proveedor puede ser responsable del despliegue. El cambio de marca, una modificación sustancial o un cambio de finalidad pueden trasladar responsabilidades. Los nombres contractuales no resuelven por sí solos el análisis jurídico.

Evalúe entonces la clasificación. El artículo 6 cubre sistemas asociados a productos del anexo I y casos del anexo III, sujetos a las condiciones y exclusiones del Reglamento. Una función que clasifica candidatos requiere un análisis distinto de una herramienta que redacta marketing interno. Registre razonamiento, revisor, fecha, supuestos y eventos que obliguen a reevaluar.

Para ampliar el contexto, consulte cómo la gobernanza de IA cambia las expectativas de compliance para proveedores SaaS.

Qué exige el Reglamento para sistemas de alto riesgo

Según el Reglamento de IA, el artículo 12 exige que los sistemas de alto riesgo permitan el registro automático de eventos durante su ciclo de vida. La funcionalidad debe ofrecer una trazabilidad adecuada a la finalidad prevista y ayudar a detectar situaciones de riesgo o modificaciones sustanciales, facilitar la vigilancia poscomercialización y permitir que los responsables del despliegue supervisen el funcionamiento.

Los eventos concretos dependen del sistema. Para determinados sistemas de identificación biométrica remota del anexo III, el artículo 12 fija información mínima adicional. Un equipo no debe copiar ese esquema especializado a un producto distinto y dar por cumplida la norma. Debe derivar los eventos de la finalidad, los riesgos, los límites de rendimiento, la supervisión humana, las instrucciones y el plan de vigilancia.

El artículo 19 obliga a los proveedores a conservar los registros automáticos bajo su control durante un periodo adecuado de al menos seis meses, salvo que el Derecho de la Unión o nacional aplicable, especialmente en protección de datos, disponga otra cosa. El artículo 26 establece un mínimo paralelo para los responsables del despliegue. Por tanto, «al menos seis meses» no es un permiso general para conservar indefinidamente todos los datos personales. Un calendario defendible debe conciliar trazabilidad, minimización, limitación del plazo, seguridad, normas laborales y sectoriales, contratos y necesidades de incidentes.

Tras el Reglamento (UE) 2026/1744, estos requisitos se aplican desde el 2 de diciembre de 2027 a los sistemas del anexo III y desde el 2 de agosto de 2028 a los sistemas de alto riesgo integrados en productos regulados del anexo I. El calendario de la Comisión Europea refleja estas fechas. La transición permite probar la arquitectura de evidencia en vez de reconstruirla justo antes de un lanzamiento o evaluación.

Qué debe registrarse

Un evento útil debe responder a una pregunta de revisión, no solo demostrar que un servidor funcionaba. Según riesgo y arquitectura, puede ser necesario capturar:

1. Sistema y versión: identificador estable, versión de modelo o componente, configuración, entorno y versión de producto.
2. Hora y correlación: marca temporal fiable, identificador de solicitud o transacción y enlaces entre eventos.
3. Contexto operativo: función, flujo previsto, rol de usuario o servicio y ajustes relevantes sin contenido innecesario.
4. Rastro de entrada y salida: referencias, hashes, resúmenes estructurados o copias protegidas suficientes para reconstruir un resultado cuando se justifique.
5. Supervisión humana: revisión, aprobación, rechazo, anulación, escalado y autoridad de quien actúa.
6. Controles y resultados: comprobaciones, umbrales, filtros, decisiones de acceso, errores, alternativas y éxito o fallo del control.
7. Cambios y supervisión: despliegues, cambios de modelo o datos, alertas de deriva, excepciones, incidentes, reclamaciones y correcciones.
8. Integridad: origen, historial de acceso, estado de conservación y transformaciones o borrado aplicados.

No almacene por defecto prompts completos, documentos cargados, respuestas o datos identificativos. A veces el contenido es esencial para investigar un resultado dañino; en otros casos basta un identificador seudónimo, hash, categoría, métrica o muestra protegida. Decida campo por campo conforme a finalidades y riesgos documentados.

Flujo operativo práctico

1. Crear una decisión de registro

Para cada sistema, registre límites, finalidad, rol, clasificación, obligaciones, objetivos de supervisión, categorías de datos y responsables. Identifique los logs controlados por la empresa y los dependientes de un proveedor o cliente. Indique supuestos pendientes y disparadores de revisión.

2. Relacionar preguntas con eventos

Empiece por lo que deberá responder: ¿qué versión produjo este resultado?, ¿se exigía y completó revisión humana?, ¿se activó un control?, ¿el uso respetó la finalidad?, ¿qué cambió antes de empeorar el rendimiento? Asigne a cada pregunta los campos mínimos fiables y su fuente.

3. Asignar responsabilidades durante el ciclo de vida

Ingeniería suele asumir instrumentación y calidad; seguridad, acceso, integridad, alertas y preservación; producto, flujo y cambios; datos o ML, identificadores de modelos, conjuntos y evaluaciones; privacidad, licitud y minimización; compliance, mapa de requisitos y revisión. Un responsable coordina sin inventar hechos de otros equipos.

4. Fijar acceso y conservación

Separe el acceso operativo del acceso de investigación. Aplique privilegio mínimo, autenticación, registro de accesos, cifrado y controles de exportación. Defina inicio del plazo, borrado normal, excepciones, aprobaciones para bloqueos y tratamiento de copias de seguridad. Si los registros de proveedor y responsable del despliegue difieren, documente responsabilidades y solicitudes lícitas.

5. Conectar la revisión a disparadores operativos

No espere a una reunión periódica. Revise tras cambios materiales en modelo, prompt, recuperación, umbral, fuente de datos, integración, finalidad o supervisión. Incidentes, quejas, rendimiento inesperado, uso no autorizado y avisos de proveedores también deben reabrir decisiones. Vincule el resultado con la versión de producción.

6. Probar reconstrucción y borrado

Pida a un revisor independiente reconstruir para un evento material la versión, los controles, las acciones humanas y el seguimiento. Después pruebe que los registros caducados se eliminan del almacén principal, analítica, exportaciones y copias. Tanto trazabilidad como borrado necesitan evidencia.

Errores habituales

Registrarlo todo por defecto. Más datos pueden crear riesgos de privacidad, seguridad, litigio y coste sin mejorar la trazabilidad.

Confundir telemetría con pista de auditoría de IA. Disponibilidad y errores rara vez identifican modelo, configuración, supervisión y evidencia de un resultado material.

Aplicar seis meses a todos los registros. El mínimo se refiere a logs automáticos de sistemas de alto riesgo bajo control del operador y queda sujeto a otras leyes.

Ignorar los límites de control. Un proveedor no conserva logs del responsable del despliegue que nunca recibe; este no debe suponer que el proveedor mantiene el contexto necesario.

Recopilar contenido sensible sin garantías. Prompts y salidas pueden contener datos personales, confidenciales o secretos de clientes. Minimice, separe, cifre y supervise el acceso.

Guardar registros imposibles de interpretar. Un código sin esquema, sincronización temporal, versión o correlación puede no servir durante una revisión.

Ejemplo: selección de personal asistida por IA

Un proveedor SaaS ofrece una función que clasifica candidaturas. El equipo registra finalidad, límites, rol y análisis de alto riesgo. El diseño conecta el modelo y configuración de producción con cada clasificación, referencias de entrada, salida y contexto de confianza, umbrales, avisos, revisión humana, anulación y acción final.

El acceso al contenido se limita a investigaciones autorizadas. La supervisión ordinaria usa datos agregados cuando sea posible. La decisión de conservación explica el artículo 19, las restricciones de datos personales, responsabilidades del cliente y plazos sectoriales superiores. Cambiar el modelo, umbral o revisión activa una evaluación y mantiene el vínculo entre evidencias anteriores y nuevas.

El diseño no garantiza por sí solo el cumplimiento. Sí permite comprobar si el sistema funcionó como se documentó, si hubo supervisión humana y si cambios e incidentes recibieron una respuesta responsable.

Preguntas frecuentes

¿Cuál es la finalidad práctica del registro y la conservación?

Hacer trazable la actividad material del sistema. Un registro útil conecta un evento con la versión, el contexto, los controles, las acciones humanas y el seguimiento sin recoger datos ajenos.

¿Cuándo se aplican las obligaciones a equipos SaaS?

Los artículos 12, 19 y 26 se refieren a sistemas de alto riesgo y asignan requisitos según rol y control. Confirme sistema, finalidad, clasificación y si la empresa es proveedor o responsable del despliegue.

¿Debe almacenarse cada prompt y respuesta?

No. Se exige trazabilidad adecuada, no conservación indiscriminada. Elija campos que apoyen finalidades definidas y aplique controles de datos y seguridad.

¿Durante cuánto tiempo deben conservarse los logs?

Los logs automáticos de alto riesgo bajo control de proveedores o responsables del despliegue deben conservarse en general durante un periodo adecuado de al menos seis meses. Otra ley puede exigir o limitar otro plazo.

¿Qué debe hacer primero un equipo?

Inventariar sistema, rol, clasificación, fuentes controladas y preguntas de revisión. Después, definir esquema mínimo, responsables, acceso, conservación, cambios y una prueba de reconstrucción.

Fuentes

• Reglamento (UE) 2024/1689, especialmente artículos 6, 12, 19 y 26.
• Reglamento (UE) 2026/1744 y las fechas modificadas de los requisitos de alto riesgo.
• Comisión Europea, «AI Act», para el calendario actual y el resumen de obligaciones.