Gestionar una flota de robots en 50 emplazamientos: guía operativa

Una flota de robots no es una suma de robots, sino una operación logística que comparte hardware con sus sitios.

Quien compra cincuenta unidades y las despliega en cincuenta emplazamientos descubre, hacia el sexto mes, que el problema ya no es el robot. El problema es el recambio que tarda once días en cruzar una aduana, el técnico que no existe en la región noroeste, la versión de firmware que en un sitio responde bien y en otro genera falsos positivos por una diferencia de iluminación. Escalar una flota de seguridad significa industrializar todo lo que rodea al robot, no replicar el robot. Quien no separa esos dos planos termina con una flota nominal de cincuenta unidades y una flota efectiva de treinta y cinco.

Por qué cincuenta cambia la lógica de cinco

Hasta cinco emplazamientos, una flota se gestiona en una hoja de cálculo y con el número de móvil del responsable técnico. Cada robot tiene nombre, cada incidencia tiene historia, cada parada se resuelve con una visita. La operación es artesanal y funciona porque la escala lo permite. A partir de diez emplazamientos empiezan las grietas. A partir de cincuenta, la operación artesanal se rompe y nadie avisa. Simplemente, las disponibilidades caen del 98 por ciento al 89 por ciento sin que ningún incidente concreto lo explique. La degradación es silenciosa, distribuida y, por eso mismo, peligrosa para el operador.

La diferencia entre cinco y cincuenta no es cuantitativa, es estructural. Con cinco sitios, una persona conoce todos los robots y todos los entornos. Con cincuenta, ninguna persona conoce el conjunto, y la operación depende de procesos escritos, de datos limpios y de una cadena de mando que distingue entre lo que se decide en sede y lo que se decide en el sitio. El fabricante que vende cincuenta robots sin haber pensado esa estructura está vendiendo un problema operativo envuelto en una factura. El operador que los compra sin exigir esa estructura está aceptando un coste oculto que solo aparece en la nota interna del año siguiente. En BOSWAU + KNAUER hemos visto ambos lados, y la conclusión es repetida: la flota se diseña en la cabeza antes de salir del almacén, o no se diseña en absoluto. Esa lección está expuesta en el capítulo sobre escalabilidad de nuestro libro "BOSWAU + KNAUER. Del oficio constructor a la tecnología de seguridad", y se condensa en una frase que repetimos a nuestros clientes: lo que no se estandariza, no se sostiene.

Lo que sigue es la traducción operativa de esa frase a cuatro capas concretas. No son las únicas, pero son las que primero ceden cuando la flota crece y nadie se anticipa.

La coordinación como problema de capas, no de personas

Coordinar cincuenta emplazamientos no es contratar a un coordinador. Es construir tres capas que se hablen sin solaparse. La primera capa es el robot mismo, con su autonomía local, su sensórica y su lógica de excepción. La segunda capa es la sala de operación, donde un operador humano sigue varias unidades en paralelo, prioriza alarmas y decide intervención. La tercera capa es la sede de gestión de flota, donde se observan tendencias, se programan campañas de firmware, se planifican recambios y se mide el rendimiento contra contrato. Cada capa tiene su ritmo. La capa robot trabaja en milisegundos. La capa sala trabaja en segundos y minutos. La capa flota trabaja en días y semanas. Mezclar los ritmos es uno de los errores más caros que hemos observado, porque genera salas de operación saturadas de información que no necesitan y sedes de flota ciegas a problemas que ya están escalando.

La capa robot debe resolver localmente todo lo que pueda resolver sin red. Una ruta de patrulla, una detección de presencia en zona restringida, una pérdida momentánea de cobertura, una recarga programada. Si cada una de esas decisiones depende de una conexión a la sede, la flota se detiene cada vez que un router parpadea. La capa sala debe ver solo lo que requiere juicio humano: ambigüedades de clasificación, alarmas confirmadas por más de un sensor, peticiones de soporte del propio robot. La capa flota debe ver agregados, no eventos individuales. Cuántas unidades han registrado fallos del mismo tipo en los últimos siete días. Cuántos sitios están operando con firmware desactualizado. Qué emplazamientos están saliendo del rango de disponibilidad contractual. La capa flota no observa robots, observa patrones.

Esta arquitectura no es elegante en el papel, es necesaria en el campo. Hemos auditado operaciones donde la sede recibía cada alerta individual de cada robot, lo que producía paneles con seis mil eventos diarios y una incapacidad práctica de leer el conjunto. También hemos visto operaciones donde la sala de control quería tomar decisiones de flota, lo que retrasaba campañas de actualización y dejaba sitios con configuraciones heterogéneas durante meses. Las recomendaciones del CCN-CERT sobre arquitecturas de operación segura insisten en esta separación de planos, y aunque su origen es la ciberseguridad de infraestructuras críticas, la lógica se traslada con facilidad a una flota de robots físicos. Quien mantenga las tres capas separadas y bien comunicadas tendrá una flota gobernable. Quien las mezcle tendrá una flota que parece funcionar hasta que deja de funcionar.

Recambios: la geografía es el verdadero coste

La pieza más cara de una flota distribuida no es la pieza, es la distancia. Un sensor óptico vale doscientos euros y se cambia en veinte minutos, pero si tarda cuatro días en llegar al sitio porque el almacén central está a ochocientos kilómetros y no hay stock regional, esos cuatro días son cuatro días de robot parado, contrato incumplido y vigilancia complementaria pagada al margen. La geografía convierte una incidencia trivial en un coste de cinco cifras. Quien diseña una estrategia de recambios sin mirar el mapa está repitiendo el error de quien diseña un sistema de seguridad sin mirar el plano.

Una estrategia de recambios para cincuenta emplazamientos se construye en tres niveles de stock. El primer nivel es el kit de sitio, una caja sellada en cada emplazamiento con las piezas de fallo más frecuente, ordenadas por probabilidad estadística. Baterías de respaldo, juntas, cables, fusibles, una rueda de repuesto, un sensor de proximidad. El kit cubre el ochenta por ciento de las incidencias menores y lo puede aplicar personal del propio sitio con una guía visual. El segundo nivel es el almacén regional, ubicado para que ninguna unidad de la flota esté a más de cuatro horas de transporte de su almacén de referencia. España bien cubierta exige al menos tres almacenes regionales, y conviene revisar la cartografía con la lógica de las direcciones provinciales del CNPIC y de las zonas operativas reales del cliente, no con la lógica administrativa abstracta. El tercer nivel es el almacén central, donde están las piezas de baja rotación y alto valor, los repuestos de electrónica especializada y las unidades de sustitución completa para casos de avería mayor.

El dimensionamiento de cada nivel no se hace por intuición. Se hace contra el histórico de averías, contra la disponibilidad contractual comprometida y contra el coste hora del robot parado. Si el contrato exige 96 por ciento de disponibilidad mensual y el robot trabaja en horario continuo, el operador dispone de unas veintinueve horas mensuales de parada antes de incumplir. Esas veintinueve horas se reparten entre averías esperadas y averías inesperadas. Si la pieza de fallo más probable tarda treinta horas en llegar al sitio, el contrato ya está incumplido antes de la primera avería. La estrategia de recambios no se mide en piezas almacenadas, se mide en horas de robot recuperadas. Esa es la única métrica que importa, y es la que el cliente ve en su factura mensual.

A esto se suma una decisión que muchos fabricantes posponen y luego pagan: la estandarización de componentes. Si la flota usa tres modelos de batería distintos según la generación del robot, el stock regional triplica. Si la flota usa una sola batería compatible con todas las generaciones, el stock se concentra y la rotación mejora. Nuestra plataforma se diseñó con esta restricción desde el inicio, y por eso el catálogo de piezas críticas se mantiene por debajo de cuarenta referencias, frente a competidores que superan las ciento veinte. La diferencia no se ve en la ficha técnica, se ve en el coste de operación a tres años.

La formación no escala por replicación, escala por estructura

Cuando una flota crece a cincuenta sitios, la formación deja de ser un asunto del fabricante y se convierte en un asunto del cliente. Pretender que el fabricante forme a todo el personal de todos los sitios es una promesa que no se cumple. Los técnicos cambian, los operadores rotan, los responsables locales se sustituyen, y al cabo de un año la formación inicial está diluida en una población distinta de la que la recibió. El fabricante que basa su modelo de servicio en formaciones puntuales está construyendo una operación que se degrada por física: la entropía del personal supera siempre la velocidad de actualización.

La respuesta a ese problema no es formar más, es estructurar la formación en niveles diferenciados y soportarla con materiales que sobrevivan a la rotación. El primer nivel es la formación de operador local, dirigida al personal de sitio que interactúa con el robot en su día a día. Debe poder impartirse en dos horas, debe estar grabada en vídeo en formato modular y debe acompañarse de fichas plastificadas que se conservan en el sitio. El operador local no necesita entender la arquitectura del robot, necesita saber cómo arrancarlo, cómo recargarlo, cómo reportar una incidencia y cómo aplicar el kit de recambios básico. El segundo nivel es la formación de técnico regional, dirigida al personal del cliente o del integrador que cubre varios sitios. Es una formación de dos a tres días, con práctica sobre hardware real, y debe certificarse contra una rúbrica documentada. Sin certificación, no hay autorización de intervención avanzada. El tercer nivel es la formación de gestor de flota, dirigida a quien observa la operación en su conjunto desde la sede. Esta formación es la más corta en horas y la más densa en concepto, y debe centrarse en la lectura de datos agregados, no en la mecánica del robot.

La existencia de un centro de formación físico, con una unidad de cada modelo de robot disponible para práctica, deja de ser un lujo cuando la flota supera los treinta emplazamientos. Hemos visto operaciones que se ahorraron el centro de formación durante dos años y luego pagaron el equivalente de su construcción en horas de técnico desplazado para reparar daños causados por personal no formado. La inversión en formación se amortiza por reducción de averías evitables, una métrica que casi nadie mide bien porque exige aislar la causa raíz de cada incidente y atribuirla con honestidad. INCIBE y ENISA han publicado materiales sobre formación operativa en infraestructura tecnológica que conviene revisar, no porque traten específicamente de robots, sino porque la lógica de niveles y certificación es transferible. Una flota formada es una flota que no genera el setenta por ciento de las llamadas a soporte que generaría una flota no formada. Esa cifra no es promesa, es observación de campo.

Firmware: quién decide y cuándo

El firmware es la capa que más cambia y la que más riesgo introduce. Una actualización mal planificada puede dejar quince robots inoperativos en una noche y desencadenar incumplimientos contractuales en cadena. Una actualización pospuesta indefinidamente acumula vulnerabilidades que tarde o temprano alguien encuentra. La gestión de firmware en una flota distribuida es uno de los temas donde más fabricantes prometen y menos cumplen, y donde el cliente raramente lee la letra pequeña hasta que es tarde.

La pregunta operativa no es si actualizar, es quién decide y cuándo. En una flota gobernada con seriedad, esa decisión sigue un protocolo en cuatro pasos. Primero, la versión nueva pasa por un entorno de pruebas controlado del fabricante durante un periodo no inferior a tres semanas, con unidades sometidas a las condiciones representativas de los sitios reales del cliente. Segundo, se selecciona un grupo piloto de tres a cinco emplazamientos, elegidos por diversidad de condiciones operativas y no por comodidad logística, donde se despliega la versión bajo monitorización reforzada durante un periodo adicional. Tercero, si el piloto cierra sin incidencias, se programa el despliegue progresivo al resto de la flota, en ventanas horarias acordadas con el cliente y con capacidad de rollback automático ante cualquier anomalía detectada por la telemetría. Cuarto, se cierra el ciclo con un informe que registra qué versión está en cada sitio, qué incidencias se produjeron y qué decisiones se tomaron. Ese informe forma parte del expediente de cumplimiento, y es lo que un auditor de la AEPD o un asegurador querrá ver si surge una controversia.

La pregunta de quién decide es más delicada. La respuesta industrial es que el fabricante decide la disponibilidad de la versión y el cliente decide el momento del despliegue. En la práctica, los contratos a menudo dejan ese punto ambiguo y el resultado es que nadie decide, lo que significa que el firmware se actualiza tarde o se actualiza mal. La cláusula contractual que recomendamos a nuestros clientes establece que el fabricante notifica con treinta días de antelación la disponibilidad de una versión clasificada como crítica de seguridad, y que el cliente dispone de quince días para autorizar o posponer el despliegue, con la posposición sujeta a una declaración formal de aceptación de riesgo. Esa estructura, que parece burocrática, es la que permite gestionar la responsabilidad cuando algo falla, y es la que recoge la lógica de las recomendaciones de la ENISA sobre actualización segura de sistemas distribuidos.

La pregunta complementaria es cómo se ejecuta. Una flota de cincuenta robots no se actualiza simultáneamente, ni siquiera si el sistema lo permite técnicamente. Se actualiza por olas, con observación entre olas, y con capacidad de detener el proceso si los primeros datos de campo muestran un comportamiento inesperado. La impaciencia en este proceso es la causa más frecuente de incidentes mayores. La paciencia en este proceso es la diferencia entre una operación profesional y una operación aficionada.

Lo que permanece

Una flota de cincuenta robots no se gestiona, se opera como infraestructura. Esa distinción es la que separa al operador que controla su seguridad del que la padece. Las piezas que hay que tener en su sitio son siempre las mismas: tres capas de coordinación con ritmos propios, tres niveles de stock dimensionados contra disponibilidad contractual, tres niveles de formación estructurada y soportada por materiales que sobreviven a la rotación, y un protocolo de firmware que distingue claramente quién decide y cuándo. Ninguna de estas piezas es opcional. Quien ahorra en una, paga en otra, normalmente con intereses.

La escala no es una versión grande de lo pequeño. Es un régimen distinto, con reglas distintas y costes distintos. Quien quiera comprobar si su operación está preparada para esa escala puede empezar por una conversación de sesenta minutos en la que pondremos sobre la mesa lo que vemos en otras flotas de tamaño comparable, sin compromiso ulterior. Quien necesite una mirada más profunda puede solicitar una auditoría de tres a cinco días sobre sus emplazamientos actuales y sus procesos operativos, con entrega de un informe utilizable con o sin nosotros. Y quien quiera medir antes de comprometerse a escala puede acordar un piloto de noventa días sobre un emplazamiento representativo, con métricas de éxito definidas antes de empezar. Los tres caminos están descritos en detalle en nuestro libro "BOSWAU + KNAUER. Del oficio constructor a la tecnología de seguridad", y los tres conducen al mismo punto: un operador que sabe qué tiene, cómo lo opera y qué le cuesta. Eso, en una flota de cincuenta robots, es lo único que sostiene la operación.

Preguntas frecuentes

¿Cómo se coordina una flota?

Mediante tres capas separadas pero conectadas. La capa robot resuelve localmente lo que no requiere juicio humano, en milisegundos. La capa sala de operación gestiona alarmas confirmadas y excepciones, en segundos y minutos. La capa sede de flota observa agregados, tendencias y campañas, en días y semanas. Cada capa tiene su ritmo y su nivel de información. Mezclar los ritmos genera saturación o ceguera. La coordinación efectiva no depende de contratar más coordinadores, depende de respetar esa arquitectura de planos, con protocolos escritos para cada interfaz entre capas.

¿Qué estrategia de recambios funciona?

Una estrategia en tres niveles de stock. Kit de sitio con piezas de fallo frecuente y reparación sencilla, presente en cada emplazamiento. Almacén regional con piezas de rotación media, ubicado para garantizar entrega en menos de cuatro horas a cualquier sitio bajo cobertura. Almacén central con piezas de baja rotación y unidades de sustitución completa. El dimensionamiento se calcula contra disponibilidad contractual y coste hora de parada, no contra intuición. La estandarización de componentes reduce el stock necesario y mejora la rotación. La métrica que importa son las horas de robot recuperadas.

¿Cómo se escala la formación?

Con estructura por niveles, no con repetición de cursos. Nivel operador local de sitio, dos horas, con vídeo modular y fichas plastificadas. Nivel técnico regional, dos a tres días con certificación documentada. Nivel gestor de flota, formación corta y densa en lectura de datos agregados. A partir de treinta emplazamientos, conviene disponer de un centro de formación físico con unidades reales para práctica. La formación se amortiza por reducción de averías evitables, una métrica que pocos operadores miden con honestidad pero que diferencia operaciones profesionales de operaciones improvisadas.

¿Quién actualiza el firmware?

El fabricante decide la disponibilidad de la versión, el cliente decide el momento del despliegue, y el contrato establece los plazos y las responsabilidades. El protocolo recomendado tiene cuatro pasos: pruebas controladas en el fabricante, piloto en tres a cinco emplazamientos diversos, despliegue progresivo con rollback automático, y cierre documental con informe de versiones por sitio. Las actualizaciones críticas de seguridad siguen un calendario abreviado, pero nunca eliminan el piloto. La impaciencia en firmware es la causa más frecuente de incidentes mayores en flotas distribuidas. La paciencia es lo que distingue una operación profesional.