Robots de seguridad en plataforma aeroportuaria: AESA, EASA y operativa real

La plataforma de un aeropuerto no es un escenario donde la robótica de seguridad se prueba, es un entorno regulado donde la robótica se subordina. Quien no entienda esa diferencia no debería acercar una máquina al lado aire.

El sector ha asimilado mal el debate. Se habla de robots autónomos en plataforma como si la cuestión fuese de capacidad técnica, cuando en realidad es de encaje normativo y de responsabilidad operativa. Un robot puede patrullar, detectar y reportar. Lo que no puede es decidir por sí mismo en un espacio donde cada metro está tasado por AESA, cada movimiento coordinado con torre y cada incidente reconstruido por una comisión. La autonomía, en este contexto, se mide en milisegundos de reacción y en líneas de procedimiento, no en folletos comerciales.

Qué es realmente la plataforma airside

La plataforma aeroportuaria, lo que en castellano técnico se denomina lado aire, comprende las pistas, calles de rodaje, plataformas de estacionamiento de aeronaves, zonas de combustible, áreas de handling y los caminos de servicio asociados. Es un espacio físicamente delimitado, jurídicamente acotado y operativamente gobernado por la Agencia Estatal de Seguridad Aérea, AESA, bajo el marco europeo de la Agencia de la Unión Europea para la Seguridad Aérea, EASA. Cualquier elemento móvil que circule por esa superficie, desde un tractor de remolque hasta un robot de vigilancia, se considera vehículo de plataforma y está sujeto a un régimen específico de autorización, marcado, iluminación y comunicación.

Esto cambia la conversación desde el inicio. Un robot de seguridad que en un polígono logístico se despliega en cuatro horas, en un aeropuerto exige semanas de análisis previo. No por capricho administrativo, sino porque la consecuencia de un fallo no es un palé volcado, es un avión desviado o, en el peor de los casos, una incursión en pista. La normativa española y europea ha codificado esa diferencia durante décadas, y la robótica llega tarde a un cuerpo regulatorio que ya estaba escrito.

El operador aeroportuario, en España AENA en la mayoría de los casos, mantiene la responsabilidad última sobre el lado aire. Cualquier proveedor que opere allí, lo hace en régimen de delegación funcional, bajo procedimientos del operador y bajo supervisión de AESA. Un fabricante de robótica que no comprenda esta jerarquía está vendiendo aire. Quien la comprenda, sabe que el producto no es la máquina, es la integración de la máquina en una cadena de mando que ya existe.

La plataforma, además, no es homogénea. Las zonas críticas, próximas a aeronaves estacionadas o en movimiento, exigen estándares distintos de las áreas perimetrales, de los caminos de servicio o de los hangares. Un robot que tenga sentido en el perímetro exterior puede no tenerlo a cincuenta metros de una aeronave en repostaje. La conversación sobre robótica airside es, en realidad, una conversación sobre zonificación.

El marco AESA: qué se exige antes de mover una rueda

AESA, como autoridad nacional, transpone y aplica los reglamentos europeos sobre operaciones aeroportuarias, fundamentalmente el Reglamento (UE) 139/2014 y sus modificaciones, junto con los requisitos del Programa Nacional de Seguridad de la Aviación Civil. Cualquier sistema robótico que se proponga operar en lado aire debe inscribirse en el manual del aeródromo, lo que implica que el operador aeroportuario debe haber documentado previamente el procedimiento de uso, las condiciones de despliegue, las interfaces con otros vehículos, los protocolos de fallo y los escenarios de retirada.

Esto no es una formalidad. El manual del aeródromo es el documento que AESA inspecciona y sobre el que se construye la certificación del aeropuerto. Introducir un nuevo tipo de vehículo, y un robot autónomo lo es a todos los efectos, exige una modificación formal del manual, con análisis de riesgo asociado, evaluación de impacto sobre la operativa existente y, frecuentemente, un período de prueba supervisado antes de la aprobación definitiva. Los plazos realistas no se miden en semanas, se miden en trimestres.

A esto se añade la cuestión del marcado y la conspicuidad. Todo vehículo de plataforma debe ser visible desde aeronaves y desde otros vehículos, con esquemas cromáticos y luminosos definidos. Un robot pintado en gris discreto, pensado para entornos industriales, no cumple. La conspicuidad es no negociable y obliga a un diseño específico para el entorno aeroportuario, lo que tiene consecuencias sobre el inventario del fabricante y sobre la economía del despliegue.

El régimen de autorización del conductor, o del operador remoto en el caso de sistemas no tripulados, está igualmente regulado. La persona que supervisa el robot desde un puesto de control debe acreditar formación específica en operaciones airside, conocimiento de fraseología aeronáutica y familiaridad con los procedimientos del aeropuerto concreto. No es transferible entre aeropuertos sin formación adicional. Esto impacta directamente sobre el modelo de servicio: un fabricante no puede mover operadores entre instalaciones como lo haría en logística.

La responsabilidad civil y penal en caso de incidente queda repartida entre el operador aeroportuario, el proveedor del sistema y el operador remoto, según el reparto establecido en el contrato y en el manual. La experiencia muestra que el operador aeroportuario tiende a desplazar la responsabilidad operativa al proveedor, lo que obliga al fabricante a contar con coberturas de seguro y con estructura jurídica adecuadas. Sin ese andamio, ningún piloto avanza.

EASA y el peso de la Parte 145 en el ecosistema

La Agencia Europea para la Seguridad Aérea, EASA, fija el marco regulatorio que AESA aplica en España. Para la robótica de seguridad airside, el cuerpo normativo relevante incluye el ya citado Reglamento 139/2014, los Acceptable Means of Compliance asociados, y, cuando el sistema incorpora componentes que interactúan con aeronaves o con sus sistemas de tierra, los requisitos de la Parte 145 relativos a organizaciones de mantenimiento.

La Parte 145 no se aplica directamente a un robot de vigilancia perimetral. Se aplica, y aquí está el punto que muchos proveedores ignoran, cuando el sistema integra sensores, comunicaciones o actuadores que afectan al estado de aeronavegabilidad de aeronaves o al funcionamiento de equipos de tierra certificados. Un robot que se limita a patrullar y reportar queda fuera. Un robot que interactúa con sistemas de iluminación de pista, con balizamiento o con equipos de handling certificados, entra en el ámbito de la Parte 145 a través de la cadena de integración. La frontera no siempre es nítida, y la prudencia exige tratarla con conservadurismo.

EASA también ha publicado documentación específica sobre la integración de sistemas no tripulados en aeropuertos, fundamentalmente en el contexto de aeronaves no tripuladas, pero con principios aplicables a vehículos terrestres autónomos. Los conceptos de Specific Operations Risk Assessment, SORA, y de niveles de aseguramiento operativo, ofrecen un vocabulario que la robótica de superficie puede adoptar para estructurar su evaluación de riesgo, aunque no le sea formalmente exigible. Un fabricante serio lo hace porque facilita el diálogo con la autoridad, no porque la ley se lo imponga.

La evolución regulatoria europea apunta hacia una mayor formalización de los sistemas autónomos en plataforma. Las discusiones en curso en el seno de EASA y en grupos de trabajo asociados sugieren que en los próximos años habrá un marco más específico, probablemente derivado de los principios de la aviación no tripulada y adaptado a la superficie. Quien construya su sistema hoy sobre principios laxos, tendrá que rehacerlo. Quien lo construya con un margen de conservadurismo regulatorio, se ahorrará la segunda inversión.

Conviene añadir que la coordinación entre EASA, AESA y los reguladores de seguridad operacional, incluyendo CNPIC para infraestructuras críticas, no siempre es fluida. Un aeropuerto es a la vez infraestructura aérea regulada por AESA, infraestructura crítica designada bajo el marco del CNPIC, y, en lo que respecta a tratamiento de datos personales captados por cámaras, sistema regulado por la AEPD. Tres autoridades, tres marcos, una misma rueda. El proveedor que no anticipe la triple revisión llega al despliegue con el cronograma roto.

Coordinación con torre y la cuestión del humano en el bucle

La torre de control es el centro nervioso de la plataforma. Toda autorización de movimiento, todo cambio de ruta, toda incursión imprevista, pasa por ella. Un robot que opere en lado aire debe estar integrado en esa cadena de comunicación, lo que no significa necesariamente que el robot hable directamente con torre. En la práctica, el modelo dominante es el del operador remoto que actúa como intermediario, comunicándose con torre por los canales aeronáuticos estándar y traduciendo las decisiones a comandos para el robot.

Este modelo introduce una latencia y una carga cognitiva que el diseño del sistema debe absorber. El operador remoto no puede gestionar simultáneamente más de un número limitado de robots, especialmente en momentos de alta carga operativa, como movimientos masivos de aeronaves en hora punta. La ratio realista, según experiencias documentadas en aeropuertos europeos que han probado sistemas similares, se sitúa en uno a dos o uno a tres en zonas activas, y puede subir a uno a cinco en perímetros menos sensibles. Quien venda ratios de uno a diez en plataforma activa, vende una expectativa que la realidad operativa no sostiene.

El concepto de humano en el bucle adquiere aquí un significado preciso. No basta con que un humano supervise. El humano debe poder tomar el control en menos de tres segundos ante cualquier anomalía, debe disponer de información suficiente para decidir, y debe estar formado para hacerlo en el marco fraseológico aeronáutico. La arquitectura técnica que permite esto, redundancia de comunicaciones, capacidad de paro inmediato, retorno automático a posición segura ante pérdida de enlace, no es trivial y encarece el sistema. Es lo que separa un robot industrial reetiquetado de un robot diseñado para airside.

La coordinación con torre exige también que el sistema sea visible en el SMR, Surface Movement Radar, o en los sistemas equivalentes de vigilancia de superficie que el aeropuerto utilice. Esto implica transpondedores específicos, marcado radar compatible o, en aeropuertos con sistemas A-SMGCS avanzados, integración digital con la plataforma de gestión de movimientos. Cada aeropuerto tiene su configuración, y la portabilidad entre instalaciones es limitada. El fabricante que prometa una solución universal está pasando por alto la heterogeneidad real del parque aeroportuario español.

Los procedimientos de baja visibilidad merecen mención aparte. Cuando el aeropuerto entra en LVP, Low Visibility Procedures, las reglas de movimiento en plataforma cambian, las distancias de separación aumentan y la prioridad de comunicación con torre se reorganiza. Un robot debe tener procedimientos específicos para LVP, idealmente con repliegue automático a una zona segura predefinida. Improvisar en LVP no es opción.

Lo que un robot puede hacer en plataforma y lo que no

Hechas las precauciones, conviene decir qué aporta un robot bien integrado en lado aire. Aporta vigilancia perimetral continua en zonas de difícil acceso, donde las patrullas humanas son costosas y la cobertura por cámaras fijas presenta ángulos muertos. Aporta detección de intrusiones en vallados, fauna en pista, objetos extraños en superficie, lo que se conoce como FOD, Foreign Object Debris, y anomalías en balizamiento. Aporta documentación continua de la operativa, lo que es valioso tanto para análisis de incidentes como para auditorías de seguridad. Y aporta una capacidad de respuesta inicial, no de intervención, que reduce el tiempo entre detección y reacción humana cualificada.

Lo que no aporta, y conviene decirlo con claridad, es sustitución del personal cualificado de seguridad aeroportuaria. Las funciones de inspección, autorización, control de accesos a zonas restringidas y respuesta a incidentes graves siguen siendo competencia humana, por razones regulatorias y operativas. El robot extiende el alcance del personal, no lo reemplaza. Esta es la misma lógica que aplica BOSWAU + KNAUER en otros entornos críticos, y que el libro "Del oficio constructor a la tecnología de seguridad" desarrolla en el capítulo dedicado a industria y logística. La regla es estable: la tecnología multiplica la atención humana, no la sustituye.

Tampoco aporta intervención sobre aeronaves o sobre equipos certificados de handling. Un robot que se acercase a una aeronave estacionada para realizar inspección visual, por ejemplo, requeriría un nivel de aprobación que hoy ningún sistema comercial ha alcanzado en España. La frontera entre vigilancia y operación es estricta, y los proveedores que la cruzan en sus presentaciones sin haberla cruzado en su documentación regulatoria pierden credibilidad ante el operador aeroportuario en la primera reunión técnica.

En el plano económico, el caso de uso más sólido para un robot en plataforma es la vigilancia perimetral nocturna y de fin de semana, donde el coste por hora del personal humano es máximo y la densidad de operaciones aéreas es mínima. Ahí el robot rinde, ahí la integración con torre es menos exigente y ahí el operador aeroportuario está más dispuesto a aprobar un piloto. Comenzar por el caso más simple permite generar la evidencia operativa que respaldará casos de uso más ambiciosos en fases posteriores.

Incidentes documentados y lo que enseñan

La experiencia internacional con sistemas robóticos en aeropuertos es todavía limitada y los incidentes documentados públicamente son escasos, lo que en sí mismo es una señal. La mayoría de pilotos se han desarrollado en condiciones de discreción, y los resultados, positivos o negativos, no siempre se publican. Lo que sí está documentado, fundamentalmente en informes de ENISA y en análisis sectoriales europeos, son patrones de fallo que afectan a sistemas autónomos en entornos críticos en general, y que aplican a la robótica de plataforma con ajustes mínimos.

Los patrones recurrentes incluyen pérdidas de comunicación entre robot y centro de control, especialmente en zonas con interferencias por la propia infraestructura aeroportuaria, fallos de localización en condiciones meteorológicas adversas, y comportamientos inesperados ante elementos no previstos en el entrenamiento, desde reflejos en superficies mojadas hasta fauna en movimiento. Cada uno de estos fallos tiene mitigación técnica conocida, pero la mitigación encarece el sistema y exige pruebas extensas que muchos proveedores no han realizado.

En el plano ciberseguro, CCN-CERT e INCIBE han alertado sobre la superficie de ataque que introducen los sistemas conectados en infraestructuras críticas. Un robot en plataforma es un nodo conectado, y por tanto un vector potencial. Las exigencias derivadas de la transposición de NIS2 al ordenamiento español elevan la barra de cumplimiento para cualquier sistema desplegado en aeropuertos designados como operadores esenciales. Un fabricante que no presente desde el primer día su arquitectura de seguridad lógica, segmentación de red, gestión de identidades y registro de eventos, no pasa la fase de evaluación técnica.

La AEPD, por su parte, ha publicado criterios sobre videovigilancia y tratamiento de datos biométricos que afectan a los robots equipados con cámaras y con capacidades de análisis. La grabación continua de espacios en los que puedan aparecer personas identificables exige base jurídica clara, información a los afectados y medidas técnicas y organizativas proporcionadas. En un aeropuerto, donde el tránsito de personal es elevado, este punto no es menor y debe integrarse en el diseño del sistema, no añadirse al final.

Las lecciones, agregadas, son claras. La robótica airside funciona cuando se diseña desde el marco regulatorio hacia el producto, no al revés. Funciona cuando el operador aeroportuario está integrado en el diseño desde el primer día, no cuando se le presenta un sistema cerrado. Funciona cuando el fabricante asume que la primera función del robot es no perturbar la operación, y la segunda es aportar valor. Quien invierta el orden, llega tarde a la siguiente conversación.

Lo que permanece

La robótica de seguridad en plataforma aeroportuaria no es un capítulo de la automatización industrial trasladado al lado aire. Es una disciplina propia, donde la capacidad técnica del sistema importa menos que su encaje en un cuerpo regulatorio denso y en una cadena de mando que precede al fabricante en décadas. AESA, EASA y el operador aeroportuario fijan el perímetro de lo posible, y dentro de ese perímetro el espacio para la innovación es real pero acotado. Quien lo entiende, construye sistemas que se aprueban. Quien lo ignora, construye demostraciones que no salen del hangar.

El humano sigue en el bucle, no por nostalgia, sino por arquitectura de responsabilidad. La pregunta no es cuándo desaparecerá, sino cómo se distribuyen las tareas entre máquina y persona para que el conjunto resulte más fiable que cada parte por separado. Esta es la misma lógica que recorre el libro "BOSWAU + KNAUER. Del oficio constructor a la tecnología de seguridad". La tecnología no sustituye, multiplica. Y en plataforma aeroportuaria, multiplicar es ya un logro considerable.

Para los responsables de seguridad aeroportuaria, de handling o de servicios auxiliares que estén considerando este camino, la vía sensata pasa por una conversación confidencial de sesenta minutos, sin compromiso, en la que situar la cuestión antes de mover una rueda. Es el Camino I del trabajo de BOSWAU + KNAUER, y el punto desde el que las decisiones siguientes se toman con información, no con folletos.

Preguntas frecuentes

¿Qué exige AESA?

AESA exige que cualquier vehículo que opere en lado aire, incluido un robot autónomo, esté incorporado al manual del aeródromo del operador aeroportuario. Esto implica análisis de riesgo previo, definición de procedimientos operativos, formación específica del personal de control, marcado y conspicuidad conformes a la normativa, y un período de prueba supervisado antes de la aprobación definitiva. Los plazos realistas se cuentan en trimestres, no en semanas. La responsabilidad última sigue siendo del operador aeroportuario, lo que obliga al proveedor a estructura jurídica y de seguros adecuada.

¿Cómo aplica EASA?

EASA fija el marco europeo a través del Reglamento 139/2014 y normativa asociada, que AESA aplica en España. Para robótica de vigilancia perimetral pura, el encaje principal es el del régimen de vehículos de plataforma. Cuando el sistema interactúa con equipos certificados o con sistemas de aeronavegabilidad, entra en el ámbito de la Parte 145 a través de la cadena de integración. EASA está desarrollando marcos específicos para sistemas autónomos, con principios derivados de la aviación no tripulada que probablemente se extenderán a vehículos terrestres en próximos años.

¿Quién coordina con la torre?

En el modelo operativo dominante, el operador remoto del robot actúa como intermediario con la torre, usando los canales y la fraseología aeronáutica estándar. El robot no habla directamente con torre. El operador debe estar formado en operaciones airside del aeropuerto concreto, no siendo la formación transferible entre instalaciones. La ratio realista de robots por operador en zonas activas se sitúa entre uno a dos y uno a tres. En procedimientos de baja visibilidad las reglas cambian y exigen protocolos específicos, idealmente con repliegue automático del robot a posición segura predefinida.

¿Qué incidentes se han documentado?

La experiencia pública es limitada, lo que en sí mismo refleja la prudencia del sector. Los patrones documentados por ENISA, CCN-CERT e INCIBE en infraestructuras críticas en general incluyen pérdidas de comunicación, fallos de localización en condiciones meteorológicas adversas y comportamientos inesperados ante elementos no entrenados. Cada uno tiene mitigación técnica conocida, pero exige pruebas extensas. La superficie de ataque ciberseguro y las exigencias derivadas de NIS2 y de la AEPD en materia de videovigilancia añaden capas adicionales que deben integrarse en el diseño desde el inicio, no añadirse al final del proyecto.