S.I.G.O. y SUBE: datos oficiales para transporte urbano
La Resolución 42/2026 aprobó S.I.G.O. para transporte urbano y suburbano. Qué dato cargar, quién accede y cómo probar cambios antes de fiscalización.
Recorrido, parada y validador: si uno cambia sin registro, el dato oficial del transporte llega tarde. La Resolución 42/2026 aprobó S.I.G.O., un sistema que une información operativa con SUBE para planificar, monitorear y fiscalizar servicios urbanos y suburbanos. Para una empresa o municipio adherido, el trabajo técnico pasa por GTFS, perfiles de acceso y evidencia de cambios. Esta nota explica qué dato vive dónde y cómo probarlo.
Qué cambió para empresas y municipios adheridos
La Resolución 42/2026 fue publicada el 8 de julio de 2026 y aprobó el Sistema Integral de Gestión Operativa, S.I.G.O. La norma lo presenta como evolución funcional y tecnológica del sistema de modernización de colectivos creado en 2019. También dice que los datos producidos por S.I.G.O. junto con SUBE serán datos oficiales. El recorrido actualizado sin rastro rompe la fiscalización. La norma anterior, la Resolución 18/2019, ya había fijado usuarios, niveles de acceso y una lógica de adhesión para jurisdicciones. El anexo de usuarios incluía empresas, cámaras empresarias, organismos públicos, Nación Servicios y otros perfiles autorizados. La resolución nueva mantiene esa tensión práctica: el sistema vale cuando identifica quién carga el dato y qué alcance tiene. La escala técnica aparece fuera del expediente. Stack Overflow reunió más de 49.000 respuestas de 177 países en su encuesta 2025 y ubicó a PostgreSQL entre las bases con mayor deseo y admiración. Ese dato ayuda a leer la decisión operativa: una base relacional sigue siendo razonable cuando hay paradas, horarios, versiones, usuarios y auditoría.
Cómo funciona por dentro
El flujo empieza con una empresa, municipio o área técnica que informa recorridos, paradas, servicios, frecuencias, vehículos y cambios operativos. La Dirección de Gestión Técnica de Transporte compila datos y coordina con CNRT. La Dirección Nacional de Implementación y Seguimiento de SUBE administra información y perfiles. Nación Servicios es el operador tecnológico. S.I.G.O. recibe datos operativos y SUBE aporta validaciones de uso. GTFS ordena el intercambio técnico. La referencia oficial de GTFS Schedule define archivos para agencias, rutas, viajes, paradas y horarios. En una implementación local, PostgreSQL guarda registros estructurados: línea, ramal, parada, versión, estado, usuario, fecha y auditoría. El almacenamiento conserva anexos, mapas, actas y evidencias. Un tablero muestra cambios pendientes, altas aprobadas y servicios observados. La evidencia vive en la versión del recorrido y en el usuario que la tocó. Los permisos separan carga, revisión, aprobación y lectura. Operaciones puede proponer una modificación de parada. El responsable SUBE revisa compatibilidad. Fiscalización lee datos y cruza con reclamos o inspecciones. Gerencia consulta métricas por línea sin editar. El backup copia base, adjuntos y configuración; la prueba recupera una línea completa en un ambiente separado.
Qué se instala o configura primero
La pila mínima para una empresa mediana o municipio adherido usa PostgreSQL 17, una API para importar GTFS, almacenamiento S3 compatible para anexos, autenticación con Keycloak o Authentik y un tablero de control con Metabase o Grafana. Con dólar oficial vendedor a $ 1.515, una VM de USD 30 ronda $ 45.450 mensuales antes de impuestos, soporte, dominio y backup remoto. El primer entregable verificable toma de siete a diez días si los datos existen en planillas limpias. Debe incluir una línea, dos ramales, veinte paradas, dos perfiles de carga, un perfil de aprobación, una importación GTFS, un cambio rechazado, una exportación y una restauración probada. UMSA suele pedir esa restauración antes de abrir usuarios externos, porque muestra si el sistema puede volver después de un error de carga. El detalle concreto es chico: código de parada, vigencia, responsable, hash del archivo, estado anterior y estado nuevo. La libreta de mantenimiento del interno puede seguir en el taller, pero el cambio que afecta al dato oficial necesita fecha, usuario y aprobación.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en paradas duplicadas. La señal es una misma esquina con dos códigos activos. La prueba carga un archivo GTFS con duplicados y revisa si el sistema bloquea o deja una observación con responsable. El segundo riesgo aparece en perfiles demasiado amplios. La señal es un usuario de lectura que puede aprobar un cambio. La prueba crea cuatro perfiles, ejecuta una modificación de recorrido y revisa log, estado anterior y estado final. El tercer riesgo aparece cuando SUBE y S.I.G.O. miran fechas distintas. La señal es un servicio qué aparece activo en un sistema y vencido en otro. La prueba toma una línea, cambia vigencia, exporta GTFS y compara fecha de alta contra validaciones recibidas. Esta lectura es técnica; cada empresa o jurisdicción debe revisar su obligación normativa con asesoramiento propio. El dato oficial que llega tarde ya tiene dueño posible: la versión que nadie aprobó.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.