La explicación presentada ante el Concejo Metropolitano de Quito sobre la paralización del Metro durante más de ocho horas el pasado 20 de abril dejó varias interrogantes sueltas. El concejal Wilson Merino solicitó la comparecencia del Gerente de Operaciones y del Coordinador de Mantenimiento del Sistema de Comunicaciones de la EPMMQ, así como de un representante de la EOMMT. Sin embargo, el pleno no aprobó el pedido.
Ante la solicitud de otro de los concejales de que el gerente de la entidad, Juan Carlos Parra, comparezca este expuso que el incidente habría tenido origen en una falla de telecomunicaciones: específicamente, un switch que habría desconectado la estación Quitumbe del Puesto de Control Central (PCC). Sin embargo, el alcalde Pabel Muñoz, en reiteradas ocasiones hizo referencia a que la causa del colapso operativo habría sido por un “switch”.
«¿Un switch o un router podría obligar a parar toda una operación durante horas? ¿Por qué no se operó en modo degradado?», Concejal Wilson Merino, ante el Concejo Metropolitano de Quito.
La pregunta técnica del concejal apuntó directamente al protocolo de contingencia y a la redundancia que existe en los sistemas del Metro de Quito: el modo degradado, que permite operar la ruta sin detenerse en la estación con fallo o establecer rutas más cortas, debió haberse activado de forma inmediata, permitiendo cubrir al menos parte de la demanda de usuarios que utilizan la línea a diario.
Licencias vencidas: la pregunta que incomoda
El punto más crítico de la sesión surgió cuando Merino cuestionó directamente a Parra sobre la vigencia de las licencias de software que conforman el sistema de comunicaciones del Metro: Cisco, Motorola, Antivirus y Solarwinds. Según información preliminar manejada por el concejal, dichas licencias habrían vencido entre mayo y junio de 2025, lo que implicaría que la ciudad opera su sistema de transporte masivo con software sin licenciamiento vigente desde hace casi un año y sin soporte de los fabricantes desde hace más de un año. Merino fue contundente: operar durante este tiempo sin licencias de software vigentes y sin soporte en infraestructura crítica constituiría un acto de irresponsabilidad que expone al sistema a fallos técnicos y vulnerabilidades de ciberseguridad. La respuesta oficial sobre este punto aún no ha sido entregada con claridad.
Una empresa sin contrato resolvió la emergencia
Otro hallazgo de alto impacto: el propio Parra confirmó que el problema de telecomunicaciones no fue resuelto por el personal técnico del Metro, sino por una empresa externa. La misma, identificada como CloudTecPlus, no tendría contrato vigente con la EPMMQ. Las autoridades aún deben responder cuánto le costará a la ciudad ese servicio de emergencia y bajo qué figura legal fue contratado.
El sabotaje que nunca fue
El alcalde Muñoz aludió en un primer momento a la posibilidad de sabotaje. Sin embargo, el propio gerente descartó de manera indirecta cualquier intrusión informática o amenaza externa. La contradicción entre la declaración política del alcalde y la conclusión técnica del responsable operativo añade otra capa de opacidad al manejo de la crisis.
La red de respaldo que no respondió
En 2023, la EPMMQ contrató a través de una variación con el Consorcio Línea 1 Metro de Quito una red WiFi de respaldo, cuyo propósito explícito era funcionar como contingencia ante fallas del Sistema TETRA, permitiendo las comunicaciones de voz entre el PCC, estaciones y trenes. El 20 de abril, ante el colapso, esa red no entró en funcionamiento. El concejal Merino exige una explicación formal y técnica sobre por qué la red de contingencia, pagada con fondos públicos y diseñada exactamente para este escenario, no fue utilizada.
Merino subraya que la ciudadanía y la capital merecen respuestas claras sobre lo ocurrido: una falla que paralizó el sistema de transporte, la inversión más grande de Quito no podría quedar sin rendición de cuentas técnica y política. La EPMMQ tiene la obligación de entregar toda la información solicitada con transparencia y sin demora.
