Diagnóstico de calidad de datos en IA industrial para HSE

El diagnóstico de calidad de datos en IA industrial no es un tema de sistemas; es un tema de seguridad. Si alimentás un modelo con registros incompletos, etiquetas inconsistentes y variables fuera de contexto, la IA no corrige el problema: lo amplifica y lo vuelve más convincente.

Esto importa tanto si dirigís un programa de Process Safety Management como si supervisás un turno o hacés recorridas en campo. En una planta, una mala decisión basada en datos malos puede terminar en una alarma mal priorizada, una inspección postergada o un riesgo mayor subestimado. Y cuando eso ocurre, el sistema no falla por culpa de una sola persona, sino por cómo está diseñado para capturar, validar y usar la información.

Por eso esta primera pieza de la serie abre con fundamentos y diagnóstico. Antes de automatizar decisiones con IA, hay que responder una pregunta incómoda: ¿qué tan confiables son los datos que hoy sostienen tus alertas, tus análisis de riesgo y tus prioridades HSE? Si no tenés esa respuesta, conviene leer después la checklist para decisiones seguras y, cuando ya tengas una línea base, avanzar a gobierno de datos y mejora continua.

Por qué el diagnóstico de calidad de datos en IA industrial define el resultado

La IA industrial no toma decisiones mágicas. Clasifica, prioriza y predice a partir de patrones aprendidos desde datos históricos y datos en tiempo real. Si el historial mezcla incidentes mal codificados, eventos duplicados, campos vacíos y condiciones operacionales no controladas, el modelo aprende una versión deformada de la realidad.

En seguridad de procesos esto es especialmente delicado porque los errores no suelen verse como un fallo inmediato del sistema. Se manifiestan como pequeñas desviaciones: demasiadas falsas alarmas, recomendaciones que no coinciden con lo que el operador ve en campo, análisis de riesgo que priorizan lo visible en lugar de lo crítico, o dashboards que se actualizan rápido pero dicen poco.

Hay seis dimensiones de calidad de datos que conviene revisar siempre: exactitud, completitud, consistencia, oportunidad, trazabilidad y contexto. En HSE, esas seis variables determinan si la IA ayuda a prevenir una pérdida de contención o si solo produce un reporte bonito con riesgos mal rankeados.

En términos de gestión, esto no se resuelve con más software solamente. Se resuelve con disciplina operativa, criterio técnico y una gobernanza que defina quién crea el dato, quién lo corrige, quién lo aprueba y quién decide usarlo para automatizar algo. Ese principio está alineado con OSHA PSM 1910.119, con ISO 45001 en la gestión de información documentada y con el enfoque de CCPS sobre riesgo basado en barreras y confiabilidad del sistema.

Normas y marcos que sí te sirven

• OSHA PSM 1910.119: exige integridad mecánica, gestión del cambio, análisis de peligros de proceso y entrenamiento. Todos dependen de datos confiables.
• API 754: ordena cómo medir eventos de seguridad de procesos. Si el dato del evento está mal clasificado, la tendencia queda rota.
• IEC 61511: para sistemas instrumentados de seguridad, la calidad de los datos de pruebas, demandas y fallas es crítica para la confiabilidad del SIS.
• ISO 45001: pide control sobre la información documentada y sobre la evaluación del desempeño. Sin datos buenos, la mejora continua se vuelve cosmética.
• CCPS: insiste en que los controles críticos deben gestionarse con datos verificables, no con percepciones aisladas.

Cómo los datos malos degradan alertas, análisis de riesgo y priorización HSE

En alertas, el problema más visible son los falsos positivos. Si el modelo se alimenta con registros duplicados o señales sin contexto, termina saturando al operador con avisos que no requieren acción. Eso genera fatiga de alarma y, tarde o temprano, alguien deja de mirar la pantalla.

El segundo problema es más peligroso: los falsos negativos. Un sensor con historial incompleto, un evento mal codificado o una variable de contexto omitida pueden esconder una condición que sí requería intervención. En seguridad de procesos, una alerta perdida no es un error menor. Puede ser el inicio de una liberación de energía o de material.

En análisis de riesgo ocurre algo parecido. Un BowTie, un HAZOP asistido por IA o una priorización de escenarios pierde valor si la base de datos no distingue entre condiciones de arranque, régimen estable y parada. Tampoco sirve si las barreras se registran como disponibles cuando en realidad estaban fuera de servicio. En ese caso, la IA no evalúa el riesgo real; evalúa una fotografía falsa.

La priorización HSE también se sesga. Si la organización registra con rigor los eventos menores visibles, pero deja débiles los datos de integridad mecánica, la IA puede terminar asignando recursos a lo que se reporta más y no a lo que más puede dañar. Eso es crítico en plantas con muchas órdenes de trabajo, miles de tags y un historial largo de mantenimiento reactivo.

Regla práctica: si no podés explicar de dónde sale un dato, quién lo valida, cuándo se actualiza y qué decisión afecta, no debería usarse para automatizar una decisión crítica.

En una auditoría real, yo buscaría tres preguntas simples: ¿el dato es verdadero?, ¿es completo?, ¿es útil para la decisión que querés automatizar? Si la respuesta a cualquiera de esas preguntas es no, todavía no estás listo para delegar a una IA la recomendación operativa.

Casos reales: cuando el problema no era la IA sino los datos

Caso 1: Texas City, 2005

Situación: durante el arranque de una unidad de refinación en Texas City, el raffinate splitter se sobrellenó. El evento terminó en explosión e incendio con 15 fatalidades y más de 180 personas lesionadas. Además del daño humano, el impacto económico superó ampliamente los mil millones de dólares en pérdidas directas e indirectas.

Problema: la operación dependía de información de nivel poco confiable, indicadores mal interpretados y registros de mantenimiento y operación que no lograban dar una imagen clara del estado real del sistema. La cadena de decisión estaba apoyada en datos débiles justo en una fase de alta sensibilidad operacional: el arranque.

Consecuencia: el sistema de gestión no detectó a tiempo que la situación ya había dejado de ser controlable con los supuestos existentes. La información mala no solo falló en prevenir el evento; además contribuyó a que la percepción del riesgo fuera más baja de lo que debía ser.

Lección: si hoy entrenaras una IA con datos como esos, el modelo aprendería que el arranque era una condición normal más, o peor, que ciertas señales no merecen prioridad. En seguridad de procesos eso es inaceptable. Un dato débil en una fase crítica puede redefinir el comportamiento del sistema entero.

Caso 2: Buncefield, 2005

Situación: en el terminal de Buncefield, en el Reino Unido, un tanque de gasolina se sobrellenó hasta liberar una cantidad enorme de producto. El incendio posterior fue uno de los mayores en tiempos de paz en Europa. Hubo 43 personas heridas, aunque afortunadamente no se registraron muertes.

Problema: la investigación mostró debilidades graves en la confiabilidad de la medición de nivel y en la prevención de sobrellenado. La planta dependía de señales que no ofrecían una barrera robusta y la organización no aseguró una validación efectiva del dato antes de que se convirtiera en decisión operacional.

Consecuencia: se liberaron decenas de millones de litros de combustible y la cadena de daños afectó instalaciones, infraestructura, respuesta de emergencia y continuidad operativa. El problema no fue solo el evento físico; fue la aceptación de información insuficiente como si fuera una base segura para operar.

Lección: la IA no reemplaza una barrera de seguridad ni corrige una medición mal diseñada. Si las entradas están sesgadas o incompletas, la recomendación será tan frágil como el dato que la originó. Un modelo puede clasificar mejor que una persona, pero no puede convertir una mala señal en una verdad confiable.

Estos casos muestran un patrón común: el accidente no nace en el algoritmo, pero sí puede quedar amplificado por un sistema que no distingue dato bueno de dato aparente. En otras palabras, si la organización ya captura mal la realidad, la IA solo va a industrializar el error.

Ejemplo típico de planta: el historial de incidentes que no se puede usar

En muchas plantas, al revisar bases de near miss o reportes de condiciones inseguras, aparecen categorías genéricas como otros, sin lesión o por revisar. Cuando esas etiquetas crecen más que las causas bien definidas, el modelo aprende ruido. Entonces la prioridad de inspección se apoya en textos libres, criterios distintos por turno y eventos duplicados. El resultado es predecible: el dashboard sube de color rojo, pero no mejora la toma de decisiones.

Diagnóstico organizacional: señales de alerta y autoevaluación

Antes de automatizar, necesitás una línea base de madurez. No hace falta empezar con un sistema sofisticado; hace falta empezar con honestidad técnica. Si te pasa más de una de estas señales, tu organización todavía está lejos de usar IA como apoyo confiable para seguridad de procesos.

• Los mismos eventos aparecen con distintas descripciones según el área o el turno.
• Los datos críticos se cargan manualmente y sin validación posterior en campo.
• Hay campos vacíos en eventos de alto potencial, pero no en eventos menores.
• No existe un diccionario de datos común entre HSE, operaciones y mantenimiento.
• Las alertas del sistema se revisan tarde o se aceptan sin contraste con la realidad operativa.
• Las variables de contexto no se capturan de forma consistente: arranque, parada, desvío, emergencia o condición normal.
• No hay trazabilidad clara entre el dato original, su corrección y la decisión tomada.
• Los indicadores de seguridad de procesos cambian, pero nadie puede explicar si cambió el riesgo o solo cambió la forma de registrar.

Autoevaluación rápida por rol: si sos director, preguntate si podés demostrar gobernanza del dato y no solo visibilidad. Si sos mando medio, preguntate si tu equipo verifica datos críticos antes de cerrar un turno. Si sos operador, preguntate si sabés cuándo un tag, una etiqueta o una condición de proceso no coincide con lo que realmente ves en campo.

Metodología para hacer un diagnóstico de calidad de datos en IA industrial

El diagnóstico no tiene que ser complejo para ser útil. Tiene que ser sistemático. Lo primero es identificar qué decisiones querés soportar con IA: alertas, priorización de inspecciones, análisis de incidentes, pronóstico de fallas o clasificación de eventos de proceso. Después se revisa qué datos alimentan cada decisión y qué tan críticos son.

Luego viene el paso que muchas organizaciones saltan: medir la calidad del dato en la fuente, no solo en el tablero. Eso implica muestrear registros, comparar con campo, revisar duplicados, validar taxonomías y verificar si el contexto operacional está bien capturado. En seguridad de procesos no alcanza con que el dato exista; tiene que representar la realidad correcta.

Un buen diagnóstico debe terminar con una línea base. Esa línea base no es un reporte decorativo; es la referencia contra la cual vas a medir mejora. Si hoy tenés 72 por ciento de completitud en campos críticos, 18 por ciento de duplicados y cero trazabilidad de cambios, ya sabés que no conviene automatizar decisiones de alto riesgo sin antes corregir el sistema.

La meta inicial no es la perfección. La meta es identificar dónde está el sesgo, qué tan grande es el vacío y qué control lo corrige. Ese enfoque es más útil que intentar comprar una plataforma avanzada para esconder que los datos siguen mal capturados.

Si tu organización quiere usar IA en HSE, el primer activo que debe madurar no es el algoritmo; es la calidad de la información que lo alimenta.

Si querés formalizar ese diagnóstico en una herramienta práctica, el producto Diagnósticos Digitales ayuda a evaluar madurez en PSM, disciplina operativa y competencias. No reemplaza el juicio técnico, pero sí te da una lectura objetiva de dónde estás parado antes de escalar automatización.

Aplicación práctica en el día a día

Para directores, el foco está en gobernanza. Pedí un tablero de calidad de datos con tres cosas: datasets críticos, porcentaje de completitud y nivel de trazabilidad. Si el comité no puede explicar cómo se corrige un dato malo, no hay gobernanza real.

Para mandos medios, la aplicación está en la verificación de turno. Incorporá una revisión rápida de campos críticos antes de cerrar reportes, permisos, hallazgos y eventos. Una rutina de cinco minutos por turno puede evitar semanas de decisiones equivocadas.

Para operadores, la clave es reconocer cuándo lo que está en el sistema no coincide con el campo. Un tag duplicado, un estado de válvula desactualizado o una clasificación rara de un incidente no son detalles administrativos; son señales de que la cadena de datos se puede romper. Reportarlo a tiempo es parte de la disciplina operativa.

Herramientas útiles para bajar esto a campo: diccionario único de etiquetas, checklist de validación de eventos, muestreo semanal de registros críticos, y reuniones cortas de revisión entre HSE, operaciones y mantenimiento. Si además querés llevar esto a un método de decisión más seguro, el siguiente paso natural es la checklist para decisiones seguras, donde aterrizamos qué revisar antes de confiar en una recomendación de IA.

FAQ rápida sobre diagnóstico de calidad de datos

¿La IA puede funcionar si mis datos no son perfectos?

Sí, pero solo para casos de baja criticidad o como apoyo exploratorio. Si vas a automatizar una decisión que puede impactar una barrera de proceso, la calidad del dato debe ser suficiente para defender la decisión frente a una auditoría. La clave no es perfección absoluta, sino demostrar límites, sesgos conocidos y controles compensatorios.

¿Qué fuente de error aparece más en plantas industriales?

La más común suele ser la captura manual sin estandarización: etiquetas distintas para el mismo evento, campos vacíos y descripciones libres difíciles de interpretar. Después aparecen los datos incompletos y la falta de contexto operacional. En IA industrial, esos errores pesan más que un pequeño error numérico porque alteran la clasificación y la priorización.

¿Cómo sé si un dataset es demasiado débil para usarlo en HSE?

Si no podés rastrear su origen, si tiene duplicados frecuentes, si no distingue entre condiciones operacionales y si cambia la codificación según el área, el dataset todavía no es confiable. Como regla práctica, cualquier variable crítica que no puedas explicar en una auditoría externa tampoco debería alimentar una decisión automatizada de alto impacto.

¿Quién debería ser dueño de la calidad de datos?

No debería ser solo TI ni solo HSE. La calidad de datos en seguridad de procesos necesita un dueño funcional por proceso, un custodio técnico y un sponsor de liderazgo. Sin esa combinación, los problemas se discuten en reuniones pero no se corrigen en la fuente.

¿Puedo empezar con un piloto aunque la base esté floja?

Sí, siempre que el piloto esté acotado a un activo, un dataset y una decisión de bajo a medio riesgo. El piloto sirve para aprender qué tan malo es el dato, qué sesgos aparecen y qué controles faltan. Lo que no conviene es escalar una solución con trazabilidad débil a toda la planta sin antes corregir la base.

¿Cómo se conecta esto con PSM y BowTie?

De manera directa. Un BowTie, un PHA o una verificación de barreras dependen de datos correctos sobre escenarios, causas, consecuencias y controles. Si esa información está contaminada, la representación del riesgo se deforma. Por eso, el diagnóstico de datos es un paso previo a cualquier automatización seria de decisiones críticas.

Cierre: antes de escalar IA, medí tu línea base

La lección central es simple: la IA no arregla una mala cultura de datos. La hace más eficiente en producir conclusiones, pero no más verdadera. Si querés usarla en seguridad de procesos, primero tenés que saber si tu organización captura bien la realidad, si valida lo que registra y si gobierna de forma consistente lo que después va a decidir.

Este artículo abrió la serie con los fundamentos y el diagnóstico. En el próximo, bajamos a una herramienta concreta para revisar decisiones seguras en campo y en gestión, con una mirada operativa y práctica. Y más adelante, cerramos el círculo con el artículo sobre gobierno de datos y mejora continua, donde la madurez deja de ser un concepto y se convierte en disciplina.

Si hoy tu planta ya usa o piensa usar IA, la pregunta correcta no es si la tecnología es buena. La pregunta es si los datos que la alimentan están listos para sostener decisiones que afecten personas, activos y continuidad operativa. Si la respuesta todavía no está clara, ese es el diagnóstico que hay que hacer primero.