73.000 medidores «inteligentes» se apagaron de la noche a la mañana, y revelaron todo lo que fallaba en cómo construimos la IA para infraestructuras

Un amigo que dirige las operaciones de una empresa de servicios de agua de tamaño mediano me llamó un sábado por la mañana. No para ponernos al día, sino para desahogarse. Su equipo acababa de descubrir que una actualización de firmware enviada a su flota de medidores inteligentes la semana anterior había corrompido en silencio los datos de facturación de miles de cuentas. Los medidores se veían bien en el panel de control. Luces verdes por todas partes. Pero los números que llegaban al sistema de facturación estaban equivocados, y nadie se dio cuenta hasta que llegó una oleada de quejas de clientes.

«El proveedor dice que es un problema conocido», me dijo. «Están trabajando en un parche».

Le pregunté cuánto tiempo llevaban los medidores enviando datos erróneos. Hizo una pausa. «Creemos que unos nueve días».

Esa conversación se me quedó grabada, no porque la tecnología fallara, sino por lo invisible que era el fallo. No eran medidores que se hubieran desconectado. Eran medidores que seguían funcionando sin problemas, transmitiendo datos que parecían plausibles pero que eran silenciosamente erróneos. Y cuando empecé a tirar del hilo de los fallos de los medidores inteligentes en Norteamérica y el Reino Unido, me di cuenta de que la crisis de aquel sábado por la mañana de mi amigo era una nota a pie de página de una historia mucho más grande.

La noche en que 73.000 medidores quedaron en silencio

En Plano, Texas, la ciudad había gastado 10,2 millones de dólares en 87.000 medidores inteligentes de agua de Aclara Technologies, esperando que duraran veinte años. Para 2023, las baterías se agotaban antes de tiempo. ¿La solución del proveedor? Una actualización remota de firmware enviada en noviembre de 2024 para optimizar el consumo de energía.

Esa actualización inutilizó 73.000 medidores.

No «rendimiento degradado». No «problemas intermitentes». Los sistemas de transmisión electrónica simplemente dejaron de funcionar. Plano —una ciudad de casi 300.000 habitantes en la metrópolis de Dallas-Fort Worth— tuvo que contratar a 20 lectores de medidores temporales y volver a recorrer rutas puerta a puerta a pie. Costo: 765.000 dólares en dos años, solo por la mano de obra manual.

Vuelvo una y otra vez a la amarga ironía de esto. Se suponía que el firmware debía corregir el problema de la batería. En cambio, convirtió un problema de hardware localizado en un colapso de toda la red. He empezado a llamar a esto la Paradoja Firmware-Batería: el software diseñado para prolongar la vida del hardware se convierte en el principal mecanismo de su fallo.

El software diseñado para prolongar la vida del hardware a menudo se convierte en el principal mecanismo de su fallo.

Y Plano no está solo. Toronto perdió 470.000 transmisores por degradación temprana: 5,6 millones de dólares en costos iniciales de reparación. Memphis Light, Gas and Water se enfrentó a una tasa de fallo sistémico del 8 % en toda su flota de medidores inteligentes, reservando 9 millones de dólares para reparaciones. En el Reino Unido, más de 900.000 medidores inteligentes han sido reparados o reemplazados desde que los reguladores empezaron a prestar atención.

Escribí con más profundidad sobre la arquitectura técnica detrás de estos fallos en la versión interactiva de nuestra investigación, pero el patrón es coherente en todos los lugares donde miro: las empresas de servicios públicos gastaron miles de millones en digitalizar sus redes, y la infraestructura «inteligente» está fallando más rápido que los medidores mecánicos a los que reemplazó.

¿Por qué mueren jóvenes los medidores inteligentes?

Cuando mi equipo empezó a analizar las causas raíz, esperábamos encontrar una fabricación descuidada o componentes baratos. La realidad era más inquietante.

Los medidores inteligentes no son simples dispositivos de medición. Son computadoras en red: procesadores integrados, chips de IA de borde, protocolos de comunicación seguros, memoria flash para el almacenamiento de datos. Y, como cualquier computadora, están sujetos a modos de fallo que los medidores mecánicos nunca tuvieron.

El problema de la memoria flash es especialmente insidioso. Los medidores inteligentes usan flash NAND para almacenar el firmware y los registros de diagnóstico. Cada operación de escritura genera datos obsoletos que se eliminan mediante un proceso llamado recolección de basura, que desgasta físicamente las celdas de memoria. Si los sistemas de archivos integrados no están optimizados —y en muchos medidores desplegados no lo están—, el almacenamiento empieza a corromper datos años antes del supuesto fin de la vida útil del dispositivo.

Aquí es donde la llamada del sábado por la mañana de mi amigo cobra más sentido. A menudo, la corrupción es silenciosa. El medidor no arroja ningún error. No se desconecta. Simplemente empieza a transmitir números ligeramente equivocados. Para cuando alguien se da cuenta, ya tienes nueve días —o nueve meses— de datos de facturación erróneos y un problema de confianza del cliente que ningún parche de firmware puede arreglar.

Luego está la crisis de los casos límite. La complejidad del software en los medidores inteligentes se ha duplicado aproximadamente en los últimos años, pero las metodologías de prueba no han seguido el ritmo. Una actualización de firmware funciona a la perfección en el laboratorio, pero despliégala en un medidor con una batería ligeramente degradada en una zona rural con señal débil, y obtienes Plano.

Un detalle de la investigación que de verdad me alarmó: los medidores inteligentes modernos tienen un interruptor remoto de «APAGADO» integrado por conveniencia administrativa. Si un error de lógica en el firmware activa accidentalmente ese interruptor a gran escala, no estás ante imprecisiones de facturación, sino ante millones de hogares que se quedan sin electricidad simultáneamente.

¿Qué pasa cuando los reguladores empiezan a contar?

El regulador energético del Reino Unido, Ofgem, decidió que ya había visto suficiente. A partir de febrero de 2026, aplicará unos Estándares Garantizados de Rendimiento que obligan a realizar pagos automáticos de 40 libras a los clientes cuando no se cumplen los estándares de servicio de los medidores inteligentes. ¿Esperar más de seis semanas para una cita de instalación? Pago automático. ¿La instalación falla porque el proveedor se presentó sin el equipo adecuado? Pago automático. ¿Se informa de una avería en el medidor y no hay un plan de resolución en cinco días hábiles? Pago automático.

Esto no es un simple tirón de orejas. Para una empresa de servicios públicos con millones de clientes y una flota de medidores inteligentes envejecidos, las cuentas se vuelven aterradoras rápidamente. La presión por el cumplimiento ya ha impulsado la reparación de más de 900.000 medidores que antes no funcionaban en el Reino Unido.

Creo que la medida de Ofgem señala algo más grande que un simple regulador poniéndose duro. Es la formalización de un principio que debería haber sido obvio desde el principio: si despliegas infraestructura «inteligente», eres responsable de mantenerla inteligente. La era de instalar el hardware, marcharse y esperar que todo salga bien se acabó.

Si despliegas infraestructura «inteligente», eres responsable de mantenerla inteligente. La era de instalar y olvidarse se acabó.

Para los líderes de empresas de servicios públicos que lean esto, la implicación es contundente. El costo de mantener un medidor que funciona mal —en sanciones regulatorias, reparación manual, rotación de clientes y disputas de facturación— ahora supera el costo de implementar diagnósticos en tiempo real impulsados por IA. La ecuación económica se ha invertido.

«Usa GPT y ya está»: el consejo que me quita el sueño

Después de publicar algunos hallazgos preliminares sobre la fragilidad de los medidores inteligentes, tuve una conversación con un posible inversor en la que todavía pienso. Había visto los datos sobre los fallos de firmware, coincidía en que el problema era real y luego dijo: «Entonces construye un envoltorio de ChatGPT que analice los datos de los medidores. Lánzalo en tres meses».

Intenté explicarle por qué eso no funcionaría. Me interrumpió. «Toda startup de IA dice que necesita construir modelos personalizados. La mayoría simplemente lo está complicando demasiado».

Entiendo su lógica. El mercado está inundado de empresas que son, en esencia, interfaces delgadas sobre las API de OpenAI o Anthropic, lo que la industria llama «envoltorios de LLM». Algunas de ellas son genuinamente útiles para aplicaciones de bajo riesgo. Pero ¿para infraestructura crítica? El enfoque está fundamentalmente roto, y necesito explicar por qué.

¿Adónde van los datos?

Cuando usas una API de IA pública, tus datos salen de tu red y entran en los servidores de un tercero. Para una empresa de servicios públicos, esos datos incluyen la arquitectura de la red, los patrones de consumo de los clientes, el código de firmware propietario y, potencialmente, vulnerabilidades de infraestructura clasificadas. Esto no es un riesgo hipotético: es la exposición a la Ley CLOUD de EE. UU. y a cualesquiera políticas de retención de datos que el proveedor de la API tenga este trimestre.

A esto lo llamo Teatro de la Seguridad. La herramienta parece y se siente como una aplicación empresarial privada. El panel de control lleva el logotipo de tu empresa. Pero el backend es un servicio público, y tus datos operativos más sensibles fluyen a través de la infraestructura de otra persona.

¿Puede un modelo genérico entender tu red?

Un LLM público ha leído internet. Sabe qué es un medidor inteligente en abstracto. Lo que no sabe es la versión específica de firmware que se ejecuta en tus medidores Aclara del cuadrante noreste, el historial de mantenimiento de los transformadores que alimentan ese vecindario, o el hecho de que tu sistema de facturación heredado trunca los decimales de una manera que enmascara pequeños errores de medición.

La ventana de contexto de una API pública olvida los matices de tu infraestructura específica. No puede realizar el análisis de binarios necesario para verificar si una actualización de firmware es segura para una revisión de hardware concreta desplegada en una zona climática concreta. Pedirle que lo haga es como pedirle indicaciones a un turista: puede que suene seguro, pero en realidad no sabe adónde va.

¿Qué pasa cuando la API cambia?

Esta es la parte en la que los líderes de empresas de servicios públicos rara vez piensan hasta que es demasiado tarde. Si tu «solución de IA» es una capa de prompts sobre el modelo de otra persona, dependes de sus precios, de sus actualizaciones de modelo, de su tiempo de actividad y de sus decisiones de negocio. Cuando OpenAI cambia la estructura de su API o retira una versión de un modelo, tu herramienta de infraestructura crítica se rompe hasta que alguien reescribe los prompts.

La infraestructura crítica no puede depender de la continuidad del negocio de la página de precios de la API de una startup de Silicon Valley.

Cómo es realmente el Deep AI

Después de aquella conversación con el inversor, pasé una semana frustrado. Luego pasé tres meses construyendo lo que creo que es realmente la respuesta.

En Veriprajna, no revendemos claves de API. No construimos envoltorios. Desplegamos la pila completa de inferencia de IA —motores como vLLM, Text Generation Inference y BentoML— directamente en la propia infraestructura del cliente. Sus clústeres de Kubernetes. Sus GPU bare-metal. Su nube privada virtual (VPC).

La primera vez que configuramos una VPC de egreso cero para un cliente de servicios públicos —lo que significa que la red estaba configurada físicamente para que los datos no pudieran salir de su entorno incluso si alguien configuraba algo mal—, uno de sus ingenieros de seguridad miró el diagrama de arquitectura y dijo: «Es la primera vez que un proveedor de IA no me pide hacer una excepción a nuestra política de datos». Ese momento me dijo que íbamos por buen camino.

Construir un cerebro semántico

El problema del contexto —el que hace que los LLM genéricos sean inútiles para el trabajo real de infraestructura— lo resolvemos con lo que concibo como un «cerebro semántico». Ingerimos los documentos propietarios de la empresa de servicios públicos: manuales técnicos, informes históricos de mantenimiento, código fuente de firmware, registros de incidentes. Todo ello se indexa en bases de datos vectoriales locales como Milvus o Qdrant, sin salir nunca del entorno del cliente.

Pero esta es la parte de la que estoy más orgulloso: el sistema respeta los controles de acceso existentes. Si un empleado no tiene permiso para ver un documento en SharePoint, la IA no recuperará esa información para responder a su consulta. No añadimos la seguridad como una ocurrencia tardía: construimos la capa de inteligencia para que heredara la postura de seguridad existente de la organización.

La última milla de la precisión

Tomamos modelos base abiertos como Llama 3 y los ajustamos con precisión sobre el corpus específico de la empresa de servicios públicos usando técnicas como LoRA (Low-Rank Adaptation). El resultado es un modelo a medida que entiende la nomenclatura del cliente, sus sistemas heredados, sus peculiaridades operativas. En nuestras pruebas, este ajuste fino específico del dominio aumenta la precisión en tareas especializadas hasta en un 15 % en comparación con el modelo base.

Ese 15 % puede sonar incremental. No lo es. En la verificación de firmware, la diferencia entre una precisión del 85 % y del 100 % es la diferencia entre detectar una actualización peligrosa y dejar que inutilice 73.000 medidores.

¿Cómo detectar un error de firmware antes de que llegue al campo?

Esta es la pregunta que me impulsó después de estudiar el desastre de Plano. La actualización de firmware que mató a esos medidores no era maliciosa. No la escribieron ingenieros incompetentes. Simplemente no se probó contra toda la gama de condiciones del mundo real que encontraría.

Construimos un pipeline para esto. Comienza con la identificación de binarios, usando herramientas como EMBA y Firmwalker para extraer y analizar los sistemas de archivos del firmware, incluso cuando no se dispone del código fuente. Luego descompilamos el binario con Ghidra, y nuestro LLM privado analiza el código descompilado en busca de fallos de lógica, prácticas inseguras y posibles vulnerabilidades.

Pero la parte que cambió mi forma de pensar sobre la seguridad del firmware es el enfoque de gemelo digital. Probar firmware en dispositivos físicos en el campo es lento, costoso y arriesgado. En su lugar, construimos réplicas virtuales detalladas de hogares inteligentes y segmentos de la red, y luego desplegamos agentes de IA que usan aprendizaje por refuerzo para interactuar con estos gemelos digitales, sondeando sistemáticamente los casos límite que los evaluadores humanos pasan por alto.

En nuestra investigación, este método encontró vulnerabilidades un 38 % más rápido que los enfoques de prueba aleatorios. Para el desglose técnico completo del pipeline de verificación de firmware y la metodología de gemelo digital, te animo a leer el artículo, pero la conclusión clave es esta: ahora podemos simular las condiciones que causaron el fallo de Plano antes de que la actualización se distribuya.

Ahora podemos simular las condiciones que causaron fallos catastróficos de firmware antes de que la actualización llegue siquiera al campo.

De reactivo a predictivo: qué cambia cuando la IA vigila la red

El enfoque tradicional del mantenimiento de servicios públicos es reactivo (arréglalo cuando se rompa) o programado (inspecciónalo cada X meses lo necesite o no). Ambos son costosos y ambos pasan por alto los fallos que más importan: las degradaciones lentas y silenciosas que no se anuncian hasta que ya han causado daños.

Los modelos de Deep AI entrenados con datos de sensores de alta frecuencia aprenden cómo es lo «normal» para cada dispositivo, cada transformador, cada segmento de la red. Cuando algo se desvía —un patrón de vibración inusual, una fluctuación de temperatura que no coincide con el clima, una flota de medidores que muestran todos a la vez una mayor latencia de comunicación—, el sistema lo señala antes de que se convierta en una crisis.

Hubo un momento durante nuestras primeras pruebas en que el sistema de detección de anomalías señaló un grupo de medidores que mostraban todos un aumento sutil en la latencia de respuesta. Nada dramático: quizá 15 milisegundos más lento que la línea base. Mi equipo debatió si esto era ruido o señal. Nuestro ingeniero sostenía que era ambiental, relacionado con la temperatura. Yo insistí en investigar más a fondo. Resultó ser un indicador temprano de degradación de la memoria flash en un lote específico de dispositivos. Sin control, esos medidores habrían empezado a corromper datos en cuestión de meses.

Ese es el tipo de hallazgo que justifica toda la inversión. Y los números lo respaldan: se ha demostrado que el mantenimiento predictivo impulsado por IA reduce los fallos de infraestructura en un 73 %, recorta los costos de mantenimiento entre un 18 % y un 25 %, y prolonga la vida útil de los activos hasta en un 40 %.

El sistema también usa IA explicable: cuando señala una anomalía, le muestra al operador humano por qué, usando herramientas de visualización como GradCAM. El operador puede verificar, corregir o anular el juicio de la IA. Ese bucle de retroalimentación significa que el sistema se vuelve más inteligente con el tiempo, reduciendo los falsos positivos y construyendo el tipo de conocimiento institucional que normalmente solo reside en la cabeza de los ingenieros veteranos que están a cinco años de jubilarse.

¿Y el ROI?

La gente siempre objeta el costo de desplegar infraestructura de IA privada frente a simplemente usar una API. Es una pregunta justa. Ejecutar tus propios clústeres de GPU y mantener tus propios modelos no es barato.

Pero considera lo que cuesta la alternativa. Plano: 765.000 dólares en lectores de medidores manuales, más los 10,2 millones de dólares de la inversión original que ahora está significativamente deteriorada. Memphis: un fondo de reparación de 9 millones de dólares. Toronto: 5,6 millones de dólares y subiendo. Empresas de servicios públicos del Reino Unido: el costo acumulado de reemplazar 900.000 medidores más las multas regulatorias que están a punto de empezar a llegar.

Las industrias informan de costos medios de interrupción de 125.000 dólares por hora. Una reducción del 30-50 % en el tiempo de inactividad no solo paga la IA, sino que transforma el perfil financiero de la empresa de servicios públicos. Cuando sumas el gasto de capital diferido por prolongar la vida útil de los activos en un 40 %, una reducción del 28 % en los retrasos de la cadena de suministro de componentes y una reducción del 40 % en los incidentes de seguridad, el cálculo del ROI no está ni cerca.

La pregunta no es si las empresas de servicios públicos pueden permitirse una infraestructura de IA soberana. Es si pueden permitirse otro Plano.

El verdadero foso defensivo de una empresa de servicios públicos no es el modelo de IA en sí: puedes descargar Llama 3 gratis. El foso es la integración profunda con datos propietarios, el ajuste fino específico del dominio, el conocimiento institucional codificado en un sistema que reside en una infraestructura que tú controlas. Ese es un activo que se revaloriza con el tiempo. Una suscripción a una API es un costo que te pueden quitar.

La red hacia la que avanzamos

Con una previsión de más de 30.000 millones de dispositivos IoT para 2026, el problema de la complejidad no va a desaparecer. Se está acelerando. La próxima frontera —y hacia lo que mi equipo está trabajando activamente— son los flujos de trabajo de IA agéntica: sistemas que no solo señalan anomalías, sino que actúan. Poniendo automáticamente en cuarentena un dispositivo IoT comprometido. Ajustando los parámetros de los transformadores en tiempo real según los patrones de carga previstos. Ejecutando reversiones de firmware en el momento en que una actualización muestra signos de estar causando problemas.

La IA de borde llevará la inteligencia aún más lejos: medidores inteligentes que funcionan como micromotores de decisión, ejecutando la detección local de anomalías con una latencia inferior a 10 milisegundos, tomando decisiones sin esperar un viaje de ida y vuelta a la nube.

Pero nada de esto funciona si los cimientos están mal. Y ahora mismo, para la mayoría de las empresas de servicios públicos, los cimientos están mal. Están ejecutando infraestructura del siglo XXI sobre paradigmas de mantenimiento del siglo XX, y cuando recurren a la IA, agarran la opción más barata y conveniente —un envoltorio en torno a la inteligencia de otra persona— en lugar de construir una capacidad soberana.

Los fallos en Plano, Toronto, Memphis y por todo el Reino Unido no son fallos técnicos puntuales. Son el resultado predecible de un desajuste sistémico entre la complejidad de la infraestructura moderna y las herramientas que usamos para gestionarla. Toda empresa de servicios públicos que despliega medidores inteligentes sin invertir en la inteligencia para gobernarlos de verdad está construyendo un sistema diseñado para fallar de maneras que no puede detectar.

La elección a la que se enfrentan los líderes de las empresas de servicios públicos no es entre IA y no IA. Ese debate ha terminado. La elección es entre alquilar inteligencia a proveedores que no tienen ningún interés en la fiabilidad de tu red, o construir capacidades soberanas que conviertan tus datos operativos en tu activo más valioso. Uno de esos caminos conduce al próximo Plano. El otro conduce a una red que es genuinamente tan inteligente como seguimos prometiendo que es.