1. La decisión de inversión
La empresa de servicios públicos debe decidir si un sistema de detección propuesto puede reducir el coste económico total de las fugas y la respuesta. Esa decisión abarca sensores, comunicaciones, ingeniería de datos, modelos, revisión por analistas, confirmación sobre el terreno, reparación y retroalimentación. Un modelo que genera alertas sin una vía fiable hacia la acción sobre el terreno está incompleto.
La aprobación debe indicar la red objetivo, los tipos de fuga, la línea base operativa, los errores aceptables, el coste de despliegue, el flujo de trabajo del servicio, el periodo de evidencia y las condiciones para escalar. La decisión debe permanecer vinculada a resultados de campo verificados.
2. Definir el resultado útil
El resultado útil es una fuga que se detecta con suficiente antelación, se localiza con suficiente precisión, se confirma de forma eficiente y se repara de forma económica. La detección por sí sola identifica comportamiento anómalo. La localización acota la búsqueda. La confirmación determina si el evento es real. La reparación convierte la información en beneficio en materia de agua y servicio.
Estas etapas deben medirse por separado. Un sistema puede detectar una anomalía con precisión mientras envía equipos a una zona de búsqueda amplia o incorrecta.
3. El problema de la tasa base
Las fugas son raras en relación con los intervalos operativos normales. Incluso una pequeña tasa de falsos positivos puede generar más alertas falsas que verdaderas cuando se examinan millones de observaciones normales. Por tanto, la precisión depende tanto del comportamiento del modelo como de la tasa subyacente de eventos.
Un piloto debe divulgar el número de fugas verdaderas, periodos normales, alertas, investigaciones y resultados confirmados. La exactitud general puede parecer alta cuando el modelo predice mayoritariamente la clase común de ausencia de fugas.
4. La economía de la matriz de confusión
Un verdadero positivo puede acelerar la reparación. Un falso positivo consume capacidad de revisión y de campo. Un falso negativo deja una fuga sin detectar. Un verdadero negativo evita la intervención. Cada resultado tiene un coste diferente, y esos costes varían según el activo, la ubicación y la consecuencia.
El umbral económico debe reflejar el agua evitada, los daños, la interrupción del servicio y la escalada frente al coste de analista, inspección, excavación y evento no detectado.
5. Precisión y exhaustividad
La precisión mide la proporción de alertas que son verdaderas. La exhaustividad mide la proporción de eventos reales detectados. Aumentar la sensibilidad puede mejorar la exhaustividad al tiempo que incrementa las alertas falsas. Endurecer el umbral puede mejorar la precisión al tiempo que se pasan por alto eventos más pequeños.
Trabajos recientes con múltiples redes reportan valores de precisión y exhaustividad sustancialmente diferentes entre estructuras de red y tamaños de fuga [1]. No debe suponerse que un único umbral sirva para todos los distritos o estados operativos.
6. Arquitectura de detección a reparación
Estructura genérica; los sistemas, las responsabilidades y los controles reales dependen de la empresa de servicios públicos y de la jurisdicción.
7. Detección frente a localización
La detección binaria pregunta si existe un evento. La localización pregunta dónde está. La estimación del tamaño pregunta qué magnitud puede tener. Los benchmarks de investigación muestran que el rendimiento de detección puede superar al de localización, especialmente con ruido, sensores dispersos o firmas hidráulicas débiles [2].
La contratación debe especificar la tolerancia de localización requerida y la carga de búsqueda en campo. Una alerta correcta que abarca varios kilómetros puede seguir siendo operativamente costosa.
8. Definir las clases de fugas
Las fugas pueden incluir fugas de fondo, fugas en acometidas, roturas, pérdidas en válvulas o hidrantes, desbordamiento de depósitos y eventos en el lado del cliente. Sus señales, consecuencias y tiempos de respuesta difieren.
La taxonomía debe identificar qué clases está diseñado el sistema para detectar. Las afirmaciones de los proveedores no deben extenderse de una clase probada a todos los mecanismos de pérdida sin evidencia.
9. Establecer la línea base operativa
La línea base debe registrar los métodos de detección actuales, la frecuencia de inspección, el tiempo de respuesta, la confirmación de reparación, el tiempo de fuga en funcionamiento, el agua perdida, las visitas repetidas y el coste. También debe documentar la segmentación de la red, el parque de sensores, la disponibilidad de telemetría y las limitaciones de campo.
El caso de inversión necesita un contrafactual. Una fuga encontrada por AI también podría haberse encontrado mediante análisis rutinario de caudal nocturno o informes de clientes.
10. Sensores de presión
Los cambios de presión pueden indicar roturas, eventos de demanda, operaciones de válvulas, cambios de bombas y fugas. La ubicación, la resolución, el muestreo y la sincronización de los sensores influyen en la capacidad de detección.
Los modelos deben incorporar eventos operativos conocidos y zonas de gestión de presión. Un umbral entrenado bajo un régimen de control puede fallar tras cambios en el punto de consigna o en el suministro.
11. Sensores de caudal
Los caudales de distrito y de límites respaldan los métodos de caudal mínimo nocturno, balance y anomalías. Unos límites fiables y contadores de entrada calibrados son esenciales.
Las anomalías de caudal pueden reflejar demanda legítima, transferencias de red, purgas o errores de medición. El contexto y la confirmación siguen siendo necesarios.
12. Detección acústica
Los registradores acústicos y los correladores pueden detectar ruido de fugas y ayudar a localizarlas. El material y el diámetro de la tubería, el suelo, el ruido de fondo, la presión y la separación entre sensores afectan a la propagación.
El uso del agua, las bombas y el ruido ambiental pueden parecerse a fugas. La confirmación sobre el terreno debe seguir formando parte del flujo de trabajo.
13. Fibra y detección distribuida
La fibra existente o instalada puede permitir una monitorización acústica o de vibración continua a lo largo de corredores extensos. La cobertura y el volumen de datos pueden resultar atractivos para tuberías principales críticas.
El caso de negocio debe incluir derechos de acceso, equipos de interrogación, procesamiento de señales, análisis especializado, clasificación de falsos eventos e integración de reparaciones.
14. Infraestructura de medición avanzada
Los intervalos de los contadores de cliente pueden revelar consumo continuo y posibles fugas en las instalaciones. La detección en la red de distribución también puede utilizar residuos de demanda agregada y contexto hidráulico.
La cobertura de AMI, el intervalo, la fiabilidad de las comunicaciones y el consentimiento del cliente determinan el caso de uso. Las alertas del lado del cliente requieren un proceso de servicio independiente.
15. Teledetección satelital y remota
La teledetección puede priorizar áreas amplias utilizando la superficie, la humedad u otras señales. Puede complementar la inspección sobre el terreno donde el acceso resulte difícil.
Las condiciones del terreno, el clima, la profundidad y la humedad no procedente del agua pueden afectar a la interpretación. Deben incluirse el coste de confirmación y la frecuencia de revisión.
16. Fusión de sensores
Combinar datos de presión, caudal, acústicos, de AMI, de órdenes de trabajo, meteorológicos y operativos puede reducir la ambigüedad. La fusión también aumenta los requisitos de integración y de calidad de los datos.
El modelo debe revelar qué fuentes motivaron la alerta y cómo se comporta cuando una fuente no está disponible. La resiliencia debe probarse mediante escenarios de ablación de sensores.
17. Ubicación de sensores
La ubicación debe ajustarse al tamaño objetivo de fuga, la topología de red, la sensibilidad hidráulica, los activos críticos, las comunicaciones y el acceso en campo. Un espaciado uniforme puede desperdiciar cobertura o pasar por alto áreas de baja sensibilidad.
La investigación sobre falsación de modelos y ubicación de sensores demuestra que la incertidumbre y la configuración de la red afectan la capacidad de localización [3]. El piloto debe probar alternativas de ubicación antes del despliegue completo.
18. Muestreo y sincronización
Los transitorios rápidos pueden requerir datos de alta frecuencia y estrechamente sincronizados. Las fugas de fondo lentas pueden detectarse mediante tendencias de menor frecuencia. El muestreo debe ajustarse a la señal física y a la decisión operativa.
La deriva del reloj, los intervalos faltantes y la agregación pueden producir anomalías aparentes. Los controles de ingeniería de datos deben especificarse junto con el modelo.
19. Comunicaciones
La conectividad determina la latencia, la completitud y el coste. El diseño puede utilizar redes celulares, de radio, de fibra, de bajo consumo o métodos de almacenamiento y reenvío.
La cobertura, la alimentación, el volumen de datos, el mantenimiento y los controles de ciberseguridad deben probarse en el entorno real de despliegue. La conectividad de laboratorio no es evidencia de campo.
20. Controles de calidad de datos
El pipeline de datos debe comprobar la plausibilidad, el rango, la alineación temporal, la duplicación, los valores faltantes, el comportamiento de línea plana y el estado de calibración. Los datos que no superen un control crítico no deben generar una alerta operativa sin las salvedades correspondientes.
El estado de calidad debe acompañar a la predicción para que los analistas puedan distinguir las anomalías de red de las anomalías de sensores.
21. Calidad de las etiquetas
El aprendizaje supervisado requiere ejemplos marcados como fuga o normal. Las etiquetas pueden proceder de pruebas controladas, reparaciones confirmadas, órdenes de trabajo, inspecciones o simulación. Cada una tiene limitaciones.
Las órdenes de trabajo pueden omitir alertas no detectadas o contener horas y ubicaciones inexactas. Las liberaciones controladas pueden no representar fallos naturales. El registro de entrenamiento debe conservar la procedencia y la confianza.
22. Datos de eventos raros
Las fugas grandes pueden ser operativamente importantes y estadísticamente escasas. Las fugas pequeñas pueden ser más numerosas pero débilmente visibles. Un conjunto de datos debe representar el evento previsto y las condiciones de la red.
El remuestreo puede ayudar al entrenamiento a la vez que mantiene realista la prevalencia de la evaluación. El rendimiento debe informarse sobre un conjunto representativo del campo que no se haya modificado.
23. Simulación
Los modelos hidráulicos y transitorios pueden generar escenarios etiquetados en distintas ubicaciones y tamaños. Permiten experimentos controlados y la exploración de la cobertura.
Los supuestos de simulación sobre la demanda, la rugosidad, los controles, el ruido y el comportamiento de los sensores deben documentarse. Un modelo entrenado con datos sintéticos requiere validación de campo.
24. Brecha entre simulación y campo
Investigaciones recientes informan de una pérdida sustancial de rendimiento cuando los modelos entrenados con simulación se aplican directamente a mediciones de campo, con mejoras tras el aprendizaje por transferencia con datos de campo [4]. Esa evidencia respalda una etapa de adaptación deliberada.
La empresa de servicios públicos debe conservar un conjunto de reserva de campo y evitar que se realice un ajuste repetido contra la muestra final de aceptación.
25. Clases de modelos
Los métodos incluyen umbrales estadísticos, detección de cambios, residuos hidráulicos, máquinas de vectores de soporte, conjuntos de árboles, redes neuronales, modelos de grafos, transformers y autocodificadores. Ninguna clase de modelo es automáticamente la mejor para todas las redes.
La selección debe basarse en la precisión de campo, la exhaustividad, la localización, la latencia, la interpretabilidad, la mantenibilidad y el coste, en lugar de la novedad.
26. Clasificación supervisada
Los modelos supervisados aprenden de ejemplos etiquetados. Pueden funcionar bien cuando las etiquetas de campo cubren la variación operativa y la clase objetivo.
El rendimiento puede degradarse con nuevos materiales de tubería, estaciones, zonas de presión o configuraciones de sensores. El plan de despliegue necesita reglas de monitorización y reentrenamiento.
27. Detección de anomalías no supervisada
Los métodos no supervisados aprenden patrones normales y puntúan las desviaciones. Pueden identificar eventos nuevos con menos etiquetas de fuga.
También pueden generar alertas ante cambios operativos legítimos. El equipo de operaciones necesita contexto, gobernanza de umbrales y un proceso para clasificar los resultados.
28. Métodos de residuos hidráulicos
Los métodos de residuos comparan la medición con la predicción del modelo. Su valor depende de la calibración del modelo, la estimación de la demanda y la incertidumbre de los sensores.
Pueden aportar interpretación física y localización, mientras que los cambios en la red requieren mantenimiento del modelo. La empresa de servicios públicos debe presupuestar la calibración.
29. Explicabilidad
Los analistas necesitan suficiente evidencia para priorizar e investigar alertas. Una explicación útil puede incluir sensores afectados, ventana temporal, dirección de la desviación, área candidata, eventos comparables y estado de calidad de los datos.
La explicación debe apoyar el criterio operativo. Una explicación visual no demuestra la corrección causal.
30. Embudo de alertas
Cifras solo ilustrativas; los volúmenes reales dependen de la red, el modelo y los umbrales operativos.
31. Gobernanza de umbrales
Los umbrales determinan el volumen de alertas y los eventos no detectados. Deben aprobarse por caso de uso, zona y consecuencia. Los operadores deben saber cuándo cambió un umbral y por qué.
La detección de emergencias o de tuberías principales críticas puede favorecer la exhaustividad; la labor rutinaria de fugas de fondo puede favorecer la precisión. El modelo económico debe reflejar esta elección.
32. Fatiga de alarmas
La guía de la EPA sobre la detección de eventos en sistemas de distribución describe la necesidad de equilibrar la sensibilidad con los falsos positivos y reconoce la fatiga de alarmas provocada por alertas excesivas [5]. Las operaciones de detección de fugas afrontan una limitación humana comparable.
Deben monitorizarse el tamaño y la antigüedad de la cola, el tiempo de revisión, los motivos de descarte y las alertas repetidas. Una alerta no atendida no tiene valor operativo.
33. Deduplicación de alertas
Un único evento físico puede generar puntuaciones repetidas entre sensores y a lo largo del tiempo. La plataforma debe agrupar las señales relacionadas en un incidente y conservar la evidencia subyacente.
Una deduplicación deficiente infla el recuento agregado de alertas y la carga de trabajo de los analistas. La precisión a nivel de incidente es más útil que la precisión a nivel de registro.
34. Priorización
Las alertas pueden clasificarse por pérdida estimada, consecuencia, confianza, clientes críticos, riesgo vial, acceso y proximidad a otros trabajos. El método de clasificación debe seguir siendo transparente.
Una confianza alta no siempre implica un valor alto. Un evento de confianza moderada en una tubería principal crítica puede requerir una revisión más rápida.
35. Triaje de analistas
Los analistas deben revisar la calidad de los datos, los eventos operativos, los sensores cercanos, el contexto hidráulico, el historial y las consecuencias. El triaje debe dar lugar a descartar, monitorizar, realizar una prueba remota o una acción sobre el terreno.
Deben medirse el tiempo de decisión y la consistencia. Los ejemplos de entrenamiento pueden utilizar resultados adjudicados.
36. Confirmación en campo
La confirmación puede emplear estudio acústico, pruebas por etapas, registro de presión, inspección visual, métodos de trazadores o aislamiento controlado. El método debe ajustarse a la tubería y a la ubicación.
Los equipos de campo necesitan una zona de búsqueda, un paquete de evidencias, un plan de seguridad y un código de cierre. Una alerta permanece sin verificar hasta que se cumpla el estándar de confirmación acordado.
37. Decisión de excavación
La excavación tiene un coste directo y genera interrupciones. La empresa de servicios públicos debe definir cuándo la confianza y las consecuencias justifican una excavación, trabajos exploratorios o monitorización continua.
La decisión debe tener en cuenta el tráfico, los permisos, el impacto en los clientes y la oportunidad de coordinar los trabajos planificados.
38. Confirmación de reparación
Tras la reparación, la empresa de servicios públicos debe confirmar el defecto y observar si la señal y el balance hídrico cambian según lo esperado. Una reparación que no explica la alerta aporta nuevas evidencias.
El registro de resultados debe conservar la ubicación, el activo, el defecto, la estimación de caudal, el coste, la duración y la respuesta de la señal.
39. Bucle de retroalimentación
Los resultados confirmados deben actualizar las etiquetas, los umbrales, las reglas y la monitorización del modelo. Las alertas descartadas deben registrar un motivo, no simplemente desaparecer.
La calidad de la retroalimentación es una capacidad operativa. El reentrenamiento del proveedor debe ser auditable y estar sujeto a controles de aceptación.
40. Cuadro de mando de rendimiento
Tabla 1. Cuadro de mando ilustrativo de detección y operación
| Dimensión | Métrica | Evidencia | Uso en la decisión |
|---|---|---|---|
| Detección | Exhaustividad por clase y tamaño de fuga | Eventos confirmados y pruebas controladas | Exposición a eventos no detectados |
| Calidad de las alertas | Precisión y falsos descubrimientos | Adjudicación a nivel de incidente | Carga de trabajo de analistas y personal de campo |
| Localización | Error de distancia o de área de búsqueda | Ubicación de reparación confirmada | Coste de inspección y excavación |
| Puntualidad | De la detección al triaje y la reparación | Marcas de tiempo del sistema y de las órdenes de trabajo | Beneficio por tiempo de funcionamiento evitado |
| Fiabilidad | Disponibilidad de datos y tiempo de actividad del modelo | Registros de la plataforma | Continuidad operativa |
| Condiciones económicas | Coste por fuga confirmada y beneficio neto | Registro financiero y de resultados | Escalar o rediseñar |
41. Coste de los falsos positivos
El coste de los falsos positivos incluye la revisión de analistas, la monitorización repetida, la inspección sobre el terreno, los desplazamientos, el control del tráfico, el contacto con el cliente y una posible excavación. También incluye el coste de oportunidad cuando los equipos aplazan trabajo real.
El modelo debería calcular el coste por ruta de alerta en lugar de usar un único promedio. La mayoría de las falsas alertas pueden resolverse de forma remota, mientras que una pequeña proporción impulsa actividades de campo costosas.
42. Coste de los falsos negativos
Una fuga no detectada puede seguir perdiendo agua, energía y productos químicos y puede escalar hasta una interrupción del servicio o daños. El coste depende del caudal de fuga, la duración, la ubicación y las consecuencias.
La empresa de servicios públicos debería evitar supuestos de catástrofe no respaldados. Los rangos de escenarios deberían separar las pérdidas rutinarias de los eventos de altas consecuencias.
43. Coste del error de localización
Una localización deficiente amplía la distancia de inspección, retrasa la confirmación y puede provocar excavaciones innecesarias. Por lo tanto, el tamaño del área de búsqueda es una métrica económica.
Los modelos deberían informar las distribuciones de errores y las zonas difíciles. La distancia promedio puede ocultar una cola larga que impulsa el coste.
44. Valor del tiempo
La detección temprana genera valor cuando acorta el tiempo de fuga activa respecto a la práctica actual. El beneficio solo comienza tras la revisión y actuación sobre la alerta.
El tiempo de extremo a extremo debe abarcar el inicio del evento, la puntuación, la decisión del analista, la visita de campo, la reparación y el cierre. La latencia del modelo por sí sola no es suficiente.
45. Valor del agua evitada
El agua evitada puede valorarse al coste marginal de producción a corto plazo, valor de escasez, capacidad diferida o valor tarifario, según la decisión. Son conceptos diferentes.
El caso de negocio debe indicar el valor elegido y evitar el doble cómputo. El beneficio en efectivo disponible para financiación puede ser más limitado que el beneficio económico.
46. Valor de daños y servicio
La actuación temprana puede reducir costes de carretera, propiedad, interrupciones y emergencias. Los datos históricos de incidentes pueden respaldar rangos de escenarios.
Los eventos graves poco frecuentes deben ponderarse por probabilidad y divulgarse por separado. Debe considerarse el tratamiento asegurador y los deducibles.
47. Estructura de costes
Tabla 2. Desglose ilustrativo del coste total
| Capa de costes | Partidas típicas | Plazos | Control |
|---|---|---|---|
| Parque de sensores | Dispositivos, instalación, alimentación y calibración | Inicial y sustitución | Cobertura y registro de activos |
| Conectividad y plataforma | Comunicaciones, almacenamiento, integración y soporte | Recurrente | Niveles de servicio y controles de uso |
| Operaciones de modelos | Configuración, monitorización, reentrenamiento y licencias | Recurrente e impulsado por cambios | Control de versiones y aceptación |
| Flujo de trabajo humano | Triaje de analistas, encuestas y gestión de programas | Basado en alertas | Informes de colas y productividad |
| Actuación en campo | Confirmación, tráfico, excavación y reparación | Basado en incidentes | Evidencia de órdenes de trabajo y resultados |
| Reserva para riesgos | Fallos, respuesta ante ciberataques y transición | Contingente | Registro de riesgos y reserva |
48. Conjunto de beneficios
Los beneficios pueden incluir ahorro de agua y energía, menores necesidades de respuesta ante emergencias, menos daños, mejor continuidad, mejor focalización de la renovación y evidencia regulatoria más sólida. Cada beneficio requiere una línea de base y un responsable.
El modelo de inversión debe distinguir entre efectivo, coste evitado, capital diferido y valor público. Solo el efectivo realizado o financiado contractualmente debe respaldar el servicio de la deuda.
49. Sensibilidad ilustrativa
Valores únicamente ilustrativos; esto no constituye una previsión, valoración ni comparación de proveedores.
50. CAPEX frente a modelo de servicio
La empresa de servicios públicos puede ser propietaria de los sensores y de la plataforma, suscribirse a un servicio gestionado o utilizar un modelo híbrido. La titularidad afecta al control, las competencias, la integración, la sustitución y la salida.
La comparación económica debe utilizar el coste total durante la vida útil prevista e incluir la transición. Un precio piloto bajo puede no representar las operaciones a plena escala.
51. Financiación
La infraestructura digital puede financiarse con capex de la empresa de servicios públicos, presupuestos operativos, fondos de innovación, subvenciones, financiación de proveedores o programas de rendimiento más amplios. La financiación debe ajustarse a la vida útil del activo y a la exigibilidad del contrato.
El beneficio modelado no proporciona automáticamente efectivo para la devolución. La autoridad presupuestaria y la fuente de pago deben permanecer explícitas.
52. Pago basado en el rendimiento
La remuneración del proveedor puede vincularse en parte a la disponibilidad del servicio, las alertas aceptadas, las fugas verificadas, el plazo de entrega o el beneficio neto. La métrica debe permanecer dentro de la influencia del proveedor y resistir la manipulación.
El pago únicamente por alerta recompensa el volumen. El pago únicamente por fuga confirmada puede desincentivar eventos difíciles pero valiosos. Una estructura equilibrada puede combinar componentes fijos de capacidad y de resultado.
53. Sala de datos de contratación
La sala de datos debe incluir mapas de red, inventario de sensores, muestras de telemetría, historial de eventos y reparaciones, registros operativos, métodos existentes, calidad de los datos, estándares de seguridad y flujo de trabajo en campo.
Los licitadores deben recibir un conjunto de datos de evaluación común cuando sea factible. La información confidencial y de infraestructura crítica requiere acceso controlado.
54. Normalización de afirmaciones de proveedores
Las afirmaciones deben indicar la red, la tubería, el sensor, la prevalencia de eventos, el tamaño de la fuga, el ruido, los datos de entrenamiento, la partición de prueba y la unidad de evaluación. La precisión sin estas condiciones es insuficiente.
La empresa de servicios públicos debe traducir cada afirmación al entorno operativo objetivo y solicitar evidencia reproducible.
55. Diseño del piloto
Un piloto debe incluir distritos representativos, estaciones, estados de demanda, materiales de tuberías y condiciones de los sensores. Debe ejecutarse durante el tiempo suficiente para observar la variación normal y eventos genuinos o controlados.
El protocolo debe acordarse antes del ajuste del modelo y preservar una fase de aceptación ciega.
56. Modo sombra
En modo sombra, el sistema genera alertas sin dirigir operaciones. Los analistas comparan las salidas con la práctica actual y con los resultados posteriores.
El modo sombra permite una calibración segura de umbrales y la medición de la carga de trabajo. Debe tener un final fijo y una puerta de decisión.
57. Pruebas controladas
Las descargas conocidas o los eventos de hidrantes pueden probar la detección y la localización en condiciones controladas. Permiten la repetibilidad, pero pueden no representar fugas naturales.
El programa debe etiquetar los eventos controlados y naturales por separado y evitar agruparlos sin revelar que se han agrupado.
58. Criterios de aceptación
La aceptación debe cubrir la precisión en campo, el recall, la ubicación, la latencia, la disponibilidad de datos, la duplicación de alertas, la integración de flujos de trabajo, la ciberseguridad, la generación de informes y los aspectos económicos. Los criterios deben medirse a nivel de incidente.
El contrato debe indicar el periodo de muestra, el tratamiento de la confianza y la medida correctiva cuando la evidencia sea insuficiente.
59. Puerta de escalado
El escalado debe requerir una operación estable, una carga de trabajo gestionable, aspectos económicos positivos en el escenario adverso, un riesgo cibernético aceptable, una integración mantenible y una capacidad financiada de respuesta en campo.
Un piloto técnico exitoso aún puede no superar la puerta operativa o comercial.
60. Deriva del modelo
La demanda, los controles, los sensores, los activos y el clima cambian con el tiempo. La deriva puede alterar las distribuciones de puntuaciones y las tasas de error.
La monitorización debería comparar datos, alertas y resultados por distrito y temporada. Los cambios de umbrales o de modelos deberían seguir un proceso de aprobación controlado.
61. Recalibración y reentrenamiento
La recalibración puede ajustar umbrales o parámetros hidráulicos; el reentrenamiento modifica el comportamiento aprendido. La empresa de servicios públicos debería definir los disparadores, los requisitos de datos, las pruebas y la reversión.
Las nuevas versiones deberían someterse a pruebas en la sombra antes de producción. El rendimiento histórico debería seguir siendo reproducible.
62. Ciberseguridad
Los sensores, las pasarelas, las plataformas y las integraciones amplían la superficie de ataque. Los controles deberían cubrir identidad, cifrado, aplicación de parches, segmentación, registro, respuesta a incidentes y acceso de proveedores.
Una alerta automatizada no debería controlar válvulas o bombas sin un diseño separado de seguridad y autorización.
63. Resiliencia
El sistema debería degradarse de forma segura cuando fallen las comunicaciones, los sensores o los servicios en la nube. Los operadores necesitan métodos de respaldo y visibilidad de las zonas ciegas.
Los informes de nivel de servicio deberían distinguir el tiempo de actividad de la plataforma de la disponibilidad de datos útiles.
64. Derechos sobre los datos
Los contratos deberían definir la titularidad, el uso permitido, la retención, la exportación, los derechos de entrenamiento de modelos y la eliminación. La empresa de servicios públicos debería conservar el historial de su red, de los eventos y de los resultados.
La salida debería incluir datos utilizables y documentación en formatos no propietarios cuando se requiera.
65. Asignación de riesgos
Tabla 3. Matriz ilustrativa de riesgos de despliegue
| Riesgo | Responsable preferente | Tratamiento contractual | Respuesta de la dirección |
|---|---|---|---|
| Fallo de sensores y telemetría | Parte que controla el equipo o el servicio | Condiciones de disponibilidad, reparación y calidad de los datos | Redundancia y notificación de zonas ciegas |
| Etiquetas históricas incompletas | Empresa de servicios públicos para registros divulgados; proveedor para el método aceptado | Salvedad de datos y plan de validación de campo | Aceptación conservadora y fase de prueba en paralelo |
| Rendimiento del modelo | Proveedor dentro del entorno acordado | Métricas y remedio a nivel de incidente | Monitorización, reversión y nueva prueba |
| Cambio de red u operativo | Utilidad con cooperación de proveedores | Aviso de cambio y proceso de recalibración | Configuración y presupuesto versionados |
| Acción falsa en campo | Compartido según la evidencia y el flujo de trabajo | Protocolo de confirmación y límites de responsabilidad | Punto de aprobación y revisión de resultados |
| Incidente cibernético | Parte que controla la capa afectada | Obligaciones de seguridad y respuesta | Segmentación, registro y recuperación |
66. Gobernanza
Un responsable final debe conectar las áreas de operaciones, datos, TI, ciberseguridad, finanzas, compras y equipos de campo. El comité de dirección debe revisar los resultados y los aspectos económicos, no solo la actividad de los proveedores.
Los umbrales significativos, las versiones de los modelos y los cambios de alcance requieren derechos de aprobación definidos.
67. Cuadro de mando mensual
El panel debe mostrar cobertura, calidad de datos, alertas, incidentes deduplicados, precisión y exhaustividad cuando sean observables, error de ubicación, antigüedad en la cola, acciones en campo, fugas confirmadas, tiempo de reparación, estimación de agua, costo y beneficio.
La confianza y la falta de verdad de referencia deben permanecer visibles. Las alertas no verificadas no deben presentarse como fugas encontradas.
68. Señales de alerta
Las señales de alerta incluyen precisión sin prevalencia, validación solo con datos sintéticos, ausencia de prueba de campo a ciegas, notificación a nivel de alerta en lugar de a nivel de incidente, costo de investigaciones falsas no contabilizado, cobertura débil de sensores, dependencia de datos propietarios, reentrenamiento no controlado, falta de capacidad de campo y beneficios declarados sin resultados de reparación.
Cada una exige evidencia, rediseño, protección de precio o una decisión de no escalar.
69. Primeros 180 días
Los primeros seis meses deben definir casos de uso, establecer la línea base de la práctica actual, mapear datos y sensores, seleccionar áreas piloto, establecer la verdad de referencia y el flujo de trabajo, adquirir la plataforma, ejecutar el modo sombra y acordar los criterios de aceptación.
El comité de inversiones debe ver evidencia real de cola, campo y costos antes de aprobar la expansión.
70. Paquete para el comité de inversiones
El paquete debe incluir las clases de fugas objetivo, la línea base, el mapa de sensores y datos, la evidencia del modelo, el protocolo piloto, la economía de la matriz de confusión, el diseño operativo, la revisión de ciberseguridad, los términos de adquisición, los escenarios de costo-beneficio, la matriz de riesgos y las puertas de escalado.
Las estimaciones de la dirección deben permanecer identificadas. Las afirmaciones de los proveedores deben conservar la fuente y las condiciones de prueba.
71. Regla de decisión
Avanzar cuando el sistema produzca incidentes creíbles en campo, oportunos y priorizados económicamente; se integre con un flujo de trabajo financiado de confirmación y reparación; preserve los datos y la seguridad; y entregue un valor positivo en el escenario desfavorable en relación con la práctica actual.
El escalado debe seguir a resultados verificados. Una puntuación alta del modelo por sí sola no constituye un caso de inversión.
72. Calcular la aritmética de la tasa base antes de la adquisición
El equipo de preparación debe calcular las alertas esperadas bajo diversos supuestos de prevalencia de eventos y de error. Para cada día-red u otra unidad de evaluación, el modelo debe estimar eventos reales, eventos detectados, eventos omitidos, alertas falsas e investigaciones totales. Esto revela situaciones en las que una tasa de falsos positivos aparentemente pequeña abruma a una población escasa de eventos reales.
La aritmética debe usar la misma unidad que el flujo de trabajo operativo. Una tasa de clasificación de registros de sensores no puede traducirse directamente a visitas de brigadas sin deduplicación y agrupación de incidentes. El modelo también debe probar distintos distritos, ya que la prevalencia de eventos y la observabilidad hidráulica pueden diferir de forma sustancial.
73. Calibrar la probabilidad y la confianza
Una puntuación del modelo no es automáticamente una probabilidad calibrada. Las pruebas de calibración deben comparar la confianza prevista con la frecuencia observada de eventos en distintas bandas de puntuación y condiciones operativas. Una calibración deficiente puede distorsionar la clasificación, la selección de umbrales y las estimaciones del caso de negocio, incluso cuando el orden de clasificación sigue siendo útil.
La plataforma debe distinguir entre la confianza del modelo, la confianza en la calidad de los datos y la confianza en la localización. Una puntuación alta del modelo basada en sensores incompletos o defectuosos no debe parecer equivalente a un incidente bien respaldado. La calibración debe volver a comprobarse tras cambios en el modelo, los sensores o la red.
74. Segmentar la red según criterios económicos
Las conducciones principales críticas, la distribución urbana densa, las redes rurales y las líneas de acometida de clientes tienen consecuencias de eventos, observabilidad y costes de respuesta diferentes. La empresa de servicios públicos debe segmentar el despliegue y seleccionar en consecuencia la sensorización, los umbrales y los flujos de trabajo. Un único promedio empresarial puede ocultar áreas con economía negativa o puntos ciegos inaceptables.
El modelo de segmentación debe considerar el material de la tubería, el diámetro, el historial de fallos, la presión, las consecuencias, el acceso, el coste de reparación, la densidad de clientes y la práctica actual de detección. El despliegue a escala debe comenzar donde la combinación de señal, consecuencia y capacidad de respuesta cree el caso basado en evidencia más sólido.
75. Diseñar el proceso de determinación de la verdad
Cada alerta debe avanzar hacia un estado final de verdad: fuga confirmada, ausencia de fuga confirmada, sin resolver, inaccesible, duplicada, fallo de sensor o evento operativo legítimo. El estado debe registrar la evidencia y el responsable de la adjudicación. Los casos sin resolver deben permanecer en los informes de rendimiento para que el sistema no parezca más preciso al excluir resultados difíciles.
El proceso de determinación de la verdad también debe identificar las fugas descubiertas fuera del sistema de alertas. Esos eventos son necesarios para estimar la exhaustividad (recall). Un sistema no puede afirmar que detecta la mayoría de las fugas cuando el denominador incluye solo sus propias alertas.
76. Medir la capacidad de las brigadas
El valor de las alertas depende de la capacidad disponible de analistas, inspección y reparación. El modelo operativo debe pronosticar las horas por etapa de alerta, cualificación y geografía. Debe probar el crecimiento de la cola tras tormentas, cambios estacionales, despliegues de sensores o ajustes de umbrales.
Los objetivos de nivel de servicio deben priorizar las consecuencias y la antigüedad. Cuando la capacidad sea limitada, el sistema debe mostrar qué incidentes permanecen sin atender y la exposición al agua o al riesgo asociada al retraso. Una decisión de despliegue a escala debe financiar la capacidad de campo necesaria para materializar el beneficio esperado.
77. Vincular las alertas con la renovación de activos
Las anomalías repetidas, los grupos de fugas y las confirmaciones difíciles pueden revelar activos que requieren renovación en lugar de reparaciones reiteradas. El programa debe incorporar evidencia verificada a la planificación de capital basada en riesgos. También debe separar el beneficio del sistema de alertas del beneficio posterior de la renovación para evitar la doble contabilización.
El equipo de activos debe recibir datos de ubicación, defecto, tubería, reparación, recurrencia e incertidumbre en un formato estable. Las decisiones de planificación de capital deben combinar esta evidencia con la condición, la consecuencia y el coste del ciclo de vida. AI respalda, por tanto, la priorización de la renovación cuando el registro de resultados sigue siendo fiable.
78. Cuantificar la deuda de datos e integración
La telemetría heredada, los identificadores inconsistentes, las marcas temporales ausentes, los activos duplicados y las órdenes de trabajo fragmentadas pueden requerir una corrección significativa. Estos costes deben estimarse antes de seleccionar al proveedor y asignarse entre la empresa de servicios públicos y el proveedor. Un piloto que utilice datos curados manualmente puede subestimar el coste operativo a plena escala.
El diseño de integración debe definir identificadores maestros para sensor, activo, distrito, cliente y orden de trabajo. Los controles de conciliación deben rastrear los registros no conciliados. La corrección de datos puede generar valor independiente, mientras que el caso de inversión de AI debe seguir incluyendo el gasto necesario para sostenerla.
79. Establecer disciplina de operaciones de modelos
La operación en producción necesita control de versiones, definiciones de características, aprobación de despliegues, monitorización del rendimiento, registro de incidentes, reversión, reentrenamiento y retirada. La empresa de servicios públicos debe saber qué modelo generó cada alerta y qué datos y umbrales se aplicaron.
El proveedor debe documentar los cambios planificados y de emergencia. Las actualizaciones materiales deben superar pruebas de regresión y en sombra utilizando la evidencia conservada. Las operaciones de modelos deben integrarse con la gestión de servicios de TI en general, de modo que los fallos de datos y aplicaciones tengan un responsable y una resolución, en lugar de quedar como problemas analíticos invisibles.
80. Probar la concentración de proveedores y la salida
Una plataforma propietaria puede combinar dispositivos, comunicaciones, datos, modelo y flujo de trabajo. Esto puede simplificar la rendición de cuentas mientras aumenta el riesgo de cambio de proveedor. El contrato debe definir la exportación de datos, la documentación de interfaces, el acceso al hardware, el apoyo a la transición y la continuidad de la operación durante la salida.
El caso de negocio debe incluir el coste de sustitución y transición. Debe identificar qué componentes pueden licitarse de forma independiente y cuáles crean dependencia del proveedor. El valor a largo plazo depende de preservar la evidencia y la capacidad operativa de la empresa de servicios públicos incluso cuando cambie el proveedor.
81. Realizar un ejercicio operativo de equipo rojo
Antes de la aceptación, un equipo independiente debe someter al sistema a pruebas con caída de sensores, deriva de reloj, picos de demanda legítimos, operaciones de válvulas, cambios de bombas, retraso de telemetría, registros duplicados, ciberincidentes y fugas en zonas con escasa observación. El ejercicio debe probar alertas, explicaciones, flujo de trabajo, escalado y recuperación.
El propósito es identificar modos de fallo y dependencias ocultas. Los resultados deben dar lugar a cambios en la configuración, el contrato, la formación y los planes de contingencia. Los fallos críticos no resueltos deben impedir la ampliación hasta que la empresa de servicios públicos acepte y financie el riesgo residual.
82. Auditar el beneficio declarado
Los beneficios deben conciliarse desde la alerta hasta el incidente, la confirmación, la reparación, la señal posterior a la reparación, el caudal estimado, la reducción del tiempo de funcionamiento y el valor financiero. Los responsables de finanzas y de operaciones deben aprobar el método. El muestreo puede verificar la exactitud de las órdenes de trabajo y de los costes.
La auditoría debe distinguir los resultados atribuidos a proveedores, los atribuidos a la empresa de servicios públicos y los logrados conjuntamente. Los beneficios que no puedan vincularse a una decisión operativa modificada no deben asignarse automáticamente al modelo. La pista de auditoría respalda la revisión de inversiones, la presentación de informes regulatorios y el pago por desempeño.
83. Elaborar un caso financiero a la baja
El caso a la baja debe combinar una menor prevalencia de eventos, una precisión más débil, fugas más pequeñas, una respuesta sobre el terreno más lenta, un mayor coste de conectividad, una sustitución más temprana de sensores y una integración tardía. También debe someter a prueba el coste de un ciberevento material o de un evento de transición sin presentar ese escenario como algo cierto.
La dirección debe identificar qué variables impulsan el valor y cuáles pueden controlarse. La inversión puede seguir justificándose mediante la reducción de riesgos críticos incluso cuando el retorno directo de efectivo sea débil; esa justificación debe ser explícita y aprobarse por separado.
84. Crear puertas de realización de beneficios
El programa debe tener puertas para la preparación técnica, la adopción operativa, el resultado verificado, el valor económico y la escala. Cada puerta debe indicar la evidencia, el responsable y la decisión. Superar una puerta anterior no debe predeterminar la siguiente.
Las revisiones de realización de beneficios deben comparar el desempeño actual con la línea base aprobada y el contrafactual. Deben identificar el valor perdido por demoras en la cola, restricciones sobre el terreno o una reparación incompleta. Las acciones correctivas deben tener fechas y responsables. La financiación para un despliegue posterior debe depender de la capacidad demostrada y no de la inercia de los costes hundidos.
85. Preservar la responsabilidad humana
El modelo puede priorizar la evidencia; el personal autorizado de la empresa de servicios públicos sigue siendo responsable de las decisiones operativas y de servicio público. Los roles deben estar claros para el descarte de alertas, el despacho sobre el terreno, el aislamiento, la excavación, la comunicación con el cliente y la reparación. Las decisiones críticas deben conservar una pista de auditoría.
El personal debe entender los límites del modelo y los modos de fallo comunes. La formación debe utilizar casos locales reales y poner a prueba la calidad de las decisiones. La dependencia excesiva puede hacer que se pase por alto información contextual; la desestimación habitual puede anular el valor del modelo. La gobernanza debe respaldar un cuestionamiento disciplinado en ambas direcciones.
86. Conclusión
AI puede mejorar la detección de fugas cuando los sensores, los datos, los modelos y las operaciones sobre el terreno forman un único sistema controlado. La economía de los falsos positivos aporta disciplina a las decisiones sobre umbrales, sensores, flujos de trabajo y adquisiciones. También pone de manifiesto el coste operativo que queda oculto tras la exactitud destacada.
El programa más sólido mide la precisión, la exhaustividad, la localización, la oportunidad y el beneficio neto a nivel de incidente en la red objetivo. Aprende de cada resultado sobre el terreno, monitoriza la deriva y se amplía solo cuando las reparaciones verificadas respaldan el caso.
Referencias
- Kwon, D. et al. Exploración de un modelo de detección de fugas mediante aprendizaje profundo en múltiples sistemas inteligentes de distribución de agua: tamaños de fuga detectables con medidores AMI. Water Research X, 2025. https://doi.org/10.1016/j.wroa.2025.100332
- Ranganathan, S., Vinothkumar, N. y Muthuramalingam, E. Evaluación comparativa de diversas arquitecturas de aprendizaje para la detección y localización de fugas en sistemas de distribución de agua. Journal of Water Process Engineering, 2026. https://doi.org/10.1016/j.jwpe.2026.110114
- Goulet, J.-A., Coutu, S. y Smith, I.F.C. Diagnóstico por falsificación de modelos y ubicación de sensores para la detección de fugas en redes de tuberías presurizadas. Advanced Engineering Informatics, 2013. https://doi.org/10.1016/j.aei.2013.01.001
- Aprendizaje por transferencia explicable de simulación a campo para la detección de fugas basada en transitorios en redes de distribución de agua. Water Research, 2026. https://doi.org/10.1016/j.watres.2026.126464
- Agencia de Protección Ambiental de los Estados Unidos. Monitoreo de la calidad del agua en sistemas de distribución: metodología y resultados de evaluación de tecnologías de sensores. https://www.epa.gov/sites/production/files/2015-06/documents/distribution_system_water_quality_monitoring_sensor_technology_evaluation_methodology_results.pdf
- Ofwat. Informe anual del Fondo de Innovación 2025. https://www.ofwat.gov.uk/wp-content/uploads/2025/07/Ofwat-Innovation-Fund-Annual-report-2025-v5.pdf
- Ofwat. Soluciones de energía verde y prevención de fugas mediante CCTV entre las innovaciones hídricas ganadoras. https://www.ofwat.gov.uk/green-energy-solutions-and-cctv-leak-prevention-among-winning-water-innovations/
- Estandarización y evaluación comparativa de conjuntos de datos y protocolos de evaluación para la detección de fugas de agua basada en aprendizaje automático: una revisión sistemática. Water, 2026. https://doi.org/10.3390/w18182267
- SIAM: un marco de código abierto para identificar anomalías en redes de distribución de agua. Software Impacts, 2026. https://doi.org/10.1016/j.simpa.2026.100842
- Detección de fugas de agua mediante clasificación autosupervisada de series temporales. Information Sciences, 2021. https://doi.org/10.1016/j.ins.2021.06.015
- Detección de fugas en tuberías de agua basada en aprendizaje automático y redes de sensores inalámbricos. Sensors, 2019. https://doi.org/10.3390/s19235086
- Detección de fugas de agua en conducciones principales de distribución suburbanas con sensores vibroacústicos Lift and Shift. Sensors, 2022. https://doi.org/10.3390/s22166066
- Detección y localización de fugas mediante modelos: resultados de campo. Procedia Engineering, 2014. https://doi.org/10.1016/j.proeng.2014.02.128
- Asociación Internacional del Agua. Contratos basados en el desempeño para la gestión de agua no facturada. https://www.iwa-network.org/our-work/performance-based-contracts-for-non-revenue-water-market-development
- Banco Mundial. Nota de orientación sobre contratos basados en el desempeño para la reducción de pérdidas de agua. 2025. https://documents1.worldbank.org/curated/en/099157411052511694/pdf/IDU-ddae29b5-2722-4a36-9992-5ac7789d6bb1.pdf
- Centro de Recursos de Asociaciones Público-Privadas del Banco Mundial. Herramientas de contratación basadas en el desempeño para la reducción de agua no facturada. https://ppp.worldbank.org/water-and-sanitation/performance-based-contracting-tools-non-revenue-water-reduction-tools-resources
Sobre el autor
Chennakeshav (CK) es un ejecutivo de finanzas corporativas y banca de inversión con más de 25 años de experiencia global en originación, estructuración y ejecución de operaciones en M&A, capital de crecimiento y estrategia corporativa. Ha liderado mandatos de creación de valor para fundadores, empresas y fondos —tendiendo un puente entre la visión del consejo de administración y la ejecución práctica y el cierre—.
Su trayectoria abarca Morgan Stanley, HSBC, Lloyds Banking Group, EWEC, empresas del portafolio de ADQ y Emirates Growth Fund, en sectores como TMT, inmobiliario, fintech, deeptech, cleantech, infraestructura y energía. Ha colaborado con directivos de primer nivel, fondos de capital privado y de capital riesgo, fondos soberanos y family offices para financiar captaciones de fondos complejas y empresas en expansión, y ha liderado iniciativas de diligencia debida de M&A, integración posfusión y transformación empresarial para crear valor.
En Matchpoint Partners es socio director y lidera la práctica de finanzas corporativas, M&A y captación de capital de la firma. Tiene un MBA por London Business School, un título de ingeniería por la VTU y un Máster en Derecho (LLM, en curso) por UCL London.
Como mentor activo de startups, CK ejerce de mentor en Techstars, DIFC FinTech Hive, Startup Grind, Founder Institute e IN5, es Entrepreneur Mentor in Residence (EMiR) en London Business School y actúa como jurado en la Copa Mundial del Emprendimiento.
LinkedIn: https://www.linkedin.com/in/ckadya/
Perfil: https://www.matchpoint-partners.com/team/ck-adya.html
