A drone-detection RFI or RFP should translate the approved threat model, site basis and operating workflow into measurable supplier responses. It should not ask vendors to interpret an undefined mission or rely on brochure terms such as “360-degree detection,” “AI classification” or “camera linkage.” Every mandatory claim needs a response field, evidence source, responsible party and acceptance method. Use the parent Guía de Adquisición de Radar para Detección de Drones y Vigilancia a Baja Altitud to approve the threat model, sensor architecture and site basis before issuing this document.

Cómo Escribir un RFI/RFP para un Sistema de Radar de Detección de Drones
1. Congele la base de adquisiciones antes de emitir el RFP
- Activos protegidos, zonas de vigilancia y corredores de aproximación prohibidos.
- Clases de objetivo, dimensiones o suposiciones RCS, velocidad, altitud y rutas representativas.
- Tiempo de advertencia requerido, decisión del operador y flujo de trabajo de respuesta.
- Roles de sensores aprobados, interfaces externas de la plataforma y límite de ciberseguridad.
- Base de la encuesta del sitio, ubicaciones propuestas, supuestos de zona ciega y responsabilidad de la infraestructura.
- Etapas de aceptación en fábrica, en el campo y en el sitio, y los datos que deben conservarse.
Si estos elementos no se aprueban, la RFP recopilará soluciones incompatibles en lugar de respuestas comparables. Resuelva primero la línea base, luego permita que los proveedores propongan alternativas conformes con las desviaciones claramente identificadas.
2. Definir Evidencia Obligatoria y Entregables
La RFP debe indicar qué evidencia y documentos de entrega debe presentar cada respondedor. El propósito no es clasificar a los proveedores dentro de esta guía; es evitar que afirmaciones vagas se conviertan en suposiciones contractuales no comprobadas.
| Categoría de evidencia requerida |
Envío obligatorio RFP |
| Evidencia de implementación comparable |
Proyectos de referencia con objetivos, entorno, arquitectura y escala similares; datos de contacto solo donde se permita su divulgación. |
| Evidencia de desempeño |
Informes de prueba que indiquen el método de medición, la configuración, la definición del objetivo, las condiciones de operación, la disponibilidad de los datos en bruto y las limitaciones. |
| Entregables de ingeniería |
Modelo de cobertura, diseño de interfaz, planos de instalación, método de puesta en marcha, plan de calibración y responsabilidad de solución de problemas. |
| Paquete de interfaz |
Documentos controlados, mensajes de muestra, definiciones de campo, herramientas de prueba, versiones soportadas, proceso de control de cambios y propietario de integración nombrado. |
| Documentos de calidad y cumplimiento |
Solo documentos de calidad, ambientales, EMC, radio, seguridad y acceso al mercado aplicables al destino para la configuración ofrecida. |
| Entregables de ciberseguridad |
Límite de arquitectura, modelo de control de acceso, política de parches, informe de vulnerabilidades, registro, reglas de acceso remoto y gobernanza de actualizaciones. |
| Entregables de soporte |
Tiempos de respuesta, diagnóstico remoto, condiciones en el sitio, plan de repuestos, plan de capacitación, ruta de escalamiento y política de aviso de fin de vida útil. |
| Declaración de soporte del ciclo de vida |
Período de soporte del software, política de compatibilidad, licencias obligatorias, ruta de actualización, necesidades de calibración y período de disponibilidad de piezas. |
| Declaración de divulgación comercial |
Elementos incluidos, exclusiones, supuestos, dependencias, cargos recurrentes, responsabilidades del comprador, reglas de cambio y hitos vinculados a la aceptación. |
No acepte declaraciones genéricas como “desplegado en todo el mundo”, “precisión de IA superior al 95%” o “casi cero falsas alarmas” como respuestas suficientes. Exija las clases objetivo, el conjunto de datos o la base de prueba de campo, el entorno, la configuración del sistema, el umbral de confianza, las limitaciones y el propietario del documento nombrado. Los requisitos de evidencia deben ser idénticos para todos los encuestados y deben convertirse en parte del contrato técnico cuando sea relevante.
3. Exigir un cronograma de cumplimiento requisito por requisito
Cada requisito debe tener un identificador único y campos para el estado de cumplimiento, valor ofrecido, condición o limitación, documento de evidencia, revisión del documento, organización responsable y método de aceptación propuesto. No combine varios requisitos técnicos en una sola línea de sí/no, porque una respuesta parcial se vuelve imposible de evaluar.
| Campo |
Entrada de proveedor requerida |
| ID de requisito |
Referencia controlada por el comprador, sin cambios en todas las respuestas |
| Cumplimiento |
Cumplir / Desviación / Alternativa opcional / No ofrecido |
| Valor ofrecido |
Respuesta numérica o medible; evitar lenguaje de marketing |
| Condiciones |
Objetivo, entorno, configuración, suposiciones sobre la licencia o la infraestructura |
| Evidencia |
Ficha técnica, dibujo, documento de interfaz, informe de prueba o demostración controlada |
| Responsabilidad |
Proveedor, comprador, tercero o responsabilidad compartida |
| Método de aceptación |
Revisión de documentos, FAT, prueba de campo, SAT u observación operativa |

Cómo Escribir un RFI/RFP para un Sistema de Radar de Detección de Drones
4. Separar la Capacidad del Producto de la Entrega del Proyecto
Una hoja de datos del producto puede respaldar una respuesta, pero no define el proyecto completo. La RFP debería solicitar por separado la radar sensor, servidor y software, licencias, EO/IR integration, interfaces externas, ingeniería del sitio, mástiles y obras civiles, cableado, puesta en marcha, capacitación, documentación, repuestos, garantía y soporte. Esto evita que un precio bajo del equipo se confunda con un sistema operativo completo.
5. Definir el Programa de Divulgación Comercial
La RFP debe requerir un cronograma de divulgación completo para que las cotizaciones posteriores puedan normalizarse sin adivinar lo que se incluye. El cronograma debe identificar equipos, infraestructura, ingeniería, integración, despliegue, servicios recurrentes, mantenimiento, supuestos, exclusiones y responsabilidades del comprador.
| Grupo de Divulgación |
Información que todo proveedor debe declarar |
| Equipo |
Radar, RF, EO/IR, servidores, almacenamiento, dispositivos de red, estaciones de trabajo de operador, accesorios y repuestos; identificar cantidad y configuración. |
| Infraestructura |
Mástiles, cimientos, refugios, energía, UPS, puesta a tierra, protección contra rayos, fibra, enlaces inalámbricos y límites de obra civil. |
| Ingeniería |
Responsabilidades de levantamiento topográfico, diseño, modelado de cobertura, dibujos, revisión de ciberseguridad, gestión de proyectos y revisión de documentos. |
| Integración |
Controladores, trabajo API, interfaces VMS/PSIM/C2, conversión de coordenadas, entorno de prueba, pruebas, documentación y dependencias de terceros. |
| Despliegue |
Flete, seguro, aduanas, instalación, puesta en marcha, calibración, apoyo en la aceptación y responsabilidades en el país de destino. |
| Servicios recurrentes |
Licencias, conectividad, servicios en la nube o de monitoreo, retención de datos, soporte de software obligatorio y condiciones de renovación. |
| Mantenimiento y soporte |
Servicio preventivo, calibración, repuestos, logística de reparación, actualizaciones de software, soporte remoto y condiciones de servicio en sitio. |
| Supuestos y exclusiones |
Equipos suministrados por el comprador, condiciones del sitio, sensores adicionales, mástiles más altos, reubicación, modificaciones de terceros, retesting y reglas de control de cambios. |
Esta guía no calcula ni clasifica el costo del ciclo de vida. Solo define la información que cada proveedor debe divulgar. El mantenimiento específico de la arquitectura, la redundancia, las piezas de repuesto, la región de soporte, la consecuencia de tiempo de inactividad y las obligaciones de software deben indicarse con supuestos y evidencia; el guía de comparación de citas separadas debería entonces evaluar esas divulgaciones en una base comparable.
6. Programa mínimo de respuesta RFI/RFP
Exija que cada respondedor complete el mismo cronograma. Una respuesta en blanco, “TBD” o “soportado” sigue siendo un requisito no resuelto hasta que se suministre una declaración medible, fuente de evidencia y parte responsable. El cronograma completado crea la línea base común que luego se utiliza para la comparación de cotizaciones.
| Grupo de requisitos |
Respuesta Obligatoria del Proveedor |
| Alcance operativo |
Solo detección, DTI o límite integrado C-UAS; funciones incluidas y excluidas |
| Objetivos |
Objetivos de referencia, perfiles de vuelo, velocidades, altitudes y condiciones de rendimiento |
| Rendimiento del radar |
Detección, inicio de seguimiento, seguimiento estable, cobertura, actualización, precisión, capacidad y clasificación |
| Arquitectura del sensor |
Radar, RF, EO/IR, datos cooperativos y roles de fusión |
| Diseño de cobertura |
Cantidad de sensores, posiciones, alturas, zonas ciegas, superposición y suposiciones |
| Integración |
Interfaces, formatos, sistemas de coordenadas, sincronización de tiempo, camera cueing, health and logs |
| Ciberseguridad |
Control de acceso, cifrado, segmentación, aplicación de parches, auditoría y soporte remoto |
| Infraestructura |
Mástiles, obras civiles, energía, red, puesta a tierra, refugios y protección ambiental |
| Pruebas |
Métodos, objetivos, datos, umbrales y reglas de reexamen para la aceptación en fábrica, en campo y en sitio |
| Soporte |
Capacitación, garantía, SLA, diagnósticos, repuestos, soporte de software y política de fin de vida |
| Comercial |
Cronograma de precios desglosado, artículos incluidos, cargos recurrentes, supuestos, exclusiones, responsabilidades del comprador, cronograma de entrega, hitos de pago y reglas de control de cambios; sin puntuación ponderada en esta guía. |
| Cumplimiento |
Responsabilidades específicas del destino en radio, EMC, seguridad, aviación, importación/exportación y documentación |
7. Desviaciones del control, supuestos y alternativas opcionales
Se requiere que cada desviación identifique el requisito afectado, la consecuencia operativa, la alternativa propuesta, el efecto en el precio y la implicación de aceptación. Las suposiciones deben consolidarse en un solo registro en lugar de estar dispersas a lo largo de la propuesta. Las alternativas opcionales deben valorarse por separado y no deben utilizarse para encubrir el incumplimiento de un requisito obligatorio.
8. Adjunte los documentos que regirán la entrega
- Especificación técnica aprobada y documento base del sitio.
- Dibujo de cobertura y declaración de riesgo residual.
- Documento de control de interfaz y matriz de responsabilidades.
- Evidencia y cronograma de presentación.
- Factory, planes de prueba de campo y de aceptación en el sitio.
- Inclusiones comerciales, exclusiones, cargos recurrentes y hitos de entrega.
- Garantía, soporte, actualización de software y obligaciones de fin de vida.

Cómo Escribir un RFI/RFP para un Sistema de Radar de Detección de Drones
9. Definir el flujo de trabajo de evaluación y aclaración
Después de la recepción, revise cada respuesta en tres fases. Primero, identifique el incumplimiento obligatorio y la evidencia faltante. Segundo, emita un registro de aclaración controlado que preserve el ID del requisito original y registre la respuesta del proveedor, el impacto y el estado de cierre. Tercero, separe el alcance base conforme de las ventajas opcionales antes de la evaluación de precios. Esto evita que una oferta técnicamente incompleta aparezca competitiva porque es más barata o tiene mayor promoción.
Las aclaraciones que cambien el alcance ofrecido, la condición de desempeño, la responsabilidad o el precio deben incorporarse en la propuesta final y en el anexo del contrato. Las explicaciones por correo electrónico que no se transfieran a la oferta controlada no deben considerarse compromisos de entrega vinculantes.
Modos de fallo comunes de RFP
- Usando un rango máximo de detección sin un objetivo y condición de operación.
- Tratando la disponibilidad de API como integración completada.
- Aceptar un porcentaje de precisión de IA sin conjunto de datos, umbral y limitaciones.
- Dejar mástiles, obras civiles, servidores, licencias o puesta en marcha fuera del calendario de respuesta.
- Definiendo la aceptación solo después de la adjudicación del contrato.
- Permitir que los proveedores respondan en diferentes formatos que no se pueden normalizar.
10. Gobernar la Línea Base Controlada RFP
Asigne un propietario a cada requisito, interfaz y calendario de evidencia. Emita una línea base controlada a todos los encuestados, registre cada aclaración e identifique si cada respuesta cambia el cumplimiento, el precio, la entrega o la aceptación. Antes de la adjudicación, incorpore las aclaraciones y desviaciones aceptadas en el calendario técnico final, de modo que la oferta evaluada y el contrato describan el mismo sistema.
Conclusión
Un RFP de detección de drones defendible es un sistema de respuesta controlado. Da a cada proveedor los mismos ID de requisitos, expectativas de evidencia, campos de responsabilidad, divulgaciones comerciales y métodos de aceptación. Una vez recibidas las respuestas conformes, el comprador puede pasar a la etapa de comparación de cotizaciones por separado sin reconstruir lo que cada propuesta incluye realmente.
Preguntas frecuentes
¿Debería la RFP especificar un modelo de radar preferido?
Por lo general, no. Especifique primero el resultado operativo requerido, el objetivo establecido, las interfaces y los criterios de aceptación. Un modelo solo puede nombrarse cuando la compatibilidad, la estandarización o un diseño aprobado lo requieren.
¿Qué evidencia es más sólida que una afirmación de un folleto?
Un informe de prueba controlado, un documento de interfaz, un dibujo de cobertura, un extracto de datos en bruto o una demostración en vivo vinculado a la configuración propuesta y las condiciones de operación indicadas.
¿Cuándo se deben divulgar las exclusiones comerciales?
En la respuesta controlada inicial. Las exclusiones descubiertas durante la negociación o la instalación crean riesgo de orden de cambio y de calendario evitables.
¿Debería la respuesta del proveedor convertirse en parte del contrato?
Las respuestas técnicas de material, los dibujos, supuestos, desviaciones, entregables y compromisos de aceptación deben incorporarse al contrato o a sus anexos controlados.