Da qualche mese ormai, in molte conversazioni con clienti, imprenditori, CTO, esce sempre la stessa domanda: “Come integriamo l’AI nel nostro progetto?”.
È la domanda sbagliata. Non perché non abbia risposta, ma perché ne ha quattro e tratta tutto quanto come un problema tecnico da risolvere con uno stack. Integrare l’AI in un progetto significa prendere quattro decisioni architetturali separate, con implicazioni diverse, soggetti decisionali diversi, costi di reversibilità e tempi di maturazione diversi. Se le collassi in una sola scelta, qualcuno dovrà prenderle comunque al posto tuo, e quel qualcuno, di solito, è il team tecnico che aveva soltanto il mandato di “implementare”.
Le quattro decisioni sono:
- Dove l’AI entra: a supporto del team di sviluppo, all’interno del prodotto, o entrambe le cose con confini espliciti?
- Quanto determinismo ti serve: puoi accettare output probabilistico ovunque, o ci sono flussi critici in cui l’AI non è lo strumento giusto?
- Quanta dipendenza dal provider sei disposto ad accettare: lock-in pieno, fallback degradato, multi-provider, self-hosted?
- Qual è il perimetro dei dati che possono essere trasmessi a un provider di terze parti: i tuoi dati aziendali, i dati dei tuoi utenti, entrambi o nessuno?
Si tratta di quattro conversazioni distinte, non di sottocategorie dello stesso problema. Coinvolgono persone diverse (CTO, legal, product, business), hanno orizzonti temporali diversi (da giorni a mesi tra il momento della decisione e quello in cui il costo diventa visibile), e una sola decisione sbagliata ne condiziona altre tre. Trattarle come una sola è il modo più efficiente per pentirsi dopo diciotto mesi.
Prima di entrare nei dettagli di ciascun asse, voglio mettere sul tavolo un concetto che vale per tutti: il costo di reversibilità. Analisi recenti stimano che il costo medio di migrazione tra provider di AI si aggiri intorno a 315.000 dollari per progetto (Savi, 2025), e che il lock-in AI si formi in dodici-diciotto mesi contro i tre-cinque anni del lock-in ERP classico. Queste cifre vanno prese cum granus salis — vengono da fonti con skin in the game commerciale — ma il principio regge: le decisioni che stai per prendere hanno un costo di reversibilità che cresce rapidamente, ed è invisibile mentre si forma.
Asse 1: dove entra l’AI
La prima distinzione è tra l’AI a supporto del team e l’AI all’interno del prodotto.
AI a supporto del team significa Claude Code, Copilot, Cursor, Codex, strumenti che accelerano lo sviluppo ma vivono nell’IDE dei developer. Il cliente finale non vede niente: il prodotto non dipende funzionalmente dall’AI e, al peggio, se il provider cambia le tariffe, il team torna a codare come nel 2023.
L’AI dentro il prodotto significa che una feature che l’utente paga o usa dipende funzionalmente da una chiamata a un LLM. Chatbot di supporto, generazione di contenuti, classificazione automatica, agenti che svolgono task per conto dell’utente. Il provider diventa una dipendenza operativa del tuo prodotto, non uno strumento accessorio.
Sembra una distinzione banale. Non lo è, perché le implicazioni per le altre tre decisioni sono molto diverse. Un’AI a supporto del team tollera molto più lock-in (cambio di IDE in un mese), tollera molto più la stocasticità (il developer rivede) e ha un perimetro dei dati limitato al codice che l’azienda produce. Un’AI integrata nel prodotto ha requisiti più stringenti su tutti e tre i fronti.
C’è anche un conflitto meno ovvio: la ricerca sulla qualità del codice AI-generated è contraddittoria. Lo studio interno di GitHub (GitHub, 2024) mostra che 202 developer con Copilot avevano il 53,2% in più di probabilità di passare tutti gli unit test e il 13,6% in più di linee senza problemi di leggibilità. Un’analisi esterna su 211 milioni di righe modificate tra 2020 e 2024 (GitClear, 2025) mostra un aumento di 4x del code cloning, con il “copy/paste” che, per la prima volta nella storia del codebase analizzato, supera il “moved code“.
Sono dati che, presi insieme, dicono una cosa interessante: la qualità locale migliora, mentre la qualità sistemica potrebbe peggiorare. Non voglio trarre conclusioni perché ho letto gli studi; non li ho rifatti. Ma se stai scegliendo “AI a supporto del team” pensando che sia la scelta più innocua, tieni presente che anche qui c’è un trade-off documentato.
Uno dei non-detti di questo asse: se la risposta è “entrambe le cose” — team-side e product-side — stai prendendo due decisioni, non una. E le due decisioni hanno vincoli diversi.
Asse 2: quanto determinismo ti serve
Gli LLM sono per la costruzione probabilistica. Lo stesso prompt produce output diversi, anche con temperature zero ci sono fonti di variabilità. Questo è un fatto tecnico documentato, con implicazioni concrete per l’architettura.
Il problema è che, nel tuo prodotto, ci sono flussi che possono tollerare questa variabilità e altri che non possono. Un paper recente (Freeman et al., arXiv 2603.10047, 2026) ha testato cinque strategie di prompt engineering per ridurre la varianza degli output su task industriali, ripetendo 100 volte ciascun run a temperatura 0.7. I risultati migliori (Enhanced Data Registry) hanno raggiunto il 100% di risultati migliori rispetto al baseline; i peggiori (Decomposed Prompting v1) il 34%, cioè peggio del single-shot prompting. Tradotto: anche con tecniche avanzate, la varianza è gestibile ma non eliminabile. Le LLM restano probabilistiche.
La distinzione pratica, come la formula IBM (Flexible by design, reliable by proof, 2026), passa tra processi intenzionalmente rigidi (regulatory approval, budget controls, identity verification, payment execution, compliance checks) e processi che beneficiano di reasoning flessibile (supplier selection, contract drafting, invoice mismatch investigation). Non si tratta di un out-or-in ma di una mappa del tuo prodotto.
Il momento in cui questa decisione ti costa di più è quando ti accorgi dopo che un flusso critico era sul lato probabilistico. Tipicamente succede quando un cliente importante riceve un output errato, o quando un audit chiede di ricostruire com’è stata presa una decisione e la risposta onesta è: “non possiamo, era un LLM”.
Un punto poco indagato: quali flussi del tuo prodotto, se producono un output sbagliato, generano un problema che non può essere risolto con uno “scusate, riprova”? Quelli sono i flussi in cui l’AI, da sola, non è lo strumento. Possono esserci architetture ibride (LLM genera + layer deterministico verifica), ma si tratta di una decisione da prendere, non da assumere.
Asse 3: quanta dipendenza dal provider
Questo è l’asse più politico e quello su cui si rischia di pentirsi più in fretta. La scelta del provider sembra una scelta tecnica (“Claude è meglio di GPT per questo task”), ma è in realtà una scelta strategica con un orizzonte di anni.
Il problema del lock-in AI presenta caratteristiche diverse rispetto a quello del lock-in cloud o di quello ERP. Si forma più velocemente (dodici-diciotto mesi contro tre-cinque anni), è invisibile mentre si forma, e tipicamente non emerge attraverso le API (che sono standardizzabili) ma attraverso tre canali che nessuno monitora: i prompt ottimizzati su uno specifico modello, i dati che escono verso il provider e non tornano indietro in forma originale (embeddings, fine-tuning, RAG), e le condizioni commerciali modificabili unilateralmente al rinnovo.
Un esempio concreto di quanto la velocità di cambiamento sia elevata: OpenAI ha deprecato GPT-4o, GPT-4.1, GPT-4.1 mini e o4-mini in ChatGPT il 13 febbraio 2026 con due settimane di preavviso (The Register, 2026). Policy diverse per API e consumer (API ha preavvisi più lunghi), ma il punto rimane: un modello su cui hai costruito può sparire rapidamente. Azure OpenAI garantisce contrattualmente dodici mesi di accesso GA più sei mesi aggiuntivi per i clienti esistenti; l’API OpenAI prevede un minimo di sessanta giorni di accesso GA. La maggior parte degli accordi enterprise sottoscritti in fretta non include clausole paragonabili.
Le quattro posizioni possibili su questo asse:
- Mono-provider, nessun fallback: la posizione più comune e al tempo stesso la più rischiosa. Va bene solo se la feature basata sull’AI è sacrificabile in caso di outage o di variazioni di prezzo.
- Mono-provider con fallback degradato: se il provider principale cade o cambia le tariffe, il prodotto continua a funzionare con un modello più semplice, un set di regole o una feature disattivata, con un messaggio trasparente all’utente. Il fallback va testato periodicamente, altrimenti non esiste.
- Astrazione multi-provider: l’applicazione parla con un gateway interno che può indirizzare verso diversi provider. Costo di implementazione alto, flessibilità alta, con un’avvertenza: l’astrazione perfetta non esiste; ogni provider ha capability diverse.
- Self-hosted / open model: controllo totale, costo infrastrutturale elevato, qualità che può essere inferiore per certi task.
Non c’è una risposta universale giusta. C’è una risposta coerente con le altre tre decisioni. Se hai scelto “AI dentro il prodotto, flussi critici, dati sensibili”, la monodipendenza senza fallback è una scommessa. Se hai scelto “AI a supporto del team, nessun flusso critico, nessun dato sensibile”, probabilmente il lock-in resta un problema gestibile.
Un aspetto raramente esplicitato: quando è stata ultimamente testata la procedura di fallback? Se la risposta è “mai” o “non ce l’abbiamo”, allora non hai una strategia di resilienza, hai un desiderio.
Asse 4: il perimetro del dato
Questo è l’asse in cui la confusione è più grave, perché quasi nessuno distingue due cose molto diverse: i tuoi dati (codice sorgente, documenti strategici, piani commerciali, comunicazioni interne) e i dati dei tuoi utenti che ti sono stati affidati.
Il primo è un rischio di business: se finiscono fuori, perdi vantaggio competitivo, esponi la strategia e forse ti accorgi, dopo mesi, che un competitor sapeva cose che non avrebbe dovuto sapere. Brutto, ma gestibile.
Il secondo è un rischio fiduciario e legale: se i dati dei tuoi utenti vengono trasmessi a un provider di terze parti senza una base giuridica adeguata, senza consenso informato, senza DPA firmato, stai violando il GDPR con tutte le conseguenze del caso. E “abbiamo messo ChatGPT nel customer service” non è un piano di compliance.
Il caso del Garante italiano è istruttivo proprio perché l’esito finale è stato favorevole a OpenAI. A dicembre 2024 il Garante ha sanzionato OpenAI per quindici milioni di euro per trattamento dei dati senza base giuridica adeguata, violazione della trasparenza, mancata notifica del data breach del marzo 2023 (Garante Privacy, provvedimento 755/2024). A marzo 2025 il Tribunale di Roma ha sospeso cautelativamente la sanzione. A marzo 2026 la sentenza 4153/2026 l’ha annullata (Federprivacy, 2026).
Chi legge questa storia come “l‘AI vince contro il Garante, quindi possiamo stare tranquilli” sta leggendo male. La lezione sta nel processo più che nell’esito: quindici mesi di incertezza regolatoria durante i quali ogni azienda europea che usava ChatGPT in produzione ha dovuto prendere una posizione sulla propria esposizione. Non ho dati aggregati su quante aziende abbiano effettivamente rivisto la compliance o riallocato budget legali per gestire l’incertezza — il principio, però, regge: un contenzioso regolatorio prolungato distribuisce il costo su chiunque dipenda dal soggetto coinvolto, indipendentemente dall’esito finale.
C’è poi un livello di complessità che il caso italiano, da solo, non rende visibile: le autorità nazionali europee stanno assumendo posizioni divergenti sullo stesso tema. Secondo IAPP (febbraio 2026), ICO UK ha autorizzato LinkedIn a usare i dati degli utenti per training dell’AI con un meccanismo di opt-out; la Autoriteit Persoonsgegevens olandese ha sollevato preoccupazioni serie sulla stessa base giuridica; CNIL Francia ha raccomandato agli utenti di esercitare l’opt-out pur riservandosi il giudizio sulla validità della base legale. La proposta di Digital Omnibus della Commissione UE mira a introdurre un nuovo articolo 88c del GDPR che consentirebbe esplicitamente il legittimo interesse per il training in AI, ma non è ancora stata approvata. Se la tua feature AI serve utenti in più paesi europei, potresti trovarti contemporaneamente conforme in UK, sotto scrutinio in Olanda e in una zona grigia in Francia. Questo è il rischio regolatorio che non si vede finché qualcuno non viene contattato.
C’è infine un secondo livello di rischio tecnico che spesso non viene considerato: la prompt injection. OWASP ha posizionato “Sensitive Information Disclosure” come LLM02 nella Top 10 2025 e “Prompt Injection” come LLM01. Un paper recente (Alizadeh et al., arXiv 2506.01055, 2025) ha mostrato che semplici attacchi di prompt injection su agenti con tool-calling possono causare leak di dati personali con un tasso di successo medio intorno al 20%. Tradotto: anche se hai scelto un provider GDPR-compliant, se il tuo agente espone tool che possono essere manipolati tramite prompt, il perimetro dei dati non è garantito a livello di architettura.
Le posizioni possibili su questo asse, tenendo separati i due livelli:
Per i dati aziendali nostri:
- Possono uscire senza restrizioni
- Non possono uscire (restano on-premise o su infrastruttura controllata)
- Possono uscire solo in forma aggregata o anonimizzata
Per i dati dei nostri utenti:
- Possono uscire con consenso esplicito e ToS del provider coerenti (DPA firmato, Art. 28 GDPR, SCC per trasferimenti extra-UE)
- Non possono uscire in nessun caso
- Solo dopo anonimizzazione verificata (con tutte le avvertenze: anonimizzare davvero è difficile)
Una domanda che resta implicita: se domani un utente ti chiedesse dove finiscano i suoi dati quando interagisce con la tua feature AI, sapresti rispondere con precisione? Se la risposta è “credo che OpenAI non li usi per il training”, non hai una risposta; hai (di nuovo) una speranza.
Prima di decidere, serve vedere
A questo punto qualcuno dirà: “ok, capisco il problema, ma cosa faccio concretamente?”
La risposta che non voglio darti è “fai queste dieci cose entro venerdì”. Non perché non sarebbe utile, ma perché sarebbe la stessa scorciatoia che sto criticando: trasformare quattro decisioni architetturali in una checklist da spuntare.
La risposta che voglio darti è diversa: prima di decidere, serve vedere. E per vedere ho costruito due canvas. Non sono strumenti finiti: sono ipotesi di lavoro e, in fondo all’articolo, trovi i link per scaricarli.
Il primo canvas (A) è diagnostico. Serve a fotografare dove sei oggi su ciascuno dei quattro assi e, soprattutto, a rendere visibile ciò che oggi non è chiaro e ciò che stai già pagando senza saperlo. È un esercizio che puoi fare da solo, in una sera, senza coinvolgere nessuno. Non produce decisioni, produce consapevolezza. La colonna più importante non è quella con “dove siamo oggi”, ma quella con “cosa non è chiaro”: se è piena, stai già prendendo decisioni per default che non ricordi di aver preso.
Il secondo canvas (B) è decisionale. Serve a trasformare la consapevolezza in un impegno. Su ciascun asse scegli una posizione, dichiari cosa stai accettando come costo di quella posizione, e fissi un “segnale di riconsiderazione”: una condizione oggettiva al verificarsi della quale la decisione va rivista. Questo terzo campo è il dettaglio che distingue una decisione da un’ipotesi che diventa tecnologia obsoleta. Senza segnale di riconsiderazione, la decisione non invecchia: marcisce.
La sequenza che suggerisco è: canvas A da solo, canvas B con il team. Il primo momento è di riflessione personale; il secondo è di allineamento collettivo e richiede il buy-in. Portare il team direttamente al canvas B, senza prima aver fatto il canvas A, porta a discussioni confuse perché ciascuno ha in mente una fotografia diversa del presente. Fare il canvas A con il team porta a un pattern di groupthink in cui le “zone grigie” si dissolvono perché nessuno vuole ammetterle di fronte ai colleghi.
Entrambi i canvas sono ipotesi aperte. Se li compili e ti accorgi che mancano campi, che gli assi non coprono il tuo caso, che la sequenza non funziona per te, fammelo sapere. La versione che leggete rappresenta lo stato attuale: quello che funziona per me oggi, non una versione finale.
Due riflessioni finali
La prima. Se guardate la lista delle quattro decisioni, nessuna è puramente tecnica. “Dove entra l’AI” è la product strategy. “Quanto determinismo serve?” È risk management. “Quanta dipendenza dal provider” è una strategia commerciale e un’architettura di business continuity. “Qual è il perimetro del dato?” è legale, in linea con la compliance e di fiducia nei confronti dei clienti. Se queste decisioni restano nel team tecnico, non dipende da una scelta del team tecnico: dipende dal fatto che nessun altro si sia presentato alla riunione.
La seconda. Il costo delle decisioni sbagliate su questi quattro assi non emerge il giorno in cui vengono prese. Emerge tra dodici e diciotto mesi dopo, quando il provider cambia i prezzi, quando un utente fa una richiesta GDPR, quando un audit chiede di ricostruire una decisione, quando un competitor rilascia una feature identica alla vostra ma con un provider diverso che voi non potete usare perché avete hardcoded tutto. In quel momento il costo di cambiare è già alto, e non lo si può rimangiare facilmente.
L’unica cosa che il tempo non fa tornare indietro è la decisione che non hai preso esplicitamente.
Scarica i canvas
Entrambi sono rilasciati con licenza Creative Commons BY-SA. Se li modificate per il vostro contesto, fatemi sapere cosa avete cambiato: mi interessa capire dove il modello funziona e dove no.
Riferimenti: GitHub Research, 2024 · GitClear, AI Assistant Code Quality Research, 2025 · Freeman et al., Toward Epistemic Stability, arXiv:2603.10047, 2026 · IBM, Building and Evaluating AI Agents, 2026 · Savi, Vendor Lock-In Analysis, 2025 · OpenAI Model Deprecations, The Register, 2026 · Garante Privacy, Provvedimento 755/2024 · Tribunale di Roma, Sentenza 4153/2026 (via Federprivacy) · IAPP, EU Digital Omnibus Amendments, 2026 · Alizadeh et al., Prompt Injection Attacks, arXiv:2506.01055, 202