Quando il risultato sembra facile, il valore diventa invisibile

Ed è qui che inizia la parte strana.

Proprio perché oggi posso costruire alcune soluzioni più velocemente e spendendo meno, il loro valore rischia di essere percepito come inferiore.

Come se il problema risolto fosse meno reale perché non è costato una fortuna.

Come se il tempo risparmiato fosse una prova di superficialità.

Come se una soluzione ottenuta con l’AI fosse, per definizione, una scorciatoia.

Poi c’è l’altra spiegazione, quella che sembra un complimento: «Tanto Vincenzo è bravo, queste cose le sa fare. È nerd».

Probabilmente è detto con affetto. Ma ha un effetto collaterale: rende invisibile il lavoro.

L’attenzione si sposta sulla facilità con cui avrei costruito qualcosa, non sulla capacità di riconoscere il problema, porre le domande giuste, organizzare il progetto, anticipare gli errori e trasformare una necessità in una soluzione utilizzabile.

Non si vedono i tentativi scartati, i guardrail, i controlli, i rollback, le dipendenze, le scelte sui dati e le decisioni prese prima che un agente scriva una sola riga di codice.

Ma il valore è quasi tutto lì.

Chiedere un software a un’AI non significa progettare un prodotto

Puoi aprire Claude, Codex o un altro strumento e scrivere: «Voglio un software che faccia questo».

Probabilmente proverà ad accontentarti.

Potresti ottenere un’interfaccia credibile, alcune funzioni operative e una demo abbastanza convincente da sembrare un prodotto.

Uno specchietto per le allodole ben impaginato.

Non è molto diverso da ciò che può accadere quando una persona con un’idea parla direttamente con uno sviluppatore senza passare da una fase di analisi, product discovery o progettazione.

Lo sviluppatore costruisce ciò che gli viene chiesto. Il problema è che nessuno ha ancora verificato se sia davvero ciò che serve.

Mancano le domande

• Chi utilizzerà quella funzione e in quale momento?
• Quale informazione rappresenta la fonte ufficiale?
• Cosa succede quando un’operazione fallisce?
• Come vengono gestiti dati incompleti, duplicati o contraddittori?
• Cosa deve essere registrato e per quanto tempo?
• Chi può modificare, approvare o annullare un’azione?
• Come si torna allo stato precedente?
• Cosa accade quando il modello non è abbastanza sicuro?

L’intelligenza artificiale ha ridotto enormemente la distanza tra l’idea e l’esecuzione.

Non ha eliminato la distanza tra l’idea e un buon prodotto.

Ne ho scritto anche in L’AI corre alla velocità della luce. Noi no.: accelerare un processo inutile non produce innovazione. Produce più inutilità, consegnata prima.

Il playbook di Notion e l’AI Chief of Staff

Questa riflessione è tornata leggendo The AI operations playbook for small businesses, pubblicato da Notion come early preview nell’edizione di luglio 2026.

Il documento parte da una frase brutale nella sua semplicità: nelle piccole organizzazioni, spesso è una persona a fare da integrazione tra strumenti diversi. Legge un’informazione in un posto, la ricopia in un altro, ricostruisce decisioni disperse e aggiorna manualmente ciò che i sistemi non si sono detti.¹

Il playbook propone di consolidare il lavoro in quattro hub:

• attività e progetti;
• CRM;
• note e brainstorm;
• conoscenza aziendale.

Ogni hub deve avere proprietà minime e coerenti — stato, responsabile, scadenza, priorità, ultimo contatto, data di revisione — perché gli agenti possano leggere e aggiornare le informazioni in modo affidabile.²

Conoscenza consolidata: agenti capaci. Conoscenza dispersa: agenti costretti a indovinare.

A pagina 9 il documento aggiunge un passaggio essenziale: il workspace deve diventare leggibile dagli agenti.

Le decisioni prese nelle chat devono finire nelle note, gli accordi verbali nel CRM, gli elementi ricorrenti nei database e ogni area importante deve avere una pagina di contesto che spieghi cosa fa l’azienda, chi sono i clienti e come vengono prese le decisioni.³

Poi arriva l’AI Chief of Staff.

Notion non lo presenta come un dirigente artificiale che decide al posto delle persone, ma come un decision-making thought partner: un agente che utilizza il contesto dell’organizzazione e una libreria di framework — SPADE, Decision Speed, matrici RACI e altri modelli — per accompagnare l’utente nelle scelte complesse.⁴

Ogni agente, nel modello del playbook, ha tre parti:

1. istruzioni;
2. connessioni;
3. trigger.

Ha un ruolo, può vedere determinati strumenti e si attiva in condizioni definite.

Non è una chat che aspetta una domanda. È un elemento operativo inserito in un sistema.

Il risultato finale immaginato da Notion è un ambiente nel quale inbox, briefing e database sono già aggiornati quando la persona apre il computer, così da dedicare il tempo al giudizio invece che alla ricostruzione delle informazioni.⁵

È un buon punto di partenza.

La mia esperienza, però, mi ha portato un po’ più avanti.

Non ho costruito un Chief of Staff. Ho costruito un’organizzazione

Nel mio sistema non esiste un solo agente che fa tutto.

Esistono agenti con ruoli diversi.

Uno corregge i miei articoli. Non li scrive al posto mio: lavora su testi che ho scritto spesso di getto, magari sullo smartphone o su reMarkable, ricompone i passaggi, riconosce errori ricorrenti e interviene sui miei pattern linguistici.

Ha elaborato centinaia di miei articoli, e-mail e conversazioni. Conosce come scrivo, cosa sbaglio più spesso e quali correzioni rischiano di rendere la mia voce più pulita ma meno mia.

Non è un ghostwriter. Odio i ghostwriter.

Mia moglie, che è una copywriter fantastica e una «nazigram» implacabile, continua invece a correggermi i pitch dei webinar. Le leggo i testi e mi aiuta a diventare uno speaker migliore.

Quella parte non voglio delegarla.

Non tutto ciò che può essere dato in pasto a un agente deve necessariamente esserlo.

Altri agenti preparano testi per LinkedIn a partire dalle mie idee, selezionano le notizie delle pillole, traducono contenuti, organizzano informazioni o presidiano scenari specifici.

Un altro agente mi ha costruito una dashboard per misurare il costo dei token utilizzati dall’intero sistema.

Non ho quindi un assistente artificiale.

Ho una piccola azienda fatta di agenti AI.

Un’azienda non funziona perché assume molte persone

Funziona perché stabilisce chi fa cosa, con quali poteri e dentro quali limiti.

Lo stesso vale per gli agenti.

• Un agente operativo non dovrebbe controllare autonomamente la qualità del proprio lavoro.
• Un agente che produce non dovrebbe essere anche quello che approva.
• Un traduttore non dovrebbe riscrivere il significato.
• Un correttore non dovrebbe sostituirsi all’autore.
• Un agente di compliance non dovrebbe inventare l’interpretazione più comoda di una regola.

Per questo sto costruendo strutture composte da supervisori, direttori operativi, agenti specializzati, quality control, controlli di compliance e privacy, logging e monitoraggio dei costi.

Non come titoli decorativi da mostrare in una dashboard.

Come separazione delle responsabilità.

Un agente probabilistico non diventa deterministico per decreto

Qui serve essere precisi.

Un modello linguistico non diventa deterministico perché nelle istruzioni gli scriviamo: «Non devi interpretare» oppure «Devi rispettare sempre queste regole».

Può essere coerente. Può essere molto affidabile in uno scenario delimitato.

Ma resta un sistema probabilistico.

Il comportamento davvero controllabile nasce dall’architettura che costruiamo attorno al modello:

• output strutturati e schemi obbligatori;
• regole codificate e validatori esterni;
• test automatici e criteri di accettazione;
• permessi minimi e separazione dei ruoli;
• soglie che bloccano l’azione in caso di incertezza;
• log verificabili e versionamento;
• approvazione umana nei passaggi sensibili;
• fallback espliciti quando il sistema non può decidere.

Non devi chiedere all’AI di rispettare una regola. Devi costruire un sistema nel quale non possa aggirarla.

Le regole devono essere decise dagli esseri umani e documentate.

L’agente può confrontare un output con quei criteri, produrre evidenze e segnalare ciò che non riesce a verificare.

L’agente non deve inventare la regola.

Deve operare dentro la regola.

È lo stesso nodo emerso in Andon Market: l’AI non sostituisce il negozio: autonomia e affidabilità non sono la stessa cosa.

Un agente può coordinare attività reali e restare fragile, opaco o incoerente se nessuno ha definito obiettivi, soglie di rischio e punti di controllo.

La velocità genera un nuovo debito

L’AI accelera la produzione.

È una delle sue qualità più evidenti.

Posso passare da un’esigenza a una prima versione funzionante in tempi che fino a poco fa sarebbero stati difficili da immaginare.

Ma l’accelerazione porta con sé un rischio.

Produciamo così rapidamente che possiamo ritrovarci a mettere toppe su qualcosa che non abbiamo avuto il tempo di testare davvero.

Il codice arriva prima delle domande.

La beta viene trattata come un prodotto finito.

La demo supera il confine della produzione quasi senza che nessuno se ne accorga.

Prima il costo dello sviluppo imponeva almeno una certa lentezza.

Non garantiva la qualità, ma limitava la quantità di software che potevamo produrre.

Ora il collo di bottiglia si è spostato.

Non è più soltanto scrivere il codice.

È capire quale codice sia sufficientemente utile, verificato, sicuro e mantenibile da meritare di restare attivo.

Senza dati strutturati non esiste nessuna azienda di agenti

I miei agenti funzionano perché cerco di non lasciare le informazioni sparse.

Un appunto non resta soltanto un appunto.

Quando contiene un’informazione utile, deve trovare una struttura, una relazione e un posto preciso in un database sul mio server.

La memoria operativa non può dipendere da una conversazione dimenticata, da un messaggio introvabile o da una nota scritta durante una telefonata.

Ogni informazione deve poter dire da dove arriva, a cosa è collegata, quale versione è valida, chi l’ha modificata e se può essere usata da un agente.

È la parte meno spettacolare di tutto il sistema.

Ed è anche quella senza la quale il sistema non funzionerebbe.

In Le aziende cercano davvero talenti? ho scritto che l’AI non decide cosa cercare: amplifica ciò che abbiamo deciso di cercare.

Qui accade la stessa cosa.

Se il processo è progettato per la conformità, l’AI renderà più efficiente quella conformità.

Se il processo è confuso, renderà più veloce la confusione.

Sto costruendo il mio esoscheletro AI

Forse «azienda» non è nemmeno la metafora definitiva.

Quello che sto costruendo assomiglia sempre di più a un esoscheletro.

Un’armatura.

Un insieme di boost in stile Cyberpunk 2077.

Non ho lame che escono dagli avambracci e non posso ancora fare il super salto.

Probabilmente è meglio così, considerando la quantità di documentazione che servirebbe per la valutazione dei rischi.

Ma posso estendere la mia memoria, aumentare la capacità di esecuzione, presidiare più processi, mantenere continuità e trasformare alcune decisioni in azioni senza dover ripetere ogni volta gli stessi passaggi.

È una domanda che mi ero già posto costruendo Untitled Life: l’AI è una scorciatoia oppure un esoscheletro per ciò che non riesco a fare da solo?

Oggi la mia risposta è più chiara.

Dipende da ciò che togli e da ciò che amplifichi.

Un esoscheletro non decide dove andare. Amplifica il movimento di chi lo indossa.

E se la direzione è sbagliata, amplifica anche l’errore.

Per questo il capo sono ancora io.

Non perché debba approvare personalmente ogni virgola prodotta dai miei agenti.

Ma perché sono ancora responsabile degli obiettivi, dei criteri, delle fonti, dei limiti, dei fallback e delle conseguenze.

Il valore non è nel codice che l’AI ha scritto

Il valore è nel problema che hai saputo riconoscere.

Nelle domande che hai posto prima di costruire.

Nelle alternative che hai scartato.

Nel sistema che continua a funzionare quando qualcosa va storto.

Nei dati che hai organizzato.

Nelle regole che hai documentato.

Nella capacità di distinguere ciò che può essere automatizzato da ciò che deve restare umano.

Ho costruito un’azienda di agenti AI.

Funziona.

Esistono sicuramente persone più brave di me nel costruire sistemi del genere.

Ma questo non cancella il valore prodotto.

Ho investito il necessario, evitato costi inutili e realizzato un sistema che risolve problemi reali.

Forse la difficoltà è che continuiamo a misurare il valore attraverso il costo della produzione.

E l’AI sta rendendo quel costo sempre meno visibile.

Quando una soluzione costa meno e arriva prima, sappiamo riconoscere il valore della progettazione oppure apprezziamo soltanto ciò che è stato abbastanza costoso da sembrare importante?

Seguimi o lasciami stare.

Fonti e riferimenti

1. Notion, The AI operations playbook for small businesses, July 2026 Edition, Early Preview, p. 2: il documento descrive la persona come integrazione manuale tra strumenti e il workspace come livello di contesto per gli agenti. ↩
2. Ivi, pp. 5–6: i quattro hub sono Tasks & Projects, CRM, Notes & Brainstorms e Company Knowledge; il paper elenca le proprietà minime che permettono agli agenti di leggere e aggiornare i dati. ↩
3. Ivi, p. 9: la sezione “Make your workspace agent-readable” raccomanda database per gli elementi ricorrenti, pagine di contesto e trasferimento delle decisioni dalle chat agli hub strutturati. ↩
4. Ivi, p. 10: l’AI Chief of Staff è definito come decision-making thought partner e viene collegato a framework quali SPADE, Decision Speed e matrici RACI. ↩
5. Ivi, sezione finale “The end state”: l’obiettivo dichiarato è liberare tempo per il giudizio, riducendo il lavoro manuale di ricostruzione e aggiornamento. ↩

Per il contesto sul prodotto: pagina ufficiale Notion AI. Il collegamento è informativo e non sostituisce la citazione del paper in anteprima.