La seguridad de la IA necesita una segunda opinión

La IA escribe software más rápido de lo que podemos protegerlo. ¿Puedes seguirle el ritmo?

Para cuando termines de leer esta frase, los desarrolladores y sus agentes de IA habrán enviado un par de miles de confirmaciones de código. En estas mismas fechas del año pasado, habrían sido unas 150.

En el último año, el software generado por IA ha avanzado a un ritmo asombroso. GitHub registró 7.38 mil millones de confirmaciones de código solo en septiembre de 2026, más de cinco veces el total de un año antes. Las implicaciones de seguridad de esta explosión son profundas. Se supone que alguien debe comprender, mantener y proteger cada una de esas confirmaciones de código. Cloud Security Alliance descubrió que los desarrolladores que usan IA en empresas de Fortune 50 confirman código a un ritmo de tres a cuatro veces mayor que sus pares, mientras que sus hallazgos de seguridad mensuales aumentaron aproximadamente diez veces.

Ahora pensemos en quién carga con ese aumento. El equipo del CISO tiene el mismo tamaño que hace un año, pero la lista de tareas pendientes no. Aumentan los reportes de vulnerabilidades, disminuyen las correcciones mensuales y se acumulan los problemas críticos sin resolver. No es de extrañar que Gartner afirme que el agotamiento de los CISO se está convirtiendo en un riesgo operativo crítico.

La tentación del modelo más reciente

Cuando la cifra es tan alta, el instinto lleva a perseguir una cifra aún mayor: más hallazgos, más cobertura, más análisis. Pero es como achicar agua de un barco que se hunde y pedir un balde más grande, cuando lo que hace falta es encontrar la fuga. La eficacia de un programa de seguridad no se mide por cuánto encuentra, sino por qué proporción de sus hallazgos son reales y cuántos de los más críticos se corrigen de verdad.

Los modelos de IA más avanzados son extraordinarios para encontrar exploits novedosos y fallos no catalogados mediante razonamiento probabilístico. Pero los resultados varían. Según una investigación de Checkmarx, si se ejecuta cinco veces el mismo análisis sobre el mismo código, los hallazgos coinciden solo en aproximadamente un tercio de los casos.

Esa inconsistencia explica por qué el análisis basado en reglas sigue siendo importante. Es menos flexible que la IA más avanzada, pero aplica la lógica probada de la misma manera cada vez, por lo que los equipos pueden confiar en los resultados y verificarlos. La IA detecta lo que las reglas pasan por alto, como debilidades conocidas que adoptan formas desconocidas o fallos que solo se vuelven explotables cuando interactúan distintas partes del código. En conjunto, la IA y el análisis basado en reglas permiten detectar más de lo que importa y reducir las falsas alarmas.

Nada de esto es un argumento en contra de la IA. Es un argumento a favor de que la seguridad necesita una segunda opinión. Sea cual sea el motor que elijas, plantéate tres preguntas.

Primera pregunta: fidelidad

Cuando el escáner indica que algo está mal, ¿merece la pena dedicarle tiempo?

La fidelidad genera confianza. Un hallazgo que no es real le cuesta una tarde de trabajo a un desarrollador y resta credibilidad al equipo de seguridad. A gran escala, los falsos positivos hacen que los equipos dejen de prestar atención. Las alertas se convierten en un «que viene el lobo» y se pierden entre el ruido de fondo.

Aquí es donde importa la consistencia. El análisis determinista devuelve siempre la misma respuesta para el mismo código, lo que genera confianza y permite auditar los resultados.

Segunda pregunta: precisión

¿Estás encontrando el conjunto completo de los problemas más importantes?

La fidelidad indica si merece la pena dedicar tiempo a un hallazgo, pero no revela qué pasó por alto el escáner. Usamos una medida práctica cuyos orígenes se remontan a la ciencia de datos: la puntuación F1. La puntuación F1 mide el rendimiento en una escala de 1 a 0, según dos factores:

• Precisión: la proporción de los hallazgos reportados que son reales. Una precisión alta significa menos falsas alarmas.
• Cobertura: la proporción de vulnerabilidades reales que el escáner encuentra efectivamente. Una cobertura alta significa que se escapan pocas.

Un escáner puede parecer preciso si señala casi nada, o exhaustivo si lo señala todo, pero en ambos casos puede obtener puntuaciones F1 bajas. La media del sector ronda el 0.20. Hemos trabajado mucho en este desafío y hemos obtenido resultados con una precisión de tres a cuatro veces superior a la de un escáner estándar.

Una mayor precisión facilita todo lo que viene después para los desarrolladores. Tu equipo dedica menos tiempo a validar y más a corregir.

Tercera pregunta: retorno de la inversión

¿Cómo podemos maximizar la inversión y los recursos?

Esta es la pregunta que más se suele pasar por alto durante el piloto y cuya respuesta más dolorosa llega en producción.

Los modelos más avanzados cobran por token, y se consumen tokens tanto si el análisis encuentra algo como si no. Analizar un repositorio de un millón de líneas cuesta más de mil dólares a los precios publicados actualmente. Además, el consumo de tokens varía mucho entre modelos: el precio varía según el modelo que elijas y cuánto razonamiento necesite para completar tu tarea.

Multiplica ese costo por cada confirmación de código, solicitud de incorporación de cambios y repositorio de una empresa. Según se informa, Uber, que gasta 3.4 mil millones de dólares al año en I&D, agotó todo su presupuesto de IA para 2026 en cuestión de meses tras implementar herramientas de programación con IA.

A esto lo llamamos el impuesto de los tokens. Es como llevar un Ferrari a hacer la compra: pagas por una potencia que el trayecto no necesita. Las credenciales codificadas de forma fija y la inyección SQL son patrones predecibles que el análisis determinista detecta de forma fiable.

La seguridad de las aplicaciones debe evolucionar

Este razonamiento está detrás de la arquitectura de Checkmarx Fusion. Los motores basados en reglas establecen una base de referencia fiable, de forma reproducible y a menor costo que el análisis basado en tokens. Los modelos de vanguardia se centran en lo que las reglas no pueden anticipar: patrones novedosos, lógica compleja y la posibilidad de explotación en contexto. Después, una capa de análisis de hallazgos combina los resultados en un único conjunto fiable.

El análisis determinista aporta certeza. La IA amplía el alcance. La cobertura y la confianza aumentan a la vez. En comparación con un LLM que trabaja por sí solo, observamos hasta cuatro veces más fidelidad, entre dos y cuatro veces más precisión y aproximadamente un tercio del costo.

Detectar problemas es solo el comienzo. La misma lógica se aplica a la prevención. Veamos un ejemplo. Si damos a los desarrolladores herramientas en el momento de crear el código, en el IDE donde lo escriben, podemos detener los problemas antes de que empiecen. Del mismo modo, cuando algunas vulnerabilidades logran pasar, ¿por qué no proporcionar a los desarrolladores correcciones listas para fusionar para las que más importan? Estos son los retos que buscamos resolver, con el objetivo de reducir progresivamente el atraso existente y lograr el mayor impacto posible en el menor tiempo y con el menor esfuerzo.

El código ya está en producción. ¿Puedes seguirle el ritmo?

La IA les dio a los atacantes la ventaja de la velocidad. Para cerrar esa brecha no basta con añadir otra herramienta. Se trata de decidir cómo toda tu organización desarrolla y protege el software. El código que se escribe hoy estará al servicio de tu empresa durante años. La pregunta para los responsables de seguridad ya no es cuánto más rápido te ayuda la IA a desarrollar, sino si tus programas pueden seguir el ritmo de lo que genera.

Así que no te pierdas entre las cifras. Hazle tres preguntas a cualquier programa: ¿Puedo confiar en lo que detecta? ¿Detecta suficientes problemas de los que importan? ¿Es viable implementarlo en toda mi organización? Combinar la precisión determinista con el razonamiento de vanguardia ofrece las mejores posibilidades de responder que sí a las tres preguntas.

El desarrollo de software no se está ralentizando. Ahora nos corresponde cerrar la brecha de riesgo: la distancia entre la velocidad a la que se crea el software y la velocidad a la que se detectan y corrigen los riesgos.