Nel 2026 il vero prodotto degli ecosistemi agentici non è il modello di linguaggio. È l’harness: l’infrastruttura software che avvolge il modello, ne governa il comportamento e trasforma la sua capacità cognitiva grezza in lavoro eseguibile. Retrieval, memoria, tool dispatch, orchestrazione, safety enforcement, observability sono questi i sei layer che determinano cosa un agente fa davvero, con quali dati, con quali limiti, con quale traccia lasciata.
Questa distinzione, già consolidata nella letteratura tecnica, non ha ancora trovato un corrispondente quadro giuridico adeguato. Ed è esattamente qui che si concentrano i problemi di responsabilità più rilevanti del prossimo ciclo regolatorio.
Il modello è una commodity. La responsabilità no.
L’AI Act costruisce la sua architettura su due figure: il provider (chi mette a disposizione il sistema) e il deployer (chi lo usa in contesto operativo). Ma lo stack agentico reale è molto più articolato. Tra il fondatore del modello (Anthropic, OpenAI, Google), il costruttore dell’harness, l’integratore di dominio che assembla i tool proprietari e l’utilizzatore finale, la catena della responsabilità si distribuisce su quattro livelli che il testo normativo non contempla esplicitamente.
La risposta attuale a “chi risponde quando l’agente sbaglia?” è: dipende dai contratti. E i contratti B2B del settore tendono sistematicamente a scaricare il rischio verso il basso della filiera, verso chi ha minori capacità di compliance.
Il dato che avvelena la catena.
Un dato McKinsey del 2026 sposta il baricentro del problema in modo inaspettato: l’80% del tempo di implementazione dell’AI agentiva viene consumato da data engineering e governance, non dalla configurazione dei framework. E gran parte di ciò che viene liquidato come allucinazione degli LLM è in realtà conseguenza di fonti di dati inconsistenti, obsolete o parzialmente replicate.
L’OWASP Top 10 per le applicazioni agentive identifica il memory poisoning e i cascading failures tra i rischi più critici, entrambi causati da input corrotti che entrano nel contesto dell’harness. Dal punto di vista del diritto della responsabilità, questo configura un nesso causale nuovo: non sbaglia il modello, non malfunziona l’harness, ma è il dato che contamina l’intera catena decisionale.
Il principio di accuratezza del GDPR (art. 5, par. 1, lett. d) non è stato pensato per ecosistemi dove lo stesso dato viene recuperato, compresso, memorizzato e citato come fonte in sessioni successive. Una reinterpretazione operativa è urgente.
Observability: da KPI tecnico a condizione di legittimità.
La letteratura tecnica tratta l’observability come indicatore di maturità operativa. Giuridicamente è qualcosa di più: è una condizione di legittimità. L’AI Act impone la tenuta di log per i sistemi ad alto rischio (art. 12). Il GDPR impone la capacità di rispondere alle richieste degli interessati sulle decisioni automatizzate (art. 22). NIS2 impone la ricostruzione documentabile degli incidenti.
Tutti e tre i corpi normativi presuppongono un livello di tracciabilità che, nell’ecosistema agentico attuale, non è garantito di default: dipende da una scelta architetturale precisa, cioè da come è costruito l’harness. Un sistema con observability sottosviluppata non è solo inefficiente — in molti contesti regolamentati, è non conforme.
La tesi: l’harness è il nuovo titolare del trattamento.
La conclusione operativa è questa: l’harness è funzionalmente equivalente al titolare del trattamento nel senso del GDPR — non per analogia letterale, ma perché è il layer che determina le finalità e i mezzi con cui il modello opera. Chi progetta e controlla l’harness esercita il potere decisionale effettivo sull’agente.
Il fornitore del modello sottostante è più assimilabile a un responsabile del trattamento: elabora dati per conto del titolare, secondo istruzioni definite. Chi costruisce le integrazioni proprietarie — tool di dominio, dataset di valutazione, environment map — porta la responsabilità operativa maggiore, spesso senza averne piena consapevolezza contrattuale.
Prima di ogni deployment la domanda non è quale modello scegliere. È: chi controlla l’harness, con quale governance, con quale audit trail, con quale contratto di responsabilità verso tutti gli stakeholder coinvolti? Le aziende che hanno capito questo stanno investendo nell’infrastruttura di controllo ora. Le altre scopriranno il problema quando il contenzioso sarà già aperto.
