Arquitectura
Por que es UN agente, no dos
La mayoria de plataformas separan "sistema de operacion" y "sistema de soporte"
en productos distintos. Eso crea silos: el sistema operativo no entiende fallas de hardware, y el de
soporte no entiende contexto de negocio. Ultrapark fue disenado al reves: un agente unico con
ambos cuerpos de conocimiento. Cuando ve un sintoma, decide si es un caso anomalo de usuario, una
regla operativa que aplicar, o una falla de equipo. Y actua diferente en cada caso.
Rol 1: Coordinacion operativa
Decide tarifas dinamicas por hora, ejecuta cierres de turno, balancea cobros entre PPAs cuando
uno se llena, aplica convenios, gestiona excepciones (vehiculos no autorizados, tickets perdidos,
devoluciones). Cruza eventos en tiempo real contra reglas configuradas y emite alertas operativas
al supervisor.
Rol 2: Soporte de equipos
Monitorea salud de cada consola, PPA, barrera, camara y sensor: estado de red, estado de
billetero, estado de pinpad, temperatura, uso de disco, eventos de error. Ante una falla
conocida, ejecuta la correccion automatica (reset de servicio, reinicio de pinpad, restart del
subprocess). Solo escala a humano cuando la correccion no funciona.
Que la inteligencia operativa y la inteligencia de soporte vivan en el mismo agente significa que
las decisiones son coherentes: si el billetero falla y no acepta efectivo, el agente coordinador
sabe que tiene que redirigir cobros a otro PPA o habilitar cobro electronico, ademas de intentar
reparar el billetero.
Lo que decide solo
Ejemplos de decisiones automaticas que no requieren operador
- Aplicar la tarifa correcta segun tipo de vehiculo, dia, hora y convenio activo.
- Redirigir cobros a otro PPA cuando uno tiene falla de billetero o esta llenando su buzon.
- Generar la factura electronica DIAN del cobro y emitir el comprobante al usuario.
- Aplicar descuentos de convenio cuando el usuario presenta la tarjeta o el QR autorizado.
- Ejecutar el cierre diario de turno (cuadre, deposito, conciliacion) en el horario configurado.
- Reiniciar el servicio que se trabo (Logic, kiosko, video, pinpad) cuando detecta sintoma conocido.
- Limpiar archivos huerfanos del disco cuando el uso pasa el umbral configurado.
- Sincronizar listas negras de placas y abrir/bloquear barreras cuando aparece una placa marcada.
- Detectar tailgating o pago no completado y aplicar la regla de fraude configurada.
- Generar reporte operativo diario y entregarlo por el canal acordado (email, Telegram, dashboard).
91% de los eventos de operacion rutinarios se cierran sin intervencion humana.
El 9% restante escala con todo el contexto del caso para que un operador decida en segundos, no en
minutos.
Caso real de operacion
Ejemplo: como el agente reacciona a un atasco de papel en la entrada
Este es un escenario que ocurre en parqueaderos varias veces por mes y que en operacion manual
detiene el ingreso hasta que alguien fisicamente atiende la consola. Asi reacciona el agente
coordinador cuando lo detecta:
-
Deteccion. El subsistema de tickets en la consola de entrada reporta atasco
de papel (sensor mecanico + reintento fallido). El agente local recibe la senal en milisegundos.
-
Diagnostico. El agente verifica que no es un sintoma transitorio reintentando
un par de veces. Confirma el atasco persistente.
-
Decision con dual rol. El agente sabe que (a) reparar el atasco requiere
intervencion fisica que tomara minutos, y (b) la entrada quedaria detenida en operacion manual.
Como tiene contexto operativo, propone una mitigacion alternativa: activar temporalmente el
ingreso por lectura de placa (LPR), manteniendo el cobro a la salida normal.
-
Escalacion controlada. El agente envia notificacion al encargado del sitio por
el canal acordado (Telegram, dashboard, SMS):
"Atasco de papel en consola E-01. Sugiero activar ingreso por placa temporalmente hasta
reparacion. Confirmar." Incluye foto del estado, log del subsistema, hora del primer
evento, y boton de aprobacion en el mismo mensaje.
-
Autorizacion humana. El encargado revisa el contexto en segundos y autoriza
desde el mensaje (un tap). El agente cambia inmediatamente el modo de la consola: en lugar de
emitir ticket, captura la placa y la registra como entrada.
-
Operacion continua sin perdida de ingreso. Los vehiculos siguen entrando, cada
uno con su placa registrada. En la salida, el sistema cobra normalmente correlacionando la placa
capturada en la entrada con el cobro.
-
Restauracion. Cuando el tecnico repara el atasco fisicamente, el agente
detecta que el subsistema vuelve a estado saludable, ofrece volver al modo de tickets normal y
el encargado confirma. Todo el episodio queda en el log de operacion con tiempo de degradacion,
vehiculos atendidos en modo alternativo, y conciliacion final.
Lo que esto demuestra: el agente no se limita a alertar "hay un atasco".
Combina su conocimiento operativo (existe modo de ingreso por placa) con su conocimiento de
soporte (este equipo tiene atasco), propone una accion concreta, y mantiene a un humano en el
loop para autorizar. Esa es la diferencia entre un sistema de alertas y un agente coordinador.
Otro ejemplo: disco lleno en un equipo critico
Tipico problema operativo: un PPA empieza a fallar intermitentemente porque su disco esta al
98% y el subsistema de logs no logra escribir. En operacion manual, esto deriva en una llamada
de soporte tecnico horas o dias despues. Asi reacciona el agente coordinador:
-
Deteccion temprana. El agente local monitorea uso de disco como metrica
continua. Cuando cruza el umbral critico (85% por defecto), evalua que hacer antes que la
falla afecte cobros.
-
Diagnostico de que ocupa el disco. Recorre los directorios conocidos
(capturas de camara antiguas, logs rotados, snapshots de video, archivos temporales) y arma
un inventario de candidatos a borrar, ordenado por edad y por riesgo de borrado.
-
Propuesta concreta. El agente NO borra autonomamente. Envia notificacion al
encargado: "PPA-03 al 98% de disco. Sugiero borrar 14 GB de capturas previas a 60 dias
y 3 GB de logs rotados a 30 dias. Eso libera 17 GB. Confirma?" Incluye el inventario
detallado y el riesgo de cada categoria.
-
Autorizacion granular. El encargado puede aprobar todo, parte (ej: solo logs,
no capturas) o rechazar. Un tap en el mensaje y el agente ejecuta exactamente lo aprobado.
-
Ejecucion controlada. El borrado se hace en lotes, verificando despues de
cada lote que el sistema sigue saludable. Si algo falla, el agente para y reporta.
-
Reporte. Al terminar, el agente confirma: "17 GB liberados, disco al
62%, sistema saludable". El evento queda en el log con todo lo que se borro y quien
autorizo.
Por que importa: en operacion manual, el atendido de un "disco lleno"
requiere que un tecnico haga ssh al equipo, vea que sobra, y decida que borrar. Lleva horas y
requiere personal con permisos. El agente coordinador convierte ese proceso en un mensaje aprobado en
segundos por el encargado del sitio, sin necesidad de un tecnico de TI.
Lo que escala
Cuando el agente pide ayuda al operador
El agente esta disenado para ser conservador con su autonomia. Las decisiones que escala incluyen:
- Reclamos de usuario con confianza baja sobre quien tiene la razon.
- Cobros con discrepancia entre cobrado y registrado que no se concilia automaticamente.
- Fraudes detectados con confianza media: el agente prepara la evidencia y deja la decision al
operador.
- Fallas de equipo que persisten despues de los intentos automaticos de correccion.
- Excepciones que no encajan en las reglas configuradas (nuevo tipo de convenio, vehiculo
atipico, evento sin precedente).
Cada escalacion llega con: contexto completo del evento, decisiones que el agente ya intento, datos
de equipos involucrados, y propuesta de accion. El operador acepta o ajusta. Esa decision realimenta
al agente para futuras situaciones similares.
Donde vive el agente
Local + cloud, sin punto unico de falla
Ultrapark no es un servicio centralizado en la nube que controla los equipos remotamente. Cada
equipo (consola, PPA, barrera) ejecuta el Agente AI interno localmente. Las decisiones criticas
(apertura de barrera, cobro, clasificacion vehicular, deteccion de fraude) ocurren on-device sin
depender de la conexion a internet.
La nube se usa para:
- Consolidar telemetria y reportes operativos.
- Distribuir listas negras de placas entre todos los sitios del cliente.
- Entregar modelos actualizados al borde via OTA.
- Conservar evidencia de eventos de fraude.
- Permitir acceso de supervisor desde cualquier ubicacion.
Si se pierde la conexion a internet, el agente local sigue operando normalmente. Cuando vuelve la
conexion, sincroniza. La operacion del parqueadero nunca depende de que la nube responda.