IA para gestión de riesgos: analizar información no es predecir incidentes

# ¿Por qué se confunden análisis y predicción?

La confusión suele empezar en una demostración convincente. Un modelo recibe cien reportes, identifica temas recurrentes y redacta una síntesis. Como la respuesta parece inteligente, es fácil dar el siguiente salto: “si entiende los incidentes anteriores, podrá anticipar el siguiente”.

Ese salto no está justificado.

Resumir información existente es una tarea retrospectiva. Estimar la probabilidad de un evento futuro es una tarea predictiva. La primera puede apoyarse en lenguaje y búsqueda; la segunda necesita demostrar una relación válida entre variables observadas y resultados posteriores.

Además, un incidente poco frecuente puede estar mal documentado, cambiar con nuevos procesos o depender de condiciones que nunca se registraron. La ausencia de reportes tampoco prueba ausencia de riesgo: puede reflejar subregistro, categorías inconsistentes o incentivos para no documentar.

# Tres usos distintos de IA en riesgos

La misma solución puede combinar los tres, pero no debe ocultar las transiciones. Si un sistema pasa de resumir un reporte a recomendar detener una operación, entran en juego otra autoridad, otro riesgo y un estándar de evidencia mayor.

# ¿Qué puede hacer bien la IA con reportes de riesgo?

Los sistemas de lenguaje son útiles cuando una organización tiene información dispersa en reportes, actas, bitácoras, procedimientos y correos autorizados.

# Clasificar y normalizar

La IA puede proponer categorías comunes para descripciones escritas de formas distintas. “Fuga menor”, “pérdida de contención” y “derrame controlado” podrían agruparse para una revisión, siempre que la taxonomía sea aprobada por especialistas y se conserve el texto original.

La normalización ayuda a buscar, pero también puede borrar diferencias importantes. Por eso la categoría propuesta debe acompañarse de evidencia y permitir corrección.

# Resumir con trazabilidad

Un buen resumen de riesgo no debe esconder la fuente. Conviene que cada afirmación importante enlace con el reporte, página o fragmento que la respalda. Si no existe evidencia suficiente, la salida correcta es indicarlo, no completar la historia.

# Encontrar controles y acciones pendientes

La IA puede localizar menciones de responsables, fechas, medidas correctivas y controles. También puede detectar documentos donde falta un campo esperado. Esto no comprueba que la acción se haya ejecutado: identifica lo documentado y lo ausente en el conjunto analizado.

# Comparar procedimientos y prácticas registradas

Un sistema puede contrastar un reporte con una lista de controles o un procedimiento vigente y señalar diferencias para revisión. La decisión sobre cumplimiento corresponde a la función autorizada y debe considerar versiones, excepciones y contexto operativo.

# Priorizar una cola de revisión

Cuando el volumen impide leer todo de inmediato, la IA puede ordenar expedientes según criterios definidos. La prioridad es una ayuda para distribuir atención; no es una declaración automática sobre gravedad, culpa o causa.

# ¿Qué exige una predicción real?

Una predicción responsable empieza por definir el evento. “Predecir amenazas” es demasiado amplio. “Estimar la probabilidad de una detención no programada de cierto equipo dentro de siete días” es una pregunta que podría evaluarse si existen datos adecuados.

Como mínimo se necesita:

• una variable objetivo observable y consistente;
• una ventana temporal definida;
• datos anteriores al resultado, sin filtraciones de información futura;
• cobertura suficiente de operaciones normales y eventos;
• documentación de cambios en procesos, equipos y criterios;
• un conjunto de validación separado;
• métricas acordes con el costo de omitir o sobrerreaccionar;
• monitoreo para detectar degradación.

Un modelo puede tener buena precisión general y aun fallar en los casos importantes. Si los incidentes son raros, predecir “no ocurrirá nada” casi siempre puede parecer preciso. Por eso se necesitan métricas que distingan cuántos eventos detecta, cuántas alertas son falsas y con cuánto tiempo de anticipación entrega información accionable.

# Falsos positivos y falsos negativos

Toda señal predictiva implica errores.

Un falso positivo ocurre cuando el sistema alerta sobre un evento que no sucede. Puede provocar inspecciones innecesarias, fatiga de alertas y pérdida de confianza.

Un falso negativo ocurre cuando el sistema no alerta y el evento sí sucede. En entornos de seguridad, continuidad o cumplimiento, su costo puede ser mucho mayor.

No existe un umbral universal. La organización debe decidir el balance con especialistas, operación, seguridad y dirección. También debe establecer qué acción corresponde a cada nivel y si esa acción puede introducir un riesgo nuevo.

# ¿Qué cambia en minería y entornos industriales?

En minería, manufactura, logística o infraestructura, la información combina documentos, sensores, mantenimiento, observaciones humanas, contratistas y condiciones del entorno. Un modelo de lenguaje puede ayudar con la parte documental, pero no reemplaza ingeniería, geología, seguridad, mantenimiento ni mando operativo.

Casos de uso razonables para explorar incluyen:

• resumir reportes de incidentes y casi incidentes;
• relacionar acciones correctivas con responsables y fechas;
• comparar descripciones contra una taxonomía aprobada;
• preparar un expediente para una reunión de revisión;
• localizar controles mencionados o ausentes;
• identificar temas recurrentes para capacitación;
• traducir y estandarizar reportes conservando el original;
• apoyar la consulta de procedimientos vigentes.

En cambio, afirmaciones como “la IA evitará accidentes” o “anticipará amenazas” no deberían usarse sin un sistema específico, validado para el contexto y sujeto a controles operativos. Una herramienta documental no se convierte en un sistema de seguridad por agregar un tablero.

# ¿Cómo diseñar un piloto de bajo riesgo?

El primer piloto debería mejorar una tarea de análisis sin tomar control de la operación.

# Paso 1. Elegir una decisión existente

Ejemplo: preparar la revisión semanal de acciones correctivas. El equipo ya sabe quién decide y qué información necesita. La IA puede reducir búsqueda y organización sin inventar un proceso nuevo.

# Paso 2. Definir fuentes autorizadas

Especifique qué versiones de procedimientos, reportes, catálogos y datos pueden utilizarse. Evite mezclar borradores, documentos vencidos o información de otras unidades sin contexto.

# Paso 3. Crear un conjunto de evaluación

Seleccione casos representativos y haga que especialistas documenten las respuestas esperadas, las ambigüedades y los casos donde no puede concluirse nada. Esta colección será más valiosa que una demostración improvisada.

# Paso 4. Exigir evidencia

Cada resumen, clasificación o recomendación debe mostrar el fragmento de origen. Una interfaz útil permite abrir la fuente y registrar una corrección.

# Paso 5. Definir el límite de autonomía

Durante el piloto, el sistema puede proponer, ordenar o redactar. No debe cerrar acciones, modificar procedimientos, determinar causas, sancionar, emitir una alerta crítica o controlar equipos sin la validación y autorización correspondientes.

# Paso 6. Medir utilidad y riesgo

Mida tiempo ahorrado, cobertura, errores, discrepancias entre especialistas, citas incorrectas, información omitida y acciones que el equipo realmente utilizó. Incluya pruebas adversas: documentos incompletos, versiones contradictorias, tablas escaneadas y términos poco frecuentes.

# ¿Qué métricas sirven para análisis documental?

No todas las implementaciones necesitan una métrica predictiva. Para un asistente documental pueden medirse:

• precisión de extracción por campo;
• proporción de afirmaciones con cita correcta;
• documentos relevantes recuperados;
• errores críticos y omisiones;
• tiempo para preparar una revisión;
• porcentaje de salidas corregidas;
• frecuencia de “evidencia insuficiente” bien utilizada;
• satisfacción de especialistas, acompañada de observación real.

La métrica debe corresponder con el uso. Una síntesis agradable no compensa una referencia equivocada; una búsqueda rápida no sirve si utiliza un procedimiento obsoleto.

# ¿Qué métricas sirven para predicción?

Si el proyecto realmente incluye un modelo predictivo, necesita métricas estadísticas y operativas. Entre ellas pueden estar sensibilidad, especificidad, precisión de alertas, calibración de probabilidades, anticipación y costo de intervención.

También debe compararse contra una línea base. ¿El modelo mejora una regla simple, el programa de mantenimiento o el criterio actual? Sin esa comparación, una métrica aislada puede impresionar sin demostrar valor adicional.

NIST recomienda que las mediciones sean representativas del contexto de uso, que se documenten limitaciones e incertidumbre y que la evaluación continúe después del despliegue. Una prueba única no garantiza desempeño permanente.

# Gobierno: ¿quién responde por la salida?

Antes del piloto deben nombrarse responsables para:

• aprobar fuentes y versiones;
• definir taxonomías y criterios;
• validar salidas en su dominio;
• autorizar cambios operativos;
• administrar accesos y conservación;
• recibir reportes de error;
• decidir cuándo suspender el sistema.

El proveedor tecnológico puede operar componentes, pero no debe convertirse por omisión en dueño del riesgo. La organización mantiene la autoridad sobre procesos, personal, seguridad y cumplimiento.

# Señales de una propuesta sobredimensionada

Conviene desconfiar cuando una propuesta:

• promete predicción sin definir el evento;
• no pregunta por calidad, cobertura ni antigüedad de datos;
• usa “exactitud” sin explicar la métrica;
• no distingue análisis de lenguaje y modelo predictivo;
• no contempla falsos positivos y negativos;
• no identifica quién valida ni quién decide;
• presenta una demostración como evidencia de desempeño;
• no incluye monitoreo, corrección o salida segura.

Una propuesta responsable puede ser menos espectacular. También será más útil para decidir si conviene invertir.

# Preguntas frecuentes

# ¿La IA generativa puede predecir accidentes?

Por sí sola, no. Puede analizar texto y producir hipótesis, pero una predicción necesita un problema definido, datos representativos y validación. Incluso un modelo validado ofrece probabilidades, no certezas, y no sustituye controles de seguridad.

# ¿Se pueden analizar reportes históricos con Claude o ChatGPT?

Sí, siempre que el producto, el contrato, la configuración y la información sean apropiados. Deben revisarse acceso, sensibilidad, retención, finalidad y versiones. Para un volumen o flujo recurrente puede convenir una integración mediante API con controles propios.

# ¿Un resumen de incidentes sirve como modelo de riesgo?

Sirve como insumo para análisis, no como modelo predictivo. Resume lo documentado y puede revelar patrones descriptivos. No estima automáticamente la probabilidad de futuros eventos.

# ¿Qué debe hacer el sistema cuando faltan datos?

Debe indicar la ausencia, reducir su confianza o solicitar revisión. Completar huecos con lenguaje plausible es especialmente peligroso en un contexto de riesgo.

# ¿Cuál es el mejor primer caso de uso?

Uno frecuente, acotado y reversible: búsqueda en procedimientos vigentes, preparación de expedientes o seguimiento documental de acciones. Permite aprender sobre datos y adopción antes de considerar usos predictivos.

# Conclusión

La IA puede mejorar la gestión de riesgos al hacer más accesible la evidencia: ordenar reportes, encontrar controles, resumir expedientes y dirigir la atención humana. Ese beneficio ya puede ser significativo.

Predecir un incidente es otro problema. Requiere datos, estadística, validación y una conversación explícita sobre errores y consecuencias. Confundir ambas capacidades crea expectativas que el sistema no puede sostener.

La pregunta inicial no debería ser “¿qué puede predecir la IA?”. Debería ser “¿qué decisión queremos mejorar, con qué evidencia y bajo la responsabilidad de quién?”.

# Fuentes consultadas

• NIST AI Risk Management Framework: Generative AI Profile
• NIST AI RMF Core
• Características de confiabilidad del NIST AI RMF
• NIST: evaluación de sistemas de IA y cuantificación de incertidumbre