El proyecto de defensa de Secern AI incorpora la programación segura en una red aislada
Secern AI ha conseguido un proyecto de defensa de 2.450 millones de wones pese a una restricción que excluye a la mayoría de las herramientas comerciales de programación con IA: el sistema no puede depender de internet. El proyecto de defensa de Secern AI integrará asistencia de programación y controles de seguridad automatizados en la red aislada de la Fuerza Aérea de la República de Corea.
El proyecto convierte un problema conocido de la IA empresarial en una exigente prueba operativa. Los desarrolladores buscan una generación, revisión y depuración de código más rápidas. Las organizaciones de defensa también deben impedir que el código fuente sensible, los documentos técnicos y el conocimiento operativo salgan de una infraestructura controlada.
Secern AI propone satisfacer ambas necesidades con IntraGenX, su plataforma local de programación con IA. El sistema combina un modelo de lenguaje de 30.000 millones de parámetros, recuperación basada en un grafo de conocimiento y análisis automatizado de seguridad del código fuente.
El contrato es más que un anuncio de despliegue. Evalúa si un proveedor nacional más pequeño puede ofrecer IA generativa útil dentro de una infraestructura donde el acceso a la nube, las API externas y la telemetría rutinaria están restringidos.
Esto enfrenta las afirmaciones de la empresa a una realidad compleja. Un aislamiento de red puede reducir la exposición externa de datos, pero no garantiza que el código generado sea correcto, seguro o apto para uso militar. La relevancia del proyecto depende de lo bien que funcionen conjuntamente sus componentes de programación e inspección bajo esas restricciones.
Lo que ofrecerá el proyecto de defensa de Secern AI
El proyecto combina la generación de código y la inspección de seguridad dentro de un entorno controlado, en lugar de tratarlas como servicios independientes en la nube.
La Fuerza Aérea de la República de Corea es el cliente del proyecto. El Instituto de Planificación y Evaluación de Tecnologías de la Información y las Comunicaciones de Corea, conocido como IITP, supervisa el programa más amplio de comercialización acelerada.
Secern AI liderará la implementación. La Fundación de Cooperación Industria-Academia de la Universidad de Sejong y el especialista en seguridad de código fuente CodeMind participarán como organizaciones ejecutoras conjuntas.
El presupuesto reportado asciende a 2.450 millones de wones. Según la cuenta del proyecto disponible, el equipo desarrollará un asistente de programación con IA y un agente automatizado de inspección de código seguro para la red de defensa de la Fuerza Aérea.
IntraGenX constituirá la capa de programación. Los desarrolladores podrán proporcionar instrucciones en lenguaje natural y recibir ayuda con el diseño lógico, la creación de código, la revisión, la detección de errores y su corrección.
CodeMind añadirá tecnología para detectar debilidades de seguridad en código recién generado o modificado. La Universidad de Sejong respaldará la investigación, el desarrollo y la validación técnica.
Esta división del trabajo es importante. Un modelo de programación puede proponer un cambio rápidamente, pero un proceso de inspección independiente debe evaluar si ese cambio vulnera los requisitos de desarrollo seguro.
La plataforma resultante pretende mantener ambas operaciones dentro del mismo entorno restringido. El código fuente no necesita llegar a un proveedor externo de modelos antes de que comience el análisis.
Secern AI también afirma que el sistema admitirá directrices de desarrollo militar, estructuras de bases de datos, documentos internos y relaciones de código existentes. Estos materiales pueden aportar un contexto que un asistente de programación de propósito general no tendría.
La empresa planea demostrar primero la tecnología en la red de la Fuerza Aérea. Después quiere examinar su posible uso en el Ejército, la Armada, el Ministerio de Defensa Nacional y organizaciones directamente afiliadas.
Esa expansión no forma parte del resultado actual. El despliegue en la Fuerza Aérea sigue siendo la prueba inmediata, mientras que una adopción más amplia en defensa es un objetivo comercial futuro.
Por tanto, el proyecto crea un punto de transición medible. IntraGenX pasa de la narrativa de producto controlada por el proveedor a un entorno de cliente con requisitos inusualmente estrictos de seguridad y disponibilidad.
El contrato no demuestra que la plataforma ya sea fiable a gran escala. Establece que Secern AI y sus socios tienen la oportunidad de validar el enfoque bajo condiciones de red de defensa.
Por qué la programación con IA en redes aisladas cambia el modelo habitual
Un despliegue en una red aislada elimina la nube como supuesto operativo y obliga a alojar el modelo, el sistema de recuperación, los controles y el proceso de evaluación en infraestructura local.
La mayoría de las experiencias populares de programación con IA dependen de inferencia remota. Un desarrollador envía indicaciones o contexto de código a una infraestructura operada por el proveedor del servicio, que devuelve sugerencias o realiza tareas agénticas.
Ese diseño ofrece actualizaciones frecuentes de modelos y acceso a grandes clústeres de computación. También puede plantear cuestiones inaceptables de manejo de datos para agencias de defensa y otras organizaciones reguladas.
Un aislamiento de red es una separación física o lógica que impide que una red protegida se comunique directamente con sistemas externos. Restringe las vías por las que puede salir información sensible.
En este proyecto, el código fuente y los datos relacionados están destinados a permanecer en servidores internos. El modelo debe funcionar sin enviar indicaciones, repositorios ni resultados generados a un punto de acceso de nube pública.
El enfoque reduce una categoría de exposición, pero introduce varios costes operativos. El cliente debe proporcionar capacidad de cómputo, distribuir actualizaciones, gestionar versiones de modelos y mantener los controles de seguridad localmente.
Las actualizaciones de modelos adquieren especial importancia. Los asistentes de programación en la nube pueden recibir correcciones y nuevas capacidades de forma continua. Un despliegue aislado necesita un proceso aprobado para importar nuevos pesos, reglas de seguridad, dependencias e información sobre vulnerabilidades.
Cada paquete importado también se convierte en una decisión de cadena de suministro. Los administradores deben establecer su origen, confirmar su integridad, analizarlo, aprobarlo y documentar su traslado al entorno protegido.
La inferencia local también limita las opciones de hardware. Secern AI describe IntraGenX como un modelo de lenguaje pequeño, o sLLM, de 30.000 millones de parámetros. El término designa un modelo situado por debajo de los mayores sistemas de propósito general, aunque 30.000 millones de parámetros siguen requiriendo recursos considerables.
El tamaño del modelo representa una disyuntiva. Un sistema desplegable localmente puede mantener los datos bajo el control del cliente, mientras que un modelo en la nube mucho mayor podría ofrecer una capacidad de programación más amplia.
Secern AI afirma que su “Loop Harness” evalúa y mejora repetidamente la salida generada. La empresa también indica que ajustó el sistema para entornos de desarrollo coreanos.
Estas afirmaciones describen el mecanismo previsto, no un rendimiento verificado de manera independiente. Los informes públicos no han proporcionado resultados de referencia sobre corrección de código, hallazgos de seguridad, velocidad de inferencia o consumo de hardware en la red de la Fuerza Aérea.
Por tanto, el despliegue deberá demostrar que el control local no reduce la utilidad por debajo de un nivel aceptable. Los desarrolladores abandonarán un asistente que responda lentamente, no comprenda el contexto del repositorio o requiera una corrección extensa.
Al mismo tiempo, los compradores del sector de defensa no pueden evaluar el éxito únicamente a través de la aceptación de sugerencias. Una alta tasa de aceptación significa poco si el código aceptado crea vulnerabilidades o infringe reglas de arquitectura.
La comparación importante no es simplemente la IA local frente a la IA en la nube. Es un flujo de trabajo de desarrollo controlado frente a un servicio externo que el cliente quizá no pueda autorizar en absoluto.
Para redes aisladas, la alternativa práctica puede seguir siendo el desarrollo manual con herramientas convencionales de búsqueda, revisión y análisis estático. IntraGenX debe superar esa base de referencia sin debilitarla.
Cómo IntraGenX conecta código, reglas y evidencia
La principal afirmación técnica de IntraGenX es que la recuperación consciente de relaciones puede proporcionar a un modelo local suficiente contexto para trabajar con una base de código interna compleja.
Un asistente de programación no puede modificar con seguridad un sistema grande considerando únicamente el archivo abierto. Necesita comprender dependencias, estructuras de bases de datos, contratos de interfaz, reglas de desarrollo y documentación relevante.
Secern AI afirma que IntraGenX utiliza generación aumentada por recuperación con grafos de conocimiento. La generación aumentada por recuperación, o RAG, proporciona información interna seleccionada a un modelo cuando prepara una respuesta.
Un grafo de conocimiento representa entidades y sus relaciones. En el desarrollo de software, esas entidades pueden incluir funciones, servicios, tablas, documentos, API, estándares y las dependencias que las conectan.
El diseño reportado analiza las relaciones entre código fuente, esquemas de bases de datos, directrices de desarrollo militar y documentos no estructurados. Después recupera contexto a partir de llamadas, referencias y dependencias.
Esto difiere de una búsqueda básica por palabras clave. Un sistema de palabras clave podría localizar todos los documentos que contienen el nombre de una API. Un sistema consciente de relaciones puede intentar mostrar qué componente llama a esa API y qué tabla de base de datos modifica.
Este contexto puede ayudar a un asistente a explicar por qué seleccionó una implementación determinada. También puede hacer que los revisores dependan menos de una respuesta que parece plausible pero carece de respaldo rastreable.
Sin embargo, la evidencia no garantiza la corrección. La capa de recuperación puede pasar por alto una relación relevante, indexar un documento obsoleto o situar una regla incorrecta por encima de una aplicable.
Los grafos de conocimiento requieren mantenimiento a medida que cambian los repositorios. Los nuevos servicios, los esquemas modificados, las funciones renombradas y los estándares militares revisados deben aparecer en el grafo antes de que el modelo pueda basarse en ellos.
El proyecto necesitará políticas claras de sincronización. Un grafo desactualizado podría ofrecer a los desarrolladores recomendaciones seguras basadas en dependencias que ya no existen.
El control de acceso plantea otro desafío. No todos los desarrolladores deberían recuperar todos los documentos solo porque todos los materiales residan en la misma red física.
La plataforma debe preservar los permisos de repositorio, los límites de proyecto y las clasificaciones de documentos durante la recuperación. De lo contrario, una indicación podría revelar información a la que el usuario no podría acceder directamente.
Las explicaciones generadas necesitan controles similares. Una respuesta puede combinar código fuente permitido con detalles recuperados de un documento más restringido, creando una divulgación indirecta dentro de la organización.
Estos problemas hacen que la identidad, la autorización y los registros de auditoría formen parte del propio asistente de programación. No son funciones administrativas independientes.
El modelo debe registrar qué fuentes influyeron en una sugerencia, qué versión la produjo y qué cambios aprobó una persona. Los revisores también necesitan una forma de reproducir resultados importantes.
La actual guía DevSecOps de NIST destaca que el material generado por IA necesita validación humana y procesos verificables. También pide rastrear modelos, modificaciones y anotaciones.
Esa guía encaja estrechamente con el proyecto de la Fuerza Aérea. Un asistente útil debe proporcionar más que código. Debe dejar evidencia que respalde la revisión técnica, el análisis de seguridad y una investigación posterior.
Los equipos que desarrollan sistemas similares pueden aplicar el mismo principio a su propia base de conocimiento de ingeniería. La calidad de la recuperación depende de material técnico gobernado, actualizado y consultable.
Para Secern AI, esta capa puede determinar si su modelo local más pequeño rinde por encima de lo que aparenta. Un mejor contexto organizativo a veces puede importar más que un conocimiento general más amplio.
El despliegue en defensa revelará si esa ventaja se mantiene en repositorios reales, documentación incompleta, límites de permisos y cambios continuos en el software.
La seguridad automatizada es la principal disyuntiva del proyecto
Combinar la programación con IA y la inspección de seguridad automatizada genera una fricción útil, pero el escáner no puede servir como prueba de que el código generado es seguro.
Los sistemas de programación generativa optimizan para ofrecer finalizaciones plausibles y cumplir tareas. El desarrollo seguro requiere comprobaciones adicionales que abarquen errores de diseño, dependencias inseguras, autorizaciones incorrectas, gestión de secretos y decisiones de implementación explotables.
El proyecto de defensa de Secern AI asigna a CodeMind la vertiente de seguridad de ese problema. Se espera que su tecnología inspeccione el código creado o modificado mediante la plataforma.
Esto crea un circuito de retroalimentación entre generación y verificación. El asistente puede proponer código, el agente de inspección puede señalar debilidades y los desarrolladores pueden revisar el resultado antes de la integración.
La arquitectura aborda una preocupación central sobre el desarrollo asistido por IA. Una generación más rápida puede aumentar la cantidad de código que requiere revisión, desplazando potencialmente un cuello de botella en lugar de eliminarlo.
La inspección automatizada puede reducir esa carga al priorizar los problemas sospechosos. También puede aplicar reglas repetibles entre equipos y proyectos.
Aun así, ningún escáner detecta todas las debilidades relevantes. El análisis estático puede encontrar patrones reconocibles, pero puede pasar por alto fallos que dependen del comportamiento del sistema, la configuración operativa o requisitos mal interpretados.
Los falsos positivos plantean otro riesgo. Si la herramienta señala repetidamente código seguro, los desarrolladores pueden desestimar sus advertencias. Si informa de muy pocos problemas, los responsables de la toma de decisiones pueden desarrollar una confianza injustificada.
El código generado por IA también crea problemas de bucles de retroalimentación. Un agente de programación podría modificar su resultado hasta satisfacer al escáner sin corregir la debilidad subyacente del diseño.
Por tanto, el proyecto debería separar las métricas de generación de los resultados de seguridad. Más líneas generadas, una finalización más rápida o una mayor aceptación de sugerencias no demuestran que el software sea más seguro.
Entre las métricas útiles estarían las tasas de aprobación de pruebas, las tasas de corrección por parte de los desarrolladores, los hallazgos de vulnerabilidades confirmadas, las tasas de falsos positivos y los defectos detectados después de la integración.
El marco de evaluación exacto no se ha detallado públicamente. Los informes disponibles no identifican umbrales de éxito, repositorios de referencia, calendarios de despliegue ni criterios de aceptación.
Esa información faltante es significativa porque el valor del contrato depende de la validación. El CEO de Secern AI, Nam Woon-sung, describió la adjudicación como una forma de validar la seguridad y la capacidad técnica de IntraGenX dentro de una red de defensa.
Sus palabras apuntan a una prueba futura, no a una prueba ya completada. La empresa ha asegurado el entorno de pruebas, pero la evidencia pública de los resultados sigue pendiente.
El marco de desarrollo seguro de NIST ofrece una referencia externa útil. Considera el desarrollo de software seguro como un conjunto integrado de prácticas, no como un análisis final realizado antes del lanzamiento.
El marco hace hincapié en proteger el software, producir versiones bien protegidas, responder a vulnerabilidades y abordar sus causas raíz. La automatización puede respaldar esas prácticas, pero no puede sustituir la gobernanza.
El mismo principio se aplica aquí. Un agente de inspección debe reforzar la revisión de código, las pruebas, la gestión de dependencias y los controles de autorización. No debe convertirse en un atajo para sortearlos.
El software de defensa también puede tener consecuencias para la misión que las aplicaciones empresariales comunes no tienen. Un error funcional puede afectar la disponibilidad, el apoyo a la toma de decisiones, la logística o las comunicaciones.
Esto eleva el estándar de supervisión humana. Las recomendaciones relacionadas con componentes críticos para la seguridad o la misión requieren la revisión de personal que comprenda el contexto operativo del sistema.
El propio modelo local también debe protegerse. Los administradores necesitan controles sobre sus pesos, prompts, índices de recuperación, configuración y paquetes de actualización.
La investigación sobre seguridad de IA de NIST destaca riesgos de confidencialidad, integridad y disponibilidad en modelos, software, hardware, datos de entrenamiento y datos de salida.
Una separación física de red aborda solo una parte de esa superficie. Siguen siendo posibles el uso indebido interno, los medios de actualización comprometidos, los documentos envenenados, los permisos excesivos y los repositorios manipulados.
La decisión de diseño más sólida del proyecto es combinar la generación con la inspección. Su mayor riesgo es que esa combinación cree una falsa impresión de seguridad automática.
El verdadero rival es la dependencia de la nube
Secern AI no intenta superar a todos los asistentes de programación en la nube en capacidad general; compite contra la suposición de que la IA generativa útil requiere infraestructura externa.
Esa distinción define la importancia comercial del proyecto. La Fuerza Aérea es un cliente de referencia exigente, pero Secern AI también menciona a organismos públicos, instituciones financieras, grandes empresas y contratistas de defensa como mercados objetivo.
Estas organizaciones suelen gestionar código sensible y documentación interna. Algunas operan redes segmentadas o imponen normas estrictas de aprobación para transferencias externas de datos.
Una plataforma local les ofrece otra vía de despliegue. Puede mantener el procesamiento interno al tiempo que proporciona funciones similares a las de los asistentes de programación en la nube.
Secern AI lanzó IntraGenX en marzo de 2026, según los informes del proyecto. El contrato con la Fuerza Aérea brinda a la joven plataforma la oportunidad de avanzar más allá de las demostraciones y las pruebas controladas de producto.
La empresa presenta su estrategia más amplia como una contraparte coreana de Palantir. Esa comparación merece cautela.
Palantir construyó su posición en defensa mediante despliegues prolongados, integración de sistemas, gobernanza de datos y aplicaciones operativas. Un contrato para un asistente de programación no sitúa a Secern AI en la misma escala ni nivel de madurez.
La similitud relevante es más limitada. Ambos enfoques organizan datos institucionales protegidos para que el software pueda respaldar el análisis y la ejecución dentro de entornos controlados.
Para Secern AI, la tarea inmediata se refiere al desarrollo de software, no a la inteligencia en el campo de batalla. Su grafo de conocimiento está concebido para conectar código, esquemas, reglas y documentos técnicos.
Otros grandes proveedores tecnológicos coreanos también impulsan la IA de defensa y la infraestructura segura para el sector público. Samsung SDS, por ejemplo, ha hablado de sistemas de defensa basados en recuperación y de oportunidades de mando y control de próxima generación.
Los integradores de sistemas tradicionales aportan experiencia en adquisiciones, personal de implementación y relaciones existentes con el gobierno. Los proveedores de seguridad aportan productos maduros de análisis y supervisión.
La respuesta de Secern AI es un paquete más integrado. Quiere combinar inferencia de modelos locales, contexto organizativo, flujos de trabajo de programación y comprobaciones de seguridad.
Ese empaquetado puede acortar el trabajo de integración si los componentes cooperan bien. También puede aumentar la dependencia de las decisiones de una sola plataforma sobre indexación, modelos, orquestación y gobernanza.
Los compradores tendrán que evaluar la portabilidad. Deberían preguntar si los repositorios, grafos de conocimiento, registros de auditoría y políticas de seguridad pueden trasladarse a otro modelo o cadena de herramientas.
También deberían examinar la sustitución de modelos. Una plataforma local se vuelve más duradera si los administradores pueden cambiar el modelo subyacente sin reconstruir todos los flujos de trabajo.
Los informes públicos no indican si IntraGenX admite múltiples modelos o interfaces estándar. Tampoco explican cómo los clientes exportan sus estructuras de conocimiento.
Los requisitos de hardware siguen sin divulgarse. Un modelo de 30.000 millones de parámetros puede ser viable en infraestructura empresarial, pero el rendimiento depende de la precisión, los aceleradores, el tamaño del contexto, la concurrencia y el diseño de la carga de trabajo.
La ausencia de cifras publicadas sobre latencia y capacidad impide una comparación directa con los servicios en la nube. Esto no es inusual antes del despliegue, pero limita la solidez de las afirmaciones sobre rendimiento.
La implementación de la Fuerza Aérea puede aportar la evidencia operativa que falta. Puede mostrar cuántos desarrolladores utilizan el sistema, qué tareas le delegan y con qué frecuencia los revisores aceptan las sugerencias.
También puede mostrar si el mantenimiento aislado es manejable. Las actualizaciones y las fuentes de vulnerabilidades deben llegar al entorno sin reabrir la vía de datos que la separación física de red se diseñó para cerrar.
Si Secern AI gestiona esos detalles, el proyecto puede convertirse en una referencia creíble para compradores regulados. Si el mantenimiento supera el beneficio de productividad, la independencia de la nube resultará menos atractiva.
La competencia es, por tanto, entre control local y comodidad operativa. Secern AI ha obtenido la oportunidad de defender el control local, pero los resultados del despliegue determinarán el ganador.
Lo que debe demostrar la próxima fase
Tres señales determinarán si este contrato se convierte en un modelo de IA de defensa repetible o sigue siendo una demostración limitada.
La primera señal es una validación técnica documentada. Secern AI, IITP o la Fuerza Aérea deberían acabar divulgando resultados medibles sin exponer sistemas sensibles.
Los resultados más útiles abarcarían la finalización de tareas, los hallazgos de revisión de código, los falsos positivos, las revisiones de los desarrolladores, el tiempo de respuesta y el uso de recursos. Los resultados de seguridad deberían distinguir entre problemas detectados y vulnerabilidades confirmadas.
Una evaluación independiente de la Universidad de Sejong podría aportar credibilidad. Su papel ofrece al proyecto una posible fuente de escrutinio técnico ajena a Secern AI y CodeMind.
La segunda señal es evidencia de uso en producción controlada. Una demostración en repositorios seleccionados es diferente del uso sostenido entre equipos de desarrollo activos.
La evidencia de producción incluiría usuarios recurrentes, flujos de trabajo aprobados, procedimientos de actualización de modelos, gestión de incidentes e integración con herramientas de desarrollo existentes.
El proyecto también debería revelar cómo funciona la aprobación humana. Los revisores necesitan autoridad para rechazar sugerencias, inspeccionar su contexto de respaldo e identificar la versión responsable del modelo.
El perfil de desarrollo de IA de NIST considera los modelos, pesos, canalizaciones y activos relacionados como partes del entorno de software protegido.
Esa visión más amplia importa dentro de una red de defensa. Proteger solo el código fuente generado dejaría la cadena de suministro del modelo y el sistema de recuperación insuficientemente gobernados.
La tercera señal es un despliegue posterior. La adopción por otra rama militar, organismo gubernamental, institución financiera o contratista de defensa demostraría que la arquitectura se extiende más allá de un solo cliente.
Un contrato posterior reforzaría la afirmación de Secern AI de que la programación con IA aislada de la red representa un mercado repetible. La falta de expansión no indicaría necesariamente un fracaso técnico, ya que los ciclos de adquisición pueden ser lentos.
Los compradores también deberían vigilar si Secern AI publica información más clara sobre interoperabilidad. La compatibilidad con modelos sustituibles, grafos exportables y herramientas de seguridad estándar reduciría la dependencia de la plataforma.
Los desarrolladores deberían centrarse en una pregunta más sencilla: ¿el asistente reduce el trabajo verificado o simplemente genera más material que los humanos deben comprobar?
Los responsables de seguridad deberían preguntarse si el flujo de trabajo combinado mejora la detección sin debilitar los controles existentes. Los equipos de adquisición deberían examinar las obligaciones a largo plazo de hardware, actualizaciones y soporte.
La evidencia actual respalda una conclusión cautelosa. Secern AI ha obtenido un proyecto definido de 2.450 millones de wones con socios identificados, un cliente identificado de la Fuerza Aérea y un modelo de despliegue específico.
La evidencia todavía no muestra cómo funciona IntraGenX dentro de la red operativa. Los benchmarks públicos, los criterios de aceptación y los resultados del despliegue siguen sin estar disponibles.
Esa brecha de verificación es el núcleo de la historia. El contrato reconoce la demanda de programación con IA en entornos que no pueden depender de herramientas cloud convencionales, pero no resuelve si la IA local puede satisfacer esa demanda.
En los próximos meses, habrá que seguir de cerca los resultados de las evaluaciones técnicas, las pruebas de uso habitual por parte de desarrolladores y un segundo despliegue en otra red controlada.
Si se cumplen las tres condiciones, el proyecto de defensa con IA de Secern ofrecerá un modelo práctico de asistencia para programación segura y operada localmente. De lo contrario, la adjudicación seguirá siendo un experimento interesante, más que un modelo de contratación probado.
