Competenze concrete su LLM (Mixtral, Llama, Claude, GPT), stack RAG (embedding, vector DB, retrieval pipeline), integrazione con sistemi aziendali esistenti (ERP, CRM, knowledge base). Sappiamo quando self-hostare (dati sensibili, latenza critica, costi API fuori controllo) e quando usare API cloud (esperimenti, carichi variabili, capacità di modelli top). Casi d'uso reali: assistenti interni, document analysis, automazione help desk, classificazione. Non vendiamo AI come feature di marketing: la proponiamo quando risolve davvero un problema, e documentiamo in anticipo costi operativi e limiti di affidabilità.
01La filosofia: AI è uno strumento, non un'etichetta di vendita
Non ci qualifichiamo come "AI company". Non abbiamo modificato il sito per metterci il badge "powered by AI". Siamo professionisti IT con 35-40 anni di mestiere alle spalle, che hanno attraversato tutte le onde tecnologiche — dal client/server ai mainframe Unix, dal web statico al cloud, dalla virtualizzazione all'LLM di oggi. L'AI moderna è l'ultima iterazione, e la usiamo dove risolve un problema reale.
La differenza, nella pratica, è che non partiamo dal tool per cercare il caso d'uso. Partiamo dal problema. Se un cliente ha bisogno di classificare diecimila ticket al mese, guardiamo prima se bastano regole ed euristiche; se la variabilità è troppo alta, allora un modello. Se un'azienda vuole un assistente interno sulla propria knowledge base, valutiamo prima se la documentazione è ordinata e ricercabile — perché se non lo è, nessun RAG la salva.
Detto in modo diretto: se qualcuno ti vende "intelligenza artificiale" senza dirti cosa fa, quanto costa a regime e dove fallisce, ti sta vendendo slide.
02Competenze concrete, non checklist
Quello su cui abbiamo messo le mani in produzione, per davvero:
- LLM API commerciali — Claude (Anthropic), GPT (OpenAI), Gemini (Google). Uso quotidiano, integrazione via SDK ufficiali, gestione rate limit, retry, cost tracking.
- Modelli open source self-hosted — Mixtral 8x7B / 8x22B, Llama 3 / 3.1 / 3.3, Gemma 2, Qwen. Inference con vLLM, llama.cpp, Ollama su GPU A100/L40S colocate.
- Embedding — BGE (M3, large), E5 (multilingual), OpenAI text-embedding-3, Cohere. Scelta del modello in base a lingua, dimensionalità, costo di inferenza batch.
- Vector database — Qdrant (il default per deploy on-prem), Postgres + pgvector (quando un DB relazionale c'è già e i volumi lo permettono), Weaviate in alcuni casi specifici.
- Orchestration — LangGraph per agenti con stato, LangChain per pipeline RAG standard, codice diretto Python quando il framework è solo overhead.
Non è una lista per impressionare chi legge: è il perimetro delle cose che sappiamo debuggare alle tre di notte quando un retrieval smette di rispondere.
03Self-hosted vs API: il trade-off reale
Non esiste una risposta universale. Esiste una matrice di vincoli che si valuta caso per caso.
| Vincolo | Self-hosted | API cloud |
|---|---|---|
| Dati sensibili / compliance | Obbligatorio (GDPR, segreti industriali, sanità) | Solo con DPA e zero-retention verificato |
| Carichi a picco | Scomodo (scalare GPU è lento) | Ideale (paghi solo l'uso) |
| Latenza critica (<500ms) | Possibile con modelli piccoli in LAN | Round-trip + coda lato vendor |
| Modelli frontier (capacità top) | Non replicabili in casa | Unica opzione reale |
| Volumi alti, prezzo prevedibile | Canone GPU fisso, break-even oltre una soglia | Costo lineare, può sfuggire |
In pratica spesso finisce ibrida: modello open self-hosted per il 90% dei task routine (classificazione, embedding, riformulazione), API frontier per il 10% dove serve davvero la capacità di ragionamento di Claude Opus o GPT-5.
04Casi d'uso che abbiamo consegnato
Niente demo da conferenza. Cose che girano in produzione e vengono usate tutti i giorni:
- Assistente interno su knowledge base aziendale (RAG) — documentazione tecnica, procedure, manuali. Pipeline: chunking consapevole della struttura dei documenti, embedding multilingue, retrieval ibrido (vettoriale + BM25), re-ranking, generazione con citazione delle fonti.
- Classificazione automatica di ticket / email — smistamento in code e priorità su volumi di migliaia al giorno. Human-in-the-loop sui casi a bassa confidenza.
- Summarization di documenti lunghi — contratti, verbali, report. Output strutturato (JSON schema) per alimentare CRM o workflow a valle, non testo libero.
- Analisi contratti / documenti legali — estrazione di clausole specifiche, scadenze, controparti. Sempre con revisione umana obbligatoria: non si firma niente su output LLM.
05Integrazione con i sistemi che già avete
La parte meno appariscente e quella dove si gioca il valore reale. Un LLM che non parla con l'ERP, il CRM e la knowledge base è una demo. Uno che ci parla è uno strumento.
Ci colleghiamo a ERP (SAP via RFC/OData, Odoo via API REST, sistemi legacy via SQL o file di scambio), CRM (Salesforce via REST, HubSpot, CRM custom direttamente su DB), knowledge base (Confluence, SharePoint, wiki Git, filesystem condivisi). La scelta delle connessioni la facciamo rispettando i vincoli di auth, audit e rate limit dei sistemi esistenti — niente scraping, niente service account che saltano i log.
06Costi operativi, a spanne
I numeri che vi servono per capire se l'investimento regge, non dopo il POC ma a regime.
- API Claude / GPT, volumi medi aziendali (centinaia di migliaia di token giorno): 200–800 €/mese di solo consumo. Sensibile al prompt design — un progetto mal tarato può raddoppiare senza preavviso.
- Self-hosted su GPU A100 40GB colocata da noi: 500–800 €/mese all-in (hw + energia + banda + gestione). Break-even contro le API intorno al milione abbondante di token/giorno.
- Pipeline di embedding (indicizzazione continua knowledge base): 50–200 €/mese, in funzione del volume di documenti e della frequenza di re-index.
Sono ordini di grandezza. Il numero reale dipende dal caso: lo misuriamo noi durante il POC e lo scriviamo in contratto prima di mettere in produzione.
07Quando non usare AI
La domanda più utile che potete farci. Rispondiamo sempre. Non usate AI quando:
- Una regex funziona. Validare un codice fiscale, estrarre un IBAN, parsare un log strutturato: non è un lavoro per LLM. Scatenare un modello sopra è spreco di soldi e introduzione di variabilità dove non serve.
- Una pagina HTML statica risolve. Per un FAQ con dieci voci ben scritte, una pagina è meglio di un chatbot — più veloce, più affidabile, più indicizzabile.
- La variabilità dell'output è un problema serio. Generare fatture, documenti contabili, messaggi regolatori: serve determinismo, non creatività. LLM qui sono un rischio.
- Il volume non giustifica la complessità. Se processate venti documenti al mese, farlo a mano costa meno di costruire, validare e mantenere una pipeline AI.
08I limiti che dichiariamo in anticipo
Nessun AI in produzione è privo di failure mode. Prima di firmare, li mettiamo nero su bianco:
- Hallucination — i modelli inventano. Mitigazione: RAG con citazioni, verifica di schema, human-in-the-loop nei punti critici. Mai eliminazione totale.
- Costi imprevedibili con API a token. Mitigazione: rate limiting, budget alert automatici, cap di emergenza.
- Model deprecation — i vendor ritirano versioni, anche con poco preavviso (viene riscritto il contratto d'uso senza preavviso). Mitigazione: astrazione dell'interfaccia, test di regressione, piano di migrazione dichiarato a contratto.
- Latenza — da centinaia di ms a secondi. Incompatibile con alcuni workflow real-time. Mitigazione: architetture asincrone, cache di risposte, modelli piccoli locali quando il tempo è un vincolo.
- Human-in-the-loop — per decisioni con impatto legale, economico o sanitario: sempre. Chi ti vende autonomia piena su questi dossier o ti mente o non ha mai mandato niente in produzione.