Tag Archive for: governance

Posts

black and white color pencils on black and white background

Aristotele, logica e Intelligenza Artificiale

April 19, 2026/in Comunicare stanca, Governance, Marketing/by pierotaglia

Capita in ogni progetto (soprattutto digitale): arrivano le richieste con una soluzione dentro: le richieste non sono “abbiamo questo problema”, ma “vogliamo fare questa cosa”. Quando chiedi da dove viene quella certezza, la risposta è qualcosa come: “Ho visto come l’ha fatto un competitor” oppure “L’ho provato e funziona”.Quella certezza, quasi sempre, nasce da un’esposizione superficiale a qualcosa di complesso. E oggi quella esposizione è diventata più rapida, più convincente e più accessibile che mai.

Nuovi problemi vecchi

Claude Design, l’ultimo strumento che ha alimentato il dibattito su AI e professioni creative, non ha inventato nulla di strutturalmente nuovo, ma ha reso più visibile una dinamica che esiste da quando esistono gli strumenti digitali:

abbassare la soglia di accesso a un dominio non equivale ad abbassare la soglia di competenza in quel dominio.

La differenza è che oggi quella soglia si abbassa in dieci minuti invece che in dieci mesi e questo cambia molto, ma non nel modo in cui il dibattito tende a descriverlo.

In mano a un designer, Claude Design fa quello che ogni buono strumento fa quando viene usato da chi ha conoscenza dichiarativa: accelera l’output e ne migliora la qualità.

Il designer sa cosa sta chiedendo, sa valutare quello che ottiene, sa quando il risultato è sbagliato anche se sembra convincente. Lo strumento moltiplica la competenza esistente.

In mano a un non-designer, fa qualcosa di diverso e altrettanto utile:

consente di effettuare iterazioni, di arrivare alla conversazione con l’altra persona con qualcosa in mano, non per sostituire quella conversazione, ma per renderla molto più produttiva.

Il collo di bottiglia

Per anni, la sperimentazione iniziale in qualsiasi progetto digitale aveva un costo (a volte nascosto) importante: richiedeva l’interazione tra persone diverse prima ancora che il lavoro reale iniziasse.

Volevi esplorare tre varianti di un’interfaccia? Serviva un designer.
Volevi capire se una soluzione era tecnicamente praticabile? Serviva uno sviluppatore.

Nel frattempo, chi aveva l’idea aspettava, il designer riceveva un brief vago, lo sviluppatore riceveva un wireframe sbagliato, e il ciclo ricominciava in una lunghissima partita a pong.

Quel ciclo ha un nome: fase di esplorazione ¹ e aveva un costo che pochi mettevano a budget ² perché non era visibile, distribuito nel tempo di tutte le persone coinvolte.

Watt Humphrey aveva descritto questo problema con una precisione che non ha perso nulla in trent’anni:

“For a new software system, the requirements will not be completely known until after the users have used it.”

L’incertezza sui requisiti non è cattiveria, non è incompetenza, ma è la natura del problema. Le persone arrivano con idee confuse non perché non si siano impegnate, ma perché un requisito diventa noto solo quando viene testato. Prima di quel momento, quello che abbiamo non è un requisito: è un’ipotesi.

Agile e Lean Startup hanno portato questa idea al centro della pratica professionale e dovrebbe essere patrimonio comune ormai. L’MVP (il Minimum Viable Product – Minimo Prodotto Fattibile) non è una versione economica del prodotto finale: è uno strumento epistemico. Serve infatti a validare le assunzioni critiche prima di investire sulla realizzazione ⁴.

La sperimentazione non è “proviamo e vediamo cosa succede”; è un’attività disciplinata.

Cosa voglio capire?
Quale ipotesi sto testando?
Cosa mi dirà che avevo ragione o torto?

Senza quelle domande, il prototipo non è un esperimento: è un’impressione con un’interfaccia sopra.

Un elemento costante

La versione zero, l’esplorazione, il prototipo, il wireframe grezzo, ha un costo che si è ridotto drasticamente: meno persone coinvolte, meno cicli di andata e ritorno, meno tempo perso a spiegare cosa si intende. Evviva.

Attenzione: la versione finale richiede ancora le stesse figure di prima [Ref]Da questo punto di vista ho dei dubbi sul fatto che sia effettivamente più economico: l’altro giorno è apparsa una notizia nella quale il CTO di Uber ha detto che hanno già finito il budget AI 2026 in questi primi mesi. Meno persone ok, ma il costo dei tool è interessante[/ref].

Figure che con gli strumenti AI, lavorano in modo strutturalmente diverso. Non meno: diversamente. A tal proposito è molto bello il racconto di Matteo Bossolini, co-founder di Cato, nell’ultimo episodio di Cosa Sposta: il programmatore non scrive meno codice perché è diventato pigro, ma perché è diventato architetto ⁵.

Il designer con Claude Design arriva alla soluzione più velocemente perché ha già eliminato le opzioni ovviamente sbagliate.

Lo sviluppatore con Claude Code produce l’architettura del sistema più in fretta perché ha già testato tre approcci senza scrivere una riga.

La competenza non vale meno; vale nel momento giusto, sul problema giusto.

Rispettare il tempo dei colleghi significa arrivare alla conversazione con un semilavorato che ha già attraversato un ciclo di verifica personale. Non “ho un’idea”, ma “ho testato questa ipotesi, ho visto che non funziona così, e voglio capire se la direzione è giusta”. Quella è la versione zero fatta bene.

Il rischio di distorsione

C’è però un effetto collaterale che va nominato senza eufemismi, e che Luca Sartoni ha descritto in un bel post: chi produce la versione zero tende a dimenticare che è una versione zero.

Non è pigrizia, non è malafede: quando in dieci minuti ottieni qualcosa che sembra un risultato professionale, il cervello registra competenza acquisita. E quella sensazione, quando incontra il potere decisionale, produce esattamente il danno che Luca descrive:

il lavoro degli esperti viene scavalcato, le risorse vengono allocate su basi emotive, chi ha competenza di dominio si trova a difendere scelte che non avrebbe mai fatto.

Il problema non è lo strumento, ma la mancanza di una distinzione operativa che le organizzazioni non stanno ancora facendo in modo esplicito: chi può produrre la versione zero (sempre di più) e chi può validare la versione finale (gli stessi di prima) sono due ruoli diversi e confonderli costa<.

Ma Aristotele?

C’è un concetto che Google ha sviluppato anni fa e che non ha mai ricevuto l’attenzione che merita fuori da alcune cerchie di sviluppo prodotto: il pretotyping.

In estrema sintesi il pretotyping aiuta a capire se ha senso fare qualcosa, il prototipo è già ragiona sul come fare a realizzare La distinzione con il prototipo è semplice ma fondamentale. Il pretotyping risponde alla domanda “ha senso farlo?”; il prototipo risponde alla domanda “Riusciamo a farlo?”. Sono due domande diverse, con due strumenti diversi e due momenti diversi ⁶.

La sperimentazione con gli strumenti AI vive esattamente nel primo spazio: serve a capire cosa ha senso fare prima di chiedere a qualcuno di farlo e portarlo alla finalizzazione.

Ed è qui che entra in gioco qualcosa che Aristotele aveva formalizzato ventiquattro secoli fa: il principio di non contraddizione.

A non può essere contemporaneamente A e non-A.

Il lavoro di sperimentazione non può essere contemporaneamente sperimentazione e prodotto finale. Non è una questione di contesto o di ottimismo: è una contraddizione in termini.

A è il pretotipo. Non-A è il prodotto. A non diventa non-A per accumulo di iterazioni: diventa non-A quando qualcuno con le competenze giuste decide che l’ipotesi è stata validata e che vale la pena realizzarla.

Confondere i due momenti non è efficienza; è saltare la domanda più importante.

Peccato che saltare la domanda più importante nell’era in cui gli strumenti AI rendono tutto più veloce costi più di prima perché la velocità amplifica gli errori di metodo, non li corregge.

BONUS: grafica by Gemini

Una comoda rappresentazione dei due pattern fatta con Nano Banana

Notes:

A questo approccio vengono dati nomi diversi a seconda della disciplina di riferimento: Ideazione, Product Exploration, Discovery… è un momento in cui si fanno degli esperimenti per raccogliere esigenze e necessità reali prima di impegnare risorse nello sviluppo vero e proprio ↩
Non tutte le aziende hanno competenze di product management #sadness ↩
Per un nuovo sistema software, i requisiti non saranno completamente noti fino a quando gli utenti non lo avranno utilizzato.” Il principio vale ben oltre il software: vale per qualsiasi prodotto, servizio o interfaccia che non è mai esistito prima nella forma in cui lo si sta progettando. ↩
Piccola sintesi sul metodo e lo strumento: fare bene cose che non hanno senso non ha valore per cui è fondamentale validare le ipotesi più rischiose prima di procedere in maniera più aggresiva e strutturata (e bruciare budget). L’MVP è lo strumento di comprensione per capire tramite sperimentazione verso soluzioni nelle quali il livello di incertezza si è ridotto ↩
Se non ascoltate Cosa Sposta fatelo. Sintesi dell’episodio: Cato ha costruito l’intero software con un team di 4 persone nel tech, affidandosi a Claude, Cursor e Claude Code per la generazione del codice e concentrando il lavoro umano su architettura, PRD e ricerca di prodotto ↩
La distinzione tra pretotyping e prototipo è spesso ignorata nella pratica: si salta direttamente al “come farlo” senza aver validato il “se farlo”. ↩

Quando il saggio indica la governance, lo stolto guarda l’AI

April 9, 2026/in Comunicare stanca, Marketing, Project Management/by pierotaglia

Quando faccio progetti (di strategia, di riorganizzazione del marketing, di introduzione dell’AI), un’interessante situazione nella quale mi imbatto (credo comune a molti e molte) è che ci sono alcune incomprensioni iniziali che non sono tecnologiche: le persone fanno fatica a identificare cosa vogliono risolvere (dove spesso il racconto è focalizzato su sintomi e soluzioni) e le organizzazioni non hanno deciso chi può decidere cosa (per cui c’è un momento di lentezza per capire qual è il giro del fumo).

Non è una novità e il fatto che si riproponga in contesti diversi, con strumenti diversi, in aziende di dimensioni diverse è per me interessante. L’AI adesso è solo l’ultimo sintomo, più visibile degli altri perché arriva con aspettative alte e risultati spesso deludenti.

Il risultato è prevedibile: si introducono strumenti senza rivedere i processi, si ottimizza localmente quello che si rompe sistemicamente, si crea nuovo muda (spreco) credendo di eliminarlo ¹.

Tre problemi concreti che trovo in sequenza, quasi sempre in quest’ordine.

Primo problema: non sai cosa stai risolvendo

L’errore più comune (nell’introduzione di qualsiasi strumento, AI inclusa) non è scegliere la soluzione sbagliata, ma è scegliere la soluzione prima di aver definito il problema.

Usiamo l’AI per fare le sintesi delle riunioni.

Bene. E quelle sintesi le usa qualcuno? Generano decisioni? Cambiano qualcosa?

No, ma almeno le abbiamo.

Questo è waste con un’interfaccia moderna. Nessuno strumento lo trasforma in valore, lo produce più velocemente (il famigerato AI Slop).

Prima di qualsiasi introduzione serve una domanda brutalmente semplice: qual è il problema che stiamo cercando di risolvere, e come fa questo strumento a risolverlo? Se la risposta è vaga, il problema non è ancora definito. E se il problema non è definito, qualsiasi soluzione è prematura. ²

Ma c’è un prerequisito ancora più a monte, che ho affrontato nel post precedente: per definire un problema con sufficiente precisione da poterlo delegare (a un collaboratore, a un team, a un sistema AI) hai bisogno di conoscenza dichiarativa, la capacità di descrivere quello che fai, i criteri con cui decidi, il risultato che vuoi ottenere. Chi non ha sviluppato questa competenza non riesce a identificare il problema in modo utilizzabile e finisce per delegare un compito che nemmeno lui sa definire con precisione ³.

C’è poi una seconda domanda da fare, che viene quasi mai fatta:

questo è un problema mio, del mio team, o dell’organizzazione?

Perché la risposta cambia completamente chi deve risolverlo, con quali strumenti e con quale livello di autonomia.

Secondo problema: non hai deciso chi può decidere cosa

Che si tratti di riorganizzare il marketing, introdurre un nuovo processo o adottare strumenti AI, il problema sottostante è quasi sempre lo stesso: manca una struttura chiara di governance. Chi può usare quali strumenti, per quali attività, con quali output attesi, con quale livello di autonomia non è sempre chiaro perché è parte (più frequentemente di quanto vorrei) di una conoscenza implicita, non dichiarata e che quindi deve essere trovata.

Senza questa struttura succedono due cose opposte e ugualmente dannose.

La prima: le persone non agiscono perché non sanno se possono, se devono, se è appropriato.
La seconda: le persone agiscono in modo non coordinato, producendo output incompatibili, processi ridondanti, e una frammentazione del lavoro che è peggio della situazione di partenza.

Quello che serve (e che poche organizzazioni hanno costruito in modo esplicito) è qualcosa che somiglia a una costituzione dell’autonomia ⁴: un insieme di principi chiari che definisce le aree in cui il problem solving locale è abilitato e le aree in cui serve coordinamento. Non un manuale operativo non una policy di 40 pagine. Un frame che risponde a: cosa puoi decidere da solo, cosa devi concordare, cosa non puoi fare senza autorizzazione esplicita.

Senza questo frame, ogni persona e ogni team risolve il problema come può, con gli strumenti che ha, secondo criteri che non sono condivisi. L’organizzazione diventa una collezione di ottimizzazioni locali che non si sommano mai in efficienza sistemica.

⁵

Terzo problema: il lavoro di orchestrazione frammenta l’attenzione

Quando nuovi strumenti entrano nel flusso di lavoro (e l’AI lo fa in modo particolarmente pervasivo) il lavoro cambia natura. Non scompare: si trasforma. Meno produzione diretta, più orchestrazione: definire il task, verificare l’output, correggere, iterare, integrare.

Questo sembra un miglioramento. In parte lo è, ma introduce un effetto collaterale che si rischia di sottovalutare: la frammentazione dell’attenzione.

Se ogni quindici minuti verifico l’output di un processo delegato (a un agente AI, a un collaboratore remoto, a un sistema automatizzato) sto lavorando su più cose contemporaneamente in modo strutturale (e ho già mostrato in un post precedente cosa produce il multitasking sul rendimento “Perché è pericoloso lavorare su più progetti”): il multitasking non è un’abilità. È un costo.

Il context switching non sparisce con l’AI, si moltiplica, perché le istanze di lavoro si moltiplicano.

Questo ha un’implicazione diretta su come organizzare il lavoro: non per attività, ma per blocchi di risultato.

La domanda non è “cosa faccio adesso?” ma “qual è il risultato che voglio avere al termine di questo blocco di tempo, e come organizzo gli strumenti per ottenerlo senza dover verificare ogni quindici minuti?” e oltretutto torniamo a un ripensamento profondo delle attività per evitare di rendere più inefficienti processi non pensati per l’AI.

Il focus si sposta ancor di più dall’attività all’impatto ovvero dal tempo lavorato al risultato prodotto. Non è una novità concettuale (è la logica del lavoro per obiettivi, degli OKR, di qualsiasi approccio che mette il risultato prima del processo).

Ma la moltiplicazione degli strumenti rende questa transizione non più opzionale.

⁶

Il problema dell’accountability che nessuno vuole affrontare

C’è un quarto problema, che non viene quasi mai nominato esplicitamente: è il più scomodo, ed è quello che rischia di avere le conseguenze più serie in particolare con l’AI, ma non solo.

Chi risponde quando qualcosa va storto?

Per rispondere con precisione, possiamo sfruttare uno strumento che il project management usa da decenni: una RAM, Responsibility Assignment Matrix, una matrice che mappa ruoli e responsabilità su attività o deliverable. Il PMBOK del PMI la definisce come strumento per illustrare le connessioni tra work package e membri del team di progetto ⁷.

La RACI (il tipo di RAM più usato) assegna a ogni attività quattro ruoli: chi esegue (Responsible), chi risponde del risultato (Accountable), chi viene consultato (Consulted), chi viene informato (Informed). Una regola fondamentale, ribadita dal PMBOK: per ogni attività deve esserci un solo Accountable. Non due. Non nessuno. Uno.

Ora prova ad applicare questa logica a un processo che include un sistema AI.

L’AI non può essere Accountable, per lo meno non nel senso tecnico del termine. Accountable significa rispondere del risultato, avere skin in the game, subire le conseguenze di una decisione sbagliata. Un sistema non risponde, non subisce conseguenze, non impara nel senso in cui impara una persona che ha sbagliato e ne porta il peso.

Questo non è un problema filosofico, è un problema operativo immediato.

In questo momento, tutta la responsabilità dell’output di un sistema AI ricade sull’operatore, la persona o l’organizzazione che ha scelto di usarlo, che lo ha configurato, che ha accettato il risultato. Anche quando il risultato è sbagliato. Anche quando l’errore era nel modello, nel training data, in una deriva che l’utente non aveva modo di prevedere.

Il parallelo più preciso è quello della guida autonoma. In caso di incidente, chi risponde? Il guidatore che non aveva le mani sul volante? Il produttore del software? La casa automobilistica? La risposta legale è ancora in costruzione, ma la risposta operativa attuale è che il guidatore è Accountable, perché era nella posizione di controllo.

Con l’AI in azienda funziona esattamente così. L’operatore risponde sempre. Anche se ha fatto “tutto bene”. La delega al sistema non riduce la responsabilità, la maschera, finché non emerge il problema.

Questo ha due implicazioni concrete che le organizzazioni quasi mai considerano esplicitamente.

Il livello di controllo iniziale non può essere basso. Un sistema AI non è un collaboratore che ha già dimostrato di meritare autonomia. È un sistema che deve guadagnarsi la fiducia attraverso output verificati, iterazioni corrette, perimetri testati. Il controllo non è inefficienza, ma è il costo necessario di un sistema che non può essere Accountable per sé stesso.
Il controllo non può probabilmente essere mai eliminato del tutto. Può essere ridotto, può essere spostato, può essere automatizzato in parte, ma la catena di accountability deve sempre terminare in una persona. Non in un sistema. Non in un processo. In qualcuno che può rispondere.

Questo è il motivo per cui introdurre qualsiasi strumento senza aver prima definito la governance dell’autonomia non è solo inefficiente. È un rischio che l’organizzazione sta assumendo senza averlo nominato (soprattutto in una narrazione dove adesso possiamo fare più cose: facciamo più cose, ma come le controlliamo senza diventare controllori a tempo pieno?).

Da dove si parte

Da tre domande, in quest’ordine.

La prima: qual è il problema che voglio risolvere? Torniamo sempre allo SMART: Specifico, misurabile, collegato a un risultato atteso. Se la risposta è vaga, il lavoro è ancora a monte e prima di rispondere serve la capacità di descrivere il proprio lavoro con sufficiente precisione dichiarativa.

Senza quella, il problem solving rimane procedurale: si agisce per intuizione, non per definizione ⁸ .

La seconda: chi è Accountable del risultato, e come lo verifico? Senza questa risposta l’organizzazione sta delegando responsabilità a qualcuno o qualcosa che non può tenerla.

La terza: come organizzo il lavoro per evitare che l’orchestrazione frammenti l’attenzione più di quanto lo strumento la liberi? Il guadagno di efficienza si perde se il context switching diventa strutturale.

L’AI è uno strumento potente, ma il problema che trovo spesso negli assessment non è mai lo strumento: è sempre la struttura che manca prima dello strumento e la struttura, come quasi sempre, non è un problema tecnologico ⁹.

Altri approfondimenti interessanti:

Report Deloitte – State of AI in the Enterprise – Solo il 21% delle imrpese ha pensato/impostato una governance per gli agenti AI

Riflessione di Sara Malaguti /Flowerista) – Cosa stai difendendo davvero? Ovvero, la Struttura