Diagnóstico de datos en una operación minera: qué revisar antes de invertir en IA

7 min de lectura · todas las notas

La mayoría de proyectos de IA en operaciones industriales no fracasan por el modelo. Fracasan porque se eligió un problema que los datos disponibles no podían resolver, o porque nadie iba a usar el resultado. Ambas cosas se detectan antes de invertir, con una revisión que la propia operación puede hacer.

Este es el guion que seguimos cuando visitamos una unidad, y sirve igual si se hace internamente.

1. Empezar por el dolor, no por la tecnología

La pregunta inicial no es «dónde podríamos aplicar IA». Es: ¿qué nos cuesta tiempo, dinero o seguridad todos los días y no hemos podido resolver?

Conviene hacerla por separado a gente de distintos niveles: al operador, al jefe de guardia, al planeador, al superintendente. Cuando el mismo problema aparece en varias respuestas desde ángulos distintos, ese es el candidato. Cuando solo lo menciona la gerencia, suele ser un síntoma y no la causa.

2. Seguir un dato de punta a punta

Elegir un dato concreto —el tonelaje de un turno, las horas de un equipo— y recorrer su recorrido completo: dónde se origina, quién lo anota, en qué soporte, quién lo transcribe, en qué sistema termina, quién lo consulta y qué decide con él.

Este ejercicio, que toma una mañana, casi siempre revela cosas que nadie tenía presentes:

• El dato se digita dos o tres veces en sistemas distintos, con criterios distintos.
• Hay una corrección manual sistemática que alguien hace y nadie documentó.
• El dato llega a destino después de que la decisión ya se tomó.
• Dos áreas usan el mismo nombre para cosas distintas, o nombres distintos para lo mismo.

3. Inventariar lo que ya existe

Antes de pensar en capturar información nueva conviene saber qué hay. La lista suele ser más larga de lo esperado: partes de guardia, sistema de dispatch, sistema de mantenimiento, señales del sistema de control de planta, mediciones de laboratorio, monitoreo ambiental, reportes de seguridad, planos, hojas de cálculo de las áreas técnicas.

De cada fuente importa: hace cuánto existe, con qué frecuencia se actualiza, si es exportable, y —crítico— si alguien la usa hoy. Una fuente que nadie mira suele tener calidad baja, porque nada obliga a que esté bien.

4. Comprobar si existe historial

Es el filtro más duro y el que más proyectos descarta a tiempo. Para que un modelo aprenda a reconocer algo, ese algo tiene que haber ocurrido antes y estar registrado.

Si se quiere anticipar fallas de un equipo, ¿existen fallas registradas de ese equipo, con fecha y causa? Si se quiere predecir demoras, ¿están las demoras codificadas de forma consistente durante los últimos meses? Si la respuesta es no, el primer proyecto no es de IA: es de empezar a registrar bien. Eso también es un resultado válido del diagnóstico.

5. Identificar al destinatario

Toda solución necesita una persona concreta que la use y a la que le cambie el trabajo. No un área: una persona con nombre.

Si al preguntar «¿quién va a abrir esto y qué va a hacer distinto?» no hay una respuesta clara, el proyecto no tiene destinatario y terminará siendo un entregable que se presenta una vez y se archiva.

Las señales de alarma

Hay cuatro respuestas que, cuando aparecen en un diagnóstico, recomiendan posponer o replantear el proyecto:

• «Queremos hacer algo con IA» sin un problema identificado detrás. La herramienta llegó antes que la necesidad.
• «Los datos están, hay que ordenarlos un poco». Ese «un poco» suele ser la mitad del esfuerzo del proyecto y conviene dimensionarlo antes, no después.
• «El área de operaciones todavía no sabe, después les contamos». Sin ellos no hay adopción, y sin adopción no hay resultado.
• «Necesitamos que esté para la presentación del directorio». El plazo manda sobre el alcance y se termina entregando una demo, no una solución.

El resultado esperado del diagnóstico

Un diagnóstico bien hecho no termina en una propuesta de software. Termina en tres cosas: el problema priorizado con su costo estimado, la lista de datos que existen y los que faltan, y una decisión honesta sobre si conviene avanzar ahora, empezar por ordenar el registro, o atacar otro problema primero.

En MinerIA hacemos esta revisión en campo antes de proponer cualquier desarrollo, y a veces la conclusión es que todavía no es el momento. Preferimos decirlo en esa etapa y no seis meses después.