Qué debería pedir una buena licitación de seguridad civil sobre la verificación, no solo sobre la detección

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 indica que alguna capa puede advertir la presencia de algo. No dice si el operador puede verificar el evento con suficiente rapidez para actuar, si la evidencia es utilizable o si el sistema puede 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 con 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 de manera rigurosa. 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 incorpora al requerimiento, la licitación pasa a ser un documento de ingeniería mucho más útil que una simple lista de compra.

La detección es solo el primer paso en la cadena de seguridad

La orientación gubernamental sobre sistemas de protección ha tratado desde hace tiempo la seguridad como una secuencia, no como una sola función. 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 monitoreo, 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 operativamente si el sitio no puede responder 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 el número más fácil de publicar. Eso suele producir propuestas difíciles de comparar, porque un fabricante enfatiza la primera alerta, otro la identificación y otro supone en silencio 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 tarea, no como palabra de moda

Una de las razones por las que la verificación queda mal definida es que el término se usa de forma imprecisa. En la práctica, proyectos distintos entienden cosas distintas por verificación.

La verificación puede significar:

confirmar que el evento es real y no una molestia,
confirmar la clase de objetivo, como persona, vehículo, dron pequeño o ave,
confirmar si la actividad está dentro de una zona protegida,
o generar evidencia apta para entrega, registro o revisión posterior.

Son tareas relacionadas, pero no idénticas. Una cámara que puede verificar que “hay algo presente” a cierta distancia quizá no pueda verificar la clase del objetivo ni la intención a esa misma distancia. Un radar puede verificar persistencia y patrón de movimiento, pero no identidad visual. Un evento de RF puede verificar que hay un transmisor activo, sin demostrar todavía 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 quedará sesgada incluso antes de comenzar el proyecto.

Una buena licitación define el objetivo, la zona y la pregunta de decisión

Los requisitos de verificación son mucho más útiles cuando se vinculan con tres elementos:

la clase de objetivo,
la zona protegida,
y la decisión que debe tomar el operador.

Por ejemplo, “verificar un objeto de baja altitud cerca de la línea de cubierta” es un requisito muy distinto de “verificar un vehículo que cruza una valla exterior”. El tamaño del objetivo, la geometría de aproximación, el tiempo de advertencia y la evidencia útil no son los mismos. Tampoco lo son las mejores combinaciones de sensores.

Por tanto, una licitación bien estructurada debería pedir desempeño de verificación frente a escenarios claramente definidos, por ejemplo:

persona en la línea de 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 sobrevolando el área sin converger hacia el activo protegido.

La geometría protegida importa tanto como el objetivo. Un sitio con un perímetro abierto y llano tiene necesidades de verificación distintas de las de un centro de datos con equipos en cubierta, estructuras mecánicas y preocupaciones sobre el espacio aéreo de 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 estar ligada 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 que el oferente explique la cadena de verificación:

qué genera la primera alerta,
qué evidencia se adjunta de inmediato,
qué sensor de verificación se activa primero,
cómo ve el operador la ubicación, el seguimiento y la imagen juntos,
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.

Preguntas útiles para la licitación incluyen:

¿Puede el sistema abrir el mapa, el seguimiento y la vista de verificación pertinentes desde un solo elemento de cola?
¿Cómo se muestra la asignación de responsabilidad cuando un operador toma el evento?
¿Cuál es la latencia esperada entre la creación de la alerta y la primera indicación de verificación?
¿Cómo se consolidan varias detecciones del mismo sensor en una sola tarea para el operador?
¿Qué evidencia permanece asociada después del cierre del incidente?

Estas preguntas muestran si el proveedor entrega un sistema operativo real o solo varios flujos conectados.

Exija pruebas de aceptación que demuestren verificación, no solo 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 el sistema pueda verificar de forma consistente en el sitio real.

Eso es un problema, porque la guía de evaluación autorizada distingue repetidamente 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 dice algo similar desde la perspectiva de medición: un sistema debe juzgarse frente a propiedades y condiciones de prueba definidas, no solo por afirmaciones generales.

Por tanto, una licitación sólida debería exigir una matriz de aceptación relevante para el sitio que cubra:

tipo de objetivo,
ruta o sector,
hora del día,
condición de clutter o ruido de fondo,
fuentes de molestia esperadas,
tiempo de primera detección,
tiempo de primera verificación,
y resultado de cierre o escalada.

Esto cambia de forma importante la conversación de compra. 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 probaremos 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 útiles de verificación suelen incluir:

tiempo desde la alerta hasta la primera vista de verificación,
porcentaje de alertas válidas que llegan a verificación dentro del tiempo requerido,
tasa de cierre de falsas alarmas,
porcentaje de escenarios en los que el sensor de verificación correcto se activa automáticamente,
y completitud de la evidencia al cierre, como imágenes, ubicación e historial del evento.

Estas métricas suelen ser más útiles que el simple número 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 detección moderada 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 frescura de la indicación?
¿Indica si el sensor de verificación ya está apuntando al objetivo?
¿Expone la incertidumbre o la 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 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é objetivos son cooperativos o no cooperativos,
si “identificar” significa identidad de protocolo, reconocimiento visual o juicio del operador,
si el sistema debe buscar de forma autónoma o puede depender de indicación previa,
y qué evidencia se requiere 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 monitoreo. Las licitaciones de seguridad civil deberían hacer lo mismo. Un radar puede cubrir la primera detección. Una capa de RF puede aportar conocimiento sobre señales cooperativas o no cooperativas. La optrónica puede cubrir la verificación visual. La licitación debería 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:

hace que las propuestas sean más fáciles de comparar con justicia,
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:

línea de visión deficiente en un sector,
bajo contraste o deslumbramiento,
estructuras de cubierta muy cargadas,
tiempo de advertencia corto ante una aproximación por arriba,
poca precisión de indicación del sensor aguas arriba,
y tráfico molesto intenso que compite por la atención del operador.

Si un oferente no puede explicar estos límites con claridad, probablemente el comprador no está recibiendo un plan de verificación honesto. Una propuesta madura debería poder indicar:

en qué zonas la verificación depende de la calidad de la indicación,
qué sectores necesitan un campo de visión estrecho o ajustes alternativos,
dónde todavía se espera intervención manual del operador,
y qué condiciones deben incluirse en la aceptación del sitio.

Esa honestidad no es una debilidad. Es exactamente lo que permite que la licitación se convierta en un despliegue y un programa de aceptación viables.

Errores frecuentes en las licitaciones

Varios errores de redacción producen de forma fiable resultados de compra débiles.

Lenguaje centrado solo en alcance

La licitación pide la máxima distancia de detección, pero nunca establece qué debe verificarse operativamente.

Supuestos mixtos sobre el objetivo

El documento compara afirmaciones hechas para tamaños de objetivo, 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 la entrega al operador.

Sin matriz de aceptación

El comprador deja la verificación en una demostración genérica, en lugar de someterla a una prueba de sitio basada en escenarios.

Sin lógica de cierre

Nunca se exige al sistema mostrar cómo se resuelven los eventos molestos, los seguimientos obsoletos y las indicaciones inciertas.

Estos errores no solo debilitan el documento. También 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 que solo genera alarmas y no verifica normalmente produce fricción operativa, no confianza operativa.

La regla práctica es simple. Defina el objetivo, la zona, la pregunta de decisión, la cadena de verificación y la prueba de aceptación. Si un oferente solo puede ofrecer cifras de detección sin mostrar cómo se verificarán los eventos reales en el sitio, la licitación sigue estando mal especificada y la propuesta sigue siendo demasiado fácil de interpretar mal.