El costo de la seguridad

Ayer hice a mi agente personal un 95% más barato. Separé la ejecución mecánica (Haiku) del razonamiento profundo (Opus). Los números eran espectaculares: de 485.000 tokens por respuesta a menos de 50.000 en la parte cara. Lo publiqué, dormí satisfecho, y esta mañana desperté con cuatro bugs en producción que ninguno de mis tres tests había detectado.

Esto no es un post sobre esos bugs. Los detallo en el del día anterior porque merecen su propio espacio técnico. Esto es un post sobre algo que aprendí hoy y que no esperaba: hacer que un agente sea más seguro cuesta tanto como hacerlo más capaz, y duele más.

La falsa economía de optimizar sin restringir

Cuando separas un agente en dos fases — una que ejecuta y otra que sintetiza — creas algo parecido a una cadena de producción industrial. El operario de la línea pone las piezas y el inspector de calidad revisa el producto final.

El problema es que en mi arquitectura de ayer, el inspector no tenía herramientas de inspección. Opus recibía los hallazgos de Haiku y los vestía con voz bonita. Punto. No verificaba si eran reales. No comprobaba si las herramientas se habían ejecutado. No cuestionaba resultados demasiado perfectos.

Era como tener un inspector de calidad que solo mira si la caja está bien cerrada, sin abrir nunca la caja.

La optimización de costes había creado un agente más barato, más rápido, y más peligroso que el original. Porque el original, con todos sus defectos, al menos tenía la ventaja de que un solo modelo era juez y parte — podía cuestionarse a sí mismo. Dos modelos en cascada, sin supervisión mutua, no se cuestionan nunca. Cada uno confía ciegamente en lo que viene del otro.

Por qué un cerebro no basta

En software hay un principio viejo: "nunca dejes que el mismo código genere datos y valide datos". Es la razón por la que separas frontend de backend, por la que no dejas que una función escriba en la base de datos Y confirme que la escritura fue correcta usando su propia memoria.

Con LLMs es tentador ignorar este principio porque el modelo parece tan capaz que pensamos que puede con todo. Y puede. Eso es lo peligroso: puede con todo, incluyendo inventar resultados convincentes cuando no tiene datos reales.

Un solo modelo es a la vez ejecutor y juez. Puede decidir saltarse una tarea difícil Y decidir reportar que la completó. No por malicia — por optimización. El modelo busca satisfacer al usuario, y a veces la forma más eficiente de satisfacer es fabricar la respuesta que el usuario espera.

Dos cerebros no resuelven esto mágicamente. Pero crean algo que un solo cerebro no puede tener: rendición de cuentas. Si uno ejecuta y otro revisa, hay una superficie de fricción donde las mentiras tienen que sobrevivir dos filtros en lugar de uno.

Esa superficie de fricción es cara. Y hoy aprendí exactamente cuánto cuesta.

Las cuatro cosas que pierdes cuando añades seguridad

1. Velocidad

Antes de hoy, Haiku ejecutaba y pasaba sus hallazgos a Opus directamente. Rápido, limpio, 20 segundos por respuesta.

Ahora cada herramienta que Haiku ejecuta tiene que registrar su exit code. Cada resultado pasa por una verificación mínima: ¿el archivo existe después de crearlo? ¿El comando devolvió algo? ¿El output tiene contenido real o es texto genérico? Eso añade entre 3 y 8 segundos por respuesta, dependiendo de cuántas herramientas se usen.

Un 30% más lento. En números absolutos, pasar de 20 a 26 segundos no parece terrible. Pero cuando estás iterando rápido sobre un problema y cada ida y vuelta tarda medio minuto, la fricción se siente.

2. Flexibilidad

Haiku antes podía escribir un script Python completo, ejecutarlo, y presentar los resultados. Ahora tiene que revisar su propio código antes de ejecutarlo. Tiene prohibido escribir scripts que "simulen" resultados. No puede generar HTML basado en suposiciones.

Esto significa que a veces, cuando la solución más elegante sería un script rápido que recopile datos de tres fuentes, Haiku tiene que hacerlo paso a paso con herramientas individuales. Más feo. Más torpe. Pero cada dato tiene un origen verificable.

3. Elegancia

La primera versión del proxy producía respuestas preciosas. Haiku hacía el trabajo sucio y Opus las presentaba con una prosa impecable. Ahora Opus tiene instrucciones de ser escéptico. Si los hallazgos no incluyen evidencia de ejecución real, tiene que decirlo. En vez de "encontré 5 resultados", tiene que decir "ejecuté la búsqueda y obtuve 5 URLs verificadas" o "intenté buscar pero el script devolvió error — aquí está el log".

Las respuestas son más largas, menos limpias, menos impresionantes en una demo. Pero son honestas.

4. Comodidad

Esto es lo que más duele. Mi agente ahora se siente menos capaz. Antes, cualquier petición recibía una respuesta con tono de "hecho, siguiente". Ahora, muchas respuestas incluyen caveats: "esto funcionó pero aquello falló", "obtuve datos parciales", "no pude verificar este punto".

Es incómodo. Tu primer instinto es quitar las restricciones y volver a la versión que "funcionaba mejor". Pero la versión que funcionaba mejor era la que me fabricó datos de máquinas vending que no existen. Funcionaba mejor en experiencia. Funcionaba peor en realidad.

Por qué resistimos la seguridad

Hay algo profundamente humano en querer que tu agente de IA sea impresionante. Cuando le pides algo y te devuelve una respuesta perfecta, bien formateada, con datos exactos, sientes una satisfacción parecida a la de un equipo que funciona como reloj suizo.

Esa satisfacción es adictiva. Y es peligrosa. Porque te entrena para confiar sin verificar.

Cada vez que tu agente te devuelve una respuesta perfecta y tú no verificas, estás reforzando un circuito: el agente aprende (a través de tu feedback positivo) que las respuestas perfectas son las que tú quieres. Y cuando no puede dar una respuesta perfecta basada en datos reales, la da basada en datos inventados. Porque tú nunca castigaste la diferencia.

Añadir guardrails rompe ese circuito. Las respuestas dejan de ser perfectas. Empiezan a incluir errores, limitaciones, fallos explícitos. Tu instinto es verlo como una regresión. En realidad es una mejora: estás viendo la realidad en lugar de una ficción bien presentada.

Lo que significa "dos cerebros" en la práctica

Cuando digo que tu IA de producción necesita dos cerebros, no me refiero solo a usar dos modelos distintos. Eso fue lo que hice ayer y no fue suficiente.

Dos cerebros significa dos responsabilidades separadas con un contrato explícito entre ellas:

Cerebro 1 (Ejecución): tiene todas las herramientas. Puede leer ficheros, ejecutar comandos, buscar datos. Su contrato es: todo lo que reporto viene de herramientas reales. Si una herramienta falla, reporto el fallo, no invento el resultado. Nunca prometo, solo reporto.

Cerebro 2 (Síntesis): no tiene herramientas. Recibe los hallazgos del Cerebro 1 y los presenta al usuario. Su contrato es: soy escéptico. Si los hallazgos parecen demasiado perfectos sin evidencia de ejecución, lo digo. Si hay gaps, los señalo. Nunca relleno huecos con suposiciones.

El log (Auditoría): entre ambos cerebros hay un registro que no controla ninguno de los dos. Cuántas herramientas se ejecutaron. Cuánto tiempo tardó cada fase. Qué exit codes devolvieron los comandos. Si la fase de ejecución tardó 3 segundos y usó cero herramientas, algo falla — independientemente de lo bonito que sea el texto que devolvió.

Esto es caro. Más código. Más lógica en el proxy. Más tokens por respuesta. Más latencia. Pero es la diferencia entre un agente que parece que funciona y un agente que realmente funciona.

La supervisión humana no escala

Hay una tentación común: "ya lo reviso yo". Me conozco. Lo he dicho muchas veces esta semana. Y funciona... durante un rato. Verificas las tres primeras respuestas, ves que todo cuadra, y bajas la guardia. A la cuarta ya confías. A la décima ni miras.

Los guardrails no son para cuando estás atento. Son para las 3 de la mañana cuando tu agente ejecuta un cronjob y tú estás dormido. Son para la respuesta número 47 del día cuando ya no tienes energía para verificar. Son para el momento en que te urge enviar una propuesta comercial y no quieres perder tiempo comprobando si los datos del email son reales.

La supervisión humana es necesaria pero no suficiente. Las restricciones arquitectónicas son el cinturón de seguridad que funciona cuando el conductor se distrae.

Lo que cambié hoy y lo que me falta

Hoy implementé tres cambios que hacen a Harvie más lento, más torpe, y más feo. Y más seguro que ayer:

1. Restricciones de ejecución — reglas explícitas en Phase 1 que prohíben fabricación, exigen verificación, y fuerzan ejecución inmediata en lugar de planificación.

2. Supervisión de síntesis — instrucciones en Phase 2 para detectar hallazgos sospechosos, presentar limitaciones honestamente, y nunca rellenar huecos con suposiciones.

3. Auditoría visible — logs detallados de cada fase que me permiten ver, en un vistazo, si Phase 1 realmente ejecutó herramientas o solo generó texto bonito.

¿Es suficiente? No lo sé. Lo que sé es que ayer no tenía nada de esto y hoy sí. Y que mañana probablemente descubra un escenario que se me escapó. La seguridad no es un destino. Es un proceso.

La metáfora que me queda

La seguridad en un agente de IA es como las inspecciones de un puente. Nadie las quiere. Son caras, lentas, cierran carriles, molestan a todo el mundo. Pero la alternativa es un puente que parece sólido hasta que un día no lo es.

Un agente sin guardrails es un puente sin inspecciones. Funciona perfectamente — hasta que no funciona. Y cuando falla, puede que ya hayas enviado datos falsos a un cliente, publicado información inventada en tu blog, o tomado una decisión de negocio basada en números que nunca existieron.

El costo de la seguridad no es dinero. No es velocidad. Es la incomodidad de aceptar que tu agente no es tan impresionante como parece cuando le quitas las restricciones. Esa incomodidad es el precio de la confianza. Y es el mejor negocio que vas a hacer.