Muchos concursos y licitaciones de seguridad civil siguen formulando la pregunta principal de forma equivocada: ¿a qué distancia puede detectar el sistema? Suena objetivo, pero normalmente no basta para comparar propuestas ni para proteger al comprador. Una afirmación de detección solo dice que alguna capa puede advertir la presencia de algo. No dice si el operador puede verificar el evento con rapidez suficiente para actuar, si la evidencia es utilizable o si el sistema sabe distinguir el tráfico irrelevante de aquello que realmente justifica una escalada.
Esa diferencia importa porque muchas decisiones de compra se toman a partir de tablas resumidas. Un licitador ofrece más alcance de radar. Otro ofrece más cámaras. Un tercero promete clasificación mediante IA. Si la licitación no define qué aspecto debe tener un desempeño operativo verificado, esas ofertas se vuelven muy difíciles de comparar con rigor. El resultado suele ser un proyecto que genera alarmas, pero no consigue cerrar incidentes con claridad.
Por eso, una buena licitación de seguridad civil no debe detenerse en la detección. Debe preguntar qué evidencia verificará el evento, cómo se entrega esa verificación a los operadores y cómo se probará ese desempeño en el sitio. Una vez que la verificación se incluye en el requerimiento, la licitación pasa a ser un documento de ingeniería mucho más útil que una simple lista de la compra.
La detección es solo el primer paso de la cadena de seguridad
La documentación oficial sobre sistemas de protección trata desde hace tiempo la seguridad como una secuencia, no como una función aislada. La guía CISA CFATS RBPS 1-7 estructura la protección física en torno a detección, demora y respuesta. Del mismo modo, los materiales del DHS sobre contramedidas contra drones separan funciones como detección, seguimiento, identificación y monitorización, porque distintas tecnologías aportan partes diferentes de la imagen operativa.
Esa estructura es importante en las licitaciones porque un evento detectado todavía no es una decisión. Una alerta puede fallar desde el punto de vista operativo si el sitio no puede responder a las preguntas básicas de seguimiento:
- ¿Qué disparó exactamente la alarma?
- ¿Dónde está en relación con el activo protegido?
- ¿El evento sigue activo?
- ¿Qué sensor puede verificarlo?
- ¿Cuánto tiempo queda antes de que la respuesta pierda valor?
Si la licitación solo pide «alcance de detección», los oferentes quedan libres para optimizar la cifra más fácil de publicar. Eso suele producir propuestas difíciles de comparar: un fabricante enfatiza la primera alerta, otro la identificación y un tercero da por sentado, sin decirlo, que un operador humano reconstruirá manualmente el resto de la situación.
La verificación es el paso que convierte una alarma en evidencia accionable. Por eso, una buena licitación debe especificar la cadena completa, no solo la primera salida del sensor.
La verificación debe definirse como una tarea, no como una palabra de moda
Una de las razones por las que la verificación queda infradefinida es que el término se usa de forma laxa. En la práctica, cada proyecto entiende algo distinto por verificación.
La verificación puede significar:
- confirmar que el evento es real y no una falsa alarma,
- confirmar la clase de blanco, como persona, vehículo, dron pequeño o ave,
- confirmar si la actividad ocurre dentro de una zona protegida,
- o generar evidencia apta para el traspaso, el registro o la revisión posterior al evento.
Son tareas relacionadas, pero no idénticas. Una cámara capaz de verificar que «hay algo presente» a una distancia determinada puede no verificar, a esa misma distancia, la clase del blanco ni la intención. Un retorno de radar puede confirmar la persistencia y el patrón de movimiento, pero no la identidad visual. Un evento de RF puede confirmar que hay un transmisor activo sin llegar a demostrar dónde está físicamente la aeronave.
Por eso, la licitación debería indicar con claridad qué significa verificación en el proyecto. Si el comprador no hace ese trabajo, los oferentes llenarán el vacío con supuestos distintos, y la comparación de propuestas resultará engañosa incluso antes de que comience el proyecto.
Una buena licitación define el blanco, la zona y la pregunta de decisión
Los requisitos de verificación ganan mucho cuando se vinculan a tres elementos:
- la clase de blanco,
- la zona protegida,
- y la decisión que debe tomar el operador.
Por ejemplo, «verificar un objeto a baja altitud cerca de la línea de cubierta» es un requisito muy distinto de «verificar que un vehículo cruza una valla exterior». El tamaño del blanco, la geometría de aproximación, el tiempo de aviso y la evidencia útil no son los mismos. Tampoco lo son las mejores combinaciones de sensores.
Por tanto, una licitación rigurosa debería pedir el desempeño de verificación frente a escenarios claramente definidos, por ejemplo:
- persona en la valla exterior,
- vehículo en la puerta de servicio,
- dron aproximándose a la línea de cubierta o al patio técnico,
- y objeto en vuelo elevado que atraviesa la zona sin converger hacia el activo protegido.
La geometría protegida importa tanto como el blanco. Un recinto con un perímetro llano y abierto tiene necesidades de verificación distintas de las de un centro de datos con equipos en cubierta, estructuras mecánicas y preocupaciones por el espacio aéreo a baja altitud. Cuando la zona se deja vaga, los proveedores pueden publicar cifras atractivas de sensores sin demostrar que resuelven la geometría real del sitio.
Esta es también la razón por la que la licitación debería evitar una frase genérica como «verificación en todo tipo de clima». La pregunta debe ligarse al sitio y a la decisión: ¿qué debe poder confirmar el operador, en qué zona y dentro de qué ventana de tiempo?
Pida la cadena de verificación, no solo una lista de sensores
Muchas licitaciones débiles especifican categorías de hardware, pero no el flujo de trabajo que las conecta. Piden radar, cámaras, analítica y quizá detección RF, pero nunca preguntan cómo pasa un evento de una capa a la siguiente.
Una licitación mejor debería exigir al oferente que explique la cadena de verificación:
- qué genera la primera alerta,
- qué evidencia se adjunta de inmediato,
- qué sensor de verificación se orienta primero hacia el blanco,
- cómo ve el operador, en una misma vista, la ubicación, la pista y la imagen,
- y qué condiciones disparan la escalada o el cierre.
Esto importa porque una lista de componentes puede parecer completa y, aun así, dejar al operador con un trabajo fragmentado. Una propuesta puede incluir sensores potentes, pero una lógica de traspaso deficiente. Otra puede incluir sensores modestos, pero una ruta mucho mejor desde la detección hasta la verificación y la respuesta.
Por eso, la licitación debe pedir comportamiento operativo, no solo la presencia de equipos.
Algunas preguntas útiles para la licitación son:
- ¿Puede el sistema abrir el mapa, la pista y la vista de verificación correspondientes desde un único elemento de la cola?
- ¿Cómo se muestra la asignación de responsabilidad cuando un operador toma el evento a su cargo?
- ¿Cuál es la latencia esperada entre la creación de la alerta y la primera indicación de verificación?
- ¿Cómo se fusionan en una sola tarea para el operador las detecciones duplicadas de varios sensores?
- ¿Qué evidencia permanece adjunta después del cierre del incidente?
Estas preguntas muestran si el proveedor entrega un sistema operativo real o simplemente varios canales conectados.
Exija pruebas de aceptación que demuestren la verificación, no solo la generación de alarmas
Esta es la parte que muchas licitaciones omiten. Exigen demostraciones de que el sistema puede disparar una alerta, pero no de que puede verificar de forma consistente en el sitio real.
Es un problema, porque la documentación técnica de referencia distingue una y otra vez entre la caracterización de laboratorio y el desempeño operativo. Los programas de apoyo técnico y de prueba del DHS existen precisamente porque los sistemas deben evaluarse en entornos realistas, no solo sobre el papel. El trabajo del NIST sobre métricas de evaluación viene a decir lo mismo desde una perspectiva de medición: un sistema debe juzgarse frente a propiedades y condiciones de ensayo definidas, no solo por afirmaciones destacadas.
Por tanto, una licitación sólida debería exigir una matriz de aceptación adaptada al sitio que cubra:
- el tipo de blanco,
- la ruta o el sector,
- la hora del día,
- la condición del clutter de fondo,
- las fuentes previstas de falsas alarmas,
- el tiempo hasta la primera detección,
- el tiempo hasta la primera verificación,
- y el resultado de cierre o escalada.
Esto cambia la conversación de compra de forma importante. En lugar de preguntar «¿cuál es su alcance máximo?», la licitación pregunta: «¿en qué condiciones puede el operador verificar este escenario en este sitio, y cómo lo demostraremos durante la aceptación?».
Esa es una base mucho mejor para comparar ofertas.
Las métricas de verificación deben ser explícitas
Una licitación no necesita convertirse en un plan de ensayo académico, pero sí debe usar un lenguaje de desempeño medible.
Las métricas de verificación útiles suelen incluir:
- el tiempo desde la alerta hasta la primera vista de verificación,
- el porcentaje de alertas válidas que llegan a verificación dentro del tiempo requerido,
- la tasa de cierre de falsas alarmas,
- el porcentaje de escenarios en los que el sensor de verificación adecuado se orienta automáticamente hacia el blanco,
- y la completitud de la evidencia al cierre: imágenes, ubicación e historial del evento.
Estas métricas suelen ser más útiles que el número bruto de alertas. Un sistema que genera muchas alarmas puede seguir fallando si la verificación tarda demasiado o si los operadores tienen que reconstruir el contexto manualmente cada vez. En cambio, un sistema con un desempeño de detección moderado puede aportar más valor operativo si verifica con rapidez y limpieza.
La licitación también debería preguntar cómo se presenta la calidad al operador. Por ejemplo:
- ¿La plataforma muestra la antigüedad de la alerta?
- ¿Indica si el sensor de verificación ya está apuntando al blanco?
- ¿Expone la incertidumbre o el nivel de confianza, en lugar de presentar cada evento como igualmente sólido?
Estos detalles influyen directamente en la calidad de la respuesta.
Las buenas licitaciones separan las obligaciones de detección, clasificación y verificación
Otro error recurrente es agrupar varios requisitos distintos en una sola frase.
Por ejemplo, «el sistema deberá detectar e identificar drones a larga distancia» puede sonar contundente, pero es un mal lenguaje de licitación si no especifica:
- qué blancos son cooperativos y cuáles no cooperativos,
- si «identificar» significa identidad de protocolo, reconocimiento visual o juicio del operador,
- si el sistema debe buscar por sí solo o puede apoyarse en una indicación previa,
- y qué evidencia se exige para la aceptación.
La guía del DHS sobre contramedidas contra drones es útil aquí porque separa funciones como detección, seguimiento, identificación y monitorización. Las licitaciones de seguridad civil deberían hacer lo mismo. Un radar puede cumplir la primera detección; una capa de RF puede aportar conciencia de las señales cooperativas o no cooperativas; el sensor EO puede cumplir la verificación visual. La licitación debe conservar esas distinciones, en lugar de obligar a cada proveedor a reducirlas a un solo verbo comercial.
Esa separación ayuda al comprador de dos maneras:
- facilita una comparación justa de las propuestas,
- y evita que un subsistema fuerte en una función se confunda con una capacidad integral de extremo a extremo.
La licitación debe preguntar cómo falla la verificación
Los buenos documentos de compra no solo preguntan cómo funciona el sistema. También preguntan dónde deja de funcionar bien.
Los modos de fallo de la verificación suelen incluir:
- una línea de visión deficiente en algún sector,
- bajo contraste o deslumbramiento,
- estructuras de cubierta muy recargadas,
- poco tiempo de aviso ante una aproximación desde arriba,
- poca precisión de la indicación procedente del sensor anterior,
- y abundante tráfico molesto que compite por la atención del operador.
Si un oferente no sabe explicar estos límites con claridad, es probable que el comprador no esté recibiendo un plan de verificación honesto. Una propuesta madura debería poder indicar:
- en qué puntos la verificación depende de la calidad de la indicación,
- qué sectores necesitan un campo de visión estrecho o posiciones preconfiguradas alternativas,
- dónde se sigue esperando intervención manual del operador,
- y qué condiciones deben incluirse en la aceptación en el sitio.
Esa honestidad no es una debilidad: es exactamente lo que permite que la licitación se convierta en un programa viable de despliegue y aceptación.
Errores frecuentes en las licitaciones
Varios errores de redacción producen de forma sistemática resultados de compra débiles.
Lenguaje centrado solo en el alcance
La licitación pide la distancia máxima de detección, pero nunca establece qué debe verificarse en la operación.
Supuestos heterogéneos sobre el blanco
El documento compara afirmaciones obtenidas con tamaños de blanco, perfiles de movimiento o sectores distintos como si fueran equivalentes.
Sin requisito de flujo de trabajo
La licitación especifica sensores, pero no la cola de eventos, el empaquetado de evidencias ni el traspaso al operador.
Sin matriz de aceptación
El comprador deja la verificación en una demostración genérica, en lugar de una prueba en el sitio basada en escenarios.
Sin lógica de cierre
Nunca se exige al sistema mostrar cómo se resuelven los eventos sin relevancia, las pistas obsoletas y las indicaciones inciertas.
Estos errores no solo debilitan el documento: premian activamente las ofertas vagas.
Conclusión
Una buena licitación de seguridad civil debería preguntar por la verificación, porque ahí es donde la detección se convierte en apoyo a la decisión. La detección sigue siendo importante, pero un proyecto capaz de generar alarmas sin verificar suele crear fricción operativa, no confianza operativa.
La regla práctica es simple: defina el blanco, la zona, la pregunta de decisión, la cadena de verificación y la prueba de aceptación. Si un oferente solo puede aportar cifras de detección sin mostrar cómo se verificarán los eventos reales en el sitio, la licitación sigue estando infradefinida y la propuesta sigue siendo demasiado fácil de malinterpretar.
Lecturas relacionadas
- Guía de integración radar + EO + RF
- Cómo convertir alertas de sensores en colas para operadores
- Cómo cambian los criterios DRI la selección de sistemas EO/IR
Lecturas adicionales
- Verificaciones ISPS de los sistemas de seguridad de los buques y las instalaciones portuarias (Ministerio de Transportes) - Ejemplo oficial español de cómo la administración verifica que un sistema de protección funciona, no solo que existe.
- Guía de documentación técnica para sistemas de IA (AESIA) - Qué documentación técnica exigir a un proveedor para poder auditar y verificar el sistema.
¿Necesita un radar antidrones para su instalación?
Los radares de vigilancia de baja cota de la serie CR detectan drones de RCS 0,01 m² a 3–10 km y clasifican los blancos por micro-Doppler: cada trayectoria se entrega con su clase y nivel de confianza.