{"id":4660,"date":"2026-04-21T19:58:34","date_gmt":"2026-04-21T18:58:34","guid":{"rendered":"https:\/\/www.fullo.net\/blog\/?p=4660"},"modified":"2026-04-21T20:09:13","modified_gmt":"2026-04-21T19:09:13","slug":"le-quattro-decisioni-da-prendere-esplicitamente-prima-di-integrare-lai","status":"publish","type":"post","link":"https:\/\/www.fullo.net\/blog\/2026\/04\/21\/le-quattro-decisioni-da-prendere-esplicitamente-prima-di-integrare-lai\/","title":{"rendered":"Le quattro decisioni da prendere esplicitamente prima di integrare l’AI"},"content":{"rendered":"\n

Da qualche mese ormai, in molte conversazioni con clienti, imprenditori, CTO, esce sempre la stessa domanda: “Come integriamo l’AI nel nostro progetto?”<\/em>.<\/p>\n\n\n\n

\u00c8 la domanda sbagliata. Non perch\u00e9 non abbia risposta, ma perch\u00e9 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\u00e0 e tempi di maturazione diversi. Se le collassi in una sola scelta, qualcuno dovr\u00e0 prenderle comunque al posto tuo, e quel qualcuno, di solito, \u00e8 il team tecnico che aveva soltanto il mandato di “implementare”.<\/p>\n\n\n\n\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Le quattro decisioni sono:<\/p>\n\n\n\n

    \n
  1. Dove l’AI entra:<\/strong> a supporto del team di sviluppo, all’interno del prodotto, o entrambe le cose con confini espliciti?<\/li>\n\n\n\n
  2. Quanto<\/strong> determinismo ti serve: puoi accettare output probabilistico ovunque, o ci sono flussi critici in cui l’AI non \u00e8 lo strumento giusto?<\/li>\n\n\n\n
  3. Quanta<\/strong> dipendenza dal provider sei disposto ad accettare: lock-in pieno, fallback degradato, multi-provider, self-hosted?<\/li>\n\n\n\n
  4. Qual \u00e8 il perimetro <\/strong>dei dati che possono essere trasmessi a un provider di terze parti: i tuoi dati aziendali, i dati dei tuoi utenti, entrambi o nessuno?<\/li>\n<\/ol>\n\n\n\n

    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 \u00e8 il modo pi\u00f9 efficiente per pentirsi dopo diciotto mesi.<\/p>\n\n\n\n

    Prima di entrare nei dettagli di ciascun asse, voglio mettere sul tavolo un concetto che vale per tutti: il costo di reversibilit\u00e0<\/strong>. Analisi recenti stimano che il costo medio di migrazione tra provider di AI si aggiri intorno a 315.000 dollari per progetto (Savi, 2025<\/a>), 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<\/em> \u2014 vengono da fonti con skin in the game commerciale \u2014 ma il principio regge: le decisioni che stai per prendere hanno un costo di reversibilit\u00e0 che cresce rapidamente, ed \u00e8 invisibile mentre si forma.<\/p>\n\n\n\n

    Asse 1: dove entra l’AI<\/h2>\n\n\n\n

    La prima distinzione \u00e8 tra l’AI a supporto del team<\/strong> e l’AI all’interno del prodotto<\/strong>.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    Sembra una distinzione banale. Non lo \u00e8, perch\u00e9 le implicazioni per le altre tre decisioni sono molto diverse. Un’AI a supporto del team tollera molto pi\u00f9 lock-in (cambio di IDE in un mese), tollera molto pi\u00f9 la stocasticit\u00e0 (il developer rivede) e ha un perimetro dei dati limitato al codice che l’azienda produce. Un’AI integrata nel prodotto ha requisiti pi\u00f9 stringenti su tutti e tre i fronti.<\/p>\n\n\n\n

    C’\u00e8 anche un conflitto meno ovvio: la ricerca sulla qualit\u00e0 del codice AI-generated \u00e8 contraddittoria. Lo studio interno di GitHub (GitHub, 2024<\/a>) mostra che 202 developer con Copilot avevano il 53,2% in pi\u00f9 di probabilit\u00e0 di passare tutti gli unit test e il 13,6% in pi\u00f9 di linee senza problemi di leggibilit\u00e0. Un’analisi esterna su 211 milioni di righe modificate tra 2020 e 2024 (GitClear, 2025<\/a>) 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<\/em>“.<\/p>\n\n\n\n

    Sono dati che, presi insieme, dicono una cosa interessante: la qualit\u00e0 locale migliora, mentre la qualit\u00e0 sistemica potrebbe peggiorare. Non voglio trarre conclusioni perch\u00e9 ho letto gli studi; non li ho rifatti. Ma se stai scegliendo “AI a supporto del team<\/em>” pensando che sia la scelta pi\u00f9 innocua, tieni presente che anche qui c’\u00e8 un trade-off documentato.<\/p>\n\n\n\n

    Uno dei non-detti di questo asse:<\/strong> se la risposta \u00e8 “entrambe le cose<\/em>” \u2014 team-side e<\/em> product-side \u2014 stai prendendo due decisioni, non una. E le due decisioni hanno vincoli diversi.<\/p>\n\n\n\n

    Asse 2: quanto determinismo ti serve<\/h2>\n\n\n\n

    Gli LLM sono per la costruzione probabilistica. Lo stesso prompt produce output diversi, anche con temperature zero ci sono fonti di variabilit\u00e0. Questo \u00e8 un fatto tecnico documentato, con implicazioni concrete per l’architettura.<\/p>\n\n\n\n

    Il problema \u00e8 che, nel tuo prodotto, ci sono flussi che possono tollerare questa variabilit\u00e0 e altri che non possono. Un paper recente (Freeman et al., arXiv 2603.10047, 2026<\/a>) 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\u00e8 peggio del single-shot prompting. Tradotto: anche con tecniche avanzate, la varianza \u00e8 gestibile ma non eliminabile. Le LLM restano probabilistiche.<\/p>\n\n\n\n

    La distinzione pratica, come la formula IBM (Flexible by design, reliable by proof, 2026<\/a>), 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.<\/p>\n\n\n\n

    Il momento in cui questa decisione ti costa di pi\u00f9 \u00e8 quando ti accorgi dopo<\/em> 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’\u00e8 stata presa una decisione e la risposta onesta \u00e8: “non possiamo, era un LLM”.<\/p>\n\n\n\n

    Un punto poco indagato:<\/strong> quali flussi del tuo prodotto, se producono un output sbagliato, generano un problema che non pu\u00f2 essere risolto con uno “scusate, riprova”? Quelli sono i flussi in cui l’AI, da sola, non \u00e8 lo strumento. Possono esserci architetture ibride (LLM genera + layer deterministico verifica), ma si tratta di una decisione da prendere, non da assumere.<\/p>\n\n\n\n

    Asse 3: quanta dipendenza dal provider<\/h2>\n\n\n\n

    Questo \u00e8 l’asse pi\u00f9 politico e quello su cui si rischia di pentirsi pi\u00f9 in fretta. La scelta del provider sembra una scelta tecnica (“Claude \u00e8 meglio di GPT per questo task”), ma \u00e8 in realt\u00e0 una scelta strategica con un orizzonte di anni.<\/p>\n\n\n\n

    Il problema del lock-in AI presenta caratteristiche diverse rispetto a quello del lock-in cloud o di quello ERP. Si forma pi\u00f9 velocemente (dodici-diciotto mesi contro tre-cinque anni), \u00e8 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.<\/p>\n\n\n\n

    Un esempio concreto di quanto la velocit\u00e0 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<\/a>). Policy diverse per API e consumer (API ha preavvisi pi\u00f9 lunghi), ma il punto rimane: un modello su cui hai costruito pu\u00f2 sparire rapidamente. Azure OpenAI garantisce contrattualmente dodici mesi di accesso GA pi\u00f9 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.<\/p>\n\n\n\n

    Le quattro posizioni possibili su questo asse:<\/p>\n\n\n\n