El presupuesto para probar: la IA abarató producir cambios, pero verificar es la partida que nadie planificó

Imagine a un responsable de seguridad un lunes por la mañana. Durante el fin de semana, un agente revisó el backlog de vulnerabilidades y abrió cuarenta pull requests en borrador, cada una con una nueva ejecución exitosa del escáner que generó la alerta. El trabajo que solía llevar un trimestre está hecho. El trabajo que queda, leer cuarenta cambios en código que el equipo del responsable no escribió, no se ha reducido en absoluto. Ha llegado todo a la vez.

Esa escena es hacia donde se dirige la IA empresarial en todas las funciones que producen algo verificable: código, correcciones de seguridad, contratos, conciliaciones, informes. Nuestra visión, y es una visión más que una medición, es que la capacidad de verificación se está convirtiendo en la restricción vinculante para la IA en producción, y la mayoría de las organizaciones no ha presupuestado para ello.

La evidencia de una semana

Cuatro anuncios del 14 y 15 de octubre hacen que el patrón sea difícil de ignorar:

• GitHub puso Agentic Autofix y AI Scan en disponibilidad general (GA). Autofix puede agrupar hasta 25 alertas en una sola pull request. Ninguna de las dos funciones puede fusionar o bloquear nada; la revisión recae en las personas.
• Snyk construyó sus nuevos agentes en torno a la regla de que “el generador no puede ser el validador”, e informa que las revisiones de seguridad con LLM dieron un hallazgo que desapareció en la siguiente ejecución el 49.7% de las veces.
• Chainguard Harness solo reporta hallazgos que se reproducen en un sandbox nuevo cada vez, y un ingeniero con nombre y apellido revisa cada informe.
• Los investigadores de Anthropic encontraron que un auditor de IA recompensado por encontrar hallazgos aprendió a inventarlos.

Productos diferentes, una misma forma. La generación está automatizada y escalando. La verificación es determinista y limitada, o humana y lenta, o basada en modelos y necesitada de su propia comprobación.

Por qué la verificación no escala de la misma manera

La generación se abarató porque una llamada al modelo puede producir un cambio plausible. La verificación resiste la misma economía por tres razones:

1. Los verificadores baratos son limitados. Una nueva ejecución de CodeQL prueba que una alerta está cerrada; una comprobación de esquema prueba un formato. No dicen nada sobre el comportamiento, la intención o los efectos secundarios.
2. Los verificadores amplios son caros. Una persona que entiende el código, el contrato o el libro mayor es la comprobación más general que existe, y la más escasa.
3. Los verificadores de modelo heredan los problemas del modelo. Varían entre ejecuciones, se desvían cuando su modelo cambia y, como mostró Anthropic, optimizan para aquello por lo que son recompensados.

Cuando Google dejó que un agente trabajara durante la noche en una base de código grande, los ingenieros conservaron dos de seis propuestas. El valor era real, y también el costo: la revisión era el trabajo.

Planifique la verificación como capacidad

Si la verificación es la restricción, merece el tratamiento que damos a otras restricciones. Siguen cinco prácticas:

Dé a cada clase de cambio una ruta de verificación antes de automatizarla. Para cada tipo de resultado que vaya a producir un agente, escriba qué lo comprueba: una prueba determinista, una reproducción, un modelo independiente con una tasa de falsos positivos medida, una persona, o una combinación. Sin ruta, no hay automatización. Esto amplía las clases de cambio que propusimos en agentes como autores de cambios en producción.

Mida la cola, no solo el resultado. Haga un seguimiento de cuánto tiempo espera la salida del agente para su verificación y cuánto de ella se aprueba sin retrabajo. Una cola en crecimiento significa que el sistema produce pasivos más rápido que activos.

Gaste primero en los verificadores baratos. Cada prueba, regla, harness de reproducción y conjunto de datos de referencia que agregue convierte la costosa revisión humana en comprobaciones automatizadas baratas para una porción del trabajo. Ahí es donde deberían ir los presupuestos de IA junto con el gasto en modelos.

Reserve el verificador caro para lo que solo él puede juzgar. Las personas deben revisar la intención, el riesgo y todo aquello que una regla no puede expresar. Pedirles que confirmen lo que una prueba podría confirmar desperdicia el recurso más escaso.

Verifique a los verificadores. Cada comprobación automatizada, especialmente una basada en modelos, necesita casos conocidos como buenos y conocidos como malos y una muestra humana periódica. Un evaluador sin una tasa de error medida tiene una desconocida.

Qué significa esto para el caso de negocio

La mayoría de los casos de negocio de IA cuentan las horas que ahorra la generación. Pocos cuentan las horas que añade la verificación, y casi ninguno financia las pruebas y los harnesses que abaratarían la verificación. Así es como las organizaciones acaban con números de piloto impresionantes y despliegues estancados, la brecha que describimos cuando escribimos que las horas ahorradas no son valor.

En el trabajo regulado, esto no es opcional. La prueba tiene que venir de fuera del modelo, y fuera del modelo es exactamente donde la capacidad es limitada. Los equipos que escalen la IA en 2027 no serán los que más generen. Serán los que construyeron los medios para confiar en lo generado, y lo pagaron a propósito.