73,000 medidores inteligentes quedaron inertes de un día para otro, y el firmware había pasado todas las pruebas de laboratorio

En noviembre de 2024, una empresa de servicios públicos de Plano, Texas, envió una actualización de firmware rutinaria a 88,000 medidores de agua. Se suponía que la actualización corregiría el agotamiento prematuro de la batería, una reparación de buena fe de un problema conocido. En el laboratorio, funcionó. En el campo, 73,000 medidores quedaron inertes y nunca volvieron a funcionar.

Vuelvo una y otra vez a esa cifra por lo que implica. No fue un ataque informático, ni una tormenta, ni un defecto de fabricación. Fue una actualización de software que había sido probada y aprobada, comportándose exactamente como se diseñó, y aun así inutilizó el 83% de una flota. Esa brecha entre "pasó el laboratorio" y "mató el campo" es todo el problema en la IA para medidores inteligentes, y es la razón por la que creamos un sistema de mantenimiento predictivo de AMI en Veriprajna que vigila las señales que un panel de analítica nunca se diseñó para ver.

La primera vez que me senté con el responsable de operaciones de una empresa municipal de servicios públicos y observé su head-end de AMI —el sistema que recopila las lecturas de cada medidor— esperaba encontrar una sala de control. Lo que encontré fue una hoja de cálculo. Marcas de tiempo de última señal, una fila por medidor, y un lento desplazamiento de celdas que se volvían obsoletas. Podía decirme, con precisión, qué medidores habían dejado de comunicarse. No podía decirme cuáles dejarían de hacerlo a continuación. Esa asimetría —retrospectiva perfecta, previsión nula— es todo el mercado.

¿Por qué el firmware que pasa el laboratorio inutiliza el campo?

Esto es lo que realmente ocurrió en Plano, y es la historia más útil de todas en este ámbito.

El firmware se probó con medidores con baterías nuevas y una señal de radio fuerte: un banco limpio. Pero la flota desplegada tenía entre cuatro y cinco años, y la mayoría de esas baterías estaban al 60 a 75% de su capacidad original. Las rutinas actualizadas de gestión de energía consumían algo más de corriente durante la escritura inicial del flasheo. En una batería nueva, irrelevante. En una degradada, ese consumo adicional bastaba para activar la protección contra caídas de tensión. Los módulos de transmisión se reiniciaron, perdieron su registro en la red y nunca se recuperaron.

El firmware no falló. Cumplió las especificaciones. La flota simplemente había envejecido por debajo del banco de pruebas, y nadie estaba modelando eso.

Esa frase es la tesis de todo lo que construimos. El defecto no estaba en el código. Estaba en la suposición de que un medidor de laboratorio y un medidor de campo son la misma máquina. No lo son, y la diferencia se acumula en silencio durante años antes de que alguien pulse el botón que la expone.

Estos fallos se agrupan. El firmware del mismo proveedor ha producido incidentes similares en Minneapolis, Toronto y Nueva York. Toronto Hydro descubrió que aproximadamente 470,000 transmisores se degradaban antes de tiempo y gastó $5.6 millones solo en la primera ronda de remediación. Memphis registró una tasa de fallo sistémico del 8% y creó un fondo de reparación de $9 millones. En el Reino Unido, alrededor de uno de cada cinco medidores inteligentes no funcionan como deberían; más de 600,000 se han vuelto a conectar desde julio de 2024. A ninguna de estas empresas de servicios públicos le faltaba una plataforma de analítica. Todas tenían una. La plataforma simplemente no estaba vigilando lo que se rompió.

El error que defendí demasiado tiempo

Quiero ser honesto sobre la versión de esto que hicimos mal, porque es la parte que la mayoría de la gente omite.

Cuando empezamos, el movimiento obvio era la detección de anomalías. Un medidor a punto de fallar debería verse raro en sus datos: lecturas de consumo que se desvían, huecos en los reportes, patrones extraños. Así que construimos un modelo que vigilaba el flujo de consumo y marcaba anomalías. Era limpio. Se demostraba de maravilla. Lo defendí en sala tras sala.

Luego lo ejecutamos contra una ola de degradación real en una flota piloto, y se quedó ahí en verde mientras los medidores se estropeaban silenciosamente por debajo. Recuerdo la sensación específica de ver el panel mantenerse en calma y estar seguro de que el modelo estaba roto. El modelo no estaba roto. Lo había apuntado a la señal equivocada.

La detección de anomalías de consumo es exactamente lo que ya hacen los sistemas de gestión de datos de medición (MDMS) existentes. Oracle lanzó detección de anomalías impulsada por IA para su plataforma de servicios públicos en junio de 2025; SAP es líder del IDC MarketScape en la categoría. Estas herramientas son buenas en lo que hacen: detectan un medidor que reporta números extraños. El problema es que un medidor que se encamina hacia la muerte por firmware no reporta números extraños. Reporta números perfectamente normales, hasta que no reporta nada. Habíamos reconstruido lo que ya existía y heredado de nuevo su punto ciego.

Un medidor que está fallando no parece enfermo en sus datos de consumo. Parece sano, y luego desaparece. La señal que necesitas vive en algún lugar que el flujo de facturación no puede ver.

Lo que el MDMS no puede ver: dos señales que sí predicen el fallo

El giro llegó cuando dejamos de preguntar "¿es anómala esta lectura?" y empezamos a preguntar "¿qué se desgasta físicamente en un medidor, y podemos medirlo antes de que se rompa?"

Dos respuestas importaron.

La primera es el estado de carga de la batería, modelado por cohorte de despliegue en lugar de como un promedio de la flota. La lección de Plano es que un envío de firmware solo es peligroso frente a una distribución particular de salud de la batería, y esa distribución es conocible. Si agrupas cada endpoint por fecha de instalación y construyes histogramas de estado de carga por cohorte, puedes ver venir el precipicio de la caída de tensión antes de flashear nada. Empezamos a escalonar el firmware frente al perfil real de edad y capacidad de la flota, no frente a un banco lleno de unidades nuevas.

La segunda es el desgaste silencioso de la memoria NAND flash, y esta realmente cambió mi forma de pensar sobre toda la categoría. Los medidores inteligentes registran datos en la memoria flash: cada lectura, cada evento, a intervalos de 15 minutos para la respuesta a la demanda. Cada escritura desgasta físicamente las celdas. Los fabricantes especifican vidas útiles de 20 años, pero el registro de alta frecuencia consume los ciclos de escritura mucho más rápido de lo que asumían esas proyecciones. Y aquí está la parte insidiosa: a medida que la flash se degrada, las lecturas de consumo almacenadas se desvían entre un 2 y un 8% mientras el medidor sigue reportando con normalidad. La radio sigue comunicándose. El MDMS muestra un endpoint sano y comunicativo. Mientras tanto, los números están silenciosamente equivocados, se acumulan las disputas de facturación y la confianza pública se erosiona, y para cuando el medidor queda totalmente en silencio, la flash está demasiado degradada como para aceptar siquiera una corrección de firmware. Esa unidad necesita un camión y un reemplazo a $650 a $1,400 cada uno.

Así que la columna de "medidor reportando" del panel y su columna de "calidad de datos" pueden discrepar durante meses, y casi nadie lee la segunda. Convertimos la discrepancia entre esas dos en la alarma más ruidosa del sistema.

"Oracle ya hace esto. ¿Por qué lo están construyendo?"

Un asesor al que respeto lo dijo sin rodeos al principio: el espacio de la analítica está saturado, los actores establecidos son serios, ¿por qué construir?

Es una pregunta justa, y la respuesta honesta es que los actores establecidos están apiñados en torno a un problema diferente. La plataforma Distributed Intelligence de Itron es genuinamente impresionante: más de 16 millones de medidores habilitados, más de 100 millones de endpoints bajo gestión, una alianza de marzo de 2026 con NVIDIA para ejecutar IA en el borde de la red. El Revelo de Landis+Gyr, con una colaboración de Sense, realiza desagregación de carga a nivel de electrodoméstico a 1 megahercio. Sensus lanzó Evolve a principios de 2026 para reposicionar los medidores como sensores activos de la red. Toda la industria, como oficializó el tema de DistribuTECH 2026, se está moviendo "de AMI a IA."

Pero cada una de esas pilas de analítica funciona solo con los propios endpoints de ese proveedor. La inteligencia de Itron ve medidores Itron. La de Landis+Gyr ve Landis+Gyr. Las empresas de servicios públicos reales operan flotas mixtas, acumuladas a lo largo de una década de ciclos de adquisición —algunas Aclara, algunas Itron, algunas Sensus— y la analítica de ningún proveedor individual las abarca todas. Y ninguno de ellos, propietario o no, ofrece simulación de firmware previa al despliegue frente a tu flota envejecida específica. La brecha que inutilizó Plano está, estructuralmente, sin dueño.

Los actores establecidos te dirán que un medidor está reportando. Las herramientas de seguridad OT te dirán que está ejecutando firmware vulnerable. Ninguna te dirá que está a tres meses de una muerte de hardware.

Vale la pena nombrar aquí a los proveedores de seguridad, porque la gente asume que cubren esto. Claroty, Nozomi, Armis: hacen un excelente descubrimiento de activos, hasta la versión de firmware de cada endpoint, y entienden los protocolos industriales. Pero están construidos para encontrar el medidor que ejecuta una versión de firmware explotable, no el medidor cuya cohorte de batería no puede sobrevivir a la próxima escritura de flasheo. Mantenimiento y seguridad miran el mismo dispositivo y hacen preguntas diferentes. Necesitábamos la pregunta de mantenimiento, y no se estaba haciendo.

El banco donde el firmware va a fallar a propósito

La pieza de la que estoy más orgulloso es la menos glamurosa: un banco de emulación donde el firmware falla antes de que llegue al medidor de un cliente.

Levantamos un entorno QEMU —software que emula el hardware real del medidor— y flasheamos una imagen de firmware candidata contra endpoints simulados que llevan los perfiles reales de batería y señal de la flota. La cohorte de batería degradada, la cohorte de RF débil, la cohorte de alto ciclo de escritura. La primera noche que ejecutamos un perfil modelado sobre una flota envejecida y vimos a la unidad emulada sufrir una caída de tensión exactamente como lo hace el campo y como el laboratorio nunca lo hace, finalmente entendí que Plano no fue un accidente. Era reproducible. Simplemente nunca se había reproducido antes del despliegue, porque el entorno de pruebas no existía.

Esa es la inversión. Hoy, el campo es el entorno de pruebas, y los clientes son los sujetos de prueba. Movemos el fallo a un laboratorio donde inutilizar mil medidores simulados no cuesta nada y te enseña todo.

¿No significa el mantenimiento predictivo simplemente más falsas alarmas?

La objeción que más escucho de la gente de operaciones —quienes se han quemado con herramientas que dan falsas alarmas— es que la predicción es solo una forma más sofisticada de generar ruido.

Es la preocupación correcta. Un modelo de puntuación de salud que marca el 30% de tu flota cada semana es peor que inútil; las cuadrillas aprenden a ignorarlo, y has gastado presupuesto en recrear la fatiga de alertas con la que empezaste. Así que calibramos frente al costo, no frente a los recuentos de anomalías. El punto de referencia no era "cuántos fallos detectamos" sino "cuántas salidas de camión evitamos en relación con las que provocamos." Los datos de la industria sobre el mantenimiento predictivo impulsado por IA apuntan a reducciones de hasta el 30% en el costo de mantenimiento y a recortes significativos del tiempo de inactividad cuando se hace frente a la señal correcta, y la señal correcta, de nuevo, es el desgaste físico, no la rareza de los datos. Una predicción que no cambia una decisión de despacho no es una predicción. Es una notificación. Esto es, creo, la razón por la que tantas empresas de servicios públicos hacen pilotos de IA de mantenimiento y luego se estancan —el trabajo de BCG de 2026 sobre servicios públicos señala explícitamente la brecha del piloto a la producción—: demuestran que un modelo puede marcar fallos, y luego no pueden justificar el despliegue porque las marcas nunca se vinculaban con un despacho en el que un jefe de cuadrilla realmente confiaría.

La gestión de firmware acaba de convertirse en un documento de cumplimiento

Hay un giro regulatorio aquí que creo que muchas empresas de servicios públicos no han absorbido del todo, y eleva considerablemente lo que está en juego.

Desde el 1 de abril de 2026, NERC CIP-003-9 está en vigor. Su Requisito R1, Parte 1.2.6 impone controles de seguridad de acceso remoto de proveedores a los sistemas cibernéticos de red de bajo impacto, que es como se clasifican la mayoría de los medidores inteligentes. En términos sencillos: la ruta de actualización por aire que usas para enviar firmware es ahora una superficie de control regulada, y las sanciones por hacerlo mal ascienden hasta $1 millón por día. El mismo canal OTA que inutilizó Plano es ahora también un artefacto de cumplimiento para el que tienes que producir evidencia.

Eso cambia por completo la conversación con el comprador. La gestión de firmware solía ser una tarea rutinaria de operaciones. Ahora los registros de acceso, los registros de escalonamiento, los procedimientos de reversión: van en una carpeta que lee un auditor. Un sistema que valida el firmware antes del despliegue ya no solo previene interrupciones; genera la evidencia de que gestionaste la ruta de actualización de forma responsable.

Hay un estándar más discreto debajo de este sobre el que los equipos de adquisiciones preguntan y rara vez obtienen una respuesta clara: IEC 62443, el estándar de ciberseguridad industrial para AMI. Muy pocos proveedores de medidores han buscado la certificación IEC 62443 completa a nivel de componente —el firmware en sí—. La mayoría certifica en la capa del sistema y deja el firmware del endpoint sin certificar, lo que significa que la capa exacta que inutilizó Plano es también la capa con la atestación de seguridad más endeble. Esa brecha es la razón por la que hacemos auditorías de seguridad a nivel de componente en cadenas de suministro de AMI mixtas, no solo en el head-end. Al otro lado del Atlántico, los estándares de Ofgem del Reino Unido ahora exigen una compensación automática —£40 por incidente— por fallos de medidores atribuibles al proveedor, pagada en un plazo de 10 días hábiles. El costo de un medidor muerto ya no es solo la salida de camión. Es la multa, la compensación y el hallazgo de auditoría.

Lo que le diría al responsable de operaciones con el panel obsoleto

Si volviera ahora a esa hoja de cálculo de marcas de tiempo obsoletas, esto es lo que diría.

La cifra que debería quitarte el sueño no son los medidores que ya se han quedado en silencio. Es el 29%: la proporción de endpoints que algunas empresas de servicios públicos descubrieron que habían fallado silenciosamente, con las radios muertas, sin que se levantara ninguna alerta, y que salieron a la luz solo cuando alguien fue a buscarlos. Tu plataforma no te está mintiendo. Está respondiendo una pregunta más estrecha que la que realmente tienes. Sabe quién dejó de comunicarse. Tú necesitas saber quién está a punto de hacerlo.

El mercado de medidores inteligentes se dirige hacia los $112 mil millones para 2035, y la base instalada en Norteamérica ya supera los 150 millones de unidades. Cada uno de esos endpoints es una pequeña computadora con una batería que envejece y un chip flash que se desgasta, apoyada en el costado de un edificio, esperando un envío de firmware probado en algún lugar donde no vive. El próximo Plano ya está aprovisionado. La única pregunta abierta es si alguien modeló la flota sobre la que está a punto de aterrizar. Si prefieres descubrirlo en un banco que en las paredes de 73,000 clientes, ese es el sistema que hay que construir.

El firmware que inutilizó Plano pasó todas las pruebas que se le hicieron. Simplemente nunca le hicimos la correcta.