Errores comunes de registro y conservación que aún cometen los equipos SaaS

Los errores más frecuentes no se deben a la falta de datos, sino a que el equipo no puede explicar qué registra, para qué, quién lo controla, cuánto tiempo lo conserva o qué pregunta concreta permite responder. El resultado suele ser telemetría costosa que aumenta el riesgo de privacidad y seguridad sin crear una pista de auditoría de IA defendible.

Para los sistemas de IA de alto riesgo, el artículo 12 del Reglamento de IA de la UE exige capacidades técnicas de registro automático de eventos durante su ciclo de vida. Los artículos 19 y 26 obligan a proveedores y responsables del despliegue a conservar los registros generados automáticamente bajo su control durante un periodo adecuado y, por regla general, al menos seis meses, salvo que otra norma aplicable disponga lo contrario. Esto no convierte toda función SaaS en alto riesgo ni exige guardar cada prompt y respuesta.

Error 1: empezar por la plataforma y no por el alcance

Activar todos los eventos no delimita un sistema. Un flujo SaaS con IA puede incluir interfaz, recuperación de datos, reglas de negocio, un modelo externo, aprobación humana y automatización posterior. Registrar solo la llamada al modelo omite con frecuencia los hechos que explican el resultado.

Documenta finalidad prevista, usuarios, personas afectadas, entradas, salidas, integraciones, versiones, entornos y decisiones influidas. Determina después el rol de la empresa, la clasificación y los desencadenantes de una reevaluación. La guía del Reglamento de IA para proveedores SaaS ofrece el contexto general.

Error 2: registrarlo todo por defecto

Prompts, documentos, resultados e identificadores completos pueden contener datos personales, secretos de clientes o credenciales. La recopilación indiscriminada amplía los riesgos de acceso, filtración, descubrimiento y borrado, y dificulta encontrar los eventos útiles.

Vincula cada campo con una pregunta definida. Para saber qué versión produjo un resultado, registra identificadores estables del sistema y la versión. Para demostrar supervisión humana, registra la obligación de revisar, la acción, el rol, la hora y el resultado. Cuando sea suficiente, utiliza referencias, hashes, categorías o resúmenes protegidos en vez del contenido completo.

Error 3: confundir telemetría con pista de auditoría

Los registros de aplicación muestran disponibilidad, latencia y errores, pero no siempre conectan un resultado relevante con el modelo, la configuración, la fuente recuperada, el control aplicado, la intervención humana o el lanzamiento correspondiente.

Una pista útil correlaciona todo el flujo: versiones, fecha y hora, identificador de transacción, contexto operativo, referencias de entrada y salida, controles, alertas, revisión humana, acción posterior y estado del incidente. También necesita esquemas documentados, relojes coherentes e identificadores inequívocos. Una persona que no diseñó el sistema debe poder reconstruir un evento seleccionado.

Error 4: aplicar seis meses a todos los datos

El mínimo de seis meses se refiere a registros automáticos de sistemas de alto riesgo bajo el control del operador correspondiente. No es una regla universal ni permiso para conservar indefinidamente todos los datos personales de los logs.

El calendario debe identificar clase de registro, inicio del plazo, fecha de borrado, finalidad, excepciones, aprobaciones y tratamiento de réplicas, exportaciones y copias de seguridad. Hay que conciliar trazabilidad con minimización, limitación del plazo, seguridad, normativa sectorial o laboral y contratos. Comprueba el borrado real fuera del panel principal.

Error 5: ignorar los límites de control

Proveedor, responsable del despliegue, cliente y proveedor tecnológico pueden controlar partes distintas. Asocia cada evento necesario con la parte y el sistema que lo controla. Los contratos y la documentación deben aclarar qué se crea, quién accede, cómo se solicita la prueba, cuánto se conserva y qué ocurre al terminar el servicio. Verifica la configuración, no solo el cuestionario del proveedor.

Antes de incorporar una herramienta, consulta las preguntas para adoptar IA internamente y alinea las respuestas comerciales con los controles de IA que piden los compradores.

Error 6: dejar implícita la responsabilidad

Producto aporta los hechos sobre finalidad y flujo; ingeniería instrumenta y mantiene la calidad del esquema; seguridad protege acceso e integridad; privacidad asesora sobre minimización; cumplimiento mantiene el mapa de requisitos y el estándar probatorio. Nombra una persona responsable del proceso completo y define quién revisa excepciones, autoriza accesos, responde solicitudes, amplía plazos, ordena bloqueos y corrige brechas.

Error 7: no proteger la pista

Los logs pueden revelar actividad de usuarios, decisiones internas, contenido de clientes y debilidades técnicas. Aplica mínimo privilegio, autenticación fuerte, cifrado, registro de accesos, separación de entornos y controles de exportación. Protege la integridad con esquemas controlados, marcas de tiempo fiables, transformaciones trazables y procedimientos de preservación. Separa el acceso operativo normal del acceso privilegiado de investigación.

Error 8: no probar nunca la reconstrucción

Selecciona un evento material y pide a un revisor independiente que identifique versión del sistema, contexto, controles, acción humana, resultado posterior y seguimiento. Registra las carencias y asigna medidas. Repite tras cambios de modelo, prompt, fuente, umbral, integración, supervisión o finalidad, y después de incidentes o quejas.

Este enfoque encaja con las nuevas expectativas de gobernanza de IA: los revisores buscan pruebas de que los controles funcionan, no solo políticas.

Flujo práctico de corrección

Empieza con un único flujo importante. Documenta alcance, finalidad, rol, clasificación, fuentes, proveedores y responsables. Enumera las preguntas previsibles y relaciónalas con los eventos mínimos. Revisa necesidad, sensibilidad, acceso, integridad, conservación y borrado de cada campo. Ejecuta una prueba de reconstrucción y otra de borrado, y conserva juntos resultados, brechas, responsables y plazos.

Según el calendario actual de la Comisión Europea, las reglas de alto riesgo para sistemas del anexo III se aplican desde el 2 de diciembre de 2027 y las relativas a IA incorporada en productos regulados del anexo I desde el 2 de agosto de 2028.

Preguntas frecuentes

¿Cuál es el mayor error?

Recopilar eventos sin definir antes el sistema y las preguntas de revisión. Produce volumen sin trazabilidad fiable.

¿Todas las funciones de IA SaaS necesitan estos registros?

No. Los artículos 12, 19 y 26 aquí tratados se refieren a sistemas de alto riesgo y dependen del rol y el control. Otras leyes, contratos o controles internos pueden justificar otros registros.

¿Hay que guardar cada prompt?

No. Elige campos proporcionales. En muchos casos bastan referencias, hashes, categorías, métricas o muestras protegidas.

¿Qué debe documentarse primero?

Límites del sistema, finalidad, rol, clasificación, fuentes controladas, preguntas, esquema mínimo, responsable, accesos y conservación.

¿Cómo se comprueba la utilidad?

Haz que un tercero reconstruya un evento relevante y prueba el borrado de datos vencidos en todas las copias.

Fuentes

• Reglamento (UE) 2024/1689, en especial sus artículos 6, 12, 19 y 26.
• Reglamento (UE) 2026/1744 sobre las fechas de aplicación modificadas.
• Comisión Europea, «AI Act», calendario vigente de aplicación.