Il vocabolario, senza il teatro.

Un sistema agentico è software che persegue un obiettivo in più passaggi, scegliendo da sé azioni e strumenti, invece di seguire una sequenza fissa.

La linea di confine con l’automazione normale è chi decide l’ordine delle operazioni. Una sequenza che hai disegnato prima è automazione; un sistema che decide cosa fare dopo, verifica se ha funzionato e riprova è agentico. Quell’autonomia è anche il rischio: quelli che sopravvivono alla produzione hanno un perimetro stretto e un’approvazione umana su tutto ciò che costa.

Un agente AI è un singolo lavoratore autonomo dentro un sistema del genere: riceve un compito, usa strumenti per portarlo a termine e riporta il risultato.

Nella pratica quelli utili sono molto meno affascinanti di quanto la parola suggerisca — smistare la posta, preparare preventivi, riconciliare fatture, rincorrere documenti mancanti. Un buon agente fa un lavoro solo, con strumenti definiti, ed escala tutto ciò che è ambiguo. Un agente con accesso a tutto e un mandato vago è un rischio.

L’orchestrazione è lo strato che decide quale modello, strumento o agente gestisce ogni passaggio di un compito, e in che ordine.

È dove sta la maggior parte dell’ingegneria vera di un prodotto AI, ed è dove stanno i costi. Farla bene di solito significa indirizzare l’80% dei casi facili verso un modello piccolo ed economico, tenendo quello costoso per i casi che lo meritano.

Una tool call è il modello che chiede al tuo software di fare qualcosa — interrogare un database, mandare un’email, recuperare un file — e poi usa il risultato.

È il meccanismo che trasforma un chatbot in un sistema che agisce. Ed è anche il confine di sicurezza: un modello può fare solo ciò che i suoi strumenti permettono, quindi la lista degli strumenti è il vero modello di permessi. Progettala come progetteresti un’API per un client non fidato, perché è esattamente quello.

Human-in-the-loop significa che una persona rivede, approva o corregge l’output del sistema prima che abbia effetto.

La domanda progettuale non è se averlo, ma dove metterlo. Approvazione su ogni passaggio rende il sistema più lento del lavoro manuale; approvazione su niente rende il primo output sbagliato un problema di qualcun altro. Mettilo dove un errore costa soldi, reputazione o un rapporto.

L’automazione di processo esegue una sequenza fissa di passaggi definita in anticipo da una persona, senza alcun giudizio proprio.

È ciò di cui la maggior parte delle aziende ha davvero bisogno, ed è molto più economica e prevedibile di qualsiasi cosa agentica. Se il processo si può scrivere come un diagramma di flusso senza mai usare la frase «dipende», non ti serve l’AI: ti serve quel diagramma, costruito bene.

L’RPA — robotic process automation — pilota software esistente attraverso la sua interfaccia, cliccando e digitando come farebbe una persona.

Utile quando un sistema non ha API e non le avrà mai. Fragile per natura: si rompe ogni volta che cambia l’interfaccia che imita. Trattala come un ponte verso un’integrazione vera, non come una destinazione.

Un LLM — large language model — è un modello addestrato su enormi quantità di testo a prevedere cosa viene dopo, e questo basta per riassumere, classificare, tradurre, scrivere e ragionare sul linguaggio.

È un motore di testo, non un database e non una calcolatrice. Tutto ciò che sa della tua azienda va messo davanti al modello nel momento in cui glielo chiedi. La maggior parte dei progetti AI deludenti sono quelli che si aspettavano la seconda cosa dalla prima.

Un foundation model è un modello generalista di grandi dimensioni, addestrato una volta a costi enormi e poi adattato a molti usi specifici.

Per quasi tutte le aziende il rapporto corretto con un foundation model è affittarlo tramite API. Addestrarne uno proprio è un investimento da milioni; il lavoro interessante è quello che ci costruisci sopra.

Il fine-tuning prosegue l’addestramento di un modello esistente sui tuoi esempi, così che adotti un formato, un tono o una competenza ristretta.

Insegna comportamenti, non fatti — un fraintendimento comune e costoso. Se vuoi che il modello conosca il tuo catalogo, serve il retrieval. Se vuoi che risponda sempre nel tuo stile o produca una struttura precisa, il fine-tuning aiuta. Prima prova prompting e retrieval: risolvono gran parte di ciò per cui si ricorre al fine-tuning.

Il RAG — retrieval-augmented generation — recupera i documenti rilevanti dai tuoi dati e li mette davanti al modello prima che risponda.

È così che un modello arriva a sapere cose su cui non è mai stato addestrato, ed è l’architettura di default per qualsiasi cosa risponda su conoscenza aziendale. La qualità di un sistema RAG è quasi interamente la qualità del suo retrieval: il modello raramente è il collo di bottiglia.

Un embedding è una lista di numeri che rappresenta un testo, posizionata in modo che ciò che ha significato simile stia vicino.

È ciò che fa funzionare la ricerca per significato invece che per parola chiave — una domanda su «fatture in ritardo» può trovare un documento intitolato «crediti scaduti». Il compromesso è che somiglianza non è rilevanza: una ricerca puramente per embedding restituisce volentieri cose legate alla domanda che però non la rispondono.

Un database vettoriale archivia embedding e trova rapidamente quelli più vicini a una query.

Sotto qualche centinaio di migliaia di documenti quasi certamente non ti serve dedicato: Postgres con pgvector basta ed è un sistema in meno da gestire. La decisione deve nascere dal numero di documenti e dal carico, non dallo schema architetturale di un fornitore.

La context window è la quantità massima di testo che un modello può considerare in una volta, contando sia ciò che invii sia ciò che scrive in risposta.

Finestre più grandi non hanno reso obsoleto il retrieval. L’accuratezza cala sensibilmente per le informazioni sepolte a metà di un input molto lungo, e paghi ogni token che invii, a ogni chiamata. Mandare le dieci pagine giuste batte mandarne quattrocento.

Un token è l’unità che i modelli leggono e scrivono — circa tre quarti di parola in inglese, e un po’ meno efficiente in italiano.

I token sono l’unità di fatturazione, quindi sono il modo giusto di ragionare sui costi. Una funzionalità che sembra economica per singola chiamata può diventare insostenibile a volume: vale la pena fare i conti prima di costruire, non dopo la prima fattura.

L’inferenza è l’atto di eseguire un modello già addestrato per ottenere una risposta, in contrapposizione all’addestrarlo.

Per un’azienda che usa l’AI invece di costruirla, l’inferenza è sostanzialmente l’intera voce di costo. Si ripete a ogni utilizzo, il che significa che una funzionalità AI è un costo operativo, non un investimento una tantum.

Un’allucinazione è una risposta sicura, scorrevole e sbagliata — un output ben formato ma non fondato su nulla di reale.

Non è un bug che si corregge: è una proprietà di come funzionano questi modelli. Si gestisce, non si elimina — ancora le risposte a fonti recuperate, fai citare al sistema da dove ha preso ciò che dice, e progetta perché una risposta sbagliata venga intercettata invece che eseguita.

Il model drift è il calo graduale dell’accuratezza di un sistema mentre il mondo in cui opera cambia.

I fornitori cambiano il layout delle fatture, i nomi dei prodotti cambiano, il provider rilascia una nuova versione del modello. Un sistema che era corretto al lancio e da allora non è più stato misurato non è un sistema funzionante: è un sistema non misurato. È il motivo per cui le eval devono esistere prima del go-live.

La prompt injection è un attacco in cui istruzioni nascoste nel contenuto che il modello legge lo portano a ignorare le proprie.

Diventa rilevante nel momento in cui il tuo sistema legge qualcosa dall’esterno — email, pagine web, documenti caricati, PDF dei fornitori. Oggi non esiste una soluzione completa. La difesa pratica è limitare ciò che gli strumenti del modello possono fare, così che un’iniezione riuscita non raggiunga nulla di prezioso.

L’output strutturato vincola il modello a restituire dati in una forma fissa, per esempio JSON conforme a uno schema che hai definito.

È ciò che rende un modello utilizzabile come componente invece che come finestra di chat. Elimina un’intera categoria di codice di parsing fragile ed è la differenza tra una demo e qualcosa su cui un altro sistema può contare.

Un’eval è un insieme di casi reali con risposte corrette note, usato per misurare se un sistema AI funziona davvero e se una modifica lo ha migliorato o peggiorato.

È la singola pratica che separa i sistemi AI che sopravvivono da quelli che marciscono in silenzio. Non serve che sia sofisticata: trenta casi reali in un foglio di calcolo, valutati onestamente, battono un’impressione. Senza eval non puoi cambiare un prompt o una versione del modello senza scommettere.

Un guardrail è un limite rigido su ciò che un sistema può fare o dire, imposto fuori dal modello invece che chiesto al modello.

La distinzione conta: istruire un modello a non fare qualcosa è una preferenza, non dargli lo strumento è una garanzia. Tetti di spesa, soglie di approvazione e accessi in sola lettura sono guardrail. Una frase gentile nel prompt no.

AI-native descrive software progettato fin dall’inizio attorno a ciò che i modelli sanno fare, invece di software esistente con funzioni AI aggiunte sopra.

La versione onesta del termine indica una differenza reale nella forma del prodotto: cosa chiede l’interfaccia, dove vive l’incertezza, cosa succede quando il modello non è sicuro. La versione marketing significa una chat nell’angolo. Chiedi quale delle due ti stanno vendendo.

Un MVP — minimum viable product — è la versione più piccola di un’idea che utenti veri possono davvero usare, costruita per capire se vale la pena continuare.

La parola portante è «viable», ed è quella che si perde per strada. Un MVP con cui nessuno riesce a completare un compito non ti insegna nulla, se non che hai costruito la cosa sbagliata velocemente.

Un pilota è una prova limitata di un sistema AI, su un gruppo ristretto o una fetta stretta del lavoro, fatta per decidere se investire.

Il fallimento tipico è il pilota che riesce e non porta a niente, perché era costruito su dati puliti a mano, senza integrazioni e con il team che prestava un’attenzione anomala. Definisci il perimetro in modo che la risposta riguardi la produzione, non il pilota.

La produzione è lo stato in cui un sistema viene usato per lavoro vero da persone che non l’hanno costruito, con dati veri e conseguenze vere quando sbaglia.

La maggior parte del costo ingegneristico vive tra una demo funzionante e questo. Gestione degli errori, casi limite, permessi, monitoraggio, i giorni in cui il provider ha un disservizio e qualcuno che se ne occupa un martedì pomeriggio — niente di cui la demo avesse bisogno.

L’osservabilità è poter vedere a posteriori cosa ha fatto un sistema AI e perché — quali input ha ricevuto, quali strumenti ha usato, cosa ha prodotto.

Senza, «l’AI ha sbagliato» è inutilizzabile. Con, trovi i dodici casi a settimana in cui fallisce e correggi lo schema. Per qualsiasi cosa agentica non è opzionale: un sistema multi-passaggio che non puoi rieseguire è un sistema che non puoi correggere.

Il forward deployed engineering è un modello di delivery in cui un ingegnere del fornitore lavora dentro il team, il repository e i dati del cliente finché il sistema non è in produzione.

È l’opposto della consulenza che consegna un piano e saluta. L’ingegnere impara come funziona davvero l’azienda invece di leggerne un brief, ed è per questo che funziona nello spazio tra un pilota che ha impressionato tutti e un sistema su cui qualcuno fa affidamento. Scegli questa strada quando sai già cosa va costruito e ti servono mani, non consigli.

Il passaggio di consegne è il punto in cui il team del cliente può eseguire, modificare e riparare il sistema senza chi l’ha costruito.

È un deliverable, non un evento, ed è la parte che si salta più facilmente. Concretamente significa documentazione che una persona esterna al progetto può seguire, una sessione con chi lo erediterà, e gli accessi trasferiti. Se il passaggio di consegne slitta di continuo, di solito è un modello di business, non un ritardo.

La computer vision è software che estrae informazioni da immagini e video — contare, ispezionare, localizzare o leggere ciò che c’è in un’immagine.

Le applicazioni mature e noiose sono quelle redditizie: leggere contatori, controllare etichette, contare scorte, individuare difetti su una linea. L’accuratezza dipende molto più dalla costanza di luce e posizione della camera che dal modello.

L’OCR — optical character recognition — converte l’immagine di un testo in testo che un computer può elaborare.

Problema risolto per documenti stampati puliti, ancora davvero difficile per scrittura a mano, scansioni scadenti e tabelle complesse. I modelli vision moderni gestiscono i documenti reali disordinati molto meglio dell’OCR classico, a un costo per pagina sensibilmente più alto — una scelta da fare in modo deliberato, tipo di documento per tipo di documento.

L’estrazione da documenti tira fuori campi specifici da documenti non strutturati — fatture, DDT, contratti, bandi — trasformandoli in dati strutturati utilizzabili da un sistema.

È uno degli usi dell’AI a più alto ritorno in una PMI italiana, perché l’input è una pila di PDF e l’output è una riga nel gestionale. La parte difficile non è mai il caso comune: è il fornitore che cambia layout, la scansione capovolta, e sapere quando il sistema deve rifiutarsi di indovinare.

Il costo di inferenza è quanto paghi per ogni utilizzo di un modello, normalmente fatturato per token in ingresso e in uscita.

Cresce con l’utilizzo, quindi va nel budget operativo dal primo giorno. I costi che sorprendono sono quelli invisibili: system prompt lunghi inviati a ogni chiamata, contesto recuperato che nessuno ha ridotto, e agenti che riprovano. Fai i conti sul volume atteso prima di costruire.

L’AI Act è la normativa europea che regola i sistemi di AI in base al rischio, con obblighi che entrano in vigore progressivamente nel 2026 e 2027.

La maggior parte degli usi in PMI — automatizzare la gestione documentale interna, redigere, riassumere — rientra nella fascia a basso rischio, con obblighi di trasparenza più che oneri pesanti. Ciò che cambia davvero il quadro è tutto ciò che tocca decisioni di assunzione, merito creditizio o dati biometrici. Questo non è un parere legale: se sei vicino a quelle categorie, procuratene uno.

La data residency è la questione di in quali Paesi i tuoi dati vengono archiviati ed elaborati, e quindi a quale legge sono soggetti.

Per le aziende europee decide quali fornitori sono utilizzabili prima ancora che inizi qualsiasi confronto tecnico. Oggi i principali provider offrono elaborazione in UE e diversi offrono condizioni di zero retention — ma le impostazioni di default spesso non sono quelle che vuoi, quindi conviene verificare invece di dare per scontato.

Il vendor lock-in è il costo di lasciare un fornitore: quanto di ciò che hai pagato non può venire via con te.

Nel lavoro sull’AI il rischio raramente è il modello, che è davvero sostituibile, e quasi sempre è tutto il resto: i prompt, le eval, le integrazioni e la pipeline dati. Chiedi di chi è il repository e se le eval sono tue. Se la risposta è vaga, quella è la risposta.