La detección de vulnerabilidades con IA suele depender de servicios en la nube: se sube código, se envían fragmentos para su análisis y se espera una respuesta. Ese esquema puede ser útil, pero choca con una restricción frecuente en bancos, hospitales, plantas industriales y organismos públicos: el software que se necesita auditar no siempre puede salir de la infraestructura propia. Aikido propuso una alternativa con Altar-1, un modelo de pesos abiertos orientado a seguridad que se ejecuta de forma local.
La novedad no reside solo en aplicar un modelo de lenguaje a la revisión de código. Altar-1 fue obtenido a partir de GLM-5.3 mediante poda de expertos y cuantización, dos técnicas para reducir el costo de operar modelos grandes. Según Aikido, el resultado baja de 1,51 TB a 328 GB y preserva buena parte de la cobertura de detección. El anuncio abre una discusión concreta para equipos de desarrollo y seguridad: qué tareas conviene automatizar dentro del perímetro corporativo y cuáles todavía exigen validación humana rigurosa.
Detección de vulnerabilidades con IA sin sacar el código del perímetro
Altar-1 apunta a un problema de confianza y cumplimiento. En una auditoría tradicional, el equipo de seguridad revisa dependencias, configuraciones, flujos de datos y fragmentos de código en busca de patrones asociados a fallas conocidas. Un modelo de IA puede acelerar la primera exploración, proponer hipótesis y priorizar archivos o rutas de ejecución que ameritan una revisión más profunda.
Cuando ese análisis se realiza mediante una plataforma remota, aparece una pregunta sensible: qué información viaja fuera de la organización y bajo qué controles se conserva. Esto no es un detalle administrativo. El código fuente puede exponer lógica de negocio, credenciales mal gestionadas, configuraciones de red o procedimientos operativos. Para sectores regulados y entornos de tecnología operacional aislados, la alternativa de enviar esos datos a internet puede estar directamente prohibida.
Aikido plantea Altar-1 como un modelo que puede alojarse on-premises, dentro de la infraestructura del cliente. La propuesta permite integrar capacidades de análisis asistido en flujos internos de pruebas de seguridad, sin que el repositorio o los hallazgos deban abandonar el entorno controlado. No equivale a una garantía automática de seguridad: el despliegue local también requiere controles de acceso, segmentación, registro de actividad y una política clara para manejar los resultados.
Cómo redujeron GLM-5.3 para volverlo operable
El punto técnico central es la compresión. El modelo de partida, GLM-5.3, ocupa 1,51 TB según la información publicada por Aikido. Llevar un modelo de esa escala a una instalación interna es costoso y limita su uso a organizaciones con infraestructura especializada. Para construir Altar-1, la compañía combinó cuantización AWQ INT4 y poda de expertos.
Cuantización: menos bits para representar los pesos
La cuantización representa los parámetros del modelo con menos precisión numérica. En vez de conservarlos con formatos de mayor tamaño, se los codifica con menos bits para disminuir el consumo de memoria y almacenamiento. El desafío es que esa reducción no degrade de forma significativa la capacidad del modelo para razonar sobre el código y detectar señales relevantes de una vulnerabilidad.
Poda de expertos: recortar lo que menos aporta
GLM-5.3 utiliza una arquitectura de mezcla de expertos, donde distintas subredes se activan según la entrada. Aikido eliminó expertos considerados menos necesarios para las tareas de seguridad y conservó los más útiles para ese dominio. La compañía denomina a su enfoque REAP, por sus siglas en inglés de poda de expertos ponderada por el router. El resultado informado es un modelo de 328 GB: una baja del 78,2% frente al tamaño original.
La reducción tiene una consecuencia práctica: Aikido indica que Altar-1 puede servirse en un nodo con cuatro GPU NVIDIA H200 y la versión más reciente de vLLM. Sigue siendo un requisito elevado, lejos de una notebook de desarrollo, pero cambia la conversación para empresas que ya operan infraestructura de IA o pueden justificarla por la sensibilidad de sus activos de software.
Qué muestran las pruebas y cómo interpretarlas
Para medir su propuesta, Aikido evaluó el modelo sobre 32 vulnerabilidades conocidas. Altar-1 obtuvo un recall promedio de 60,4%, frente al 61,5% del GLM-5.3 cuantizado, de acuerdo con el benchmark interno de la empresa. Expresado de otro modo, el modelo compacto retuvo aproximadamente el 92% de la cobertura de detección de esa referencia, con una huella de almacenamiento mucho menor.
La cifra es interesante, aunque debe leerse con cautela. El recall indica qué proporción de vulnerabilidades presentes logra identificar un sistema, pero no describe por sí solo cuántas alertas erróneas genera, qué tan explotables son los hallazgos ni cómo se comporta ante proyectos, lenguajes y configuraciones que no integraron el conjunto evaluado. Además, el benchmark fue comunicado por el propio proveedor.
Para un equipo de AppSec, la forma razonable de validar una herramienta así es ejecutar una prueba controlada con repositorios representativos, vulnerabilidades históricas conocidas y criterios propios de severidad. También conviene contrastar sus sugerencias con análisis estático, revisión manual, pruebas dinámicas y herramientas de gestión de dependencias. La IA puede orientar el trabajo; no debe cerrar el diagnóstico por sí sola.
Aplicaciones para DevSecOps y ambientes regulados
El mayor valor de un modelo local aparece cuando la privacidad y la residencia de datos son condiciones operativas. Entre los escenarios posibles se encuentran:
- Revisión continua de repositorios internos: priorizar módulos, dependencias o cambios de código que demandan atención del equipo de seguridad.
- Pruebas de penetración asistidas: generar hipótesis para explorar vectores de ataque y documentar el contexto técnico de un hallazgo.
- Entornos desconectados: apoyar auditorías en redes industriales, laboratorios o instalaciones donde no existe salida a internet.
- Preparación de remediaciones: explicar por qué un patrón puede ser riesgoso y ayudar a proponer correcciones que luego deben revisarse y probarse.
Integrado con criterio, este tipo de herramienta puede reducir el tiempo entre un cambio de código y la revisión inicial de sus riesgos. También permite que los especialistas se concentren en validar impacto, explotabilidad y prioridad de mitigación, tareas donde el conocimiento del negocio y de la arquitectura continúa siendo decisivo.
Los límites de una auditoría automatizada
Que un modelo esté instalado dentro de la red no elimina los riesgos. Una plataforma local debe actualizarse, monitorearse y aislarse adecuadamente. Los prompts, los resultados y los logs pueden contener información sensible; por eso necesitan las mismas políticas de protección que cualquier otro componente de la cadena de desarrollo.
También persiste el problema de los falsos positivos y falsos negativos. Un modelo puede marcar como peligrosa una construcción segura por no comprender un control compensatorio específico, o pasar por alto una falla que depende de una condición de negocio, una configuración de despliegue o la interacción entre varios servicios. Su utilidad crece cuando se lo usa para aumentar cobertura y velocidad, no para reemplazar un proceso de ingeniería de seguridad.
La disponibilidad de pesos abiertos aporta auditabilidad y opciones de despliegue, pero transfiere responsabilidades: evaluar licencias, asegurar el entorno de inferencia, administrar capacidad de cómputo y verificar el comportamiento ante los lenguajes y marcos de trabajo usados por cada organización. En otras palabras, soberanía tecnológica no significa ausencia de operación técnica.
Una señal para la seguridad de software
Altar-1 muestra una tendencia que gana relevancia: la IA aplicada a ciberseguridad no tendrá una única forma de consumo. Para algunas organizaciones, un servicio remoto seguirá siendo suficiente. Para otras, la exigencia será acercar el modelo al código, a los datos y a los procesos internos. La combinación de modelos especializados, compresión y ejecución local puede habilitar ese segundo camino, aunque todavía con una barrera de hardware considerable.
El desafío para los equipos de tecnología será evitar dos extremos: descartar estas herramientas por sus límites actuales o adoptarlas como si fueran un auditor autónomo. La oportunidad está en incorporarlas a flujos DevSecOps medibles, con evidencia, supervisión humana y mejoras continuas. Así, la detección de vulnerabilidades con IA puede convertirse en una capa adicional de defensa sin perder el control sobre los activos digitales más sensibles.
Fuentes: anuncio técnico de Aikido y cobertura de Hipertextual.