SORA 2.5: evaluación de riesgo para drones en la categoría Específica

Cuando una operación con dron no encaja en ningún escenario predefinido, la categoría Específica obliga a demostrar que es segura mediante un análisis de riesgo a medida. La herramienta para hacerlo se llama SORA. Conviene fijar la idea desde el principio: SORA no es una forma de autorización ni un trámite, sino una metodología de evaluación de riesgo. El trámite sigue siendo la solicitud de autorización operacional ante AESA; SORA es el método con el que analizas tu operación y construyes la evidencia que sustenta esa solicitud. Esta guía explica, para un profesional, cómo funciona la metodología paso a paso y qué cambia con la versión 2.5.

Qué es SORA y para qué sirve

SORA (Specific Operations Risk Assessment) es la metodología desarrollada por JARUS que EASA publica como Medio Aceptable de Cumplimiento (AMC) al artículo 11 del Reglamento (UE) 2019/947. No es una norma de uso obligatorio, sino el camino reconocido para justificar que una operación de la categoría Específica alcanza un nivel de seguridad aceptable. El resultado del análisis es lo que el operador presenta a AESA junto con su manual de operaciones para obtener la autorización.

En esencia, SORA es un proceso de 10 pasos que evalúa por separado el riesgo en tierra y el riesgo en aire, los combina en un único nivel de exigencia y, a partir de ahí, fija qué medidas de seguridad debe cumplir la operación y con qué robustez. Es el mismo lenguaje que usan todas las autoridades europeas, de modo que una evaluación bien hecha es comprensible y reutilizable más allá de España.

Todo empieza en el ConOps y el volumen operacional

El primer paso de la metodología no es ninguna tabla de riesgo: es describir con precisión qué quieres hacer. Ese documento se llama ConOps (Concept of Operations) y recoge la misión, el dron, el equipo humano, los procedimientos y el entorno. Todo lo que viene después se calcula sobre lo que el ConOps declara, así que un ConOps vago produce un análisis inservible.

Sobre el ConOps, SORA delimita el espacio de la operación en capas concéntricas. La geografía de vuelo es el volumen donde pretendes volar. A su alrededor se añade el volumen de contingencia: el margen al que puede llegar el dron si algo se desvía y aplicas tus procedimientos de contingencia. Ambos forman el volumen operacional. En el suelo, ese volumen se proyecta con un buffer de riesgo en tierra que cubre dónde podría caer el dron, y más allá queda el área adyacente, que la metodología también obliga a considerar por si el dron escapa del volumen previsto.

Los 10 pasos de la metodología

SORA 2.5 mantiene la estructura de 10 pasos de la metodología. Vistos en orden, se entiende cómo cada pieza alimenta a la siguiente:

1. Describir el ConOps. La operación, el UAS, el personal y los procedimientos.
2. Calcular el GRC intrínseco (iGRC). El riesgo en tierra «bruto», a partir de la densidad de población sobrevolada y del tamaño y velocidad del dron.
3. Aplicar mitigaciones de tierra → GRC final. Zonas de resguardo, restricciones operacionales o sistemas como el paracaídas reducen el GRC.
4. Determinar el ARC inicial. El riesgo de encuentro con aviación tripulada según el espacio aéreo del volumen operacional.
5. Aplicar mitigaciones estratégicas de aire → ARC residual. Restricciones de zona y horario que reducen la probabilidad de encuentro antes de despegar.
6. Fijar el TMPR. Los requisitos de mitigación táctica: qué capacidad de «ver y evitar» (observadores, DAA) exige el ARC residual en vuelo.
7. Cruzar GRC y ARC → SAIL. El nivel de exigencia global de la operación, de I a VI.
8. Identificar los OSO. La lista de Objetivos de Seguridad Operacional que el SAIL activa y su robustez (baja, media o alta).
9. Evaluar el área adyacente. Qué pasa si el dron escapa del volumen operacional: requisitos de contención según lo que haya alrededor.
10. Componer el paquete de seguridad. Reunir toda la evidencia (ConOps, cálculos, mitigaciones, OSO) en el expediente que acompaña la solicitud.

Ground Risk Class (GRC) y Air Risk Class (ARC)

El GRC (Ground Risk Class) mide el riesgo que la operación supone para las personas que están en tierra: depende de cuánta gente puede haber bajo la trayectoria y del tamaño y energía del dron. Cuanto más poblado es el suelo sobrevolado y más grande el UAS, mayor es el GRC.

El ARC (Air Risk Class) mide el riesgo de colisión con otra aeronave y depende del espacio aéreo en el que se vuela: no es lo mismo operar a baja altura en zona rural sin tráfico que dentro de un espacio aéreo controlado. Volar a la vista (VLOS) reduce el riesgo aéreo frente a operar BVLOS.

Ambas clases admiten mitigaciones, y aquí está buena parte del trabajo fino de la metodología. En tierra, SORA 2.5 reconoce reducciones por resguardo (la población sobrevolada está protegida por estructuras), por restricciones operacionales (acotar la zona y la ventana horaria para exponer a menos gente) y por sistemas que reducen el efecto del impacto, como un paracaídas que limita la energía de caída. Cada mitigación reclamada hay que sostenerla con evidencia proporcional a la reducción que aporta.

En aire, la metodología distingue dos familias. Las mitigaciones estratégicas actúan antes de despegar: elegir espacio aéreo y horarios con menos tráfico reduce el ARC inicial a un ARC residual. Las tácticas actúan en vuelo, y SORA no las deja a criterio del operador: el ARC residual fija un TMPR (Tactical Mitigation Performance Requirement) que dicta qué capacidad de detectar y evitar tráfico necesitas, desde el simple «ver y evitar» del piloto en VLOS hasta observadores del espacio aéreo o sistemas DAA en BVLOS. El objetivo del operador es llegar al SAIL más bajo posible de forma honesta, porque eso reduce el número y la robustez de los requisitos posteriores.

Del riesgo al SAIL (I–VI) y a los OSO

Una vez fijados el GRC final y el ARC residual, SORA los cruza en una tabla para obtener el SAIL (Specific Assurance and Integrity Level), que va de I a VI. El SAIL es la pieza central: traduce el riesgo en un nivel de exigencia y dicta qué OSO (Objetivos de Seguridad Operacional) se aplican y con qué robustez —baja, media o alta— hay que demostrarlos. Los OSO cubren cuatro frentes: la solidez del operador y sus procedimientos, la fiabilidad técnica del UAS, la competencia del personal y la resistencia de la operación a condiciones adversas.

Contención: que el dron no se salga del análisis

Todo el análisis anterior vale para el volumen operacional declarado. Por eso SORA dedica un paso propio a la contención: demostrar que el dron no va a acabar fuera de ese volumen y, si lo hace, que el área adyacente puede tolerarlo. En SORA 2.5 estos requisitos se gradúan en niveles —bajo, medio y alto— que escalan con lo que haya alrededor: no exige lo mismo un campo rodeado de más campo que un volumen pegado a una aglomeración o a un espacio aéreo con tráfico. Un área adyacente sensible implica contención de nivel alto —límites geográficos programados, terminación de vuelo, fiabilidad demostrada—, y este punto tumba más solicitudes de lo que se cree: un buen GRC y un buen ARC no sirven si no puedes demostrar que el dron se queda donde dijiste.

Novedades de SORA 2.5 (iGRC cuantitativo, densidad de población)

EASA adoptó SORA 2.5 mediante la ED Decision 2025/018/R, publicada y de aplicación inmediata desde el 29 de septiembre de 2025. El cambio más relevante es que sustituye las etiquetas cualitativas «poblado / escasamente poblado» de la versión anterior por un iGRC cuantitativo: el riesgo en tierra inicial se calcula a partir de datos numéricos de densidad de población y de las dimensiones del dron, en lugar de clasificar el entorno «a ojo».

Esto hace la evaluación más objetiva y reproducible, pero también más dependiente de datos geográficos fiables: ahora importa conocer con precisión cuántas personas por km² hay realmente bajo la operación, hora a hora si hace falta. El iGRC se obtiene cruzando esa densidad con las dimensiones características y la velocidad del dron, de modo que la misma misión puede cambiar de riesgo según la franja horaria en que se vuele.

• iGRC cuantitativo: el riesgo en tierra inicial sale de datos de densidad de población cruzados con tamaño y velocidad del dron, no de etiquetas cualitativas. Los UAS de menos de 250 g que vuelen a menos de 25 m/s reciben directamente el iGRC 1.
• Mitigaciones de tierra reordenadas: quedan como M1(A) resguardo, M1(B) restricciones operacionales, M1(C) observación del terreno y M2 (reducir el efecto del impacto). El plan de respuesta a emergencias (la antigua M3) deja de descontar GRC y pasa a ser un requisito obligatorio dentro de los OSO para toda operación.
• OSO reformulados: la lista se reorganiza para delimitar mejor las responsabilidades de operador, diseñador del UAS y terceros, así que la correspondencia con los OSO de la 2.0 no es uno a uno.
• Contención graduada: los requisitos de contención se definen con más precisión, se evalúan antes en el proceso y se estructuran en niveles bajo, medio y alto.

La consecuencia práctica: una evaluación heredada de la versión 2.0 no se traslada de forma automática a 2.5. Hay que recalcular el iGRC con datos de población, revisar qué mitigaciones siguen siendo reclamables y remapear la evidencia de los OSO.

Transición desde SORA 2.0: los plazos de AESA

AESA articuló una transición corta. Aceptó solicitudes elaboradas con SORA 2.0 solo hasta el 17 de noviembre de 2025, y las autorizaciones concedidas por esa vía durante la ventana de transición se emitieron con una validez máxima de 1 año. Desde el 18 de noviembre de 2025, toda solicitud nueva se evalúa exclusivamente con SORA 2.5. Quien tenía una solicitud 2.0 ya presentada no tuvo que aportar documentación adicional.

Cuándo te toca aplicar SORA (y cuándo ya está aplicado)

Aplicar la metodología tú mismo no siempre es necesario, porque parte del trabajo ya lo ha hecho la autoridad. Los escenarios estándar (STS) y las PDRA son, en el fondo, evaluaciones de riesgo ya resueltas: la autoridad analizó una operación tipo con esta misma lógica y publicó el resultado con sus condiciones cerradas. Si tu operación encaja en un STS, basta una declaración operacional; si encaja en una PDRA, la autorización llega sin desarrollar el análisis completo. Te toca aplicar SORA justamente cuando tu operación no cabe en ninguna evaluación predefinida.

• STS-01 / STS-02: la evaluación viene hecha y sus condiciones son fijas (dron C5/C6, límites cerrados). Se resuelve con una declaración, sin análisis propio.
• PDRA: evaluación predefinida por la autoridad para operaciones típicas; tú demuestras que cumples sus condiciones, sin rehacer el análisis.
• SORA completo: operación atípica (combinación de BVLOS, sobrevuelo, espacio aéreo o dron concretos): aplicas la metodología a medida y construyes tú la evidencia.

Antes de embarcarte en un SORA conviene comprobar si puedes reformular la misión para que entre en un STS o una PDRA: suele ser más rápido y barato. Si quieres profundizar en estas vías, consulta la categoría Específica paso a paso y los escenarios estándar STS-01 y STS-02.

Qué parte resuelve SKAI (y cuál es trabajo de consultoría)

SKAI parte de los datos de tu misión —dónde, a qué altura, con qué dron y con qué tipo de vuelo— y determina si necesitas un SORA o si te basta un STS o una PDRA, explicándote el porqué. La plataforma también comprueba las zonas geográficas de tu vuelo y tramita las coordinaciones que exijan (ENAIRE, Interior, CECAF…), que forman parte del mismo expediente. La elaboración del SORA en sí —el cálculo del GRC y el ARC, el SAIL y la argumentación de los OSO ante AESA— es un trabajo de consultoría a medida que queda fuera de la plataforma: lo realiza el equipo de Airdexa, la compañía detrás de SKAI.