Usar IA en auditoría sin perder la cadena de custodia

Un modelo de lenguaje resume un informe de 200 páginas en un minuto, clasifica tres mil hallazgos por categoría y redacta un borrador de plan de remediación aceptable. La tentación de meterlo en el proceso de auditoría es razonable y el ahorro es real.

El problema aparece cuando alguien pregunta, dieciocho meses después, por qué un hallazgo concreto se cerró como falso positivo. Si la respuesta involucra un modelo cuya versión ya no existe, con un prompt que nadie guardó y una salida que se copió y pegó en un documento, la evidencia se ha roto. No porque el modelo se equivocara, sino porque ya no se puede demostrar que no lo hiciera.

Qué es exactamente lo que se rompe

La cadena de custodia de una evidencia es la traza continua que permite afirmar, ante un tercero, que lo que estás mostrando procede de donde dices y no ha cambiado por el camino. Cada paso debe tener autor, fecha y una transformación descriptible.

Cuando un modelo interviene, aparecen tres agujeros nuevos:

• No determinismo. La misma entrada puede producir salidas distintas. No puedes reproducir el paso ejecutándolo otra vez.
• Autor difuso. ¿Quién tomó la decisión, el modelo o la persona que aceptó su sugerencia sin leerla?
• Transformación opaca. «Se resumió con IA» no describe una transformación. Describe una caja.

Los tres tienen solución, y ninguna consiste en no usar el modelo.

La línea: el modelo propone, el sistema de origen prueba

La regla que mejor funciona en la práctica es sencilla. La evidencia se genera siempre en el sistema de origen —el escáner, el registro, la consola, el repositorio— y nunca en el modelo. El modelo puede leerla, ordenarla, correlacionarla y sugerir qué hacer con ella, pero no la crea ni la sustituye.

Dicho de otro modo: si borras todas las salidas del modelo, el expediente debe seguir siendo completo y auditable. Si borrarlas deja huecos, has usado el modelo para producir evidencia, y eso es lo que no se puede hacer.

Con esa línea trazada, las tareas se reparten solas.

Donde el modelo aporta y no compromete nada: resumir, agrupar hallazgos similares, traducir, redactar borradores, extraer campos de documentos largos, sugerir la correspondencia entre un control y una obligación regulatoria, detectar incoherencias entre documentos, preparar preguntas para una entrevista.

Donde no debe operar sin revisión humana explícita: declarar un falso positivo, cerrar un hallazgo, valorar el riesgo residual, aceptar una excepción, emitir la conclusión de conformidad, decidir si un incidente supera el umbral de notificación.

La diferencia entre ambas listas no es la dificultad técnica. Es si la acción tiene consecuencias jurídicas o si alguien tendrá que defenderla personalmente.

Qué hay que registrar en cada intervención

Para que un paso asistido por modelo siga siendo auditable hace falta guardar seis cosas, y las seis son baratas si se automatizan desde el principio:

1. La entrada exacta que recibió el modelo, no un resumen de ella. Si la entrada era un documento, su hash.
2. La instrucción o plantilla de prompt, con su versión. Los prompts cambian; si no los versionas, no puedes explicar por qué el mismo proceso dio resultados distintos en marzo y en septiembre.
3. Identificación del modelo y su versión, y los parámetros relevantes —temperatura, si hubo recuperación de contexto y de qué corpus—.
4. La salida literal, íntegra, antes de cualquier edición humana.
5. Quién revisó, cuándo y qué cambió. Este es el campo decisivo: convierte una sugerencia en una decisión con autor.
6. La decisión final, enlazada al hallazgo o al control correspondiente.

Con esos seis campos, un paso asistido por modelo es tan trazable como uno manual. Sin el quinto, no lo es en absoluto.

El sesgo de automatización es el riesgo real

El fallo que más he visto no es que el modelo alucine un hallazgo inexistente. Es que el revisor acepta trescientas sugerencias seguidas porque las veinticinco primeras eran correctas. A partir de cierto volumen, la revisión humana se convierte en un clic.

Dos contramedidas funcionan razonablemente bien:

• Muestreo de verificación obligatorio. Un porcentaje fijo de las decisiones asistidas se reprueba manualmente contra el sistema de origen, y el resultado se registra. Si la tasa de error sube, se estrecha el ámbito de automatización. Esto además produce, por sí solo, la evidencia de eficacia que pide el artículo 21.2.f de la NIS2.
• Fricción proporcional a la consecuencia. Aceptar una reclasificación de categoría puede ser un clic. Cerrar un hallazgo crítico como falso positivo debería exigir escribir el motivo. La fricción no es burocracia cuando protege la decisión que alguien tendrá que defender.

Confidencialidad y dónde viven los datos

Hay un segundo frente que no es de evidencia sino de control. Los expedientes de auditoría contienen rutas internas, credenciales de prueba, arquitectura, vulnerabilidades sin corregir y a veces datos personales. Antes de enviarlos a un modelo hay tres preguntas que responder por escrito, porque un auditor las va a hacer:

• ¿Dónde se procesa y dónde se almacena? La ubicación importa para el RGPD y para el ENS, y tu propio análisis de riesgos debería cubrirla.
• ¿El proveedor del modelo retiene las entradas o las usa para entrenar? La respuesta tiene que estar en el contrato, no en la página de marketing.
• ¿Qué se anonimiza antes de enviar, y quién lo comprueba?

Y una obligación que suele olvidarse: si el modelo lo presta un tercero y soporta una función relevante, ese tercero entra en tu registro de proveedores con todo lo que eso implica.

Lo que hay que poder decir

La prueba de fuego es poder responder esta frase sin incomodidad: «este hallazgo se clasificó como falso positivo el 14 de mayo; la sugerencia la produjo el modelo X versión Y con la plantilla de prompt v3, la salida literal está archivada, la revisó Ana Ruiz el mismo día, comprobó la traza original en el escáner y confirmó la clasificación».

Si puedes decir eso, usa el modelo en todo lo que te ahorre tiempo. Si no puedes, el ahorro es prestado: lo estás tomando del futuro, y se devuelve con intereses el día de la auditoría. Por eso, en Violet Security, cada sugerencia del asistente queda archivada junto al hallazgo con su prompt, su versión y su revisor, en lugar de desaparecer en el documento final.