Al construir TriggerProof, una capa de arbitraje para disparadores paramétricos de inundación, descubrí que el verdadero fallo es el falso positivo, y un verificador físico determinista lo detecta.
Parametric InsuranceRemote SensingFlood Risk

Un satélite dijo que un depósito estaba bajo el agua. Era la sombra de una nube, y el disparador paramétrico estuvo a un clic de pagar 1,2 M$ automáticamente.

Ashutosh SinghalAshutosh Singhal12 de julio de 202612 min

Un satélite observó Mesa Junction Depot, vio una mancha oscura donde debería haber suelo seco y marcó la ubicación como inundada. Una póliza de inundación paramétrica leyó ese disparador como un hecho y armó un pago de 1,2 M$ para que se emitiera automáticamente, sin perito, sin llamada telefónica, sin segunda mirada. La mancha oscura era la sombra de una nube. Seis días después había desaparecido de las imágenes, y el suelo bajo ella nunca había estado mojado.

Construí ese caso exacto a propósito, porque es el que un único fotograma satelital nunca puede captar. Soy Ashutosh y dirijo Veriprajna. TriggerProof es una demo que construí para demostrar una afirmación concreta: el momento peligroso en los seguros paramétricos contra inundaciones no es la detección, sino la decisión de pagar. Cada ubicación, tesela, escala fluvial e informe de campo en ella son sustitutos sintéticos y fieles a la física que redacté para poder escenificar los modos de fallo con claridad. Puedes abrirla y probarlo todo tú mismo en veriprajna.com/es/demos/inteligencia-satelital-de-inundaciones-adjudique-el-disparador-parametrico-antes-del-pago. Mesa Junction Depot es por donde quiero empezar, porque es el caso que me enseñó qué estaba construyendo en realidad.

Cuatro cosas distintas oscurecen los mismos píxeles

No comprendí el verdadero problema hasta que me senté a generar las imágenes sintéticas y tuve que hacer que cuatro cosas parecieran idénticas en un solo fotograma. El seguro paramétrico contra inundaciones sustituyó al perito de siniestros por un disparador: un satélite dice que una ubicación está bajo el agua y el dinero se mueve. El problema es que, en una sola imagen óptica o en una pasada de radar, el agua de inundación real, la sombra de una nube, una sombra de radar o de terreno y un embalse permanente se oscurecen del mismo modo. Un único fotograma no puede separarlos, porque la información que los separa no reside en un solo fotograma.

Eso redefinió toda la demo para mí. El error catastrófico en este negocio no es la inundación que el disparador pasa por alto. Es la inundación que el disparador inventa, un pago seguro de 2 M$ por una sombra, sin un rastro de evidencia para defender la decisión cuando una reaseguradora pregunte por ella un año después. TriggerProof no detecta inundaciones ni produce datos satelitales. Toma un disparador que ya se ha activado y arbitra si realmente debe pagar.

Un fotograma decía inundación; el siguiente decía que el suelo nunca estuvo mojado

Aún recuerdo recorrer la tira de fotogramas de Mesa Junction la primera vez que se renderizó correctamente. La interfaz te permite abrir una ubicación marcada y recorrer los fotogramas de adquisición uno a uno, el óptico arriba y el de radar abajo. En el fotograma del disparador, la mancha oscura está justo ahí, verde señal de agua, exactamente lo que activó la alarma. Avanzas a la siguiente adquisición y ha desaparecido. Vuelves atrás y la retrodispersión de radar bajo esa misma mancha se lee normal en cada fotograma, porque el radar vio suelo seco directamente a través de la nube todo el tiempo.

La tira temporal de AOI-B para Mesa Junction Depot: la mancha oscura óptica aparece únicamente en el fotograma disparador t+0 y está ausente en t-6d y t+6d, mientras que la fila SAR se mantiene uniforme en los tres fotogramas, clasificada como sombra de nube con una confianza de 1,00.
Mesa Junction Depot, el caso de 1,2 M$. La mancha oscura óptica aparece únicamente en el fotograma disparador (persistencia temporal del 33%) y la retrodispersión de radar se mantuvo normal en todo momento. La regla R1 falla, la regla R2 falla y el veredicto es sombra de nube, no agua.
La sombra se movió; el agua se habría quedado. Eso solo se ve a través del tiempo y a través de los sensores, nunca en el único fotograma que activó el disparador.

La física no es sutil una vez que colocas los fotogramas uno al lado del otro. La sombra de una nube es transitoria y viaja a la velocidad de la nube, por lo que es oscura en una adquisición y desaparece en la siguiente. El agua de inundación real persiste entre adquisiciones y se lee oscura en óptico y baja en radar al mismo tiempo. Dos reglas codifican exactamente eso: persistencia temporal y concordancia radar-óptico. En Mesa Junction ambas devuelven FAIL, y el clasificador determina sombra de nube con una confianza de 1,00. Los 1,2 M$ nunca debieron haberse puesto en cola.

Las cinco reglas deciden, no el modelo de lenguaje

Al principio intenté que el modelo de lenguaje tomara esta decisión, y me alegro de haberlo hecho porque falló de la manera más instructiva posible. Puse a un agente a leer las mismas pruebas y le pregunté, en efecto, si la ubicación estaba realmente inundada. En un caso ambiguo me escribió un párrafo fluido y seguro de sí mismo argumentando a favor de una inundación, y estaba equivocado, y nada en su tono advertía de que lo estuviera. Aquella tarde resolvió una decisión de diseño que no he vuelto a reabrir desde entonces.

Así que la decisión reside en Python puro, en cinco discriminadores inspeccionables, sin ningún modelo en ninguna parte del flujo que mueve dinero. La persistencia temporal (R1) separa una inundación de la sombra transitoria de una nube. La concordancia radar-óptico (R2) separa una inundación tanto de la sombra de una nube como de una sombra de radar. La pendiente DEM (R3) rechaza el agua que tendría que acumularse en terrenos escarpados. Una máscara de agua permanente (R4) excluye los embalses conocidos. El vínculo hidrológico (R5) comprueba que la zona húmeda realmente se conecte con la red de drenaje. El verificador decide; el modelo de lenguaje solo asesora. El agente asesor está construido sobre Pydantic AI, permite intercambiar modelos, con valor por defecto en claude-opus-4-8, y coteja el veredicto físico contra señales terrestres independientes y devuelve corrobora, contradice o no concluyente. Puede ser desestimado, y cuando retiro la clave API la demo se ejecuta completamente fuera de línea con un respaldo determinista, porque la parte a la que confío un pago no puede ser la parte que habla en párrafos seguros de sí mismos.

Cuando la propia física no está segura, el sistema escala en lugar de adivinar

Me importa más el caso en el que el sistema dice «no lo sé» que cualquiera de las detecciones limpias. Canal Street Hub es ese caso. Las firmas óptica y de radar son dudosas, la señal de inundación persiste en dos de tres fotogramas y la escala fluvial independiente nunca superó el nivel de desbordamiento. Las pruebas entran en conflicto de forma genuina. La confianza se sitúa en 0,151, muy por debajo del umbral de automatización de 0,65 que ajusté en el conjunto etiquetado, y el agente terrestre contradice frontalmente la clasificación satelital.

El detalle de AOI-F Canal Street Hub: clasificada como inundación con una confianza de 0,15, una firma óptica y SAR en el límite, la escala fluvial por debajo del nivel de desbordamiento y un veredicto enrutado a un árbitro humano como ESCALATE en lugar de un pago automático.
Canal Street Hub, 0,8 M$ en juego. La señal está en el límite y la escala fluvial nunca superó el nivel de desbordamiento, por lo que las pruebas sobre el terreno entran en conflicto con el satélite. La confianza de 0,151 queda por debajo del umbral de 0,65, y el caso escala a un humano con todas las pruebas adjuntas en lugar de decidirse automáticamente.

La compuerta de políticas envía esos 0,8 M$ a un humano con todas las pruebas adjuntas, marcado como «requiere comprobación», en lugar de lanzar una moneda al aire y llamarlo automatización. Un disparador de inundaciones que escala el caso genuinamente ambiguo parece para algunos compradores un producto más débil. Yo lo veo al revés. Es la única versión que dejaría funcionar sin supervisión, porque la alternativa a escalar aquí es una conjetura rápida sobre dinero real, disfrazada de decisión.

La cifra de la cartera a la que sigo volviendo

Sigo consultando la cartera de ocho ubicaciones porque hace que lo que está en juego sea tangible como ningún caso aislado lo hace. Una tormenta atraviesa una cartera de ocho zonas. El disparador heredado de fotograma único se activa en seis de ellas y pone en cola 8,0 M$ en pagos automáticos. TriggerProof arbitra la cartera: dos inundaciones reales confirmadas y pagadas por 4,0 M$, tres falsos positivos suprimidos (una sombra de nube por 1,2 M$, una sombra de radar por 1,0 M$, un embalse permanente por 1,0 M$) con 3,2 M$ retenidos, y el único caso ambiguo escalado por 0,8 M$.

La cartera de TriggerProof arbitrada: el sistema heredado puso en cola 8,0 M$, confirmados para pagar 4,0 M$ en dos inundaciones reales, 4,0 M$ retenidos entre tres supresiones y una derivación a revisión, con una cobertura de pruebas del 100% y veredictos por fila de PAY, DENY y ESCALATE frente a la columna PAY heredada.
La cartera de ocho ubicaciones tras el arbitraje. De los 8,0 M$ que el disparador de fotograma único habría pagado automáticamente, 4,0 M$ se confirman en dos inundaciones reales y 4,0 M$ se detienen o retienen: 3,2 M$ de falsos positivos suprimidos y 0,8 M$ escalados para verificación. Cada fila lleva su propio expediente pericial.

La mitad de lo que el disparador heredado habría pagado, 4,0 M$ de 8,0 M$, se detiene o se retiene para verificación. Esa es la cifra, y quiero ser preciso sobre su alcance: esta es la cartera sintética de la demo, ocho casos que redacté para ser fieles a la física, no una cartera de siniestros reales. El mecanismo es real e inspeccionable. Los siniestros están escenificados para que puedas ver cómo funciona el mecanismo.

Cero decisiones inseguras y la advertencia a la que me niego a renunciar

Ejecuté una comparativa adecuada porque una cartera de ocho es una historia, no una prueba. El banco de pruebas evalúa 60 casos etiquetados que abarcan desde firmas claras hasta ruido cercano al umbral. El titular no es una puntuación de precisión, es un recuento de seguridad: cero decisiones automatizadas inseguras, frente a 48 de la línea base de fotograma único que paga cada caso marcado. El ochenta por ciento de los casos se resuelve automáticamente y el 20% incierto se escala. Entre los casos resueltos automáticamente, la supresión de falsos positivos es de 36 sobre 36 y la exhaustividad de inundaciones es de 12 sobre 12, y cada uno de los 12 casos genuinamente ambiguos se escala en lugar de decidirse automáticamente.

El panel de referencia de TriggerProof sobre 60 casos etiquetados: cero decisiones automáticas inseguras frente a 48 de la línea base de fotograma único, 80% de resolución automática, 100% de supresión de falsos positivos con 36 de 36 sombras denegadas y 100% de exhaustividad de inundaciones con 12 de 12.
La comparativa de 60 casos etiquetados. La cifra que importa es la del extremo izquierdo: cero decisiones automatizadas inseguras frente a 48 de la línea base de fotograma único, con un 80% resuelto automáticamente y el quinto incierto escalado para verificación.
El objetivo nunca fue una puntuación perfecta en mi propio conjunto de pruebas. El objetivo es que el sistema nunca toma una decisión automatizada insegura. Cuando no está seguro, escala.

La advertencia acompaña a cada una de esas cifras, y no permitiré que se descarte. Están medidas en un conjunto fijo y etiquetado de 60 casos sintéticos y físicamente fieles, no son una garantía de mundo abierto ni un resultado de campo. El siguiente paso honesto no es hacer una afirmación más grande, sino la validación frente a archivos reales como Sen1Floods11 y escenas en vivo de Sentinel, y eso es lo primero que ofrecería un encargo real, no algo que esta demo haya hecho. Decir eso claramente es lo que me permite respaldar el resto de las cifras.

Un pago que no puedes defender después es un pasivo, incluso cuando fue correcto

No me propuse convertir el rastro de evidencia en la pieza central, pero al final fue la parte que con mayor seguridad una aseguradora podría respaldar. Un pago correcto que no puedes reconstruir después sigue siendo un pasivo, porque «el satélite lo dijo» no es una defensa que acepte una reaseguradora o un auditor. Por tanto, cada decisión, tanto un pago como una supresión, emite un expediente pericial: el linaje de datos de cada fotograma, la evidencia por regla con el valor medido de cada discriminador, el registro de eliminación de falsos positivos, la referencia cruzada sobre el terreno independiente y un hash de procedencia SHA-256 de la decisión.

El expediente pericial del disparador de inundación para Mesa Junction Depot: un veredicto de DENY, la tabla de pruebas de cinco reglas mostrando R1, R2 y R5 como FAIL con sus lecturas medidas, un registro de eliminación de falsos positivos, la referencia cruzada contextual y una tabla de linaje de datos de Sentinel-1 y Sentinel-2.
El expediente detrás de la denegación de Mesa Junction. Cada regla muestra su valor medido y su resultado, el registro de eliminación de falsos positivos detalla por qué no fue una inundación y todo el registro lleva un hash SHA-256. Este es el artefacto que entregas a una reaseguradora, no una captura de pantalla de un panel.

Quiero ser prudente sobre lo que es y no es ese hash. Es un hash de contenido que hace que el registro sea a prueba de manipulaciones, de modo que cualquiera puede recalcularlo y comprobar que la decisión no fue alterada a posteriori. No es una firma digital PKI, y la recuperación satelital, la asignación de SAR, los flujos terrestres y la integración con la plataforma de siniestros están simulados en esta demo para que todo funcione en mi portátil. Lo que es real es la estructura del registro: para cada decisión de pago automatizada, exactamente qué física dijo qué, con qué confianza, cotejada con qué señal independiente.

El seguro paramétrico hizo un intercambio genuino, renunciando al perito de siniestros para lograr pagos instantáneos e indiscutibles. Lo que heredó fue un problema de física que no puede ver más allá en un solo fotograma, y el fallo al que te expone ese intercambio es un pago rápido y seguro de sí mismo sobre una sombra. La solución duradera reside fuera del modelo: reglas deterministas que separan los elementos visualmente similares a lo largo del tiempo y los sensores, una compuerta que escala el caso ambiguo a una persona y un registro que hace que cada decisión sea defendible. Un satélite más nítido no soluciona un problema de arbitraje, y este es un problema de arbitraje.

Y si prefieres verlo a leerme describirlo, aquí está todo funcionando de principio a fin.

Mesa Junction es el caso al que sigo volviendo. Solo la segunda adquisición supo la diferencia entre la sombra y la inundación, y el disparador se activó antes de que llegara. Puedes recorrer esa tira de fotogramas tú mismo y anular el pago que crees que debió haberse emitido en veriprajna.com/es/demos/inteligencia-satelital-de-inundaciones-adjudique-el-disparador-parametrico-antes-del-pago. La pregunta que plantearía a cualquiera que gestione una cartera automática de inundaciones es concisa y con respuesta: de los disparadores que pagaste automáticamente la temporada pasada, ¿cuántos podrías demostrar todavía que eran agua y no una sombra?

Investigación relacionada

También publicado en

Construya su IA con confianza.

Colabore con un equipo que cuenta con amplia experiencia en la creación de la próxima generación de IA empresarial. Permítanos ayudarle a diseñar, construir e implementar una estrategia de IA en la que pueda confiar.

Veriprajna consultora de Deep Tech está especializada en la creación de sistemas de IA críticos para la seguridad en los sectores de salud, finanzas y ámbitos regulatorios. Nuestras arquitecturas se validan conforme a protocolos establecidos, con documentación de cumplimiento integral.