Control de tráfico aéreo con LLM: guía técnica 2026

“`html

En pocas palabras: Sí: los LLM pueden generar transmisiones de radio de control aéreo con realismo operativo. El estudio publicado en arXiv el 19 de agosto de 2026 por Mahyar Ghazanfari y seis coautores demostró que el prompt más simple (P1) superó a las estructuras más complejas en los nueve modelos evaluados.

¿Puede un modelo de lenguaje hacer de controlador aéreo? Un estudio publicado el 19 de agosto de 2026 en arXiv lo puso a prueba con cinco estructuras de prompt, nueve LLM y un vuelo real transcribido a mano. La conclusión va contra la intuición: ganaron los prompts más simples.

El control de tráfico aéreo con LLM es el uso de modelos de lenguaje grandes para generar o asistir las transmisiones de radio entre controladores y pilotos, una tarea clasificada como safety-critical dentro de la gestión del tráfico aéreo. El paper de Mahyar Ghazanfari y seis coautores evalúa si estos modelos logran realismo operativo mediante un pipeline de diálogo multi-turno, métricas de similitud y un juez automatizado validado contra anotaciones de expertos humanos.

En 30 segundos

Los prompts ligeros ganaron: la estructura más simple (P1) superó a las versiones más restringidas en los nueve modelos evaluados.
El script pesado colapsó: el prompt más “scripteado” (P5) se degradó turno a turno porque sus propios errores entraban en el historial del diálogo.
Un ejemplo in-context ayuda: incluir la transcripción completa de otro vuelo como referencia mejoró la similitud de las respuestas.
Inyectar historial real repara: condicionar el modelo sobre transcripciones verificadas en vez de sus propias respuestas salvó la conversación.
La evaluación fue híbrida: métricas automáticas más un LLM como juez (GPT-5.5) validado contra anotaciones de expertos humanos.

GPT-5 es un modelo de lenguaje grande desarrollado por OpenAI, presentado en agosto de 2025. Está diseñado para generar texto, responder preguntas, razonar sobre problemas complejos y asistir en tareas de programación, integrando capacidades de razonamiento avanzado en un único sistema.

Si alguna vez armaste un bot que mantiene una conversación, ya conocés el problema de fondo: el contexto se degrada. Este estudio lo midió con datos duros en uno de los dominios más exigentes que existen, y lo que encontró cambia la forma de diseñar prompts para diálogos largos.

¿Cuál es el desafío de automatizar las comunicaciones de control de tráfico aéreo?

La comunicación de control aéreo es un diálogo crítico para la seguridad que sigue siendo conducido por personas, incluso cuando otras partes de la gestión del tráfico aéreo ya están semiautomatizadas. Esa brecha es exactamente lo que el equipo de investigación quiso medir: si un LLM puede producir transmisiones que un operador real no distinguiría de las genuinas.

Antes de seguir, la definición que vamos a usar en todo el artículo: el prompt engineering para control de tráfico aéreo es el diseño de instrucciones, contexto e historial de diálogo que recibe un modelo de lenguaje para que genere transmisiones de radio con formato y fraseología realistas. El problema que resuelve es concreto. Sin esa estructura, el modelo improvisa, contesta como chatbot y se va de la consigna.

Ponele que estás volando un avión de aviación general sobre la Bahía de San Francisco, en la ruta turística conocida como Bay Tour. Hablás con el control, te dan instrucciones, confirmás readbacks, cambiás de frecuencia. El estudio transcribió a mano un vuelo experimental así y lo usó como referencia (la llaman P0, la verdad de terreno) para comparar lo que generaban los modelos contra lo que dijeron humanos reales.

El tema es que la fraseología de ATC es un lenguaje con reglas estrictas: cada transmisión tiene callsign, verbos reglamentarios y un formato esperado. Un desvío no es un typo. Por eso la investigación avanza con cautela, y el debate ya salió del ámbito académico: en España los colectivos profesionales discuten el rol de la inteligencia artificial en la gestión del tráfico aéreo, mientras la formación de especialistas sigue centrada en criterios humanos.

¿Cómo es la arquitectura de un sistema de control de tráfico aéreo con LLM?

El sistema del estudio es un pipeline de diálogo multi-turno con estado: el modelo hace de controlador, responde a una transcripción fija de piloto y condiciona cada respuesta nueva sobre el historial acumulado de la conversación. Nada de preguntas sueltas; es una conversación entera, turno por turno.

La mecánica es simple de describir y tramposa de implementar. Tomás la transcripción del piloto (que queda fija), le agregás el prompt con la estructura elegida y el modelo responde como si estuviera en la frecuencia. Cada respuesta nueva se suma al historial, y el turno siguiente se genera condicionando sobre todo eso. Subís el modelo, lo probás en local, funciona bárbaro en los primeros turnos, lo dejás correr la conversación completa y de repente la calidad se cae porque un error chico del turno tres entró al historial, el turno cuatro lo tomó como válido, el cinco lo amplificó y al turno ocho tu controlador sintético está reportando un punto de referencia que no existe en la carta.

Acá aparece la variable de arquitectura más interesante. El equipo probó dos formas de armar ese historial: en una, el modelo condiciona sobre sus propias respuestas anteriores (lo natural en un despliegue real); en la otra, el pipeline le inyecta el historial correcto, la transcripción verificada, como si un sistema externo validara cada turno. La distancia entre ambas condiciones es el corazón del paper. Cubrimos ese tema en detalle en lo que cambia con GPT-5.6 Sol.

¿Qué estructuras de prompt se usaron para ATC?

Cinco estructuras, de P1 a P5, con nivel creciente de restricción, diseñadas mediante un proceso iterativo con el piloto en el bucle: un piloto real iteró sobre los prompts hasta afinarlos antes de la evaluación masiva con los nueve modelos.

P1 es el más liviano: una instrucción mínima de rol y tarea. P5 es el más pesado, un script casi reglamentario que dicta formato, fraseología y contenido de cada transmisión. Entre los dos hay tres niveles que agregan restricciones de a poco. Detrás había una intuición razonable: más reglas deberían dar más realismo, porque la fraseología de ATC es estricta.

Spoiler: no funcionó así.

Un prompt ligero se ve más o menos así (esquema ilustrativo basado en la descripción del paper):

Rol: sos un controlador de tráfico aéreo.
Tarea: respondé a la siguiente transmisión del piloto
como lo haría un controlador real en esta frecuencia.

Historial de la conversación:
[transcripción acumulada]

Y el pesado, en cambio, dicta hasta el mínimo detalle:

Sos un controlador de torre. Cada transmisión debe seguir
esta estructura: 1) callsign del piloto, 2) instrucción con
verbo fraseológico reglamentario, 3) readback esperado.
No uses frases fuera del estándar, no introduzcas información
que no esté en el historial y no te desvíes de la plantilla.

Historial: [transcripción acumulada]

Si el prompt está bien armado, el modelo devuelve una transmisión breve, con el callsign correcto, un verbo fraseológico estándar y coherencia con lo que dijo el piloto. Si está mal armado, devuelve un párrafo amable de asistente virtual que arranca con “¡Por supuesto! Aquí tienes la instrucción…” (y eso, en una frecuencia real, sería un problema serio).

Ojo con esto: los prompts de arriba son esquemas ilustrativos que reconstruyen la lógica de P1 y P5 a partir de la descripción del estudio. El texto exacto de cada estructura está en el PDF completo del paper.

¿Por qué los prompts más simples producen mejores resultados?

Porque en un diálogo multi-turno los errores se acumulan. El prompt más restringido colapsó cuando sus propios desvíos entraron en el historial y contaminaron los turnos siguientes. Es el hallazgo central del estudio y va contra la intuición de cualquiera que haya hecho prompt engineering.

En un turno único, más restricción da más control. El problema es el turno veinte. Cuando el modelo se desvía aunque sea un poco del script, ese desvío queda en el historial, el próximo turno se genera condicionando sobre un contexto que ya contiene el error, y el modelo lo trata como válido. Un script rígido no tiene mecanismo de recuperación: se rompe y arrastra todo.

¿Y qué repara el colapso? La inyección de historial correcto. Cuando el equipo reemplazó las respuestas acumuladas del modelo por la transcripción verificada, el prompt pesado volvió a rendir. Es decir, el problema nunca fue la restricción en sí, sino la calidad del contexto sobre el que el modelo condiciona. La “seguridad” por reglas estrictas, sin control del historial, es una ilusión.

Si trabajás con GPT-5 u otro modelo cerrado de última generación, la lección viaja igual: el diseño del prompt pesa, pero el diseño del historial pesa igual o más. Un pipeline con estado sin control de calidad del contexto es una bomba de tiempo. Ya lo cubrimos antes en nuestra guía completa de herramientas dev.

¿Qué LLMs se evaluaron y cómo se midieron los resultados?

Nueve modelos, de código abierto y cerrados, evaluados turno a turno con tres familias de métricas: similitud léxica, estructural y semántica. A eso se suma un LLM como juez (GPT-5.5), que el equipo validó contra anotaciones de expertos humanos antes de usarlo a escala.

Ese detalle del juez me parece bien resuelto. Validar al evaluador automático contra expertos es lo mínimo exigible en un dominio crítico, y acá lo hicieron: si el juez no coincide con los humanos, no sirve, y lo comprobaron antes de confiar en él.

Honestidad obligatoria: el resumen del paper no publica los puntajes numéricos por modelo, así que no te voy a tirar tablas de scores que no tengo. Las comparaciones detalladas están en el PDF completo. Lo que el abstract confirma es el patrón cualitativo: el ejemplo in-context mejora, la restricción extrema empeora, y la inyección de historial repara.

¿Cómo mejora el rendimiento un ejemplo in-context?

Incluir una transcripción completa de otro vuelo experimental como ejemplo dentro del prompt mejoró la similitud de las respuestas en los modelos evaluados. Es la técnica few-shot de toda la vida, aplicada a un dominio con formato muy marcado.

En vez de describirle al modelo qué es una buena transmisión de ATC, le mostrás una conversación real completa, de un vuelo distinto al de prueba, y después le pedís que continúe con el suyo. El modelo agarra el formato, el ritmo y el nivel de detalle sin que tengas que escribirlos en reglas. Es más barato en esfuerzo y más robusto en resultados.

El trade-off es conocido: el ejemplo come tokens, y tokens son costo y latencia. En un pipeline que corre decenas de turnos, meter una transcripción completa en cada prompt se paga. Ahora bien, si la alternativa es un script rígido que colapsa en el turno quince, el ejemplo sale barato. Para producción habría que ver cómo comprimirlo (un resumen de la transcripción, por ejemplo) sin perder el efecto.

Antes y después: prompts de ATC mal armados vs bien armados

La diferencia entre un prompt que zafa y uno que se rompe está en tres cosas: rol acotado, historial incluido y mecanismo de recuperación. Acá van dos casos del dominio ATC.

Caso 1: el prompt vago.

Hacé de controlador aéreo.

Por qué falla: no define rol, ni formato, ni historial. El modelo contesta como asistente de chat y se manda frases que en una torre jamás se dicen. Más contexto en el agente de Copilot para Jira.

Sos un controlador de aproximación. Respondé a la transmisión
del piloto con fraseología estándar, breve y coherente con el
historial. No agregues información que no esté en el historial.

Historial: [transcripción acumulada]

Qué cambió: rol acotado, formato esperado, prohibición explícita de inventar y el historial dentro del prompt. Con eso, el modelo se ancla al contexto real en vez de improvisar.

Caso 2: el prompt “sobrescripteado”.

Respondé siempre con esta plantilla exacta de tres partes,
sin desviarte jamás, incluso si el piloto pide algo distinto
o falta información. No preguntes, no repitas, no corrijas.

Por qué falla: la rigidez extrema no tiene mecanismo de recuperación. En un diálogo multi-turno, el primer desvío queda en el historial y contamina todo lo que sigue (el paper lo demostró con el colapso de P5).

Respondé con fraseología estándar y mantené coherencia con el
historial. Si falta información o el readback no coincide,
pedile al piloto que repita.

Historial verificado: [transcripción]

Qué cambió: la plantilla rígida se reemplazó por reglas de comportamiento más un mecanismo de recuperación (pedir repetición) y un historial verificado. El modelo puede corregir el rumbo sin romperse.

Tabla comparativa de técnicas para control de tráfico aéreo con LLM

Esta tabla resume cuándo conviene cada técnica según lo que el estudio demostró con datos:

Técnica	Cuándo usarla	Complejidad	Resultado según el estudio
Prompt ligero (estilo P1)	Diálogos multi-turno largos	Baja	Mejor desempeño general
Script restrictivo (estilo P5)	Tareas de un solo turno con formato fijo	Alta	Colapsa por acumulación de errores
Ejemplo in-context (few-shot)	Cuando tenés transcripciones reales disponibles	Media	Mejora la similitud de las respuestas
Inyección de historial verificado	Evaluación y producción con contexto confiable	Media	Repara el colapso del script pesado

control de tráfico aéreo con llm diagrama explicativo

Errores comunes al diseñar prompts para comunicaciones de ATC

Estos son los cuatro errores que el paper ayuda a evitar, cada uno con su corrección.

Error 1: sobrescriptear el prompt

Usá únicamente esta fraseología, en este orden, con esta
cantidad de palabras, sin excepciones ni variantes.

Por qué falla: la restricción extrema funciona en el turno uno y se derrumba en el turno quince, cuando el primer desvío entra al historial. La corrección: prompt ligero más un ejemplo in-context que muestre el formato deseado.

Error 2: dejar que el modelo confíe en su propio historial

[Pipeline sin verificación: cada respuesta del modelo
entra directo al historial del siguiente turno]

Por qué falla: los errores se propagan y se amplifican en cadena, que es justo lo que hizo colapsar al prompt pesado. La corrección: inyectar historial verificado, o al menos validar los turnos antes de acumularlos.

Error 3: evaluar con una sola métrica

Modelo aprobado: similitud léxica alta en el 90% de los turnos.

Por qué falla: que las palabras se parezcan no garantiza que el significado sea correcto ni que el formato de la transmisión cumpla. La corrección: combinar las tres familias de métricas del estudio (léxica, estructural, semántica) y validar contra expertos o un juez previamente validado. Relacionado: qué modelo conviene elegir en 2026.

Error 4: arrancar sin ejemplo in-context

Generá transmisiones de ATC realistas para este vuelo.

Por qué falla: el modelo tiene que adivinar el formato, el ritmo y el nivel de detalle. La corrección: incluir una transcripción real de otro caso como referencia dentro del prompt, que es la técnica que mejoró los resultados en los nueve modelos.

¿Cuáles son los límites actuales de los LLM en control de tráfico aéreo?

Los límites son claros: el estudio mide realismo de simulación, no seguridad operacional en frecuencia real; trabajó con un solo vuelo de aviación general como referencia; y no hay despliegue en torres a la vista. ¿Alguien probó esto en una torre operativa? Todavía no. Los propios autores hablan de un camino hacia el ATC asistido por LLM, con sus límites bien marcados.

Lo confirmado por el estudio

Cinco estructuras de prompt evaluadas (P1 a P5) en un pipeline multi-turno con estado, diseñadas con un proceso iterativo con el piloto en el bucle.
Nueve LLM probados, abiertos y cerrados, con métricas léxicas, estructurales y semánticas por turno.
El ejemplo in-context mejora la similitud de las transmisiones generadas.
El prompt más restringido colapsa en diálogos largos, y la inyección de historial correcto lo repara.
Juez automatizado validado: GPT-5.5 como evaluador, chequeado contra anotaciones de expertos humanos.

Lo que sigue pendiente

No hay despliegue operacional ni pruebas en torres reales; todo ocurrió en simulación experimental.
La referencia es un solo vuelo de aviación general (la ruta Bay Tour de San Francisco); falta escala y diversidad de tráfico.
El resumen no publica puntajes por modelo ni datos de latencia en tiempo real.
El marco regulatorio (FAA, EASA) para IA en posiciones de control sigue sin definirse; el paper habla de asistencia, no de reemplazo.

Ojo con una cosa: el riesgo de alucinación no desaparece. Un modelo que inventa una instrucción o un callsign en una simulación es un resultado feo; en una frecuencia real, es otra conversación. Y la latencia es una pregunta abierta: la radio de ATC es tiempo real, y ningún despliegue serio puede esperar segundos por turno. Son temas que el paper deja planteados y que cualquier implementación va a tener que responder.

¿Cómo se valida que un LLM es seguro para comunicaciones críticas?

Con evaluación en capas: transcripciones reales como verdad de terreno, métricas automáticas de similitud por turno y un juez automatizado validado contra expertos humanos. Ninguna capa alcanza sola; la combinación es el estándar que propone el estudio.

El framework tiene tres niveles. Primero, la referencia: un vuelo real transcribido a mano, porque sin verdad de terreno no hay nada que comparar. Segundo, métricas automáticas en tres dimensiones: léxica (las palabras), estructural (el formato de la transmisión) y semántica (el significado). Tercero, el LLM como juez, que el equipo validó contra anotaciones de expertos antes de usarlo a escala.

La diferencia entre laboratorio y operación es donde se juega todo. Que un modelo genere transmisiones parecidas a las de un controlador en una simulación no significa que sea seguro ponerlo en una frecuencia. La validación del paper es un piso, no un techo. En España, la formación de controladores y especialistas de tránsito aéreo sigue centrada en criterios humanos, y los colectivos profesionales ubican a la IA como apoyo, no como sustituto. Esa postura coincide con la conclusión del estudio: asistencia primero; el reemplazo, ni a futuro cercano.

Preguntas Frecuentes

¿Pueden los modelos de lenguaje generar comunicaciones de control aéreo realistas?

Sí, con matices: el estudio de 2026 mostró que los LLM generan transmisiones con alta similitud frente a transcripciones reales cuando usan prompts ligeros y ejemplos in-context. El realismo en simulación está demostrado; la seguridad operacional en frecuencia real sigue sin probarse.

¿Puede la IA reemplazar a los controladores aéreos?

No a corto plazo. Los propios autores del paper hablan de un camino hacia un ATC asistido por LLM, no de reemplazo humano. La comunicación de control aéreo es safety-critical, los modelos acumulan errores en diálogos largos y el marco regulatorio para IA en posiciones de control todavía no existe.

¿Qué estructura de prompt funciona mejor para ATC?

La más ligera. En el estudio, el prompt con menos restricciones (P1) superó a los scripts pesados (P5) en los nueve modelos evaluados, porque la rigidez extrema colapsa cuando los errores del modelo se acumulan en el historial del diálogo. Combinar prompt ligero con un ejemplo in-context dio los mejores resultados.

¿Cómo se evalúa un LLM para sistemas críticos de aviación?

Combinando métricas automáticas de similitud (léxica, estructural y semántica) por turno, un LLM como juez validado contra anotaciones de expertos humanos y transcripciones reales como verdad de terreno. Ninguna métrica sola alcanza: la validación cruzada entre métodos es el estándar del estudio.

¿Qué es la ruta Bay Tour que usó el estudio?

Es una ruta turística de aviación general sobre la Bahía de San Francisco. Los investigadores transcribieron a mano un vuelo experimental por esa ruta y lo usaron como verdad de terreno (P0) para comparar las transmisiones generadas por los modelos con las de controladores humanos reales.

Conclusión

Si tenés que arrancar mañana con algo de esto, empezá por lo barato y lo probado: prompt ligero más un ejemplo in-context. Esa combinación fue la que mejor rindió en el estudio, funciona con modelos abiertos y cerrados, y no requiere infraestructura exótica. Para tareas de un turno con formato fijo, un script puede tener sentido; para diálogos largos, no, y el paper lo demostró con datos.

Las expectativas realistas: esto es tecnología de simulación y asistencia. Sirve para generar tráfico sintético de entrenamiento, para probar sistemas de ATC automatizado y para armar escenarios de práctica. No sirve, hoy, para poner un modelo en una frecuencia. El siguiente paso lógico del campo es escalar las referencias (más vuelos, más rutas, más tráfico) y medir latencia y robustez en condiciones de tiempo real. Hasta ahí, la torre sigue siendo cosa de humanos, con los modelos aprendiendo a hacer bien las veces de controlador en el simulador.

LLM en la torre de control: así se evalúa su desempeño