IA en minería: el valor está probado, la factura no
Por qué la IA sí paga en minería —pero le manda la cuenta al modelo operativo, la gobernanza de datos, los incentivos y la arquitectura— y cómo rediseñar la operación para capturar ese valor de forma soberana y resiliente.
La IA paga, pero le manda la factura al modelo operativo
La ponencia parte de una evidencia que el expositor considera zanjada: la IA sí genera valor y las empresas líderes en datos capturan más ingresos y márgenes. El problema no es si la IA funciona, sino quién captura el valor y quién no. La tesis central: la IA entrega valor pero cobra un costo que nadie presupuesta —cambiar el modelo operativo, la gobernanza de datos, los incentivos y la arquitectura tecnológica—. Sin ese rediseño, los pilotos no escalan a autonomía.
Las frases que resumen la charla
«Es un problema cultural» es la explicación cómoda —y es falsa
El expositor cuestiona el diagnóstico de moda que atribuye el fracaso de la IA a la «resistencia cultural» de las personas. Cuando se mira caso a caso, las razones para no adoptar son perfectamente racionales: los operadores son medidos por KPIs que los exponen si siguen la recomendación del sistema.
El ejemplo emblemático: un recomendador técnicamente correcto que la gente dejó de usar. No por desconfianza en la herramienta, sino porque cada vez que seguían la recomendación y algo salía mal, el KPI los castigaba a ellos. La herramienta funcionaba en contra de las personas.
Cuatro partidas que nadie presupuestó
El estudio Operational Autonomy in Mining 2026 (NTT DATA + MIT Technology Review, edición en español, resultados preliminares, n=25) sintetiza cuatro barreras concretas para capturar valor con IA en minería. Las cifras provienen directamente de las diapositivas.
1 · El dato no tiene dueño
- 64% reconoce datos fragmentados, con iniciativas activas para corregirlos.
- 20% describe sistemas apilados por proyecto, proveedor o área, con reconciliación manual como práctica recurrente.
- 16% reporta una arquitectura deliberada, con fuentes de verdad documentadas (los más maduros).
«El problema no es tener más datos. Es poder confiar en los datos que ya tienes.» Caso citado: un data lake logró conglomerar todas las operaciones, pero cada faena conservó su propio modelo de datos y había que «jurar» los datos a mano antes de cada reporte.
2 · El KPI castiga a quien confía en la máquina
- 60% identifica un conflicto entre los incentivos actuales y lo que intentan lograr con IA o autonomía.
- 28% mantiene los mismos KPIs de siempre, con métricas por área y bonos individuales.
- 12% rediseñó los incentivos antes de desplegar.
«El KPI es la instrucción real que recibe la gente. Mientras contradiga la decisión que quieres delegar, gana la contradicción.» Mover bonos y métricas es lento y político —pero es la palanca decisiva.
3 · La intención del negocio nunca llega al sistema
- 88% reconoce que necesita una interfaz de gobernanza para traducir su intención estratégica al sistema autónomo —y aún no la ha conectado.
- 4% tiene un documento de intención operativa que el supervisor de turno actualiza y que el sistema efectivamente consume.
«La operación sabe qué quiere maximizar, proteger y evitar. El sistema no lo puede leer.» Los sistemas se optimizan para disponibilidad y recuperación, pero no para articular la intención estratégica del negocio.
4 · Nadie se entrenó para el día malo
- 56% tiene protocolos documentados, pero admite que el entrenamiento bajo presión real no es suficiente.
- 32% dice que, si el sistema falla, el operador retoma «como antes», sin protocolo formal robusto.
- 12% trata la gestión por excepciones como un rol permanente y entrenado.
- En simulacros: 36% no corre ninguno; solo 4% corre dos o más al año bajo presión real.
«La autonomía no se prueba cuando el sistema funciona. Se prueba cuando falla.» El riesgo crítico que mencionó un entrevistado: un hackeo que deje tres días sin operar. Hay que preparar a la gente para operar «a ciegas», con conocimiento fenomenológico y procedimientos.
Rediseñar el modelo operativo no es un PowerPoint: tiene un plano
La integración «orgánica» —pegar una API por aquí, un chatbot por allá, un DSS más al lado— funciona perfecto hasta el primer tirón: un cambio de proveedor, un incidente de seguridad, un operador nuevo. Ahí se erosiona lo más valioso, la confianza. La alternativa es un diseño intencional con la tecnología al centro.
La arquitectura de referencia se estructura en cuatro planos, no uno:
- Información — ancha, abundante y rica en contexto. La IA sin contexto produce basura.
- Decisión — donde vive y se apoya la IA en la toma de decisiones.
- Actuación / control — estrecho, tipado y gobernado. No cualquiera puede «controlar la marcha».
- Seguridad funcional — independiente, no depende de la IA ni del GPS. DCS, SCADA e interlocks operan aunque la capa de decisión se caiga.
write_node("FIC_204.SP", 825) —una escritura directa, sin contexto ni límites—, el patrón gobernado es request_feed_strategy(...): el agente solicita una capacidad, un envolvente pide aprobación y un sistema determinístico verifica permisos y límites antes de cambiar nada, con trazabilidad completa.La autonomía se asigna peldaño a peldaño, no por proyecto
La adopción de IA es un camino de confianza que no se compra a un proveedor: se construye por madurez. Cada decisión se ubica en un peldaño según su confianza, riesgo, complejidad y quién dispara la acción.
Principios de diseño irrenunciables
- La planta debe producir aunque la plataforma de IA se caiga. Desplegar los agentes de decisión en el edge / dominio propio, con comunicaciones resilientes (los datos se duplican cada ~2 años o menos).
- «No construyas IA sobre incentivos rotos.»
- «La automatización excelente des-entrena al operador»: hay que gestionar el riesgo de desaprendizaje.
- «El operador siempre decide, el sistema siempre aprende.» Convertir los pilotos en productos mantenibles, no en proyectos que se traspasan a soporte y mueren como deuda técnica.
Soberanía de la capa de decisión
La forma de tomar decisiones es lo más íntimo y propio de una operación minera: debe ser soberana. Cuidado con las plataformas «agénticas» de proveedores que podrían cambiar tus reglas de negocio y apropiarse de tus datos. Los sistemas de decisión tienen que ser exportables; hay que gestionar el lock-in de los grandes vendors. El negocio necesita un solo socio tecnológico, no una dispersión.
«¿Qué hago con esto el lunes?» Seis preguntas críticas
El expositor cierra con seis preguntas binarias para auditar si un piloto está listo para escalar a autonomía. La regla: si una sola respuesta no es un «sí» confirmado, «estás comprando el piloto, no la autonomía».
- ¿Cada flujo de datos crítico tiene un dueño con nombre, no un área?
- ¿Auditaste los KPIs que chocan con lo que quieres delegar —antes de escalar?
- ¿La intención del turno está escrita en algo que el sistema pueda leer?
- ¿Cada dominio autónomo tiene un protocolo de degradación escrito?
- ¿Corriste un simulacro de falla bajo presión real este año?
- ¿Tu próximo contrato de compra garantiza exportar tu capa de decisión en formato abierto?
Del Q&A: elegir el nivel de complejidad tecnológica
Ante la pregunta del público sobre cómo elegir el grado de complejidad tecnológica, el expositor respondió que se necesita una estrategia de decisiones por dominio: no usar un agente costoso (p. ej. 50 millones de tokens) para una tarea trivial de control. Hay que analizar la complejidad, el riesgo y la velocidad de cada decisión y definir si es autónoma, semi-autónoma o manual con soporte (un DSS al lado, incluso un Excel), usando un framework adecuado. El moderador —gerente de una empresa de componentes— agregó que la nube pasó de atractiva a problemática por costos, y subrayó preparar la infraestructura para el crecimiento de tokens y sostener proyectos rentables.
Por qué nos importa
Esta sección es interpretación propia del equipo Nidatech y no forma parte de la charla. La leemos como proveedor tecnológico para la minería.
- Vender rediseño de modelo operativo, no licencias. El expositor deja claro que la factura de la IA está en el modelo operativo, no en el software. Nuestra propuesta de valor debería anclar en ayudar a rediseñar procesos, incentivos y gobernanza —no solo desplegar la herramienta—.
- Diseñar para la soberanía y contra el lock-in. El mensaje «los sistemas de decisión deben ser exportables» y «un solo socio tecnológico» es una oportunidad: posicionarnos como el socio que garantiza portabilidad de la capa de decisión y datos, y ganar la confianza que los grandes vendors erosionan.
- Arquitectura edge-first y operable sin nube. «La planta debe producir aunque la IA se caiga» valida invertir en despliegue en el edge, seguridad funcional independiente y resiliencia de comunicaciones —un diferenciador técnico frente a soluciones 100% cloud—.
- Convertir pilotos en productos con ciclo de vida. El riesgo de «entregar a soporte y que muera» es exactamente donde podemos diferenciarnos: producto mantenible, mejora continua y métricas de adopción que eviten el desaprendizaje del operador.