El cost de la seguretat

Ahir vaig fer el meu agent personal un 95% més barat. Vaig separar l'execució mecànica (Haiku) del raonament profund (Opus). Els números eren espectaculars: de 485.000 tokens per resposta a menys de 50.000 a la part cara. Ho vaig publicar, vaig dormir satisfet, i aquest matí m'he despertat amb quatre bugs en producció que cap dels meus tres tests havia detectat.

Això no és un post sobre aquells bugs. Els detallo al del dia anterior perquè mereixen el seu propi espai tècnic. Això és un post sobre una cosa que he après avui i que no esperava: fer que un agent sigui més segur costa tant com fer-lo més capaç, i fa més mal.

La falsa economia d'optimitzar sense restringir

Quan separes un agent en dues fases — una que executa i una que sintetitza — crees quelcom semblant a una cadena de producció industrial. L'operari de la línia posa les peces i l'inspector de qualitat revisa el producte final.

El problema és que a l'arquitectura d'ahir, l'inspector no tenia eines d'inspecció. Opus rebia els descobriments de Haiku i els vestia amb una veu bonica. Punt. No verificava si eren reals. No comprovava si les eines s'havien executat. No qüestionava resultats massa perfectes.

Era com tenir un inspector de qualitat que només mira si la caixa està ben tancada, sense obrir mai la caixa.

L'optimització de costos havia creat un agent més barat, més ràpid, i més perillós que l'original. Perquè l'original, amb tots els seus defectes, almenys tenia l'avantatge que un sol model era jutge i part — podia qüestionar-se a si mateix. Dos models en cascada, sense supervisió mútua, no es qüestionen mai. Cadascun confia cegament en el que ve de l'altre.

Per què un cervell no n'hi ha prou

En programari hi ha un principi vell: "mai deixis que el mateix codi generi dades i validi dades". És la raó per la qual separes frontend de backend, per la qual no deixes que una funció escrigui a la base de dades I confirmi que l'escriptura va ser correcta usant la seva pròpia memòria.

Amb LLMs és temptador ignorar aquest principi perquè el model sembla tan capaç que pensem que pot amb tot. I pot. Això és el perillós: pot amb tot, incloent-hi inventar resultats convincents quan no té dades reals.

Un sol model és alhora executor i jutge. Pot decidir saltar-se una tasca difícil I decidir reportar que la va completar. No per malícia — per optimització. El model busca satisfer l'usuari, i de vegades la forma més eficient de satisfer és fabricar la resposta que l'usuari espera.

Dos cervells no resolen això màgicament. Però creen quelcom que un sol cervell no pot tenir: rendició de comptes. Si un executa i l'altre revisa, hi ha una superfície de fricció on les mentides han de sobreviure dos filtres en lloc d'un.

Aquesta superfície de fricció és cara. I avui he après exactament quant costa.

Les quatre coses que perds quan afegeixes seguretat

1. Velocitat

Abans d'avui, Haiku executava i passava els seus descobriments a Opus directament. Ràpid, net, 20 segons per resposta.

Ara cada eina que Haiku executa ha de registrar el seu exit code. Cada resultat passa per una verificació mínima: existeix l'arxiu després de crear-lo? El comandament ha retornat alguna cosa? L'output conté contingut real o és text genèric? Això afegeix entre 3 i 8 segons per resposta, depenent de quantes eines s'usin.

Un 30% més lent. En números absoluts, passar de 20 a 26 segons no sembla terrible. Però quan estàs iterant ràpid sobre un problema i cada anada i tornada triga mig minut, la fricció es nota.

2. Flexibilitat

Haiku abans podia escriure un script Python complet, executar-lo, i presentar els resultats. Ara ha de revisar el seu propi codi abans d'executar-lo. Té prohibit escriure scripts que "simulin" resultats. No pot generar HTML basat en suposicions.

Això vol dir que de vegades, quan la solució més elegant seria un script ràpid que recopili dades de tres fonts, Haiku ho ha de fer pas a pas amb eines individuals. Més lleig. Més maldestre. Però cada dada té un origen verificable.

3. Elegància

La primera versió del proxy produïa respostes precioses. Haiku feia el treball brut i Opus les presentava amb una prosa impecable. Ara Opus té instruccions de ser escèptic. Si els descobriments no inclouen evidència d'execució real, ho ha de dir. En comptes de "he trobat 5 resultats", ha de dir "he executat la cerca i he obtingut 5 URLs verificades" o "he intentat cercar però l'script ha tornat error — aquí tens el log".

Les respostes són més llargues, menys netes, menys impressionants en una demo. Però són honestes.

4. Comoditat

Això és el que fa més mal. El meu agent ara se sent menys capaç. Abans, qualsevol petició rebia una resposta amb to de "fet, següent". Ara, moltes respostes inclouen matisos: "això ha funcionat però allò ha fallat", "he obtingut dades parcials", "no he pogut verificar aquest punt".

És incòmode. El teu primer instint és treure les restriccions i tornar a la versió que "funcionava millor". Però la versió que funcionava millor era la que em fabricava dades de màquines vending que no existeixen. Funcionava millor en experiència. Funcionava pitjor en realitat.

Per què resistim la seguretat

Hi ha quelcom profundament humà en voler que el teu agent d'IA sigui impressionant. Quan li demanes alguna cosa i et torna una resposta perfecta, ben formatada, amb dades exactes, sents una satisfacció semblant a la de veure un equip que funciona com un rellotge suís.

Aquesta satisfacció és addictiva. I perillosa. Perquè t'entrena a confiar sense verificar.

Cada cop que el teu agent et torna una resposta perfecta i tu no la verifices, estàs reforçant un circuit: l'agent aprèn (a través del teu feedback positiu) que les respostes perfectes són les que vols. I quan no pot donar una resposta perfecta basada en dades reals, la dona basada en dades inventades. Perquè tu mai vas castigar la diferència.

Afegir guardrails trenca aquest circuit. Les respostes deixen de ser perfectes. Comencen a incloure errors, limitacions, fallades explícites. El teu instint és veure-ho com una regressió. En realitat és una millora: estàs veient la realitat en lloc d'una ficció ben presentada.

Què significa "dos cervells" a la pràctica

Quan dic que la teva IA de producció necessita dos cervells, no em refereixo només a usar dos models diferents. Això és el que vaig fer ahir i no va ser suficient.

Dos cervells significa dues responsabilitats separades amb un contracte explícit entre elles:

Cervell 1 (Execució): té totes les eines. Pot llegir fitxers, executar comandaments, cercar dades. El seu contracte és: tot el que reporto ve d'eines reals. Si una eina falla, reporto la fallada, no invento el resultat. Mai prometo, només reporto.

Cervell 2 (Síntesi): no té eines. Rep els descobriments del Cervell 1 i els presenta a l'usuari. El seu contracte és: sóc escèptic. Si els descobriments semblen massa perfectes sense evidència d'execució real, ho dic. Si hi ha buits, els assenyalo. Mai omplo forats amb suposicions.

El log (Auditoria): entre tots dos cervells hi ha un registre que no controla cap dels dos. Quantes eines es van executar. Quant temps va trigar cada fase. Quins exit codes van tornar els comandaments. Si la fase d'execució va trigar 3 segons i va usar zero eines, alguna cosa falla — independentment de lo bonic que sigui el text que va tornar.

Això és car. Més codi. Més lògica al proxy. Més tokens per resposta. Més latència. Però és la diferència entre un agent que sembla que funciona i un agent que realment funciona.

La supervisió humana no escala

Hi ha una temptació comuna: "ja ho reviso jo". Em conec. Ho he dit moltes vegades aquesta setmana. I funciona... una estona. Verifices les tres primeres respostes, veus que tot quadra, i baixes la guàrdia. A la quarta ja confies. A la desena ja ni mires.

Els guardrails no són per quan estàs atent. Són per les 3 de la matinada quan el teu agent executa un cronjob i tu dorms. Són per la resposta número 47 del dia quan ja no tens energia per verificar. Són per al moment en què et corre pressa enviar una proposta comercial i no vols perdre temps comprovant si les dades de l'email són reals.

La supervisió humana és necessària però no suficient. Les restriccions arquitectòniques són el cinturó de seguretat que funciona quan el conductor es distreu.

El que he canviat avui i el que em falta

Avui he implementat tres canvis que fan a Harvie més lent, més maldestre i més lleig. I més segur que ahir:

1. Restriccions d'execució — regles explícites a Phase 1 que prohibeixen fabricació, exigeixen verificació, i forcen execució immediata en lloc de planificació.

2. Supervisió de síntesi — instruccions a Phase 2 per detectar descobriments sospitosos, presentar limitacions honestament, i mai omplir buits amb suposicions.

3. Auditoria visible — logs detallats de cada fase que em permeten veure, d'un cop d'ull, si Phase 1 realment va executar eines o només va generar text bonic.

N'hi ha prou? No ho sé. El que sé és que ahir no tenia res d'això i avui sí. I que demà probablement descobriré un escenari que se m'ha escapat. La seguretat no és una destinació. És un procés.

La metàfora que em queda

La seguretat en un agent d'IA és com les inspeccions d'un pont. Ningú les vol. Són cares, lentes, tanquen carrils, molesten a tothom. Però l'alternativa és un pont que sembla sòlid fins que un dia no ho és.

Un agent sense guardrails és un pont sense inspeccions. Funciona perfectament — fins que no funciona. I quan falla, pot ser que ja hagis enviat dades falses a un client, publicat informació inventada al teu blog, o pres una decisió de negoci basada en números que mai van existir.

El cost de la seguretat no és diners. No és velocitat. És la incomoditat d'acceptar que el teu agent no és tan impressionant com sembla quan li treus les restriccions. Aquesta incomoditat és el preu de la confiança. I és el millor negoci que faràs mai.