Hi ha una diferència fonamental entre un agent IA que funciona en demo i un agent que passa una auditoria regulatòria. La demo la guanyes amb un model bo i un prompt acurat. L'auditoria la perds, o la guanyes, en l'arquitectura que va triar el teu equip sis mesos abans.
El 2 d'agost de 2026 entren en aplicació les obligacions centrals de l'EU AI Act per a sistemes d'alt risc. En aquesta data — a poc més de tres mesos d'avui — els agents desplegats en banca, assegurances, salut, pharma, selecció de personal, scoring creditici o educació han de complir requisits formals: gestió de riscos, documentació tècnica, logging automàtic, supervisió humana, robustesa, ciberseguretat i vigilància post-mercat. Les multes per incompliment arriben fins a 15 milions d'euros o el 3% de la facturació global anual, la xifra que sigui més gran.
La majoria d'equips amb qui parlem té agents funcionals desplegats en entorns regulats. Gairebé cap els ha dissenyat pensant en com es reconstrueix una decisió concreta davant d'un auditor. Aquest gap no es tanca amb una capa de logging afegida a sobre. Es tanca dissenyant l'agent com un sistema auditable des de la primera spec.
EU AI Act 2026: la finestra de compliment
Fonts: Reglament (UE) 2024/1689 · Comissió Europea · AI Act Service Desk
Què significa compliance-first (i què no)
Compliance-first AI design és exactament el contrari de retrofit compliance. En retrofit compliance, l'equip construeix l'agent, el desplega, algú del costat legal descobreix tres mesos després que falta documentació tècnica i traçabilitat, i s'obre un sprint per "afegir els logs que demana l'auditor". En aquell moment, ja és tard: les dades d'entrenament no estan versionades, les decisions passades no es poden reconstruir i l'arquitectura no permet bloquejar accions sensibles sense reescriure l'orquestració.
Compliance-first significa que cada requisit regulatori es tradueix en una decisió d'arquitectura abans d'escriure la primera línia de codi. Què es logueja, amb quina granularitat i on. Quines accions requereixen validació humana i com s'apliquen els circuit breakers. Quina documentació tècnica es genera automàticament cada vegada que una versió de l'agent es promou a producció. Quins criteris d'acceptació ha de complir un output per considerar-se vàlid — i com s'evidencia que els compleix.
És la mateixa disciplina que apliquem en DevSecOps: la seguretat no s'afegeix al final, es dissenya des de l'inici. Amb l'EU AI Act, el principi s'estén al govern de l'agent. Governance-first no és overhead addicional; és l'únic patró que escala quan el regulador pregunta.
Els 9 requisits de l'EU AI Act que es tradueixen a arquitectura
El Capítol III de l'EU AI Act defineix els requisits per a sistemes d'alt risc. Llegits amb lent d'arquitectura de programari, es tradueixen en nou decisions tècniques concretes que un CTO ha de prendre abans de desplegar l'agent. No són nou documents legals: són nou components de sistema.
Procés documentat, iteratiu i actualitzat per identificar, avaluar i mitigar riscos al llarg del cicle de vida de l'agent. En arquitectura: un registre de riscos versionat al repo, revisat a cada release, amb mesures de mitigació traçables a components del sistema.
Datasets d'entrenament, validació i prova rellevants, representatius, lliures d'errors i complets. Per a agents amb retrieval, inclou els corpora indexats. En arquitectura: data lineage traçable, hashes de datasets per versió, procediments de bias assessment.
Descripció del sistema, el seu desenvolupament, tests, mètriques de rendiment i mesures de mitigació. Ha d'estar llesta abans de posar el sistema al mercat. En arquitectura: docs generades des del codi (specs, model cards, ADRs) amb un pipeline que les actualitza a cada release.
Registre automàtic d'esdeveniments durant el funcionament, amb un nivell de detall suficient per identificar situacions de risc i permetre vigilància post-mercat. En arquitectura: event log estructurat, immutable, amb correlació per sessió i decisions traçables al prompt, tool calls, dades recuperades i output final.
Instruccions d'ús clares: capacitats, limitacions, riscos, rendiment esperat per context d'ús. En arquitectura: model card versionada, exposada per API, consultable per l'operador humà en temps d'inferència.
Mecanismes efectius perquè una persona pugui entendre l'output, decidir no fer-lo servir, intervenir o aturar el sistema. En arquitectura: human-in-the-loop graduat per risc, botó de kill switch, UI d'explicació de decisions, registre d'overrides humans.
Mètriques d'accuracy declarades, resistència a inputs adversarials i atacs de prompt injection, mesures de fail-safe. En arquitectura: suite d'avaluació automàtica, red-teaming continu, detecció d'anomalies i degradació del model.
Polítiques, procediments i instruccions escrites per al disseny, verificació, validació i gestió de canvis. En arquitectura: el CI/CD i la governança del repo són part del QMS. Cada canvi en l'agent deixa traça en un sistema de control de versions auditat.
Recol·lecció activa de dades de funcionament després del desplegament i notificació d'incidents greus a l'autoritat en terminis definits. En arquitectura: telemetria contínua, dashboard de quality monitoring, runbook d'incident response amb canal cap a l'autoritat competent.
Un equip que construeix l'agent pensant primer en aquests nou components no passarà l'auditoria per sort. La passarà perquè l'agent està dissenyat per ser auditable. El que no — per molt model premium que faci servir — arribarà al 2 d'agost amb el mateix problema que descrivim a el gap de qualitat dels agents IA en producció: observabilitat sense governança.
Arquitectura de referència: les 5 capes d'un agent audit-ready
La forma neta d'organitzar aquestes responsabilitats és una arquitectura de cinc capes on cada capa té una pregunta de l'auditor associada. Quan la capa existeix i està ben dissenyada, la pregunta es contesta amb evidència; quan falta, la pregunta es contesta amb nerviosisme.
Specification layer — specs i criteris d'acceptació
Per a cada cas d'ús, una spec amb input esperat, output esperat, criteris de qualitat, modes de fallada i accions davant excepció. Pregunta de l'auditor: "Com sabeu que l'agent compleix amb el seu propòsit declarat?"
Execution layer — orquestració i guardrails
El motor que executa l'agent (Managed Agents, LangGraph, harness propi) amb polítiques d'scope aplicades abans de cada tool call, validació d'output i circuit breakers automàtics. Pregunta de l'auditor: "Què impedeix que l'agent faci alguna cosa que no ha de fer?"
Evidence layer — logging estructurat i immutable
Cada interacció genera un esdeveniment traçable: prompt, context recuperat, tool calls, outputs intermedis, decisió final, intervenció humana. Logs append-only, signats i retinguts pel termini regulatori. Pregunta de l'auditor: "Reconstrueix la decisió X del 14 de juliol."
Oversight layer — supervisió humana i post-market
UI que permet a un operador entendre, aprovar, rebutjar o aturar l'agent. Dashboard de quality monitoring, procés de revisió d'incidents i canal al regulador. Pregunta de l'auditor: "Com sap l'operador humà quan i com intervenir?"
Aquesta arquitectura no és una arquitectura nova que cal inventar per a l'EU AI Act. És l'arquitectura que els equips que ja han passat auditories en sectors regulats (banca, assegurances, salut) fan servir des de fa temps, adaptada a la naturalesa no determinista de l'agent. El que canvia és que a partir d'agost deixa de ser bona pràctica i passa a ser obligació per llei.
Per què Spec-Driven Development és la base natural del compliance-first
Com desenvolupem a Spec-Driven Development: IA en codi controlat, SDD eleva l'especificació a font de veritat per damunt del codi. Quan l'agent es construeix contra una spec estructurada — constitució, templates de spec, playbook de prompts, flux de review — els nou requisits de l'EU AI Act deixen de ser artefactes separats i passen a ser subproductes del procés de desenvolupament.
Mapatge SDD → Requisits EU AI Act
El que és important d'aquest mapatge no és que SDD sigui l'única forma de complir l'EU AI Act. És que si ja estàs aplicant SDD de debò, tens la major part de la feina feta: els artefactes de la metodologia són la documentació tècnica que exigeix l'Annex IV. Els equips que no tenen aquesta disciplina descobriran que la seva "documentació" és un Notion desordenat i un backlog de prompts sense versionar — material insuficient per a un conformity assessment.
Aquest patró és idèntic al que expliquem a SDD + Agentic Orchestration: la spec és la policy layer, el motor d'execució és substituïble. Amb compliance-first, aquesta separació guanya a més una propietat regulatòria — la spec és l'artefacte que l'auditor revisa.
Tres casos on compliance-first canvia el resultat
Per baixar la conversa al terreny, tres escenaris concrets en què un agent dissenyat compliance-first sobreviu a l'auditoria i un retrofit no.
1. Scoring creditici automatitzat
Un agent que rebutja o aprova una sol·licitud de crèdit cau de ple a l'Annex III, àrea 5(b). L'auditor pot demanar la reconstrucció completa de qualsevol decisió: quines features es van fer servir, quins pesos van tenir, quines alternatives va avaluar el model, quina supervisió humana hi va haver abans de comunicar el resultat al client. Sense Evidence layer des del dia u, aquesta reconstrucció no és possible: els logs d'app standard no capturen tool calls, tokens consumits ni versions del prompt. Amb compliance-first, cada decisió té un event ID i una cadena completa reproduïble.
2. Classificació de reclamacions en assegurances
Un agent que categoritza i prioritza sinistres — salut, auto, llar — toca dades personals i té conseqüències directes per a l'assegurat. El risc principal no és que la categorització sigui errònia aïllada; és que sistemàticament perjudiqui certs perfils. L'Art. 10 exigeix govern de dades i avaluació de biaix. Un agent retrofit descobreix el biaix quan arriba la denúncia. Un agent compliance-first el detecta a l'Evidence layer abans que escali, perquè la suite d'avaluació contínua està monitoritzant la distribució d'outputs per segment protegit.
3. Suport clínic en pharma/healthtech
Un agent que ajuda un metge a interpretar imatges, proposar dosificacions o resumir història clínica és alt risc per definició. La supervisió humana ha de ser efectiva, no merament declarada. Si el metge aprova amb un clic sense context, la supervisió falla com a control. En compliance-first, l'Oversight layer obliga a mostrar l'evidència — quins passatges de l'historial, quines guies clíniques, quin nivell de confiança — abans de permetre aprovació. Fa la supervisió real i la deixa registrada.
Stack mínim per arribar al 2 d'agost: 8 setmanes de treball honest
Si avui tens un agent en producció en sector regulat i no l'has dissenyat compliance-first, el camí realista no és reescriure'l sencer. És instrumentar per capes en un ordre que maximitzi el valor regulatori de cada sprint.
Classificar el sistema (alt risc / limitat / mínim) segons l'Annex III. Obrir el risk register i documentar els riscos identificats. Aquest pas és el que justifica (o no) tota la resta de l'esforç.
Escriure la constitució de l'agent i les specs per cas d'ús. Declarar capacitats, limitacions i modes de fallada. Aquesta és la base de l'Art. 13 (transparència) i de l'Annex IV (documentació tècnica).
Afegir logging estructurat i immutable a nivell d'esdeveniment: prompt, context, tool calls, output, overrides. Retenció pel termini regulatori. Si aquest pas no existeix avui, és el de major impacte legal.
UI de supervisió humana efectiva, kill switch, procediment d'escalat, canal a l'autoritat competent. Cobreix Art. 14 i Art. 73.
Revisió interna amb checklist de l'Annex IV, correcció de gaps, preparació del dossier tècnic. Idealment validat per un auditor extern abans del 2 d'agost.
Vuit setmanes ben organitzades són un pla realista si l'equip té el criteri tècnic per prioritzar. Deixa de ser-ho si la conversa de compliance comença al juny. Per això els 90 dies previs a la data d'aplicació són la finestra que importa.
L'insight estratègic: compliance-first no és un cost extra sobre l'agent. És l'única arquitectura que permet desplegar agents IA a Europa amb la mateixa velocitat amb què els vas desplegar abans de l'EU AI Act. Sense ella, cada release nova és un risc legal no quantificat.
Dos escenaris per al 2 d'agost
A 105 dies de la data d'aplicació, cada equip amb agents en sectors regulats té dos escenaris realistes al davant. No són escenaris teòrics: són la diferència entre poder continuar entregant valor al negoci o haver de parar a arreglar el sistema.
Escenari A · arribar compliance-first. Els agents passen auditoria sense aturades, el dossier de l'Annex IV es genera automàticament des de les specs i cada feature nova es desenvolupa ja dins del marc regulatori. La conversa amb legal i amb el regulador se sosté amb evidències en lloc de amb PowerPoints. Operativament, res canvia: el roadmap segueix.
Escenari B · retrofit compliance a l'estiu. Entre juny i agost, l'equip descobreix que falten logs estructurats, dades d'entrenament sense traçabilitat, processos de supervisió humana només de boquilla i documentació tècnica incompleta. S'obren sprints per tapar-ho. El roadmap es bloqueja. En el pitjor cas, l'agent s'apaga fins que el dossier estigui llest — i l'àrea de negoci, que ja havia integrat l'agent en el seu flux, perd capacitat operativa. A això se suma l'exposició a multes de fins al 3% de la facturació global si un incident o una inspecció arriba abans de tancar el gap.
El cost d'arribar a l'escenari A són vuit setmanes de treball tècnic ben dirigit. El cost d'arribar a l'escenari B és més alt en temps, en roadmap perdut i en exposició legal. Per això la finestra importa: en els 90 dies previs a la data d'aplicació, cada setmana que es retarda la conversa tècnica de compliance és una setmana que després costa el doble recuperar.
L'EU AI Act no prohibeix desplegar agents IA. Exigeix poder explicar, demostrar i reconstruir el que fa cadascun. Aquest és un problema d'arquitectura, no de compliment formal. I és exactament el problema que Spec-Driven Development porta resolent des d'abans que fos obligatori.
Fonts principals: Reglament (UE) 2024/1689 del Parlament Europeu i del Consell ("EU AI Act"), articles 5, 6, 9-17, 72-73 i Annexos III-IV; "Implementation Timeline" (AI Act Service Desk, Comissió Europea); "Guidelines for providers of general-purpose AI models" (European Commission Digital Strategy); "EU AI Act Compliance: a technical audit guide for the 2026 deadline" (Raconteur); "The EU AI Act: 6 Steps to Take Before 2 August 2026" (Orrick, 2025); "High-Risk AI Systems Under the EU AI Act" (DLA Piper, ISACA White Paper 2024).
Lectura complementària: SDD + Agentic Orchestration | Spec-Driven Development: IA en codi controlat | Agents IA en producció: el gap de qualitat | DevSecOps: seguretat integrada des de l'inici
Metodologia onext: onext AI-Accelerated Development integra compliance-first AI design en la metodologia SDD amb què els Centres d'Excel·lència d'IA d'onext construeixen agents per a sectors regulats: fintech, assegurances, pharma i healthtech. Specs, evidence layer i oversight layer com a part del flux d'entrega — no com un projecte a part de compliance. Sense paralitzar lliuraments.
Jordi García és Tech Lead a onext. Treballa a portar la IA a producció governada en equips de desenvolupament i de producte —amb Spec-Driven Development, enginyeria de context i verificació humana a cada pas— i signa els insights tècnics d'onext sobre mètode, qualitat i cost de la IA aplicada.
LinkedIn →