Sviluppare applicazioni AI in Italia: guida completa 2026

Nel 2026 il range tipico osservato è 25-40K€ per un MVP focalizzato su un singolo caso d'uso (8-12 settimane), 60-120K€ per una piattaforma B2B AI-native (4-6 mesi), 90-200K€ per un sistema agentic multi-tool e oltre 150K€ per piattaforme enterprise multi-tenant con RAG su corpus estesi. Il costo non dipende dal numero di pagine, ma dal numero di workflow critici, dalla qualità di eval richiesta e dal vincolo di compliance (self-hosted alza il prezzo del 20-40%). Non considerare preventivi sotto i 15K€: o sono POC mascherati o nascondono debito tecnico che pagherete dopo. I costi ricorrenti vanno calcolati a parte: 50-2000€/mese di inference LLM, 20-500€/mese di vector DB, 100-300€/mese di monitoring.

Un MVP AI consegnato in produzione, non un demo, richiede 8-12 settimane se lo scope è onesto: un caso d'uso, un'integrazione dati, un'interfaccia, eval baseline. Le prime 2 settimane sono discovery e definizione architettura, dalla 3 alla 6 si costruisce la pipeline RAG o l'agente core, dalla 7 alla 10 si itera su qualità output e UX, le ultime 2 sono hardening, eval automatici e deploy. Chi promette MVP AI in 3 settimane sta consegnando un wrapper su ChatGPT che fallirà al primo edge case. Chi promette 6 mesi sta usando processi pre-LLM. La finestra sana, con vibecoding e Server Components, è proprio 8-12 settimane.

Nel 95% dei casi enterprise la risposta è RAG, non fine-tuning. Il fine-tuning ha senso quando dovete imporre uno stile o un formato di output molto specifico, quando avete migliaia di esempi etichettati di alta qualità e quando il costo per token a runtime è il vincolo principale. Il RAG vince quando la knowledge base cambia spesso (giorni o settimane), quando dovete poter citare la fonte e quando volete poter aggiornare la conoscenza senza riaddestrare. Esiste anche un percorso ibrido: RAG come default, fine-tuning di un modello piccolo solo sull'ultimo layer di formattazione. Iniziate sempre da RAG con un modello frontier: passare a fine-tuning si decide dai dati di eval, non dall'intuizione.

Sì, e in molti scenari italiani è la scelta corretta. Llama 3.x e Mistral Large sono allineati alle frontier closed per molti task in italiano, soprattutto su classificazione, estrazione strutturata e Q&A su corpus aziendale. Self-hosted ha tre vantaggi reali: i dati non escono dal vostro perimetro (cruciale per legal, sanità, finanza, PA), il costo a regime diventa prevedibile (server fisso vs. token variabili) e non avete lock-in commerciale. I contro: serve infrastruttura GPU (un A100 o H100 in colocation o cloud sovrano), gli aggiornamenti li gestite voi e per task di reasoning complesso il gap con GPT-4 o Claude resta tangibile. La pratica matura nel 2026 è ibrida: open-source per il volume, frontier per i pochi task critici.

Il lock-in tecnico è basso, il lock-in di workflow è alto. Tecnicamente le API sono simili e si possono astrarre dietro un layer di routing in poche righe di codice. Il problema vero è che ogni provider ha un comportamento diverso sui prompt: cambiando da GPT-4 a Claude i vostri prompt resi finissimi smettono di funzionare e dovete riallineare eval e fallback. Inoltre i prezzi cambiano senza preavviso (sono già cambiati 4 volte in 24 mesi) e le policy di uso possono escludere casi business interi. Mitigazione corretta: progettare l'app per essere multi-provider fin dal giorno uno, mantenere una suite di eval automatici e tenere un fallback open-source self-hosted per i task ad alto volume.

Dipende dalla categoria di rischio. Per la stragrande maggioranza delle applicazioni B2B (assistenti interni, RAG su documenti, automazioni di workflow) l'AI Act richiede trasparenza verso l'utente, documentazione tecnica e gestione del rischio, non riscritture. Le scadenze chiave 2026 sono: agosto per i sistemi general purpose già sul mercato e febbraio 2027 per i sistemi ad alto rischio in settori critici. Se sviluppate per terzi siete Provider e avete obblighi più stringenti; se usate AI internamente siete Deployer e gli obblighi sono più leggeri ma reali. La riscrittura è necessaria solo se siete in alto rischio (HR, credito, accesso a servizi essenziali, biometria) e l'architettura attuale non permette logging, eval e human-in-the-loop.

Sotto i 10 milioni di vettori pgvector basta e avanza, soprattutto se Postgres lo state già usando per i dati transazionali. Il vantaggio è enorme: una sola fonte di verità, transazioni ACID che legano embedding e metadata, niente sincronizzazioni fragili. Sopra i 10 milioni di vettori o con query latency budget sotto i 50ms su corpus diversi conviene un DB dedicato: Pinecone per la semplicità operativa, Weaviate o Qdrant per casi ibridi con filtri complessi e schema evolutivo. Errore classico nel 2026: scegliere Pinecone perché è il nome più conosciuto, scoprire dopo 6 mesi che il costo per milione di vettori è 3 volte quello di pgvector e che la latenza vinta è invisibile all'utente finale.

Con eval, non con feeling. Le metriche minime da implementare al day one sono quattro: retrieval recall (i documenti giusti finiscono nel contesto?), answer faithfulness (la risposta è effettivamente supportata dal contesto?), answer relevance (la risposta risponde alla domanda?) e citation accuracy (le citazioni puntano alla fonte corretta?). Per ognuna serve un dataset di valutazione di 100-300 domande reali, etichettate da esperti di dominio, da rilanciare a ogni modifica del prompt o del retrieval. Strumenti consolidati: Ragas, DeepEval, o setup custom su LangSmith e Langfuse. Senza eval automatici ogni release è un atto di fede e il sistema degrada in silenzio quando cambia il corpus, il modello o un prompt upstream.

Sì, e nel 2026 è diventato il default per molti settori regolati. Tre strategie. Primo: usare provider con zero data retention contrattuale (OpenAI e Anthropic la offrono via API enterprise) e residenza dati EU. Secondo: pseudonimizzare i dati prima dell'invio, sostituendo entità sensibili (nomi, codici fiscali, numeri di pratica) con placeholder e ricostruendo a valle. Terzo, il più solido: self-hosted con modello open-source (Llama, Mistral, Qwen) su infrastruttura sotto vostro controllo, italiana o europea. Le tre strategie si combinano: pseudonimizzazione sempre, self-hosted per il volume e ZDR enterprise per i task critici dove serve il modello frontier. La domanda giusta non è 'usare o no l'AI', è 'come architettare il flusso dati'.

Range tipico osservato sui progetti consegnati. Un assistente interno con 50-100 utenti attivi al giorno e RAG di medie dimensioni costa 50-200€/mese di sola inference. Una piattaforma B2B con 500-2000 utenti finali e query medie si aggira fra 400 e 1500€/mese. Un agente che fa molte chiamate per task (5-20 LLM call per richiesta) può salire facilmente sopra i 2000€/mese su modelli frontier. Le leve per ridurre il costo sono note: caching aggressivo delle risposte deterministiche, instradamento per difficoltà (modello piccolo per il 70% delle query, frontier per il 30%), prompt più corti tramite RAG mirato. La regola pratica: budget iniziale al 2x della stima, dopo 60 giorni di dati reali si ottimizza al 50% senza perdere qualità.

Sì, ed è il percorso che consigliamo nella maggior parte dei casi. Partire da frontier API (OpenAI o Anthropic) significa validare il caso d'uso in poche settimane senza investire in infrastruttura GPU, avere accesso immediato al miglior reasoning disponibile e raccogliere dati reali di utilizzo. La migrazione a self-hosted ha senso quando si verifica almeno una di queste condizioni: il volume rende l'inference frontier più cara dell'hosting dedicato (soglia tipica: oltre 3000€/mese), il vincolo normativo o contrattuale impone perimetro dati italiano o europeo, oppure la latenza richiesta scende sotto i 500ms su query semplici. La precondizione tecnica è una sola: progettare il layer LLM come pluggable fin dal giorno uno.

Un workflow è deterministico: A poi B poi C, sempre nello stesso ordine, eventualmente con if-else. Un agente è autonomo: riceve un obiettivo, sceglie quali tool usare, in che ordine, decide quando ha finito. Esempio pratico: un workflow di onboarding cliente legge il documento, estrae i dati, popola il CRM, manda l'email di benvenuto in sequenza fissa. Un agente di customer support riceve il ticket, decide se cercare in knowledge base, se chiamare il CRM, se escalare a umano o se rispondere direttamente. L'agente vince quando il task ha molte varianti e il costo del 'caso eccezionale' è alto, perde quando il processo è stabile e auditabile. Regola 2026: prima workflow, agente solo se i workflow non scalano in varietà.