Los anexos del SORA 2.5 de JARUS,
explicados en español

El Main Body es el documento central del paquete: define el proceso completo de la SORA, desde la descripción del concepto de operación (ConOps) hasta la determinación del GRC en tierra, el ARC en aire, el SAIL resultante y la lista de OSO que debes cumplir. Todo lo demás —los anexos— existe para desarrollar en detalle lo que aquí se enuncia. En la edición 2.5 se reescribió a fondo: lenguaje más simple, proceso reordenado y, sobre todo, un cálculo del riesgo en tierra cuantitativo, basado en densidades de población reales (personas/km²) en lugar de los escenarios cualitativos de la 2.0.

En la práctica española, es el documento que AESA espera que hayas seguido cuando presentas una solicitud de autorización en categoría específica fuera de un STS o un PDRA. Si solo vas a leer un PDF del paquete, es este. La calculadora SORA de AeroCopi implementa este flujo paso a paso, con cada decisión trazada al método.

El Anexo A es la checklist documental de la SORA: qué información sobre tu operación y tu aeronave debes recopilar y cómo presentarla para que la solicitud esté completa. Cubre la descripción del ConOps, los datos técnicos del UAS, la organización del operador, los procedimientos y las evidencias que sostienen cada mitigación y cada OSO reclamado. En 2.5 se actualizó para alinearse con el nuevo Main Body.

Importa a cualquiera que redacte la solicitud para AESA: en España, ese análisis se plasma en el EARO, y la diferencia entre una autorización fluida y meses de requerimientos suele estar en haber seguido esta estructura. AeroCopi genera el EARO en PDF a partir de tus datos, con las evidencias organizadas según este esquema.

Si quieres reclamar un GRC final más bajo que el intrínseco, este es tu anexo. Define los criterios de integridad (qué consigue la mitigación) y garantía (cómo demuestras que lo consigue) en robustez baja, media y alta para las mitigaciones del riesgo en tierra: restringir el área sobrevolada, el apantallamiento por obstáculos (sheltering) o reducir el efecto del impacto con un paracaídas. Cada nivel de robustez dicta la evidencia que tendrás que aportar.

Ojo con un cambio relevante de la 2.5: el plan de respuesta a emergencias (ERP) dejó de contar como mitigación que reduce el GRC — ahora se evalúa dentro de los OSO. Si vienes de una SORA 2.0 con el ERP restando un punto de GRC, ese descuento ya no existe.

El Anexo C desarrolla las mitigaciones estratégicas del riesgo aéreo: las que aplicas antes de despegar. Dos familias: restricciones operacionales (limitar el volumen de vuelo, la ventana horaria o la exposición al tráfico) y estructuras y reglas comunes del espacio aéreo. Con ellas puedes justificar ante la autoridad un ARC inicial más bajo que el que la clasificación genérica asigna a tu volumen de operación.

Es uno de los dos anexos que JARUS no tocó en la 2.5: sigue vigente la edición 1.0 de 2019, publicada con el paquete SORA 2.0. El rediseño de los anexos C y D está previsto para cuando exista el modelo teórico de riesgo aéreo (el futuro Anexo G), así que si te lo cruzas citado como «v2.5», desconfía: no existe tal versión.

La pata táctica del riesgo aéreo: qué haces después de despegar para no encontrarte con otra aeronave. El Anexo D define los TMPR (Tactical Mitigation Performance Requirements): las prestaciones de detección, decisión y maniobra de evasión que exige cada ARC residual. Cubre desde el VLOS como mitigación táctica básica y los observadores del espacio aéreo hasta los sistemas técnicos de detectar y evitar (DAA) para BVLOS.

Como el Anexo C, sigue en la edición 1.0 de 2019: la 2.5 no lo modificó. Para el operador español importa sobre todo al preparar operaciones BVLOS: los requisitos de «ver y evitar» que te va a pedir AESA salen de aquí.

El SAIL te dice qué OSO aplican y con qué robustez; el Anexo E te dice qué significa eso exactamente. Para cada objetivo de seguridad operacional detalla los criterios de integridad y de garantía en sus tres niveles de robustez: qué debe conseguir la medida y qué evidencia la demuestra —desde una declaración propia en robustez baja hasta verificación por tercero en robustez alta. En 2.5 se actualizó en línea con la reorganización de los OSO del Main Body.

Es el anexo donde vive el grueso del trabajo documental de cualquier operación con SAIL medio o alto: formación de pilotos, mantenimiento, procedimientos, diseño del UAS. Si tu flota y tus pilotos están bien documentados, este anexo se convierte en un checklist; si no, en un muro. En AeroCopi, los OSO de tu SAIL salen listados con su robustez exigida dentro del flujo de compliance.

La gran novedad de la 2.5. El Anexo F publica el modelo matemático del que sale la tabla de GRC intrínseco del Main Body: cómo se calcula el área crítica de impacto a partir de la dimensión y la velocidad del dron, qué bandas de densidad de población se usan, qué probabilidad de letalidad se asume y qué hipótesis conservadoras protegen el resultado. También documenta la base del modelo de contención (qué pasa si te sales del volumen operacional).

No necesitas leerlo para rellenar la tabla, pero es la referencia si quieres entender por qué da lo que da o justificar una desviación ante la autoridad. Para nosotros es un documento especial: el motor SORA de AeroCopi está verificado celda a celda contra las tablas que emanan de este modelo, y el cálculo de densidad de población usa datos reales del terreno, no estimaciones a ojo.

Si buscas «SORA 2.5 Annex G», aquí tienes la respuesta honesta: no existe. El Anexo G está previsto como la base teórica del modelo de riesgo de colisión en aire —el equivalente aéreo del Anexo F—, pasó consulta externa de JARUS a finales de 2018 y desde entonces sigue en desarrollo, sin publicación oficial.

Su ausencia explica otra rareza del paquete: los anexos C y D siguen en la versión 1.0 de 2019 porque JARUS quiere reescribirlos sobre el modelo del futuro Anexo G en lugar de parchearlos dos veces. Hasta entonces, el riesgo aéreo de la SORA se trabaja con el Main Body 2.5 más los anexos C y D originales.

Nuevo en la 2.5 y publicado unos meses después que el resto (diciembre de 2024). El Anexo H extiende la SORA al escenario en el que parte de la seguridad de tu operación descansa en servicios de terceros: información de tráfico de un proveedor U-space, detectar-y-evitar como servicio, enlaces de comunicaciones contratados. Define cómo se reparten las responsabilidades entre el operador y el proveedor y qué debe exigirse al servicio para poder apoyarse en él dentro de la evaluación de riesgo.

En España hoy afecta a poca gente —los espacios U-space están aún desplegándose—, pero marca la dirección: cuando el BVLOS a escala llegue apoyado en servicios digitales, la frontera de «quién responde de qué» estará escrita aquí.

El diccionario del paquete: define en inglés cada término que usan el Main Body y los anexos, de «adjacent area» a «visual observer». Puede parecer trámite, pero en un método donde media discusión con la autoridad se reduce a qué significa exactamente una palabra («contención», «volumen operacional», «área adyacente»), tener la definición oficial a mano zanja debates.

Si prefieres la terminología en español y aplicada al contexto de AESA, ese trabajo ya lo hicimos: nuestro glosario UAS y SORA define los términos clave con su referencia normativa, citables y con ancla propia.

Antes conocida como «Cyber Annex», esta extensión responde a una pregunta incómoda: ¿qué pasa cuando el riesgo no viene de un fallo mecánico sino de un ataque? Define los conceptos y amenazas de ciberseguridad con impacto en la seguridad operacional —interferencia o suplantación del enlace de mando y control (C2), jamming y spoofing de GNSS, integridad de los datos— y cómo aplicar consideraciones proporcionales al riesgo de la operación dentro del método SORA.

La palabra clave es «proporcionales»: nadie pide una auditoría de ciberseguridad para volar un dron de 2 kg sobre un campo. Pero cuanto más dependa tu operación de enlaces, servicios y automatismos, más presente estará este documento en tu evaluación.

El documento más rentable del paquete si ya conocías la SORA 2.0: la nota explicativa recorre qué cambió en la 2.5 y por qué, documento a documento. Confirma la composición del paquete —Main Body y anexos A, B, E, I y la Cyber Safety Extension actualizados, el Anexo F como novedad, los anexos C y D sin cambios— y razona las decisiones de diseño, como el paso al modelo cuantitativo de riesgo en tierra.

Léelo antes que ningún otro si vienes de una SORA 2.0 aprobada y necesitas evaluar cuánto te afecta la transición. Para una lectura en español de esos cambios, tienes nuestra guía completa de SORA 2.5.