Il permesso è più grande del compito: documentare i connettori dell'IA

Immaginate una mattina qualsiasi in uno studio professionale, o nell’ufficio di una piccola impresa. Qualcuno apre l’assistente di IA e scrive una richiesta banale: riassumimi le mail di oggi e rispondi a quelle urgenti. Pochi secondi dopo il riassunto è pronto, due risposte sono già partite e la giornata può cominciare. In quel momento nessuno si chiede che cosa sia successo davvero dietro lo schermo.

È successo che il sistema è andato a prendersi i dati da solo. Per farlo ha usato un connettore, cioè un collegamento che gli consente di entrare in un servizio esterno, oppure un server MCP, che fa la stessa cosa attraverso un protocollo comune pensato per collegare i modelli linguistici a strumenti e archivi. Per chi ragiona da giurista il punto non è tecnico. Prima eravamo noi a decidere quali dati consegnare a uno strumento. Oggi gli consegniamo una chiave, e lui sceglie di volta in volta quali porte aprire.

E la chiave, di solito, apre tutto. Il permesso concesso al momento della configurazione raramente si limita alle mail del giorno: copre l’intera casella, spesso con anni di archivio, e insieme alla lettura comprende quasi sempre anche l’invio. Il compito è piccolo, il permesso enorme. Secondo me è questa distanza il vero oggetto di cui dovremmo occuparci quando parliamo di protezione dei dati negli agenti di IA.

Pensate a cosa contiene davvero una casella di posta. Ci sono i dati di chi la usa, certo, ma soprattutto quelli di chi ci scrive: clienti, fornitori, candidati, perfetti sconosciuti. Nessuno di loro ha scelto di essere letto da un agente, e molti non lo sapranno mai. Poi ci sono le cose che arrivano per caso, come un certificato medico allegato a una richiesta di rinvio o una mail in cui qualcuno racconta la propria situazione familiare. Sono categorie particolari di dati, che l’art. 9 GDPR protegge in modo rafforzato, e nessuno le ha cercate.

Qui si vede la differenza tra uso effettivo e accesso potenziale. Quella mattina l’agente ha letto forse venti messaggi. Ma avrebbe potuto leggerne ventimila, e basterebbe una richiesta formulata in modo diverso perché lo faccia. Il GDPR conosce questo problema, anche se non lo chiama così. C’è la minimizzazione dell’art. 5, par. 1, lett. c), e soprattutto la protezione per impostazione predefinita dell’art. 25, par. 2, che chiede di trattare di default solo i dati necessari per ciascuna finalità, anche quanto alla loro accessibilità. Un permesso sull’intera casella per riassumere le mail del giorno è difficile da far rientrare in quella logica.

La posta ha poi una caratteristica che altri archivi non hanno: chiunque può scriverci. Una mail può contenere istruzioni nascoste, magari in testo bianco su fondo bianco, che l’agente legge come se fossero un ordine. È la cosiddetta prompt injection. OWASP, nella sua classifica dei rischi delle applicazioni basate su modelli linguistici, la affianca a quella che chiama excessive agency, cioè un agente con più permessi o autonomia del necessario. Messe insieme, le due cose spiegano perché il permesso di invio non è un dettaglio: decide se i dati possono uscire dalla casella su ordine di un estraneo.

La proposta che faccio, e che presento come buona pratica e non come obbligo, perché nessuna norma parla espressamente di connettori, è semplice. Per ogni connettore o server MCP collegato a un sistema di IA andrebbe compilata una scheda. Niente di sofisticato. La prima voce riguarda le fonti, cioè dove arriva davvero il connettore. Una casella sola o tutte quelle dell’organizzazione, solo la posta in arrivo o anche l’archivio e gli allegati, e magari il calendario e la rubrica, che spesso viaggiano nello stesso pacchetto.

La seconda voce riguarda i permessi, e qui conviene essere pignoli. Leggere, rispondere, inoltrare e cancellare sono livelli di rischio molto diversi, e la scheda dovrebbe dire quali sono stati concessi e perché. Vale la pena annotare anche se l’agente chiede conferma prima di inviare qualcosa o se agisce da solo. Tra un suggerimento e un’azione già compiuta passa la stessa differenza che separa un errore rimediabile da uno che non lo è.

La terza voce è la più trascurata: chi gestisce il server. Un server MCP può essere offerto dal fornitore della posta, da quello del sistema di IA o da uno sviluppatore terzo che in organizzazione nessuno ha mai sentito nominare. Da questa risposta dipende la qualificazione giuridica di quel soggetto, e quindi se serve un contratto con il responsabile ai sensi dell’art. 28 GDPR. Ne dipende anche la mappa dei flussi: dove transitano i messaggi, in quali paesi vengono elaborati e se escono dallo Spazio economico europeo, con le garanzie richieste dagli artt. 44 e seguenti.

L’ultima voce riguarda ciò che il sistema ottiene e trattiene. Un agente non si limita a leggere: produce riassunti, a volte costruisce una memoria delle conversazioni precedenti, quasi sempre lascia dei log. Sono copie parziali dei messaggi originali, ma spesso molto eloquenti. La scheda dovrebbe dire dove finiscono, per quanto tempo restano e se il fornitore può riutilizzarle per altri scopi, perché una mail cancellata dalla casella può sopravvivere benissimo nel registro di un agente.

Anche senza un obbligo espresso, tutto questo ha un fondamento preciso nell’accountability. Gli artt. 5, par. 2, e 24 GDPR chiedono al titolare di rispettare le regole e anche di essere in grado di dimostrarlo, e non vedo come si possa dimostrare la conformità di un trattamento di cui non si conosce il perimetro. Una volta compilata, la scheda alimenta quasi da sola i documenti che già esistono: il registro dei trattamenti dell’art. 30, le informative degli artt. 13 e 14, le misure di sicurezza dell’art. 32 e, quando è dovuta, la valutazione d’impatto dell’art. 35.

Lo stesso vale, in prospettiva, per la valutazione d’impatto sui diritti fondamentali che l’art. 27 dell’AI Act impone ad alcuni deployer di sistemi ad alto rischio. Va detto con onestà che un assistente che riassume la posta quasi mai rientra in quella categoria. Se però lo stesso agente, con gli stessi connettori, venisse usato in un contesto ad alto rischio, la descrizione dei processi, delle persone coinvolte e dei rischi partirebbe proprio da lì. E l’obbligo di aggiornare la valutazione quando quegli elementi cambiano, previsto dallo stesso articolo, avrebbe nella scheda il suo punto di riferimento.

So già quale sarà l’obiezione: un altro documento, altra burocrazia, quando il GDPR offre già tutti gli strumenti necessari. È vero solo in parte. Il registro descrive finalità, categorie di dati e destinatari, ma dei permessi non dice nulla. Scrivere “dati di contatto e contenuto della corrispondenza” non racconta che un agente può leggere dieci anni di archivio e spedirne una parte a chiunque. La scheda non si aggiunge agli adempimenti, sta a monte. E serve soprattutto dove nessuna valutazione d’impatto è obbligatoria, cioè nella maggior parte dei casi, perché lì nessun altro documento descriverebbe quel perimetro.

Resta un’ultima ragione per tenerla aggiornata. Aggiungere un connettore richiede un clic, ampliare un permesso un altro, e oggi nessuno dei due passaggi spinge qualcuno a fermarsi e riflettere. Il perimetro di un agente può così crescere in silenzio per mesi. Mi chiedo se non dovremmo trattarlo come tratteremmo un nuovo collaboratore, a cui nessuno consegnerebbe il primo giorno le chiavi dell’intero archivio solo perché deve smistare la posta del mattino. Perché con l’IA ci sembra normale farlo?