Hay una frase en la propuesta técnica de Abordo que a veces incomoda al cliente: "el sistema asume un operador adversarial". Suena dura, suena como una acusación, suena como decirle al gerente de operaciones que sus choferes son ladrones. Y vale la pena explicarla con cuidado, porque la frase no es sobre las personas, es sobre el diseño. Es el principio que separa los productos que funcionan en producción real de los que se ven bien en demo y fallan cuando aterrizan en el mundo.
Qué significa exactamente "adversarial"
En ingeniería de software, decir que un usuario es "adversarial" no significa que sea moralmente malo. Significa que tiene incentivos potenciales para sabotear, manipular o evadir el sistema, y por lo tanto el diseño debe asumir esos comportamientos como posibles y prepararse para ellos.
Esto es estándar en seguridad informática. Ningún ingeniero serio diseña un sistema bancario asumiendo que los usuarios siempre quieren lo mejor para el banco. Asume que algunos van a intentar cosas raras, y construye el sistema para que esas cosas raras no rompan nada importante. La asunción adversarial no es paranoia: es realismo profesional.
Para Abordo el principio se traduce así: el chofer del bus puede tener incentivos económicos directos para que el sistema no funcione bien, o para que sus mediciones sean manipulables. Esa posibilidad no la podemos ignorar. Por lo tanto el diseño tiene que ser robusto frente a ella.
Por qué la confianza no es opción
El argumento intuitivo opuesto sería: trabajemos con los choferes, incluyámoslos en el sistema, hagamos que reporten. En empresas con buena cultura puede funcionar. Pero en el momento exacto en que el sistema empieza a entregar valor —es decir, cuando empieza a hacer visible una pérdida que antes no se veía— se introduce un incentivo grande para que algunos operadores quieran que el sistema deje de funcionar bien.
Notar el matiz: no todos. La mayoría de los choferes en cualquier flota son honestos y harían su trabajo bien con o sin sistema. Pero un sistema robusto tiene que funcionar incluso para los pocos que no. Diseñar suponiendo que todos cooperan es entregar el control del producto a la minoría no cooperativa.
Esto es importante decirlo al cliente porque no es una declaración sobre su personal. Es una declaración sobre diseño bajo incentivos asimétricos.
Las decisiones que se derivan del principio
Una vez que asumes operador adversarial, todas las decisiones del producto se vuelven más claras.
No depende de la cooperación del chofer
El sistema no le pide al chofer apretar ningún botón, abrir ninguna pantalla, reportar ninguna cosa. Si el chofer no hace nada en relación a Abordo durante toda su jornada, el sistema sigue contando. La cooperación no es input.
Esto contrasta con sistemas APC más antiguos que dependían de que el chofer activara o calibrara algo. Cualquier dependencia de acción humana es una palanca de sabotaje. Eliminarla en el diseño elimina la palanca.
Detección de manipulación física
El dispositivo está montado en techo dentro de un enclosure protegido, fuera del alcance directo. Pero más importante: el sistema monitorea su propio funcionamiento. Si la calidad de las detecciones cae bruscamente en una ruta en operación normal —por ejemplo, porque algo está tapando la cámara—, eso genera una alerta de tampering en el portal. La caída anómala de eventos en un trayecto que históricamente registra X conteos es una señal de manipulación posible y dispara revisión presencial.
No es a prueba de todo, pero eleva significativamente el costo de manipular: el chofer no solo tendría que tapar la cámara, tendría que hacerlo de manera que la operación no caiga visiblemente respecto a la normal histórica. Eso es mucho más difícil que tapar y olvidarse.
Independencia del sistema de boletaje
La reconciliación de Abordo cruza eventos de visión contra boletos. Si el conteo y el boletaje vinieran del mismo origen (por ejemplo, ambos reportados por el chofer en un dispositivo), no habría reconciliación posible. Manteniendo ambos canales independientes —boletos desde el sistema del operador, conteos desde un dispositivo Rutik autónomo— se mantiene la propiedad clave: hay dos versiones de la verdad y donde difieren hay un dato relevante.
Procesamiento local y telemetría continua
Si el dispositivo dependiera de subir video a la nube para hacer su trabajo, manipulando la conexión 4G se podría apagar el sistema. Procesando localmente, el dispositivo cuenta incluso sin conexión y guarda los eventos para sincronizar después. El intento de saturar la conexión no apaga el conteo, solo retrasa el reporte.
Telemetría adicional (estado de salud del dispositivo, voltaje de entrada, temperatura del enclosure, integridad del fuse del firmware) viaja continuamente y permite detectar manipulación del propio aparato.
Qué le decimos al chofer
Una pregunta operativa razonable: ¿hay que comunicarle al chofer que hay un sistema de conteo? La respuesta es sí, por varias razones:
- Es un requisito de transparencia laboral. No comunicar un sistema de monitoreo es problemático bajo varias dimensiones legales y éticas.
- El efecto disuasivo depende de que se sepa. Si el operador no sabe que hay un dato auditable, no ajusta su comportamiento. La eficacia del sistema baja.
- Refuerza la confianza con quien sí trabaja bien. Los choferes honestos prefieren operar en un contexto donde la fuga no se les imputa colectivamente. El sistema separa el desempeño individual.
La comunicación típica es: "se instaló un sistema de conteo automático que mide la ocupación del bus y la cruza contra el boletaje. No graba personas, no identifica a nadie, no transmite video. Solo cuenta." La frase es honesta y completa.
El malentendido frecuente
A veces algún gerente reacciona: "yo confío en mis choferes, no necesito esto". La respuesta no es discutir la confianza. La respuesta es: incluso confiando, los datos te ayudan a tomar mejores decisiones. Y donde la confianza está bien depositada, los datos lo van a confirmar. Donde no, los datos te van a dar la información para actuar.
Confiar es bueno. Verificar es mejor. Y en este caso verificar es barato.
La incomodidad como característica
La frase "operador adversarial" es incómoda. Pero la incomodidad es información: lo que la frase está diciendo es que el sistema no se cae si parte del personal decide no cooperar. Esa es una propiedad valiosa, no un defecto. Si un proveedor te promete un APC que funciona "siempre y cuando el chofer colabore", lo que te está vendiendo es algo frágil disfrazado de algo robusto.
Los productos que asumen adversarialidad son los que sobreviven en producción real. Los que asumen cooperación caen al primer problema. Esta es la regla en cualquier campo —seguridad, finanzas, infraestructura crítica— y aplica también aquí.
Cierre
Diseñar contra el chofer no es desconfiar de la gente. Es diseñar bien. Y la prueba es que cuando el sistema lleva tiempo operando, la conversación dentro de la empresa cambia: deja de hablarse de "quién es deshonesto" y se empieza a hablar de "qué rutas, qué tramos, qué patrones". Los datos despersonalizan la conversación y la vuelven operacionable. La paradoja es que un sistema diseñado bajo desconfianza estructural produce una operación con más confianza individual, porque los problemas dejan de ser anécdotas y se vuelven métricas.
Con este post cerramos la primera serie del blog. Si quieres seguir conversando sobre estos temas, escríbenos. Y si quieres ver el sistema funcionando, el prototipo es gratis.