La respuesta corta: mide el trabajo útil, no el número de alertas
Una herramienta de revisión de código con inteligencia artificial puede encontrar patrones sospechosos con rapidez y, al mismo tiempo, trasladar al equipo una cola difícil de verificar. Por eso el piloto no debería premiar el volumen de avisos. Debe responder cuatro preguntas: cuántas vulnerabilidades reales detecta, cuántas omite, cuántas falsas alarmas genera y cuánto trabajo humano requiere convertir una alerta en una decisión.
AWS publicó el 9 de septiembre de 2026 Deception Benchmark, un conjunto diseñado para comprobar si un sistema distingue código explotable de variantes que parecen peligrosas pero incluyen una mitigación válida. El blog técnico y el repositorio del proyecto describen 14.822 muestras, 16 lenguajes y más de 70 categorías CWE. En su evaluación de modelos generalistas con una tarea de clasificación de una sola interacción, ninguna configuración probada mantuvo a la vez las tasas de falsos positivos y falsos negativos por debajo del umbral del 10 % definido por los autores.
Ese resultado no permite concluir que todos los productos comerciales funcionen igual. El propio estudio separa su línea base de los sistemas especializados que añaden herramientas, contexto o validación en varios pasos. La señal útil para una empresa es más concreta: exigir evidencia sobre errores en ambos sentidos y repetir la prueba en condiciones cercanas a su tecnología, sus controles y su forma de revisar cambios.
- Verdadero positivo: existe una vulnerabilidad y la herramienta la identifica.
- Falso positivo: el código es seguro en el contexto probado, pero la herramienta lo marca como vulnerable.
- Falso negativo: existe una vulnerabilidad y la herramienta no la detecta.
- Verdadero negativo: el caso es seguro y la herramienta lo descarta correctamente.
Construye un conjunto de prueba con resultado conocido
No se puede medir precisión si nadie conoce la respuesta correcta. OWASP Benchmark resuelve este problema con aplicaciones ejecutables que contienen casos vulnerables y casos seguros, asociados a categorías CWE y acompañados de resultados esperados. Su esquema permite comparar herramientas mediante verdaderos positivos, falsos negativos, verdaderos negativos y falsos positivos. Deception Benchmark aplica la misma idea general a sistemas de IA, pero endurece los casos seguros para que compartan patrones superficiales con vulnerabilidades reales.
Para un piloto empresarial, combina un benchmark público con una muestra interna pequeña y revisada. Selecciona cambios históricos que incluyan defectos corregidos, alertas descartadas con justificación y controles compensatorios documentados. Elimina secretos y datos de clientes antes de enviarlos a un servicio externo. Un especialista debe etiquetar cada caso sin consultar la predicción de la herramienta, y una segunda persona debería resolver los casos dudosos.
No conviertas el histórico interno en un examen que el proveedor pueda memorizar. Mantén parte de los casos fuera de la configuración inicial y registra la versión del modelo, las reglas, el prompt, las herramientas conectadas y cualquier ajuste. Tanto OWASP como el repositorio de AWS insisten en la reproducibilidad: sin conservar configuración y procedimiento, una mejora aparente puede deberse a que cambió el ensayo, no a que mejoró el sistema.
- Incluye vulnerabilidades confirmadas y código seguro que contenga patrones parecidos.
- Representa los lenguajes, frameworks y tipos de fallo que utiliza la empresa.
- Reserva casos no usados durante la configuración para la evaluación final.
- Documenta versión, reglas, contexto, permisos, coste y duración de cada ejecución.
Separa precisión, cobertura y coste de revisión
Una sola cifra de exactitud puede ocultar un comportamiento inútil. Una herramienta que marque todo como vulnerable capturará muchos defectos, pero también inundará al equipo con falsas alarmas. AWS explica este problema al publicar por separado la tasa de falsos positivos y la de falsos negativos; OWASP utiliza la misma matriz de resultados para puntuar herramientas de análisis de seguridad.
Calcula al menos la precisión de las alertas —qué proporción de lo marcado era realmente vulnerable—, la cobertura o sensibilidad —qué proporción de las vulnerabilidades conocidas fue detectada— y la tasa de falsos positivos sobre los casos seguros. Añade métricas operativas: minutos de validación por alerta, porcentaje de avisos que llegan a una corrección aceptada, repetición de la misma alerta y tiempo desde el cambio hasta la decisión.
El objetivo no es fijar un umbral universal. Un falso negativo en autenticación, autorización o manejo de secretos puede tener un coste distinto al de un aviso incorrecto sobre código de bajo impacto. Define el criterio por severidad y ruta de riesgo antes de ver los resultados. Así se evita bajar el listón para justificar una compra o endurecerlo después de que la herramienta haya generado ruido.
- Precisión de alertas = verdaderos positivos dividido entre todas las alertas positivas.
- Cobertura = verdaderos positivos dividido entre vulnerabilidades reales conocidas.
- Tasa de falsas alarmas = falsos positivos dividido entre todos los casos seguros.
- Carga de revisión = tiempo humano total dividido entre alertas evaluadas.
Prueba el contexto donde se desplegará la herramienta
El código no determina por sí solo toda la explotabilidad. Una política de red, una comprobación de identidad, una consulta parametrizada o un aislamiento de proceso pueden cerrar una ruta que parece abierta al observar solo una función. Deception Benchmark incluye casos donde el entorno cambia la respuesta correcta. NIST, en la función Measure del AI Risk Management Framework, pide demostrar los criterios de rendimiento en condiciones similares a las del despliegue y documentar conjuntos de prueba, métricas y herramientas.
Diseña dos fases. En la primera, ejecuta la herramienta sobre código aislado para conocer su capacidad básica. En la segunda, dale solo el contexto que tendría en producción: configuración de infraestructura, dependencias, controles de identidad y resultados de pruebas. Compara cuánto mejora y qué nuevos datos necesita. Si para acertar requiere acceso amplio al repositorio, a incidencias o a entornos cloud, ese permiso debe entrar en la evaluación de riesgo y coste.
También importa dónde aparece la alerta. Un comentario informativo en una solicitud de cambio no tiene el mismo impacto que un bloqueo automático del despliegue. Empieza sin capacidad para aprobar, fusionar o cambiar código. Solo después de demostrar resultados estables se puede valorar una acción automática limitada, reversible y protegida por los controles normales del ciclo de desarrollo.
- Modo observación: la herramienta informa, pero no bloquea ni modifica.
- Contexto mínimo: acceso únicamente a los archivos y configuraciones necesarios.
- Comparación: mismos casos, versión y criterios con y sin contexto adicional.
- Trazabilidad: cada alerta conserva evidencia, decisión humana y resultado final.
Mantén una revisión humana proporcionada al riesgo
NIST recomienda definir cómo se utilizarán y supervisarán las salidas de un sistema de IA, probar antes del despliegue y revisar regularmente el rendimiento en operación. AWS llega a una conclusión compatible para este caso: las alertas de rutas de alto riesgo deben verificarse por una persona. La supervisión no consiste en aceptar o rechazar avisos a ciegas, sino en comprobar el flujo de datos, la mitigación, el contexto de despliegue y la posibilidad real de explotación.
Asigna responsables diferentes para configurar la herramienta y evaluar el piloto cuando el tamaño del equipo lo permita. NIST señala que una revisión independiente puede reducir sesgos y conflictos de interés. Para una pyme, independencia puede significar que la persona que negocia la compra no sea la única que etiqueta los resultados, o que una muestra crítica reciba una segunda revisión externa.
El Secure Software Development Framework de NIST sitúa estas prácticas dentro del ciclo de desarrollo, no como una inspección aislada al final. Integra las alertas válidas en el registro normal de defectos, conserva las decisiones y revisa si el mismo origen reaparece. La herramienta debe reforzar revisiones, pruebas y gestión de vulnerabilidades existentes; no reemplazar propietarios, criterios de severidad ni controles de cambio.
- Exige revisión experta para autenticación, autorización, secretos y límites de confianza.
- Registra por qué una alerta se confirmó o se descartó y qué evidencia se usó.
- Muestrea periódicamente casos negativos para buscar vulnerabilidades omitidas.
- Reevalúa tras cambios de modelo, reglas, repositorio, infraestructura o permisos.
Ejecuta un piloto de treinta días con criterio de parada
Durante la primera semana, define alcance, responsables, datos permitidos y conjunto de prueba. En la segunda, mide el sistema en modo observación sobre casos públicos y cambios internos ya resueltos. En la tercera, intégralo en un repositorio no crítico y registra el tiempo real de triage. En la cuarta, compara los resultados con el proceso anterior y decide si continuar, ajustar o retirar.
Antes de empezar, escribe un criterio de parada. Puede activarse si la herramienta envía código sensible fuera del entorno aprobado, bloquea cambios sin una ruta de excepción, supera una carga máxima de revisión o repite errores críticos después de ajustar la configuración. Define también qué evidencia permitiría ampliar: mejora medible de cobertura sin deteriorar la precisión, tiempo de revisión asumible, trazabilidad completa y aceptación por quienes reciben las alertas.
La salida del piloto debe ser una decisión, no una presentación. Conserva una ficha con versión, coste, permisos, casos, métricas por severidad, incidencias, limitaciones y responsable. Si el resultado es prometedor pero incierto, mantén la herramienta en modo informativo y amplía la muestra. Si no reduce riesgo o trabajo, retirarla también es un resultado válido.
- Semana 1: alcance, permisos, casos conocidos y umbrales.
- Semana 2: benchmark reproducible y revisión ciega de resultados.
- Semana 3: repositorio no crítico, modo observación y carga real.
- Semana 4: comparación, decisión documentada y plan de seguimiento.
Preguntas que el proveedor debe poder responder
Una demostración centrada en el hallazgo más llamativo no basta para valorar una herramienta defensiva. Pide resultados separados para código vulnerable y seguro, detalles sobre los conjuntos de prueba y límites conocidos. Pregunta si el producto ha sido evaluado con controles compensatorios y configuraciones de infraestructura, no solo con fragmentos aislados.
Solicita además información operativa: dónde se procesa el código, cuánto se conserva, qué identidades utiliza, quién puede ver las alertas y cómo se auditan los cambios de modelo o reglas. NIST recomienda considerar los riesgos de componentes y servicios de terceros y mantener procesos de contingencia ante sus fallos. Si la herramienta se integra en el flujo de desarrollo, su disponibilidad, actualización y retirada también forman parte de la decisión.
La pregunta final es sencilla: ¿qué evidencia demuestra que la herramienta mejora este proceso concreto sin trasladar más riesgo o más trabajo del que elimina? Si la respuesta depende solo del número de vulnerabilidades encontradas en una demo, todavía no hay base suficiente para automatizar decisiones.
- ¿Qué tasas de falsos positivos y falsos negativos obtiene y sobre qué casos?
- ¿Cómo cambia el resultado cuando existen controles de red, identidad o ejecución?
- ¿Qué datos, permisos y retención necesita la integración?
- ¿Cómo se revierte un bloqueo, una regla defectuosa o una actualización del modelo?
- ¿Puede la empresa reproducir la evaluación con su propio conjunto de prueba?
