Categoria: AI & GENAI

Intelligenza artificiale generativa, large language model, agentic AI e applicazioni dell’AI nei processi aziendali. In questa sezione raccolgo le mie analisi sui temi più rilevanti dell’AI applicata: cosa cambia davvero per le aziende italiane ed europee, dove vale la pena investire nei prossimi 12-24 mesi, quali sono i rischi sopravvalutati e quelli sottovalutati. Gli articoli coprono cinque filoni principali. Il primo è l’analisi dei modelli AI: Claude di Anthropic, ChatGPT di OpenAI, Gemini di Google, Mistral, modelli open-source. Non recensioni superficiali, ma riflessioni su cosa cambia per chi deve scegliere quale tecnologia adottare in azienda e su quali criteri valutare il fit con i propri processi. Il secondo filone è la strategia AI aziendale: come costruire una roadmap di adozione, dove l’AI genera ROI misurabile, come strutturare governance, change management e formazione. Temi che approfondisco anche nei progetti di advisory strategico con CEO, founder e leadership team di aziende medie e grandi. Il terzo è l’agentic AI: Claude Managed Agents, GPT Agents, Model Context Protocol (MCP), automazione di processi complessi via AI autonoma. Cosa funziona oggi in produzione, cosa è ancora demo, come progettare workflow human-AI che reggono in scala. Il quarto filone è il change management nell’era dell’AI: come cambiano i ruoli, le competenze richieste, le strutture organizzative quando l’intelligenza artificiale distribuisce il sapere nei nodi dell’organizzazione. Temi al centro del mio libro La mente adattiva e di articoli più recenti sul concetto di onlyness applicato alla leadership. Il quinto è la cultura dell’AI: cosa significa convivere con sistemi che generano testi, immagini, codice, decisioni. Implicazioni etiche, sociali, cognitive che vanno oltre il singolo caso d’uso aziendale. Se è la tua prima volta in questa sezione, ti consiglio di partire dagli articoli più recenti sulla leadership in era AI, o dai pezzi sui Claude Managed Agents e MCP che hanno generato più discussione. Per uno sguardo più strategico, c’è la pagina Advisory con i formati di collaborazione che propongo a chi vuole portare l’AI nei processi reali, e la sezione Pubblicazioni con i quattro libri che ho scritto su questi temi.

AI & GENAI, TECH & BUSINESS

Progettare il loop invece di scrivere il prompt successivo

Chiedi a Claude di aggiungere un pulsante di like e parte un loop agentico. Legge il codice, fa la modifica, lancia i test e ti restituisce qualcosa che crede funzioni. Poi tocca a te: apri la pagina, clicchi, guardi la console del browser, e scrivi il prompt successivo. Il collo di bottiglia sei tu, per come è fatto il ciclo: l’agente produce, l’umano controlla, un turno alla volta.

Delba de Oliveira e Michael Segner, del team di Claude Code, hanno messo per iscritto a fine giugno la definizione di loop agentico che usano internamente: «agents repeating cycles of work until a stop condition is met». Agenti che ripetono cicli di lavoro finché non scatta una condizione di stop. È una definizione povera di aggettivi e piena di conseguenze, perché tutto il peso si sposta su una domanda sola, chi scrive quella condizione.


Il ciclo di base: raccoglie contesto, agisce, verifica, e riparte finché la condizione di stop non è soddisfatta.

Quattro modi di far girare un agente

Il turn-based è il loop agentico che usiamo tutti senza chiamarlo così. Parte da un tuo prompt, Claude raccoglie il contesto, agisce, controlla il proprio lavoro e risponde, e si ferma quando giudica il compito chiuso oppure quando gli serve qualcosa che non ha. Quello che deleghi, se lo deleghi, è il controllo del risultato.

Il goal-based nasce quando un turno solo non basta. Con /goal dichiari che cosa significa fatto, e Claude continua a lavorare senza che tu debba rilanciarlo a ogni giro. Ogni volta che prova a fermarsi, un modello valutatore rilegge la conversazione e decide se la condizione regge, e se non regge lo rimanda al lavoro con una motivazione che diventa la guida del turno successivo. Qui deleghi la condizione di uscita, ed è la ragione per cui i criteri deterministici funzionano molto meglio delle formule generiche.

Il time-based serve al lavoro che torna, quello in cui il compito resta identico e cambiano solo gli ingressi: il riassunto dei messaggi del mattino, la pull request che riceve commenti di review e fa fallire la CI. Deleghi l’innesco.

Il proattivo è quello in cui davanti allo schermo non c’è nessuno. Un evento o una pianificazione fanno partire il lavoro, ogni task esce quando raggiunge il proprio obiettivo, la routine continua a girare finché non la spegni. Deleghi il prompt, cioè la parte che fino a ieri consideravamo il mestiere.

I comandi che Anthropic ha rilasciato

/goal imposta una condizione di completamento valida per la sessione, lunga fino a quattromila caratteri. A ogni fine turno un modello piccolo e veloce, Haiku per impostazione predefinita sull’API di Claude, restituisce uno di tre verdetti: soddisfatta, non ancora, impossibile. Il valutatore non esegue comandi e non legge file per conto suo, giudica soltanto quello che Claude ha già portato in conversazione, quindi la condizione va scritta come qualcosa che l’output può dimostrare. Dentro la condizione conviene mettere anche un tetto, «oppure fermati dopo venti turni», altrimenti il loop si allunga oltre quello che ti aspetti. Funziona anche in modalità non interattiva, con claude -p.

/loop rilancia lo stesso prompt a intervalli regolari e gira sul tuo computer, quindi si spegne quando spegni la macchina. /schedule sposta la stessa idea nel cloud e la trasforma in una routine, che continua a lavorare a portatile chiuso. Una routine può partire da una pianificazione oraria, giornaliera, feriale o settimanale, da una chiamata HTTP autenticata a un endpoint dedicato, oppure da un evento GitHub come l’apertura di una pull request o la pubblicazione di una release, con filtri su autore, titolo, branch, etichette. L’intervallo minimo è un’ora. Le routine sono disponibili sui piani a pagamento di Claude, si gestiscono da claude.ai/code/routines e hanno un tetto giornaliero di esecuzioni oltre al consumo ordinario dell’abbonamento.

Intorno a questi due comandi girano altri pezzi. La modalità auto approva le chiamate agli strumenti dentro un turno, e si combina bene con /goal, che invece toglie di mezzo la conferma tra un turno e l’altro. I dynamic workflows, in research preview, permettono a Claude di orchestrare sottoagenti in parallelo. Le skill descrivono i controlli da ripetere. Per chi non apre mai un terminale ci sono gli scheduled task di Cowork, che si configurano dall’interfaccia, girano da remoto anche a computer spento e usano i connettori e le skill già attive.

Il criterio d’uscita vale più del prompt

La qualità di un loop dipende dal sistema che gli sta intorno, e il pezzo che pesa di più è la verifica. Il consiglio di Anthropic è codificare in un file di skill i passaggi che oggi fai a mano, così che l’agente possa controllare il proprio lavoro dall’inizio alla fine invece di dichiararlo finito appena la modifica è andata a buon fine: avviare il server, aprire la pagina, cliccare il controllo nuovo, fare uno screenshot prima e dopo, guardare che in console non compaiano errori, misurare le metriche di performance. Più i controlli sono quantitativi, più l’autoverifica diventa semplice.

Nel mio flusso editoriale la condizione di uscita è un exit code. Uno script passa il testo al setaccio cercando i tic di scrittura che non voglio, e finché non esce zero il pezzo non si consegna. È un criterio grezzo, e misurabile, e chiude il loop in molti meno giri di qualunque descrizione a parole di che cosa sia un buon articolo.


Più il criterio d’uscita è misurabile, meno turni servono al loop per chiudersi da solo.

Due accorgimenti da rubare. Il primo è affidare la revisione a un secondo agente con contesto pulito, perché chi non ha seguito il ragionamento del primo è meno incline a confermarlo. Il secondo riguarda cosa fare quando un risultato non è all’altezza: correggere il singolo errore serve una volta sola, mentre spostare la correzione dentro la skill la rende valida per tutti i giri successivi. È la differenza tra un loop che migliora e uno che ti fa rimettere a posto la stessa cosa per la terza volta.

Sei loop da accendere questa settimana

La rassegna delle sette è il più facile da accendere: uno scheduled task che legge messaggi, posta e calendario delle ultime ventiquattro ore e consegna un brief prima che tu apra il computer. «Ogni mattina alle 7:00 riassumi Slack, email e calendario delle ultime 24 ore e scrivimi trecento parole con le tre cose che oggi richiedono una mia decisione».

Quando le richieste arrivano su un canale condiviso, la coda si accumula da sola e qualcuno passa la giornata a smistarla. Una routine oraria con un obiettivo esplicito la tiene bassa: «ogni ora controlla il canale delle richieste, e non fermarti finché ogni segnalazione trovata in questo giro non ha un responsabile, una priorità e una risposta».

C’è poi il documento che non esce finché non passa l’audit, il caso in cui il criterio esiste già da qualche parte e nessuno lo aveva mai dato in pasto all’agente: «l’articolo passa lo script di audit con exit code 0 e resta sopra le 1.400 parole, fermati dopo sei tentativi».

Anche il debito accumulato su un sito si può assegnare a un lunedì mattina: «ogni lunedì alle 6:00 controlla i post pubblicati nell’ultimo mese, segnala meta description mancanti, immagini senza testo alternativo e link interni rotti, e prepara le correzioni in bozza».

Sulle pull request funziona meglio l’intervallo, perché quello che cambia sta fuori dal tuo progetto e arriva quando arriva: /loop 10m controlla la mia PR, rispondi ai commenti di review, sistema la CI che fallisce.

L’ultimo parte da un evento invece che da un orario. La pipeline di deploy chiama via HTTP l’endpoint della routine appena il rilascio è in produzione, la routine esegue gli smoke test, cerca regressioni nei log e scrive go o no-go nel canale di release prima che la finestra si chiuda. Lo stesso schema regge sugli alert: il sistema di monitoraggio passa il corpo dell’allarme, l’agente correla lo stack trace con i commit recenti e apre una bozza di pull request con una proposta di correzione, così chi è di turno trova qualcosa su cui lavorare invece di un terminale vuoto.

Per scegliere quale accendere per primo, Anthropic propone un criterio pratico: guarda il lavoro che già fai, prendi un compito in cui sei tu a rallentare tutto, e chiediti quale pezzo puoi passare alla macchina, se sai scrivere il controllo di verifica, se l’obiettivo è già abbastanza chiaro da poter essere giudicato da un altro modello, oppure se il lavoro arriva comunque a scadenze regolari.

Quanto costa tenere acceso un loop

Un loop senza confini è un modo elegante di bruciare token. Il primo controllo è la scelta del pezzo giusto: un compito piccolo non ha bisogno di più agenti, e parecchio lavoro gira benissimo su modelli più economici, tenendo quello più capace per le decisioni di giudizio. Il secondo è la precisione del criterio di uscita, che deve essere specifico abbastanza da far arrivare Claude alla soluzione presto, senza però farlo fermare troppo presto.

Poi ci sono due regole che sembrano banali e non lo sono. Quando una parte del lavoro è deterministica, conviene che sia uno script a farla, perché eseguire uno script costa meno che ragionare ogni volta sugli stessi passaggi. E l’intervallo di una routine va tarato su quanto spesso cambia davvero la cosa che stai guardando, non su quanto ti piacerebbe essere aggiornato. Prima di lanciare un workflow su tutto il perimetro conviene provarlo su una fetta piccola, visto che l’orchestrazione dinamica può generare centinaia di agenti.

Per misurare c’è /usage, che scompone il consumo recente per skill, sottoagenti e connettori, /goal senza argomenti, che mostra turni e token spesi finora, e /workflows, da cui si vede quanto sta consumando ogni agente e si può fermarne uno al volo.

Una routine firma con la tua identità

Qui arriva la parte che in azienda pesa più del risparmio di tempo. Una routine gira come sessione autonoma: durante l’esecuzione non ci sono richieste di permesso, e Claude può usare tutti gli strumenti dei connettori inclusi, comprese le scritture. Quando crei una routine i connettori attivi vengono inclusi tutti per impostazione predefinita, e toglierli è un gesto che conviene fare subito.

Quello che la routine fa attraverso la tua identità appare come fatto da te. I commit e le pull request portano il tuo utente GitHub, i messaggi su Slack e i ticket su Linear passano dai tuoi account collegati. L’ambiente cloud definisce a quali domini la sessione può arrivare, e il testo che accompagna un’attivazione via API viene consegnato all’agente dentro un blocco marcato come dato non affidabile, così il prompt della routine deve dichiarare esplicitamente di volerlo usare prima che quel testo possa orientare il lavoro.

Sono dettagli di configurazione, e insieme disegnano una superficie di responsabilità nuova. Permesso revocabile è la formula che uso da tempo per questa condizione, in cui l’autonomia di un sistema è sempre concessa e sempre ritirabile. Con le routine la domanda operativa diventa chi ha aperto il permesso, quali strumenti ha lasciato dentro, e in quanto tempo qualcuno se ne accorge.

Il livello che stavamo saltando

Per due anni abbiamo lavorato quasi solo sul primo livello, la formulazione del singolo turno, e poi sul secondo, il contesto da mettere davanti al modello. Sopra c’è l’harness, il guscio che decide che cosa l’agente può toccare e con quali permessi. In mezzo sta il livello che stavamo saltando: quante volte l’agente ci riprova, e a quali condizioni ha il diritto di dire che ha finito.


Il loop sta sopra il contesto e sotto l’harness: un guasto si attribuisce al livello che lo ha prodotto.

Chi progetta il loop agentico decide dove finisce il lavoro della macchina e dove comincia la responsabilità di una persona. Nei prossimi mesi credo che nelle organizzazioni comparirà un ruolo che oggi non ha ancora un nome: qualcuno che scrive le condizioni di stop, le rivede quando cambia il contesto, e risponde di tutto quello che quelle condizioni lasciano passare.

AI & GENAI, DIGITAL CULTURE

Maledetto AI slop

Arrivo alla fine del secondo paragrafo e mi accorgo che sto ancora aspettando. Il testo è scritto bene, le transizioni sono al posto giusto, i paragrafi hanno tutti la stessa lunghezza cortese, non c’è un refuso, e non c’è una riga che qualcuno abbia voluto scrivere. Chiudo la pagina e dopo dieci secondi non saprei ricordarmene una parte né ripeterne i concetti.

In inglese la parola l’hanno trovata, ed è brutta apposta. Slop è la broda di scarti e avanzi che si versa ai maiali, riciclata sul modello di spam per indicare i testi prodotti in serie dai modelli. E AI slop si è attaccato subito perché descrive la consistenza prima del contenuto: qualcosa di uniforme, versato, senza pezzi riconoscibili e autentici dentro. Della metà che riguarda chi scrive, cioè della voce che si perde un aggettivo alla volta, ho già detto la mia. Qui mi interessa l’altra metà: chi legge, chi paga il conto e chi mette la firma sotto al pezzo.

Un testo scritto senza un giudizio

L’AI slop non si riconosce dagli errori, perché di errori spesso non ne ha. Anzi, se ci fossero degli errori forse sarebbe umano. Si riconosce dal fatto che, tolta la superficie, quella delle parole ben strutturate e delle frasi ben formattate, dentro non c’è nessun giudizio, nessuna idea che qualcuno abbia sentito come propria, e nessun punto in cui l’autore avrebbe potuto sbagliare.

Un testo scritto da qualcuno porta con sé i segni di quello che ha buttato via (le scelte di non dire cose, per capirci), e il segno più affidabile è l’obiezione rimasta dentro senza risposta, quella che l’autore non sapeva chiudere e non se l’è sentita di far sparire. Lo slop di obiezioni aperte non ne ha. Non ha rinunciato a niente, dice tutto il dicibile sull’argomento, e lascia chi legge esattamente dove l’ha preso.

Per questo supera i controlli di qualità: la leggibilità è alta e i fatti a volte sono pure giusti. Manca la ragione per cui quel testo esisteva.

Nessuno si sveglia la mattina con l’intenzione di produrre slop

Il modello fa esattamente quello per cui è costruito: la continuazione più probabile, poi limata per piacere a chi legge. Il risultato ha una forma precisa, simmetrica, chiusa bene, e quella forma è la media di tutto ciò che era già stato scritto sull’argomento. I tic che ormai riconosciamo tutti, il trattino lungo, le frasi che pesano tutte dodici parole, le triadi che suonano incisive, le chiusure che riassumono il paragrafo appena letto, sono l’impronta di quella media.

C’è però una causa che pesa più del modello, ed è l’incentivo di chi pubblica. Produrre un testo è passato da ore a secondi, la pressione a pubblicare è rimasta identica, anzi è cresciuta, perché il calendario editoriale, il posizionamento, la presenza sui canali chiedono volume e il volume adesso è gratis. Per secoli la quantità di testo è stata una misura indiretta della fatica di qualcuno, e quella misura ha smesso di funzionare in diciotto mesi.

Poi c’è l’ultimo anello: la catena che andava dall’autore al lettore aveva in mezzo qualcuno che leggeva prima. Un direttore, o anche solo il collega scocciato che ti diceva che non si capiva niente. Quella figura è saltata quasi ovunque, e il primo lettore di gran parte di quello che circola è il destinatario finale.

Scriverlo costa zero, leggerlo costa come prima

La lettura è ferma dov’era. Duecento parole al minuto scarse, un limite che nessun aggiornamento software sposta, e un’attenzione che rimane la risorsa più rigida che abbiamo.

L’economista George Akerlof, nel 1970, descrisse il mercato delle auto usate: quando il compratore non riesce a distinguere prima dell’acquisto un’auto buona da un bidone, offre a tutti un prezzo medio, i venditori onesti si ritirano perché quel prezzo non copre la qualità, e sul mercato sopravvivono i bidoni. Vinse un Nobel per aver spiegato come l’asimmetria informativa distrugga un mercato dall’interno.

Con i testi il prezzo è l’attenzione. Il lettore che si è preso tre fregature di fila abbassa l’offerta su tutti, comincia a scorrere invece di leggere, e apre ogni pagina con una domanda in sottofondo che riguarda chi l’ha scritta. Il sospetto diventa l’impostazione predefinita, e i primi a pagarlo sono i testi onesti, che adesso devono dimostrare di esserlo prima ancora di essere letti.

C’è un secondo giro, più lento e più preoccupante. I modelli imparano da ciò che trovano scritto in giro, e ciò che trovano scritto in giro è prodotto in quota crescente da altri modelli. Fotocopia di fotocopia: ogni passaggio perde le code della distribuzione, cioè le voci rare, gli usi strani, le formulazioni che nessun altro avrebbe scelto. Stiamo dando in pasto ai modelli la loro stessa broda.

L’AI slop dentro i documenti che decidono

Fuori dal feed la faccenda si fa seria. In azienda i testi non servono a intrattenere, servono a far prendere decisioni, e la forma tipica è la nota di quattro pagine che circola il giorno prima di un consiglio, quando nessuno ha più il tempo di verificarla.

Un documento generato ha la forma dell’analisi, con il linguaggio di chi i dati li ha guardati davvero e la cautela messa nei punti in cui serve cautela. Il rischio grosso non arriva dall’errore fattuale, che prima o poi qualcuno scopre, arriva dalla fluidità che copre l’assenza di ragionamento, perché un testo che scorre bene viene approvato più in fretta di uno che inciampa e obbliga a fermarsi.

E poi c’è la domanda che faccio sempre quando mi trovo davanti a un documento del genere: chi risponde di questa frase, se tra otto mesi si rivela sbagliata? Nei sistemi con più agenti che lavorano insieme la questione è la stessa, e l’ho già affrontata parlando di chi decide quando due agenti non sono d’accordo: il criterio che nessuno ha messo per iscritto finisce comunque dentro il processo, solo che nessuno l’ha deliberato.

Le organizzazioni che riempiono di AI slop la propria documentazione accumulano debito cognitivo. Producono più pagine di quante ne sappiano difendere, e il conto arriva quando qualcuno le contesta, di solito in una due diligence o davanti a un’autorità. Vale anche qui la regola del mercato dei bidoni, applicata all’interno: quando i lettori interni smettono di distinguere i documenti che contengono lavoro da quelli che contengono forma, smettono di leggerli sul serio, e la produzione documentale diventa un rito.

Superare l’audit e non dire niente

Ogni cosa che pubblico passa da uno script che conta i trattini lunghi, le triadi, le frasi tutte della stessa misura, le formule che fingono sincerità. Lo uso da mesi e ho imparato una cosa che all’inizio mi ha infastidito: serve meno di quanto pensassi.

Un testo può superare l’audit e continuare a essere slop. I tic sono l’impronta digitale, il reato è un altro. Togli i trattini, spezzi le simmetrie, allunghi due periodi e accorci gli altri, e ottieni un testo medio travestito da testo personale. È lavaggio, e se ne vede sempre di più, perché la caccia ai tic è diventata a sua volta un prompt.

L’unica verifica che non si automatizza è anche la più scomoda, e consiste nel chiedersi cosa si è tolto: quale frase, tra quelle che il modello aveva proposto e che suonavano bene, è stata buttata perché non ci credevo. Se la risposta è nessuna, quel testo è slop anche con lo script a zero, e il fatto che sia gradevole peggiora la situazione invece di migliorarla.

L’ordine in cui si fanno le cose

Lavoro con questi strumenti tutti i giorni e non ho nessuna intenzione di smettere, quindi la domanda pratica diventa dove metterli nella sequenza. La differenza tra un pezzo mio e uno slop sta quasi tutta lì, nell’ordine delle operazioni, molto più che nella quantità di AI che c’è dentro.

Prima la tesi. Non apro la chat per scoprire cosa penso di un argomento, ci arrivo con una frase che sono disposto a difendere, anche brutta, anche mal messa. Se quella frase manca, il modello riempirà il vuoto con la media di ciò che esiste, e la riconoscerò tardi.

Poi il modello come avversario. Gli chiedo dove ho torto e quale obiezione mi farebbe la persona più competente della stanza. Usato come ghostwriter produce slop, usato come sparring partner mi tira fuori obiezioni che da solo non mi sarei fatto, e quelle obiezioni cambiano il pezzo.

Delego volentieri la fatica meccanica, la ricerca, la verifica, il riordino. Tengo l’attrito nel punto in cui si decide cosa entra e cosa esce, perché è lì che si forma il giudizio, e un modello, di sua iniziativa, non toglie mai niente: aggiunge sempre. Scriviamo con le stesse parole con cui pensiamo, e la pelle digitale tra noi e le macchine si forma lì, molto prima che in qualsiasi interfaccia.

Alla fine metto il nome sotto. Prima di pubblicare mi chiedo se difenderei quel testo in una stanza con dieci persone che ne sanno più di me, e se la risposta è no lo riscrivo o lo butto. Non è un problema di stile, è un problema di responsabilità: lo slop è quello che resta sulla pagina quando nessuno se ne assume nessuna.

Per secoli un testo ben fatto costava tempo, e proprio per questo funzionava come segnale di competenza. Adesso costa niente e non segnala più niente, il che spiega perché tanti mestieri che si reggevano su quel segnale si sentano il pavimento cedere sotto.

Akerlof indicava anche la via d’uscita dal mercato dei bidoni, e non passava dalla capacità del compratore di riconoscere la merce buona: passava dalla garanzia, cioè da qualcuno che accetta di rispondere del prodotto anche dopo averlo venduto. Vale per le auto usate e vale per i testi. La cosa scarsa, da qui in avanti, sarà qualcuno disposto a mettere la faccia sotto una frase e a risponderne quando viene contestata. Le aziende che avranno tenuto in casa persone capaci di scrivere una pagina difendibile scopriranno di avere un vantaggio che non avevano messo a bilancio, e lo scopriranno nel momento peggiore, che è sempre quello in cui i vantaggi si contano.

AI & GENAI, TECH & BUSINESS

Chi decide quando due agenti AI non sono d’accordo

Al tavolo di un cliente, qualche settimana fa, la riunione si è fermata su una domanda che non era tecnica. Avevano due agenti AI quasi pronti, uno che istruisce le pratiche e uno che interroga i sistemi di rischio, e a un certo punto qualcuno ha chiesto cosa succede quando il secondo contraddice il primo. Il silenzio che è seguito non era imbarazzo. Quella regola non stava scritta da nessuna parte nemmeno per le persone che facevano lo stesso identico lavoro il giorno prima, e per quindici anni era bastato così, perché c’era un capo servizio che la teneva in testa e la applicava caso per caso, con criteri che nessuno gli aveva mai chiesto di dettare.

Da un paio d’anni ripeto una cosa che sembra ovvia e nella pratica non lo è mai: mettere più modelli linguistici dentro lo stesso spazio computazionale non produce da sé né i benefici né i rischi. Li produce il modello di coordinamento che gli diamo, e quel modello va scritto, in forma esplicita, con protocolli, criteri, autorità. Attendersi che il valore emerga da solo da un collettivo di macchine è la versione tecnologica della speranza che un’orchestra suoni bene perché i musicisti sono bravi.

La parte scomoda arriva subito dopo: progettare un modello di coordinamento presuppone che da qualche parte, in azienda, ce ne sia già uno leggibile da cui partire, e quasi nessuna organizzazione ce l’ha.

Il collettivo di agenti AI eredita quello che trova

Un sistema di agenti AI messo in produzione dentro un’azienda non arriva su una tabula rasa, si innesta sul modo in cui quell’azienda coordina già le proprie persone. Dove quel modo è esplicito, e capita nelle filiere regolate, nella logistica, in parte della sanità, gli agenti trovano un substrato: chi ha l’ultima parola su cosa, quale eccezione va scalata a chi, entro quanto, con quale traccia. Il collettivo computazionale eredita una grammatica e ci si appoggia.

Dove invece il coordinamento vive nella testa di sette persone anziane e in una manciata di chat, non c’è niente da ereditare. E quel vuoto lo riempie chi integra, il martedì pomeriggio, con la scelta di implementazione che gli sembra più ragionevole in quel momento. È così che il modello di coordinamento di un’impresa finisce dentro un file di orchestrazione senza che nessuno l’abbia mai deliberato, e senza che nessuno se ne accorga finché non arriva la prima contestazione seria.

Avevo affrontato la stessa questione dal lato del significato quando scrivevo di ontologia come infrastruttura invisibile: lì il problema era che un agente non sa cosa vuol dire “cliente attivo” se l’azienda non l’ha mai definito. Qui il problema è gemello e sta un piano sopra, perché anche sapendo cosa significa un ordine bisogna ancora stabilire chi può agire su di esso, e chi può fermare l’altro.

Quando il protocollo fra due uffici non esiste

Di questi progetti il pezzo più utile matura molto prima della messa in produzione, e non ha niente di tecnologico. Provare a scrivere il protocollo di coordinamento fra due agenti AI costringe a scoprire che non esisteva nemmeno fra due uffici.

Nelle sessioni di assessment che conduco succede quasi sempre lo stesso movimento: si parte con la domanda su quale modello usare, si finisce a ricostruire chi ha l’autorità di annullare una decisione presa da qualcun altro, e quanto vale quell’autorità dopo che la decisione è già stata comunicata al cliente. Sono domande di governance che l’azienda si porta dietro irrisolte da anni, tollerabili finché a coordinare erano persone che si conoscono e si telefonano, insostenibili nel momento in cui il coordinamento passa a un collettivo di agenti AI che esegue e basta.

Su questo tema ho una posizione che ripeto da un po’: la vera unità di misura di un agente non è quello che sa fare, è il permesso revocabile sotto cui lo fa. La maturità di un’organizzazione cognitiva si misura sulla capacità di dire, per ciascun agente in circolazione, chi gliel’ha concesso, fino a quando, e con quale gesto glielo si toglie.

La gavetta era il posto dove passava il criterio

C’è una trasformazione che vedo sottovalutata quasi ovunque, e riguarda l’apprendimento. Questi sistemi si sono messi in mezzo fra le persone e la conoscenza di come si fanno le cose, e il primo posto dove si sono infilati sono i compiti di gavetta, quelli che nelle organizzazioni funzionavano da palestra per chi comincia. Una generazione intera rischia di perdere le occasioni di imparare che tutte le precedenti hanno avuto.

Dal mio tavolo si vede bene una cosa in più. La gavetta non serviva solo a formare chi la faceva. Era il momento in cui il criterio implicito veniva tirato fuori dalla testa del senior e messo in parole, malamente, di corsa, davanti a una pratica sbagliata da rifare, e in quell’attrito il criterio si riformulava ogni volta un po’ diverso e un po’ più preciso. Toglila di mezzo e non perdi soltanto il canale di trasmissione verso i giovani, perdi la sola occasione in cui l’azienda si spiegava a voce alta come funziona.

È il debito cognitivo nella sua forma meno visibile: non si accumula quando deleghiamo l’esecuzione, si accumula quando deleghiamo l’occasione di dover spiegare. Sulla superficie di contatto fra noi e le macchine si decide ogni giorno cosa passa e cosa no, e continuo a pensare che la parte da tenere di qua sia proprio quella, il momento in cui qualcuno è costretto a dire perché.

Governare uno strumento, non attendere un’entità

Nelle conversazioni con i board torna spesso l’idea, che si associa di solito a Nick Bostrom, dell’intelligenza artificiale come ultima invenzione che l’umanità dovrà fare, quella che poi risolverà i problemi troppo grandi per noi. È una formula che semplifica parecchio, e soprattutto colloca l’AI in una zona fuori portata, dove le decisioni le prende lei e a noi tocca aspettare l’esito.

Trovo che la cornice messianica, in azienda, faccia un danno preciso e poco spettacolare. Se l’AI è un destino, la cosa sensata da fare è aspettare, magari fare un pilota per dire che ci si sta muovendo, e rimandare. Se invece è uno strumento, la cosa sensata da fare è noiosa e comincia lunedì: scrivere il protocollo, assegnare le autorità, decidere dove gira il calcolo e con quali termini, verificare di poterli revocare. La narrazione dell’entità super intelligente è comoda perché sposta la responsabilità dal consiglio di amministrazione a un futuro indeterminato.

Della sovranità digitale ho parlato spesso come di una questione di infrastruttura, e lo è, ma la sua metà meno raccontata sta qui: sovrano è chi ha scritto le regole con cui i propri agenti AI si parlano e può cambiarle senza chiedere il permesso a un fornitore, molto più di chi si limita a ospitarli dentro il proprio perimetro.

Chi scrive il protocollo

La domanda più fastidiosa arriva alla fine, ed è chi materialmente questo lavoro lo fa. Il vendor porta un default ragionevole, calibrato su mille clienti diversi dal tuo, e non può fare altrimenti. L’integratore chiede le regole all’azienda e si vede consegnare un documento di processo del 2019 mai più aggiornato. All’IT da solo non si può lasciare, perché le regole di coordinamento fra agenti AI sono decisioni di business travestite da configurazione.

Nelle poche organizzazioni dove ho visto funzionare, il protocollo l’hanno scritto le persone che il lavoro lo fanno, sedute in una stanza per settimane, con qualcuno che faceva domande scomode e trascriveva. Costa parecchio e non produce nessuna demo da mostrare in comitato. Ed è l’unica parte del progetto che l’azienda si tiene anche se cambia modello, fornitore e architettura tre volte in cinque anni.

Se davvero l’era agentica ci obbliga a mettere per iscritto come coordiniamo il lavoro, allora l’effetto più duraturo dell’AI in azienda potrebbe non avere niente a che fare con le macchine, e riguardare il fatto che per la prima volta molte imprese saranno costrette a leggere ad alta voce come funzionano davvero. Vediamo quante reggono la lettura.

AI & GENAI, TECH & BUSINESS

Chi delega all’AI il proprio lavoro

Il 24 agosto è comparso su arXiv il primo tentativo serio di misurare la delega di lavoro all’AI dal lato di chi la compie: 53.000 specifiche di skill prese dal marketplace di Manus, incrociate con circa 18.000 descrizioni di mansione dell’O*NET americano, per ricavarne quella che gli autori chiamano esposizione delegata. La domanda che si sono posti è diversa da quella su cui abbiamo costruito due anni di grafici, perché invece di stimare quanto una professione potrebbe essere svolta da un modello hanno contato quanti gesti chi quel mestiere lo fa davvero abbia già scritto dentro una routine automatica, e lasciato andare.

Sembra una sfumatura, e sposta quasi per intero l’elenco di chi dovrebbe preoccuparsi.

L’esposizione delegata come misura

Le mappe dell’esposizione all’AI che circolano dal 2023 misurano una capacità teorica, e lo fanno con un metodo ragionevole: si prende la descrizione di un compito, si valuta se un modello saprebbe eseguirlo, si aggrega per professione. Il risultato è una fotografia di quello che potrebbe accadere, costruita da chi guarda il lavoro da fuori.

Il marketplace di Manus è un’altra cosa. È un posto dove le persone pubblicano le configurazioni che hanno costruito per farsi fare il lavoro, e ogni skill caricata è un pezzo di mestiere che qualcuno ha ritenuto abbastanza stabile da poterlo descrivere una volta sola e riusarlo. Chi la carica non sta rispondendo a un questionario, sta risolvendo un problema che ha. Gli autori hanno preso quelle configurazioni, le hanno rappresentate in uno spazio semantico, e hanno misurato quanto le mansioni di ciascuna professione somiglino alle routine che i praticanti si sono già costruiti.

Quello che ne esce assomiglia molto più a un registro di quello che è già successo che a una previsione su quello che accadrà.

Dal potenziale al gesto registrato

Il primo risultato che gli autori mettono in fila è che le professioni dove la delega si concentra sono nettamente diverse da quelle che i framework pre-AI indicavano come più a rischio. Il secondo è che l’indice della delega segue più da vicino quello che l’AI saprebbe fare rispetto a quello che i lavoratori ne fanno oggi, il che vuol dire che c’è uno spazio aperto tra il possibile e l’adottato, e che quello spazio non si chiude da solo.

Il terzo è quello che mi ha tenuto sveglio. La delega sale verso il centro della distribuzione salariale e al livello di laurea triennale, poi scende ai due estremi. Scende in basso, dove il lavoro è manuale o troppo variabile per essere specificato in anticipo, e questo era prevedibile. Scende anche in alto, dove ci sono le professioni che tutti indicavano come le prime a essere riscritte, e questo non lo era.

La disponibilità tecnica, scrivono gli autori, spiega gran parte della variazione ma non il deficit tra le occupazioni più istruite. Qualcosa lì trattiene.

Dove la delega si ferma

Gli autori lasciano due ipotesi aperte, senza sceglierne una: lavoro che resiste alla specificazione anticipata, oppure discrezionalità professionale sul ritmo con cui il proprio mestiere viene codificato.

La prima è un limite tecnico, e i limiti tecnici hanno la brutta abitudine di cadere. Se un avvocato senior non delega perché la sua parte di lavoro non si lascia scrivere in una specifica, allora è questione di tempo, di finestre di contesto più lunghe, di modelli che tollerano meglio l’ambiguità di un incarico mal posto. La seconda ipotesi descrive invece una posizione, presa e tenuta, e implica che ci sia una categoria di persone che ha capito che scrivere il proprio criterio dentro una configurazione riusabile equivale a consegnarlo, e che ha deciso quanto e quando.

In Pelle Digitale avevo provato a descrivere la superficie di contatto tra noi e le macchine come il punto in cui si decide cosa passa e cosa resta, e mi rendo conto adesso che l’avevo pensata come una scelta individuale e istantanea, mentre qui la vedo funzionare come una scelta di categoria, lenta, forse nemmeno del tutto consapevole.

Il criterio che si scrive una volta sola

A luglio avevo scritto che il gemello cognitivo lo addestri tu, e l’argomento era che correggendo il modello gli trasferisci il criterio che ci hai messo quindici anni a costruire, mentre lui lo esporta a chiunque e tu intanto ti disalleni. Quel pezzo l’avevo scritto sulla correzione, che è un gesto quotidiano e distratto. La skill caricata su un marketplace è la stessa cosa fatta con intenzione, messa per iscritto, versionata, e resa disponibile a un numero indefinito di persone che non hanno fatto il percorso per arrivarci.

Chi delega in questo modo sta facendo la cosa più razionale del mondo dal punto di vista della propria produttività questa settimana. Sta anche pubblicando la parte trasferibile del proprio mestiere, gratis, in un posto dove viene indicizzata.

Le 53.000 skill che i ricercatori hanno analizzato sono, viste da questa angolazione, il più grande esercizio collettivo di documentazione del lavoro qualificato mai fatto, e nessuno lo sta chiamando così.

Chi si sottrae, e per quanto

Resta la domanda su cosa fare di questa informazione, e non ho una risposta pulita.

Da un lato la riluttanza delle professioni più istruite è difendibile e la capisco: c’è un valore reale nel non rendere esplicito tutto quello che sai, e chi consiglia le aziende su questi temi lo tocca con mano ogni volta che un cliente chiede il documento invece della conversazione. Dall’altro lato la stessa riluttanza somiglia molto a quella delle categorie che negli anni Novanta si sono difese dal digitale non digitalizzandosi, e sappiamo tutti come è finita quella storia.

Su questo avevo già toccato il tema della riconfigurazione delle competenze partendo dalla scuola, e mi accorgo che avevo trattato la questione come un problema di formazione delle nuove generazioni, quando questi dati la spostano su chi il mestiere ce l’ha già.

C’è una terza possibilità che il paper non nomina e che a me sembra la più probabile, ed è che le professioni in alto non stiano scegliendo affatto, ma semplicemente non abbiano ancora incontrato lo strumento nella forma in cui lo userebbero, perché i marketplace di skill sono costruiti da sviluppatori per sviluppatori e un notaio o un primario non ci passa. Se è così, il dato che oggi leggiamo come discrezionalità professionale è solo un ritardo di distribuzione, e la delega si riempirà dall’alto nei prossimi diciotto mesi.

Gli autori chiudono dicendo che distinguere tra le due ipotesi richiederà misurazioni ripetute nel tempo. Hanno ragione, e vale la pena rifare questo conto tra sei mesi, perché sarà la prima volta che potremo osservare una categoria professionale decidere in diretta quanto di sé mettere per iscritto.

Il paper è Who Delegates to AI? Evidence from 53,000 Agent Configurations, pubblicato su arXiv il 24 agosto 2026.

AI & GENAI, TECH & BUSINESS

Il permesso, non solo il significato: dove finisce l’ontologia e comincia l’agente

Il 16 agosto Fanghua Yu ha pubblicato su Medium una mappa dell’evoluzione dell’ontologia che mi ha tenuto incollato allo schermo più a lungo di quanto i suoi dodici minuti dichiarati di lettura lascino immaginare. La tesi è semplice da enunciare, meno da digerire: un’ontologia non serve più a un solo tipo di sistema, e la definizione che bastava a un reasoner logico negli anni Novanta non è la stessa che serve oggi a un agente chiamato ad autorizzare un rimborso.

Di cosa sia un’ontologia, e di chi debba possederne il significato dentro un’azienda, ho già scritto su ontologie e grafi di conoscenza e su governare il significato. Quella domanda resta in piedi, e qui non la riapro. Quello che il pezzo di Yu mette a fuoco, e che i due articoli precedenti lasciano fuori campo, è cosa succede quando il significato smette di dover reggere una query e comincia a dover reggere un’azione autonoma. Con conseguenze che, a leggerle bene, portano dritte al concetto che uso per definire i limiti operativi di un agente: il permesso revocabile.

Il grafo impone la sua logica

Yu parte da un’osservazione che in trent’anni di ontologia formale nessuno aveva mai dovuto affrontare seriamente: nel momento in cui l’ontologia diventa lo schema che regge un grafo di conoscenza operativo, la domanda smette di essere solo “qual è la rappresentazione più fedele del dominio” e comincia a essere anche “quale struttura del grafo serve davvero alle applicazioni che ci devono girare sopra”.

L’esempio che porta è chirurgico. Rappresentare un acquisto come Cliente → ha piazzato → Ordine → contiene → Riga d'ordine → si riferisce a → Prodotto preserva tutta la struttura transazionale, quantità, prezzi, date. Un motore di raccomandazione, però, ha bisogno molto più spesso di un salto diretto: Cliente → ha acquistato → Prodotto. Quella relazione si può derivare dal percorso lungo, e da un punto di vista puramente formale materializzarla sembra ridondante. Dal punto di vista di chi deve rispondere in pochi millisecondi a “cosa comprano insieme a questa fotocamera”, è tutt’altro che superfluo.

Stesso dato, due priorità diverse: la fedeltà semantica conta i salti, il traversal operativo li taglia.

Il knowledge graph, scrive Yu, trasforma l’ontologia da modello del significato ad architettura di navigazione. E qui l’idea di un’unica ontologia “migliore in assoluto” comincia a scricchiolare, perché un modello semanticamente preciso introduce astrazioni e percorsi lunghi che aiutano il ragionamento ma appesantiscono le query, mentre un grafo ottimizzato per le prestazioni appiattisce distinzioni e duplica relazioni derivate per convenienza operativa. Non è un dettaglio da architetti di dati: è la prima cucitura visibile tra due mestieri che fino a ieri si pensavano identici.

Dal significato alla decisione

Il passaggio dove mi fermo di più, per me, comincia dove Yu smette di parlare di ragionamento semantico e comincia a parlare di decisione. L’ontologia, scrive, ha sempre avuto una capacità di inferenza, con l’OWL un reasoner deriva da Smartphone ⊆ Prodotto Elettronico e Prodotto Elettronico ⊆ Prodotto che Smartphone ⊆ Prodotto, pura logica di classe. Ma un sistema aziendale oggi deve rispondere a domande più larghe: dato quello che sappiamo, quale logica si applica, perché è successo, cosa potrebbe succedere, cosa dovremmo fare.

Dal significato alla decisione: quattro strati con compiti diversi, non uno che li assorbe tutti.

Yu propone una separazione che trovo più utile di qualunque tentativo di far fare tutto all’ontologia da sola. L’ontologia definisce cosa significa “cliente premium” o “prodotto ingombrante”, e resta relativamente stabile nel tempo. Le regole applicano quel significato alla logica del momento: se il cliente è premium, l’ordine supera i cento euro, la destinazione è servita e non ci sono prodotti ingombranti, allora si offre la consegna espressa gratuita. I modelli causali rappresentano ipotesi su cause ed effetti, non correlazioni: se il tasso di reso aumenta e la causa è la qualità di un fornitore, cambiare fornitore dovrebbe abbassarlo, ammesso che l’ipotesi regga alla prova. I modelli decisionali, infine, combinano prove e alternative per stabilire quale azione prendere.

La distinzione conta perché smette di chiedere all’ontologia di fare un lavoro che non le compete. Un’azienda italiana che lavora su una filiera manifatturiera lo sa bene quando vede aumentare i resi su una linea di prodotto: il grafo di conoscenza può mostrare la correlazione con un fornitore, ma solo un modello causale, testato e falsificabile, può dire se cambiare quel fornitore abbasserebbe davvero il tasso di reso o se la correlazione nasconde una terza variabile, magari il periodo dell’anno o il canale di vendita. Confondere i due piani è il modo più rapido per prendere decisioni sbagliate con sicurezza matematica.

Il permesso, non solo il significato

Ed eccoci al punto che, letto da chi lavora tutti i giorni con architetture agentiche, cambia registro rispetto al resto del pezzo. Un sistema tradizionale, anche generativo, legge, recupera, riassume, spiega. Un agente interpreta per agire. La differenza non è cosmetica.

Prendi una richiesta banale: “le cuffie che ho comprato la settimana scorsa sono difettose, sostituiscile con il modello nuovo”. Un agente che la esegue deve trovare l’ordine, identificare l’articolo, capire quale politica di reso si applica, verificare la disponibilità del ricambio, calcolare l’eventuale differenza di prezzo, creare l’ordine sostitutivo, generare l’etichetta di reso, emettere o richiedere un rimborso. A quel punto un fraintendimento sul significato di “cliente” o di “reso” non è più un problema di qualità dell’informazione. È un’azione sbagliata, con soldi e merce che si muovono davvero.

Yu chiama questo passaggio “operational semantic contract”, un contratto semantico operativo che lega concetti, relazioni, dati autorevoli, capacità disponibili, precondizioni, policy, evidenze richieste ed effetti attesi. È un vocabolario tecnico corretto. Preferisco però nominarlo con una parola che uso da tempo per la stessa idea, perché la rende immediatamente operativa in una conversazione con un board: permesso revocabile.

Il permesso non è un interruttore acceso o spento. È una funzione delle precondizioni, delle evidenze raccolte e della reversibilità dell’azione.

Un agente che sa cos’è un ordine ma non sa se è autorizzato a rimborsarlo conosce metà della storia. Le precondizioni gli dicono cosa deve essere vero prima che l’azione sia valida. Le policy gli dicono cosa può fare, non solo cosa sa fare, ed è una distinzione che nell’harness engineering, di cui ho scritto qui, diventa architettura concreta, non principio astratto. Le evidenze gli dicono quali prove raccogliere prima di premere il grilletto. Gli effetti gli dicono cosa cambia davvero, in quale sistema, se l’azione riesce. E la reversibilità decide quanto in alto deve stare l’asticella dell’autorizzazione: un’azione che si può disfare con un clic merita meno attrito di una che non si può disfare affatto.

Questo è il cuore del permesso revocabile applicato alla semantica: non basta che l’agente capisca cosa significa “ordine” o “rimborso” nel vocabolario dell’azienda. Deve sapere, prima di agire, se quel permesso specifico è ancora valido in quel momento, con quelle evidenze, per quella azione, e se può essere ritirato nel momento in cui qualcosa cambia. Un’ontologia che descrive solo cosa esiste, senza descrivere cosa un agente è autorizzato a fare con ciò che esiste, prepara il terreno a errori che nessun modello linguistico, per quanto capace, può correggere da solo.

Quando capire male diventa agire male

Yu arriva a una conclusione che condivido fino in fondo: quando un sistema si limita a leggere e spiegare, una semantica confusa produce al massimo una risposta confusa, ma quando un sistema agisce da solo, la stessa confusione si traduce in una decisione presa male e in un’azione reale, con soldi o merce che si muovono sulla base di un errore. Questo salto, da capire male a fare male, è la ragione per cui la modellazione semantica smette di essere un esercizio da specialisti isolati e diventa una competenza condivisa tra chi disegna i grafi, chi costruisce i modelli decisionali, chi progetta gli harness degli agenti e chi conosce il dominio dall’interno.

Non credo che il futuro sia un’unica ontologia perfetta capace di servire reasoner, grafi, motori decisionali e agenti con la stessa struttura. Credo, e qui la lettura di Yu mi conferma più che convincermi, che il lavoro sia costruire un’architettura semantica coerente, dove ontologie, grafi, regole, modelli causali e contratti operativi lavorano insieme senza pretendere che uno solo di questi livelli assorba il compito degli altri. E dove, ogni volta che un agente riceve la possibilità di agire, quella possibilità porti con sé la domanda che conta più di ogni definizione: chi può revocarla, e in base a cosa.

Spunto da The Evolution of Ontology: From Formal Semantics to Knowledge Graphs, Decisions and AI Agents di Fanghua (Joshua) Yu, pubblicato su Medium il 16 agosto 2026.

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

Il gemello cognitivo lo addestri tu

Alla terza volta esce giusta. L’hai corretto due volte, gli hai detto che quel cliente vuole una cosa e non un’altra, che in quel contesto non si apre mai dal prezzo, che una proposta senza un certo paragrafo non regge. Al terzo tentativo la risposta è esattamente quella che avresti scritto tu, e ti senti efficiente. In quell’istante qualcosa è passato da te al modello, e non era la risposta.

Quello che è passato è la correzione, il motivo per cui hai scartato le prime due, il gusto con cui hai riconosciuto quella buona, la riga che con un cliente non superi. Ci hai messo quindici anni a costruirla, l’hai consegnata in tre scambi.

Il mestiere passa nella correzione

Il modello non impara dalla tua risposta giusta, impara dai tuoi no. La distanza tra quello che ha prodotto e quello che gli hai fatto riscrivere è il segnale più prezioso che gli puoi dare, perché è lì che vive il giudizio, e il giudizio è la parte di te che non trovi scritta da nessuna parte, quella che negli anni ha smesso di essere una regola ed è diventata un istinto.

Sui gemelli digitali ho scritto altrove, pensando ad avatar e identità sintetiche. Questo gemello è più intimo: riproduce un criterio. Chiamiamolo gemello cognitivo. Il modello pubblico ne costruisce uno del tuo modo di decidere a partire dall’attrito, dalle volte in cui gli dici che ha sbagliato e soprattutto perché. A pesare è la sequenza di scelte che ti ha portato a quel documento e non a un altro, la cosa che ti chiede di rendere esplicita a ogni passaggio. I documenti in sé li ha già visti a milioni.

Un clone che non dimentica niente

Un collaboratore giovane impara guardandoti, poi dimentica qualcosa, è uno solo, e in qualche modo ti deve qualcosa: lo stipendio, la riconoscenza, gli anni che gli stai regalando. Il modello non dimentica niente e si copia all’infinito, senza doverti nulla. Nel momento in cui la tua correzione risolve un problema che hanno in milioni, in milioni ricevono il tuo modo di farlo senza sapere che è tuo, e senza che a te torni indietro niente. Un tempo il tuo modo di trattare quel cliente valeva perché lo avevi solo tu, e chi lo voleva veniva da te. Adesso lo stesso modo, una volta entrato nel modello, esce dal rubinetto per chiunque digiti la domanda giusta, allo stesso prezzo dell’abbonamento.

La reciprocità che regge l’apprendistato umano qui salta. È il punto dove di solito il ragionamento si ferma, con un senso di furto e un’aria da resa.

Mentre lo istruisci, ti disalleni

C’è una metà che quasi nessuno dice. Lo stesso gesto che manda fuori il tuo metodo lo consuma dentro. Smetti di scrivere la proposta e correggi quella che ha scritto lui, smetti di tenere in mano il criterio e ti riduci a sorvegliarlo, e ogni volta che deleghi la parte difficile perché tanto poi la sistemi, quella parte in te si assottiglia di un grado.

Tra cinque anni la macchina ha il tuo modo di fare e tu hai perso il tono muscolare per rifarlo senza. Il gemello cognitivo si affina mentre l’originale si spegne. Non è un furto, è un’atrofia. Di questo assottigliamento, del debito cognitivo che si accumula un riassunto accettato alla volta, ho scritto pensando alla metacognizione, all’esercizio di guardare come si pensa proprio mentre si usa il modello. Il segnale è facile da riconoscere: quando ti accorgi che davanti a un foglio bianco, con il modello chiuso, non partiresti più con la sicurezza che avevi due anni fa.

Trattenere tutto è una prigione

La risposta istintiva a tutto questo è nascondere. Tenersi il metodo, non darlo in pasto, lavorare a fari spenti. Strada chiusa, per due motivi. Il primo è che il modello rende peggio esattamente dove ti serve di più, quindi o affami lo strumento o nutri il gemello, e nel mezzo non c’è granché da abitare. Il secondo è più scomodo: l’accumulo come difesa è a sua volta una trappola, i quindici anni di sapere implicito che ti proteggono sono anche quindici anni che non riesci a scalare, a trasferire, a lasciare andare senza sentirti scoperto. È la ragione per cui certi professionisti bravissimi restano piccoli a vita: tutto passa dalle loro mani perché il valore è nelle loro mani, e le mani sono due.

Custodire tutto quello che sai è una prigione con una bella vista. Che prendano è dato, avviene comunque. Quello su cui hai voce sono le condizioni in cui avviene la presa.

La domanda è dove gira il calcolo

Quelle condizioni si giocano su una parola che suona burocratica e invece è molto concreta: giurisdizione. La domanda utile riguarda dove avviene il calcolo, con quali termini, e se quei termini puoi revocarli. Il contenuto che riveli pesa meno del luogo in cui lo riveli.

Sull’accesso ai modelli di frontiera l’ho già chiamato permesso più che proprietà, guardando a un governo capace di spegnere un modello dall’oggi al domani. La stessa logica vale un piano più in basso, sul tuo mestiere. Un’impresa cognitiva che gira sull’infrastruttura di un altro è cognitiva solo nel nome, affitta la stanza in cui si conia la sua stessa intelligenza, e paga l’affitto in giudizio. Un affitto che sale da solo, perché più il modello diventa capace più la tua operatività dipende da lui, e la dipendenza non è mai un buon posto da cui trattare le condizioni.

La sovranità digitale riguarda il contenitore, non l’ansia sul contenuto. Far girare il modello dove le regole le metti tu è una forma di questo, però il principio viene prima dello strumento: chi decide la giurisdizione del calcolo decide anche chi, dentro l’organizzazione, può ancora dire di no.

Il gemello cognitivo lo costruiranno comunque, quella parte non è in discussione. Quello che decidi tu è se la stanza dove lo costruiscono è tua o presa in affitto, e lo decidi adesso, mentre il metodo è ancora tutto dentro di te e non ancora tutto dentro la macchina. Tra qualche mese la proporzione si sposta, e si sposta da sola.

AI & GENAI, TECH & BUSINESS

Baseten a 13 miliardi e il paradosso dell’inferenza a basso costo

Il 18 giugno il Wall Street Journal ha scritto che Baseten sta chiudendo un round da 1,5 miliardi di dollari, con una valutazione che arriva fino a 13. Quattro giorni dopo l’azienda lo ha confermato: Series F, guidato da Altimeter, Conviction e Spark Capital. A gennaio la stessa Baseten valeva 5 miliardi, a settembre 2025 ne valeva poco più di due. Sei volte tanto in nove mesi, per una società che non costruisce modelli e non vende intelligenza propria, ma si occupa di farli girare bene una volta che qualcun altro li ha addestrati.

Ecco quello che mi ha fermato, e non è la cifra. Il capitale si sta spostando dalla parte spettacolare dell’AI, l’addestramento dei modelli, a quella operativa, l’inferenza: il lavoro ripetitivo e poco fotogenico di rispondere, milioni di volte al giorno, a chi fa una domanda. La scommessa di Baseten è che lì, sul costo di quel lavoro, ci sia il margine. La domanda che mi porto dietro è un’altra: una valutazione da 13 miliardi su un’infrastruttura che vende risparmio è il segno che il mercato sta maturando, o l’ennesima curva troppo ripida di una corsa all’oro?

L’inferenza è il livello meno glamour dello stack

Nessuno apre una demo vantandosi della latenza. L’addestramento ha preso quasi tutta l’attenzione degli ultimi anni perché era spettacolare, cluster enormi, GPU introvabili, miliardi bruciati per tirare su un modello più grande del precedente. Poi il modello esce, arriva il primo cliente vero, e la bolletta comincia a contare. L’inferenza è quel momento lì, quando il modello smette di essere una promessa e deve produrre una risposta utile, in fretta, a un costo che regga. È lo strato in cui l’intelligenza tocca davvero la persona, ed è lo stesso strato in cui un’azienda scopre se i conti tornano. In Pelle Digitale ho provato a raccontare proprio questa frontiera, la pellicola sottile dove la tecnologia diventa esperienza per chi la usa. Baseten vive lì, prende modelli, spesso open source, e li serve su una rete multi-cloud che oggi processa più di un miliardo di chiamate al giorno, distribuite su 87 cluster e 18 cloud diversi.

Da 2,15 a 13 miliardi in nove mesi

La cadenza degli aumenti è da capogiro. Series D a settembre 2025, valutazione 2,15 miliardi. Series E a gennaio, 5 miliardi, con dentro anche Nvidia. A maggio si parlava già di un round vicino al miliardo a una pre-money di 11. A giugno il round si gonfia a 1,5 miliardi fino a 13. Il fatturato segue una traiettoria altrettanto verticale, dal run-rate annualizzato di circa 200 milioni a 600 nell’arco di un trimestre, una crescita che molti raccontano come ventiplicata anno su anno. Tra gli investitori storici ci sono Greylock, IVP, CapitalG e la stessa Nvidia, che a gennaio aveva messo 150 milioni. Resta che a 13 miliardi parliamo di un multiplo sui ricavi vicino a 22 volte, e un multiplo del genere racconta molto più le aspettative sul futuro che i conti di oggi.

Il prezzo per task conta più del prezzo per token

La tesi di chi mette i soldi è abbastanza diretta. I modelli open source sono diventati buoni abbastanza da rendere superfluo, per molti casi d’uso, pagare il sovrapprezzo di un modello proprietario. Alcuni clienti di Baseten, da Cursor a Mercor a OpenEvidence, dichiarano di spendere circa un terzo di quanto costerebbe loro un’API chiusa. Se quel dato regge, l’unità della competizione cambia: non è più il modello migliore a fare la differenza, è la capacità di consegnarlo veloce e a basso costo. Ne avevo scritto la settimana scorsa a proposito della guerra dei prezzi dell’AI certificata dal Wall Street Journal, dove i volumi corrono verso il basso costo mentre la spesa resta alla frontiera. Baseten è l’altra faccia di quella dinamica, il venditore di pale e picconi per chi non vuole restare incastrato dentro un solo fornitore. Together AI, Fireworks, Modal Labs giocano la stessa partita, e Fireworks starebbe trattando un round a 15 miliardi. Il fondatore Tuhin Srivastava la riassume così: se il cloud è stato la base della generazione precedente di grandi aziende tecnologiche, l’inferenza è la base della prossima. Intanto Baseten ha firmato un accordo di collaborazione con AWS e ha comprato Parsed, una startup di post-training, segno che vuole presidiare tutto il ciclo di vita del modello, non solo il momento della risposta.

Due prezzi nello stesso round

C’è un dettaglio nella struttura del round che dice più della cifra. È diviso in due fasce, alcuni investitori entrano a una valutazione di 11 miliardi, altri pagano 13. È un meccanismo diventato comune nei mega-round del 2026, serve a sbandierare il numero più alto tenendo dentro chi vuole un prezzo d’ingresso più cauto. Lo si può leggere in due modi. Come ingegneria finanziaria che gonfia il titolo, oppure come fotografia fedele di quanto sia diventato difficile mettere d’accordo investitori con appetiti di rischio diversi sullo stesso asset. Tra i nomi del round c’è Wellington Management, un gestore di lungo periodo, non esattamente la firma che ti aspetti quando si parla di schiuma speculativa. La sua presenza è la texture che complica la storia comoda della bolla. A 13 miliardi Baseten viene prezzata come un pezzo della macchina che i team di AI non possono permettersi di sbagliare, più che come un fornitore qualsiasi seduto tra i cloud e i modelli.

Una corsa all’oro è sempre una bolla?

Quindici anni fa scrivevo di un’altra ondata di valutazioni che sembravano slegate dai fondamentali, quella dei social network e delle prime startup mobile, e mi chiedevo se i numeri avessero senso. Molti di quei numeri non lo avevano, alcune di quelle aziende sono sparite, altre sono diventate l’infrastruttura su cui viviamo adesso. La storia della tecnologia raramente sceglie tra bolla e rivoluzione, di solito fa le due cose insieme, gonfia troppo e nello stesso movimento costruisce qualcosa che resta. L’inferenza ha però una caratteristica che la distingue dalla speculazione pura, assomiglia più a una bolletta che a una puntata, torna ogni volta che un utente fa una domanda, a prescindere dall’umore del mercato. Questo non mette al riparo Baseten dal rischio che gli iperscalari, Amazon su tutti, decidano di tirare l’inferenza dentro le proprie piattaforme e schiaccino i margini dello specialista. Spiega però perché un asset manager prudente sceglie di entrare adesso.

Il test vero arriva dopo, quando i soldi saranno atterrati e i clienti dovranno decidere, bolletta alla mano, se affidarsi a Baseten costa davvero meno che cavarsela da soli. A quel punto sapremo se quei 13 miliardi erano la misura di un’infrastruttura diventata essenziale o il prezzo di una puntata fatta nel momento più caldo del ciclo. Per adesso l’unica cosa certa è dove il mercato sta mettendo i soldi veri.

Fonti: TechCrunch, AI inference startup Baseten reportedly raising $1.5B; Baseten, Raises $1.5 Billion to Power the Next Era of AI Inference (comunicato ufficiale). Dati sul round riportati in origine dal Wall Street Journal.

AI & GENAI, TECH & BUSINESS

Bolt: la guida completa al builder AI che gira dentro il tuo browser

Il 3 ottobre 2024 Eric Simons pubblica un tweet. Nessun budget di marketing, nessuna campagna, un link a un prodotto chiamato bolt.new costruito da una società che l’anno prima faceva ottantamila dollari di ricavi ricorrenti e stava per chiudere. Il primo giorno il prodotto aggiunge 60.000 dollari di ARR. Il secondo giorno altri 80.000, più di quanto StackBlitz avesse raccolto in sette anni di lavoro. In quattro settimane sono quattro milioni, a marzo 2025 quaranta.

Dentro quella storia c’è una lezione che riguarda poco l’AI e molto la pazienza industriale, e c’è la ragione tecnica per cui Bolt resta diverso dai suoi concorrenti. Questa è la terza e ultima guida della serie, dopo Lovable e Replit.

Sette anni di infrastruttura prima del successo improvviso

Simons e Albert Pai fondano StackBlitz nel 2017 per costruire un ambiente di sviluppo dentro il browser. Passano quattro anni su una tecnologia chiamata WebContainers: un kernel scritto in Rust, compilato in WebAssembly, che fa girare Node.js dentro la scheda del browser, senza server remoti. Funziona benissimo. Lo usano Google, Cloudflare, Uber per condividere ambienti di debug, e SvelteKit per i tutorial interattivi. I ricavi restano sotto il milione.

A febbraio 2024 i due prototipano l’idea di generare applicazioni con l’AI dentro quell’ambiente, e la mettono via perché i modelli disponibili non reggono. A giugno ottengono l’accesso anticipato a Claude 3.5 Sonnet di Anthropic, il primo modello capace di sostenere l’esperienza. Ci lavorano da luglio, pubblicano a ottobre. La crescita è tale da saturare temporaneamente la capacità di calcolo di Anthropic, e Dario Amodei la descrive come la più rapida mai vista in un cliente.

A gennaio 2025 StackBlitz raccoglie una Series B guidata da Emergence Capital e GV, con Greylock, Madrona e Conviction, per un totale di 135 milioni raccolti e una valutazione intorno ai 700 milioni. Simons ha definito il lancio un successo improvviso costruito in sette anni.

La cosa che mi interessa di questa vicenda è il rovescio di ciò che si racconta di solito sull’AI. Il modello ha reso possibile il prodotto, e il prodotto è stato possibile perché qualcuno aveva speso quattro anni su un problema che sembrava senza mercato.

Un computer intero dentro la scheda

Quando digiti un prompt su Bolt e premi invio, non parte una macchina virtuale su un cloud da qualche parte. Parte un ambiente Node.js dentro il tuo browser. L’agente scrive il codice, installa i pacchetti, esegue il server di sviluppo, e tu vedi l’anteprima girare mentre le modifiche arrivano. Il codice è editabile direttamente, con un editor derivato da VS Code, e questo rende Bolt il più tecnico dei tre strumenti della serie.

L’architettura ha una conseguenza economica che i concorrenti non hanno. Simons l’ha spiegata a Sacra: quando l’utente lancia un progetto, l’ambiente costa zero all’azienda, perché gira sul computer dell’utente. Bolt dichiara margini lordi intorno al settanta per cento, vicini a quelli di un SaaS tradizionale, ed è profittevole, mentre gli altri accendono container su infrastrutture a noleggio per ogni sessione. In un mercato dove tutti bruciano capitale sull’inferenza, questa è una posizione diversa, e per chi valuta la durabilità di un fornitore conta più di una demo.

Intorno al nucleo l’azienda ha costruito il resto. Bolt Cloud, arrivato ad agosto 2025, aggiunge hosting, database, autenticazione e funzioni serverless. Da allora ogni progetto include database interni illimitati, creati quando servono, con gestione utenti, funzioni edge, storage dei file, e l’integrazione con Supabase resta disponibile per chi la preferisce. C’è l’integrazione con Stripe per incassare pagamenti dalle app costruite, ci sono i domini acquistabili dalla piattaforma, e le analitiche del sito pubblicato.

Bolt ha smesso di inseguire i curiosi

Dopo il lancio, centinaia di migliaia di utenti consumer arrivano a costruire progetti personali, e se ne vanno con la stessa velocità. Simons ha raccontato che quel segmento aveva tassi di abbandono altissimi e costi di uscita prossimi allo zero, quindi l’azienda ha girato il timone verso i team di prodotto e ingegneria dentro le aziende, dove la retention somiglia a quella di un SaaS classico.

Oggi l’enterprise vale circa un quarto dei ricavi, il B2B nel suo complesso sta superando la metà, e Bolt dichiara che il 75 per cento delle Fortune 500 usa la piattaforma. A maggio 2026 è arrivata la partnership con Microsoft Azure e Microsoft 365, che aggiunge il Marketplace Microsoft ai canali di acquisto accanto a quello AWS, il deployment nativo su Azure, e l’integrazione con Teams e Microsoft 365 Copilot.

Questa traiettoria dice qualcosa a chi decide gli acquisti. Uno strumento che nasce per i curiosi e si sposta verso l’impresa smette di ottimizzare per la meraviglia dei primi quindici minuti e comincia a ottimizzare per il rinnovo del contratto, che è il momento in cui la sicurezza e la governance diventano argomenti di vendita invece che note a piè di pagina.

Sono i file a consumare i token

Il piano gratuito dà un milione di token al mese, con un tetto di trecentomila al giorno, progetti pubblici e privati, hosting con il marchio Bolt in vista, e un limite di dieci megabyte sui file caricati. Il piano Pro parte da 25 dollari al mese per dieci milioni di token, toglie il tetto giornaliero, il marchio, e aggiunge dominio personalizzato e condivisione privata. Il piano Teams costa 30 dollari per membro, con fatturazione centralizzata e controlli di accesso. Enterprise va a preventivo. Dal luglio 2025 i token non consumati si riportano al mese successivo, per un massimo di due mesi, e servono un abbonamento attivo per essere usati.

La particolarità sta in cosa mangia i token. Bolt sincronizza l’intero albero dei file del progetto con il modello a ogni messaggio, quindi il consumo non dipende dalla lunghezza della tua domanda, ma dalla dimensione di quello che hai costruito fino a quel momento. Una landing page da cinque file costa poco per prompt. Un’applicazione da cinquanta file costa molto, e continua a costare di più mano a mano che cresce. Gli utenti che spingono un progetto oltre una certa complessità riferiscono singoli prompt da un milione di token, cioè l’intero piano gratuito mensile in una richiesta.

L’effetto pratico è che i primi giorni sembrano economici e gli ultimi sembrano una rapina, quando invece il prezzo unitario non è mai cambiato. Chi lavora bene con Bolt tiene i progetti modulari, usa le modalità di discussione e pianificazione per ragionare senza generare, e parte dai template. I prezzi si verificano su bolt.new/pricing prima di ogni decisione.

La sandbox protegge finché il codice non esce

La sicurezza di Bolt va guardata in due tempi, perché la piattaforma e le applicazioni che produce hanno posture opposte.

Durante la costruzione l’isolamento è buono, forse il migliore della categoria. Il WebContainer è una sandbox del browser, il codice generato non ha un filesystem vero, non ha rete privilegiata, e qualunque server tu avvii è raggiungibile soltanto dalla tua scheda. Finché resti lì dentro, il danno che puoi fare a te stesso è limitato.

Il problema comincia quando quel codice esce. Il deploy va su un host reale, l’app si collega a un progetto Supabase reale, a chiavi Stripe reali, a utenti reali, e a quel punto ogni scelta predefinita che l’agente ha preso durante il prototipo diventa una superficie di attacco. Le forme ricorrenti sono sempre le stesse: tabelle pubblicate senza Row Level Security attiva, quindi leggibili da chiunque possieda la chiave anonima che sta nel bundle JavaScript, chiavi API scritte dentro il codice del frontend e trovate dagli scanner automatici nelle prime ore dopo la pubblicazione, endpoint generati per fare operazioni sui dati senza un controllo su chi possiede quel dato, funzioni serverless senza limiti di frequenza sulle chiamate.

Bolt genera frontend, backend, schema del database e collante tra i servizi nella stessa sessione, e ogni strato è un posto dove un controllo di sicurezza viene saltato perché nessuno lo aveva chiesto nel prompt. Questo lo rende più esposto di uno strumento che genera solo interfacce, come v0. Scansioni indipendenti su oltre mille applicazioni costruite con questi strumenti hanno trovato problemi nella quasi totalità dei casi, con una quota rilevante di falle critiche, e i campioni includevano Bolt insieme a Lovable, Replit e v0, come documenta lo studio di Security Boulevard.

C’è un rischio più recente che vale la pena conoscere. I modelli suggeriscono a volte pacchetti npm che non esistono, e gli attaccanti registrano in anticipo quei nomi con dentro codice malevolo, aspettando che qualcuno installi la dipendenza allucinata. Un controllo delle dipendenze dopo ogni aggiunta smette di essere pignoleria.

Le regole per chi porta la responsabilità in azienda sono poche. Ogni file generato va trattato come se fosse pubblico. Ogni chiave passata dalla piattaforma va considerata compromessa e ruotata. La Row Level Security va attivata e verificata a mano, senza chiedere conferma all’AI che ha scritto il codice, perché il modello vede il file che gli mostri, non il controllo che hai dimenticato altrove. E la verifica va fatta sull’applicazione pubblicata, non sull’anteprima nella sandbox.

Il vecchio agente ha una data di spegnimento

Ad aprile 2026 Bolt ha ritirato il suo agente storico. Dal 13 aprile non è più selezionabile per i nuovi progetti, e dal 3 agosto 2026 i progetti costruiti con la vecchia versione, e i siti che ne derivano, smetteranno di essere accessibili: vengono commutati automaticamente su Claude Agent, che nel frattempo è diventato il motore predefinito della piattaforma. Chi passa a mano perde la cronologia della chat, mentre file e codice restano.

Il modello predefinito oggi è Claude Sonnet 4.6, con Haiku 4.5 per le modifiche rapide e Opus 4.6 per il ragionamento complesso. Si può guidare il contesto del progetto con un file claude.md, la stessa convenzione che chi lavora con Claude Code conosce bene.

Vale la pena fermarsi su questa scadenza, perché è il tipo di evento che nessuna demo racconta. Un fornitore giovane può decidere che una parte della tua storia di lavoro non è più supportata, fissare una data, e migrarti d’ufficio. Il codice resta tuo, ed è la ragione per cui la portabilità va verificata prima di costruirci sopra, non dopo aver ricevuto la mail.

Dove si colloca rispetto a Lovable e Replit

Bolt è lo strumento più vicino allo sviluppatore dei tre. Ti lascia le mani nel codice, supporta più framework, gira interamente nel browser, e il suo modello di costo premia i progetti piccoli e modulari. Lovable arriva prima a un’applicazione web presentabile ed è la più amichevole con chi non scrive codice. Replit è l’ambiente più completo, con terminale, database gestito, deployment sofisticati e app mobili native, ed è la risposta quando il progetto deve girare in produzione da qualche parte.

Chi sceglie Bolt di solito è una persona che sa cosa sta guardando quando apre un file, e vuole che l’AI faccia la parte noiosa. Chi sceglie gli altri due sta comprando qualcosa che assomiglia di più a un servizio completo. Le tre guide stanno insieme nella sezione AI e GenAI.

Il primo progetto

Si parte dal piano gratuito, senza carta di credito, con un milione di token che bastano per capire il meccanismo e costruire qualcosa di piccolo. La prima cosa da fare è restare in modalità discussione o pianificazione finché l’impianto non è chiaro, perché ogni giro di generazione su un progetto già grande costa più del precedente.

Poi si costruisce, tenendo i moduli separati e i file corti, che qui è una scelta economica prima che architetturale. Quando servono dati e autenticazione si usa il database integrato oppure Supabase, e si attiva la Row Level Security prima di mettere qualunque cosa online. Prima di pubblicare si cerca nel bundle compilato ogni traccia di chiavi segrete, si sposta il codice che chiama servizi a pagamento dentro una funzione lato server, e si prova l’applicazione pubblicata come se fosse di qualcun altro.

Dove regge, dove rallenta

Bolt è eccellente per portare in mezz’ora un’idea allo stato di prototipo funzionante, dentro una scheda del browser, senza installare niente. Landing page, strumenti interni, MVP, applicazioni che devono esistere in fretta per essere mostrate a qualcuno: su questo terreno è veloce come pochi, e la portabilità del codice ti lascia una via d’uscita. Dove rallenta è dove rallentano tutti, con l’aggravante del suo modello di costo: quando il progetto cresce, ogni prompt costa di più e l’agente perde il filo del contesto, e la tentazione di continuare a chiedere invece di mettere le mani nel codice diventa la voce più cara della fattura.

Per chi guida la tecnologia in azienda, Bolt è un caso di studio su due livelli. Sul primo è uno strumento che accorcia il ciclo dall’idea al prototipo mantenendo il codice leggibile e trasportabile, e questa è una virtù rara. Sul secondo è la dimostrazione che un’architettura scelta bene sette anni prima decide chi resta in piedi quando il costo dell’inferenza schiaccia i margini di tutti. Il mestiere di chi sa leggere il codice non scompare, si sposta verso la revisione, la sicurezza, e la scelta di quale fornitore meriti la propria dipendenza.

Senza dubbio tra un anno questi strumenti saranno più capaci e i loro margini più chiari. La domanda che resta aperta riguarda la data del 3 agosto: quando un fornitore decide che una parte del tuo lavoro non esiste più, quanto del tuo lavoro sei ancora in grado di portare via?

Riferimenti.

Ufficiali: sito Bolt, piani e prezzi, note di rilascio con il calendario del ritiro del vecchio agente.

Azienda e crescita: la scheda di Contrary Research su Bolt; l’intervista di Sacra a Eric Simons su margini, WebContainers e virata verso il B2B; la scheda Sacra su Bolt.new per finanziamenti e migrazione dell’agente.

La storia del lancio, raccontata da Simons: la puntata di Lenny’s Newsletter.

Sicurezza della categoria: studio Security Boulevard sulle vulnerabilità nelle app vibe coded.

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.