Logística y transporte por carretera · Plataforma de datos e inteligencia territorial
El Observatorio de Riesgo Vial es un producto propio pensado para la logística por carretera en Argentina, empezando por los corredores Rosario-Córdoba, Rosario-Bahía Blanca y los accesos al AMBA. Junta lo que publican por separado vialidades, servicios meteorológicos e hidrológicos, pasos fronterizos y prensa local, y lo convierte en un nivel de riesgo por tramo con la evidencia que lo sostiene.
Resumen ejecutivo
Las rutas argentinas se cortan por crecidas, nevadas, incendios u obras, y la información para preverlo existe, pero repartida entre decenas de organismos con formatos distintos. El Observatorio ingiere 44 fuentes públicas, guarda cada documento original sin modificarlo, extrae observaciones con reglas y, solo donde el texto no tiene estructura, con Claude, y las consolida en eventos. Un motor de reglas versionado combina unas 18 señales y publica, para cada uno de los 20.345 tramos de 10 km y cinco ventanas de 6 horas a 7 días, un nivel de riesgo con su evidencia. Funciona 24/7 en un servidor propio; las métricas de acierto todavía no son calculables.
El reto
La pregunta operativa es sencilla: si un camión puede salir por una ruta en las próximas 24 horas. La respuesta depende de datos que nadie cruza entre sí.
Vialidad Nacional y las vialidades provinciales publican partes en PDF, imágenes u hojas de cálculo, casi siempre sin coordenadas ni kilómetro y cada una con su propio vocabulario.
El servicio meteorológico y el instituto del agua avisan de lluvias, nevadas o crecidas, pero ninguno dice sobre qué ruta caen.
Los pasos fronterizos tienen varias fuentes que a veces se contradicen, y la prensa llega tarde y en texto libre, sin una ubicación estructurada.
Además, para afirmar que el sistema anticipa un corte hay que poder distinguir haberlo predicho de haber copiado un aviso que otro organismo ya había publicado.
La solución
Un pipeline en Python descarga cada fuente con su cadencia, su cuota y sus reintentos, y guarda el documento crudo sin tocarlo. Reglas deterministas y, solo donde no hay estructura, Claude Haiku y Sonnet extraen observaciones, que se deduplican en eventos con historial. PostGIS los cruza con una red vial fija de tramos de 10 km, el motor calcula las amenazas por ventana temporal y un panel en Next.js con MapLibre y Cesium lo muestra.
Funcionalidades
El mapa se abre eligiendo qué se mira, hechos reportados o predicciones del motor, con un interruptor siempre visible para no confundirlos. Muestra solo lo vigente, sin eventos vencidos ni revocados, y un panel de capas para combinar eventos, observaciones y predicciones.
Cada tramo de 10 km recibe un estado INFO, WATCH, WARNING o CRITICAL para ventanas de 6, 12, 24, 72 y 168 horas, con su probabilidad y la evidencia que la sostiene, enlazada a la versión exacta de cada evento usado.
Las observaciones de varias fuentes sobre un mismo hecho se agrupan en un evento con nivel de confianza y contradicciones resueltas por jerarquía de autoridad. La base guarda cada versión, de modo que se puede ver qué sabía el sistema en cada momento.
Cada conector muestra sus corridas, errores, cuota consumida y estado del cortacircuito. La pantalla de cobertura explica qué eventos no llegan a ningún tramo y por qué: sin ubicación, geometría lejana o ruta sin kilómetro oficial.
Las amenazas que suben de nivel se agrupan por ruta, necesitan corroboración y respetan un tope para no saturar. Cada alerta guarda su texto congelado y se exporta en CAP 1.2, validado con el esquema de OASIS. El envío por webhook aún no tiene destino.
Un globo Cesium con terreno, separado del mapa operativo, para estudiar el agua y capas geográficas propias importadas en KML. Lo que se sube queda guardado en el servidor y se puede borrar desde la misma pantalla, sin mezclarse con el mapa diario.
La pantalla de métricas separa eventos anticipados, confianza, acierto y coste de extracción. No publica un porcentaje cuando la muestra es mínima y respeta el bloqueo del backtest, que no da cifras de acierto mientras falte historia.
Los aparcaderos de camiones aparecen con su capacidad y su ocupación. El porcentaje nunca se muestra solo: va con la antigüedad de la lectura y, si el dato es viejo, se ve degradado y con el tiempo que lleva sin actualizarse.
Módulos
3 operativos, 3 parciales y 0 propuestos. Los propuestos son diseño de producto: todavía no hay software detrás.
44 conectores registrados con cuotas por proveedor, cortacircuito, cola de fallos y reproceso del documento crudo cuando se corrige un parser.
Reglas versionadas con unas 18 señales y cinco ventanas temporales. Dos señales más se calculan en sombra para compararlas antes de que decidan.
Mapa, amenazas, eventos, fuentes, cobertura, revisión, métricas, aparcaderos y explorador 3D.
Se calculan, se registran y se exportan en CAP 1.2, pero todavía no se entregan: el webhook no tiene destino configurado.
Lógica y comandos para cruzar un recorrido ordenado de tramos con las amenazas de una ventana y traducirlo a una decisión. Sin pantalla en el panel.
Escrito y ejecutable, con seis métricas separadas. Devuelve «no calculable» hasta reunir 42 días de historia y una afirmación firmada de que el catálogo de impactos está completo.
Cómo funciona
Cada fuente se descarga con su cadencia y su cuota. El documento original se guarda con un hash único y nunca se borra ni se modifica.
Reglas deterministas para los formatos estructurados. En prensa, un filtro de palabras deja pasar pocas notas, Claude Haiku las clasifica y Claude Sonnet extrae los datos en JSON validado; nunca se infieren kilómetros ni horarios.
Las observaciones se deduplican en eventos con confianza, contradicciones y un historial de versiones que mantiene la propia base.
Triggers de PostGIS cruzan cada evento con la red vial de tramos fijos de 10 km y guardan el resultado, sin recalcularlo en cada lectura.
El motor combina eventos, avisos, lluvia, nieve, niveles de río, focos de calor e historial del tramo, y publica un estado y una probabilidad por ventana.
Las subidas de nivel se agrupan por ruta, se exige corroboración y un tope, y la alerta queda registrada y exportable en CAP 1.2.
Los impactos registrados alimentan el backtest, que mide detección, predicción, acierto, anticipación, error espacial y calibración por separado.
Arquitectura
Otros flujos
Tecnologías
Ingeniería
El 15 de agosto se crea el monorepo con el esquema base, el núcleo de ingesta y las primeras fuentes: TomTom, Vialidad Nacional, la policía caminera de Córdoba, medios por RSS y clima de Open-Meteo. Ese mismo día llega la primera versión del motor de probabilidad por tramo con anticipación hidrológica.
Entre el 16 y el 19 de agosto se fija la red vial en tramos de 10 km, el cruce con eventos pasa a triggers persistidos, la contradicción entre fuentes usa una jerarquía de autoridad y se añaden caché de respuestas del modelo y guardas contra cruces geométricos sin índice.
Se rehacen el mapa, las amenazas, la cobertura y la revisión sobre un mismo sistema visual, se separa el explorador 3D con Cesium y se añade la exportación de alertas en CAP 1.2. También se valida el pronóstico de nivel de río contra lo observado.
Se ajusta con 30 años de series el tiempo que tarda una crecida entre estaciones, se carga un corpus histórico de 24.679 eventos de protección civil fuera del motor, se arma un conjunto de 280 cortes de referencia y se mide el estado completo del sistema.
El 26 de agosto el sistema se instala entero en un servidor Windows encendido 24/7, con el planificador y el panel como servicios, copia diaria de la base y un script de actualización que se niega a desplegar fuera de la rama principal.
Galería
Web pública en móvil.
Resultados
Cada cifra lleva su fuente y su fecha. Lo que no se ha medido va aparte, como potencial.
36.087
documentos públicos ingeridos y guardados sin modificar en los primeros 11 días
Informe de estado del repositorio (docs/salidas/observatorio-estado-2026-08-25, script medir_estado.py) · 2026-08-25
91,6 %
de las observaciones extraídas con reglas deterministas, sin modelo de lenguaje
Informe de estado del repositorio (30.856 de 33.693 observaciones, medir_estado.py) · 2026-08-25
20.345
tramos de 10 km con nivel de riesgo calculado para cinco ventanas temporales
Tabla red_vial (migración 024), recuento del informe de estado · 2026-08-25
Documentos crudos capturados cada día en los primeros once días de operación.
Fuente: Informe de estado del repositorio (docs/salidas/observatorio-estado-2026-08-25, medir_estado.py) · Datos a 2026-08-25 · El 15 de agosto es el día de arranque del sistema y el 25 de agosto se midió durante la propia jornada.
| Periodo | Documentos crudos |
|---|---|
| 15 ago | 514 |
| 16 ago | 3.677 |
| 17 ago | 3.331 |
| 18 ago | 4.224 |
| 19 ago | 4.296 |
| 20 ago | 3.134 |
| 21 ago | 3.886 |
| 22 ago | 3.249 |
| 23 ago | 2.870 |
| 24 ago | 4.194 |
| 25 ago | 2.712 |
Por tramo
probabilidad de corte con la evidencia y la versión de cada dato usado
Cronología
Arranque con las primeras fuentes y el motor de probabilidad por tramo.
Panel rehecho, explorador 3D con Cesium y exportación de alertas en CAP 1.2.
Primer parámetro ajustado con datos, la propagación de crecidas entre estaciones.
Instalación completa en un servidor Windows en servicio 24/7.
Operación continua con copia diaria de la base.
Evolución prevista
Trabajo planificado, todavía no disponible.
Configurar el destino del webhook, que ya tiene lista blanca de hosts y texto redactado, para que las alertas emitidas lleguen a una persona y no solo al panel.
Añadir la forma de firmar que el catálogo de impactos está completo para una ventana, hoy sin comando ni pantalla, y publicar las seis métricas con la historia ya acumulada.
Geolocalizar los partes que describen el lugar en prosa: de las vialidades provinciales conectadas, solo la que publica la traza del tramo llega hoy al motor.
Proyectos relacionados
Automoción y posventa · CRM/ERP a medida
CRM y ERP a medida para un taller de reparación de llantas: de la consulta al cobro, con QR por llanta, recogidas con conductor y facturación por sucursal.
Cosmética y comercio electrónico · CRM/ERP a medida
CRM y gestión de stock para una marca argentina que vende en Tiendanube y Mercado Libre: lotes con FEFO, ventas unificadas, cobros conciliados y anuncios.
Contratación pública · Plataforma de análisis con IA
Radar de licitaciones públicas que lee la Plataforma de Contratación, puntúa cada oportunidad, lee los pliegos con IA citando la página y prepara la oferta.
Hablemos
Cuéntanos el problema. Te respondemos con un planteamiento claro: qué haríamos, en cuánto tiempo y con qué entregables.