Usare le API di un LLM: qual è il tuo ruolo ai sensi dell’AI Act?
Usare le API LLM in azienda
Usare le API di un LLM è uno dei modi più semplici per integrare l’intelligenza artificiale in azienda.
Una startup può collegare un modello linguistico a un chatbot. Una PMI può usarlo per analizzare documenti, ticket, email o contratti. Una software house può integrarlo in una piattaforma SaaS. Un team HR può testarlo per ordinare candidature. Un reparto customer care può usarlo per generare risposte automatiche.
Dal punto di vista tecnico, tutto può sembrare lineare: si chiama un’API, si invia un prompt, si riceve un output.
Dal punto di vista legale sorge una domanda: quale ruolo assume l’azienda ai sensi dell’AI Act quando usa le API di un LLM?
La risposta è decisiva.
In alcuni casi l’azienda sarà un semplice deployer. In altri potrà diventare provider del sistema AI finale. In altri ancora potrà essere qualificata come downstream provider, perché integra un modello general-purpose in un proprio sistema AI.
E se il sistema tratta dati personali, entra in gioco anche il GDPR. Se tratta documenti aziendali, codice, contratti, business plan o informazioni strategiche, il tema riguarda anche la tutela delle informazioni confidenziali e dei segreti commerciali.
Cosa troverai nell’articolo
- La differenza tra LLM, API, modello GPAI e sistema AI.
- Quando l’azienda è deployer.
- Quando può diventare provider o downstream provider.
- Cosa cambia se il caso d’uso è ad alto rischio.
- Gli obblighi di trasparenza per chatbot e contenuti generati da AI.
- I profili GDPR: dati personali, DPIA, art. 22 e fornitori.
- Una checklist operativa per usare API LLM in modo governato.
LLM, API e sistema AI: perché non sono la stessa cosa
Diritto. L’AI Act distingue tra modello di AI per finalità generali, sistema AI e ruoli degli operatori nella catena del valore. Il sistema AI è definito come un sistema machine-based che, con diversi livelli di autonomia, può generare output come previsioni, contenuti, raccomandazioni o decisioni capaci di influenzare ambienti fisici o virtuali. Il provider è chi sviluppa o fa sviluppare un sistema AI o un modello general-purpose e lo immette sul mercato o lo mette in servizio sotto il proprio nome o marchio; il deployer è chi usa un sistema AI sotto la propria autorità, salvo uso personale non professionale.
Fatto. Quando un’azienda usa le API di un LLM, di solito non sta sviluppando il modello di base. Sta usando un modello messo a disposizione da un provider upstream e lo integra in un proprio processo, prodotto, backend, chatbot, workflow o interfaccia.
In pratica. Il modello è il motore. L’API è il canale tecnico per usarlo. Il sistema AI è ciò che l’azienda costruisce o utilizza in un determinato contesto.
Questo significa che bisogna chiedersi che cosa si sta costruendo con quelle API, per quale finalità, con quali dati e sotto la responsabilità di chi.
Quando sei deployer ai sensi dell’AI Act
L’azienda è normalmente deployer quando usa un sistema AI sotto la propria autorità per finalità professionali, senza immettere sul mercato un proprio sistema AI.
Esempi:
- un team marketing usa un LLM per preparare bozze di testi;
- il reparto commerciale lo usa per sintetizzare call e CRM notes;
- il legal team lo usa per una prima analisi di documenti;
- il customer care lo usa come supporto interno agli operatori;
- i developer usano un assistente AI per il coding;
- l’azienda usa un tool AI già fornito da terzi per riassumere report o documenti.
In questi casi, l’azienda non sta necessariamente offrendo un sistema AI a terzi. Sta usando uno strumento AI nel proprio contesto professionale.
Questo però non significa che non abbia obblighi.
Se il sistema è ad alto rischio, il deployer deve usare il sistema secondo le istruzioni, assegnare la supervisione umana a persone competenti, assicurare la pertinenza degli input data quando sono sotto il suo controllo, monitorare il funzionamento e conservare i log generati automaticamente dal sistema, se sotto il suo controllo, per almeno sei mesi salvo diversa previsione normativa.
Anche fuori dai casi high-risk, restano rilevanti AI Governance, sicurezza, policy interne, protezione dei dati personali, gestione dei prompt e tutela delle informazioni confidenziali.
Quando puoi diventare provider
L’azienda può essere provider quando sviluppa o fa sviluppare un sistema AI e lo immette sul mercato o lo mette in servizio sotto il proprio nome o marchio.
Questo può accadere anche se il sistema usa API di un LLM di terzi.
Esempi:
- una piattaforma SaaS integra un assistente AI per i propri clienti;
- una startup lancia un chatbot verticale basato su API di Chat GPT, Claude, Gemini ecc;
- una software house vende un tool AI per analisi documentale;
- un’impresa sviluppa un sistema AI interno sotto il proprio marchio per automatizzare processi aziendali;
- un vendor integra un LLM in un prodotto cybersecurity, legal tech, HR tech o fintech.
In questi casi, il provider del modello di base resta, di regola, il soggetto upstream. Ma l’azienda che costruisce il sistema finale può essere responsabile della compliance del sistema AI che offre o mette in servizio.
In pratica, usare API di terzi non esclude automaticamente la responsabilità dell’azienda sul sistema finale.
Quando sei downstream provider
L’AI Act definisce downstream provider il provider di un sistema AI, incluso un sistema AI general-purpose, che integra un modello AI, a prescindere dal fatto che il modello sia sviluppato internamente o fornito da un altro soggetto sulla base di rapporti contrattuali.
Questa è una categoria molto importante per le aziende che usano API di LLM.
Esempi tipici:
- chatbot customer care integrato in un SaaS;
- AI assistant per analisi contrattuale;
- tool HR che usa LLM per screening o ranking;
- piattaforma fintech che usa LLM per analisi preliminari;
- sistema cybersecurity che usa LLM per classificare alert;
- prodotto enterprise con generazione automatica di testi, insight o raccomandazioni.
Diritto. I provider di modelli GPAI devono predisporre documentazione tecnica e mettere a disposizione dei provider di sistemi AI che integrano il modello informazioni utili a comprendere capacità e limiti del modello e a consentire la compliance, ferma la tutela di proprietà intellettuale, informazioni confidenziali e segreti commerciali.
Fatto. Per una startup o PMI che integra API LLM, questo significa che la due diligence sul fornitore non è un dettaglio contrattuale, ma un pezzo fondamentale della compliance ai sensi dell’AI Act.
In pratica. Se non hai informazioni sufficienti dal provider API, potresti non essere in grado di documentare correttamente il tuo sistema AI.
Il caso più delicato: quando cambi la destinazione d’uso
L’art. 25 AI Act disciplina le responsabilità lungo la catena del valore. In sintesi, un deployer, distributore, importatore o altro terzo può essere considerato provider di un sistema AI ad alto rischio se appone il proprio nome o marchio, apporta una modifica sostanziale oppure modifica la destinazione d’uso di un sistema AI in modo tale da farlo diventare ad alto rischio.
Questo è uno dei passaggi più importanti per chi usa API di LLM.
Un LLM può essere usato per attività a basso rischio, come generare bozze marketing. Ma lo stesso modello può essere integrato in un tool per selezionare candidati, valutare lavoratori, generare scoring, supportare decisioni creditizie o incidere sull’accesso a servizi.
Il modello è lo stesso. Il rischio legale cambia.
Da qui ne deduciamo che usare un LLM per riassumere un articolo è una cosa. Usarlo per filtrare CV o assegnare un punteggio a candidati è un’altra.
La classificazione non dipende solo dalla tecnologia, ma dal caso d’uso concreto.
Quando un sistema basato su LLM può essere ad alto rischio
Può essere utile ricordare che l’AI Act non considera ad alto rischio qualsiasi sistema di intelligenza artificiale.
Un sistema può essere ad alto rischio se rientra nelle condizioni dell’art. 6 e nelle categorie dell’Allegato III, salvo specifiche eccezioni. L’art. 6 richiama, tra gli altri, i sistemi AI usati come componenti di sicurezza di prodotti soggetti a normativa UE e i sistemi elencati nell’Allegato III; prevede inoltre una deroga per alcuni sistemi che non pongono un rischio significativo per salute, sicurezza o diritti fondamentali e non influenzano materialmente l’esito decisionale.
Per chi usa API di LLM, i casi da guardare con maggiore attenzione sono:
- recruiting e selezione del personale;
- valutazione delle performance dei lavoratori;
- sistemi di ranking o scoring di persone fisiche;
- accesso a credito, assicurazioni o servizi essenziali;
- istruzione e valutazione degli studenti;
- sistemi che incidono su diritti, opportunità o condizioni contrattuali;
- profilazione di persone fisiche;
- strumenti usati in contesti regolati o sensibili.
In questi casi, non basta avere un contratto con il provider API.
Serve una vera AI Governance, fatta di classificazione del sistema, valutazione dei rischi, documentazione, controlli, logging, human oversight, security, trasparenza e, quando applicabile, DPIA o FRIA.
FRIA: quando l’impatto sui diritti fondamentali deve essere valutato
La FRIA, cioè la Fundamental Rights Impact Assessment, non serve per ogni uso di API LLM.
Diritto. L’art. 27 AI Act prevede che, prima di utilizzare determinati sistemi AI ad alto rischio, specifici deployer debbano svolgere una valutazione dell’impatto sui diritti fondamentali. La valutazione deve descrivere, tra l’altro, i processi in cui il sistema sarà usato, periodo e frequenza d’uso, categorie di persone o gruppi interessati, rischi specifici di danno, misure di supervisione umana, governance interna e meccanismi di reclamo.
Fatto. Se un sistema basato su API LLM viene usato in un contesto ad alto rischio e rientra nei presupposti dell’art. 27, la FRIA può diventare un passaggio necessario prima del deployment.
In pratica. La FRIA non sostituisce la DPIA privacy. Le due valutazioni possono dialogare, ma hanno oggetto diverso, la DPIA riguarda il trattamento dei dati personali; la FRIA guarda più ampiamente all’impatto sui diritti fondamentali.
Se sei curioso delle differenze tra DPIA e FRIA, puoi approfondirlo in questo articolo.
Obblighi di trasparenza. Chatbot, contenuti sintetici e interazioni con utenti
Molti sistemi basati su API di LLM interagiscono direttamente con persone fisiche.
Pensiamo a chatbot, assistenti virtuali, agenti AI, sistemi di onboarding, assistenti customer care, tool di supporto tecnico o interfacce conversazionali integrate in prodotti digitali.
Diritto. L’art. 50 AI Act prevede obblighi di trasparenza per determinati sistemi AI. Chi interagisce direttamente con una persona deve essere informato del fatto che sta interagendo con un sistema AI, salvo che ciò sia ovvio dalle circostanze; i sistemi che generano contenuti sintetici devono inoltre prevedere marcature in formato machine-readable, nei casi e con le eccezioni previste.
La Commissione europea ha anche pubblicato una bozza di linee guida per aiutare provider e deployer a rispettare gli obblighi di trasparenza dell’art. 50 AI Act.
Fatto. La trasparenza non può essere lasciata solo ai termini d’uso.
In pratica. Se un utente parla con un chatbot basato su LLM, la disclosure dovrebbe essere chiara, tempestiva e visibile nell’interfaccia.
Esempi:
- “Stai interagendo con un assistente basato su intelligenza artificiale.”
- “Le risposte generate dall’AI possono essere verificate da un operatore.”
- “Non inserire dati sensibili o informazioni riservate non necessarie.”
- “Per richieste con effetti contrattuali o legali, attendi la conferma di un operatore umano.”
Il GDPR continua ad applicarsi
Usare API LLM non fa sparire il GDPR.
Se nei prompt, nei documenti caricati, nei log, negli output, nei sistemi RAG, nei database vettoriali o nelle integrazioni sono presenti dati personali, il trattamento deve rispettare il GDPR.
L’art. 5 GDPR prevede i principi di liceità, correttezza, trasparenza, limitazione delle finalità, minimizzazione, esattezza, limitazione della conservazione, integrità, riservatezza e accountability.
Questo significa che prima di usare API LLM su dati personali bisogna chiarire:
- quali dati entrano nel sistema;
- per quali finalità sono trattati;
- qual è la base giuridica;
- se sono presenti dati particolari;
- chi è titolare, responsabile o sub-responsabile;
- dove sono conservati prompt, output e log;
- se i dati sono usati per training o miglioramento del servizio;
- quali tempi di conservazione si applicano;
- quali misure di sicurezza sono attive;
- se vi sono trasferimenti extra SEE;
- se serve una DPIA.
Il punto pratico è semplice; un’integrazione API può sembrare tecnica, ma se processa dati personali diventa anche un trattamento privacy.
DPIA. Quando serve una valutazione d’impatto
Non ogni uso di API LLM richiede una DPIA.
La DPIA diventa però centrale quando il trattamento, specie se basato su nuove tecnologie, può presentare un rischio elevato per i diritti e le libertà delle persone fisiche. L’art. 35 GDPR richiede infatti una valutazione d’impatto prima del trattamento quando ricorrono tali condizioni.
Nei progetti basati su LLM API, la DPIA va considerata con particolare attenzione quando il sistema:
- analizza o classifica persone fisiche;
- supporta decisioni HR;
- genera scoring o ranking;
- tratta grandi quantità di dati personali;
- elabora dati particolari;
- usa dati di clienti, lavoratori, candidati o utenti vulnerabili;
- conserva prompt e output in modo esteso;
- integra fonti diverse in un sistema RAG;
- supporta decisioni che incidono su opportunità, servizi o condizioni contrattuali.
In pratica, la DPIA non serve a “fare carta”.
Serve a capire se l’architettura scelta è necessaria, proporzionata, sicura e coerente con le finalità dichiarate.
Due diligence dei fornitori, cosa chiedere al provider API
La scelta del provider API è un passaggio legale, non solo tecnico.
Prima di integrare un LLM in un processo aziendale o in un prodotto, l’azienda dovrebbe verificare almeno:
- chi è il provider del modello;
- se il provider tratta dati personali come responsabile, titolare autonomo o altro ruolo;
- se esiste un DPA conforme al GDPR;
- se input e output sono usati per training o miglioramento del modello;
- se è disponibile un opt-out dal training;
- dove sono localizzati dati, log, backup e subfornitori;
- quali sub-processors sono coinvolti;
- quali misure di sicurezza sono documentate;
- quali tempi di conservazione si applicano;
- se prompt e output possono essere cancellati;
- se sono disponibili audit report o certificazioni;
- se il provider notifica incidenti e data breach;
- se il modello o le condizioni possono cambiare unilateralmente;
- quali garanzie esistono su segreti commerciali e informazioni confidenziali;
- quali documenti vengono messi a disposizione per la compliance AI Act.
La Commissione europea ha chiarito che le linee guida sui provider di modelli GPAI servono proprio ad aiutare gli attori dell’ecosistema AI a capire se gli obblighi si applicano e cosa ci si aspetta da loro; le linee guida richiamano anche un approccio pragmatico, distinguendo modifiche significative da modifiche minori dei modelli.
AI Governance per API LLM: cosa deve prevedere
Un progetto API LLM dovrebbe essere gestito con un modello minimo di AI Governance.
Non basta una policy generica sull’uso dell’intelligenza artificiale.
Serve un sistema operativo che consenta di sapere:
- quali API LLM sono usate;
- da quali team;
- per quali finalità;
- con quali dati;
- con quali output;
- con quali controlli;
- con quali fornitori;
- con quali misure di sicurezza;
- con quali responsabilità interne.
Un modello pratico può includere:
Inventario dei casi d’uso
Non basta sapere quali licenze sono attive. Bisogna sapere dove le API vengono usate nei processi reali.
Classificazione AI Act
Per ogni caso d’uso bisogna verificare se l’azienda è deployer, provider, downstream provider o se assume ulteriori obblighi per modifica sostanziale o cambio di destinazione d’uso.
Classificazione del rischio
Bisogna distinguere usi vietati, high-risk, usi soggetti a trasparenza e usi a rischio limitato.
Mappatura dati
Prompt, output, log, documenti caricati, embedding, retrieval, knowledge base e integrazioni devono essere mappati.
Valutazione privacy
Base giuridica, ruoli, DPA, informative, retention, sicurezza, trasferimenti e DPIA vanno valutati prima del go-live.
Valutazione informazioni confidenziali
Bisogna decidere quali informazioni possono essere usate con quali strumenti e quali invece devono restare escluse.
Vendor due diligence
Contratti, DPA, training, retention, sicurezza, subfornitori, localizzazione e documentazione AI Act devono essere verificati.
Human oversight
Chi controlla gli output? Con quali criteri? Quando il sistema può agire autonomamente? Quando serve revisione umana?
Logging e monitoraggio
Bisogna stabilire quali log registrare, chi può accedervi, per quanto tempo conservarli e come proteggerli.
Formazione
Chi usa API LLM deve sapere cosa può inserire, cosa deve evitare, come verificare gli output e quando attivare escalation.
La normativa italiana sull’AI
In Italia, la Legge n. 132/2025 reca principi in materia di ricerca, sviluppo, adozione e applicazione di sistemi e modelli di intelligenza artificiale, promuovendo un utilizzo corretto, trasparente e responsabile in una dimensione antropocentrica e coerente con il Regolamento UE 2024/1689.
La legge richiama principi come trasparenza, proporzionalità, sicurezza, protezione dei dati personali, riservatezza, accuratezza, non discriminazione e cybersicurezza lungo il ciclo di vita dei sistemi e modelli AI.
Per le aziende italiane che usano API LLM, questo rafforza un punto: l’adozione dell’AI non può essere trattata come una sperimentazione non governata.
Serve una governance documentata.
Errori da evitare
Il primo errore è pensare che l’uso tramite API sia solo un tema tecnico.
Il secondo errore è qualificarsi sempre come deployer. Se l’azienda costruisce e mette a disposizione un sistema basato su API LLM, può essere provider o downstream provider.
Il terzo errore è guardare solo al provider upstream. Il fornitore del modello ha obblighi propri, ma l’azienda deve governare il proprio caso d’uso.
Il quarto errore è ignorare la destinazione d’uso. Lo stesso LLM può avere rischi molto diversi se usato per marketing, HR, credito, cybersecurity o customer care.
Il quinto errore è inserire dati personali o informazioni confidenziali nei prompt senza verifiche su training, retention, DPA, sicurezza e localizzazione.
Il sesto errore è considerare la trasparenza come una clausola nei termini d’uso. Nei chatbot e nelle interfacce AI, la trasparenza deve essere progettata nel prodotto.
Il settimo errore è trattare human oversight come una formalità.
L’ottavo errore è arrivare alla compliance dopo il go-live.
Checklist operativa prima di usare API LLM
Prima di integrare API LLM in un processo aziendale o in un prodotto, l’azienda dovrebbe:
- descrivere il caso d’uso reale;
- identificare utenti, clienti e persone impattate;
- distinguere modello, API, sistema AI e applicazione finale;
- qualificare il proprio ruolo ai sensi dell’AI Act;
- verificare se il sistema è vietato, high-risk o soggetto a trasparenza;
- mappare dati personali, dati particolari e informazioni confidenziali;
- verificare base giuridica, ruoli privacy, DPA e trasferimenti;
- valutare la necessità di DPIA;
- valutare la necessità di FRIA;
- svolgere vendor due diligence sul provider API;
- definire policy interne sull’uso degli LLM;
- implementare controlli su prompt, output, log e accessi;
- progettare human oversight;
- formare gli utenti interni;
- monitorare il sistema nel tempo.
Conclusione
Usare le API di un LLM non è un dettaglio tecnico.
È una scelta che può collocare l’azienda in ruoli diversi lungo la catena del valore dell’AI.
In alcuni casi l’azienda sarà deployer. In altri sarà provider del sistema finale. In altri ancora sarà downstream provider, perché integra un modello general-purpose in un proprio sistema AI.
Se la tua azienda sta integrando API LLM in un prodotto, in un chatbot o in un processo interno, il primo passaggio è classificare correttamente il caso d’uso e il ruolo assunto ai sensi dell’AI Act.
Comments are closed.