Tag: AI governance

AI & GENAI

Il watermark di Claude e il tool open source che lo smonta

Dal 2 agosto 2026 i nuovi modelli Claude lanciati nell’Unione Europea nascono con un watermark incorporato nel testo che generano, e, dove il formato lo consente, con metadati di provenienza firmati secondo lo standard C2PA. È l’attuazione pratica dell’articolo 50(2) del Codice di condotta europeo sull’AI Act, che Anthropic ha firmato insieme ad altri fornitori di modelli generativi: il funzionamento è descritto nella scheda ufficiale sul marking pubblicata dall’azienda.

La rete, come sempre, ha reagito più in fretta della norma. Su LinkedIn circola uno screenshot con toni da comunicato: non sarebbero passate nemmeno ventiquattr’ore da quando è comparsa una skill capace di ripulire i testi da Claude, Gemini e OpenAI, mille stelle su GitHub in un giorno, cento per cento open source. Il progetto si chiama watermarks-remover, ed è il banco di prova giusto per capire quanto valga davvero, oggi, marcare un contenuto generato da intelligenza artificiale.

Due firme, non una

Il watermark di Anthropic si scompone in due meccanismi distinti, e la distinzione conta perché determina anche dove un tool avversario può colpire. Il primo vive dentro il testo stesso: un segnale statistico intessuto nella scelta dei token, invisibile a occhio nudo, che sopravvive al copia e incolla e in parte anche alle modifiche successive. Il secondo vive nei file: metadati C2PA firmati, applicati a formati come SVG, PNG e JPG, pensati per segnalare se un contenuto è stato processato da Claude e se è stato manomesso dopo.

Anthropic stessa, nella sua scheda di trasparenza, elenca i limiti di entrambi i canali con una franchezza che raramente si vede nella comunicazione di prodotto. Un segnale rilevato non prova la paternità intera del contenuto, perché Claude può aver semplicemente tradotto, riassunto o corretto un testo altrui. E l’assenza del segnale non prova il contrario, perché basta un modello precedente all’agosto 2026, una riscrittura pesante, un passaggio troppo corto o una conversione di formato per far sparire la traccia. È dentro questo margine dichiarato, non contro di esso, che si è mosso chi ha scritto watermarks-remover.

Watermark scomposto in tre livelli

Il repository di Guillaume Meyer, con licenza MIT e oltre trecento fork, separa il problema in tre pezzi con garanzie molto diverse tra loro, e qui la differenza tra teoria e pratica diventa concreta. Il primo livello ripulisce i caratteri Unicode invisibili, spazi esotici, marcatori bidirezionali, tag nascosti che alcuni schemi di marcatura usano come vettore. È un’operazione deterministica, verificabile riga per riga, e non tocca una sola parola del testo visibile: puliscono un file di testo o un Markdown senza alterarne il significato.

Il secondo livello attacca invece i watermark statistici, quelli intessuti nella probabilità con cui un modello sceglie un token piuttosto che un altro, come SynthID-Text di Google o gli schemi in stile Kirchenbauer. Qui non esiste scorciatoia: il segnale è distribuito su quasi ogni frase, quindi rimuoverlo richiede una riscrittura pesante, frase per frase, non un rimescolamento di paragrafi. Gli stessi autori del progetto lo scrivono senza infingimenti nel proprio README, ponendo una domanda che è quasi un autogol dichiarato: se il piano è comunque riscrivere il testo con un modello più economico, che senso ha aver pagato prima un modello premium? La riscrittura degrada tono, voce, precisione, e il risultato non può superare il livello del modello usato per riscrivere.

Il terzo livello ripulisce infine i metadati dei file, dalle proprietà nascoste di un DOCX ai chunk EXIF e XMP di un PNG, passando per PDF, SVG, ODT, HTML. Qui però la matrice di copertura pubblicata dal progetto stesso ammette due buchi precisi: la rimozione dei watermark incorporati nei pixel resta fuori portata, e il cosiddetto soft binding C2PA, quel legame che può ricollegare un file a un manifest remoto anche dopo aver ripulito i metadati locali, non viene toccato. Per la marcatura pixel di SynthID esiste solo uno strumento esterno, non incluso nel pacchetto, che ne misura la probabilità di presenza: la rileva, non la cancella.

Il limite che la letteratura conosce da prima

Lo screenshot che circola su LinkedIn parla di “segnali statistici SynthID” gestiti dallo strumento, ed è vero solo a metà: vale per la variante testuale dello schema, descritta da Dathathri e colleghi su Nature nel 2024, non per l’uso più noto di SynthID sulle immagini, dove restare invisibile al watermark resta un’altra storia. La stessa distanza tra rivendicazione social e comportamento reale del codice vale per la cornice temporale: la cronologia delle release, da v0.0.1 a v0.3.2, mostra un lavoro incrementale fatto di hardening della sicurezza, scritture atomiche sui file, limiti di risorse, pipeline CI con firma delle dipendenze. Non è il weekend hack che il post lascia intendere, ed è forse anche per questo che le stelle su GitHub, oggi che scrivo, hanno superato quota tremila: non un picco isolato, un interesse strutturale.

C’è poi un piano più teorico che il caso pratico rende visibile. Zhang e colleghi, in un lavoro presentato all’ICML del 2024, avevano già dimostrato che nessuno schema di watermarking robusto può resistere a un avversario sufficientemente motivato senza pagare un prezzo inaccettabile in termini di qualità del testo. Il costo che gli autori di watermarks-remover ammettono candidamente, quello della riscrittura che impoverisce la prosa, non è un dettaglio implementativo: è la conferma pratica di un risultato che la ricerca aveva già scritto sulla carta, prima ancora che qualcuno lo trasformasse in un tool con trecento fork.

Ne avevo scritto, da un’angolatura diversa, quando affrontavo il tema della realtà sintetica e di quanto sia diventato fragile il confine tra ciò che vediamo e ciò che è stato costruito: lì il problema riguardava le immagini e i deepfake, qui riguarda il testo, ma la domanda di fondo resta identica, chi decide cosa merita fiducia.

L’etica del progetto, dichiarata esplicitamente dagli stessi autori, parla di uso legittimo per la privacy e l’igiene dei propri contenuti, non di frode accademica né di false dichiarazioni di autorialità umana. È una precisazione onesta, ma resta scritta in un file di testo dentro un repository con licenza MIT, dove nessuno controlla davvero chi la legge prima di usare lo strumento. È esattamente qui, nello spazio tra l’intenzione dichiarata e l’uso reale, che la governance deve costruire le proprie fondamenta, non nel codice ma nelle norme, nelle abitudini professionali, nella cultura di chi tratta un contenuto generato come parte di una filiera che merita verifica, non come un dato acquisito.

La trasparenza non vincerà perché un singolo watermark resiste a ogni tentativo di rimozione, quella battaglia l’aveva già persa la ricerca prima ancora che iniziasse. Vincerà se costruiamo un ecosistema di segnali sovrapposti, testo e metadati e strumenti di verifica esterni come l’interfaccia di mediazione tra chi produce e chi legittima un contenuto, capace di alzare il costo della cancellazione anche quando la cancellazione resta tecnicamente possibile. È un lavoro di infrastruttura più che di crittografia, e su questo lavoro vale la pena investire.

Fonti: How Claude marks AI-generated content (Anthropic); watermarks-remover di Guillaume Meyer su GitHub.

AI & GENAI, TECH & BUSINESS

Model router: come funziona il middleware che smista le richieste AI

Tra l’applicazione e i modelli è comparsa una casella che diciotto mesi fa non esisteva. Si chiama model router, intercetta ogni richiesta e decide quale modello deve rispondere prima che la richiesta parta, e nel giro di pochi mesi ha sviluppato un mercato suo, con prodotti commerciali, progetti open source e paper accademici che se la contendono.

Il 2 luglio scrivevo che il router viene prima del modello, riprendendo un’osservazione di Tomasz Tunguz: la logica di instradamento, non il modello scelto per ultimo, determina costi, latenza e chi resta padrone dell’infrastruttura. Quel pezzo era la tesi. Questo è la mappa: come quella casella si costruisce dentro, chi la vende già pronta, e il vincolo che quasi nessuno disegna nel diagramma.

Regole scritte a mano, regole imparate

Le architetture di model router in circolazione si riducono a quattro famiglie, e conoscerle serve perché ognuna sposta il compromesso tra costo, latenza e qualità in un punto diverso.

La più semplice è quella euristica: regole fisse, parole chiave, lunghezza del prompt. Se la richiesta contiene una query SQL, va dritta a un modello da codice, senza che nessun classificatore si accenda. Costa niente e si spiega in una riga, e si rompe appena il traffico esce dai casi previsti da chi ha scritto le regole.

Il gradino successivo è il router appreso, un classificatore leggero, di solito su embedding, che predice quale modello renderà meglio su quella richiesta in base a valutazioni storiche. Qui la qualità del model router dipende interamente dalla qualità dei dati di valutazione con cui è stato addestrato, e questa dipendenza pesa più di qualunque scelta di algoritmo.

Poi ci sono le cascate, che rovesciano la logica: si prova prima il modello economico, un validatore controlla la risposta, e solo se il controllo fallisce la richiesta sale al modello più potente. E infine gli ensemble, dove più modelli lavorano in parallelo sulla stessa richiesta e un giudice algoritmico sintetizza o sceglie. La cascata ottimizza il costo accettando qualche giro in più di latenza, l’ensemble ottimizza la qualità accettando di pagare ogni risposta tre o quattro volte.

Il model router diventa un prodotto da scaffale

Fino a poco fa questa casella la scrivevi in casa. Adesso la compri. OpenRouter ha portato in produzione a giugno Fusion, la versione a scaffale dell’ensemble: la tua richiesta va a un pannello di modelli in parallelo e un giudice fonde le risposte. Sul benchmark di deep research DRACO di Perplexity, un pannello economico composto da Gemini 3 Flash, Kimi K2.6 e DeepSeek V4 Pro ha segnato 64,7%, sopra GPT-5.5 da solo (60,0%) e Opus 4.8 da solo (58,8%), a circa metà del costo della configurazione di punta. Il dato che trovo più istruttivo è un altro, sepolto nello stesso annuncio: fondere Opus 4.8 con sé stesso alza il punteggio da 58,8 a 65,5. È la sintesi a produrre valore, non solo la diversità dei modelli.

Sul versante dei router appresi, Not Diamond vende l’addestramento su misura: carichi i tuoi prompt, i modelli provati e i punteggi delle tue valutazioni, e ne esce un router calibrato sui tuoi criteri, comprese le regole di formattazione o le convenzioni di codice che nessun benchmark pubblico misura. Il prodotto, in pratica, è la trasformazione dei tuoi dati di valutazione in una politica di instradamento.

La via che resta in casa

Chi non vuole un intermediario tra sé e i modelli, per latenza o per riservatezza dei dati, ha alternative open source che nell’ultimo semestre sono maturate in fretta.

NadirClaw è un proxy locale compatibile con l’API OpenAI che parte da un’osservazione empirica: nelle sessioni di sviluppo assistito, il 60-70% dei prompt sono operazioni semplici, letture di file, formattazioni, domande brevi, e non hanno bisogno di un modello premium. Un classificatore su embedding decide in una decina di millisecondi, un motore di ottimizzazione sfronda schemi di strumenti gonfi e array ridondanti prima dell’invio, tagliando il peso in token dal 30 al 70%, e sui benchmark RouterArena il profilo a cascata predefinito segna 0,7358 riducendo la spesa API fino al 70%. Gira sulla tua macchina, con le tue chiavi, e nessuna piattaforma di mezzo può cambiarti le condizioni.

Il fronte accademico spinge un passo oltre. Agent-as-a-Router, il paper dietro il framework ACRouter, parte da una diagnosi precisa: i router statici falliscono per deficit di informazione, decidono una volta e non imparano mai dal risultato. La risposta è un ciclo continuo in cui un orchestratore leggero instrada la richiesta usando lo storico di prestazioni conservato in una memoria interna, e un verificatore valuta l’esito con metriche oggettive, i test unitari sul codice generato per esempio, riscrivendo il risultato nella memoria come esperienza. Il router accumula esperienza fondata sull’esecuzione reale, ed è la stessa architettura del ciclo notturno che descrivevo nel pezzo di luglio, formalizzata e messa alla prova contro modelli di frontiera.

Per chi lavora con l’inferenza dentro il perimetro aziendale, ed è il terreno su cui costruiamo LocalAI, questa famiglia di strumenti è quella che conta: il routing self-hosted è ciò che rende sostenibile l’ibrido, i modelli locali per la maggioranza del traffico, il cloud per ciò che lo giustifica davvero.

Funziona dove il risultato si può misurare

Tutte queste architetture, dalla cascata al ciclo di ACRouter, si reggono su un presupposto che i diagrammi non mostrano: che esista un segnale oggettivo per dire se una risposta è buona. Il codice passa i test o non li passa, il JSON rispetta lo schema o non lo rispetta, la stringa si estrae o no. Dove il segnale è binario, il validatore della cascata sa quando scalare, il verificatore sa cosa scrivere in memoria, e il router impara.

Dove il segnale non c’è, tutto l’impianto si affloscia. Valutare un testo di marketing, un brainstorming aperto, una sintesi il cui pregio è il taglio e non la correttezza: su questi compiti la verifica automatica è debole, e un model router che non sa distinguere una risposta buona da una mediocre instrada alla cieca, con in più il pedaggio di latenza che le catene a cascata e i cicli di validazione si portano dietro per costruzione. Il router aggiunge un premio di complessità allo stack, e non ripara la logica applicativa rotta o il prompting fatto male: sposta i compiti giusti sui modelli giusti, a condizione che qualcuno gli abbia insegnato a riconoscerli.

Il registro dei prompt vale più del modello

Resta la parte che riguarda chi decide, non chi implementa. Il panorama dei modelli cambia ogni settimana, i prezzi per token continuano a scendere, e qualunque scelta di modello fatta oggi sarà rivedibile tra un trimestre. Le due cose che invece restano, e si apprezzano nel tempo, sono i dataset di valutazione interni e lo storico dei prompt con i loro esiti. Sono il carburante di ogni model router appreso, di ogni cascata calibrata, di ogni memoria alla ACRouter, e nessun fornitore può venderteli perché descrivono il tuo lavoro, non il suo.

L’avevo scritto parlando del vantaggio che si accumula in memoria, e il routing ne è la dimostrazione infrastrutturale: un’organizzazione che non registra cosa ha chiesto ai modelli e come è andata non potrà mai instradare bene, con nessuno strumento, comprato o costruito. Il processo di valutazione viene prima del router, come il router viene prima del modello. E mentre l’AI bill shock spinge tutti a cercare la casella magica che abbatte il conto, i dati che servirebbero ad addestrare il vostro model router si stanno raccogliendo adesso, oppure non si stanno raccogliendo affatto. Chi li registra oggi, tra un anno instraderà sulla propria esperienza. Gli altri affitteranno quella di qualcun altro.

Riferimenti: OpenRouter, Surpassing Frontier Performance with Fusion; Zhou et al., Agent-as-a-Router: Agentic Model Routing for Coding Tasks (arXiv); NadirClaw su GitHub; Not Diamond.

AI & GENAI, TECH & BUSINESS

Governare il significato: l’ontologia, l’infrastruttura invisibile dell’AI in azienda

La parola “cliente” significa tre cose diverse allo stesso tavolo. Finché a leggerla siamo noi non è un problema. Quando a leggerla è un agente che decide, lo diventa. È da qui che parte Govern Meaning, il primo degli AI Strategy Papers di ZeroFive, e questa ne è la versione breve.

Prendi la parola “cliente” in una riunione dove siedono vendite, finanza e supporto. Per il commerciale è chiunque abbia lasciato un’email, per la finanza è un’entità fatturata, per il supporto è chi ha diritto ad aprire un ticket. Tre definizioni, una parola sola, e ogni numero costruito su quella parola porta dentro l’ambiguità senza dichiararla.

Finché a leggere quei dati siamo noi, il malinteso si assorbe: aggiustiamo a mente, chiediamo conferma. Il problema nasce quando a leggerli mettiamo una macchina che deve rispondere, decidere, agire. La macchina non aggiusta a mente. Prende la definizione che trova, la applica con sicurezza, e ti restituisce una retention, un’esposizione al rischio, una lista di destinatari, senza sapere che quella definizione ne conteneva altre due dentro.

Ecco perché la parola d’ordine del momento, ontologia, non è una moda da convegno. È la struttura del significato su cui poggia davvero l’AI in azienda, e decide se un sistema ragiona o indovina.

Ancorare il modello: dal plausibile al verificato

Un modello linguistico è straordinario a produrre testo plausibile, e non è progettato per essere corretto. Sono due qualità diverse, e le confondiamo di continuo perché il testo plausibile, quando lo leggiamo, ci sembra corretto.

Un “probabilmente corretto” va benissimo quando suggerisci un film. Non va bene nella manifattura, nell’antifrode, in finanza, in medicina, dove una risposta sbagliata detta con sicurezza costa denaro, conformità, a volte vite. Lì serve un ancoraggio: il modello resta l’ultimo passo, non il primo, e il ragionamento vero avviene prima, sulla struttura. L’ontologia dà il significato, il knowledge graph dà i fatti veri di adesso, e il modello si limita a mettere in linguaggio una risposta già verificata. Vietare che le cuffie diventino impermeabili è un vincolo scritto una volta, non un vezzo, e blocca il fatto invalido prima che il modello parli.

Dopo la qualità del dato viene la struttura

Per vent’anni abbiamo lavorato sulla qualità del dato. Giusto, e non è finito, però il vincolo si è spostato di un gradino. La qualità dice se un’informazione è affidabile, la struttura dice alla macchina cosa quell’informazione significa e come le cose si relazionano. Sono due domande diverse, e il ragionamento vive nella seconda.

L’esempio che uso ai tavoli è il piano dei conti. Nessuna azienda seria lascia decidere per caso cosa è ricavo e cosa è costo: lo custodisce, lo governa, lo difende. Le definizioni delle entità in un grafo, cosa è un cliente, un prodotto, un fornitore, hanno oggi lo stesso peso del piano dei conti, ma su una superficie molto più larga, perché toccano i numeri che riporti, gli obblighi in cui incappi, le persone che un sistema di AI tratterà come bersaglio di una decisione. Il chart of entities è il nuovo chart of accounts.

Governare il significato

Presa sul serio, la parola ontologia porta molto lontano dalla scelta di un prodotto o di un database. Porta in sala del consiglio, perché le decisioni vere riguardano chi possiede le definizioni, e le definizioni vincolano tutto ciò che sta a valle.

C’è un dettaglio che rende il tema urgente adesso. Costruire un grafo è diventato più facile che mai, ma solo un knowledge graph su quattro arriva davvero in produzione, e il collo di bottiglia non è più costruire, è mantenere allineato il significato mentre il business cambia. I modelli semantici non falliscono di colpo, divergono: una definizione cambia in un reparto, nessuno aggiorna il resto, e l’agente continua a rispondere con sicurezza su una logica ormai superata. La divergenza uccide l’adozione dell’AI più in fretta della vecchia BI, perché l’AI non ha il senso critico dell’analista che compensa a valle. Fallisce in silenzio, e il silenzio è la parte pericolosa.

L’ontologia serve, quindi, ma come fonte di verità interna e governata, il resoconto ufficiale di come la tua azienda definisce le proprie cose, non una verità universale. E si comincia sempre dal problema di business, mai dall’eleganza del grafo, con la maturità del dato come primo lavoro, la misurabilità e la governance dal primo giorno, l’umano nel ciclo come default.

Il primo AI Strategy Paper

Questo è il nocciolo. Il paper completo, Govern Meaning, lo affronta per intero: cos’è davvero un’ontologia, l’architettura che ferma le allucinazioni, come costruire riusando gli standard invece di reinventarli, la deriva che uccide i progetti dopo il go-live, e come si porta tutto questo in azienda. Taglio da studio, con le fonti, ma pragmatico e leggibile da chi decide, non solo da chi implementa.

È il primo degli AI Strategy Papers di ZeroFive, una serie che prende una domanda difficile sull’AI e la affronta senza hype. Lo scarichi, in italiano e in inglese, e lasci la mail per i prossimi, nella pagina dedicata:

👉 Scarica Govern Meaning su zerofive.ai/papers

Il grafo latente della tua azienda esiste già, distribuito nelle teste delle persone e nelle giunture tra i sistemi. Il giorno in cui saranno i tuoi agenti a ragionarci sopra, erediteranno le tue definizioni così come sono, coerenti o contraddittorie. Tanto vale sceglierle adesso, mentre a rileggerle ci sono ancora persone capaci di correggerle.

AI & GENAI, TECH & BUSINESS

AI bill shock: la bolletta dei token è arrivata, come previsto

Il conto è arrivato, e ha pure un nome. Da mesi, tra le chiamate con i clienti e i pezzi che scrivo, ripeto la stessa cosa: il costo dei token non è un dettaglio da smanettoni, è la prossima voce che finisce sul tavolo del CFO. A marzo lo scrivevo su AI4Business, parlando di governo economico dei token come disciplina ancora da costruire. A maggio, qui sul blog, mettevo per iscritto che sarebbe arrivato sotto forma di budget esplosi a fine mese.

Questa settimana CorCom lo ha chiamato AI bill shock, riprendendo un’analisi di Analysys Mason: la spesa a consumo per modelli generativi, Api e agenti autonomi rende i budget aziendali sempre meno prevedibili, al punto da riportare sul tavolo di molti CIO l’idea di possedere un pezzo della propria infrastruttura invece di affittarla sempre. I numeri sotto contano più del titolo. Il budget è solo la parte più visibile: sotto ci sono i dati, la compliance, il controllo dell’infrastruttura su cui gira la tua azienda.

300 aziende, un balzo del 500%

Tra aprile e maggio circa 300 aziende hanno sollevato la questione dei costi legati ai token durante le chiamate agli investitori sui risultati trimestrali, contro le 93 dello stesso periodo dell’anno precedente. Lo racconta AI4Business citando Paul Roetzer e Mike Kaput del Marketing AI Institute. La Royal Bank of Canada ha visto il proprio consumo di token salire del 500% in sei mesi. Cisco descrive i propri volumi come fuori da ogni norma conosciuta.

Amazon, Walmart, Uber, Cisco e Meta, secondo quanto riportato dal Financial Times e ripreso sempre da AI4Business, hanno già introdotto tetti di spesa o indicazioni più severe su quando vale davvero la pena accendere un modello. Uber ha fissato un tetto di 1.500 dollari al mese per dipendente dopo aver esaurito, già ad aprile, l’intero budget AI previsto per il 2026. Amazon ha spento la classifica interna che misurava quanto i dipendenti usassero l’AI, dopo aver scoperto che alcuni ingegneri facevano girare bot autonomi solo per scalare la graduatoria: è il fenomeno che va sotto il nome di tokenmaxxing, la corsa alla vanità mascherata da adozione.

A Workato, azienda da 1.300 dipendenti, la spesa è aumentata di sette volte in un solo giorno quando Anthropic ha spostato l’azienda su un pricing basato sui token, a maggio. Goldman Sachs Research stima che l’uso degli agenti possa moltiplicare per 24 il consumo di token entro il 2030. E sul mercato aperto dei modelli, secondo i dati di OpenRouter ripresi dal Financial Times, i modelli cinesi hanno già superato quelli americani per consumo di token: quando il prezzo diventa il primo criterio di scelta, a vincere è chi costa meno, non chi segna il punteggio più alto sui benchmark.

Il token non misura il lavoro fatto

Più del volume, a ingannare è la natura della metrica. I fornitori fanno pagare i token di output da due a cinque volte più di quelli di input, perché generare una risposta costa computazionalmente più che leggerla: il modello prevede una parola alla volta, in sequenza, mentre l’input lo processa in un solo passaggio. Due flussi di lavoro che sembrano identici per volume possono avere costi molto diversi a seconda di quanto testo producono rispetto a quanto ne ricevono, e quasi nessuna azienda, quando firma il contratto, ci pensa davvero. Un prompt di 1.500 parole, quasi 2mila token, che produce una sintesi di 600 parole, circa 800 token, costa già un paio di centesimi con un modello come Claude 3.5 Sonnet: sembra nulla, finché non lo moltiplichi per centinaia di richieste al giorno e per ogni team che nel frattempo ha acceso un proprio agente senza dirlo a nessuno.

Gli agenti aggravano la cosa, perché a ogni passaggio ritrasmettono l’intero contesto della conversazione: alla decima fase di un compito, il modello rilegge integralmente le prime nove. AI4Business fa un esempio concreto, quello di un assistente per il servizio clienti che accede a una base di conoscenza di 20mila token: per mille richieste al giorno, genera 20 milioni di token quotidiani solo per rileggere sempre gli stessi dati, circa 60 dollari al giorno spesi prima ancora di rispondere a un cliente vero. Se l’agente si blocca in un loop, o richiama più volte lo stesso strumento, il conto sale prima che qualcuno se ne accorga.

L’AI bill shock non è un problema di cassa

Affidare l’inferenza a un fornitore esterno porta con sé più di un conto a consumo: la sua politica dei prezzi, i suoi limiti di utilizzo, le sue scelte su dove vivono i tuoi dati, la sua libertà di cambiare le regole senza preavviso. Il pricing può cambiare le regole da un mese all’altro, come è successo a Workato quando Anthropic l’ha spostata su un modello a consumo. Un fornitore può introdurre un tetto di utilizzo che scopri solo quando lo tocchi, a metà di una sessione di lavoro, come raccontano diversi utenti citati da AI4Business. Un governo può spegnere l’accesso a un modello, come abbiamo visto succedere quest’anno. E quando arriva un audit di conformità, la domanda su dove sia passato un dato aziendale durante l’inferenza, su quale server, sotto quale giurisdizione, spesso non ha una risposta scritta da nessuna parte.

Bain, in un sondaggio su 951 aziende pubblicato a giugno, trova che quasi il 40% di chi ha misurato i risparmi da AI è rimasto sotto il 10%, contro un obiettivo dichiarato dell’11-20%. Michael Heric, uno degli autori della ricerca, spiega che per molte aziende il business case si ferma alla spesa in token e non arriva mai a contare i costi di data engineering, di governance, di conformità che le girano intorno. Il 90%, nonostante tutto, aumenta comunque il budget per l’anno prossimo, prova che nessuno ha ancora imparato a misurare il ritorno dell’AI con lo stesso rigore con cui ne misura il costo.

LocalAI lavora esattamente in questa direzione: porta l’inferenza dentro il perimetro dell’azienda invece di affittarla ogni mese da qualcun altro. I costi non spariscono: cambia chi li governa. Sai dove vivono i dati, sai quanto costa davvero un carico di lavoro perché lo possiedi, e nessuno può cambiarti il prezzo o il tetto di utilizzo a metà mese.

Dall’opex che non controlli al capex che scegli

Analysys Mason legge lo spostamento come l’ennesimo giro di un ciclo che l’informatica ha già visto: dal mainframe centralizzato ai minicomputer distribuiti, dal PC in rete al cloud che ricentralizza tutto, e ora l’AI che riapre la stessa domanda. Comprare calcolo come servizio o possederne una parte? Per chi ha volumi di inferenza stabili, la risposta pratica passa quasi sempre dall’ibrido: hardware proprio per i compiti che non hanno bisogno di un modello di frontiera, server dedicati o cloud privato per il resto, il cloud pubblico riservato a ciò che lo giustifica davvero.

Il TCO a tre anni tra cloud e on-premise, calcolato sui prezzi reali di Claude, GPT, Gemini e DeepSeek, conferma la stessa cosa: nella maggior parte degli scenari aziendali italiani l’on-premise vince con margine quando i volumi sono prevedibili, mentre il cloud resta la scelta giusta per i picchi occasionali e per chi parte da zero. La maggior parte del traffico di un’azienda, del resto, non ha bisogno del modello più caro: ha bisogno di un sistema che decida bene dove instradarlo. Quella logica di instradamento, non il modello scelto per ultimo, è ciò che decide chi resta padrone della propria infrastruttura.

Decide il board, non il reparto IT

Il sondaggio di Bain lo conferma da un altro lato: le aziende che centrano i risparmi attesi sono quelle che hanno trattato l’accesso ai dati, la governance e il ridisegno dei processi come materia da consiglio di amministrazione, non da reparto IT. Vale lo stesso per il bill shock. Un alert di budget o un tetto di spesa imposto dall’alto sposta il sintomo, non la causa.

La prima domanda, in questi casi, non riguarda mai il modello. Riguarda dove vivono i dati, chi decide quanto vale un’ora di inferenza, cosa succede se domani il fornitore cambia le regole: non cambia molto se l’azienda ha cinquanta o cinquemila dipendenti, cambia solo quanto in fretta un budget fuori controllo diventa un problema di tutti, non solo di chi ha acceso l’ultimo agente.

La bolletta continuerà a salire, per tutti. La differenza, da qui in avanti, la fa chi ha già deciso come governarla e chi la scoprirà solo a budget già bruciato.

Fonti: CorCom su Analysys Mason; AI4Business, “La crisi dei token che spaventa i budget aziendali”; AI4Business, “AI, le aziende frenano”; Bain & Company, Automation and AI Pathfinder Survey 2026.

AI & GENAI, TECH & BUSINESS

L’Europa e l’AI di frontiera che non controlla

Il 7 luglio la Commissione europea ha presentato un Action Plan su cybersicurezza e intelligenza artificiale. A firmarlo è Henna Virkkunen, che nella nuova Commissione porta una delega dal nome esplicito, sovranità tecnologica, sicurezza e democrazia, e che ha messo in fila un ragionamento semplice, l’AI sta cambiando il significato stesso della sicurezza informatica e l’Europa deve tenere il passo alle vulnerabilità che le nuove tecnologie si portano dietro. Nelle settimane precedenti, a Bruxelles, si leggeva un fatto molto preciso: un modello di frontiera, il Mythos di Anthropic, aveva mostrato di saper individuare vulnerabilità nascoste nel software, e un governo straniero aveva deciso di limitarne l’accesso a chi non è cittadino americano.

Per anni l’Europa ha scritto regole per un’intelligenza artificiale che non costruisce. Questo piano è il primo documento che lo dice ad alta voce, con parole sue: le capacità di frontiera nascono per lo più fuori dai confini dell’Unione, e la loro disponibilità dipende da processi decisi altrove, spesso poco trasparenti. La cybersicurezza, letta così, non è un problema di adempimento, è un problema di sovranità digitale.

Una capacità di valutazione da costruire

La prima mossa concreta è una capacità europea di valutazione dei modelli, che la Commissione vuole creare nel 2027. Servirà a esaminare i modelli di frontiera prima che arrivino sul mercato, anche dal lato della sicurezza informatica, a sostegno del lavoro dell’AI Office, con criteri pubblici per i valutatori indipendenti che vorranno candidarsi.

Sotto l’annuncio c’è un’ammissione. Oggi l’Europa non riesce a valutare da sola i modelli che pretende di regolare. L’AI Act le ha dato il diritto di chiedere che quei modelli vengano esaminati, questo piano riconosce che le manca il muscolo per farlo in proprio.

Il primo pezzo di quel muscolo arriva prima. ENISA, l’agenzia dell’Unione per la cybersicurezza, e il Centro comune di ricerca costruiranno entro fine 2026 una piattaforma europea sicura per mettere alla prova i modelli in ambienti simulati, portando competenza sull’uso sicuro dell’AI agli operatori dei settori critici, dalla finanza alla sanità, dall’energia ai trasporti fino alla pubblica amministrazione.

Quando a decidere l’accesso è un altro

Qui il piano tocca il nervo scoperto. Le capacità di frontiera, scrive la Commissione, si sviluppano quasi tutte fuori dall’Unione, e chi le vuole usare dipende da processi decisi altrove. Conoscerle e potervi accedere non riguarda soltanto la resilienza informatica, riguarda la sovranità tecnologica di un continente.

L’episodio Mythos serve da promemoria. Un modello capace di trovare falle nascoste diventa un’arma se finisce nelle mani sbagliate, uno strumento di difesa se resta in quelle giuste, però la mano che decide chi può usarlo, in quel caso, stava a Washington e non a Bruxelles. È l’idea del permesso revocabile portata su scala geopolitica: quando il permesso di usare una capacità può essere ritirato da qualcun altro, dall’esterno, la tua sovranità sui processi che quella capacità protegge è presa in prestito.

Somiglia alla competenza presa in prestito di cui scrivevo a proposito del nostro rapporto quotidiano con questi modelli, solo che qui il prestito non tocca una singola persona che smette di saper fare una cosa, tocca la capacità di un’intera economia di difendere le proprie infrastrutture.

Dal codice condiviso alla vulnerabilità che resta scoperta

Il secondo pilastro guarda dentro le organizzazioni. Il piano non chiede di aspettare, chiede di usare da subito le capacità di AI già disponibili, compresi i modelli aperti, per trovare e correggere le vulnerabilità più in fretta di prima, e per reagire quando un attacco è già in corso. Da qui a fine 2026 ENISA pubblicherà linee guida e buone pratiche, e aprirà un progetto pilota sulla resilienza del software libero critico, pensato per accelerare la correzione delle falle con l’aiuto dell’AI.

Il codice aperto, in questo disegno, pesa più di una bandiera ideologica. Resta la sola capacità che un’organizzazione può ispezionare riga per riga e far girare sulle proprie macchine, senza chiedere permesso a nessuno e senza che nessuno la spenga da lontano. La stessa falla che un modello di frontiera straniero potrebbe scovare al posto tuo, oggi, un modello aperto che controlli tu può aiutarti a chiuderla domani.

La difesa prima della norma

C’è un contrasto che vale la pena guardare in faccia. Nelle stesse settimane in cui prepara questo piano, l’Europa rallenta il suo stesso codice: il 29 giugno il Consiglio ha dato il via libera definitivo alla semplificazione dell’AI Act, che sposta in avanti gli obblighi sui sistemi ad alto rischio, al dicembre 2027 per quelli autonomi e all’agosto 2028 per quelli dentro i prodotti.

Frenare la regola e costruire la difesa, allo stesso tempo, sembra una contraddizione e invece è una sola mossa. Il baricentro si sposta da ciò che vietiamo prima a ciò che sappiamo fare adesso, dalla conformità alla capacità. È l’ansia da competitività dei rapporti Draghi e Letta tradotta in atti di governo, e cambia il modo in cui un CIO dovrebbe leggere la politica europea sull’AI.

La lettura solo per adempimento non basta più. Ciò che pesa davvero, sui tavoli dove si decide, è lo stesso metro che vale con gli agenti: la reversibilità, cioè il controllo su runtime, contesto e permessi e la rapidità con cui puoi fermare un processo e riportarlo indietro senza danni.

Sovranità digitale, da iniziare adesso

Il piano, in filigrana, detta anche cosa fare senza aspettare né l’agenzia del 2027 né la sfida europea di fine anno. C’è l’igiene di base da rafforzare e la sicurezza da mettere fin dentro la progettazione, come le regole sulla cybersicurezza già chiedono. Conviene poi iniziare a usare i modelli disponibili, anche quelli aperti, per scovare e chiudere le vulnerabilità e per rispondere quando un attacco è già partito. Merita attenzione, da qui a fine anno, la piattaforma di ENISA per la sperimentazione dei modelli, con le linee guida che arriveranno tra il terzo e il quarto trimestre.

E la dipendenza da un singolo modello di frontiera controllato da un altro Stato va trattata per quello che è, un’esposizione nella catena di fornitura che una decisione presa altrove può accendere o spegnere da un giorno all’altro.

L’occasione, per chi in Europa costruisce sicurezza e AI nello stesso posto, prende una forma concreta. Bruxelles lancerà entro fine 2026 una sfida europea per le soluzioni di cybersicurezza basate sull’AI, e sta studiando con la Banca europea per gli investimenti uno strumento pubblico che finanzi i progetti strategici, la frontiera dell’AI compresa. Attorno a una capacità sovrana, che si possa ispezionare e valutare in casa, si sta formando un mercato.

Il piano costruisce la capacità di valutare i modelli e gli strumenti per difendere le reti, e sono due cose che all’Europa mancano da tempo. Resta però, sui tavoli dove lavoro, una domanda a cui non ho ancora una risposta netta: si può davvero essere sovrani su una capacità che non hai costruito e che non riesci a vedere fino in fondo? Finché la risposta non è chiara, la sovranità digitale somiglia più a un cantiere aperto che a un traguardo raggiunto.

Il documento è l’Action Plan on Cybersecurity and Artificial Intelligence presentato dalla Commissione europea il 7 luglio 2026, con il comunicato integrale della Commissione. La struttura in tre pilastri e le scadenze operative sono ricostruite dal servizio di Agence Europe. Il via libera definitivo alla semplificazione dell’AI Act è del Consiglio dell’UE, 29 giugno 2026.

AI & GENAI

Harness engineering: runtime, contesto, permessi

Il modello non è quasi mai il problema. Adnan Masood, in un’analisi dell’aprile 2026 sul control plane degli agenti, riporta che il 65% dei fallimenti dei progetti AI in azienda non nasce da carenze di ragionamento del modello, ma da difetti dell’infrastruttura che gli sta intorno, dal contesto che va alla deriva agli schemi disallineati, fino allo stato che degrada nel tempo senza che nessuno se ne accorga. Lo stesso numero gira in più rassegne di settore, e dice una cosa scomoda per chi compra licenze guardando solo i benchmark. La parte che fa fallire i progetti sta altrove, in un livello, l’harness engineering, che fino a diciotto mesi fa nessuno chiamava per nome.

Adesso un nome ce l’ha. Si chiama harness engineering, ed è diventato il mestiere che separa una demo che impressiona in riunione da un agente che regge tre mesi in produzione senza che qualcuno debba riavviarlo a mano ogni venerdì.

Harness engineering, cosa c’è davvero intorno al modello

L’harness è l’infrastruttura di runtime che avvolge il loop di ragionamento di un LLM. Salesforce lo descrive bene con un’immagine edilizia: il framework, LangChain o un agent builder qualsiasi, è il progetto dell’edificio, l’harness è il cantiere dove l’agente lavora davvero. Un paper su arXiv di marzo 2026 sull’architettura degli agenti da terminale lo definisce come il livello che coordina, a runtime, la spedizione degli strumenti, la gestione del contesto, l’applicazione delle regole di sicurezza e la persistenza dello stato fra un turno e l’altro.

Tradotto per chi deve decidere: il modello è il motore, l’harness è tutto il resto dell’auto. Senza, hai un blocco di potenza che gira a vuoto.

Dentro questo livello vivono sei o sette sottosistemi che lavorano insieme. L’assemblaggio del contesto, che decide cosa entra nella finestra del modello a ogni passo. I contratti degli strumenti, gli schemi che il modello deve rispettare quando chiede un’azione. La memoria, che tiene insieme un compito lungo. L’osservabilità, che permette di capire cosa è successo quando qualcosa va storto. Il recupero degli errori e l’orchestrazione, che governano la danza tra modello, strumenti e dati. Ognuno di questi è un punto dove un prototipo elegante diventa fragile.

System design per un runtime che hallucina

C’è un’obiezione che chi ha background da systems engineer fa appena sente “harness engineering”: questo lo facciamo da decenni. Loop che persistono lo stato tra una chiamata e l’altra, validazione degli input prima dell’esecuzione, retry on failure, log per l’audit. È esattamente quello che scrivi quando avvolgi un’API esterna e pensi “forse dovrei gestire il timeout”.

Akshay Kokane, in un’analisi che gira molto tra chi costruisce sistemi agentici, mette la questione in modo diretto: l’harness engineering è al 90% system design che conosci già, applicato a un substrato nuovo. Il 10% rimanente è genuinamente diverso, perché il tuo sistema ora ha al centro un componente non deterministico che può hallucinar una tool call, restituire una risposta semanticamente sbagliata o perdere il filo dell’obiettivo dopo quaranta turni di conversazione.

La differenza concreta sta in un solo punto: con un’API tradizionale validi il formato dell’output, con un agente devi validare l’intento. La pipeline di permessi di Claude Code non controlla solo se una tool call è sintatticamente valida, controlla se il modello è autorizzato a volere quello che vuole. Il vecchio stack retry-and-log non basta più perché il problema non si trova nella risposta, si trova nella richiesta, prima che qualcosa venga eseguito.

Questo spiega anche perché il nome è arrivato adesso, e perché conviene tenerlo anche se sa di marketing. Chi entra nell’AI engineering senza anni di systems engineering alle spalle ha bisogno di un vocabolario per afferrare questi pattern. Chi conia quel vocabolario si prende conferenze, SEO e mindshare, certo, ma distribuisce anche conoscenza che altrimenti resterebbe dispersa nei thread di GitHub. Il termine vale la pena impararlo per ciò che descrive, non per chi lo promuove.

La regola che cambia tutto

C’è un principio che ricorre in ogni guida seria sull’argomento, e vale la pena fermarsi: il modello non deve mai eseguire direttamente uno strumento. Mai. Il modello restituisce una richiesta di azione strutturata, l’harness valida lo schema, controlla i permessi, esegue, e reinietta il risultato.

Sembra un dettaglio implementativo. È invece il punto in cui si gioca la sicurezza di un sistema agentico in azienda. Se l’agente può chiamare arbitrariamente comandi, basta una prompt injection ben costruita dentro un documento che l’agente legge, e quel comando viene eseguito con i permessi dell’agente. Il livello di mediazione, la validazione tra l’intenzione del modello e l’azione sul mondo, è ciò che distingue un assistente da un rischio operativo che gira con le credenziali aziendali.

Le tassonomie di rischio più mature classificano le azioni: sola lettura, finanziarie, distruttive. Per ognuna una matrice di permessi diversa. È il tipo di ingegneria noiosa che non finisce nei keynote e che decide se il progetto sopravvive al primo incidente.

Quattordicimila parole perse in un colpo solo

Avevo costruito un agente editoriale che lavora sul mio blog via MCP, e per settimane ha funzionato. Poi un giorno, su un articolo molto lungo, una singola operazione ha sovrascritto un post intero perché lo strumento che usavo riscriveva l’intero corpo invece di toccare il blocco giusto. Quattordicimila parole perse in un colpo. Il modello aveva ragionato benissimo, l’harness intorno non aveva il vincolo che serviva.

Da lì ho imparato sulla mia pelle quello che le aziende stanno scoprendo su scala enterprise: la fragilità non sta nell’intelligenza del modello, sta nell’assenza di guardrail attorno alle sue azioni. Avevo dovuto cambiare strategia, passare a edit chirurgici con verifica a vuoto prima di ogni scrittura, salvare lo stato prima di toccarlo. Harness engineering applicato a una redazione di una persona sola.

Birgitta Böckeler, in un modello mentale pubblicato ad aprile 2026, descrive l’harness come una combinazione di guide in avanti e sensori di ritorno che si autocorreggono prima che l’output arrivi sotto gli occhi di un umano. Distingue i controlli computazionali, i linter, i test, dalle verifiche inferenziali, un modello che giudica un altro modello. Chiude con una proposta netta: la harnessability, la capacità di un sistema di essere imbrigliato in modo affidabile, dovrebbe diventare un criterio di prima classe nelle decisioni di architettura. Alla pari del costo e delle prestazioni.

L’etica nascosta in un livello di software

Qui il discorso esce dall’ingegneria ed entra in un territorio che mi interessa da tempo. In Pelle Digitale ho provato a descrivere lo strato sottile dove l’umano e la macchina si toccano, la mediazione che decide cosa passa e cosa no. L’harness è esattamente questo, portato dentro l’azienda: il punto in cui decidiamo quanta autonomia diamo a un sistema, dove mettiamo i confini, cosa l’agente può fare da solo e cosa deve passare da una mano umana.

Le scelte che sembrano tecniche sono scelte di governance: quali azioni richiedono conferma, quali log conservare e per quanto tempo, visto che la memoria di un agente che processa dati personali resta soggetta a GDPR come qualsiasi altro trattamento, e chi risponde quando l’agente sbaglia. Domande che nessun modello, per quanto grande, risolve da solo: si affrontano progettando con cura il guscio che gli sta intorno.

Avevo già osservato come Anthropic abbia spostato l’esecuzione degli agenti dentro l’azienda lasciando la regia fuori, con sandbox self-hosted e tunnel MCP. Quella mossa ha senso solo se chi la riceve sa costruire l’harness dalla propria parte del confine. Il fornitore ti dà il motore e parte dell’infrastruttura, il resto è responsabilità tua.

Prodotto, non collante

La soglia di accesso a un harness funzionante è più bassa di quanto sembri. Nick T., ricercatore che ha documentato la costruzione di un harness senza toccare una riga di codice, mette la cosa in modo diretto: chiunque può aggiungere file Markdown a un repository e sentire la differenza già dalla sessione successiva. Il CLAUDE.md o l’AGENTS.md nella root del progetto viene caricato dal modello all’avvio come un briefing. Le convenzioni di naming, i comandi di build, le cose da non fare: tutto scritto una volta, disponibile a ogni sessione senza doverlo ripetere. Primo strato, non l’intero edificio, ma quello che separa il ripartire da zero ogni volta dall’avere un agente che sa già dove si trova.

Trattate l’harness come prodotto, non come collante. La tentazione è incollare insieme un framework open e qualche script. Funziona finché non smette, di solito al primo carico reale. Le aziende che scalano comprano la plumbing commodity, runtime gestiti e telemetria di base, e costruiscono in casa la parte proprietaria che riguarda i loro dati e i loro permessi.

Mettete l’osservabilità prima dell’autonomia. Un agente che fa cose senza che voi possiate ricostruire cosa ha fatto è un debito tecnico travestito da innovazione. Prima i log strutturati e i sensori, poi l’allargamento dei poteri.

Testate l’harness, non solo il modello. Le valutazioni di sicurezza serie non si limitano a controllare le risposte del modello: provano l’infrastruttura con injection, timeout, sovraccarico di strumenti. Il punto debole è quasi sempre lì.

L’harness engineering non elimina i rischi degli agenti autonomi, li rende governabili. È una differenza che conta, perché governabile significa che qualcuno può rispondere delle decisioni del sistema, e in azienda è esattamente la domanda da cui parte tutto il resto. Quanta autonomia dare a un sistema di cui capiamo fino in fondo solo il guscio è una scelta di governance, e la maturità di un’organizzazione si vede da quanto sa tenerla bassa proprio dove tornare indietro costa di più. Se l’argomento vi tocca da vicino, è il terreno su cui lavoro con CEO e CTO ogni settimana.

Spunto dall’analisi di Adnan Masood sul control plane degli agenti, dal modello mentale di Birgitta Böckeler sull’harness engineering e dall’analisi di Akshay Kokane su Agent Harness Is Just System Design With a New Name (Level Up Coding) e dall’analisi pratica di Nick T. su Harness Engineering: A Deep Dive Into the Buildable Harness via Markdown Files (AI Advances).

AI & GENAI, TECH & BUSINESS

Il router prima del modello

Il 1° luglio Tomasz Tunguz di Theory Ventures ha scritto una cosa semplice che quasi nessuno applica: la maggior parte dei team che costruisce agenti sceglie il modello per primo. Sbaglia ordine, e lo sbaglia sistematicamente, perché il modello è la decisione più visibile e quindi quella su cui si concentra tutta l’attenzione, mentre il pezzo che davvero determina costo e latenza resta invisibile: il router, cioè il codice che decide chi risponde a ogni singola richiesta.

Tunguz lo racconta riferendosi al modo in cui Coinbase ha dimezzato la spesa in AI mentre il consumo di token cresceva, non frenando gli ingegneri con alert di budget ma cambiando i default di instradamento. È un’osservazione operativa, non una teoria, e tocca qualcosa che seguo da mesi lavorando con LocalAI: la sovranità computazionale si gioca sull’architettura, molto più che sulla scelta del modello.

Tre problemi diversi, non uno

Classificatore, router e selettore vengono trattati come sinonimi, e non lo sono. Il classificatore riconosce l’intento: trasforma una richiesta grezza dell’utente in un’operazione concreta, riassumere un repository, scrivere una risposta, lanciare una migrazione. Il router legge quell’etichetta insieme a poche feature, complessità, dimensione del contesto, storico di successo, e decide su quale livello far girare l’operazione. Il selettore, infine, sceglie il modello più economico dentro quel livello che rispetta una soglia di confidenza.

Confonderli è comodo mentre si scrive il primo prototipo, e costa caro dopo: la scelta del modello finisce sepolta dentro il prompt, e diventa impossibile testare due modelli diversi sulla stessa operazione senza riscrivere mezzo sistema. È lo stesso errore di livello che ho descritto parlando dello stack verticale dell’AI: confondere i piani porta a decisioni prese al piano sbagliato.

Il locale è gratis, l’asincrono è economico, il tempo reale costa

E infatti è questa la parte che mi ha fatto fermare a rileggere. Il calcolo locale ha un costo marginale prossimo allo zero, il batch asincrono costa due ordini di grandezza meno dell’inferenza in tempo reale, e la parte di lavoro che ha davvero bisogno di una risposta immediata è sorprendentemente piccola, una volta che il sistema può accodare.

Una bozza di risposta, un riassunto di repository, un memo di due diligence, la valutazione notturna di un batch di tracce: nessuno di questi compiti pretende un secondo di risposta. Pretende di essere fatto bene, non subito.

Ho visto questa stessa dinamica dentro LocalAI, dove la maggioranza del traffico non tecnico regge tranquillamente su modelli piccoli fatti girare in locale, con il cloud che entra in scena solo quando il compito lo richiede davvero. Non è un compromesso al ribasso, è disegno.

Un ciclo che impara mentre dorme

Ecco, e qui il design descritto da Tunguz aggiunge un doppio ritmo di feedback che vale la pena isolare. Un predittore sincrono annota ogni richiesta in ingresso con cinque segnali di rischio, dal contesto di repository mancante alle catene di dipendenze troppo lunghe, fino alle scritture che possono avere conseguenze pesanti se sbagliate, e intercetta così i compiti già noti come difficili prima che falliscano.

Poi, ogni notte, un valutatore batch rilegge le tracce del giorno e aggiorna i pesi del router, mentre il costo di quella valutazione resta vicino allo zero perché gira anch’esso in modalità asincrona. Ed è lì che il sistema scopre i modi di fallire che il predittore non aveva ancora imparato a riconoscere.

Mi sembra la versione infrastrutturale di qualcosa che scrivo da tempo a proposito del vantaggio che un’organizzazione accumula in memoria, non in modello: un sistema che non ha un meccanismo per far rientrare l’esperienza di ieri nelle decisioni di oggi accumula lo stesso tipo di debito, che si parli di persone o di router. L’ho scritto anche a proposito del tokenmaxxing: quel che resta dopo la spesa pesa più del numero speso, che si tratti di token o di traffico instradato.

Da dove si comincia davvero

Nei progetti dove entro a lavorare sull’adozione dell’AI, il primo intervento quasi mai tocca il modello. Tocca l’inventario dei segnali di fallimento: quali richieste arrivano senza contesto sufficiente, quali toccano dati sensibili, quali scritture, se sbagliate, costano care da correggere. Prima si rende visibile quel rischio, poi si decide dove instradarlo.

È un lavoro lento e poco fotogenico rispetto a scegliere l’ultimo modello uscito, e proprio per questo tende a restare indietro nella lista delle priorità. Ma un router costruito senza quella mappa dei rischi impara a fatica, perché non sa cosa sta effettivamente evitando di rompere. Il ciclo notturno di cui scrive Tunguz funziona solo se qualcuno, all’inizio, ha scritto a mano la prima versione grezza di quella mappa.

Chi possiede la logica di instradamento

Se il novanta per cento del traffico può girare su modelli piccoli e locali, la dipendenza da un singolo fornitore cloud smette di essere un fatto tecnico e diventa una scelta di governance, quasi sempre presa per default e non per decisione consapevole.

Progettare intorno al routing, non intorno al modello, sposta il controllo esattamente lì: chi scrive la logica che manda il traffico da una parte o dall’altra decide, di fatto, chi resta padrone dell’infrastruttura. Nella maggior parte delle aziende che conosco quella logica non la possiede nessuno davvero: cresce dentro il notebook di un ingegnere, non dentro un comitato di governance. Ed è lì, non nel modello scelto per ultimo, che si decide chi dipende da chi.

Spunto: Tomasz Tunguz, General Partner at Theory Ventures.

Confronto tra tokenmaxxing di vanità e tokenmaxxing strategico
AI & GENAI, TECH & BUSINESS

Tokenmaxxing: cosa serve oltre a bruciare token

Ottantacinquemila dipendenti di Meta compaiono in una classifica interna dedicata al tokenmaxxing. Si chiama Claudeonomics, l’hanno costruita loro stessi incrociando i dati di utilizzo aziendale, e misura una cosa sola: quanti token ciascuno consuma lavorando con l’AI. In cima ci sono i “Token Legend”, vince chi ne brucia di più. A fine aprile Business Insider ha raccontato la lista, a fine maggio Amazon ha spento la sua versione interna dello stesso gioco, e a giugno Fortune titolava che il tokenmaxxing era già finito.

Finito nella forma che fa notizia, forse. Nella forma che sposta budget vero dalle assunzioni al motore agentico, il tokenmaxxing è appena cominciato, e le due cose vengono continuamente confuse.

Amazon ha spento la classifica interna sui token

La dinamica descritta da chi l’ha vissuta è semplice. Un dashboard aziendale mette in fila i dipendenti per numero di token consumati, il numero diventa visibile ai manager, e da lì in poi la classifica smette di misurare qualcosa e comincia a determinarlo. È il meccanismo che gli economisti chiamano legge di Goodhart: una misura, appena diventa un obiettivo dichiarato, smette di essere una buona misura. Al Financial Times alcuni dipendenti Amazon hanno raccontato di aver fatto girare agenti su compiti inutili solo per restare in classifica, mentre Uber, secondo Fortune, ha esaurito l’intero budget AI del 2026 in quattro mesi.

Il paradosso è che nessuno, in questa versione del fenomeno, sta ridisegnando un solo processo. Si sta solo alzando un contatore. Ridisegnare i flussi di lavoro attorno all’AI è lavoro lento, spendere token per apparire “AI-native” è immediato, e la seconda cosa continua a travestirsi da prova della prima.

Il bilancio AI di Uber esaurito in quattro mesi

Nello stesso periodo, però, circola un’idea quasi opposta con lo stesso nome. Y Combinator la spiega ai suoi fondatori così: tokenmaxx, non headcountmaxx. Diana Hu, partner del fondo, lo dice senza troppi giri: una persona con gli strumenti giusti oggi può valere quello che prima valeva un intero team di ingegneria, e un budget API “scomodamente alto” è spesso più economico di un organico gonfiato.

Qui il token non è un trofeo da esibire su una classifica interna, è una voce di bilancio che sostituisce uno stipendio. Una startup che nasce nel 2026 non deve disimparare trent’anni di processi legacy per diventare AI-native, li costruisce così fin dal primo giorno: meno persone, più agenti, decisioni che si prendono dentro un flusso continuo invece che in una riunione settimanale.

Due aziende possono dichiararsi entrambe “tokenmaxxing” e fare l’esatto contrario: una infila numeri in un dashboard per sembrare avanti, l’altra riscrive l’organigramma attorno a quei numeri.

Cosa distingue un token che produce conoscenza da uno sprecato

Confronto tra tokenmaxxing di vanità e tokenmaxxing strategico

Il test operativo che circola tra chi studia il tokenmaxxing si riduce a una domanda: quando il volume di token sale, cosa cambia nel lavoro che viene effettivamente accettato? Se la risposta è “niente”, si sta guardando la versione di vanità. Se la risposta è “un ciclo di revisione in meno, una decisione presa prima, un cliente servito senza aspettare”, si è dentro qualcosa che vale la pena misurare.

Un sistema che moltiplica le interazioni con l’AI senza lasciare che quelle interazioni si accumulino in qualcosa di riusabile genera un debito. Non lo vedi nella fattura del mese, lo vedi tre mesi dopo, quando ogni nuovo agente riparte da zero perché nessuno ha organizzato ciò che il primo aveva già imparato. Il vantaggio, in questo genere di sistemi, smette di stare nel modello e finisce nella memoria che un’azienda accumula, e lo stesso principio vale per il conto dei token: quel che resta dopo la spesa pesa più del numero speso.

Il ciclo che rende utile il tokenmaxxing

L’azienda che tokenmaxxa in modo utile non brucia token in sessioni isolate, li fa girare in un ciclo che si autoalimenta. Un ticket di supporto genera una sintesi, la sintesi aggiorna la base di conoscenza condivisa, la base di conoscenza informa il prossimo agente che risponde a un cliente simile, e ogni giro rende il giro successivo più preciso e più economico. Satya Nadella lo scorso mese ha messo lo stesso meccanismo al centro della sua visione d’impresa, chiamandolo learning loop, e il punto che aggiungo io è che il ciclo regge solo se qualcuno possiede l’infrastruttura che lo fa girare, non solo il modello che lo alimenta.

Schema del loop aziendale: strumenti aziendali, agente AI, verifica umana, base di conoscenza condivisa

La meccanica del ciclo: trigger, non riunioni

Il loop non si costruisce con più call di allineamento, si costruisce con eventi che si attivano da soli. Un ticket chiuso genera un webhook, il webhook passa il testo a un agente con accesso al contesto storico del cliente, l’agente produce una sintesi strutturata e la scrive in un repository condiviso, e quella sintesi diventa automaticamente parte del contesto disponibile per il prossimo ticket simile. Nessun passaggio richiede che un umano apra una chat e formuli una domanda: il trigger sostituisce la richiesta.

Nel tokenmaxxing che funziona, la differenza tecnica che conta è tra un agente che risponde quando qualcuno lo interpella e un agente che si attiva quando cambia lo stato di un sistema: un CRM aggiornato, un documento modificato, una trascrizione caricata. Il secondo tipo tiene il ciclo vivo anche quando in azienda nessuno sta guardando, ed è quello che separa un assistente da un processo.

I loop cambiano forma da reparto a reparto

In assistenza clienti il loop più maturo parte da un ticket risolto: il caso alimenta una base di risposte pronte, e il prossimo cliente con lo stesso problema riceve una soluzione prima ancora che un operatore la legga. In ingegneria il ciclo passa dai code review, ogni commento di un revisore diventa una regola che l’agente applica al pull request successivo invece di essere ripetuto una volta di più. Nelle vendite il loop nasce dalla trascrizione delle chiamate: l’agente estrae le obiezioni ricorrenti e le carica nel CRM come suggerimenti per la trattativa dopo, senza aspettare il report trimestrale. Nella finanza aziendale il ciclo si chiude sulle policy di spesa, ogni eccezione approvata aggiorna la regola scritta e la richiesta successiva non arriva più a un umano se rientra nel nuovo perimetro. Nelle risorse umane il loop gira attorno alle domande sui benefit: la prima risposta corretta diventa voce di una base consultabile, la centesima non richiede più nessuno.

Il segnale che il ciclo funziona si misura sul tempo, non sui reparti coinvolti: quanto passa tra un’interazione e il momento in cui quell’interazione aggiorna qualcosa di consultabile per la prossima. Se la risposta è “mai”, quel reparto sta ancora solo usando l’AI, il loop non è partito.

Non conta quanto token bruci ma cosa resta dopo

Le aziende nate trent’anni fa restano indietro non perché usino meno AI, ma perché il loro organigramma è stato disegnato prima che esistesse un’alternativa al mettere una persona su ogni compito. Cambiarlo ora significa smontare processi che hanno funzionato per decenni, ed è un lavoro che nessun dashboard di token può velocizzare. Le aziende che nascono oggi non hanno questo problema, e la differenza tra chi vince e chi perde questa fase si vede meno nella fattura di Anthropic o OpenAI e più in quante decisioni, alla fine del trimestre, vengono ancora prese da un umano che rilegge tutto da capo.

Il ruolo umano che resta, in questo schema, è quello descritto anche in un pezzo recente su chi oggi gestisce insieme persone e agenti: meno produzione diretta, più verifica, correzione, approvazione finale. Un lavoro che a differenza dei token non si può comprare a peso.

Chi guarda la classifica dei token e pensa di aver capito qualcosa dell’azienda del 2026 sta guardando la metrica sbagliata. La domanda utile non è quanti token, ma quanti di quei token tornano indietro sotto forma di conoscenza che il prossimo agente non deve reinventare.

Fonti: Fortune, The Pragmatic Engineer, Business Insider / Y Combinator.

AI & GENAI, TECH & BUSINESS

Guidare Claude Code: la guida completa a skill, hook, subagent e regole

Il 18 giugno 2026 Anthropic ha pubblicato una mappa di tutti i modi in cui si può dire a Claude Code come comportarsi. Sono sette, e la cosa interessante non è l’elenco, è che ognuno di quei sette modi risponde a tre domande diverse: quando l’istruzione entra in memoria, se ci resta quando la sessione si allunga, e quanto è vincolante. Lavoro con questi agenti tutti i giorni, e ho imparato che la maggior parte degli errori di configurazione nasce dall’aver messo l’istruzione giusta nel posto sbagliato.

Per chi scrive codice da solo è una questione di efficienza. Per chi porta la responsabilità della tecnologia in un’azienda diventa qualcosa di più, perché la distanza tra un’istruzione e una garanzia è la stessa che separa una buona intenzione da una regola che nessuno può aggirare. Questa guida prova a mettere ordine: cosa sono i sette meccanismi, come si comportano quando la sessione cresce, e dove conviene scrivere ogni tipo di istruzione.

Ogni istruzione ha un costo e un’autorità

Ogni riga che finisce nella finestra di contesto di Claude occupa spazio e influenza il comportamento, e questi due effetti vanno tenuti insieme. Lo spazio è il costo: token che paghi a ogni richiesta, che l’istruzione serva o no in quel momento. L’autorità è il peso: quanto Claude segue quell’istruzione quando le cose si complicano, in una sessione lunga, in una situazione ambigua, o quando un file letto durante il lavoro contiene istruzioni nascoste che spingono in direzione opposta.

I sette meccanismi si distribuiscono lungo questi due assi. Alcuni costano molto e valgono sempre, altri costano poco perché entrano in scena solo quando servono, altri ancora non vivono affatto nel contesto perché sono codice che gira per conto suo. Sapere dove cade ciascuno è metà del lavoro. L’altra metà è una sola domanda, che torna a ogni scelta: questa cosa deve succedere quando il modello decide di farla, o deve succedere e basta?

CLAUDE.md, il file che Claude rilegge a ogni avvio

Il CLAUDE.md è un file markdown nella radice del progetto. Si carica all’inizio della sessione e ci resta per tutta la durata. Comandi di build, struttura delle cartelle, organizzazione di un monorepo, convenzioni di codice, norme del team: tutto questo sta bene qui, perché sono fatti che Claude deve avere sempre sottomano.

Ne esistono due tipi, e si comportano in modo opposto. Quello nella radice è sempre presente, sopravvive alle sessioni lunghe, e quando Claude Code comprime la conversazione per liberare spazio lo rilegge da capo. Quelli nelle sottocartelle invece si caricano su richiesta, solo quando Claude legge un file dentro quella cartella. Un app/api/CLAUDE.md non entra all’avvio, entra quando si tocca qualcosa sotto app/api, e sparisce di nuovo finché non si torna lì.

Il problema del file nella radice arriva con la scala. In un repository condiviso cresce come ogni configurazione senza padrone: ogni team aggiunge le sue righe, nessuno cancella niente, e quel testo si carica in ogni sessione di ogni persona, che riguardi il suo lavoro o no. Si pagano token, e si diluisce l’aderenza alle istruzioni che contano.

Il consiglio di Anthropic è di tenerlo sotto le duecento righe, dargli un proprietario, e trattarne le modifiche come si tratta il codice, con una revisione. Pensa a questo file come a un indice: una mappa del progetto che rimanda ad altri file dove Claude trova il dettaglio quando gli serve. Per le regole che devono valere su ogni repository dell’organizzazione, politiche di sicurezza o requisiti di conformità, esiste un CLAUDE.md gestito centralmente, distribuito sulle macchine via MDM, che il singolo non può escludere.

Le regole si caricano solo dove servono

Le regole sono file markdown dentro .claude/rules/, e danno a Claude vincoli o convenzioni precise. Senza un raggio d’azione si comportano come il CLAUDE.md: caricate all’avvio, rimesse dentro dopo ogni compressione, sempre presenti anche quando il compito non le riguarda.

Con il campo paths nell’intestazione cambia il momento del caricamento. Una regola legata a src/api/** resta fuori dal contesto durante una sessione che tocca solo la documentazione, e si carica unicamente quando Claude legge un file dentro quella cartella. L’intestazione si scrive così:

---
paths:
  - "src/api/**"
  - "**/*.handler.ts"
---
Ogni handler API deve validare l'input con Zod prima di processarlo.

Un vincolo legato a un file specifico, tipo le migrazioni che si possono solo aggiungere e mai modificare, sta bene come regola con il suo paths. Conviene preferire una regola con raggio d’azione a un CLAUDE.md annidato quando l’istruzione riguarda un aspetto trasversale, o un tipo di file che compare in più punti del codice ma non ovunque.

Le skill portano dentro la procedura al momento giusto

Le skill vivono in .claude/skills/, cartelle che contengono istruzioni, script e risorse, ognuna con un file SKILL.md fatto di nome, descrizione e corpo. All’avvio della sessione si caricano solo il nome e la descrizione. Il corpo entra quando la skill viene invocata, con un comando slash come /code-review oppure perché Claude riconosce che il compito corrisponde a quella descrizione.

/code-review è una skill già inclusa: legge le modifiche correnti e riporta cosa ha trovato senza toccare i file. La skill definisce il copione, e Claude segue lo stesso percorso ogni volta che la richiami. Quando la conversazione viene compressa, le skill già invocate vengono rimesse dentro fino a un tetto di token condiviso tra tutte: se ne hai usate molte nella stessa sessione, le più vecchie cadono per prime.

La regola pratica è corta. Le istruzioni procedurali, un flusso di deploy o una checklist di rilascio, stanno in una skill, non nel CLAUDE.md. Claude Code arriva con le sue skill, ma puoi scriverne di tue, ed è proprio quello che faccio per il lavoro editoriale e di consulenza, impacchettando in una cartella le procedure che ripeto.

Un agente separato per il lavoro che non vuoi leggere

I subagent sono file markdown in .claude/agents/, e definiscono assistenti isolati per compiti laterali. Ogni file ha un’intestazione YAML, nome e descrizione più eventuali campi per il modello e per gli strumenti a cui può accedere, seguita da un corpo che diventa il prompt di sistema di quel subagent.

Somigliano alle skill, perché all’avvio si caricano nome, descrizione ed elenco degli strumenti, mentre il corpo non si attiva da solo: Claude lo chiama tramite lo strumento Agent passandogli un prompt. La differenza vera è l’isolamento. Il corpo del subagent non entra mai nella conversazione principale. Il subagent gira in una finestra di contesto tutta sua, e al termine torna alla sessione madre solo il suo messaggio finale, spesso il risultato aggregato di molti passaggi, più qualche metadato.

Questo schema scala in un modo che vale la pena capire. I subagent si annidano fino a cinque livelli, e i flussi di lavoro dinamici orchestrano da decine a centinaia di agenti in background senza che tu debba specificare ogni dettaglio. Il piano di orchestrazione e i risultati intermedi vivono dentro variabili di script invece che nel contesto di Claude, e questo permette di crescere senza perdere fedeltà alle istruzioni.

L’isolamento è il motivo principale per scegliere un subagent invece di una skill. Lo usi quando un compito laterale, una ricerca profonda o l’analisi di un log ingombrerebbe la conversazione principale con risultati intermedi che non riguarderai più. Usi una skill quando vuoi che la procedura si svolga dentro il thread principale, sotto i tuoi occhi, un passaggio alla volta. La documentazione sui subagent entra nel dettaglio dei campi dell’intestazione e dei permessi sugli strumenti.

Gli hook girano fuori dal contesto

Gli hook sono comandi, endpoint HTTP o prompt che danno un controllo più deterministico sul comportamento di Claude, perché scattano su eventi precisi del suo ciclo di vita: una modifica a un file, una chiamata a uno strumento, l’avvio della sessione. Si registrano nel settings.json, nelle impostazioni gestite, o nell’intestazione di una skill o di un agente.

Ne esistono di cinque tipi: command, HTTP, mcp_tool, prompt e agent. Tutti scattano in modo deterministico, ma i primi tre eseguono codice, mentre prompt e agent usano il giudizio di Claude invece di una regola fissa per decidere l’output. Il costo in contesto è basso, perché la configurazione vive fuori dalla finestra principale. Qualche output può rientrare: l’errore di un hook che blocca un’operazione viene salvato nel contesto, così Claude sa perché la chiamata è stata negata. La maggior parte degli hook invece non lascia traccia, a meno che la configurazione non lo preveda. Se hai salvato la cronologia della chat in un altro file prima della compressione usando l’evento PreCompact, Claude non saprà in quale file l’hai messa.

È qui che gli hook si staccano dal CLAUDE.md, dalle regole e dalle skill. Servono per tutto ciò che deve accadere in modo deterministico: far girare un linter dopo ogni modifica, scrivere su Slack a lavoro finito, bloccare certi comandi prima che partano. Un hook PreToolUse può ispezionare qualunque chiamata a uno strumento e uscire con codice 2 per negarla. Costano poco perché sono codice che l’ambiente esegue, non istruzioni che Claude deve caricare e interpretare.

Output style e system prompt: l’autorità più alta

Gli output style sono file in .claude/output-styles/ che iniettano istruzioni nel prompt di sistema. Non vengono mai compressi, si caricano all’inizio di ogni sessione, e dopo la prima richiesta restano in cache, quindi il costo in contesto è moderato. Stando nel prompt di sistema portano il peso di aderenza più alto tra tutti i metodi visti finora, e vanno usati con misura.

C’è una trappola. Cambiare l’output style sostituisce quello predefinito, a meno che tu non imposti keep-coding-instructions: true nell’intestazione. In Claude Code questo cancella le istruzioni che dicono a Claude di star aiutando con un lavoro di ingegneria del software, e con loro abitudini critiche come quando aggiungere o togliere commenti al codice, come gestire le questioni di sicurezza, l’abitudine a far girare i test prima di dichiarare finito un lavoro. Senza accorgertene, Claude Code diventa un assistente generico invece di un assistente che programma. Prima di scriverne uno tuo, conviene guardare quelli già inclusi: Proactive, Explanatory e Learning coprono i bisogni più comuni.

L’alternativa più leggera è il flag append-system-prompt. Dove modificare un output style può avere effetti larghi e non voluti, il flag è solo additivo: non cambia il ruolo di Claude, gli aggiunge istruzioni. Si passa al momento dell’invocazione e vale solo per quella, non resta come file tra le sessioni. Costa qualche token in più in ingresso, attenuato dalla cache dopo la prima richiesta, ed è la via giusta per standard di codice specifici, formati di output, conoscenza di dominio. Con un avvertimento che vale per tutti i metodi a prompt: più istruzioni infili, meno Claude le segue alla lettera, soprattutto se qualcuna contraddice le altre.

Quando l’istruzione è nel posto sbagliato

Ci sono segnali che dicono che un’istruzione andrebbe spostata altrove. Se ti ritrovi a scrivere “ogni volta che X, fai sempre Y” nel CLAUDE.md, e quel comportamento deve essere affidabile, tipo far girare prettier dopo ogni modifica, quello è un hook nel settings.json. Il modello che sceglie di lanciare un formattatore è un’altra cosa rispetto al formattatore che parte da solo.

Se nel CLAUDE.md compare un “non fare mai questo”, l’istruzione è lo strumento sbagliato. Claude la seguirà quasi sempre, ma sotto pressione, in una sessione lunga, in una situazione ambigua, o per via di un’iniezione di prompt dentro un file aperto durante il compito, il modello può non rispettarla. Una barriera vera è deterministica, e si costruisce con gli hook e i permessi. Un hook PreToolUse ispeziona la chiamata ed esce con codice 2 per bloccarla. Le impostazioni gestite vanno oltre: le distribuisce un amministratore, l’utente non le può sovrascrivere, e sono l’unico modo per imporre una barriera deterministica su tutta l’organizzazione.

Una procedura di trenta righe nel CLAUDE.md va in una skill. Una regola che vale solo per src/api/** va scritta con il suo paths, perché senza è meccanicamente identica a mettere quel testo nel CLAUDE.md, sempre caricata, sempre a consumare token. E le preferenze personali, tipo usare sempre messaggi di commit semantici, vanno nei file a livello utente, che valgono per ogni sessione a prescindere dal repository, non nel file di progetto condiviso con il team.

Un’istruzione non è una garanzia

Tutto questo si riduce a una distinzione che per chi guida la tecnologia conta più di qualunque dettaglio di configurazione. Un’istruzione a prompt, stia nel CLAUDE.md o in una regola o in un output style, è una richiesta che il modello interpreta e quasi sempre rispetta. Una barriera costruita con hook e permessi è un fatto meccanico che non dipende dal giudizio del modello. La prima si piega sotto pressione, la seconda no. Quando in gioco ci sono dati sensibili, ambienti di produzione, o un comando che non deve partire mai, l’unica risposta seria è quella deterministica.

C’è anche un costo che si accumula nel tempo, e somiglia parecchio a quello di cui scrivo da mesi a proposito del debito cognitivo. Un CLAUDE.md senza proprietario cresce, e ogni riga in più si carica in ogni sessione di ogni persona, pesando sul budget di token e annacquando le istruzioni che servono. È un debito di contesto: lo paghi poco alla volta, finché un giorno la finestra è piena di righe che nessuno legge e il modello segue peggio quelle importanti. La cura è la stessa di sempre, un proprietario, una revisione, e la disciplina di spostare ogni istruzione dove il suo costo e la sua autorità corrispondono al compito.

Nei vari testi che scrivo da un po’ ho provato più volte a descrivere l’interfaccia tra la mente e gli strumenti che la estendono, e guidare un agente è proprio quel punto: il momento in cui un’intenzione umana si traduce in qualcosa che una macchina eseguirà al posto tuo. Quando hai qualcuno di questi meccanismi a posto, puoi raccoglierli insieme, skill, subagent, hook e output style, dentro un plugin, e condividere un assetto coerente con il team o tra i progetti.

Senza dubbio nei prossimi mesi questi strumenti diventeranno più semplici e più capaci. La domanda che resta aperta è chi, nella tua organizzazione, possiede la mappa di cosa Claude può e non può fare, e la tiene aggiornata mentre la finestra di contesto si riempie. Se è il genere di mappa che serve disegnare per la tua azienda, è una delle conversazioni che porto al tavolo nel mio lavoro di advisory.

Fonte: Anthropic, Steering Claude Code: CLAUDE.md files, skills, hooks, rules, subagents and more, 18 giugno 2026. Approfondimenti nella documentazione ufficiale su subagent e output style.

AI & GENAI, TECH & BUSINESS

Vendor lock-in AI: l’errore architetturale dei progetti enterprise

Conversazione vera, due settimane fa, con il CTO di un’azienda manifatturiera italiana medio-grande. Loro hanno un sistema AI in produzione da quattordici mesi, costruito sopra le API di OpenAI con function calling, prompt engineerizzati con cura, memoria conversazionale gestita in Pinecone, agente che orchestra cinque tool diversi. Funziona bene, gli utenti sono contenti, il management è soddisfatto. Mi chiama perché ha letto i miei articoli su AI privata e vuole capire se ha senso, per loro, valutare una migrazione verso un setup on-premise con modelli open-weight.

La mia risposta è stata: “Tecnicamente sì, però oggi la migrazione vi costa quanto rifare metà del prodotto da zero”. Lui ha avuto un momento di silenzio, poi ha chiesto: “Come è possibile? Usiamo l’API standard di OpenAI. Mi avevano detto che era portabile”. La risposta a quella domanda è il tema di questo articolo. È un fenomeno che chiamo “vendor lock-in tecnico AI“, e fa fallire più progetti AI enterprise di quanti se ne discutano apertamente.

Il debito tecnico che non si vede

Le aziende che costruiscono prodotti AI sopra API cloud accumulano un debito tecnico di portabilità che non emerge nei primi mesi. Funziona tutto, perché ogni provider rispetta il proprio contratto API. Però sotto la superficie, dozzine di scelte tecniche e operative legano profondamente il prodotto al provider specifico, in modi che diventano evidenti solo quando si prova a cambiare.

Vorrei elencare i punti di lock-in più ricorrenti, in ordine crescente di gravità.

System prompt engineerizzati per quirk specifici del modello. Ogni LLM ha le sue idiosincrasie. Claude reagisce a certe formulazioni in modo diverso da GPT-4. Gemini ha pattern di risposta tutti suoi. Mistral e Llama hanno default culturali diversi. Quando il vostro team di prodotto ha lavorato 6 mesi per perfezionare prompt che funzionano bene sul modello scelto, quei prompt non funzionano più allo stesso modo se cambiate modello. La migrazione richiede re-engineering completo, con cicli di test e regression.

Function calling con sintassi proprietaria. OpenAI ha introdotto il function calling con uno schema specifico. Anthropic ha il suo formato per i tool. Gemini ha un altro ancora. Anche se tutti sono “function calling”, il modo in cui passare gli schemi, gli argomenti, le risposte è leggermente diverso. Codice che orchestra agenti complessi con dieci tool diversi è ricco di queste specificità.

Embedding model legati al provider. Se avete fatto RAG con embeddings di OpenAI ada-002 o text-embedding-3-large, quei vettori non sono compatibili con embeddings di Cohere, Voyage, BGE. Per cambiare modello di embedding, dovete re-indicizzare tutto il corpus documentale, che su grandi volumi richiede tempo e costa risorse.

Vector database con schemi rigidi. Avete usato Pinecone con metadati strutturati in un certo modo, indici composti definiti, filtri configurati. Migrare a Qdrant, Weaviate o Milvus significa rifare lo schema, validare i risultati, magari riadattare le query applicative.

Memoria conversazionale tarata sul modello. I limiti di token, le strategie di summarization, le truncation policies, sono tutti calibrati sul modello specifico. Cambiando modello, la memoria si comporta diversamente, i contesti vengono troncati in modo diverso, le conversazioni perdono coerenza in punti diversi.

Monitoring e observability legati alle API. Avete configurato logging strutturato per le chiamate OpenAI con i loro request ID, latency metrics, cost tracking basato sui loro pricing tier. Cambiare provider significa rifare l’osservabilità.

Skills del team. Il vostro sviluppatore AI senior conosce profondamente l’API OpenAI dopo due anni di lavoro. Conosce le edge case, sa come reagire ai 429, ha intuizione per i prompt che funzionano. Su un provider nuovo, quella conoscenza è azzerata. Servono mesi di learning curve.

Sommato tutto, una migrazione fra provider AI cloud su un’applicazione in produzione di 12+ mesi richiede tipicamente 2-4 mesi di lavoro di team specializzato. Quei mesi sono pieni di rischio: i clienti si lamentano dei comportamenti diversi, qualità delle risposte temporaneamente peggiore, bug che emergono solo in produzione, costi che non rientrano nei piani.

L’astrazione che salva la vita architetturale

C’è una soluzione architetturale ben nota, e si chiama “abstraction layer”. L’idea è semplice: invece di chiamare direttamente le API del provider AI, fate passare ogni interazione attraverso un layer intermedio che espone un’interfaccia stabile compatibile (tipicamente compatibile con OpenAI, perché è lo standard de facto). Il layer si occupa di tradurre nel formato del provider specifico sottostante. Quando volete cambiare provider, cambiate solo il layer, non le applicazioni.

Sembra banale, ma poche aziende lo fanno bene. La maggior parte di quelle che ho visto in advisory ha un’astrazione “leggera” che gestisce solo il routing delle chiamate al LLM, ma non astrae le altre cinque-sei superfici di integrazione (embeddings, vector DB, memoria, tools, logging). Risultato: il giorno della migrazione, scoprono che l’astrazione copre solo il 30% del problema.

L’astrazione completa deve coprire sette superfici, e qui entra il valore di un orchestratore maturo come LocalAI.io, su cui ho investito personalmente come cofondatore.

1. Chat completions. LocalAI espone l’endpoint OpenAI-compatible standard, ci puntate il vostro codice esistente, e il modello sotto può essere Llama, Mistral, Qwen, DeepSeek o anche un OpenAI/Claude pass-through. Cambiate il modello dalla console, le applicazioni continuano a funzionare.

2. Embeddings. Stessa cosa per il modello di embedding. Esponete l’endpoint embedding-compatible OpenAI, dietro c’è il modello che decidete (bge-m3, multilingual-e5, OpenAI ada). Cambiate dietro senza toccare il codice.

3. Function calling. L’orchestratore unifica le specifiche function calling fra provider diversi, traducendo in tempo reale.

4. Vector database. Qui l’astrazione è più sottile: serve un layer applicativo (LangChain, LlamaIndex, o codice custom) che si interfacci con un’API generica di vector DB. Qdrant, Weaviate, Chroma hanno tutti adapter per le librerie principali.

5. Memoria conversazionale. Va gestita in un livello applicativo che non dipenda dal modello specifico. Esistono librerie come mem0 che fanno questo lavoro bene.

6. Monitoring. Centralizzato sull’orchestratore, non sui singoli provider. Tutto il logging passa per il layer, indipendentemente da chi sta servendo le richieste.

7. Cost tracking. Anche qui centralizzato. L’orchestratore conta i token, applica le sue policy di pricing, espone le metriche aggregate.

Con un’astrazione completa di queste sette superfici, una migrazione di provider AI può ridursi a un’ora di lavoro di reconfigurazione, invece di tre mesi di refactor. È una differenza che, su un’applicazione enterprise, si traduce in 50.000-200.000 euro risparmiati ogni volta che cambiate.

Quando vale la pena pagare il costo dell’astrazione

Una nota di onestà. L’abstraction layer ha un costo iniziale. Aggiunge una dipendenza al vostro stack, un piccolo overhead di latenza (5-30ms tipicamente), un componente in più da manutenere. Per startup che stanno facendo POC veloci, è probabilmente overkill, perché il rischio di voler cambiare provider entro 6 mesi è basso e gli investimenti accumulati sono minimi.

Per le aziende enterprise che stanno costruendo un sistema AI destinato a vivere 3-5 anni, l’astrazione vale praticamente sempre l’investimento. Tre situazioni dove l’astrazione è essenziale:

Quando il modello scelto oggi non sarà quello di fra 24 mesi. L’ecosistema AI evolve velocemente. Nel 2024 OpenAI dominava. Nel 2026 Claude, Gemini, Mistral, modelli open-weight sono tutti competitivi su task specifici. Nel 2028 lo scenario sarà ancora diverso. Un’azienda che si lega oggi a un singolo provider si trova a inseguire la concorrenza con due anni di ritardo.

Quando la compliance può cambiare. Una banca italiana che oggi usa Claude potrebbe domani avere requisiti che impongono di portare il modello in casa per AI Act o evoluzioni normative. Se ha un’astrazione, la migrazione è di una settimana. Se non ha, sono 4 mesi.

Quando vi serve usare modelli diversi per task diversi. L’approccio “best model per ogni task” sta diventando standard. Claude per scrittura, GPT per reasoning, DeepSeek per codice, Qwen per estrazione strutturata, Mistral per italiano fluente. Senza astrazione, dovete integrare 5 SDK diversi. Con astrazione, è un parametro nel routing.

L’errore tipico che vedo nei progetti AI enterprise

Per chiudere, vorrei raccontare il pattern di errore più frequente che vedo nei progetti AI enterprise che falliscono. Si svolge sempre nello stesso modo, in tre fasi.

Fase 1: prototipo veloce. Il team prodotto vuole muoversi rapidamente. Chiamano direttamente l’API OpenAI, fanno il POC in due settimane, lo presentano al management. Il management è entusiasta, dà luce verde a una versione di produzione. Decisione presa: usiamo OpenAI come fornitore principale.

Fase 2: produzione e accumulo. Nei 12-18 mesi successivi, il team costruisce features sopra features. System prompt sempre più sofisticati, function calling, RAG con Pinecone, agenti multi-step. Tutto su API OpenAI. Nessuno si pone il problema dell’astrazione perché funziona tutto bene.

Fase 3: il momento di verità. Arriva una di queste situazioni: i costi OpenAI superano i budget previsti, il management chiede di portare l’AI in casa per ragioni di sovranità o compliance, un competitor si vanta di prestazioni migliori con Claude e il management vuole switchare. A questo punto il team scopre che la migrazione costa 3-4 mesi di lavoro e mette a rischio il prodotto. Si rinvia. Si rinvia ancora. Poi qualcuno decide che è meglio non toccare niente, e l’azienda resta legata al provider scelto due anni prima, anche quando non è più la scelta migliore.

Quel pattern, per me, è la singola causa più frequente di stagnazione strategica nei progetti AI enterprise italiani. La soluzione non è tecnicamente difficile (un abstraction layer maturo si setta in due settimane). È una decisione architetturale da fare presto, prima che l’accumulo di lock-in la rende troppo costosa.

Tre azioni concrete per chi sta valutando ora

Per chi sta costruendo o ha appena messo in produzione un sistema AI enterprise, tre azioni che vale la pena valutare nei prossimi 30 giorni.

Audit del lock-in attuale. Mappare quali punti del vostro stack sono legati al provider AI specifico. System prompt, embeddings, function calling, vector DB, memoria, logging, expertise del team. Quantificare quanto tempo costerebbe oggi una migrazione totale a un provider diverso. Se la stima è oltre un mese di lavoro, avete un debito tecnico che vale la pena ridurre.

Introduzione progressiva dell’abstraction layer. Non serve un big-bang refactor. Si può introdurre un’astrazione progressivamente: cominciando dalle chat completions (l’80% del traffico tipico), poi embeddings, poi function calling. In 6-8 settimane è possibile arrivare a un’astrazione completa su un sistema esistente.

Test di portabilità periodici. Anche se non avete intenzione di cambiare provider oggi, fate un esercizio: ogni 6 mesi, provate a far girare una percentuale del traffico (5-10%) su un provider alternativo via l’abstraction layer. Misura due cose: la qualità delle risposte resta accettabile, e l’astrazione regge il routing. Se sì, siete davvero portabili. Se no, scoprite dove sono i punti deboli mentre i costi della migrazione sono ancora bassi.

Per chi vuole approfondire il setup di un’architettura AI sovrana basata su abstraction layer, ho scritto questa serie di articoli: GDPR e LLM, hardware locale, TCO on-premise, scelta del modello open-weight, AI Act checklist, installazione di LocalAI, cloud sovrano italiano. Insieme coprono lo stack completo. Per una conversazione specifica sul vostro contesto, c’è la pagina Advisory.

La domanda finale, quella che cambia il futuro architetturale del vostro sistema AI, è semplice. Se domani il provider che usate oggi raddoppiasse i prezzi, deprecasse il modello che vi serve, o cambiasse i termini commerciali in modo per voi inaccettabile, in quanto tempo sareste in grado di rispondere? Se la risposta è in mesi, avete un problema architetturale che vale la pena affrontare adesso, mentre la migrazione costa ancora poco.