Ha ocurrido un incidente con IA: qué preservar antes de cambiar el sistema

Un sistema de inteligencia artificial produce un resultado anómalo. La reacción técnica inmediata es lógica: corregir el prompt, actualizar el modelo, cambiar una regla, borrar una memoria defectuosa o desactivar una integración.

Pero si el incidente puede terminar en una investigación interna, una reclamación, una discusión contractual o un litigio, intervenir demasiado pronto puede destruir la posibilidad de responder después a una pregunta elemental: ¿qué configuración exacta produjo el efecto?

La contención y la preservación no son fases opuestas. Deben diseñarse juntas.

La unidad de prueba no es solo el output

Guardar una captura de pantalla del resultado puede ser útil y seguir siendo insuficiente.

Para reconstruir una actuación de IA puede ser necesario identificar:

• modelo y versión;
• configuración;
• prompt o instrucción relevante;
• fuentes y documentos recuperados;
• memoria utilizada;
• herramientas o APIs ejecutadas;
• inputs y outputs;
• logs disponibles;
• reglas o umbrales;
• intervención humana;
• cambios realizados antes y después del incidente;
• proveedor y subproveedores cuando tengan evidencia relevante.

El objeto probatorio es una cadena de producción del efecto, no un archivo aislado.

La LEC ya permite trabajar con evidencia digital

La Ley 1/2000, de Enjuiciamiento Civil, en su artículo 299, contempla distintos medios de prueba e incluye medios de reproducción y determinados instrumentos que permiten archivar, conocer o reproducir palabras, datos, cifras y operaciones relevantes para el proceso.

Los artículos 382 a 384 regulan, entre otras materias, instrumentos de filmación, grabación y otros medios, así como instrumentos que permiten archivar, conocer o reproducir datos relevantes. El artículo 335 regula el dictamen de peritos cuando son necesarios conocimientos científicos, artísticos, técnicos o prácticos.

Por tanto, el problema no es que el Derecho procesal carezca de categorías para evidencia digital. El problema práctico es llegar al litigio con una cadena suficientemente preservada y explicable.

El AI Act añade exigencias de documentación y logs en determinados sistemas

El AI Act contiene obligaciones de documentación, registro y conservación de logs para determinados sistemas de alto riesgo cuando su régimen resulta aplicable, entre otras obligaciones.

Esas reglas no significan que todo sistema de IA deba conservar todos sus logs indefinidamente. Tampoco sustituyen el análisis probatorio de un incidente concreto.

Sí muestran una dirección clara: la trazabilidad forma parte de la gobernanza de sistemas cuyo efecto debe poder reconstruirse.

Qué preservar primero

1. Identidad de la configuración

Hay que fijar qué versión estaba operando y con qué parámetros relevantes. Si el proveedor actualiza automáticamente, esta información puede perderse rápidamente.

2. Inputs, fuentes y contexto

El mismo modelo puede producir resultados distintos según documentos recuperados, memoria, instrucciones de sistema, contexto previo o herramientas disponibles.

3. Output y actos posteriores

Debe conservarse no solo la respuesta, sino qué ocurrió después: envío, modificación, decisión, pago, rechazo, clasificación o cualquier otro efecto.

4. Logs y metadatos

Los logs pueden mostrar tiempos, llamadas, herramientas, errores, identificadores o secuencias. Pero un log no es automáticamente prueba suficiente ni explica por sí solo el significado del evento.

5. Decisión humana

Si una persona revisó, confirmó, corrigió o ignoró el resultado, hay que fijar qué información tuvo, qué hizo y qué capacidad real tenía para cambiar el curso del sistema.

Contener sin destruir

Supongamos que el problema está en una memoria compartida. La organización puede necesitar aislarla inmediatamente para evitar nuevos efectos. Eso no obliga a mantenerla activa.

La arquitectura correcta puede ser:

1. bloquear uso;
2. preservar una copia controlada cuando sea lícito y necesario;
3. registrar versión y estado;
4. separar acceso de investigación del acceso operativo;
5. corregir el sistema en producción;
6. documentar la diferencia entre estado anterior y posterior.

La preservación no significa conservar indiscriminadamente datos personales o secretos. Debe coordinarse con minimización, confidencialidad, seguridad y plazos aplicables.

El proveedor puede tener la pieza que falta

En servicios externos, parte de la evidencia puede estar fuera del control directo de la organización: logs, historial de versiones, metadatos, información de incidentes o documentación técnica.

Ese problema se resuelve mal si aparece por primera vez después del incidente.

Los contratos deberían prever, de forma proporcionada:

• qué logs existen;
• cuánto se conservan;
• qué puede solicitar el cliente;
• cómo se preserva ante una disputa;
• qué cooperación ofrece el proveedor;
• qué ocurre al terminar el contrato.

La arquitectura probatoria empieza en procurement y gobernanza, no en el juzgado.

Criterio H&C

Ante un incidente no preguntamos solo «¿qué dijo la IA?». Preguntamos:

¿qué sistema exacto produjo el efecto, con qué información, bajo qué autoridad y qué cambió después?

La secuencia es:

contener → fijar configuración → preservar cadena → reconstruir hechos → determinar necesidad pericial → decidir corrección → documentar aprendizaje.

El Protocolo de incidente, contención y suspensión convierte esta lógica en una estructura operativa.

Una regla práctica

Antes de modificar un sistema tras un incidente, debería existir una respuesta explícita a estas preguntas:

• ¿qué evidencia puede desaparecer con el cambio?;
• ¿qué necesitamos para entender la causa?;
• ¿qué datos no debemos conservar más de lo necesario?;
• ¿qué controla el proveedor?;
• ¿qué decisión humana hay que reconstruir?;
• ¿qué versión debemos poder identificar después?;
• ¿quién autoriza la preservación y quién accede?;

La mejor investigación no es la que conserva más. Es la que conserva lo necesario para reconstruir de forma fiable la diferencia que produjo el efecto.