Publica correcciones de IA solo tras un reproductor de exploit, no una puntuación del modelo

La puntuación no es el control

Un parche de IA puede superar un evaluador del modelo y aun así dejar el exploit activo. En el experimento de 1Password Off-by-1 Labs, el 26,0 % de los parches generados por LLM corrigió por completo la vulnerabilidad sin alterar de forma material el comportamiento de la aplicación.

Off-by-1 Labs de 1Password publicó un estudio que examina las correcciones generadas por LLM para vulnerabilidades nuevas y complejas. El experimento creó 6.080 parches utilizando dos modelos de razonamiento de frontera con capacidades cibernéticas en seis CVE recientemente divulgados. La hipótesis era que los modelos de IA de frontera lograrían tasas de éxito de parcheo de aproximadamente el 67 % al generar parches de software. El 53,9 % de los parches de LLM eran defectuosos por dejar el error sin corregir, añadir un error nuevo o ambas cosas.

Trail of Bits calificó el benchmark de parcheo de IA de 1Password como engañoso debido a un diseño experimental defectuoso y publicó herramientas de validación. La disputa importa porque la metodología del benchmark determina qué significa una puntuación. Una puntuación puede ser útil, pero no puede sustituir una prueba.

Construye la puerta antes de que el modelo se ejecute

La puntuación del modelo es una señal. La puerta obliga al parche a demostrar su validez. Usa este conjunto mínimo para un pipeline de corrección con IA.

• Define el conjunto de pruebas antes de la generación. Enumera la vulnerabilidad exacta, la versión objetivo, la entrada y el fallo esperado.
• Exige compilación. El parche debe compilarse en el mismo entorno que el objetivo.
• Ejecuta el reproductor de exploit. El error original debe fallar tras aplicar el parche.
• Comprueba el comportamiento. La prueba de humo debe mostrar sin nuevos cuelgues, sin API modificada y sin nuevas advertencias.
• Registra el evaluador del modelo. Anota la puntuación, la confianza y cualquier discrepancia con el reproductor.
• Deriva a revisión humana cuando el evaluador, el reproductor o la prueba de humo discrepan.

Una prueba vaga permite que el modelo resuelva un error cercano, y un paso de compilación ausente deja que un evaluador acepte código que no puede ejecutarse. Un reproductor ausente permite que una puntuación sustituya a la prueba, mientras que una comprobación de comportamiento ausente deja que un parche rompa otra ruta. Un registro de evaluador ausente no da al revisor motivo para mirar, y una puerta humana ausente deja que una discrepancia automatizada se publique.

Mantén el conjunto de pruebas lo suficientemente pequeño para ejecutarse rápidamente y lo suficientemente específico para rechazar un parche que modifica la ruta equivocada. Usa el mismo reproductor que el equipo utilizaría para confirmar el error original, y cubre con la prueba de humo el comportamiento que la prueba espera preservar.

Mantén la puerta humana cuando los evaluadores discrepan

La evaluación del modelo puede discrepar con el reproductor. Un modelo puede considerar un parche seguro mientras el exploit sigue disparándose. Otro puede marcar un cambio seguro como arriesgado. La puerta no debe promediar esas puntuaciones. Envía el parche a una persona cuando el reproductor entre en conflicto con la salida del modelo. La discrepancia es la señal útil. Muestra dónde divergen la confianza del modelo y los resultados del reproductor.

El revisor humano no vuelve a ejecutar toda la suite de pruebas. La revisión cubre el diff, el resultado del reproductor y el registro de comportamiento. La pregunta es si el parche modifica la aplicación de una forma que la prueba no esperaba. Si es así, el parche se detiene. Si no, pasa al camino normal de publicación.

Cuando el evaluador y el reproductor discrepan, el reproductor gana. El evaluador aún puede ser útil. Puede señalar una línea arriesgada, un caso límite ausente o un patrón que el revisor debe inspeccionar. Trata la puntuación como una nota adjunta al resultado del reproductor, no como un veto.

Cuando la prueba de humo y el reproductor discrepan, detente. Un parche que corrige el exploit pero cambia el comportamiento fuera de la prueba no está listo. Compara el comportamiento esperado en el conjunto de pruebas con el comportamiento observado en la prueba de humo. La diferencia es la pregunta de la revisión.

La puerta de revisión debe tener una condición de salida por escrito. El parche se publica cuando el reproductor pasa, la prueba de humo pasa y el revisor aprueba el diff. El parche se detiene cuando alguna de esas condiciones falla.

El operador necesita saber qué pruebas cuentan, qué reproductor es definitivo y qué discrepancia activa la revisión. Una respuesta poco clara significa que el pipeline no está listo para producción. Una respuesta clara convierte la puntuación del modelo en una señal secundaria en lugar de la decisión de publicación.

El operador también debe conservar los parches fallidos. Muestran dónde la confianza del modelo fue errónea y dónde el conjunto de pruebas necesita una entrada más precisa.