Programa ONA — Integración de sistemas, SUPGOD y arquitectura operacional para ver, entender, decidir y actuar mejor

Luego de una primera entrevista con Gustavo Fauez, CEO y presidente de Roca Defense & Systems, volvimos a conversar con él sobre cómo se realiza la integración de sistemas tal como la plantean en el Programa ONA.

Pucará Defensa: El programa ONA plantea la integración de una gran cantidad de sistemas del operador. ¿Cómo está concebido para integrar aquellas plataformas que el operador ya tiene?

Gustavo Fauez: Las Armadas, fuerzas de seguridad, agencias marítimas y organismos estatales ya cuentan con medios propios, con distintos grados de modernización, diferentes orígenes tecnológicos y procedimientos consolidados. Pueden existir patrulleros oceánicos, aeronaves, radares costeros, centros de mando, sensores embarcados, sistemas de comunicaciones, fuentes satelitales, sistemas de monitoreo marítimo, plataformas no tripuladas y capacidades de inteligencia ya instaladas.

Por eso, ONA no está pensado como una arquitectura que llega a reemplazar lo existente, sino como una arquitectura que busca ordenar, integrar y potenciar lo que el operador ya tiene.

El enfoque es modular, progresivo y no invasivo. Primero se comprende el ecosistema operativo del usuario: qué medios tiene, cómo los utiliza, qué información producen, qué restricciones existen, qué niveles de acceso son posibles y cuáles son las prioridades operacionales. A partir de ahí, ONA puede incorporarse como una capa adicional de persistencia, vigilancia, despliegue no tripulado e inteligencia operacional.

En defensa, muchas veces el problema no es la ausencia absoluta de medios, sino la falta de integración efectiva entre esos medios. Un sensor detecta, una unidad observa, un centro de mando analiza, una plataforma patrulla, pero si esos elementos no están suficientemente conectados, el operador termina con fragmentos de información en lugar de una imagen operacional coherente.

ONA busca precisamente resolver esa brecha: conectar capacidades existentes con nuevas capas no tripuladas y con SUPGOD como plataforma de inteligencia operacional, para que el sistema completo funcione de manera más coordinada, más persistente y más eficiente.

La idea central es simple: no obligar al operador a reconstruir su ecosistema, sino darle una arquitectura capaz de multiplicar el valor de sus medios actuales.

PD: ¿Cómo se lleva adelante la integración de dichos sistemas? Especialmente cuando son tecnologías de orígenes distintos, para que se comuniquen entre sí.

GF: La integración se lleva adelante por etapas, porque en defensa la interoperabilidad no se resuelve con una única solución técnica ni con una promesa genérica. Se resuelve entendiendo el entorno real del operador.

La primera etapa es de relevamiento operacional y técnico. Se analiza qué sistemas existen, qué tipo de información generan, cuáles pueden compartir datos, bajo qué condiciones de seguridad, con qué restricciones institucionales y qué nivel de integración es conveniente en cada fase.

La segunda etapa consiste en definir una matriz de integración. No todos los sistemas necesitan integrarse de la misma manera ni con la misma profundidad. Algunos pueden aportar datos de forma directa, otros pueden hacerlo mediante interfaces intermedias, otros pueden integrarse mediante reportes estructurados, y en algunos casos la integración puede comenzar de manera semiautomatizada antes de avanzar hacia niveles mayores de interoperabilidad.

La tercera etapa es la normalización de la información. En un entorno real, las tecnologías no siempre hablan el mismo idioma. Pueden venir de distintos fabricantes, distintos países, distintas generaciones tecnológicas o distintos marcos de adquisición. El objetivo no es forzar artificialmente que todos los sistemas sean iguales, sino construir capas de traducción, adaptación y correlación que permitan que esa información sea utilizable dentro de una lógica común de misión.

Un ejemplo concreto de esta lógica es la incorporación de capacidades especializadas de búsqueda y rescate dentro de la arquitectura ONA/SUPGOD. En ese tipo de casos, ONA no necesita absorber ni reemplazar una solución externa, sino permitir que esa capacidad pueda integrarse como módulo funcional dentro de una arquitectura operacional más amplia.

Esto permite que información proveniente de soluciones especializadas —por ejemplo, en búsqueda, rescate, georreferenciación, análisis de zonas de interés o apoyo a la coordinación de respuesta— pueda ser aprovechada dentro de un marco común de misión, siempre bajo los criterios de seguridad, autorización y control definidos por el operador.

Para nosotros, ese es el sentido correcto de la interoperabilidad: no convertir a ONA en un sistema cerrado, sino en una arquitectura capaz de integrar capacidades propias y de terceros sin perder coherencia operacional.

La cuarta etapa es la validación operacional. En defensa no alcanza con que un dato llegue técnicamente al sistema. Hay que comprobar que sea útil, confiable, oportuno y accionable para el operador. La integración tiene que servir para mejorar la decisión, no para llenar una pantalla de información sin jerarquía.

Finalmente, cada integración debe respetar los criterios de seguridad, doctrina y soberanía del usuario institucional. La arquitectura puede ser flexible, pero la autoridad sobre qué se conecta, qué se comparte y qué grado de automatización se permite siempre debe permanecer en manos del operador.

La interoperabilidad, bien entendida, no consiste en imponer una plataforma cerrada. Consiste en permitir que medios diversos puedan contribuir a una imagen operacional común, sin comprometer la seguridad ni la autonomía decisional del usuario.

PD: ¿Cuál es el rol de la plataforma SUPGOD en esta integración?

GF: SUPGOD cumple el rol de capa de inteligencia operacional dentro de la arquitectura ONA.

No debe entenderse simplemente como un visualizador de datos ni como una plataforma que acumula información sin criterio. Su función es integrar, contextualizar, correlacionar y ayudar a priorizar eventos dentro de una lógica de misión.

En un escenario marítimo, el operador puede recibir información desde múltiples fuentes: sensores costeros, patrulleros, aeronaves, satélites, drones, sistemas de identificación, reportes operativos, fuentes abiertas o medios no tripulados desplegados en zona. El desafío no es solamente recibir esos datos, sino convertirlos en una lectura útil del entorno.

Ahí es donde entra SUPGOD. Su propósito es reducir la fragmentación, ordenar la información y apoyar al operador en la construcción de una imagen operacional más clara. No reemplaza al comandante ni sustituye la responsabilidad humana. Actúa como una capa de apoyo a la decisión, ayudando a identificar patrones, priorizar alertas, correlacionar eventos y sugerir posibles cursos de acción dentro de los parámetros definidos por el usuario.

Un punto central en nuestra visión es el concepto de Machine Learning soberano. Roca Defense aporta la arquitectura base, la lógica de integración, la capa cognitiva inicial y las herramientas de explotación operacional. Pero el aprendizaje más sensible del sistema debe pertenecer al usuario institucional, no al proveedor tecnológico.

Esto es fundamental en defensa. Los datos operacionales no son solamente datos: son patrones de despliegue, criterios de reacción, hábitos institucionales, prioridades doctrinales, zonas de interés, tiempos de respuesta, comportamiento de unidades y memoria operacional acumulada. Ese conocimiento no puede quedar cautivo de una caja negra externa.

Por eso SUPGOD está concebido para permitir que cada usuario pueda construir, alimentar, validar y resguardar su propia capa de aprendizaje operacional conforme a su doctrina, sus reglas, sus niveles de clasificación y sus criterios de ciberdefensa.

Dicho de manera simple: Roca Defense aporta el framework y la arquitectura; la memoria operacional sensible debe quedar bajo control soberano del usuario.

PD: ¿Qué ventajas tiene frente a otras plataformas de fusión de datos?

GF: La principal diferencia es que SUPGOD no está pensado únicamente como una plataforma de fusión de datos, sino como una arquitectura de inteligencia operacional.

Fusionar datos es importante, pero no suficiente. Muchas soluciones pueden reunir información de distintas fuentes en una pantalla común. El verdadero desafío es transformar esa información en criterio de misión: qué está ocurriendo, qué nivel de prioridad tiene, qué medios están disponibles, qué riesgo existe, qué requiere validación humana y qué cursos de acción son posibles.

SUPGOD busca ir más allá de la visualización. Su valor está en la correlación, la priorización, la reducción de ruido operativo y la capacidad de adaptar la lectura del sistema a la doctrina del usuario.

Otra ventaja relevante es su enfoque modular. No está concebido para obligar al operador a reemplazar todo su ecosistema tecnológico. Está pensado para integrarse de manera gradual con los medios existentes, sumar nuevas capas donde haya vacíos operacionales y permitir que el usuario avance por etapas, de acuerdo con sus prioridades, presupuesto, infraestructura y niveles de seguridad.

También hay una diferencia doctrinal importante: la idea de Machine Learning soberano. Un sistema cognitivo aplicado a defensa no puede convertirse en una arquitectura donde el proveedor externo sea dueño de la memoria operacional del cliente. En nuestro enfoque, la capa tecnológica puede ser provista, configurada y acompañada por Roca Defense, pero el aprendizaje sensible, la validación doctrinal y la explotación de los datos críticos deben quedar bajo control del usuario institucional.

Esto tiene una dimensión técnica, pero también una dimensión estratégica y de ciberdefensa. Un país o una fuerza no solo necesita integrar sensores; necesita preservar control sobre sus datos, sus patrones, sus reglas y su capacidad de decisión.

En ese sentido, SUPGOD se diferencia porque no busca simplemente concentrar información, sino permitir que el operador construya una ventaja operacional propia a partir de sus medios, su doctrina y su conocimiento acumulado.

PD: ¿Cómo mejora la conciencia situacional del operador al poder integrar la información de sus sensores?

GF: La conciencia situacional mejora cuando el operador deja de ver eventos aislados y comienza a ver relaciones.

Un radar puede mostrar un contacto. Un satélite puede detectar actividad en una zona. Un dron puede aportar confirmación visual. Una patrulla puede validar presencia. Un sistema marítimo puede aportar historial de navegación. Un centro de mando puede tener información previa sobre una conducta sospechosa. Pero si todo eso aparece separado, el operador tiene que reconstruir manualmente el contexto.

La integración permite acortar la distancia entre detección, interpretación y decisión.

SUPGOD ayuda a ordenar esas señales, cruzarlas y presentarlas con mayor sentido operacional. No se trata solamente de ver más datos, sino de entender mejor qué significan esos datos. En defensa, más información no siempre equivale a mejor decisión; muchas veces significa más ruido. La clave está en filtrar, jerarquizar y contextualizar.

Por ejemplo, una detección aislada puede no parecer crítica. Pero si esa detección se vincula con una ruta anómala, una zona sensible, una imagen satelital previa, una ausencia de identificación, una condición ambiental específica o una alerta generada por otro medio, el nivel de prioridad cambia.

Esa es la diferencia entre vigilancia fragmentada y conciencia situacional integrada.

Para el operador, esto se traduce en mayor claridad sobre qué está ocurriendo, dónde está ocurriendo, con qué nivel de urgencia, qué medios pueden intervenir y qué decisión requiere validación humana. El resultado es una operación más informada, más rápida y con menor carga cognitiva.

En dominios marítimos extensos, esa mejora es crítica. No hay forma eficiente de controlar grandes espacios si cada sensor funciona como una isla. La ventaja aparece cuando los sensores, las plataformas y los centros de decisión empiezan a trabajar como parte de una arquitectura común.

PD: ¿Cómo es la presentación de la información para los operadores?

GF: La presentación de la información debe responder al rol de cada usuario dentro del sistema.

Un centro de mando no necesita la misma visualización que una unidad patrullando. Un comandante operativo no necesita exactamente lo mismo que un operador de drones. Una autoridad superior puede requerir indicadores estratégicos, mientras que una unidad táctica necesita información concreta, filtrada y accionable.

Por eso la lógica de presentación debe ser diferenciada. El objetivo no es mostrar todo a todos, sino entregar la información correcta, al actor correcto, en el momento correcto.

En un nivel estratégico, el sistema puede presentar situación general, zonas de interés, evolución temporal, prioridades operacionales, medios disponibles, alertas relevantes e indicadores de riesgo.

En un nivel operacional, puede mostrar eventos priorizados, correlaciones, disponibilidad de plataformas, recomendaciones de verificación, áreas de patrulla, rutas sugeridas o evolución de una situación determinada.

En un nivel táctico, la información debe ser más directa: qué ocurre, dónde ocurre, qué prioridad tiene, qué medio está asignado, qué restricciones existen y qué acción requiere autorización o ejecución.

Esto es importante porque uno de los grandes problemas de los sistemas modernos es la saturación de información. Una pantalla cargada de datos no necesariamente mejora la decisión. A veces la empeora.

La arquitectura ONA/SUPGOD busca evitar esa sobrecarga. La información debe presentarse de manera clara, jerarquizada y orientada a misión. La finalidad no es impresionar visualmente al operador, sino ayudarlo a decidir mejor.

En defensa, una buena interfaz no es la que muestra más cosas. Es la que reduce incertidumbre, elimina ruido y permite actuar con mayor precisión.

PD: ¿Cómo interactúa ONA con las distintas plataformas de los operadores? En cuanto a la recepción de información y el envío de feedback para que las plataformas actúen.

GF: La interacción de ONA con las plataformas del operador debe entenderse como un ciclo de información, validación y coordinación operacional.

En primer lugar, ONA puede recibir información de distintas fuentes autorizadas dentro del ecosistema del usuario. Esa información puede provenir de sensores, plataformas tripuladas, sistemas no tripulados, centros de mando, medios satelitales u otros sistemas disponibles. El nivel de integración dependerá siempre de lo que el operador autorice y de lo que sea técnicamente, doctrinalmente y jurídicamente viable.

En segundo lugar, SUPGOD procesa y contextualiza esa información dentro de una lógica de misión. Esto no significa que el sistema sustituya al mando humano, sino que ayuda a ordenar el entorno, identificar prioridades y generar insumos útiles para la toma de decisiones.

En tercer lugar, el operador humano valida. Este punto es central. En operaciones sensibles, la decisión de actuar, escalar, desplegar, interceptar, verificar o responder debe permanecer dentro del marco de autoridad definido por el usuario institucional.

En cuarto lugar, la arquitectura puede generar feedback hacia las plataformas integradas. Ese feedback puede adoptar distintos niveles según el grado de integración aprobado: alertas, solicitudes de verificación, recomendaciones de patrulla, asignación de áreas de interés, actualización de situación, coordinación con sistemas no tripulados o apoyo a la planificación de misión.

Es importante aclarar que ONA no debe entenderse como una arquitectura que toma control indiscriminado de medios externos. Su propósito es permitir que la información circule mejor, que las decisiones se tomen con mayor claridad y que las plataformas actúen de manera más coordinada bajo reglas definidas por el operador.

La lógica es pasar de plataformas aisladas a una arquitectura de misión. Cada medio conserva su función, su cadena de mando y sus restricciones, pero aporta y recibe información dentro de un sistema más amplio.

En ese sentido, ONA puede actuar como nodo avanzado, como plataforma de persistencia, como punto de despliegue no tripulado y como parte de una red de vigilancia y respuesta. SUPGOD, por su parte, permite que esa red no sea simplemente una acumulación de sensores, sino una arquitectura de inteligencia operacional.

La diferencia es sustancial: no se trata solo de conectar máquinas, sino de coordinar capacidades al servicio de una decisión humana mejor informada.

La tesis central de ONA es que la ventaja en defensa ya no depende únicamente de poseer más plataformas, sino de lograr que sensores, sistemas no tripulados, medios tripulados, centros de mando e inteligencia operacional funcionen como una sola arquitectura.

Para América Latina, esto es especialmente relevante. La región enfrenta enormes espacios marítimos, recursos estratégicos, presupuestos limitados y ecosistemas tecnológicos heterogéneos. Pretender resolver ese desafío únicamente con más plataformas sería insuficiente y, en muchos casos, económicamente inviable.

ONA propone otro camino: integrar mejor lo existente, sumar persistencia no tripulada, incorporar inteligencia operacional, preservar el control humano y permitir que cada usuario institucional mantenga soberanía sobre su doctrina, sus datos y su aprendizaje operativo.

El objetivo no es reemplazar al operador. El objetivo es darle más capacidad de ver, entender, decidir y actuar.