# Andrea Margiovanni — Full content export > Scrivo di architetture software, intelligenza artificiale e di compliance europea — AI Act, sovranità digitale, sourcing — vista come architettura da progettare, non come ostacolo da aggirare. **Author:** Andrea Margiovanni — Product & Technology Strategist at Oltrematica **Site:** https://margiovanni.it **License:** Content is freely citable. Please attribute to the author with a link to the original URL. **Generated:** 2026-05-29 This file contains every published essay on the site in plain markdown, for LLM ingestion and offline reading. The site is bilingual (IT/EN); articles are grouped by language. Each article includes its canonical URL, publication date, tags, and the full body stripped of HTML/Liquid. --- ## Italiano --- # L'umano è una posizione - **URL:** https://margiovanni.it/it/blog/umano-e-una-posizione/ - **Pubblicato:** 2026-05-27 - **Tag:** Intelligenza Artificiale, AI Act, Sovranità Digitale, Compliance, Etica, Filosofia Della Tecnica - **Tempo di lettura:** 10 min > Sono ateo, vengo dalla filosofia, lavoro nella compliance europea. La prima enciclica di Leone XIV sull'intelligenza artificiale non l'ho firmata, l'ho discussa. E ci ho trovato un lessico che a Bruxelles ancora manca. ## Vengo dalla filosofia, e sono rimasto ateo {: #filosofia-ateo } Vengo dalla filosofia. Anni in cui leggevo Garin e Cassirer la mattina e Foucault e Bobbio il pomeriggio, dove anti-clericalismo e umanesimo coincidevano in modo così naturale che neanche bisognava argomentarlo. Da allora ho conservato due convinzioni che continuo a considerare il presupposto di qualunque discorso pubblico serio. La prima è che le religioni storiche siano, nella stragrande maggioranza dei casi, dispositivi anti-umanistici, perché la difesa dell'umano richiede una libertà che le strutture clericali non hanno mai potuto concedere se non a denti stretti, sotto pressione, e quasi sempre in ritardo. La seconda è che l'umanesimo, quello vero, quello che parte da Garin e arriva al diritto continentale del Novecento passando per la Costituzione italiana e per la dichiarazione del 1948, sia un terreno strutturalmente laico, in cui le tradizioni religiose entrano come ospiti, e quando vogliono prendersi tutto lo spazio o si confondono o tradiscono se stesse. Sono giudizi che ho continuato a praticare senza grandi turbamenti mentre leggevo gli allegati tecnici dell'AI Act, le ultime bozze applicative del Cyber Resilience Act, le indicazioni EDPB sui modelli DPIA per i sistemi ad alto rischio. Lavoro nella compliance europea, parlo ogni giorno con clienti di pubblica amministrazione e sanità, e l'unica metafisica che mi serve di solito è quella, già abbastanza complicata, del considerando 71 del GDPR. Poi è uscita *Magnifica Humanitas*, e qualcosa si è mosso. ## Non un'esortazione, un trattato sull'umano {: #trattato } Ho impiegato due sere a leggerla. Non è breve, e non si finge breve. È un testo lungo, duecentoquarantacinque paragrafi distribuiti in cinque capitoli, con un apparato di duecentoventiquattro note, scritto in quella prosa curiale che a tratti rallenta e a tratti accelera in modo quasi sorprendente. Mi aspettavo l'ennesima esortazione moraleggiante sull'intelligenza artificiale, quel genere di documento che cerca di fare il pari con un convegno di settore e finisce per arrivare in ritardo di due anni e con mezza tesi in meno. Mi sono ritrovato davanti a qualcosa di diverso. Non un'esortazione, ma un trattato. Non sull'IA, ma sull'umano, con l'IA usata come pietra di paragone per ridire chi siamo. È esattamente la cosa che il dibattito tecnico secolare fatica a produrre, perché presuppone un livello di fondazione concettuale che siamo abituati a delegare alle leggi, sperando che le leggi se la cavino da sole. ## La sussidiarietà non è nata a Bruxelles {: #sussidiarieta } Il problema è che le leggi non se la cavano da sole. Lo vedo benissimo quando provo a spiegare a un cliente perché la sussidiarietà digitale, quella che ispira buona parte dell'architettura del Data Act e dei capitoli operativi dell'AI Act, non è un'invenzione di Bruxelles ma un principio con quasi un secolo di elaborazione alle spalle. Lo formulava Pio XI nel 1931 dentro la *Quadragesimo anno*, e da allora ha attraversato la giurisprudenza, l'ordoliberalismo tedesco, i lavori di Adenauer, fino a depositarsi nell'articolo 5 del Trattato sull'Unione europea. Quando un regolatore europeo scrive che certe decisioni vanno prese al livello più vicino possibile alle persone interessate, sta usando una grammatica che è nata altrove, non a Bruxelles. E quando io provo a difendere quella scelta di fronte a un committente, mi accorgo che mi mancano le parole giuste per spiegarla. Magnifica Humanitas, su questo punto, mi ha restituito un lessico. ## La destinazione universale dei beni, applicata agli algoritmi {: #destinazione-beni } La cosa che mi ha colpito non è la novità delle idee. Le idee dell'enciclica sono in larga parte note. Mi ha colpito il modo in cui le tiene insieme, perché sono esattamente le idee che mi servono ogni volta che devo discutere di compliance senza ridurla a un esercizio burocratico. La destinazione universale dei beni, per esempio, applicata al paragrafo 67 ai brevetti, agli algoritmi, alle piattaforme, alle infrastrutture e ai dati. Non è una posizione che si possa archiviare come prepolitica o utopica. È esattamente lo stesso problema che il Data Governance Act prova a inquadrare con il concetto di altruismo dei dati, che il DMA insegue con le regole sui gatekeeper, che la futura interpretazione delle banche dati sanitarie europee si troverà ad affrontare quando lo European Health Data Space entrerà in regime. Il fatto che un dato sia tecnicamente raccoglibile e proprietariamente assegnabile non significa che la sua destinazione finale sia legittimamente privata. È un'affermazione operativa, non una predica. ## Sopra il cittadino non c'è più solo lo Stato {: #sopra-il-cittadino } Lo stesso vale per la sussidiarietà al paragrafo 71. L'enciclica fa qualcosa che pochi documenti tecnici hanno il coraggio di fare in modo esplicito: ricorda che, nel contesto digitale, il livello superiore rispetto al cittadino non è più lo Stato, ma il grande attore economico che esercita un potere di fatto sulle condizioni della vita comune. Non è una metafora. Quando una piattaforma decide cosa è visibile e cosa è oscurato, quando un sistema di scoring algoritmico stabilisce chi accede al credito e chi no, quando un modello di linguaggio diventa l'interfaccia dominante per certi tipi di servizio, si esercita un potere che la teoria classica della sussidiarietà non aveva previsto in quei termini. Riconoscerlo formalmente, dentro un documento ufficiale di questa autorevolezza, sposta il piano della discussione. Smette di essere un'opinione di nicchia. Diventa una posizione fondata che si può citare in una memoria difensiva, in una valutazione di impatto, in un parere a un committente che chiede perché si sta facendo tutta questa fatica per implementare un sistema di logging trasparente. ## Dal giudizio al calcolo, mezzo secolo dopo Weizenbaum {: #giudizio-calcolo } C'è poi un passaggio che non mi aspettavo, e che è probabilmente il pezzo più forte del documento intero. Si trova al paragrafo 198, nel capitolo sulla cultura della potenza, là dove l'enciclica affronta la guerra, ma vale per tutto. *Il giudizio morale non è riducibile a un calcolo, poiché implica coscienza, responsabilità personale e riconoscimento dell'altro come persona. Perciò non è lecito affidare a sistemi artificiali decisioni letali o comunque irreversibili.* Due frasi che contengono almeno mezzo secolo di pensiero critico sul calcolo automatico. Joseph Weizenbaum, l'ingegnere del MIT che nel 1966 aveva costruito ELIZA e che pochi anni dopo si era spaventato vedendo come la sua segretaria ci parlava in confidenza, scriveva nel 1976 un libro il cui sottotitolo era *From Judgment to Calculation*. Dal giudizio al calcolo. Tutto il libro era una difesa di quella preposizione, *al*, che segna una perdita. Weizenbaum sosteneva che ci sono compiti che i computer non possono e non devono svolgere, anche se tecnicamente potrebbero svolgerli, perché coinvolgono il riconoscimento dell'altro come persona, e quel riconoscimento non è un problema di rappresentazione interna. È un atto. Magnifica Humanitas, mezzo secolo più tardi, dice esattamente la stessa cosa con un vocabolario diverso. Non è una coincidenza. È che certe verità antropologiche tornano fuori quando le condizioni materiali le costringono a tornare fuori, e oggi le condizioni materiali sono quelle del decision making automatizzato applicato a vite umane reali. ## Le nuove schiavitù e il colonialismo dei dati {: #nuove-schiavitu } L'enciclica si spinge oltre. Al paragrafo 173 nomina cose che il dibattito mainstream sull'IA preferisce lasciare nei margini delle conference dei vendor. Cita esplicitamente l'etichettatura dei dati, la moderazione dei contenuti, l'estrazione delle terre rare, il lavoro minorile nelle miniere. Le chiama nuove schiavitù, e non per retorica. Le chiama così perché stanno effettivamente alimentando, in modo invisibile per chi usa una API a sessanta centesimi ogni milione di token, l'intera economia delle architetture transformer. Al paragrafo 178 introduce un concetto che gli studiosi di tecnopolitica usano da almeno cinque anni ma che fa una certa impressione vedere usato in un documento pontificio: colonialismo dei dati. La frase chiave è che chi possiede i dati sanitari di intere popolazioni, oggi raccolti spesso sotto il segno dell'aiuto, della ricerca o dell'innovazione, possiede in realtà una leva strutturale sul futuro. È una descrizione esatta del rischio strategico che pesa su molti contesti africani, asiatici, latinoamericani, e che dovrebbe pesare sulle nostre scelte di committenza quando decidiamo dove ospitare un dato, da quale fornitore comprare l'addestramento di un modello, a quale ecosistema delegare l'analisi epidemiologica di una regione. Non è una sensibilità new age. È una valutazione di impatto. ## Un trattato che regge come fonte per una DPIA {: #fonte-dpia } A questo punto della lettura mi sono fermato. Stavo annotando passaggi a margine come se preparassi una memoria tecnica, e mi sono reso conto che era esattamente quello che stavo facendo. L'enciclica funziona benissimo come trattato antropologico, ma funziona anche come fonte secondaria per un argomento di compliance. È un testo che può essere citato in una DPIA per giustificare una valutazione restrittiva. È un testo che può essere allegato a un parere su un'integrazione di IA in ambito sanitario. Non perché abbia valore giuridico, ovviamente, ma perché fornisce quella cornice di principio che spesso manca quando si discute di scelte tecniche, e che quando manca si traduce in decisioni prese sull'unica base del costo opportunità. Chi lavora in compliance europea sa cosa intendo. C'è una zona grigia, tra il considerando e l'articolo, tra l'intenzione del legislatore e la lettera della norma, dove il tecnico ha bisogno di appoggiarsi a qualcosa di solido per spiegare perché una certa interpretazione è preferibile a un'altra. Avere un testo di questa portata, scritto da una posizione esterna al sistema tecnico ma capace di parlarne dall'interno, è un asset che è stupido non usare per pregiudizio. ## Non è una conversione, e non è un testo perfetto {: #non-conversione } Mi rendo conto che chi mi conosce potrebbe trovare strano leggere queste righe. Non sto annunciando una conversione, e non sto neanche dicendo che il documento è perfetto. Ci sono punti in cui l'enciclica scivola, soprattutto quando entra nel terreno bioetico e della famiglia, dove la mia distanza personale resta integra. Ci sono passaggi in cui il tono pastorale prende il sopravvento sulla precisione concettuale, e dove avrei voluto meno carità retorica e più strumenti di analisi. Non è un testo che si firma, è un testo che si discute. Ma è il tipo di discussione che a me, da ateo che lavora sulla regolazione europea della tecnica, serve oggi più di quanto serviva ieri. E credo serva, allo stesso modo, a chi sta provando a costruire un'industria tecnologica europea diversa da quella che ci arriva da San Francisco o da Hangzhou, perché diversa significa fondata su qualcosa, e qualcosa, in questa fase storica, non si può improvvisare. ## Disarmare {: #disarmare } Al paragrafo 110 c'è una parola che mi ha fatto sorridere. *Disarmare*. L'enciclica dice di voler disarmare l'IA, e specifica subito che disarmare non significa rinunciare. Significa sottrarla ai monopoli e alla logica della competizione, renderla discutibile e contestabile, restituirla alla pluralità delle culture umane. È una parola politica, non religiosa. È esattamente la parola che a Bruxelles non si riesce ancora a pronunciare, perché Bruxelles è ancora ostaggio del realismo che presume la corsa agli armamenti come dato naturale. Una corsa che ha smesso di essere militare per diventare cognitiva, come l'enciclica nota con notevole lucidità, ma che mantiene la stessa logica di fondo. Il fatto che a pronunciarla per primo, in un documento ufficiale di questa diffusione, sia stato il Vaticano e non un commissario europeo, dice qualcosa sullo stato del nostro dibattito pubblico. Non è una buona notizia, ma è una notizia da cui partire. ## Tre cose che prendo a prestito {: #tre-cose } Chiudo con una nota che non c'entra niente con la teologia. Quando si legge un testo prodotto dentro una tradizione che non ci appartiene, ci sono due strade. Una è quella della diffidenza preventiva, che consiste nel chiedere al testo di tradire la propria origine prima di accettare anche solo di sentirlo. L'altra è quella del prestito, che consiste nel prendere quello che serve, lasciare quello che non serve, e tornare al proprio lavoro con un attrezzo in più. Da ateo, sento di poter prendere a prestito da *Magnifica Humanitas* almeno tre cose. Il riconoscimento esplicito che il giudizio morale non è automatizzabile, e che chi prova ad automatizzarlo sta facendo un'operazione politica, non tecnica. La nominazione delle filiere invisibili che alimentano l'economia digitale, che è il presupposto per qualsiasi richiesta seria di due diligence. E quella parola, *disarmare*, che vorrei vedere applicata, nei prossimi anni, ai testi normativi che mi capiterà di leggere per lavoro. Il resto, chi ci tiene, lo discuta nei luoghi adatti. **A me, oggi, basta avere un trattato in più sul comodino, e qualche pagina ben scritta da rileggere quando un committente mi chiederà perché in fondo, dopo tutto, mi sto prendendo la briga di fare le cose per bene.** --- # Dodici mestieri in cerca di mercato - **URL:** https://margiovanni.it/it/blog/dodici-mestieri/ - **Pubblicato:** 2026-05-13 - **Tag:** AI Act, Intelligenza Artificiale, Compliance, Normative Europee, Mercato IT, Lavoro - **Tempo di lettura:** 6 min > Il primo standard nazionale europeo sui profili professionali dell'AI è uscito il 30 aprile. Vale la pena prenderlo sul serio, e vale anche la pena diffidarne nel modo giusto. ## La norma arriva il 30 aprile 2026 {: #norma-30-aprile } La prima reazione alla pubblicazione della UNI 11621-8, lo standard italiano che definisce i dodici profili professionali dell'intelligenza artificiale, dovrebbe essere il sospetto. Standardizzare i mestieri di un campo che cambia ogni sei mesi è un esercizio quasi paradossale, e farlo prima del resto d'Europa significa assumersi il rischio di sbagliare per primi. La norma è arrivata il 30 aprile 2026, firmata da UNINFO con il coordinamento del Dipartimento per la Trasformazione Digitale. L'aggancio normativo va al Regolamento UE 2024/1689, cioè l'AI Act, e alla Legge 132/2025 sull'IA. La Legge 4/2013 sulle professioni non regolamentate fa da scivolo per la certificazione. ## Una parola che cercava un metro dal 2 febbraio {: #parola-metro } Per chi lavora di compliance ogni giorno è la chiusura di un cerchio rimasto aperto dal 2 febbraio 2025. Quel giorno l'articolo 4 dell'AI Act ha imposto a fornitori e deployer di garantire un livello sufficiente di alfabetizzazione del personale, senza spiegare cosa significasse, esattamente, l'aggettivo sufficiente. Negli ultimi mesi, mentre lavoravamo a progetti di compliance per clienti in settori ad alta regolazione, quella parola tornava in ogni conversazione come una domanda senza risposta. Nessun kit documentale o template DPIA riusciva a fissarne il significato senza ricorrere a circonlocuzioni. Cosa significa, esattamente, "competenze sufficienti"? Quando una richiesta del cliente è ragionevole, e quando è una pretesa che non ha ancora un metro? La UNI 11621-8 quel metro lo offre, lo offre in italiano, con nomi che il buyer di un'azienda sanitaria o di un assessorato regionale può leggere senza tradurli. ## Dodici profili, dal CAIO al ricercatore {: #dodici-profili } I dodici profili coprono lo spettro dalla governance alla ricerca. Si va dal Chief AI Officer all'AI Research Scientist. Per ogni profilo la norma specifica missione e compiti, oltre a una mappa delle competenze richieste con il livello atteso e gli indicatori di prestazione associati. La metodologia è quella consolidata della UNI 11621-1, e l'ancoraggio è all'e-Competence Framework europeo, lo UNI EN 16234-1. Tecnicamente il lavoro è solido, e questo è importante dirlo prima di passare ai problemi. ## La materia che si codifica è ancora mobile {: #materia-mobile } I problemi cominciano dalla materia che la norma prova a fissare. Una professione si codifica quando ha raggiunto un grado di stabilità sufficiente, e l'AI di oggi non lo ha. Il Prompt Engineer, presente nella lista come profilo separato, è già un caso interessante. Quando esisteva come ruolo distinto, ha avuto vita breve, ed è stato rapidamente assorbito dagli sviluppatori e dai product manager che lavorano direttamente con i modelli generativi. Tenerlo come profilo dedicato significa rincorrere una pratica che si è già evoluta altrove. Lo stesso vale, in misura diversa, per la separazione netta tra Data Scientist e Machine Learning Engineer, due ruoli che nella pratica reale si sovrappongono ampiamente. I confini delle figure professionali codificate sono molto più netti dei confini delle competenze che le persone effettivamente esercitano. Un buon Data Scientist tocca l'ML engineering, e un ML engineer competente sa muoversi nella pipeline dei dati. Quando un AI Security Specialist non capisce i modelli alla radice, smette di essere un professionista della sicurezza e diventa un revisore di documenti. ## Chi scrive lo standard, e perché {: #chi-scrive } C'è poi una questione più sottile, e riguarda l'origine delle norme di profilo professionale in Italia. Sono prodotte da commissioni in cui siedono enti di certificazione e fornitori di formazione, oltre alle associazioni di categoria. Soggetti legittimi, e tutti con un interesse economico nel risultato finale. Questo non rende lo standard meno utile, cambia il modo in cui dovrebbe essere letto. Sotto la veste tecnica c'è la costruzione di un mercato. Il mercato della certificazione professionale e della formazione accreditata. I percorsi ITS Academy si stanno allineando in queste settimane, e gli enti certificatori stanno preparando i propri schemi. La Legge 4/2013 fornisce l'aggancio, chi può certificare un profilo professionale guadagna da quella certificazione. La domanda non è se il sistema sia legittimo, lo è. La domanda è cosa stiamo davvero comprando quando spendiamo per certificare un Chief AI Officer interno. ## L'effetto di sostituzione, come per il DPO {: #effetto-sostituzione } Una terza cautela riguarda l'effetto di sostituzione, che è probabilmente il rischio più serio. Avere profili UNI-conformi non significa avere governance AI competente. La storia recente del GDPR è piena di organizzazioni che avevano un DPO certificato e processi disastrosi, perché il DPO era una casella amministrativa, non una funzione operativa. Lo stesso può succedere con il Chief AI Officer e con il Security Specialist. La compliance per checklist produce comfort organizzativo e poca sicurezza reale. Se la UNI 11621-8 verrà letta come adempimento documentale, avremo aziende con tabelle pulite e sistemi AI fragili. Se verrà letta come scheletro intorno a cui costruire pratica vera, avremo qualcosa di utile. ## Una traiettoria che abbiamo già visto {: #traiettoria } Detto tutto questo, la pubblicazione della norma vale la pena di essere presa sul serio. Per un motivo che ha poco a che fare con la tecnica, e molto con il timing del mercato regolato. Lo schema, in Italia, lo abbiamo già visto. La Strategia Cloud Italia del 2021 ha generato un framework di classificazione dei dati e dei servizi PA. Quel framework è poi diventato regolamento ACN nel 2022-2023. Il catalogo dei servizi cloud qualificati è infine entrato nelle procedure di acquisto della PA, fino al Consip MEPA. Le clausole sulla sicurezza dei servizi cloud, all'inizio vaghe, sono diventate requisiti tecnici verificabili e condizioni di partecipazione. Chi è arrivato dopo ha competuto da fornitore generico contro fornitori già qualificati, e ha perso gare significative. La UNI 11621-8, applicata alla cornice dell'AI Act, segue una traiettoria analoga. Lo standard parte come riferimento volontario e finisce nei capitolati di gara. Il passaggio per gli atti di indirizzo del Dipartimento è quasi un dettaglio amministrativo. La finestra utile è quella che si apre adesso, e si chiude quando il primo capitolato significativo cita la norma. ## Dentro un kit di compliance multi-framework {: #kit-compliance } Per chi, come noi a Oltrematica, lavora di compliance multi-framework, lo standard è prima di tutto uno strumento di documentazione difendibile. La matrice RACI di un progetto AI ad alto rischio, costruita sopra i profili UNI, diventa un'evidenza che regge in sede di audit. Anche il piano di formazione interno aziendale, se mappato sui profili, smette di essere un costo amministrativo e diventa parte integrante del programma di gestione del rischio AI. La forma che stiamo dando ai nostri kit documentali interni assorbe lo standard senza fatica, perché parla la stessa lingua dei framework che già usiamo, dal GDPR al Cyber Resilience Act. ## Una mappa imperfetta, ma una mappa {: #mappa-imperfetta } C'è una linea di lavoro più interessante della pura conformità, e probabilmente meno redditizia nel breve. Lo standard è una **occasione di intelligibilità interna**. Permette alle organizzazioni che adottano AI di parlarne con un vocabolario condiviso, prima ancora che con i regolatori o con gli enti certificatori. È un vocabolario imperfetto, in parte datato e costruito attorno a interessi economici riconoscibili. Ma è il primo vocabolario disponibile, e la sua imperfezione è inferiore alla sua utilità. La questione vera, quella che deciderà se la UNI 11621-8 sarà una buona norma o una cattiva norma, non è scritta nel testo. Si scriverà nei prossimi mesi, nelle interpretazioni che le organizzazioni le daranno, e nei capitolati che la useranno per filtrare i fornitori. Nel frattempo, **vale la pena leggerla per quello che è**. Una mappa imperfetta del territorio che stiamo già attraversando, che almeno propone una toponomastica condivisa per non perderci tutti allo stesso modo. --- # La sera dico no, la mattina lavoro con gli stessi strumenti - **URL:** https://margiovanni.it/it/blog/gli-stessi-strumenti/ - **Pubblicato:** 2026-05-08 - **Tag:** Design Responsabile, Genitorialità, Attention Economy, Dipendenza Digitale, Etica - **Tempo di lettura:** 8 min > La sera dico no a mio figlio di tre anni che vuole il tablet ancora un pochino. Lo dico per un motivo molto specifico, e da quel motivo nasce un libro gratuito. ## Le otto di sera {: #otto-di-sera } Le otto di sera, più o meno. La cena è finita da poco, i piatti nel lavandino, il tavolo ancora da sparecchiare. Mio figlio ha tre anni e sta cercando di convincermi a lasciargli il tablet ancora un pochino, che nella sua grammatica del tempo significa un periodo compreso tra i venti minuti e l'infinito. Dico no. Non con rabbia, non con un discorso pedagogico. Dico no con la stanchezza precisa di chi ripete la stessa scena ogni sera sapendo che la prossima sarà uguale. Fin qui è una scena che qualunque genitore riconosce. Potrebbe succedere in qualunque casa. ## So come funziona quel tablet {: #so-come-funziona } La differenza è il motivo per cui dico no. Non è perché ho letto un articolo allarmante sugli schermi, o perché seguo un pediatra su Instagram che consiglia il digital detox, o perché ai miei tempi si giocava fuori. Il motivo è che so come funziona quel tablet. Non in senso generico, non «la tecnologia fa male ai bambini». Lo so in senso tecnico. So come è fatto il software che ci gira sopra. So quali decisioni di design hanno preso le persone che lo hanno costruito, e so perché le hanno prese. So cosa succede quando mio figlio tocca lo schermo, quale logica decide cosa mostrargli dopo, e quale obiettivo quella logica sta cercando di raggiungere. Quell'obiettivo non è il suo benessere. Questo lo so perché è il mio mestiere. Costruisco software da quasi vent'anni. Non lavoro per le grandi piattaforme social, non ho mai avuto un ufficio a Menlo Park o a Mountain View. Faccio cose molto più noiose: sistemi gestionali, piattaforme per la formazione, applicazioni che aiutano le aziende a organizzare dati. Roba che non finirebbe mai in un'inchiesta giornalistica perché non è abbastanza interessante. Si potrebbe obiettare che allora il problema non mi riguarda, che le tecniche di cattura dell'attenzione sono cose da TikTok, da Meta, da ByteDance, e che tra una piattaforma social e un sistema gestionale c'è la differenza che passa fra una pista da Formula 1 e una strada di campagna. Sarebbe un'obiezione sensata se non fosse falsa. Le tecniche per tenere le persone incollate a uno schermo non sono un segreto industriale. Sono una disciplina condivisa, documentata, insegnata nelle conferenze a cui vado, discussa nei canali Slack dove passo le mie giornate lavorative. Sono patrimonio comune di chiunque costruisca prodotti digitali. Le leve che TikTok usa per far restare un quindicenne incollato allo schermo sono parenti strette delle leve che userei per aiutare un cliente ad aumentare il tempo medio di sessione su una piattaforma di formazione aziendale. Cambia il contesto, cambia l'intensità, cambia il tipo di utente. Gli strumenti di base si chiamano allo stesso modo, si insegnano nelle stesse conferenze, si ritrovano negli stessi libri di design. La sera, a casa, leggo la planimetria del tablet di mio figlio come si legge il progetto di un edificio: questo serve a questo, quello serve a quello, qui il design ti spinge in questa direzione, lì ti impedisce di andare in quell'altra. La mattina lavoro con gli stessi strumenti di chi quella planimetria l'ha disegnata. Da questa frattura nasce un libro che ho scritto e che ho deciso di rendere disponibile gratuitamente. Si chiama *I tuoi figli non sono i tuoi utenti*, e prova a fare una cosa molto specifica: trasferire un pezzo di sapere professionale a chi quel sapere non lo ha, perché la differenza fra averlo e non averlo, quando si tratta dei propri figli, è enorme. ## Skinner, il piccione, il feed {: #skinner-piccione-feed } Per dare un'idea di che tipo di sapere parliamo prendo un solo esempio fra molti, quello che secondo me è il più importante e il meno conosciuto. Tra gli anni Quaranta e Cinquanta lo psicologo B. F. Skinner fece una serie di esperimenti con dei piccioni in una gabbia. Se il piccione picchiava un disco col becco otteneva del cibo. Skinner scoprì una cosa interessante: se il cibo arrivava ogni volta che il disco veniva picchiato, il piccione lo picchiava quando aveva fame e basta. Se invece il cibo arrivava in modo imprevedibile, ogni tre volte, ogni cinque, ogni due, il piccione cominciava a picchiare il disco continuamente, in modo compulsivo, anche quando non aveva fame. La ricompensa variabile, quel meccanismo lì, è il motore psicologico delle slot machine. È anche il motore psicologico del feed di un social network, e non per analogia poetica ma per progettazione esplicita. Quando vostro figlio scorre Instagram per venti minuti, la maggior parte dei contenuti che vede è banale, ininfluente, dimenticabile. Ogni tanto però arriva qualcosa di buono, qualcosa che lo fa ridere, una notizia che gli interessa, una foto che lo riguarda. Non sa quando arriverà. Sa solo che se continua a scorrere prima o poi arriva. Il suo cervello sta facendo, in versione elegante e digitale, esattamente quello che faceva il piccione di Skinner. ## Random personalizzato {: #random-personalizzato } C'è una differenza importante che peggiora le cose, e che chi non lavora nel settore di solito non considera. Le slot delle sale giochi distribuiscono le vincite in modo casuale, perché non sanno nulla del giocatore. L'algoritmo di un social network sa cosa vi piace, su cosa vi fermate un secondo di più, cosa vi indigna, cosa vi commuove. Usa queste informazioni per calibrare la distribuzione dei contenuti in modo da massimizzare l'effetto del rinforzo variabile su di voi, specificamente. Non è più random, è random personalizzato, paradossalmente più efficace del puro caso perché mantiene l'imprevedibilità (non sapete quando arriverà il contenuto buono) aggiungendo la rilevanza (quando arriva, è calibrato sui vostri interessi). Per un cervello adolescente, la cui corteccia prefrontale è ancora in costruzione, questo meccanismo è particolarmente potente. ## Gli altri meccanismi {: #altri-meccanismi } La ricompensa variabile è uno dei meccanismi che il libro descrive. Ce ne sono altri: lo scroll infinito che elimina i punti di decisione, l'autoplay che rende il «continua a guardare» il default, le notifiche calibrate per produrre una risposta fisica involontaria, i dark pattern che rendono semplice iscriversi e difficile uscire. Sono tutti documentati, tutti insegnati, tutti applicati senza distinzione di età anche ai prodotti che vostro figlio ha sul telefono. Non c'è niente di clandestino in tutto questo. È letteratura aperta, accessibile a chiunque voglia leggerla. Il problema è che chi la legge è quasi sempre chi quei prodotti li costruisce, raramente chi li subisce. ## Cosa sa chi costruisce, e cosa fa con i propri figli {: #chi-costruisce-sa } Da qui nasce la domanda che dà il titolo al libro, e che è la più semplice che io conosca su tutta la faccenda. Le scuole private della Silicon Valley che vietano gli schermi in classe non sono una leggenda metropolitana. Tim Cook ha dichiarato pubblicamente che non avrebbe permesso a suo nipote di usare i social media. Sean Parker, primo presidente di Facebook, ha descritto il design della piattaforma come consapevolmente orientato a sfruttare una vulnerabilità della psicologia umana, e ha aggiunto che solo Dio sa cosa stia facendo al cervello dei nostri figli. Chamath Palihapitiya, ex vicepresidente della crescita utenti di Facebook, ha detto pubblicamente che i suoi figli non avevano il permesso di usare quella roba. Le testimonianze di insider che ammettono di proteggere i propri figli dai prodotti che hanno contribuito a costruire non sono nascoste, non sono ambigue, non sono scarse. Basta cercarle. L'osservazione che faccio nel libro, e che faccio anche qui, è più piccola e più ordinaria di queste dichiarazioni famose. Tra i colleghi che lavorano nel software con cui parlo regolarmente, quelli che hanno figli sono quasi unanimi su una cosa: regole più restrittive sull'uso del telefono rispetto alla media dei genitori non-tech, accesso ritardato ai social media, controllo attento di quali app vengono installate, conversazioni con i figli su come funzionano le notifiche e perché. Non è un dato scientifico, è un'osservazione aneddotica. Ma è coerente, è ricorrente, e la sua stessa esistenza dimostra il punto: chi conosce il meccanismo si comporta diversamente. Se le persone che costruiscono queste cose ne tengono lontani i propri figli, cos'è che sanno e noi no? ## Asimmetria informativa, e il libro {: #asimmetria-libro } Non è una domanda retorica. Non c'è una stanza segreta dove i dirigenti del tech pianificano come danneggiare i bambini del mondo. C'è qualcosa di molto più banale e molto più difficile da combattere, che gli economisti chiamano asimmetria informativa. Da una parte c'è chi capisce come funzionano i prodotti digitali, come sono progettati, quali leve psicologiche usano e perché. Dall'altra c'è chi li usa, e li fa usare ai propri figli, senza avere quelle informazioni. Questa asimmetria esiste da quando esistono le industrie. I chimici delle aziende alimentari sanno cose sul cibo che i consumatori non sanno. Gli ingegneri automobilistici sanno cose sulle auto che i guidatori non sanno. La differenza è che in quei settori, nel tempo, si è costruito un sistema di etichette, standard di sicurezza, obblighi di trasparenza. Per i prodotti digitali quel sistema è ancora largamente da costruire, e nel frattempo i nostri figli ci passano dentro ore ogni giorno. Il libro prova a colmare quel divario. Non tutto, sarebbe una pretesa eccessiva. Una parte. Spiega come funzionano i meccanismi principali in un linguaggio che non richiede competenze tecniche, racconta cosa sappiamo e cosa stiamo ancora cercando di capire sugli effetti che hanno sui nostri figli, e prova a delineare cosa possiamo fare ciascuno nel proprio ruolo: come genitori, come cittadini, come utenti, e anche, per chi come me lavora nel settore, come persone che costruiscono questa roba. **Non è un manuale di sopravvivenza genitoriale, e non è un libro contro la tecnologia. È un tentativo di trasferire una piccola parte di sapere professionale a chi normalmente non lo riceve.** **Il libro è gratuito**, in epub e pdf, e si trova su [ebook.margiovanni.it](https://ebook.margiovanni.it). Se lo leggete e vi è utile, la cosa che vi chiedo è di passarlo a un altro genitore. Quel passaggio fra due persone che si conoscono vale più di qualunque algoritmo di raccomandazione, ed è esattamente il tipo di cosa che i meccanismi di cui parla il libro non sanno fare. --- # La clessidra della compliance - **URL:** https://margiovanni.it/it/blog/clessidra-della-compliance/ - **Pubblicato:** 2026-05-07 - **Tag:** Compliance, Mercato IT, Advisory IT, Sovranità Digitale, ACN - **Tempo di lettura:** 8 min > Mappa del mercato italiano della compliance vista da dentro: l'advisory in alto, le piattaforme in basso, il middle layer schiacciato fra i due. E la specificità tutta italiana — ACN — che cambia le regole. ## Una mappa fatta da dentro {: #mappa-da-dentro } Un grande cliente del settore regolato ci ha chiesto, qualche mese fa, di mettere in sicurezza la piattaforma. La richiesta era posta nei termini consueti, sicurezza informatica e audit di conformità. Quello che alla fine si sono portati a casa è una DPA Appendice 2 articolata in diciannove sezioni, una gap analysis tecnica, una roadmap di remediation, una formalizzazione della catena di sub-processor scritta per reggere a un controllo serio. Non c'era una linea di codice nuova in quello che gli abbiamo consegnato, e nemmeno una piattaforma da licenziare. Carta strutturata e posizionamento contrattuale, prodotti in modo che fossero difendibili davanti a chiunque venisse a chiedere conto. La cosa interessante è che questo non era un'eccezione, era la regola che si è andata stabilendo nei nostri ultimi dodici mesi di lavoro. Qualcuno potrebbe sostenere che la mappa di questo mercato esiste già e che basta leggere il Magic Quadrant di Gartner per i GRC tools, oppure consultare i report di Forrester sulle piattaforme di privacy management. Sarebbe una scorciatoia comoda e parzialmente fuorviante. Quei documenti fotografano il mercato globale delle piattaforme, dove ci sono ServiceNow, MetricStream, OneTrust, Drata, e Optro che ha appena rinominato AuditBoard nel marzo scorso. Il mercato italiano della compliance ha invece una struttura sua, plasmata dall'Agenzia per la Cybersicurezza Nazionale, dal recepimento di NIS2 con il decreto legislativo 138 del 2024, dal peso dominante della pubblica amministrazione sul totale degli acquisti, dalla velocità irregolare con cui le direttive europee vengono operativizzate dai clienti finali. Per leggerlo serve una mappa fatta da dentro. ## In alto: l'advisory specialistica {: #strato-alto } Mi sembra utile guardarlo come una clessidra. In alto si è formato uno strato spesso di advisory specialistica. Le Big4, Deloitte, PwC, EY, KPMG, hanno practice GRC che ormai sono indistinguibili nelle proposte commerciali e si fanno concorrenza più sui nomi dei senior partner che sulle metodologie. Accanto a loro, e in alcuni casi a un livello qualitativamente superiore, operano le boutique italiane strutturate. P4I del gruppo Digital360 dichiara oltre centosessanta professionisti sul proprio sito e vende un brand metodologico chiamato Advisory Engine, con un prodotto a catalogo registrato come Compliance360. ICTLC ha consolidato il taglio legal-tech che oggi è di moda, ma quando ha cominciato non lo era. Spike Reply opera dentro il gruppo Reply mantenendo identità riconoscibile, e copre l'intero spettro della cybersecurity e della protezione dei dati con un peso significativo sui dossier financial e manifatturieri. Deda Tech ha scelto la strada del team multidisciplinare, dove legali ed economisti siedono accanto agli ingegneri, e nelle interviste pubbliche dichiara apertamente di non vendere soluzioni tecniche ma fiducia. La frase suona come marketing, e corrisponde al posizionamento reale. Quello che questi soggetti vendono è interpretazione. Non un software che fa qualcosa, ma una persona riconoscibile, capace di tradurre una norma nei termini specifici della tua filiera e di sostenere il tavolo di negoziazione su un Data Processing Agreement con un cloud provider americano senza cedere quello che non si dovrebbe cedere. I margini sono alti e la scalabilità è bassa. La dipendenza dal singolo nome con la barba grigia o con il curriculum accademico è strutturale al modello. La crescita avviene per cooptazione, hiring di nomi pesanti, acquisizioni di studi più piccoli che portano in dote portafogli clienti consolidati. È un meccanismo che assomiglia più al mondo legale che al mondo del software. ## In basso: le piattaforme {: #strato-basso } In basso si è formato lo strato delle piattaforme. Le proiezioni di IntelMarket Research valutano il mercato globale dei GRC platform a 16,7 miliardi di dollari nel 2024 con orizzonte 2032 a 32,8 miliardi e tasso composto del 9,9 per cento, e altre stime danno numeri sensibilmente diversi a seconda del perimetro che includono, ma la direzione è quella. ServiceNow GRC è il default per chi già utilizza ServiceNow per l'IT service management, e questo rappresenta una porzione significativa dell'enterprise italiano. MetricStream copre il segmento delle multinazionali con programmi GRC maturi. OneTrust ha trasformato il GDPR in prodotto e ora si sta riposizionando sull'AI governance. Drata e Vanta automatizzano SOC2 e ISO 27001 per startup e scale-up, con evidenza raccolta in continuo e prezzi SaaS che entrano nel budget di un CTO senza dover passare dal CFO. La parte italiana di questo strato è sottile. Il mercato italiano del software dedicato alla compliance non ha prodotto player di scala internazionale, e i tentativi locali restano confinati a singole verticali o a singoli clienti. ## Il middle layer compresso {: #middle-compresso } Tra questi due strati, dove la clessidra si stringe, si trova il middle layer, e qui sta la dinamica interessante. È lo strato del software custom per la compliance, dei gestionali GDPR fatti su misura, delle piattaforme verticali per ISO 27001 sviluppate da software house italiane di medie dimensioni. Per anni è stato uno strato confortevole. Il cliente non si fidava delle piattaforme americane per ragioni di sovranità del dato, le Big4 costavano troppo per il mid-market, e una software house locale che ti consegnasse il portale GDPR brandizzato era la soluzione naturale. Oggi questo strato è compresso da entrambi i lati simultaneamente. Da sotto perché Drata fa SOC2 a una frazione del costo di un gestionale custom, e le startup non hanno alcun motivo di farsi sviluppare nulla di proprietario per una funzione commodity. Da sopra perché quando il problema diventa serio, una DPIA difendibile o una negoziazione contrattuale con Microsoft che non lasci buchi, il cliente capisce che il software non basta e che gli serve una persona che parli la sua lingua e firmi documenti che reggano. ## ACN, e il mercato dentro al mercato {: #acn-mercato-dentro } Quello che rende la mappa italiana strutturalmente diversa da quella globale è ACN. Il Regolamento unico per le infrastrutture digitali e i servizi cloud, decreto direttoriale 21007 del 27 giugno 2024, in regime ordinario dal primo agosto dello stesso anno, ha creato un mercato dentro al mercato. La pubblica amministrazione può acquistare servizi cloud solo se qualificati QC1, QC2, QC3 o QC4, erogati su infrastrutture adeguate AI1 fino ad AI4, secondo una matrice che lega la classificazione del dato al livello di servizio ammesso. Aruba ha qualificato ai livelli più alti, Polo Strategico Nazionale gestisce i dati classificati come strategici, una manciata di altri provider sta riempiendo le caselle restanti del catalogo. Per i system integrator italiani che lavorano con la PA la scelta concreta diventa binaria. Si rivende il cloud qualificato di qualcun altro accettando margini compressi e un ruolo da implementer, oppure si costruisce un'advisory che orienti il cliente PA nella scelta architetturale capitalizzando la conoscenza del catalogo qualificato come asset distintivo. Quando ho preparato per Pescara Multiservice il proposal di hosting cloud ACN-qualificato basato su Aruba VPC al livello QC3, contro il listino reale ARB-11504-1 di 217,38 euro al mese, la parte di valore che il cliente comprava era il mio lavoro di traduzione tra le sue esigenze applicative e i requisiti del catalogo. L'infrastruttura era commodity. L'interpretazione no. ## Cosa fanno gli system integrator {: #system-integrator } A questo punto si capisce cosa sta succedendo agli system integrator italiani e perché. I grandi, Reply, Engineering, Almaviva, NTT Data Italia, Accenture, hanno già practice GRC interne che competono direttamente con le Big4, e in alcuni casi le hanno superate sui contratti pubblici. Spike Reply è l'esempio canonico di questo movimento, ma non l'unico. I medi come Deda Tech, Var Group, Lutech costruiscono team multidisciplinari e rivendono la propria identità di trusted advisor con un linguaggio nuovo. Il fatturato di implementazione resta significativo, ma il margine alto si trova dove vendi giorni di interpretazione e non sprint di sviluppo. I piccoli si trovano davanti a una scelta più stretta. Possono diventare reseller di qualcun altro perdendo identità. Possono restare implementer specializzati su una verticale dove la profondità di dominio compensa la mancanza di scala. C'è poi una terza strada, più rischiosa delle altre, che è trasformarsi in advisory boutique e vendere conoscenza prima e implementazione dopo, rinunciando a una parte di fatturato certo in cambio di un posizionamento ancora incerto. La maggior parte non sta scegliendo, sta ricevendo passivamente il movimento del mercato. In Oltrematica la scelta l'abbiamo fatta verticalmente, sanità privata e pubblica amministrazione locale, con un investimento serio nella documentazione di compliance come prodotto. Quella DPA, la formalizzazione a cinque livelli per una catena di sub-processor che attraversa tre società dello stesso gruppo industriale, l'analisi del nuovo template DPIA che l'EDPB ha adottato il 10 marzo e pubblicato il 14 aprile in consultazione fino al 9 giugno, sono tutti pezzi di lavoro che cinque anni fa avremmo fatto come accessorio del progetto principale. Oggi sono il progetto principale, e il software viene dopo, ammesso che venga. ## Dove migra il valore, e cosa non so del 2027-28 {: #valore-non-so } C'è una conseguenza di tutto questo che vale la pena rendere esplicita. Il valore nel mercato italiano della compliance sta migrando dai due estremi della clessidra. Le piattaforme internazionali spingono verso il basso il costo dell'evidenza, e questa pressione non si fermerà perché il loro modello di business dipende dall'automazione progressiva. Le boutique advisory e le practice GRC dei system integrator grandi spingono verso l'alto il prezzo dell'interpretazione, e non c'è un'innovazione tecnologica all'orizzonte che riduca il costo di un'opinione firmata da un nome riconoscibile. Quello che resta in mezzo, il software custom per la compliance, ha davanti una biforcazione. Può diventare specialistico dentro una verticale fino al punto di non essere più sostituibile dalle piattaforme generaliste, oppure può essere assorbito dentro un'offerta advisory come capability invece che come prodotto autonomo. Il dato del Politecnico di Milano che stima il segmento cyber e data protection italiano a 2,78 miliardi di euro nel 2025 con crescita del dodici per cento non distingue questi strati nelle sue rilevazioni, e questo è probabilmente uno dei motivi per cui le aziende del middle layer continuano a leggere i numeri come buone notizie quando invece dicono qualcosa di più sottile. La frase più onesta che posso scrivere sulla configurazione di questo mercato nel 2027 e nel 2028, quando il Cyber Resilience Act sarà operativo e l'AI Act in piena enforcement, è che **non lo so**. Mi sembra plausibile che si formi un middle layer riconfigurato, dove strumenti come Claude Code, GitHub SpecKit e i loro derivati permetteranno a software house come la nostra di produrre artefatti di compliance trattati come codice, versionati, testati, generati da specifiche formali tracciabili. È una direzione su cui sto investendo personalmente e che racconto qui sopra da diversi mesi. Ma è anche possibile che il middle layer collassi del tutto e che il mercato italiano si polarizzi su due lati come è successo in altri mercati maturi prima del nostro. Tra dodici mesi questa mappa andrà rifatta. Sarà uno degli esercizi che farò. --- # Lo spettro che siamo - **URL:** https://margiovanni.it/it/blog/lo-spettro-che-siamo/ - **Pubblicato:** 2026-05-05 - **Tag:** Sovranità Digitale, GDPR, AI Act, DSA, Politica Della Tecnologia - **Tempo di lettura:** 24 min > Una lunga ricognizione sulla normativa europea del digitale guardata da fuori — da chi la odia — e una controlettura dall'interno, da chi quelle norme le traduce ogni giorno in oggetti tecnici. ## Lo spettro siamo noi {: #spettro } Uno spettro si aggira per l'Europa, e per una volta non è quello immaginato da Marx. È uno spettro più curioso, perché non si aggira tra noi che lo abitiamo. Si aggira tra coloro che ci osservano da fuori, dall'altra parte dell'oceano, e che ci guardano come si guarda un parente eccentrico al pranzo di Natale, qualcuno con cui si è obbligati a interagire, di cui in fondo si vorrebbe disfarsi, ma che ostinatamente continua a esistere e a parlare di cose strane come dignità del lavoro, accessibilità, protezione dei minori, responsabilità da prodotto. Lo spettro siamo noi. O meglio, è quello che stiamo facendo qui in materia di regolazione del digitale, una serie di acronimi che a Bruxelles vengono considerati lavoro tecnico ordinario e che a San Francisco vengono percepiti come una minaccia di natura quasi esistenziale. Vista da fuori, e in particolare vista da una specifica parte del mondo che si è fatta sentire molto negli ultimi anni, l'Europa è diventata un personaggio. Non è più un soggetto economico né un'unione politica né, ormai, il continente di centinaia di milioni di persone che ci abitano. È un meme. Un meme con una funzione narrativa precisa: incarnare ciò che il futuro non deve essere. La burocrazia ottocentesca incollata sopra il Ventunesimo secolo. Il vecchio mondo che frena il nuovo. Il museo a cielo aperto che pretende di dettare regole alla fabbrica del domani. È una caricatura, naturalmente, ma è una caricatura efficace, perché funziona dentro una storia molto più grande di sé, e quella storia è la guerra culturale che una parte del capitalismo americano sta conducendo contro l'idea stessa che il software possa essere oggetto di norme. ## Il GDPR e il banner che lo riassume {: #gdpr-banner } Per capire dove siamo oggi è utile risalire un po'. Il momento in cui il rapporto tra Silicon Valley e regolazione europea si è incrinato in modo difficile da ricomporre è il GDPR. Un regolamento del 2016, applicato dal 2018, tecnicamente non rivoluzionario, ispirato in larga parte a principi che esistevano già nella Convenzione 108 e nella direttiva 95/46. Eppure quello che il GDPR ha fatto in pratica è stato dichiarare che certi modelli di business basati sulla raccolta indiscriminata di dati personali avrebbero dovuto, a un certo punto, fare i conti con qualcosa. Non è un caso che il GDPR sia diventato il bersaglio simbolico per eccellenza nella narrazione anti-europea, e non è un caso che il modo prevalente per attaccarlo sia il cookie banner. Mi tocca, qui, fare la mia prima concessione. Il cookie banner come lo viviamo è un fallimento. Lo è dal punto di vista dell'utente, che lo clicca via senza leggere. Lo è dal punto di vista della tutela effettiva, perché quel consenso è quasi sempre fittizio. Lo è dal punto di vista del designer di interfacce, costretto ad accettare che ogni sito europeo si apra con una porta di dogana digitale che nessuno desidera. È il classico esempio di una norma corretta sul piano dei principi che si è scaricata sul piano applicativo in un modo grottesco, perché il legislatore ha assunto che il consenso fosse un atto di volontà sovrana di un soggetto razionale, e i designer di prodotti digitali sapevano benissimo che bastava progettare il banner in un certo modo per farlo cliccare via in mezzo secondo. Il dark pattern si è mangiato la teoria del consenso libero, specifico, informato e inequivocabile. Lo si vede ogni giorno. È un problema reale. Chi lo critica ha ragione su questo punto specifico. Ma è qui che inizia la divergenza tra la critica utile e la critica strumentale, perché chi ha ragione sul cookie banner non sta in realtà discutendo del cookie banner. Sta usando il cookie banner come metonimia per attaccare l'idea stessa che la raccolta dei dati personali sia un problema regolabile. Sta dicendo, in sostanza, che se la regola produce un'attuazione brutta allora la regola va abolita, e non che l'attuazione va corretta. Si tratta di una mossa retorica antica, e qui non è il caso di scomodare nessuno, basta osservare che chi sostiene l'abolizione del GDPR sulla base del cookie banner di solito non sostiene la modifica delle norme tecniche di consenso, che sarebbe la posizione coerente. Sostiene il ritorno a un mondo in cui le piattaforme americane facciano quello che vogliono dei nostri dati senza dover spiegare niente a nessuno. Il banner era una scusa, non un argomento. ## DSA, DMA, e il modello di business {: #dsa-dma } Il fatto che fosse una scusa lo si è capito definitivamente con il DSA e con il DMA. Quando la Commissione ha cominciato a chiedere ai gatekeeper di aprire le loro piattaforme, di rendere interoperabili certi servizi, di non favorire i propri prodotti negli store, di permettere agli utenti di disinstallare applicazioni preinstallate, l'argomento "voi regolate troppo" si è trasformato senza intermezzo nell'argomento "voi state attaccando le nostre aziende". Il salto è interessante. Per anni ci hanno spiegato che il problema era l'eccesso di norme, non l'identità di chi pagava. Da quando le norme sono diventate operative, ci hanno spiegato che il problema è che colpiscono soltanto i campioni americani. Le due tesi non sono compatibili, ma vivono benissimo insieme nella stessa argomentazione, e questo già dovrebbe far sospettare che ci sia qualcosa che non torna. C'è da dire una cosa importante a proposito del DMA. La tesi secondo cui il DMA prende di mira specificamente le aziende statunitensi è fattualmente debole, perché tra i gatekeeper figura anche ByteDance, e perché le soglie sono soglie. Un'azienda europea che raggiungesse i settantacinque miliardi di capitalizzazione e i quarantacinque milioni di utenti finali mensili sarebbe gatekeeper anch'essa. Il problema è che le aziende europee in quella fascia sono rarissime, e l'unico caso recente, Booking, opera da Amsterdam ma fa capo a una holding statunitense. Questa assenza non dipende dal DMA. Dipende da scelte industriali, fiscali, finanziarie e formative degli ultimi quaranta anni che il DMA non ha causato e che il DMA non risolverà. Se vogliamo parlare di quel problema parliamone, e parliamone seriamente, citando il rapporto Draghi se ci serve un appiglio recente, ma non confondiamolo con la regolazione delle piattaforme, perché sono due piani che si toccano solo all'apparenza. Questo è il punto che chi ci osserva da fuori non vuole vedere, o forse vede benissimo e fa finta di no. La regolazione delle piattaforme non è in concorrenza con l'innovazione. È in concorrenza con un modello di business specifico, quello dell'estrazione massiva di dati personali, dell'ottimizzazione dell'attenzione fino al limite dell'addiction, della cattura di mercati adiacenti tramite leva di posizione dominante, dello scaricamento sistematico delle esternalità negative sul corpo sociale. Si dà il caso che quel modello di business sia stato il modello prevalente del capitalismo digitale americano negli ultimi venti anni. Si dà il caso che le aziende che lo hanno praticato siano oggi le più grandi del mondo, e che abbiano un interesse evidente a continuare a praticarlo. Se l'Unione Europea dice che quel modello specifico ha dei limiti, sta toccando un nervo scoperto, e non per accidente. Sta dicendo, in modo più o meno articolato, che esiste un altro modo di fare tecnologia digitale. Questo, nel 2026, è eresia. ## Dalla norma all'oggetto tecnico {: #norma-oggetto } Lascio per un attimo l'analisi e racconto un episodio concreto, perché credo che sia utile capire da dove parlo. Lavoro, da diversi anni, in una società ICT italiana di media dimensione, fuori dalle grandi aree metropolitane, che fa software per la pubblica amministrazione e per la sanità. Negli ultimi due anni il mio lavoro è stato in larga parte uno solo: tradurre le normative europee in oggetti tecnici. Cosa significa avere una piattaforma sanitaria conforme all'articolo 28 del GDPR quando il fornitore di un fornitore è in Germania e il dato sanitario riguarda un cittadino italiano. Cosa significa, per un ente di formazione che eroga corsi sulla sicurezza sul lavoro ai sensi dell'Accordo Stato-Regioni, vedere arrivare il Cyber Resilience Act e capire che il proprio LMS rientra nell'ambito di applicazione. Cosa significa, per una software house che produce un applicativo gestionale, prepararsi al fatto che la Product Liability Directive aggiornata ha esteso il regime di responsabilità da prodotto difettoso anche al software, comprese certe forme di componente AI integrata, e che il regime si applicherà operativamente ai prodotti immessi sul mercato dopo il dicembre del 2026. Cosa significa progettare una DPIA seguendo il template approvato dall'EDPB lo scorso marzo, accorgendosi che si tratta non di un modulo ma di un genere documentale che deve essere tenuto vivo insieme al sistema che descrive. Sono lavori di traduzione, non di astrazione. Le norme che dall'altra parte dell'oceano vengono dipinte come ostacoli all'innovazione sono, per me, l'innovazione stessa, perché definiscono il perimetro entro cui si può progettare bene. Non lo dico per romantica adesione al progetto europeo. Lo dico perché, dopo aver implementato decine di volte questi requisiti dentro a sistemi reali, si vede una cosa che da un articolo di Andreessen non si vede. Si vede che la conformità non è un costo isolato, è una pressione progettuale. Come tutte le pressioni progettuali, restringe lo spazio delle scelte e in cambio costringe a fare le cose meglio, almeno entro la dimensione che la norma protegge. La PLD, per esempio, sposta la responsabilità del produttore sulla qualità del software in modo che fino a ieri non esisteva nemmeno come fattispecie. Per chi vende prodotti seri questo è un fastidio amministrativo. Per chi vendeva monnezza promettendo che fosse magia, questo è un terremoto. Indovinate da quale dei due gruppi viene la critica più virulenta. Si potrebbe dire, e si dice, che il discorso vale per il mio piccolo studio italiano ma non vale per la frontiera della tecnologia. Lo studio italiano non sta inventando i modelli di fondazione, non sta progettando datacenter da gigawatt, non sta ridefinendo il paradigma della ricerca scientifica. Vero. Ma è proprio per questo che il mio punto di osservazione mi sembra utile, perché racconta da molto vicino quello che le grandi narrazioni californiane non riescono a vedere mai, e cioè che la stragrande maggioranza del software che gira nel mondo non è frontiera, è infrastruttura quotidiana. Sono i sistemi sanitari che gestiscono i nostri dati clinici, sono i portali della pubblica amministrazione che gestiscono i nostri rapporti con lo Stato, sono i gestionali che fanno funzionare le piccole imprese, sono i sistemi di formazione che certificano competenze obbligatorie per legge. È tessuto. La regolazione europea è scritta soprattutto per questo tessuto, e il tessuto, per definizione, ha bisogno di regole per esistere come tessuto e non come accumulo casuale di fili. ## AI Act, Vance, e la corsa {: #ai-act-vance } Andiamo avanti, perché c'è un altro tema che merita di essere preso sul serio, ed è l'AI Act. Anche qui la concessione va fatta. L'AI Act è un regolamento difficile, scritto in un momento storico in cui la tecnologia che doveva regolare cambiava ogni quattro settimane. Ha avuto una gestazione complicata, ha subito una svolta in corsa quando sono arrivati i modelli di fondazione, ha prodotto nel testo finale alcune asimmetrie tra obblighi per fornitori e obblighi per utilizzatori che gli operatori del settore stanno ancora cercando di capire come applicare. Ci sono ambiguità nei codici di condotta sui sistemi general purpose. Ci sono dubbi su come si calcolino le soglie computazionali. Ci sono difficoltà operative nella valutazione di conformità per le applicazioni high risk in ambito sanitario, e qui parlo per esperienza diretta perché Trustie, la piattaforma su cui lavoro come CTO-as-a-Service per Umana Analytics, deve fare i conti con alcuni di questi dubbi insieme al GDPR e ad altri pezzi di disciplina europea che si sovrappongono in modo non sempre lineare. Tutto vero. Tutto giusto. Ed è esattamente per questo che l'AI Act non è la fine del mondo. È una norma giovane, in fase di rodaggio, che si confronta con un settore che è giovane anch'esso e in fase di rodaggio. Le difficoltà di applicazione sono reciproche, perché la tecnologia è in fase di scoperta del proprio spazio e la norma è in fase di scoperta della propria attuazione. Questo è normale. È successo con qualunque tecnologia trasformativa, è successo con la chimica industriale del primo Novecento, con la sicurezza nucleare del secondo, con i dispositivi medici negli anni Ottanta, con la finanza dopo Lehman. Le norme nuove vivono i primi anni in stato di iterazione. La differenza, oggi, è che gli operatori americani considerano normale che la legge insegua la tecnologia, mentre considerano scandaloso che la legge si metta in piedi prima. Lo scandalo è raccontato in termini quasi religiosi. Non è regolamentazione, è iper-regolamentazione. Non è cautela, è codardia. Non è interesse pubblico, è socialismo travestito da diritto. Vance, da Parigi, l'anno scorso, ha tenuto un discorso che resta nei libri di testo non per il contenuto ma per il tono. Ci ha spiegato, alla platea europea, che noi stiamo strangolando l'AI con le nostre paure, che siamo prigionieri del nostro stesso garantismo, che il futuro non aspetterà. Era un discorso pensato per essere shareato in clip da quaranta secondi. Funzionava molto bene per quello scopo. Funzionava meno bene come analisi di una norma che, ricordiamolo, non vieta lo sviluppo dell'AI, lo articola secondo livelli di rischio. Il framework concettuale dell'AI Act è lo stesso framework con cui in qualunque civiltà industriale si regolano le sostanze chimiche pericolose, i farmaci, le automobili, gli alimenti destinati ai bambini. Nessuno chiede a Vance di smettere di pensare che la regolazione sia sempre eccessiva, è una posizione politica legittima e ha una sua tradizione. Solo, che la presenti per quello che è, e non come l'osservazione neutra di un osservatore neutro. C'è un argomento che si sente spesso e che mi sembra meriti una risposta. È l'argomento della corsa. L'AI è una corsa, ci dicono, e l'Europa la sta perdendo. Mentre noi scriviamo regolamenti, la Cina costruisce, gli Stati Uniti costruiscono, e tra cinque anni saremo irrilevanti. Bene. Concedo anche questo, in parte. Sul piano delle infrastrutture computazionali e della disponibilità di capitale di rischio l'Europa è effettivamente indietro, e lo sarà a lungo, e questo è un problema serio che richiederebbe politica industriale vera, investimenti pubblici sostanziosi, integrazione del mercato dei capitali europeo, riforme del lavoro accademico, niente di cui discutiamo seriamente da decenni. Ma la corsa, di che corsa parliamo. Una corsa la si definisce dal traguardo. Qual è il traguardo. Avere la propria versione di OpenAI. E poi. Avere la propria versione di Meta. E poi. Cioè, avere aziende che fanno cosa, di chi, per ottenere cosa, vendendo cosa a chi. La domanda non è oziosa, perché le aziende che gli amici di Vance ci propongono come modello sono aziende il cui valore è in larga parte costruito su un assunto preciso: che si possa raccogliere e usare dati personali con limiti minimi e che si possa scalare modelli di business basati sull'attenzione senza vincoli sostanziali sulla protezione dei minori. Se l'Europa vuole essere quella che corre dietro a quel modello e cerca di replicarlo, allora sì, sta perdendo. Se l'Europa vuole essere quella che propone un'alternativa, la corsa è un'altra. Si gioca su un altro terreno. Si vince con altre regole. E la regolazione, in quel caso, non è un freno. È il prodotto. ## Brussels Effect e il muro normativo a stelle e strisce {: #brussels-muro } Mi rendo conto che questa frase suona presuntuosa, e in parte lo è. Ma è il cuore della questione. La Brussels Effect, di cui parla Anu Bradford da almeno un decennio, non è un'invenzione retorica. È un meccanismo concreto. Quando l'Unione Europea fissa uno standard, e quando il mercato europeo è abbastanza grande da non poter essere ignorato, le imprese globali finiscono per adottare quello standard come default, perché tenere due architetture parallele costa più che tenerne una sola. Il GDPR è già da anni un default informale per il design dei sistemi di gestione dati nelle aziende che operano globalmente. Le specifiche di accessibilità europee finiscono per essere implementate ovunque, perché chi vende anche solo un terzo dei propri prodotti in Europa progetta una sola interfaccia. Il CRA produrrà un effetto simile sul software. La PLD produrrà un effetto simile sulla responsabilità da prodotto. L'AI Act produrrà un effetto simile sulla classificazione del rischio dei sistemi automatizzati. Non è imposizione coloniale al contrario, è il funzionamento ordinario del mercato, ed è esattamente per questo che fa così rabbia ai techno-ottimisti, perché le loro aziende sono costrette ad adattarsi a regole che non hanno scritto loro. Poi c'è l'argomento del muro normativo. L'Europa, ci dicono, sta costruendo un muro normativo che esclude i fornitori americani. Questo è un argomento che merita di essere preso davvero sul serio, perché ha una parte di vero e una parte di falso, e chi lo usa di solito mescola le due. La parte di vero è che alcuni regolamenti, in particolare il Data Act, alcune disposizioni sulla cybersicurezza coordinata, certe norme sui cloud sovrani, hanno effettivamente una componente di politica industriale, nel senso che cercano di favorire l'emergere di un'offerta tecnologica europea in settori critici. Questo non è un mistero, è scritto nei considerando, ed è un'attività legittima che fanno tutti gli Stati e tutte le aree economiche del mondo. La Cina lo fa apertamente, gli Stati Uniti lo fanno con il CHIPS Act e con l'Inflation Reduction Act, con il rinnovato controllo sugli investimenti esteri, con i divieti di esportazione di GPU avanzate. La novità non è che l'Europa lo faccia. La novità è che lo faccia con una sua specificità europea, basata su requisiti di trasparenza e di accountability, su una preoccupazione esplicita per i diritti fondamentali. Questo, agli occhi di un investitore americano della cerchia di Andreessen Horowitz, è un'anomalia. Lo è nella misura in cui l'investitore americano considera l'attività regolatoria come, di per sé, un'aberrazione politica. La parte di falso, invece, è la pretesa che il muro normativo europeo sia diverso da qualunque altro muro normativo nel mondo. Provate a esportare software medico negli Stati Uniti senza FDA. Provate a vendere un servizio finanziario a consumatori americani senza autorizzazione SEC o FINRA. Provate a operare un veicolo a guida autonoma a livello federale senza confrontarvi con il NHTSA. Provate a vendere giocattoli per bambini senza CPSC. Il sistema americano è pieno di muri normativi, e quei muri sono lì da decenni, e funzionano benissimo come barriere all'ingresso per i fornitori esteri. Quando un'azienda europea ne lamenta il peso, la risposta standard americana è "le regole sono le regole, se vuoi vendere qui ti adegui". È esattamente la stessa risposta che oggi diamo noi a chi protesta per il CRA, e ha esattamente la stessa legittimità. Solo che noi la diamo da un'asimmetria di potere narrativo che ci colloca, in partenza, dalla parte del torto. ## L'asimmetria narrativa {: #asimmetria } Questa asimmetria narrativa è il vero spettro che si aggira per l'Europa. Non l'Europa che fa paura agli altri. L'Europa che ha paura di sé stessa, perché l'unica cornice culturale dominante del settore tech è quella elaborata in California negli ultimi venticinque anni, e quella cornice considera ogni atto regolatore un fallimento per definizione. Da quella cornice, ogni nostra norma è un sintomo di decadenza. Ogni nostra direttiva è un segno di stagnazione. Ogni nostro tentativo di articolare una visione differente del rapporto tra tecnologia e cittadini è derubricato a rancore di chi ha perso la corsa. È una cornice molto efficace, ed è molto difficile contestarla dall'interno della tech europea, perché quella stessa tech europea spesso si è modellata sulla tech americana, ne legge i blog, ne adotta gli strumenti, ne assorbe il vocabolario, e finisce per giudicare il proprio continente con gli occhi di un altro. Faccio un altro passo. Quando dico che la cornice californiana è egemonica, non sto facendo sociologia da bar. Sto descrivendo il fatto che, in qualunque conferenza europea sul digitale, nel 2026, gran parte del lessico tecnico, gran parte degli esempi virtuosi, gran parte del frame interpretativo provengono dalla letteratura americana di settore. È un fatto. Da qui passa il problema, perché quando il regolatore europeo prova a scrivere una norma, deve farlo in un ambiente intellettuale popolato da operatori che hanno introiettato la grammatica avversaria. Non sempre ne sono consapevoli. Spesso pensano in buona fede di essere "pragmatici", di stare dalla parte dei "fatti", di voler "evitare l'iper-regolazione". Ma stanno usando un vocabolario fatto altrove, per finalità altrui, e finiscono per produrre, anche da posizioni europee, una difesa implicita del modello che vorrebbero criticare. Il risultato è che nei corridoi di Bruxelles si discutono regolamenti progressivi mentre nei feed dei founder italiani circolano clip di Sacks che spiegano come quei regolamenti siano un'aggressione al libero mercato. Le due cose convivono. Più di questo, si alimentano a vicenda. Ogni norma scritta a Bruxelles produce un nuovo round di lamentele a San Francisco, ogni round di lamentele a San Francisco produce un nuovo cedimento culturale di una parte della classe imprenditoriale europea, ogni cedimento culturale produce, in cascata, un indebolimento politico del processo legislativo successivo. ## Il progetto, e perché va nominato {: #progetto } A questo punto, dopo due ondate di concessioni e una di analisi, il lettore ha probabilmente intuito dove voglio arrivare. Vorrei che fossimo molto chiari su una cosa. L'odio per la normativa europea sul digitale, quello vero, quello viscerale, quello che si trova nei post di David Sacks, nelle interviste di Joe Lonsdale, nelle paranoie di Balaji Srinivasan, nelle sortite di JD Vance, non è un disaccordo tecnico. È una posizione politica, ed è una posizione politica precisa, e va riconosciuta per quella che è. Quella posizione sostiene che gli Stati nazionali dovrebbero arretrare rispetto alle imprese tecnologiche, che le imprese tecnologiche dovrebbero godere di una sovranità funzionale equivalente o superiore a quella degli Stati nei territori in cui operano, che la democrazia rappresentativa è troppo lenta per il ritmo dell'innovazione e che, in caso di conflitto, è la democrazia a doversi adattare. Questa è una posizione coerente, ed è una posizione che ha alle spalle pensatori, libri, manifesti, perfino elaborazioni teoriche raffinate, dal libertarianesimo di Ayn Rand al neo-reazionarismo di Curtis Yarvin, passando per l'accelerazionismo di destra che prendeva spunto da Nick Land, fino alle ultime sintesi di Thiel sul concetto di stagnazione. Non è caricaturale, anche se la sua versione popolare lo è. È un progetto. Vale la pena soffermarsi un momento su questo progetto, perché per molto tempo è stato sottovalutato in Europa, e forse continua a esserlo. Il filone che parte da Yarvin, in particolare, sostiene apertamente che la democrazia rappresentativa sarebbe un sistema disfunzionale e che andrebbe sostituita da forme di governo gestite come imprese, da CEO con poteri pieni, sciolti dai vincoli costituzionali. È una posizione che fino a dieci anni fa veniva considerata folkloristica anche dalla destra americana mainstream. Negli ultimi cinque anni si è normalizzata, è entrata nelle conversazioni di Sand Hill Road, ha trovato finanziamento implicito ed esplicito dentro il network di Thiel, ha colonizzato pezzi del Partito Repubblicano e si è seduta, alla fine, dentro la Casa Bianca con un vicepresidente che cita pubblicamente Yarvin senza imbarazzo. Detto altrimenti, una parte significativa della classe dirigente americana attuale considera l'assetto liberal-democratico postbellico come un esperimento fallito, e considera il proprio modello tecno-aziendale come la sua naturale successione storica. In questa cornice, l'Unione Europea non è solo un fastidio commerciale. È, letteralmente, un'incarnazione di tutto ciò che si vuole superare: un soggetto sovranazionale che impone standard di trasparenza alle imprese, che protegge la concorrenza, che pone limiti alla libertà del produttore in nome di diritti che non si possono comprare né scambiare. Per chi pensa che il futuro debba essere governato dai migliori, e che i migliori siano i vincitori del mercato, l'Europa è un nemico storico. Capisco che presentata così la questione possa sembrare estremizzata, e che molti lettori italiani, magari non ostili pregiudizialmente alla cultura tech americana, mi diranno che sto facendo il caricaturista al contrario. Non sto caricando. Sto solo prendendo sul serio le cose che le persone in questione scrivono pubblicamente sui propri profili. Andate a leggere le interviste di Marc Andreessen del biennio 2023-2024. Andate a guardare il manifesto techno-ottimista. Andate a leggere il libro di Yarvin del 2024. Andate a sentire i podcast All-In, soprattutto le pagine in cui si commenta la regolazione europea. Andate a guardare il discorso di Vance al summit AI di Parigi del febbraio 2025. Non sto leggendo qualcosa fra le righe. Sta tutto sopra le righe, scritto con una franchezza che, dal nostro punto di vista, è perfino disarmante. L'unica cosa che rimane fra le righe è la conclusione politica, e la conclusione politica si formula così: l'autorità democratica non ha titolo a porre vincoli all'attività delle imprese tecnologiche, perché le imprese tecnologiche stanno costruendo il futuro e l'autorità democratica appartiene al passato. Rispetto a questo progetto, l'Unione Europea, con tutta la sua lentezza, con tutte le sue imperfezioni, con tutto il suo cookie banner, è effettivamente il principale ostacolo geopolitico contemporaneo. Lo è non perché abbia un piano contro la tech americana, ma perché il suo modello incorpora un assunto che il progetto californiano vuole demolire: l'assunto secondo cui l'autorità democratica può legittimamente porre vincoli all'attività economica delle imprese. Tutto qui. È un assunto antico, lo si trova nella tradizione costituzionale di tutti i Paesi europei e anche degli Stati Uniti pre-Reagan, ma nel contesto culturale del 2026 è diventato eretico. La nostra eresia consiste nel riprendere quell'assunto e applicarlo al digitale. Niente di più, niente di meno. Per questo siamo uno spettro: perché ricordiamo, con la nostra esistenza istituzionale, che è possibile pensare diversamente. ## Europa coerente, Cina malposta {: #europa-cina } Mi fermo un istante per rispondere a un'obiezione che immagino. Ma l'Europa è davvero così coerente. Non ci sono divisioni interne, non ci sono lobby, non ci sono manovre nazionali, non ci sono pasticci normativi. Certo che ci sono. L'Europa è un sistema politico complesso, con interessi divergenti tra Stati membri, con la Germania che spesso difende gli interessi della propria industria automobilistica anche quando questo confligge con la coerenza ambientale, con la Francia che spesso cerca di promuovere campioni nazionali sotto la copertura della politica industriale europea, con l'Italia che ha una rappresentanza tecnica spesso debole nei tavoli che contano, con governi nazionali che usano l'ostilità alla regolazione europea come strumento di consenso interno. Tutto questo esiste. Niente di tutto questo, però, cambia il fatto che l'output normativo del processo europeo, alla fine, è coerente con un certo modello di rapporto tra tecnologia e cittadini, e che quel modello è radicalmente diverso da quello americano, e che la differenza è l'oggetto vero del conflitto. Un'altra obiezione. E la Cina. La Cina, nel discorso anti-europeo, viene sempre tirata in ballo come reductio ad absurdum: voi regolate, mentre la Cina costruisce, e la Cina vincerà. Questa è una mossa retorica così sgangherata che spesso non vale nemmeno la pena affrontarla, ma vale la pena osservare un dettaglio. Il modello cinese di governo del digitale è un modello in cui lo Stato, identificato con il Partito, esercita un controllo profondissimo sul comportamento delle piattaforme, sui contenuti, sui dati, sui flussi internazionali. Pechino ha, sull'algoritmo di TikTok cinese, un livello di intervento normativo che farebbe sembrare il DSA un libretto di istruzioni di un robot da cucina. Eppure, quando i tecno-ottimisti citano la Cina come modello di non-regolazione, non lo dicono. Si limitano a citare la velocità di costruzione delle infrastrutture, la velocità di diffusione delle applicazioni AI, la velocità di chiusura di siti come Temu e Shein. Saltano, con eleganza notevole, l'esistenza dello Stato. Questo perché, in fondo, il loro problema non è lo Stato in quanto tale, è uno Stato democratico che imponga vincoli ai propri amici. Di fronte a uno Stato autoritario che imponga vincoli generici a tutti, e contemporaneamente garantisca a sé stesso una posizione dominante incontestabile, hanno molto meno da obiettare. Il punto è la democrazia, non la regolazione. La regolazione è solo la forma in cui la democrazia, in un mondo digitale, prende forma giuridica. ## La tecnica al servizio della politica {: #tecnica-politica } Vorrei chiudere ricomponendo un po' di tessuto, perché ho cominciato citando Marx ed è giusto che il cerchio si chiuda. Lo spettro del Manifesto era una promessa di trasformazione. Era qualcosa che, agli occhi delle classi dominanti dell'Ottocento, rappresentava la possibilità che il futuro non fosse semplicemente la continuazione del presente. Lo spettro che oggi turba i sogni dei venture capitalist californiani non promette nessuna rivoluzione. Promette solo che il futuro digitale possa essere progettato anche da soggetti diversi dai loro investimenti, secondo principi diversi dai loro, in un quadro istituzionale che precede il loro modello e che sopravvivrà alla sua eventuale crisi. È uno spettro modesto, e proprio per questo è insopportabile, perché smonta la pretesa di esclusività che il modello californiano si è arrogato per un quarto di secolo. Smonta l'idea che esista un solo modo legittimo di fare tecnologia digitale, secondo le regole scritte da una specifica comunità di investitori in una specifica area geografica del pianeta. Restituisce alla tecnologia il suo statuto di artefatto culturale plurale, soggetto a istituzioni plurali, contestabile e contestato. Per chi credeva di aver vinto la storia, questo è un affronto. Per chi fa questo mestiere, in questo continente, in questi anni, lo spettro non è un fastidio. È una bussola. È quello che ci dice, ogni mattina, quando apriamo una pull request o quando scriviamo un capitolato di gara, che le scelte tecniche hanno conseguenze politiche e che le conseguenze politiche meritano di essere protette dal diritto. Non lo facciamo perché siamo decadenti. Lo facciamo perché abbiamo una memoria storica lunga, e sappiamo che le tecnologie senza vincoli, nei quattrocento anni precedenti, hanno prodotto l'esatto contrario della libertà che promettevano. Lo facciamo perché abbiamo letto Polanyi, abbiamo letto Hannah Arendt, abbiamo letto i Padri costituenti del nostro continente, abbiamo letto la giurisprudenza europea sui diritti fondamentali, e da tutto questo materiale abbiamo tratto una conclusione semplice. Il mercato non è un dato di natura. È un'istituzione. E come tutte le istituzioni umane, va costruita e va corretta nel tempo. Il digitale è un mercato. Le sue regole non scendono dal cielo della Silicon Valley. Le scriviamo, anche noi, qui, in mezzo a un continente che si sta accorgendo, lentamente, di essere diventato il luogo più strano del mondo: il luogo in cui qualcuno prova ancora a dire che la tecnica deve servire la politica, e non il contrario. C'è un'ultima cosa che vorrei dire, e la dirò in tono più personale, perché è il tono giusto per chiuderla. Quando capita di parlare di queste cose con colleghi americani, di solito entro tre minuti arriva il momento in cui mi viene chiesto, con una sfumatura di compatimento sincero, se non mi senta soffocato, in Europa, da tutta questa burocrazia. La domanda è posta in buona fede. Loro pensano davvero che noi viviamo in una specie di gabbia regolatoria che ci impedisce di costruire. La risposta più onesta che riesco a dare è che no, non mi sento soffocato. Mi sento nel posto giusto. Perché qui, almeno qui, la domanda "questo software cosa fa alle persone" è una domanda legittima, è una domanda che si può porre a un consiglio di amministrazione, è una domanda che ha conseguenze giuridiche se la risposta è cattiva. Altrove la stessa domanda viene considerata, nel migliore dei casi, ingenua. Nel peggiore, sovversiva. Ecco. Io preferisco lo stato di cose in cui posso porla, anche se per porla devo accettare un po' di carta in più, qualche audit, qualche template EDPB, qualche valutazione conformità. È un prezzo. Si paga. Non è un cataclisma. È, semmai, il prezzo della civiltà. **Lo spettro che si aggira per l'Europa siamo noi. E continueremo a esserlo finché qualcuno, da qualche parte, considererà ancora che la tecnica è una questione politica e non una questione di ingegneria pura. Non è poco. Non è poco affatto.** --- # L'inganno del contratto - **URL:** https://margiovanni.it/it/blog/linganno-del-contratto/ - **Pubblicato:** 2026-05-01 - **Tag:** Compliance, PLD, AI Act, CRA, Diritto Digitale - **Tempo di lettura:** 20 min > Sul perché il contratto di fornitura software, così come lo abbiamo conosciuto, ha smesso di essere lo strumento principale della relazione fra fornitore e cliente — e su quanto costa continuare a fingere che lo sia. ## Un contratto fra le persone sbagliate {: #persone-sbagliate } Il contratto era stato firmato a fine 2023, e dal punto di vista del fornitore principale era un contratto pulito, ben strutturato, con tutte le clausole di salvaguardia che l'ufficio legale aveva preteso negli anni. Specificava chiaramente l'oggetto della fornitura, individuava i livelli di servizio, fissava le penali per il mancato rispetto, definiva il perimetro della responsabilità del fornitore con limitazioni standard al valore annuo del contratto, escludeva i danni indiretti, regolava la subfornitura attraverso una clausola che richiedeva al cliente di approvare i sub-fornitori principali e che spostava sul cliente la responsabilità di verificarne l'adeguatezza. Era stato negoziato per quattro mesi, era passato attraverso tre cicli di revisione legale da entrambe le parti, era stato firmato da figure dirigenziali con le procure necessarie. Il fornitore principale, una software house di cinquanta persone, lo considerava un buon contratto. Il cliente, una società di servizi sanitari privati con un milione di assistiti, lo considerava un contratto equilibrato. Per due anni il rapporto è andato bene. A fine 2025 un assistito ha subito un danno da quello che il sistema clinico avrebbe dovuto fare e non ha fatto. La causa tecnica è stata attribuita a una libreria di valutazione del rischio che il sistema usava per classificare le priorità di intervento. La libreria era stata fornita da un sub-fornitore approvato dal cliente quattro anni prima, era stata aggiornata silenziosamente dal sub-fornitore stesso ottanta giorni prima dell'incidente con un cambiamento di algoritmo che nessuno aveva comunicato al fornitore principale, e nessuno aveva richiesto un cambiamento di documentazione perché il sub-fornitore considerava il proprio aggiornamento come una manutenzione ordinaria. Il sub-fornitore aveva sede in un paese terzo, non aveva rappresentante legale nell'Unione, e nei mesi successivi alla causa è risultato di fatto irraggiungibile per le notifiche giudiziarie. Il fornitore principale ha reagito alla richiesta di danni del legale dell'assistito mostrando il contratto. Ha sostenuto che il sub-fornitore era stato approvato dal cliente, che la modifica era stata introdotta unilateralmente dal sub-fornitore senza alcuna comunicazione, che il contratto escludeva i danni indiretti e limitava la responsabilità al valore annuo, e che comunque la responsabilità materiale ricadeva sul cliente in qualità di soggetto che gestiva direttamente la relazione con l'assistito. Il legale dell'assistito non ha contestato nessuno di questi punti contrattuali. Ha semplicemente notato che il contratto fra fornitore e cliente non lo riguardava, perché lui non lo aveva firmato, e che la sua azione era basata sul nuovo regime europeo di responsabilità del prodotto, sotto il quale il fornitore principale era qualificabile come produttore del prodotto difettoso e rispondeva a titolo oggettivo verso il danneggiato finale a prescindere dalle clausole contrattuali pattuite con il proprio cliente. Quelle clausole, ha aggiunto, regolavano la rivalsa fra le parti firmatarie, non l'esposizione verso terzi. Il contratto, in altre parole, era un buon contratto fra le persone sbagliate. ## L'obiezione tradizionale {: #obiezione-tradizionale } L'obiezione che vorrei affrontare subito, perché è la più radicata e la più sincera, è quella che viene dai legali tradizionali con cui ho lavorato in questi anni. Suona così: tutto questo è un problema di scrittura del contratto. Se le clausole sono ben scritte, se le manleve sono complete, se le procedure di sub-fornitura sono rigorose, il fornitore principale è protetto. È un'obiezione formalmente coerente con il modo in cui il diritto contrattuale ha funzionato per quarant'anni nel software. Era un'obiezione che fino a qualche anno fa era anche sostanzialmente vera, perché il regime di responsabilità del produttore di software era debole, le azioni dei terzi danneggiati passavano quasi sempre attraverso il cliente diretto, e il fornitore principale poteva ragionevolmente attendersi che la propria esposizione si esaurisse nei limiti contrattuali pattuiti. Quell'epoca è finita. Il regime giuridico che si sta consolidando in Europa fra il 2024 e il 2027, e di cui ho già scritto in questa serie a proposito del prodotto software valutato come promessa scritta e della specifica come asset giuridicamente rilevante, introduce un livello di responsabilità che opera al di fuori del contratto e che il contratto può solo parzialmente disciplinare. La revisione della Product Liability Directive, applicabile dal 9 dicembre 2026, qualifica esplicitamente il software come prodotto e applica al produttore di software un regime di responsabilità oggettiva verso i danneggiati finali. Il Cyber Resilience Act, applicabile pienamente dall'11 dicembre 2027, introduce obblighi di sicurezza del prodotto digitale che gravano sul produttore lungo tutto il ciclo di vita, e che si estendono ai componenti integrati. L'AI Act distribuisce obblighi lungo la catena dei fornitori di sistemi di AI in modo che il provider del sistema finale debba garantire che i componenti che integra siano conformi. Il Digital Operational Resilience Act, applicabile dal 17 gennaio 2025, impone alle entità finanziarie e ai loro fornitori critici di ICT obblighi di gestione del rischio della catena di fornitura che attraversano i confini contrattuali. NIS2, applicabile dal 18 ottobre 2024, fa lo stesso movimento per i settori critici allargati. Ognuno di questi atti, preso singolarmente, sarebbe gestibile con qualche aggiustamento contrattuale. Presi insieme, e nelle loro intersezioni, definiscono una struttura di responsabilità che il contratto di fornitura non è più in grado di contenere. ## I quattro presupposti caduti {: #presupposti-caduti } Il modello contrattuale tradizionale del software è cresciuto in un'epoca in cui valevano alcuni presupposti impliciti, ed è diventato inadeguato perché tutti questi presupposti sono saltati nello stesso decennio. C'era anzitutto l'idea che la responsabilità del fornitore verso il cliente esaurisse l'esposizione del fornitore, perché il cliente intermediario assorbiva e gestiva qualsiasi responsabilità verso terzi danneggiati. C'era poi la convinzione che il software fosse un oggetto delimitato nel tempo della consegna, valutabile sulla base di un capitolato statico al momento del rilascio. Si dava per scontato, in terzo luogo, che la catena di fornitura fosse essenzialmente bilaterale dal punto di vista giuridico, cioè che ogni anello potesse essere disciplinato da un contratto fra due parti senza dover preoccuparsi delle dinamiche complessive della catena. E si presupponeva infine che il regime di responsabilità rimanesse stabile nel tempo, abbastanza da rendere ragionevole firmare contratti pluriennali sulla base del quadro giuridico vigente al momento della firma. Erano presupposti che sembravano leggi di natura della contrattazione software fino al 2020 circa, e che a posteriori si rivelano essere semplicemente le caratteristiche di un'epoca giuridica specifica. Il primo presupposto è stato eroso dall'allargamento della legittimazione attiva dei terzi danneggiati nella nuova PLD. Sotto il vecchio regime di responsabilità del prodotto, il danneggiato finale poteva agire contro il produttore ma in pratica le azioni passavano per lo più attraverso il rivenditore o l'integratore commerciale, e il produttore di software, fino al 2024, godeva di un'incertezza interpretativa sul fatto stesso di rientrare nella definizione di produttore. La nuova Direttiva, includendo il software esplicitamente nella definizione di prodotto e introducendo presunzioni di difettosità che alleggeriscono l'onere probatorio del danneggiato, rende la posizione del produttore di software molto più esposta. Aggiunge inoltre un meccanismo di disclosure documentale che permette al giudice di ordinare al fornitore di esibire la documentazione tecnica del prodotto, e di presumere il difetto in caso di mancata esibizione. Da quel momento il legale del danneggiato non ha più bisogno di passare attraverso il cliente intermediario, e può agire direttamente contro il fornitore principale del software che ha causato il danno, ignorando del tutto le clausole contrattuali fra fornitore e cliente, perché quelle clausole regolano un rapporto a cui il danneggiato è terzo. La cosa è scritta esplicitamente nell'Articolo 15 della Direttiva, intitolato «Esclusione o limitazione della responsabilità», che impone agli Stati membri di assicurare che la responsabilità dell'operatore economico verso il danneggiato non possa essere limitata o esclusa né da clausole contrattuali né da disposizioni di diritto nazionale. È un articolo breve e tecnico, ma è la chiave di volta dell'intero impianto, perché trasforma quello che sembrava un margine di manovra contrattuale in una zona di indisponibilità giuridica. Il secondo presupposto è stato eroso dal Cyber Resilience Act e dall'AI Act, che entrambi introducono obblighi di sicurezza e di gestione del rischio che gravano sul produttore lungo tutto il ciclo di vita del prodotto, non solo al momento della consegna. Il software ha cessato di essere un oggetto delimitato nel tempo della consegna, e si configura come un oggetto continuamente esposto al regime regolatorio, e ogni aggiornamento, ogni modifica, ogni integrazione di nuovi componenti, può essere riqualificato come modifica sostanziale che fa rientrare il prodotto nel regime applicativo, anche se il prodotto era stato immesso sul mercato in epoca precedente. Il fornitore principale che ha consegnato il sistema nel 2023 non si è scaricato della responsabilità nel 2026 quando una libreria di terze parti integrata in quel sistema ha smesso di essere mantenuta e ha sviluppato vulnerabilità di sicurezza. La responsabilità si è semplicemente spostata sul piano della manutenzione, e il fornitore che non ha aggiornato è un fornitore che è venuto meno a un obbligo continuativo, non a un obbligo limitato al momento della consegna originaria. Anche il terzo presupposto, quello sulla bilateralità della catena di fornitura, è stato eroso dall'introduzione di catene di responsabilità che attraversano la contrattazione bilaterale. Sotto il regime DORA, l'entità finanziaria deve mappare e gestire i propri ICT third-party risk lungo tutta la catena, e quando un fornitore è qualificato come critico le obbligazioni si estendono in modo che le clausole contrattuali fra l'entità finanziaria e il fornitore critico devono contenere elementi specifici imposti dal Regolamento, indipendentemente dalla volontà delle parti. Il CRA, da parte sua, impone al produttore di un prodotto digitale di garantire la sicurezza del prodotto integrato, e questa garanzia non si esaurisce nei rapporti contrattuali con i propri sub-fornitori, perché il regolatore valuta il prodotto come un tutto unitario indipendentemente dalla composizione interna della catena di fornitura. La PLD revisionata aggiunge un'ulteriore complicazione, prevedendo che il modificatore sostanziale di un prodotto possa diventare lui stesso responsabile come produttore, e questo crea una dinamica di responsabilità circolare in cui il fornitore principale, l'integratore intermedio, il sub-fornitore e l'utilizzatore finale possono essere chiamati in causa con titoli diversi per lo stesso danno. NIS2 e l'AI Act completano il quadro estendendo obblighi analoghi rispettivamente ai settori critici allargati e ai sistemi di intelligenza artificiale ad alto rischio, con il risultato che ogni segmento della catena è oggi attraversato da almeno due o tre regimi sovrapposti che le clausole contrattuali bilaterali non riescono a comporre. Il quarto presupposto, quello della stabilità del regime giuridico nel tempo, è quello la cui erosione produce gli effetti più subdoli, perché i contratti pluriennali firmati oggi sotto il quadro vigente saranno applicati domani sotto un quadro che si sarà evoluto. Il fornitore che firma un contratto a sei o sette anni nel 2026 si troverà a eseguirlo nel 2032 o 2033 sotto regimi che potrebbero essere cambiati a quel punto in modo significativo, perché la PLD prevede una clausola di revisione, perché il CRA sarà oggetto di linee guida che modificheranno l'interpretazione di intere sezioni, perché l'AI Act è già stato definito un cantiere aperto dalla Commissione stessa. Il contratto pluriennale sotto il modello tradizionale presupponeva un'inerzia regolatoria che non c'è più. ## Quattro fenomeni che il contratto non indirizza {: #quattro-fenomeni } Ognuno di questi quattro fenomeni ha conseguenze pratiche che il contratto tradizionale non sa indirizzare. La responsabilità solidale dei fornitori di componenti critici, introdotta in modi diversi da PLD e CRA, fa sì che il fornitore principale risponda dei difetti dei componenti integrati anche quando i sub-fornitori sono inadempienti o irraggiungibili. Le clausole contrattuali che disciplinano la rivalsa contro i sub-fornitori restano valide fra le parti firmatarie, ma non spostano la responsabilità verso il danneggiato finale, che può sempre agire contro il fornitore principale come anello accessibile e patrimonialmente più solido della catena. Il fornitore principale che voleva traslare il rischio sul sub-fornitore mediante clausole contrattuali si trova quindi a doverlo assorbire e a poter solo successivamente provare a recuperare per via di rivalsa, ammesso che il sub-fornitore sia ancora esistente, solvibile e raggiungibile. Gli obblighi di disclosure documentale introdotti dalla nuova PLD sono il secondo fenomeno, e sono particolarmente insidiosi perché trasformano il fornitore in un soggetto che deve esibire al giudice la propria documentazione tecnica anche quando questa documentazione include scelte progettuali, configurazioni di sicurezza, dataset di addestramento, decisioni architetturali che l'azienda considererebbe segreto industriale. Il giudice deve bilanciare il diritto alla disclosure con la tutela dei segreti commerciali, ma in pratica il fornitore si trova esposto a richieste documentali che il contratto con il cliente non può limitare, perché il contratto non vincola il giudice né il danneggiato. Il fornitore può aver pattuito con il cliente l'inaccessibilità della documentazione, ma se il danneggiato chiede l'esibizione il fornitore deve produrre, e l'eventuale rifiuto di esibire genera presunzione di difettosità ai sensi dell'Articolo 10 della Direttiva. Le presunzioni di difettosità che il singolo fornitore non può sfatare da solo sono il terzo fenomeno, e sono il più sottile dei quattro. La nuova PLD prevede che il giudice possa presumere la difettosità del prodotto quando il prodotto è tecnicamente o scientificamente complesso e la prova del difetto sarebbe eccessivamente difficile per il danneggiato. Per i sistemi software complessi, in particolare per quelli che integrano componenti AI, questa presunzione si attiva quasi automaticamente, e l'onere di sfatare la presunzione ricade sul fornitore. Sfatare la presunzione richiede di dimostrare che il prodotto al momento della consegna non presentava il difetto, oppure che il difetto è stato introdotto successivamente da modifiche fuori dal controllo del fornitore. Entrambe le dimostrazioni richiedono documentazione storica dettagliata del sistema, e il fornitore che non ha mantenuto questa documentazione si trova a non poter provare nulla, e quindi a soccombere alla presunzione. L'accountability del modificatore sostanziale è il quarto fenomeno, ed è quello che più radicalmente rompe la struttura del contratto bilaterale. Quando un cliente o un integratore intermedio modifica sostanzialmente un prodotto software fornito da un terzo, può diventare lui stesso responsabile come produttore del prodotto modificato, e questo apre una dinamica in cui il fornitore originale potrebbe non essere più responsabile per il prodotto come è stato modificato, ma il modificatore potrebbe non avere le competenze, la documentazione e la struttura per assumere la responsabilità che ha materialmente assunto. Il risultato è una zona grigia di responsabilità in cui il danneggiato sceglie chi citare in giudizio sulla base di criteri di accessibilità patrimoniale e procedurale, e in cui le parti coinvolte si rimpallano la responsabilità con esiti spesso paradossali. ## L'assestamento che non arriva subito {: #assestamento } Si potrebbe obiettare, e qualcuno lo farà, che tutto questo è esagerato e che la prassi giudiziaria troverà un modo per riportare l'ordine nel sistema. È un'obiezione che merita rispetto, perché la prassi giudiziaria ha sempre questa funzione assestante, e perché i regolamenti europei, una volta tradotti in giurisprudenza nazionale, perdono spesso la rigidità che hanno sulla carta. La risposta che mi sento di dare, dopo aver osservato come si sta muovendo la prassi nelle giurisdizioni europee dove i primi casi stanno emergendo, è che l'assestamento avverrà, ma avverrà in cinque o sette anni, e nel frattempo la finestra di esposizione per i fornitori che operano sotto contratti tradizionali è molto larga. Le prime sentenze rilevanti in materia di responsabilità del produttore di software sotto la nuova PLD non arriveranno prima del 2028, perché il regime si applica ai prodotti immessi sul mercato dopo il 9 dicembre 2026 e le cause hanno tempi minimi di un anno e mezzo. Da quel momento occorreranno altri tre o quattro anni perché si formi una giurisprudenza consolidata. Nel frattempo, ogni fornitore che opera con contratti del modello vecchio sta accumulando esposizione retroattiva, perché molti dei sistemi che sta consegnando oggi saranno ancora in produzione quando la giurisprudenza si sarà assestata, e saranno valutati con i criteri che si saranno consolidati a quel punto. ## I settori che ci precedono {: #settori-che-ci-precedono } Sarebbe disonesto non riconoscere che ci sono settori dove queste dinamiche esistono già da decenni, e dove i contratti di fornitura hanno una struttura che riconosce l'inadeguatezza del modello bilaterale tradizionale. Sono settori che vivono sotto regimi di responsabilità del prodotto stretti da molto prima del software generalista, e che hanno sviluppato pratiche contrattuali che meritano di essere studiate. L'aviazione civile è uno di questi, e i contratti di fornitura di componenti aeronautici incorporano da sempre obblighi di tracciabilità documentale, di certificazione di parte terza, di gestione coordinata delle non conformità, di responsabilità solidale verso le autorità regolatorie. Il dispositivo medico è un altro, e i contratti di fornitura di componenti per dispositivi medici prevedono accordi quadro di qualità che vanno al di là del singolo contratto commerciale, e che disciplinano la relazione fra le parti come una relazione regolatoria oltre che commerciale. L'automotive è il terzo, soprattutto dopo l'introduzione delle norme ISO 26262 sulla sicurezza funzionale dei sistemi elettronici dei veicoli, e i contratti di fornitura di software per automotive incorporano da una decina d'anni clausole di responsabilità lungo la catena che riconoscono l'impossibilità di confinare l'esposizione nei rapporti bilaterali. Quello che sta accadendo nel software generalista è la convergenza, accelerata dal pacchetto regolatorio europeo, verso il modello che questi settori già praticano. La differenza è che aviazione, dispositivi medici e automotive hanno avuto trent'anni per costruire le pratiche contrattuali, le competenze interne, gli standard di settore, e le relazioni di fornitura strutturate. Il software generalista ha cinque o sette anni per fare la stessa cosa, e lo deve fare mentre continua a operare in mercati dove la maggior parte dei competitor ancora ragiona con il modello vecchio. È una transizione asimmetrica, in cui chi si muove per primo paga un costo di posizionamento che chi si muove dopo non paga, ma chi si muove per primo costruisce anche capacità di assorbire le evoluzioni regolatorie successive che chi si muove dopo dovrà acquistare a mercato consolidato. ## Cinque dimensioni operative {: #cinque-dimensioni } Su un piano operativo, la trasformazione del contratto di fornitura software ha cinque dimensioni che vanno gestite contemporaneamente. La prima è il passaggio dal contratto come documento ai documenti contrattuali come ecosistema. Un contratto di fornitura software sotto il nuovo regime non si esaurisce in un documento singolo che vale fino al rinnovo, ma costituisce un sistema di documenti correlati che includono il contratto principale, gli allegati di livelli di servizio, gli allegati di sicurezza, gli accordi di qualità simili a quelli del medical device, gli accordi di trattamento dei dati personali ai sensi dell'Articolo 28 GDPR, gli accordi di gestione coordinata delle vulnerabilità, gli accordi di disclosure reciproca della catena di fornitura. Ognuno di questi documenti vive con un proprio ciclo di aggiornamento, e il contratto principale diventa il quadro che li tiene insieme, non il contenitore di tutte le clausole. La seconda dimensione è la trasformazione della clausola di limitazione della responsabilità. Le clausole tradizionali che limitano la responsabilità del fornitore al valore annuo del contratto, o che escludono i danni indiretti, restano valide fra le parti firmatarie ma non producono effetti verso i terzi danneggiati. Per il fornitore questo significa che l'esposizione effettiva è quella verso il danneggiato finale, non quella concordata con il cliente, e le polizze assicurative devono essere dimensionate su quella esposizione effettiva, non sui massimali contrattuali. La pratica assicurativa del settore è in questo momento confusa, perché le compagnie stanno ridefinendo i prodotti per la responsabilità civile dei produttori di software in funzione del nuovo regime, e i premi stanno aumentando in modo non lineare. Per le software house italiane di dimensione media, il costo assicurativo della responsabilità di prodotto sta diventando una voce di bilancio rilevante, dove fino a qualche anno fa era una voce trascurabile. La terza dimensione è la riscrittura delle clausole sulla subfornitura, che devono passare da un modello in cui il cliente approva i sub-fornitori principali al momento della firma a un modello in cui esiste una procedura continua di valutazione, monitoraggio e disclosure dei sub-fornitori lungo tutta la durata del contratto. Il fornitore principale deve poter dimostrare in qualsiasi momento la composizione della propria catena di fornitura, deve poter produrre la SBOM ai sensi del CRA, deve poter rispondere a richieste di audit del cliente o del regolatore, deve gestire le situazioni in cui un sub-fornitore esce dal mercato o cessa la manutenzione di un componente. Tutto questo richiede strumenti di gestione della catena di fornitura che il modello contrattuale tradizionale dava per scontati e che oggi diventano oggetto di attività operativa continua. La quarta dimensione è l'introduzione di clausole di gestione coordinata delle vulnerabilità e degli incidenti di sicurezza. Sotto il CRA, sotto NIS2 e sotto DORA per il finanziario, il fornitore e il cliente hanno entrambi obblighi di reporting in finestre temporali strette, e il rispetto di queste finestre richiede un coordinamento che il contratto deve disciplinare in modo operativo, non solo formale. Una clausola che dice «le parti collaborano nella gestione degli incidenti» è inutile se non specifica chi notifica, in quanto tempo, attraverso quali canali, con quali soglie di gravità. La clausola deve essere quasi un mini-runbook contrattuale, e la sua qualità si misura nella capacità di funzionare nel momento in cui un incidente reale è in corso, non nella sua eleganza giuridica. La quinta dimensione è la più sottile, e riguarda la gestione del ciclo di vita del prodotto. Sotto il CRA il produttore deve dichiarare il periodo di supporto del prodotto e mantenerlo per quel periodo, e deve gestire l'uscita del prodotto dal mercato in modo che gli utilizzatori siano informati e abbiano percorsi di transizione. Il contratto di fornitura software deve disciplinare questo aspetto, perché il fornitore principale è esposto verso il danneggiato finale anche dopo la fine della relazione contrattuale con il cliente, e perché la gestione dell'end of support diventa un momento critico in cui responsabilità residue possono materializzarsi. Le clausole tradizionali di *perpetual licence* o di *no warranty after termination* non producono effetti verso i terzi danneggiati, e questo significa che il fornitore deve gestire il ciclo di vita del prodotto come una funzione che eccede la durata del contratto. ## Disclosure: diciotto mesi di riscrittura {: #disclosure } Devo essere trasparente su un punto, perché su questo argomento sto descrivendo trasformazioni che sto vivendo in prima persona. La revisione dei nostri contratti di fornitura, dentro l'azienda dove lavoro, è un'attività in corso da diciotto mesi e non è ancora arrivata a una forma stabile. Stiamo lavorando con il nostro studio legale di riferimento per riscrivere il contratto base di fornitura di servizi software, e quello che sta venendo fuori dista molto dal contratto pulito ed elegante che speravamo di produrre, e ha la forma di un sistema di documenti più articolato del precedente, con allegati che esistono per ragioni diverse e che non si possono ridurre a un singolo template. Alcuni clienti accettano la nuova struttura, altri la trovano inutilmente complessa e chiedono di tornare al modello vecchio. La pressione del mercato verso la semplicità contrattuale è ancora forte, e in qualche caso noi stessi accettiamo di firmare contratti del modello vecchio quando il cliente lo impone, sapendo che stiamo accumulando esposizione retroattiva. È una scelta che facciamo per ragioni commerciali immediate, e che ho chiamato esposizione composta nelle nostre conversazioni interne, perché si accumula in modo non lineare al crescere del portafoglio clienti. ## Un'opportunità, non solo un peso {: #opportunita } Voglio anche dire, perché altrimenti il pezzo sembrerebbe una previsione pessimistica sull'industria del software italiano, che la trasformazione che sto descrivendo è un'opportunità prima di essere un peso. Le software house italiane di dimensione media che decideranno di costruire competenze contrattuali coerenti con il nuovo regime, di affiancare al lavoro di delivery un lavoro continuo di mantenimento documentale e di gestione della catena di fornitura, di formare al proprio interno le figure ibride che ho descritto nel pezzo precedente di questa serie, avranno fra cinque anni una posizione competitiva difficile da erodere. Le software house che continueranno a firmare contratti tradizionali nella speranza che il quadro regolatorio non si applichi davvero, o che la giurisprudenza nazionale lo addolcisca, si troveranno esposte e dovranno colmare il ritardo a costi molto più alti di quelli sostenibili oggi. È una di quelle situazioni in cui la decisione di non decidere è la più costosa di tutte, perché il tempo lavora contro chi non si muove, e perché ogni contratto firmato oggi sotto il modello vecchio è una passività che si rivelerà fra qualche anno, quando i casi che la PLD ha disegnato come scenario standard cominceranno a comparire nelle sezioni cronaca dei giornali specializzati. ## La centralità che muore {: #centralita-che-muore } Mettendo insieme i quattro pezzi di questa serie, l'argomento generale che sto cercando di costruire è il seguente. Il software, come oggetto industriale e come oggetto giuridico, sta cambiando natura sotto i nostri occhi, e la cultura ingegneristica e commerciale del settore non si sta adeguando con la velocità che il momento richiede. Il primo pezzo, *[Cruft, non patina](/it/blog/cruft-non-patina/)*, argomentava che il software non sa invecchiare come gli oggetti materiali. Quello successivo, *[Il debito di specifica](/it/blog/il-debito-di-specifica/)*, spostava l'attenzione sul fatto che la specifica scritta è diventata l'asset giuridicamente rilevante del prodotto e che la nostra industria non ha gli strumenti per mantenerla viva. Poi è arrivato *[L'ascesa del compliance engineer](/it/blog/lascesa-del-compliance-engineer/)*, dedicato alla figura professionale ibrida che sta emergendo per presidiare il vuoto fra ingegneria e regolazione. In questo quarto pezzo l'argomento si sposta dal piano del prodotto e del lavoro al piano della relazione fra organizzazioni, e la tesi è che il contratto di fornitura, lo strumento giuridico classico di quella relazione, sta diventando uno strumento fra altri di una relazione più ampia e più strutturata, che il diritto contrattuale tradizionale può solo parzialmente disciplinare. Il contratto di fornitura software non è morto, e niente di quello che ho scritto va letto come una previsione della sua scomparsa. Quello che è morto è la sua centralità, l'idea che la relazione fra fornitore e cliente possa essere descritta esaurientemente da un documento bilaterale negoziato all'inizio del rapporto e aggiornato ai rinnovi. La relazione contemporanea è una relazione multilaterale, regolatoriamente carica, dinamicamente esposta a soggetti terzi che il contratto non vincola, e attraversata da obblighi documentali continui che il contratto può solo sintetizzare. Pensare che basti scrivere meglio le clausole è una nostalgia comprensibile e umana, ed è anche il modo più rapido per accumulare esposizione mentre si crede di essere protetti. Le clausole servono ancora, anzi servono più di prima, ma servono come elementi di un dispositivo più ampio che le contiene e le supera. **Il contratto, così come lo abbiamo conosciuto, è diventato l'inganno gentile che permette ai fornitori di software di credere di sapere a cosa si stanno esponendo.** I contratti tradizionali continueranno a essere firmati per qualche anno ancora, perché il mercato si muove più lentamente del diritto, e perché il modello vecchio è familiare e i nuovi modelli sono ancora in formazione. Ma chi continua a firmare contratti tradizionali nei prossimi cinque anni sta firmando, oltre al contratto, una scommessa silenziosa sul fatto che le cose non cambieranno davvero. È una scommessa che la mia generazione di chi fa software in Europa probabilmente perderà, perché le cose stanno già cambiando, e quello che oggi sembra un eccesso di prudenza dei pochi che si stanno muovendo si rivelerà fra qualche anno il minimo prudenziale che era richiesto fin dal principio. --- # L'ascesa del compliance engineer - **URL:** https://margiovanni.it/it/blog/lascesa-del-compliance-engineer/ - **Pubblicato:** 2026-05-01 - **Tag:** Compliance, Lavoro, Sviluppo Software, AI Act, Mercato Del Lavoro - **Tempo di lettura:** 17 min > Sulla figura che sta emergendo dal vuoto fra ingegneria del software e regolazione europea, e su perché quasi nessuno se ne sta accorgendo in tempo. ## L'annuncio confuso {: #annuncio-confuso } Il job posting era apparso a febbraio su una di quelle bacheche dove le aziende italiane di medie dimensioni cercano figure tecniche senza essere troppo sicure di cosa stanno cercando. Il titolo della posizione era "Senior Software Engineer with Regulatory Background", e già lì c'era qualcosa di strano, perché in italiano una formula del genere non significa niente di preciso. Il corpo dell'annuncio chiariva poco. Si chiedeva esperienza di almeno cinque anni in sviluppo backend, preferibilmente Java o Python, conoscenza di Kubernetes, esperienza in pipeline CI/CD. Fin qui un profilo da senior developer normale. Poi il testo cambiava registro e cominciava a chiedere conoscenza approfondita del GDPR, padronanza dell'AI Act per quanto riguarda i sistemi ad alto rischio, capacità di redigere DPIA e valutazioni di rischio, esperienza con framework di compliance come ISO 27001 e SOC 2, capacità di interfacciarsi con auditor esterni. La RAL indicata era da senior developer di mercato, con un piccolo extra non quantificato per le competenze regolatorie. Ho letto quell'annuncio una decina di volte cercando di capire chi lo stesse cercando davvero. Una persona così, con quella combinazione di competenze, in Italia oggi non esiste in numeri rilevanti, e quando esiste costa il doppio di quello che l'azienda offriva. L'azienda lo sapeva o non lo sapeva, è difficile dirlo. Quello che è certo è che aveva un bisogno reale, perché stava per consegnare un sistema a un cliente regolato, e non aveva la persona giusta in casa. Aveva sviluppatori senior che non sapevano leggere un Regolamento europeo, aveva un legale interno che non sapeva leggere il codice, e aveva un consulente di compliance esterno che riusciva a parlare con uno dei due ma non con l'altro. La persona che cercava esisteva nella sua testa come traduttore fra mondi che non si parlavano, ma quella persona non aveva ancora un nome di mestiere stabile. L'annuncio è stato ripubblicato a marzo con un titolo diverso, "Compliance Engineer", senza altre modifiche al corpo. Poi è scomparso. Non so se l'azienda abbia trovato qualcuno o abbia rinunciato. So che annunci come quello, con varianti minime, ne sto vedendo passare uno o due alla settimana sulle bacheche italiane, e molti di più su quelle europee. Sto vedendo un mestiere che si sta cercando un nome, e che lo troverà nei prossimi due o tre anni perché non ha alternative. ## L'obiezione tecnologica {: #obiezione-tecnologica } L'obiezione che vorrei affrontare subito, perché è la più seria di tutte e perché viene posta sempre dai C-level che si occupano di costi, è quella tecnologica. Suona così: tutto il lavoro che descrivi lo farà l'AI fra tre anni. Un agente leggerà il sistema, leggerà il regolamento, produrrà la mappatura, aggiornerà la documentazione, segnalerà le incongruenze. Non serve costruire una nuova figura professionale, serve aspettare che la tecnologia maturi. È un'obiezione che ha una sua plausibilità apparente, ed è diffusa quanto basta da meritare una risposta. La risposta è che l'AI farà davvero il novanta per cento del lavoro meccanico, e non sto facendo previsioni cauto-cautelative qua, sto descrivendo quello che già fa adesso nei contesti in cui viene applicata seriamente. Quello che resta, il dieci per cento, non corrisponde al dieci per cento residuale che si presume sparirà man mano che i modelli migliorano. È il dieci per cento interpretativo e politico, ed è esattamente la parte che richiede un essere umano che capisca contemporaneamente l'architettura del sistema e la struttura del regolamento, e che sappia scegliere come allineare i due quando la lettera della norma e la realtà del software entrano in tensione, cosa che accade molto più spesso di quanto i regolatori vorrebbero ammettere. Anzi, capovolgendo la prospettiva, è proprio l'AI a rendere economicamente sostenibile la figura del compliance engineer. Senza assistenza generativa il volume di documentazione richiesta dal nuovo regime europeo sarebbe ingestibile per chiunque non fosse una multinazionale con un team dedicato di trenta persone. Una software house di dieci o quindici persone non può permettersi di avere due figure full-time su questa funzione, e infatti oggi non ce l'ha. Ma con assistenza AI ben configurata una sola persona, ben formata, può presidiare la compliance di tutti i progetti dell'azienda con una qualità che cinque anni fa avrebbe richiesto un piccolo team. La domanda da porre, quindi, non riguarda se l'AI sostituirà il compliance engineer, ma riguarda esattamente l'opposto. Senza AI il compliance engineer non esisterebbe come ruolo accessibile alle PMI, esisterebbe solo come reparto delle grandi aziende. Con AI, diventa la figura di sintesi che permette anche alle organizzazioni di dimensioni medie di operare in mercati regolati senza esternalizzare la propria intelligenza normativa. ## Una distanza istituzionale {: #distanza-istituzionale } La ricostruzione di come si sono formate le condizioni perché questa figura emergesse merita qualche dettaglio, perché la sua genesi è tipicamente italiana ed europea, e capire la genesi serve a capire perché il mestiere ha la forma che ha. Il punto di partenza è una distanza istituzionale fra due tradizioni accademiche e professionali che in Italia, più che altrove, non si sono mai incontrate seriamente. Da un lato l'ingegneria informatica, formata nelle facoltà di ingegneria, con un'attenzione storica al funzionamento del software inteso come oggetto tecnico. Dall'altro il diritto, formato nelle facoltà di giurisprudenza, con un'attenzione storica alle norme intese come testi da interpretare. Le due tradizioni non si parlano, non perché non ci siano persone di buona volontà che provano a costruire ponti, ma perché i programmi formativi non prevedono il ponte come oggetto di studio strutturato. L'ingegnere esce dall'università sapendo scrivere codice e progettare sistemi, ma con un'esposizione al diritto che si limita, nei casi migliori, a un corso semestrale di diritto dell'informatica spesso erogato da un docente che il software lo ha studiato come fenomeno e non come pratica. Il giurista esce dall'università sapendo interpretare norme, ma con un'esposizione al software che si limita, nei casi migliori, a qualche convegno e a qualche manuale divulgativo. Questa distanza non era un problema serio finché il software era valutato sulla base di criteri funzionali, prestazionali e commerciali. Quando il software ha cominciato a essere valutato anche su criteri normativi, il problema è esploso, perché le organizzazioni si sono ritrovate a dover certificare al regolatore che il loro sistema rispettava obblighi che né i loro sviluppatori né i loro legali sapevano tradurre completamente. Il GDPR, applicato dal maggio 2018, è stato il primo test serio. Per anni la risposta delle aziende italiane è stata quella di esternalizzare la compliance a consulenti specializzati, che producevano documenti adeguati ma raramente entravano nel codice, oppure di nominare un Data Protection Officer interno o frazionato che parlava con il legale ma poco con l'ingegneria. Funzionava male, ma funzionava abbastanza perché il GDPR, da solo, non era sufficiente a generare la pressione necessaria a far emergere una nuova figura professionale. La pressione necessaria è arrivata negli ultimi tre anni con l'accumularsi degli atti del pacchetto regolatorio europeo sul digitale. AI Act, Cyber Resilience Act, revisione della Product Liability Directive, NIS2, Digital Operational Resilience Act per il settore finanziario, Data Act, European Accessibility Act. Ognuno di questi regolamenti, preso singolarmente, sarebbe stato gestibile con i metodi tradizionali. Presi insieme, e nei tempi compressi in cui sono entrati o stanno entrando in vigore fra il 2024 e il 2027, hanno reso la situazione strutturalmente diversa. Le organizzazioni che producono software per il mercato europeo si sono ritrovate ad avere obblighi documentali, di valutazione del rischio, di sicurezza, di tracciabilità, di accountability che si moltiplicano e si intersecano in modi che richiedono una visione integrata. Il consulente esterno che produce un documento alla volta non basta. Il legale interno che non legge il codice non basta. Lo sviluppatore senior che spiega il sistema agli auditor due volte all'anno non basta, e nemmeno la combinazione delle tre figure messe a coordinarsi in riunioni periodiche basta, perché il coordinamento per riunioni periodiche è esattamente il dispositivo che genera il debito di specifica. Serve qualcuno che faccia solo questo, e che lo faccia tutti i giorni, dentro l'organizzazione. ## Tre fette in una persona sola {: #tre-fette } Su un piano di tassonomia delle figure professionali, quello che sta succedendo è che il compliance engineer sta assorbendo fette di lavoro oggi distribuite fra tre ruoli distinti. Prima fetta, il dev senior che oggi spiega il sistema agli auditor. È una figura che esiste in quasi tutte le organizzazioni di una certa dimensione, ed è quasi sempre un senior che sa il sistema da anni e che viene tirato fuori dai progetti di sviluppo per fare presentation alle parti terze. Fa il lavoro malvolentieri perché non è quello per cui è stato assunto, lo fa con qualità mediocre perché non ha gli strumenti documentali per farlo bene, e occupa il suo tempo in attività che sottraggono valore al ruolo principale. Seconda fetta, l'architetto che oggi traduce i requisiti normativi in scelte di design. Anche questa è una figura presente quasi ovunque, ed è di solito un architect che si è auto-formato sui regolamenti perché qualcuno doveva farlo, e che lo fa nel tempo libero dalle decisioni tecniche, con il risultato che le sue scelte di design sono prudenti per eccesso quando i regolamenti sono ambigui, e che spesso sovra-regolamenta il sistema generando attriti operativi inutili. Terza fetta, il legale interno o il consulente compliance che oggi prova a leggere il codice senza saperlo leggere. Questa è la figura più frustrata di tutte, perché ha la responsabilità formale ma non ha gli strumenti tecnici per esercitarla, e finisce per chiedere ai dev cose che i dev non sanno tradurre in pratica, generando un loop comunicativo che produce documenti formalmente corretti ma sostanzialmente inerti. ## Una giornata tipo {: #giornata-tipo } Il compliance engineer prende le tre fette e le riunisce in una persona sola, con un tempo dedicato e con strumenti dedicati. Una giornata tipo, in un'azienda media che produce software per clienti regolati, comincia con la rassegna dei ticket della settimana per identificare quali modifiche di codice impattano la compliance. Continua con una sessione di lavoro su una pull request specifica per discutere con il reviewer architetturale gli effetti di una modifica sui flussi dati personali. Prosegue con una call con il legale interno per chiarire una clausola contrattuale che il cliente ha proposto e che potrebbe entrare in tensione con la nostra Appendice tecnica di sicurezza. Pomeriggio di lavoro sull'aggiornamento della DPIA del progetto X, perché il fornitore terzo ha cambiato data center di hosting e questo modifica la mappatura dei flussi transfrontalieri. Chiusura con una riunione di sprint planning dove il compliance engineer presenta i requisiti di documentazione dei prossimi tre task, in modo che il team sappia cosa deve produrre oltre al codice. Niente di tutto questo è giuridico in senso stretto, niente è tecnico in senso stretto. Tutto è tecno-giuridico, ed è la natura ibrida del lavoro a giustificare la figura. ## Le due degenerazioni {: #due-degenerazioni } Il rischio della figura, e bisogna nominarlo in modo esplicito perché è il rischio principale, è che possa degenerare in due direzioni patologiche entrambe già osservabili. La prima degenerazione è il compliance engineer come gate-keeper burocratico che blocca i rilasci. È la versione più visibile e più dannosa, perché mette il presidio compliance contro il delivery, e quando questa contrapposizione si stabilizza l'organizzazione perde sia in velocità sia in qualità della compliance. Il gate-keeper produce checklist sempre più lunghe, richiede approvazioni sempre più articolate, ritarda i rilasci con motivazioni che agli sviluppatori sembrano formalismi, e finisce per essere percepito come un costo da minimizzare anziché come un investimento da preservare. La seconda degenerazione, opposta nei sintomi ma identica nella radice, è il compliance engineer come decoratore di policy che firma documenti senza leggere il codice. Questo lo si vede di più nelle aziende dove la figura viene introdotta perché la richiede un cliente regolato o un audit imminente, e dove l'incarico viene affidato a una persona scelta per la sua disponibilità a sopportare carichi documentali piuttosto che per la sua capacità di leggere effettivamente il sistema. Il decoratore produce documenti perfetti dal punto di vista formale, riempie tutti i campi richiesti, fa firmare al management, e nel frattempo il sistema reale evolve in direzioni che il documento non descrive più. È esattamente la condizione che ho chiamato debito di specifica nel pezzo precedente di questa serie, e che il compliance engineer dovrebbe contrastare ma che invece contribuisce a generare se interpretato male. Entrambe le degenerazioni hanno una causa comune, ed è la mancanza di formazione strutturata della figura. Quando il mestiere non ha un percorso accademico di riferimento, ognuno se lo costruisce a partire dalla propria provenienza. Lo sviluppatore che diventa compliance engineer porta con sé il pregiudizio che la compliance sia una funzione di servizio del codice, e tende a sottovalutare le conseguenze giuridiche delle scelte tecniche. Il legale che diventa compliance engineer porta con sé il pregiudizio opposto, che il codice sia una funzione di servizio della norma, e tende a sovra-regolamentare con conseguenze tecniche e organizzative pesanti. Una terza traiettoria, sempre più frequente, è quella del sistemista che diventa compliance engineer per affinità naturale con le pratiche documentali, e che tende a costruire pipeline di certificazione che vivono parallele e mai congiunte rispetto al ciclo di sviluppo applicativo. Esiste anche una quarta traiettoria, più rara ma più promettente, quella di chi arriva alla figura per percorsi misti, ad esempio chi ha lavorato per anni in product management su prodotti regolati e ha sviluppato sensibilità a entrambi i lati della frattura. Nessuna delle prime tre traiettorie produce, da sola, un compliance engineer all'altezza del compito. Producono mezze figure che funzionano in alcune aziende e in alcuni contesti, e che falliscono altrove. ## Una doppia competenza vera {: #doppia-competenza } Quello che servirebbe, e che oggi non esiste, è un percorso formativo strutturato che parta dall'assunzione che la disciplina è genuinamente bicipite, ingegneristica e giuridica al tempo stesso, e che entrambe le metà richiedono solidità non superficialità. L'ingegneria del software del compliance engineer si distingue dalla versione semplificata e generalista che si trova nei corsi divulgativi, e richiede ingegneria del software vera, con padronanza di architetture distribuite, sicurezza applicativa, ciclo di vita del codice, pratiche DevOps, modellazione dati. La compliance del compliance engineer, allo stesso modo, va oltre la versione operativa e checklist-driven che si trova nei corsi delle business school, e richiede giurisprudenza europea vera, con padronanza dei Regolamenti, capacità di lettura dei considerando, conoscenza della giurisprudenza della Corte di Giustizia, capacità di anticipare l'evoluzione interpretativa delle Autorità nazionali. Una persona che ha tutto questo non si forma in un master di sei mesi, si forma in qualche anno di lavoro guidato da mentor seri, e i mentor seri sono ancora pochi. L'università italiana, da questo punto di vista, è strutturalmente in ritardo. I corsi di laurea in ingegneria informatica, anche i migliori, dedicano alla compliance regolatoria un ammontare di ore irrisorio rispetto al peso che questa disciplina ha assunto nel mercato. I corsi di laurea in giurisprudenza, anche i migliori, dedicano al software in quanto oggetto regolato un ammontare di ore irrisorio rispetto alla centralità che il software ha nell'economia. Esistono master post-lauream che provano a colmare il gap, e alcuni sono fatti bene, ma sono master, cioè formazioni complementari di sei o dodici mesi che non costruiscono la doppia competenza dalle fondamenta, la sovrappongono a una competenza preesistente. Il risultato è che le aziende che cercano compliance engineer non li trovano formati dal sistema universitario e devono auto-formarli internamente, con i tempi e i costi che questo comporta. È una distorsione di mercato classica, in cui la domanda esiste e l'offerta non si è ancora consolidata, e produce posizioni vacanti per mesi e RAL volatili. ## Le grandi consultancy e il vuoto {: #grandi-consultancy } Il segmento di mercato che invece si è già accorto del fenomeno, e che si sta muovendo per occuparlo prima degli altri, è quello delle grandi società di consulenza. È il fenomeno più visibile e più ambivalente, e va valutato senza moralismi ma con realismo. Le grandi consultancy hanno forza commerciale, presenza sui clienti corporate, processi industriali per il deployment di figure professionali, e budget per produrre formazione interna a velocità che le università non possono sostenere. Stanno costruendo offerte di "compliance as a service" che impacchettano il lavoro del compliance engineer in pacchetti vendibili a peso. Il problema, e lo dico senza nominare nessun attore specifico perché il problema è categoriale e non individuale, è che la versione della figura che le grandi consultancy stanno costruendo è quasi sempre la versione decoratore di policy. È quella più scalabile commercialmente, più facile da vendere, più facile da industrializzare. Il compliance engineer come traduttore tecnico-giuridico vero, quello che entra nel codice e che modifica le scelte architetturali, non scala bene per modello consulenziale, perché richiede continuità sul cliente che il modello a progetti tipico delle grandi consultancy non fornisce facilmente. Il vuoto che le grandi consultancy non riusciranno a coprire, e che invece le software house italiane potrebbero coprire, è quello del compliance engineer interno alle organizzazioni che producono software per clienti regolati. Le software house di dimensione media, fra le dieci e le cinquanta persone, sono in posizione strutturalmente migliore per costruire questa figura rispetto sia alle grandi consultancy sia alle aziende regolate stesse. Hanno la prossimità tecnica al codice che le consultancy non hanno, hanno la pluralità di clienti che le aziende regolate non hanno, hanno la dimensione che permette di sostenere una persona dedicata senza doverla esternalizzare. Quello che molte software house italiane non hanno, ed è la ragione per cui non si stanno muovendo abbastanza velocemente, è la consapevolezza che la trasformazione è già in corso e che chi la copre per primo otterrà un vantaggio di posizione difficile da erodere nei cinque anni successivi. Su un piano operativo, costruire un compliance engineer interno significa investire fra i ventiquattro e i trentasei mesi su una persona che ha già metà delle competenze necessarie. Il candidato tipico è uno sviluppatore senior con curiosità per la dimensione regolatoria, oppure un architect con sensibilità ai temi di sicurezza e privacy, oppure una persona di product management con un certo gusto per la formalizzazione. La traiettoria di crescita prevede affiancamento a casi reali, lettura sistematica dei regolamenti europei nelle versioni inglese e italiana confrontate, partecipazione ad audit con clienti, redazione di DPIA e valutazioni di rischio sotto supervisione, costruzione di repository documentali, esposizione progressiva ai legali interni e ai consulenti esterni in modo da assorbire il vocabolario e le pratiche giuridiche per osmosi. È un investimento significativo per una software house piccola, ed è esattamente il tipo di investimento che produce un asset competitivo difficilmente replicabile. ## Disclosure: una traiettoria che abito {: #disclosure } Devo essere trasparente, perché su questo tema sto descrivendo un fenomeno di cui faccio parte, e l'analisi sarebbe disonesta se non lo dichiarassi. La traiettoria che sto descrivendo è quella che sto vivendo personalmente nella mia azienda, e una parte non secondaria del mio lavoro degli ultimi due anni è stata costruire il proprio compliance engineer dentro Oltrematica, occupando direttamente quella posizione mentre allo stesso tempo cerco di formalizzarla per chi verrà dopo. Non sto scrivendo questo pezzo come osservatore neutrale di una tendenza altrui, lo sto scrivendo come uno che la sta abitando dall'interno e che, dopo qualche anno di pratica, ha l'impressione di aver capito la forma che la figura sta prendendo, e di avere qualcosa da dire su cosa funziona e cosa non funziona. Non sono particolarmente felice né particolarmente orgoglioso di questa traiettoria. È semplicemente quello che il momento richiede a chi vuole continuare a fare software per clienti regolati senza esternalizzare la propria intelligenza normativa, e l'ho accettato come si accettano i compiti di transizione, sapendo che fra dieci anni la figura sarà ovvia e che oggi tocca costruirla a tentoni. ## Connessione, e una previsione {: #previsione } C'è una connessione diretta, e vale la pena renderla esplicita, fra la figura che sto descrivendo e i due saggi precedenti di questa serie. Nel pezzo che ho intitolato *[Cruft, non patina](/it/blog/cruft-non-patina/)* argomentavo che il software non sa invecchiare, perché il drift fra il codice e l'ambiente in cui gira lo erode più velocemente di quanto la cultura ingegneristica riesca a metabolizzare. Nel pezzo successivo, *[Il debito di specifica](/it/blog/il-debito-di-specifica/)*, argomentavo che la specifica del software invecchia in modo ancora peggiore del codice, perché manca la pratica continua che la mantenga viva, e che il quadro normativo europeo sta caricando questo invecchiamento di conseguenze giuridiche prima inesistenti. Il compliance engineer è la figura il cui mestiere è precisamente combattere il debito di specifica nel quotidiano, mantenere la specifica allineata al sistema mentre il sistema cambia, e farlo con la doppia competenza che permette di non cadere né nel formalismo del documento né nell'inerzia del codice. È la persona che, in un'organizzazione che produce software, presidia l'allineamento fra promessa scritta e comportamento osservato, sapendo che sotto il nuovo regime la coerenza fra i due piani è quello che il giudice valuterà se mai arriverà il giorno della valutazione. Il pezzo si chiude con una previsione che è anche un invito all'azione per chi mi sta leggendo da dentro un'organizzazione che fa software in Europa. Fra cinque anni, intorno al 2031, la figura del compliance engineer sarà ovvia. Ci saranno corsi di laurea, ci saranno certificazioni serie, ci saranno albi professionali in qualche forma, ci saranno rubriche fisse sui giornali specializzati. Quello che resta da capire non riguarda se accadrà, riguarda solo a quale velocità. Le organizzazioni che la stanno costruendo adesso, in modo artigianale e per necessità, avranno un vantaggio strutturale rispetto a quelle che aspetteranno la maturazione del mercato. Il vantaggio si gioca al di là del piano commerciale, è soprattutto cognitivo, perché chi sta abitando il ruolo oggi sta anche definendo le pratiche che diventeranno standard, e chi definisce le pratiche le definisce a misura del proprio modo di lavorare. **La figura del compliance engineer non è una nicchia, è il ruolo che sta ridisegnando il modo in cui il software europeo viene prodotto sotto il nuovo regime regolatorio.** Sta accadendo lentamente, in silenzio, in annunci confusi che cercano persone che non esistono ancora con titoli che cambiano da un mese all'altro. Quando gli annunci troveranno il loro nome stabile, e accadrà presto, l'industria si dividerà fra chi avrà investito su questa figura per tempo e chi si troverà a importarla a mercato consolidato pagandola il triplo. Chi sta leggendo dentro una software house italiana di dimensione media ha probabilmente in azienda, in questo momento, la persona giusta da formare. È un dev senior con la testa storta sui regolamenti, o un architect che ha cominciato da solo a leggere il GDPR per curiosità, o ancora un sistemista che si è preso a cuore la documentazione perché nessun altro la curava, e in qualche caso una figura più ibrida arrivata da percorsi misti che non rientrano in nessuna delle tre traiettorie classiche. Riconoscerlo e dargli un mandato esplicito, investendoci tempo e formazione strutturata, è la decisione manageriale che produrrà più valore composto nei prossimi cinque anni. Non perché la figura sia di moda. Perché senza, fra qualche anno, fare software per clienti regolati in Europa diventerà un mestiere che le software house italiane non potranno più permettersi. --- # Il debito di specifica - **URL:** https://margiovanni.it/it/blog/il-debito-di-specifica/ - **Pubblicato:** 2026-05-01 - **Tag:** Compliance, AI Act, PLD, Debito Tecnico, Filosofia Della Tecnica - **Tempo di lettura:** 21 min > Sul perché il documento che certifica il sistema invecchia peggio del codice che lo implementa, e su perché la prossima generazione di cause civili in materia di software si combatterà sulla specifica. ## L'audit clinico {: #audit-clinico } Ci sono documenti che si aprono solo nei momenti sbagliati. La DPIA del sistema di triage clinico è stata firmata nell'aprile del 2024 e archiviata nella cartella della compliance, da dove non è uscita più, come nessuna DPIA esce mai dalla cartella della compliance. Diciotto mesi dopo, qualcuno la apre. Non è un giurista, è un consulente arrivato per un audit di sicurezza, e la apre per ragioni di routine, perché vuole verificare che le misure dichiarate corrispondano a quelle implementate. Il documento descrive un sistema che usa un modello di scoring deterministico, addestrato su un dataset chiuso, con regole esplicite per la classificazione del livello di urgenza. Le finalità del trattamento sono quattro. Le basi giuridiche sono mappate al considerando corretto del Regolamento. I diritti degli interessati sono elencati uno a uno con le procedure operative per esercitarli. I flussi transfrontalieri non esistono, perché tutto resta nel data center europeo del fornitore. Il consulente legge, prende qualche appunto, poi alza gli occhi e chiede al CIO se può vedere il sistema in esecuzione. Il sistema in esecuzione è un altro. Tre mesi dopo la firma della DPIA il fornitore ha sostituito il modello deterministico con un classificatore neurale addestrato in continuo sui dati clinici degli ultimi sei mesi. Il dataset non è più chiuso. Le regole di classificazione non sono più esplicite. Le finalità ufficiali sono ancora quattro, ma una quinta funzione è stata aggiunta su richiesta del reparto di emergenza, ed è una funzione che la DPIA non contempla. I flussi transfrontalieri continuano a non esistere finché un giorno non esistono, perché il fornitore ha cambiato hyperscaler e adesso una porzione del traffico passa da un data center irlandese gestito da una controllata americana. Niente di tutto questo è documentato altrove. Il sistema funziona. Gli utenti sono contenti. Gli audit interni passano perché si limitano a verificare che il sistema esista e che produca output coerenti. Il consulente si volta verso il CIO e chiede chi ha autorizzato la quinta funzione. Il CIO risponde che è stata una richiesta urgente del primario di emergenza, gestita in una settimana, con il fornitore che ha rilasciato in produzione il giovedì successivo dopo un test in ambiente di staging. C'è un ticket in Jira che traccia la modifica, c'è una pull request approvata da due reviewer, c'è un changelog interno. Tutto in ordine sul piano operativo. Il consulente chiede se la DPIA è stata aggiornata. Il CIO lo guarda con l'espressione di chi non ha mai pensato che fosse necessario, perché la DPIA appartiene a un altro circuito, gestito da un'altra persona, in un'altra cartella, con tempi che non hanno niente a che vedere con i tempi del rilascio. Il consulente chiude la DPIA e non la chiama più DPIA. La chiama specifica fantasma, perché descrive un sistema che esiste solo sulla carta firmata. ## Una condizione ordinaria {: #condizione-ordinaria } La specifica fantasma, contrariamente a quello che si crede, è una condizione ordinaria. Chiunque abbia lavorato in un'organizzazione che produce software per un cliente regolato, o per sé stessa sotto regime regolato, sa che fra il documento che descrive il sistema e il sistema effettivamente in esercizio si apre, dopo qualche mese, una distanza che cresce ogni settimana e che nessuno ha incarico di richiudere. Non perché qualcuno menta. Perché il codice ha un metabolismo che la specifica non ha, e perché il ciclo di vita della specifica, nel software che facciamo davvero, non è gestito da nessuno strumento paragonabile a quelli che abbiamo per il codice. L'obiezione che si fa di solito a chi solleva questo punto è ragionevole, e va affrontata prima di andare avanti. L'obiezione dice: il codice è la specifica vera. La documentazione è una proiezione semplificata del comportamento del sistema, ed è in ritardo per definizione, dunque l'unica strategia sensata è tenere in ordine il codice e accettare che il resto sia letteratura. È il principio del *code as documentation* in versione un po' più sofisticata, e ha governato la cultura ingegneristica del software per almeno vent'anni. Funzionava perché si basava su un assunto implicito che oggi non è più vero, cioè che il software venisse valutato sulla base di quello che fa quando gira. ## Il nuovo statuto valutativo {: #statuto-valutativo } Il software, sotto il regime giuridico che si sta consolidando in Europa fra il 2024 e il 2027, non viene più giudicato solo sulla base di quello che fa. Viene giudicato sulla base di quello che ha promesso di fare, e la promessa vive nella specifica scritta, non nel codice eseguito. La revisione della Product Liability Directive, adottata a fine 2024 con termine di recepimento entro il 9 dicembre 2026, ha incluso esplicitamente il software nella nozione di prodotto. Significa che il produttore di software risponde dei danni causati da difetti del prodotto secondo un regime di responsabilità oggettiva. Su questo punto avevo già scritto qualche tempo fa il pezzo che ho intitolato *[L'ultima bottiglia di Mrs. Donoghue](/it/blog/lultima-bottiglia-di-mrs-donoghue/)*, riprendendo il caso fondativo della responsabilità del produttore nel diritto inglese del 1932 e proiettandolo sul software contemporaneo. Quello che lì avevo solo accennato, e che qui voglio mettere a fuoco, è la conseguenza epistemologica del nuovo regime. La nozione di difetto, sotto la responsabilità oggettiva, non coincide con il bug. Coincide con lo scarto fra ciò che ci si poteva legittimamente aspettare dal prodotto e quello che il prodotto ha effettivamente fatto. Le aspettative legittime, in mancanza di altri parametri, vengono ricostruite a partire dalla documentazione tecnica del prodotto, dalle dichiarazioni del produttore, dai materiali commerciali, dai requisiti di conformità mappati nelle valutazioni di rischio. Vengono ricostruite, cioè, dalla specifica. Il Cyber Resilience Act, applicabile in modo pieno dall'11 dicembre 2027, fa lo stesso movimento sul versante della sicurezza. La conformità si dimostra attraverso la documentazione tecnica del prodotto digitale, e questa documentazione include la valutazione dei rischi, le misure di sicurezza implementate, la SBOM aggiornata, le procedure di gestione delle vulnerabilità, il piano di supporto e gli aggiornamenti per il ciclo di vita del prodotto. L'AI Act, sui sistemi ad alto rischio, richiede una documentazione tecnica ancora più estesa, definita dall'Annex IV, che include la descrizione architetturale del sistema, i dataset usati per l'addestramento e le procedure di data governance, le metriche di performance e accuratezza, il sistema di gestione dei rischi previsto dall'Articolo 9, le procedure di monitoraggio post-rilascio. Sono regolamenti distinti, con ambiti di applicazione differenti, ma con una struttura epistemica identica. Il prodotto software ha cambiato statuto valutativo. Viene giudicato come la corrispondenza fra una promessa scritta e un comportamento osservato, e quando le due cose divergono, il giudice o l'autorità di vigilanza guarda la promessa scritta. Non perché creda che la specifica sia il sistema reale. Perché la specifica scritta è l'unico punto fermo su cui si possa fondare un giudizio. Una piccola precisazione di cornice serve qui per evitare un fraintendimento facile. Non sto dicendo che il regime europeo trasformi la specifica in un oggetto magico che vale a prescindere dal sistema. Il giudice o l'autorità non si limitano a leggere il documento e dichiarare la conformità. Confrontano il documento con il sistema, valutano la coerenza, accolgono perizie tecniche. Quello che cambia rispetto al regime precedente è che il documento smette di essere un'appendice del prodotto e diventa una parte costitutiva della valutazione, sullo stesso piano del comportamento del sistema. Quando i due divergono, il documento non viene più automaticamente liquidato come obsoleto. Il produttore deve spiegare perché ha rilasciato un sistema diverso da quello descritto, e questa spiegazione, in un contenzioso, è molto più costosa di quanto non lo sia oggi. ## Tutto per il codice, quasi nulla per la specifica {: #asimmetria-strumenti } A fronte di questo spostamento, l'industria dispone di un arsenale di strumenti per gestire il ciclo di vita del codice e di quasi nulla per gestire il ciclo di vita della specifica. Il codice ha il versionamento atomico, e quando una riga cambia c'è un commit con autore, data e messaggio. Ha il blame, che permette di risalire all'origine di ogni decisione visibile nel sorgente. Ha i test, che falliscono in modo automatico quando il comportamento devia da un'aspettativa codificata. Ha i deprecation warning, che segnalano una promessa in via di ritiro. Ha il refactor sicuro, supportato da type system e da suite di regressione. Ha la code review, ritualizzata in pull request che lasciano traccia. Ha l'integrazione continua, che impedisce a un cambiamento incompatibile di entrare nel ramo principale senza essere visto. Ha le branch protection rules, che impediscono fisicamente di scavalcare il processo. Ha il rollback in un comando, che riduce il costo dell'errore. Ognuno di questi strumenti è il prodotto di una pressione ingegneristica accumulata negli ultimi trent'anni e oggi è infrastruttura della pratica quotidiana, talmente metabolizzata che chi entra adesso nel mestiere la dà per scontata e fatica a immaginare un mondo senza. La specifica ha la sua versione, e basta. Una DPIA viene firmata, datata, archiviata in PDF, e nel momento in cui il sistema cambia non c'è alcun meccanismo automatico che dica al firmatario o al delegato che la sua firma copre adesso un sistema diverso. Le architetture decisionali registrate nelle ADR si accumulano in Confluence, in Notion, in cartelle SharePoint, e nessuno le rilegge a meno che un audit specifico non le richieda. I requisiti di sicurezza allegati ai contratti vengono firmati, depositati nel CRM, e da quel momento esistono come allegati di backoffice fino al rinnovo. Le valutazioni di rischio prodotte per la conformità all'AI Act sui sistemi ad alto rischio richiederanno aggiornamenti periodici, ma il meccanismo che lega l'aggiornamento alle modifiche concrete del sistema sarà, nella stragrande maggioranza dei casi, un calendario o un trigger contrattuale, non un evento di codice. La specifica, a differenza del codice, non ha nessuna pressione interna a stare aggiornata. Sopravvive in una zona di tempo lento dove la firma vale più della freschezza, e dove l'invecchiamento non si manifesta come degrado funzionale ma come progressivo allontanamento dalla realtà che il documento dovrebbe descrivere. Le ragioni di questa asimmetria sono di ordine culturale. Tecnicamente, gli strumenti per trattare le specifiche con la stessa serietà del codice esistono da decenni. Le specifiche eseguibili in stile BDD, le test specification scritte in Gherkin, i contratti formali in linguaggi come TLA+ o Alloy, le specifiche di interfaccia in OpenAPI o gRPC, le proof assistant come Lean o Coq. Ognuno di questi sistemi presuppone che la specifica sia un artefatto di prima classe, eseguibile o verificabile, vivo nel repository accanto al codice. Nella pratica industriale, niente di tutto questo è la norma. La norma è che la specifica vive in un documento Word, viene rivista da una persona del legale o della compliance, viene firmata, viene archiviata, e da quel momento il suo destino è separato da quello del codice. ## L'origine agile {: #origine-agile } L'origine di questa separazione è storica e merita di essere ricostruita con qualche dettaglio. La cultura del software è cresciuta in opposizione alla cultura della documentazione, perché la documentazione era percepita come un'imposizione del management ingegneristico in stile waterfall, e l'agile ha vinto fra le altre cose perché ha promesso di ridurre il peso del documento a favore del codice funzionante. Il Manifesto Agile, firmato a Snowbird nel febbraio del 2001, recita esplicitamente «working software over comprehensive documentation». La formulazione era cauta, perché alla fine del documento gli autori scrivevano «while there is value in the items on the right, we value the items on the left more», quindi la documentazione veniva ridimensionata, non abolita. Ma la lettura industriale dei due decenni successivi è stata più drastica della formulazione originale. La documentazione comprensiva è diventata sinonimo di documentazione superflua, e i progetti che osavano produrre più di un README, qualche commento e una manciata di diagrammi venivano sospettati di pratiche waterfall residuali. La promessa era sensata nel suo contesto, perché il software che si scriveva nei primi anni Duemila era valutato sulla base di criteri funzionali e commerciali, e il documento era effettivamente un costo che produceva poco valore informativo dopo le prime settimane di vita del progetto. Era anche un costo politico, perché spesso veniva usato per imporre processi di gate-keeping che rallentavano il lavoro senza aggiungere qualità. Quello che è cambiato, e che la cultura ingegneristica non ha ancora metabolizzato, è il contesto di valutazione. Il software che scriviamo oggi viene venduto in mercati regolati, integrato in catene di fornitura che lo trattano come componente certificato, sottoposto a obblighi di conformità che richiedono documentazione vivente. Il documento ha cessato di essere lo strumento interno di una burocrazia che vuole controllare gli sviluppatori. È diventato lo strumento attraverso cui il prodotto si presenta al regolatore, al cliente regolato, al giudice eventuale. La cultura ingegneristica continua a trattare la specifica come un sottoprodotto del processo, mentre il quadro normativo la sta promuovendo ad artefatto primario. Lo scarto fra queste due percezioni è il terreno in cui il debito di specifica cresce indisturbato. ## Spec-driven, BDD, e i loro limiti {: #spec-driven-limiti } Sarebbe disonesto fingere che non esistano tentativi di chiudere questo gap, e alcuni di questi tentativi sono seri. Lo *spec-driven development* nella forma che ha preso negli ultimi due anni, con strumenti come SpecKit di GitHub e con la pratica di tenere un `CLAUDE.md` per progetto come briefing di contesto per agenti AI, prova a spostare il baricentro del lavoro a monte del codice. La specifica diventa l'input di generazione assistita per un agente che produce codice, test e documentazione di accompagnamento in un singolo passaggio coerente. La promessa è che la specifica sia eseguibile, nel senso che produce un sistema, e quindi mantenuta dalla pressione di generare codice funzionante. È una direzione interessante, e nei progetti dove l'ho applicata ha cambiato l'economia del lavoro in modo non banale. Il tempo che prima spendevo a tradurre i requisiti in codice si è ridotto, ma è cresciuto il tempo speso a scrivere requisiti precisi, e questo è un trade-off favorevole, perché la precisione ha un valore residuo anche quando il codice viene riscritto. Il limite che vedo, dopo qualche mese di pratica, è che lo spec-driven development risolve la sincronizzazione fra specifica e codice nel momento della prima generazione, e questo è un guadagno reale, ma non risolve la deriva successiva. Quando il sistema entra in produzione e viene modificato in risposta a richieste dei clienti, a incidenti, a cambiamenti dell'ambiente operativo, la specifica formalizzata può essere aggiornata oppure può non esserlo, e gli incentivi pratici giocano contro il suo aggiornamento. Aggiornare la specifica costa tempo e rigore, e costringe a una negoziazione fra chi ha scritto la modifica al volo e chi è custode del documento. Sotto pressione di delivery, il documento perde. Il codice in produzione vince sempre, perché è la cosa che gli utenti usano. La specifica torna a essere un fantasma, anche quando è stata scritta in un linguaggio formale. Le specifiche eseguibili tipo BDD hanno lo stesso problema, in versione attenuata. Una suite Gherkin che descrive il comportamento del sistema rimane sincronizzata finché qualcuno la fa fallire e la riallinea, ma quando la pressione di delivery sale gli scenari vengono saltati, marcati come pending, eliminati. Ho visto suite di centinaia di scenari ridursi a poche decine in un anno e mezzo, non perché i comportamenti descritti fossero spariti dal sistema, ma perché la suite era diventata un attrito che il team non aveva più tempo di gestire. La specifica eseguibile resta più resistente di una DPIA, perché è codice e quindi soggetta agli incentivi del codice, ma non è immune dalla deriva. È solo più lenta a derivare. E c'è un secondo problema più sottile. Le specifiche eseguibili coprono bene il comportamento funzionale, cioè la parte del sistema che si può verificare in modo automatico. Coprono molto meno la parte del sistema che la nuova compliance europea richiede di documentare, cioè la valutazione dei rischi, le scelte architetturali, le finalità del trattamento, le misure di mitigazione. Quella parte sfugge all'automazione, perché non è comportamentale, e resta costitutiva del prodotto come oggetto giuridico. Nessun framework di test ti dice se è ancora coerente con il sistema. ## Sottocategoria, non sinonimo {: #sottocategoria } Si potrebbe obiettare, a questo punto, che il debito di specifica è già incluso nel concetto generale di debito tecnico, e che parlarne separatamente è un modo elegante per riscoprire la luna. L'obiezione è formalmente corretta. Le tassonomie del debito tecnico che si sono sviluppate nei due decenni successivi alla formulazione originaria di Ward Cunningham, in particolare i lavori di Martin Fowler e di chi ha rifinito il quadrante delle cause, includono la documentazione obsoleta come una delle forme di debito. La distinzione che propongo è di natura economica più che concettuale. Il debito tecnico classico ha incentivi naturali al pagamento, perché ti rallenta, ti irrita ogni giorno, ti costa onboarding e tempo di sviluppo. Il debito di specifica ha incentivi quasi assenti finché non arriva un evento scatenante, e gli incentivi che ha sono burocratici e calendarizzati, non operativi. Questa differenza giustifica trattarlo come una sottocategoria con dinamiche proprie, soprattutto adesso che il quadro normativo lo sta caricando di valore in modo asimmetrico rispetto alle altre forme di debito. Quello che chiamo debito di specifica è la versione invisibile del debito tecnico. Il debito tecnico è il prezzo che paghi sotto forma di lentezza di sviluppo, di bug ricorrenti, di difficoltà di onboarding. È un prezzo che paghi continuamente, in piccole rate, e che ti motiva a investire nel rifattoring perché senti il dolore. Il debito di specifica non lo senti. Non rallenta lo sviluppo, perché chi sviluppa non legge la specifica, e quando la legge la trova spesso utile come riferimento storico ma non vincolante. Non genera bug, perché il codice è già la specifica vera dal punto di vista dell'esecuzione. Non ostacola l'onboarding, perché chi entra nel team impara dal codice e dai colleghi, non dai documenti archiviati. Il debito di specifica produce un solo tipo di danno, e lo produce quando arriva un evento che ti costringe a confrontarti con la specifica come oggetto vincolante. Un audit di parte terza. Un incidente di sicurezza che diventa caso giudiziario. Una richiesta di accesso ai dati personali a cui non sai rispondere perché la mappatura dei trattamenti era stata fatta su un sistema diverso. Una contestazione di un cliente che ha letto il contratto e dichiara, con qualche ragione, di aver acquistato qualcosa che non gli è stato consegnato. Quando arriva quell'evento, il debito di specifica diventa visibile tutto in una volta, e il prezzo è asimmetrico rispetto al debito tecnico. Il debito tecnico lo paghi a rate, il debito di specifica lo paghi in un'unica soluzione, di solito più alta della somma delle rate che avresti pagato gestendolo nel tempo. C'è anche una differenza di natura nel costo. Il debito tecnico lo paghi in tempo di sviluppo, e questo tempo lo controlli tu. Il debito di specifica lo paghi in tempo di legali, di consulenti esterni, di audit straordinari, di rimedi imposti, e di reputazione, che è la valuta più costosa di tutte perché non si rifinanzia. C'è infine una differenza temporale che nessuno nota finché non gli capita addosso. Il debito tecnico si paga gradualmente, mentre lavori. Il debito di specifica si paga di colpo, mentre stai facendo altro, e di solito in un momento in cui non hai margine. Le crisi che lo rivelano arrivano sempre nel peggior momento possibile, perché sono il momento in cui qualcun altro ha deciso di guardare quello che tu non hai guardato. ## Archeologia e asset {: #archeologia-asset } In questi mesi mi è capitato di lavorare a una valutazione di compliance per un sistema di gestione di flussi clinici sviluppato per un grande ospedale di ricerca, e il committente del committente, cioè la fondazione clinica finale, aveva richiesto un'appendice di sicurezza con dieci domini di controllo da mappare al GDPR Articolo 28 e a una lista di requisiti specifici di settore. La specifica originaria del sistema era stata redatta tre anni prima, in un momento in cui il sistema era una piattaforma di raccolta dati relativamente semplice. Nel frattempo il sistema era cresciuto, aveva acquisito moduli di elaborazione, era stato connesso a sistemi terzi, aveva cambiato fornitore di hosting. La distanza fra il documento di partenza e il sistema attuale era enorme. Il lavoro che ho dovuto fare per sei settimane consisteva sostanzialmente nel ricostruire la specifica a partire dal sistema, cioè nel fare reverse engineering del comportamento per scrivere un nuovo documento che fosse coerente con la realtà. Il dettaglio operativo di questo lavoro è istruttivo, perché racconta cosa significa davvero gestire il debito di specifica quando viene chiamato in causa. Ho dovuto parlare con sei persone diverse, ognuna depositaria di un pezzo di conoscenza non documentata. Ho dovuto leggere il codice di tre microservizi che erano stati aggiunti dopo la firma della DPIA. Ho dovuto rintracciare un fornitore esterno per chiedergli quale algoritmo di anonimizzazione applicava ai dati che ci passava, perché nessuno nel team interno lo sapeva con precisione. Ho dovuto ricostruire il flusso dei dati personali fra cinque sistemi diversi guardando le configurazioni di rete e i log applicativi, perché il diagramma originale era diventato inservibile. Tutto questo lavoro era estraneo allo sviluppo. Era pura ricostruzione di una verità documentale che avrebbe dovuto essere mantenuta nel tempo e che invece doveva essere riscritta da capo. Era esattamente l'operazione che il regime normativo presuppone non sia mai necessaria, perché la specifica dovrebbe essere stata mantenuta lungo il percorso, ed era esattamente l'operazione che è quasi sempre necessaria, perché il percorso non è mai gestito così. Su un altro progetto, una piattaforma di valutazione del rischio legale per uno studio specializzato, abbiamo deciso a un certo punto di migrare l'intero stack da Python a Laravel 12. La migrazione è in corso e siamo intorno al settantotto per cento del completamento. Quello che ho imparato in questa migrazione è che il vero asset trasferito non era il codice, era la specifica funzionale. Il codice Python è stato in larga parte buttato e riscritto, il modello dati è stato ridisegnato, le scelte di framework sono cambiate radicalmente. Quello che è sopravvissuto è la conoscenza precisa, formalizzata nella documentazione di prodotto e nei contratti con il cliente, di cosa il sistema deve fare, in che ordine, con quali vincoli, con quali interfacce verso fonti esterne. Senza questa specifica, la migrazione sarebbe stata impossibile. Con questa specifica, e con un team che la trattava come riferimento attivo durante il lavoro, la migrazione è stata difficile ma fattibile. La differenza fra questo progetto e il caso clinico raccontato prima è una differenza di pratica, non di natura della specifica. In entrambi i casi esisteva una specifica scritta. Nel caso clinico la specifica era stata firmata e poi abbandonata. Nel caso della migrazione la specifica era stata letta ogni due settimane in retrospettiva, contestata quando il team trovava incoerenze, modificata quando una scelta di prodotto cambiava, integrata quando una funzione veniva aggiunta. Era un oggetto vivente nel processo, non un cimelio della compliance. È la stessa distinzione che separa un manuale di volo che il pilota legge prima di ogni decollo da uno stesso manuale archiviato in biblioteca. Lo stesso testo, due funzioni completamente diverse, e due valori operativi non confrontabili. La specifica come asset trasferibile, e la specifica come asset che invecchia o non invecchia in base a come la trattiamo, sono due facce della stessa cosa. ## Strumenti che ancora non abbiamo {: #strumenti-mancanti } Un'ipotesi che mi sembra ragionevole è che il prossimo decennio dell'ingegneria del software sarà definito da strumenti per il ciclo di vita della specifica analoghi a quelli che il decennio scorso ha definito per il ciclo di vita del codice. Già oggi cominciano a vedersi i primi tentativi seri. Sistemi di tracciabilità che legano i requisiti della specifica ai test che li verificano, e i test alle modifiche di codice che li toccano, di modo che quando un test cambia il sistema sappia quale requisito è stato impattato e chieda l'aggiornamento del documento. Strumenti di drift detection sulle architetture, che confrontano la topologia di servizio dichiarata con la topologia osservata e segnalano divergenze. Versionamento delle DPIA in repository git con review obbligatorie a ogni modifica strutturale del sistema. Specifiche di prodotto che vivono come oggetti versionati a fianco del codice, con CI che fallisce quando lo scarto fra specifica e implementazione supera una soglia. Provo a immaginare come potrebbe essere la pratica quotidiana fra cinque anni in un team che ha metabolizzato questa svolta. La DPIA ha cambiato forma e vive come file YAML in un repository protetto, con storico delle versioni, autori delle modifiche, processo di approvazione attraverso pull request. Quando uno sviluppatore introduce un nuovo trattamento di dati personali, una pipeline di analisi statica sul codice rileva il nuovo flusso e marca automaticamente la pull request come «DPIA-impacting». Il merge resta bloccato finché il responsabile della protezione dati non rivede e approva la modifica corrispondente al documento di trattamento. Le valutazioni di rischio dell'AI Act seguono un meccanismo analogo, con drift detector che segnalano quando il modello in produzione si discosta dalle metriche dichiarate nella documentazione tecnica. Le SBOM si aggiornano automaticamente a ogni build e producono diff leggibili che entrano nei changelog di prodotto. Tutto questo non elimina il lavoro di compliance, ma lo trasforma da archeologia ricostruttiva, come quella che ho fatto per sei settimane sul sistema clinico, a manutenzione continua, integrata nello stesso ritmo del lavoro di sviluppo. Il salto culturale da fare è capire che documentare il sistema, sotto questo nuovo regime, costituisce la costruzione dell'asset giuridicamente rilevante del prodotto, e non un costo amministrativo da minimizzare. Chi non lo fa adesso lo farà fra cinque anni dopo aver perso una causa, e a quel punto sarà più costoso. ## Corpo e anima {: #corpo-e-anima } Qualche mese fa, su questo blog, ho scritto un pezzo che si chiama *[Cruft, non patina](/it/blog/cruft-non-patina/)*, e l'argomento principale era che il software non sa invecchiare come gli oggetti materiali, perché il drift fra il codice e l'ambiente in cui gira lo erode più velocemente di quanto la cultura ingegneristica riesca a metabolizzare. C'era un passaggio che parlava di Unix come eccezione, perché in Unix la specifica si è staccata dal codice ed è diventata cultura, sopravvivendo attraverso cicli di riscrittura integrale del corpo. Quel passaggio chiudeva con una nota di ottimismo cauto sul fatto che la specifica, quando si stacca, è il piano stabile che attraversa il cambiamento. Devo qualificare quella nota. La specifica si stacca dal codice in due modi diversi, e la differenza fra i due decide tutto. Il primo modo è quello di Unix, in cui la specifica diventa cultura condivisa, descritta in libri canonici, mantenuta attraverso una comunità che la sa applicare a contesti nuovi, e quindi si rinnova senza perdere identità. Il secondo modo è quello della DPIA archiviata, in cui la specifica diventa un documento firmato che non viene più letto, e quindi resta identica a sé stessa mentre il sistema diventa un'altra cosa. Nel primo caso lo stacco produce continuità. Nel secondo caso lo stacco produce specifica fantasma. La differenza fra i due modi non sta nella natura della specifica. Sta nelle pratiche di chi la usa. Una specifica che viene letta, contestata, modificata, ridiscussa, applicata a casi nuovi, è una specifica che vive. Una specifica che viene scritta, firmata, archiviata, e poi ignorata fino al prossimo audit, è una specifica che muore lentamente mentre nessuno la guarda. Mettendo i due saggi insieme, l'argomento generale che provo a costruire è questo. Il software ha un problema doppio con il tempo. Da un lato il codice non sa invecchiare, perché il suo ambiente cambia troppo veloce e il drift lo trasforma in *cruft* anziché in patina. Dall'altro lato la specifica, che potrebbe essere il piano stabile che attraversa la riscrittura del codice, riesce a esserlo solo quando una pratica costante la mantiene viva, e nella stragrande maggioranza dei casi questa pratica non c'è. Il risultato è che il software, sotto il regime giuridico che si sta consolidando in Europa, sta entrando in un'epoca in cui sia il corpo che l'anima del prodotto sono fragili, e in cui l'unica cosa che può tenere insieme i due piani è una disciplina di manutenzione documentale che la cultura ingegneristica deve ancora costruire. La cultura ingegneristica del software non ha ancora distinto le due cose con la chiarezza che serve, perché ha trattato a lungo la specifica come un sottoprodotto. Il quadro normativo che si sta consolidando in Europa la sta costringendo a fare quella distinzione, e il prezzo dei prossimi anni sarà pagato da chi non se ne accorge in tempo. **Il debito di specifica è il debito tecnico che non si vede finché qualcuno non si fa male.** Lo stiamo accumulando in silenzio, in cartelle SharePoint che nessuno apre, in PDF firmati che non sono più una rappresentazione fedele dei sistemi che certificano, in DPIA depositate sul server della compliance come se fossero monumenti. Il primo grande caso giudiziario europeo sulla responsabilità del software per difetto, sotto il nuovo regime della Product Liability Directive, sarà combattuto sulla specifica. Quando arriverà, e arriverà presto, l'industria si dividerà fra chi avrà tenuto in vita la propria specifica e chi avrà solo continuato a firmarla. --- # La forma che il giorno ha perso - **URL:** https://margiovanni.it/it/blog/la-forma-che-il-giorno-ha-perso/ - **Pubblicato:** 2026-04-29 - **Tag:** Benessere, Intelligenza Artificiale, Lavoro, Tempo, Filosofia Della Tecnica - **Tempo di lettura:** 7 min > C'è una stanchezza diffusa che non sappiamo nominare. Non viene dal fare di più: viene dal vivere dentro un tempo che ha perso la sua forma. L'AI non accelera l'attività, la sostituisce con un'altra — e il corpo, calibrato in anni, non riesce più a leggere la giornata. ## Il mercoledì sospeso {: #mercoledi-sospeso } È mercoledì pomeriggio. Hai appena finito in venti minuti un compito che sei mesi fa ti avrebbe portato via mezza giornata. Lo schermo è fermo. Il pomeriggio si apre davanti. Per ogni metrica esterna dovresti sentire qualcosa di simile al trionfo. Invece c'è una stanchezza sorda, ingiustificata, che non sai a cosa attribuire. Le ore risparmiate non si sono aggiunte alla tua vita. Hanno solo reso il giorno strano. La spiegazione di default — quella secondo cui siamo stanchi perché abbiamo compresso più cose nella stessa giornata — è sbagliata, o quantomeno insufficiente. Molti di noi stanno facendo meno, in tempo da orologio, e si sentono più svuotati. La fatica non è quantitativa, è di tessitura. Qualcosa, nel modo stesso in cui viviamo la giornata lavorativa, si è spostato, e non abbiamo ancora le parole per dirlo. ## Tempo da orologio, tempo vissuto, e una terza cosa {: #una-terza-cosa } Da più di un secolo la filosofia distingue due modi di abitare il tempo. C'è il tempo matematico, quello degli orologi e degli orari, divisibile e uniforme. E c'è il tempo vissuto, quello che Bergson chiamava *durée*: il tempo dell'esperienza, in cui dieci minuti di attesa sembrano più lunghi di un'ora di immersione. I due erano sempre in tensione, ma correvano grosso modo paralleli. Una giornata di lavoro aveva otto ore di tempo da orologio e una forma sentita che più o meno vi corrispondeva, con un inizio pesante e un finale che si poteva anticipare. Sapevamo dove eravamo dentro la giornata anche senza guardare l'ora. L'AI introduce una terza cosa che non è mai esistita prima. L'orologio continua a ticchettare uniforme. L'esperienza vissuta ha ancora le sue variazioni. Ma la superficie dei costi delle attività è diventata selvaggiamente irregolare, e non in un modo che il corpo possa prevedere. Un compito che ieri ha consumato tre ore oggi ne richiede venti minuti. Un altro compito, simile in apparenza, richiede ancora tre ore. Non c'è regola. L'asimmetria è locale, e arriva senza preavviso. Si passa da un regime in cui il lavoro è arduo a uno in cui è banale, e poi di nuovo, più volte nello stesso pomeriggio, senza segnali che permettano di adattarsi. ## Il corpo che non legge più la mappa {: #corpo-non-legge-mappa } Il corpo si era calibrato, in anni, su una cadenza precisa. Sapeva come distribuire l'energia attraverso una giornata, quando spingere e quando rallentare. Quella calibrazione presupponeva una mappa relativamente stabile dei costi delle attività: scrivere un report richiedeva ore, rispondere a un'email pochi minuti, e in quel range si distribuiva la maggior parte del lavoro intellettuale. La mappa non è più accurata. Il corpo continua a fare i suoi calcoli su costi che non valgono più, e c'è una spesa silenziosa e persistente di energia in questa continua ricalibrazione che non riusciamo nemmeno a osservare mentre avviene. ## Una stanchezza senza forma {: #stanchezza-senza-forma } È una stanchezza diversa da quelle che conoscevamo. Non è la stanchezza dello sforzo. È la stanchezza del tempo senza forma, che è più difficile da nominare perché ne abbiamo pochi esempi nella nostra storia. Anche le costrizioni più severe, dal carcere alla malattia, tendono a imporre un ritmo proprio, e infatti chi ne è uscito spesso descrive la mancanza di quel ritmo come una delle cose più disorientanti del rientro nella vita libera. Anche il tempo libero ha un ritmo, quello del fine settimana contro quello dei giorni feriali, quello dei pasti e delle abitudini. Quello in cui siamo dentro adesso è qualcos'altro: una giornata lavorativa la cui forma cambia mentre la stiamo lavorando, e che non si lascia ricondurre a nessun pattern stabile abbastanza a lungo perché ci si possa adagiare dentro. ## Non è solo transizione {: #non-solo-transizione } Si potrebbe obiettare che è solo transizione. Date tempo al sistema. Impareremo la nuova mappa e un nuovo ritmo emergerà, come è sempre successo. Forse. Ma l'analogia con le precedenti transizioni tecnologiche è fuorviante in un modo che vale la pena nominare. La fabbrica imponeva una cadenza brutale ma leggibile, e in pochi decenni il corpo collettivo dei lavoratori si è ricalibrato attorno a quella nuova forma. Il personal computer ha accelerato certi compiti ma ne ha mantenuto intatta la fenomenologia interna: scrivere era ancora scrivere, solo su una superficie diversa. Quello che sta cambiando ora è più fondamentale. L'AI non accelera l'attività, la sostituisce con un'altra. I trenta minuti che passavi a formulare un paragrafo non vengono compressi in tre minuti di formulazione più veloce. Vengono rimpiazzati da novanta secondi in cui descrivi quello che vuoi e qualche minuto in cui editi quello che torna indietro. Queste non sono la stessa attività accelerata. Sono attività diverse, con costi diversi e forme sentite diverse. Il corpo non ha nulla su cui ricalibrarsi, perché non si sta formando alcuna nuova normalità stabile abbastanza a lungo. ## I pensieri che non vengono raggiunti {: #pensieri-non-raggiunti } C'è anche qualcosa che perdiamo quando la tessitura della giornata si appiattisce, e che vale la pena guardare in faccia. La tradizione del *deep work*, per quanto sia stata fagocitata da una certa retorica della produttività, indicava qualcosa di reale e sottile: certi tipi di pensiero accadono solo in tratti uniformi prolungati. Le ore della mattina che proteggevamo per il compito difficile non erano semplicemente ore di qualità superiore. Erano ore che rendevano possibile il compito stesso. Certi pensieri si raggiungono solo dopo quaranta minuti di attenzione sostenuta, e non puoi arrivarci in otto minuti di attenzione ripetuti quattro volte. Quando la tessitura del giorno diventa frammentata e imprevedibile, quei pensieri semplicemente non vengono raggiunti. Non ne notiamo l'assenza direttamente, perché ciò che non viene pensato non lascia traccia sensibile. La notiamo come una specie di assottigliamento cognitivo, un output più rapido ma in qualche modo più leggero, la sensazione strana di produrre molto e di pensare poco senza riuscire a dire in che cosa consista esattamente la differenza. ## Le impalcature contro l'asimmetria {: #impalcature-contro-asimmetria } Non ho una formula per cosa fare di tutto questo, e diffido di chi ce l'ha già pronta. Le risposte da *productivity genre* — che per lo più suggeriscono di imporre struttura artificiale al nuovo caos attraverso calendari blindati e rituali del mattino eretti contro l'asimmetria — possono aiutare in casi individuali. Non affrontano il fenomeno sottostante, che è che la forma naturale della giornata era una cosa reale, sostenuta dai costi relativi delle attività, e quei costi sono cambiati in modo strutturale. La struttura artificiale è un'impalcatura che cerca di tenere in piedi un edificio le cui fondamenta si sono spostate. Può funzionare per un po', e logora chi la mantiene. Quello che noto in me stesso, e nei colleghi che me ne parlano quando c'è abbastanza fiducia da uscire dalla retorica della produttività, è che la fatica è più acuta nei giorni in cui ci siamo sforzati di più di usare il tempo risparmiato. Il mercoledì pomeriggio in cui il compito è collassato in venti minuti e abbiamo riempito le ore restanti con altri compiti finisce con una stanchezza particolare, che non viene dal lavoro ma dalla violenza interna di fingere che il tempo che abbiamo vissuto fosse il tempo che abbiamo misurato. Il mercoledì pomeriggio in cui il compito è collassato in venti minuti e ci siamo fermati — in cui siamo usciti a camminare, o siamo rimasti a guardare la stranezza del pomeriggio senza tentare di rinormalizzarla — finisce diversamente. Non in modo produttivo, nel senso vecchio. Ma il corpo riconosce che qualcosa è stato onorato, e quella stanchezza più pulita è un'altra cosa rispetto alla prima. ## Un nuovo rispetto per l'assenza di ritmo {: #rispetto-assenza-ritmo } Forse quello che serve non è un nuovo ritmo ma un nuovo rispetto per l'assenza di ritmo, almeno finché dura. La vecchia giornata aveva una forma perché il lavoro aveva una forma perché i costi avevano una forma. Niente di tutto questo sta tornando nella veste in cui lo conoscevamo. Cercare di ricostruirlo a forza, attraverso impalcature sempre più elaborate, continuerà a produrre la stanchezza diffusa che tutti ci portiamo dietro senza nominarla. Lasciare che la giornata sia la cosa strana che è diventata, ora uno scatto ora un tratto vuoto, potrebbe almeno restituirci l'energia che stiamo spendendo nel progetto inutile di fingere che nulla sia cambiato. È una resa parziale, certo. Ma alcune rese sono il preludio a un modo di stare nelle cose che la resistenza non ci avrebbe mai concesso. Questo non è ottimismo. Il giorno asimmetrico potrebbe essere un giorno peggiore in cui vivere rispetto a quello strutturato di prima, e non sono sicuro di come finirà. Quello di cui sono sicuro è che chiamare la fatica con il suo nome reale è la prima cosa che dobbiamo a noi stessi e ai nostri colleghi: non siamo stanchi perché abbiamo fatto di più, siamo stanchi perché abbiamo vissuto dentro un tempo che aveva perso la sua forma, e abbiamo continuato a comportarci come se la forma fosse ancora lì. --- # La forma del vincolo - **URL:** https://margiovanni.it/it/blog/la-forma-del-vincolo/ - **Pubblicato:** 2026-04-27 - **Tag:** Compliance, Normative Europee, AI Act, CRA, Filosofia Della Tecnica, Architettura, Strategia - **Tempo di lettura:** 17 min > Trattare la conformità normativa come avversaria del progetto tecnico significa non aver compreso cosa sia il progetto tecnico. Un saggio sull'errore di categoria che indebolisce l'industria europea del software, e su come il quadro normativo europeo — letto come sistema, non come elenco — configuri un vantaggio competitivo strutturale per chi sa abitarlo. > «Più vincoli ci si impone, più ci si libera dalle catene che ostacolano lo spirito.» > — Igor Stravinsky, *Poetica della musica* ## Il racconto che ci hanno raccontato {: #racconto-che-ci-hanno-raccontato } C'è una storia che si è insediata, negli ultimi anni, al centro del dibattito europeo sulla tecnologia. La conoscete tutti. Nella sua forma più sintetica suona così: «L'America innova, la Cina copia, l'Europa regola». È una battuta che si ripete nelle conferenze, sui giornali, nei rapporti dei think tank, e che ha trovato la sua consacrazione nel rapporto Draghi sulla competitività europea — un documento onesto e drammatico, che ha indicato nella frammentazione regolatoria una delle cause del nostro ritardo strutturale. C'è un fondo di verità in questa storia. È vero che il quadro normativo europeo è denso. È vero che il moltiplicarsi di requisiti — AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act, NIS2, GDPR, Data Act, DSA, DMA — produce un carico cognitivo non banale per chi sviluppa software. È vero che molte PMI italiane stanno annaspando, che la consulenza specializzata costa, che gli strumenti maturi mancano ancora. Ma la storia, come spesso accade, è più interessante di come ce la raccontano. Perché c'è un altro modo di leggere lo stesso scenario, ed è quello che vorrei provare ad articolare in queste pagine. Un modo che non nega le difficoltà, ma rifiuta la conclusione apparentemente scontata: che regolamentazione e innovazione siano in opposizione, e che chi sta in Europa stia perdendo per il solo fatto di starci. La tesi che sostengo è semplice nel suo nucleo, complessa nelle sue implicazioni: la conformità normativa, intesa correttamente, non è un costo della competizione ma uno dei suoi terreni. E il quadro europeo, letto come progetto tecnico coerente, configura un vantaggio competitivo che le aziende che lo hanno capito stanno già monetizzando, mentre quelle che continuano a viverlo come un fastidio si stanno progressivamente escludendo dai mercati a maggior valore aggiunto. ## L'errore di categoria {: #errore-di-categoria } Il primo passo per disinnescare il falso dilemma «regolamentazione vs innovazione» è riconoscere che si tratta, prima ancora che di una posizione discutibile, di un errore di categoria. Quando un architetto progetta un edificio, lavora dentro una rete fittissima di vincoli: leggi della fisica, codici antisismici, normative urbanistiche, requisiti energetici, accessibilità, sicurezza antincendio, vincoli paesaggistici. Nessuno, davanti a un edificio ben progettato, dice che «sarebbe stato più innovativo senza le leggi della statica». Sarebbe assurdo. La gravità non è un freno all'architettura: è la condizione che rende l'architettura possibile come disciplina. È ciò che distingue costruire da accumulare materiali. Lo stesso vale per il software. Le costanti, gli standard, i protocolli, le specifiche — TCP/IP, ANSI SQL, POSIX, IEEE 754, RFC 7231 — sono vincoli. Vincoli severissimi. Eppure non c'è ingegnere serio che li consideri ostacoli all'innovazione. Sono il contrario: sono la grammatica condivisa che rende possibile la composizione di sistemi complessi a partire da pezzi indipendenti. Senza quei vincoli non avremmo Internet, non avremmo i database, non avremmo l'interoperabilità. Avremmo un arcipelago di soluzioni proprietarie incomparabili tra loro — esattamente quello che la regolamentazione europea, nella sua intenzione, cerca di evitare per il prossimo strato della pila tecnologica: dati, intelligenza artificiale, sicurezza, accessibilità. Il vincolo, in altri termini, non è il nemico del design: è la sua forma. Lo sapeva Schönberg con la dodecafonia, lo sapevano gli Oulipo con i loro algoritmi letterari, lo sapeva Calvino quando elogiava l'esattezza come valore della letteratura, lo sa qualsiasi sviluppatore esperto quando capisce che i tipi statici non rallentano lo sviluppo, lo strutturano. La libertà assoluta in ingegneria si chiama caos, e produce sistemi fragili, incomparabili, non manutenibili. La libertà disciplinata produce architettura. Trattare la compliance come un avversario del progetto tecnico significa non aver compreso cosa sia il progetto tecnico. ## Il quadro europeo come sistema, non come elenco {: #quadro-europeo-come-sistema } Il secondo passo è leggere il corpo normativo europeo nel modo giusto. Quasi tutta la critica tradizionale — anche quella in buona fede — commette lo stesso errore: tratta le regolamentazioni come una lista. Un elenco di obblighi sconnessi, ognuno dei quali aggiunge attrito, ognuno dei quali andrebbe valutato singolarmente in termini di costo-beneficio. Ma questa non è la forma che il quadro europeo ha effettivamente assunto. Se si guarda la tessitura complessiva delle regolamentazioni dell'ultimo decennio — dal GDPR all'AI Act, passando per CRA, PLD, EAA, NIS2, Data Act, DSA, DMA — si scopre che non si tratta di un elenco ma di un sistema. E come ogni sistema progettato, ha una sua logica architetturale. Quella logica si può riassumere così: rendere *accountable*, *by design*, i sistemi tecnici che hanno effetti rilevanti sui diritti e sui beni delle persone. Tutto il resto è declinazione di questo principio. Il GDPR rende *accountable* i flussi di dati personali. Il GDPR non vi dice come progettare il database: vi dice che dovete poter rispondere — sempre, a chiunque chieda — chi tocca i dati di chi, perché, per quanto, e con quale base giuridica. Il Cyber Resilience Act fa la stessa cosa per la sicurezza dei prodotti software: non vi dice quale linguaggio usare, ma vi chiede di sapere e dimostrare cosa c'è dentro al vostro prodotto, di mantenerlo sicuro nel tempo, di gestire le vulnerabilità con processi tracciabili. La Product Liability Directive estende la responsabilità del produttore al software stesso, dichiarando esplicitamente che un bug può essere un difetto di prodotto. L'European Accessibility Act estende l'*accountability* all'inclusività: i prodotti digitali sopra una certa soglia di mercato devono essere usabili da chiunque. NIS2 lo fa per le infrastrutture critiche. L'AI Act lo fa per i sistemi che decidono o influenzano in modo rilevante le scelte umane. Vista così, la compliance europea non è una giungla di regole. È una grammatica unica, applicata a domini diversi: progetta in modo che tu possa rispondere di ciò che fai, *by design*. Non come ripiego, non come patina aggiuntiva. Come architettura. E qui sta il punto spesso ignorato: una volta che si è costruita un'organizzazione che pensa per *accountability* — con SBOM, con audit trail, con threat modeling, con privacy impact assessment, con accessibilità testata, con gestione delle vulnerabilità formalizzata — la marginale conformità al regolamento N+1 diventa molto più economica. La curva dei costi è opposta a quella che la critica naïve immagina: alta all'inizio, decrescente nel tempo, mentre per chi tratta ogni regolamento come una nuova emergenza la curva è bassa all'inizio ma divergente. Le organizzazioni che capiscono questo non «si conformano». *Sono* conformi, nel senso forte del termine: hanno una forma compatibile con il quadro. Le altre rincorrono. ## L'effetto Bruxelles, dieci anni dopo {: #effetto-bruxelles } C'è poi una dimensione di mercato che spesso si dimentica, e che da sola dovrebbe dissuadere chiunque dal liquidare la regolamentazione europea come una zavorra. Anu Bradford, giurista della Columbia, ha coniato l'espressione *Brussels Effect* per descrivere un fenomeno empirico ben documentato: quando l'Unione Europea regola un mercato di queste dimensioni — il secondo per PIL nominale, il terzo a parità di potere d'acquisto, comunque uno dei tre più grandi del mondo — le multinazionali tendono ad adottare lo standard europeo come standard globale, perché mantenere due regimi paralleli è più costoso che adottare ovunque il regime più stringente. Il caso paradigmatico è il GDPR. Approvato nel 2016, applicato dal 2018, è oggi de facto la base normativa che orienta le politiche di privacy delle principali aziende tech del mondo. Lo si vede nei consensi cookie ovunque, nelle dashboard di privacy delle big tech, nel California Consumer Privacy Act (che ne riprende impostazione e princìpi pur con un'architettura diversa, più snella e basata sull'opt-out), nelle leggi brasiliana, sudafricana, indiana. Quasi otto anni dopo l'applicazione, possiamo dire con ragionevole certezza: la grammatica della privacy mondiale parla europeo. L'AI Act sembra avviato sulla stessa traiettoria. Non perché sia perfetto — non lo è — ma perché è il primo quadro normativo *orizzontale e organico* al mondo per i sistemi di intelligenza artificiale. La Cina è arrivata prima, nel 2023, con regole vincolanti sull'AI generativa: ma sono regole settoriali e con un'enfasi diversa — etichettatura obbligatoria, registrazione presso l'autorità, verifica dell'identità degli utenti, controllo dei contenuti — più orientate alla stabilità informativa che alla protezione dei diritti fondamentali. L'AI Act è stato il primo a tentare un'architettura generale, per livelli di rischio, applicabile a tutti i sistemi di AI in tutti i settori. Le grandi aziende dell'AI stanno già strutturando i loro processi interni in funzione dei requisiti europei. Negli Stati Uniti, in un movimento che pochi si sarebbero aspettati, la regolamentazione statale sta riprendendo — soprattutto in Colorado, ma con echi in California e in qualche legge locale di New York — la logica della categorizzazione per rischio, pur con un percorso non lineare: il Colorado AI Act, originariamente in vigore dal 2026, è stato rinviato ed è in fase di rielaborazione mentre scrivo. Per un'azienda europea che progetta software, questo significa una cosa molto concreta: state già lavorando dentro lo standard che, statisticamente, sarà lo standard globale tra cinque anni. I vostri concorrenti americani e asiatici dovranno adeguarsi a un quadro che voi avete già metabolizzato. Non è un dettaglio: è la definizione operativa di vantaggio del *first mover*. Si dirà: ma se l'effetto Bruxelles è così potente, perché allora le aziende europee sono in difficoltà? La risposta richiede onestà. Perché molte aziende europee non hanno effettivamente metabolizzato il quadro: lo subiscono. Trattano il GDPR come un fastidio da minimizzare, l'AI Act come un'incognita da rinviare, l'EAA come una cosa da fare quando arriva l'ispezione. In questo modo pagano due volte: il costo della conformità (che gestita male è alto) e l'opportunità mancata di trasformare quella conformità in posizionamento. Mentre le aziende non europee, costrette a conformarsi per accedere al mercato, lo fanno strutturalmente — e a quel punto il vantaggio competitivo che sarebbe potuto essere nostro diventa loro. L'effetto Bruxelles è una freccia che vola verso il bersaglio. Sta a noi decidere se il bersaglio siamo noi o gli altri. ## L'asimmetria che decide {: #asimmetria-che-decide } Veniamo al cuore dell'argomento, quello operativo. C'è un'asimmetria fondamentale tra due tipi di aziende che operano nel mercato europeo, e questa asimmetria — silenziosa, accumulativa, oggi appena percepibile, domani decisiva — determinerà chi vince e chi esce dai segmenti a maggior valore. Il primo tipo di azienda tratta la compliance come *adempimento*. È la posizione di default, ed è perfettamente comprensibile: il regolamento arriva, si nomina un responsabile, si compilano le checklist, si producono i documenti, si aggiorna la privacy policy, si aggiungono i banner, si fanno fare le valutazioni quando serve. La compliance è un costo da minimizzare, un'attività difensiva, qualcosa che si fa per non prendere sanzioni. È un'attività che si esternalizza appena possibile: meglio un consulente al bisogno che strutturare il processo internamente. Il secondo tipo di azienda tratta la compliance come *architettura*. La differenza è che i requisiti normativi non vengono affrontati al momento della loro applicazione, ma assunti come vincoli di progetto fin dall'inizio. Il SBOM non è un documento da produrre ex post: è un artefatto generato dalla pipeline CI/CD a ogni build. La privacy non è una checklist da compilare: è una dimensione del modello dati. L'accessibilità non è una verifica finale: è un set di componenti UI che la garantiscono. La sicurezza non è un audit annuale: è un threat model rivisto a ogni modifica architetturale rilevante. L'*accountability* dell'AI non è una risposta a un'ispezione: è una serie di test, di documentazione del training, di evaluation suite. Per un osservatore esterno, nei primi due o tre anni, la differenza tra i due tipi di azienda è poco visibile. Anzi, la prima sembra più efficiente: produce gli stessi prodotti con meno overhead. La seconda investe in cose che non si vedono ancora: pipeline, framework, processi, formazione, documentazione strutturata. Poi qualcosa cambia. Cambia quando il mercato rilevante diventa la sanità, la pubblica amministrazione, il finance, l'energia, le infrastrutture critiche — cioè i segmenti dove i clienti hanno un'esposizione regolatoria propria, e dove la propria conformità dipende da quella dei loro fornitori. A quel punto succede una cosa che chiunque lavori nel B2B regolato ha già visto: la richiesta d'offerta arriva con un'Appendice tecnica di trenta pagine, e l'azienda «adempimento» scopre che molti dei requisiti non sono incrementali ma strutturali. SBOM completo per ogni componente. Tracciabilità delle vulnerabilità con SLA di rimedio. Processi di SDLC documentati e auditati. Penetration test annuali con remediation tracciabile. Politiche di backup, disaster recovery, business continuity testate. Privacy by design dimostrabile per ogni flusso. Accessibilità verificata. Auditabilità dei modelli AI utilizzati, se ce ne sono. L'azienda «adempimento» ha due opzioni: o si trasforma in azienda «architettura» — investendo improvvisamente, sotto pressione, in tutto ciò che non aveva costruito — o si ritira. Trasformarsi sotto pressione è caro, lento, e mai pulito: produce documentazione approssimativa, processi che sopravvivono al massimo fino al rinnovo del contratto, fragilità che emergono al primo audit serio. Ritirarsi significa scendere di un gradino di mercato. L'azienda «architettura» partecipa, vince, e — questo è il punto — vince con margini superiori, perché in quei segmenti il pricing premia la dimostrabilità, non solo le funzionalità. Sto descrivendo, come dovrebbe essere chiaro, qualcosa che vivo in prima persona. Negli ultimi tre anni ho visto progetti di sanità in cui il discriminante non era né il prezzo né la *feature parity* ma la capacità di produrre, in tempo utile, una documentazione di governance, sicurezza e accessibilità coerente con i requisiti del committente. Ho visto bandi della pubblica amministrazione in cui la qualifica ACN era un cancello, e dove la mancanza di un fornitore qualificato si traduceva in esclusione meccanica. Ho visto trattative in cui un'Appendice tecnica di sicurezza ha ridefinito da zero l'asse del negoziato: non più «cosa fa il vostro prodotto», ma «come dimostrate di poterlo gestire negli anni». La compliance, in questi contesti, non è il fastidio finale della trattativa. È *il* terreno della trattativa. ## La fiducia come prodotto {: #fiducia-come-prodotto } C'è una formulazione che mi sembra utile: in B2B regolato non si vendono funzionalità, si vende fiducia documentata. Le funzionalità contano, ovviamente. Ma le funzionalità diventano una commodity più velocemente di quanto si pensi. Tutti i CRM si assomigliano. Tutti gli LMS si assomigliano. Tutte le piattaforme di telemetria si assomigliano. Le differenze sono incrementali, e dopo un certo livello smettono di essere il discriminante d'acquisto. Diventa discriminante quello che funzionalità non è: la capacità di firmare un contratto con clausole di responsabilità precise, di superare un audit, di garantire continuità operativa, di documentare la propria supply chain software, di rispondere in 24 ore a una richiesta di esercizio dei diritti, di dimostrare la non discriminatorietà di un sistema decisionale, di mantenere accessibili i propri prodotti per anni. Nessuna di queste cose è una funzionalità in senso classico. Sono *capabilities organizzative dimostrabili*. E sono esattamente ciò che il quadro normativo europeo costringe a costruire. Qui si trova, secondo me, l'inversione concettuale fondamentale. Per un'azienda che vive la compliance come adempimento, la documentazione è un sottoprodotto: la cosa che si produce affinché gli ispettori siano contenti. Per un'azienda che vive la compliance come architettura, la documentazione *è il prodotto* — o meglio, è una parte costitutiva del prodotto, perché ciò che si vende non è il software ma la capacità organizzata di gestirlo nel tempo, e quella capacità è dimostrabile solo per via documentale. Si capisce, da questa prospettiva, perché il SBOM non è una scartoffia: è il manifesto della catena di fornitura del proprio software, ed è ciò che permette al cliente di gestire la *propria* esposizione. Si capisce perché l'audit log non è un costo: è una proprietà di affidabilità che il cliente comprerà comunque, e che diventerà obbligatoria di lì a poco. Si capisce perché un report di accessibilità conforme allo standard EN 301 549 non è una formalità: è ciò che permette al cliente pubblico di vincere il proprio bando, e quindi è ciò che fa di voi un fornitore preferito. Quando si vende fiducia, la documentazione è il prodotto e la conformità è il manuale di funzionamento del prodotto. ## L'obiezione onesta {: #obiezione-onesta } Sarebbe disonesto presentare questa lettura senza riconoscere le obiezioni serie. Ce ne sono almeno tre, e meritano di essere prese sul serio. La prima è quella della **sproporzione**. Il carico normativo che oggi grava su una software house di dieci persone è oggettivamente molto vicino a quello che grava su una grande corporation. Non in senso assoluto — ci sono soglie ed esenzioni — ma in senso strutturale: i processi richiesti per essere genuinamente conformi al CRA, all'AI Act, al GDPR sono a tratti gli stessi di una multinazionale, semplicemente con meno persone a gestirli. Questa sproporzione è reale, ed è il principale motivo per cui in Europa molte PMI faticano. È un problema serio, che chiede a Bruxelles di lavorare meglio sulla proporzionalità, sui regimi semplificati per le PMI, sulla disponibilità di strumenti di compliance accessibili. Non è, però, un argomento contro la compliance in sé: è un argomento per implementarla meglio. La seconda obiezione è quella dell'**eterogeneità implementativa**. Il regolamento europeo, una volta entrato negli ordinamenti nazionali, viene declinato in modi che variano da paese a paese — autorità competenti, schemi di certificazione, strumenti di vigilanza, soglie. Questa eterogeneità è effettivamente un costo, soprattutto per chi lavora cross-border. È una debolezza specificamente europea, legata alla nostra storia istituzionale, e non si risolve facilmente. Ma — e questo è il punto — non è una debolezza della compliance: è una debolezza dell'integrazione del mercato unico. Sono due problemi diversi. Liquidare la regolamentazione europea perché è applicata in modo non uniforme è un po' come liquidare l'idea di lingua perché esistono i dialetti. La terza obiezione è la più interessante, e merita la risposta più articolata. È l'obiezione del **time-to-market**: se i nostri concorrenti americani non devono fare AI Act compliance, e noi sì, loro arrivano prima sul mercato. Questa obiezione si scontra con l'effetto Bruxelles ma non lo annulla del tutto: c'è una finestra reale in cui l'asimmetria di vincolo produce asimmetria di velocità. Il punto, però, è che quella finestra si applica a un sottoinsieme specifico di prodotti — quelli che mirano al mass market consumer, dove il time-to-market vince spesso sulla solidità — e non a quelli che mirano ai segmenti regolati. Per chi vende a ospedali, banche, PA, infrastrutture critiche, la velocità non è quasi mai il discriminante: lo è la robustezza dimostrabile. E lì il quadro europeo è un avvantaggio, non uno svantaggio. Esistono aziende europee che stanno vincendo nel B2B regolato proprio perché il prodotto americano arriva senza la documentazione, senza i processi, senza la cultura — e deve essere ricostruito sotto pressione per superare gli audit. Ricostruire sotto pressione è caro: i loro margini scendono, i nostri salgono. Tutte e tre le obiezioni, in sintesi, hanno un fondo di verità ma nessuna giustifica la conclusione catastrofista che spesso le accompagna. La risposta corretta è: implementare meglio la compliance, non rifiutarla. ## Cosa fa un'organizzazione conforme by design {: #organizzazione-conforme-by-design } Fin qui il livello concettuale. Vorrei chiudere con qualcosa di più operativo, perché un saggio sulla compliance che non scenda in dettagli rischia di essere apprezzato e poi dimenticato. Un'organizzazione che ha trasformato la compliance in vantaggio competitivo, nella mia esperienza, ha questi tratti. Ha *un singolo modello di accountability* che attraversa il ciclo di vita del software. Non un modello per la sicurezza, uno per la privacy, uno per l'accessibilità, uno per l'AI: un modello unico, con declinazioni specifiche, dove tutti i requisiti convergono nelle stesse pipeline e nella stessa documentazione. Il SBOM, il PIA, il threat model, il record dei test di accessibilità, la model card vivono nello stesso repository, sono versionati, sono aggiornati a ogni release, sono linkabili da ogni altra parte dell'organizzazione. Ha *automazione del compliance artifact*. La generazione di SBOM, di SPDX, di license report, di vulnerability reports, di accessibility scans, di model evaluation reports è automatica. Non è qualcosa che qualcuno produce a mano in vista di un audit: è qualcosa che la pipeline produce a ogni build, con timestamp e commit di riferimento. Il risultato è che, quando arriva una richiesta del cliente, la risposta è disponibile in minuti, non in settimane. Ha *contratti come specifiche*. I contratti con i clienti — soprattutto in ambito sanitario e PA — non sono testi giuridici disgiunti dal lavoro tecnico, ma specifiche tecniche che vivono dentro il backlog. Le clausole di sicurezza sono mappate su requirement, i requirement su test, i test su pipeline. Quando un cliente chiede di certificare la conformità a una clausola, la risposta non è «chiediamo al consulente»: è una query nel proprio sistema. Ha *competenza giuridica internalizzata*. Non significa avere un avvocato in pianta organica. Significa che i tech lead conoscono i regolamenti che si applicano al loro dominio, ne capiscono la logica, sanno tradurre i loro requisiti in scelte architetturali. Il consulente esterno è una risorsa per casi specialistici, non il proprietario della compliance. Ha *cultura del trade-off esplicito*. Sa quando un requisito di compliance impone un costo, lo dichiara, lo discute, e prende decisioni motivate. Non finge che la compliance sia gratuita. Non finge che sia impossibile. La tratta come uno dei vincoli del progetto, da bilanciare con gli altri. E, soprattutto, ha *una narrazione commerciale fondata sulla conformità*. Sa raccontare ai clienti perché il proprio prodotto è migliore, e quel «perché» include — accanto alle funzionalità — la struttura di affidabilità documentata. Sa che il cliente sanitario, il cliente PA, il cliente bancario stanno comprando proprio quello: la garanzia che, a tre anni, a cinque anni, davanti a un'ispezione, davanti a un incidente, davanti a un cambiamento normativo, tu sarai ancora un fornitore solido. Non è una concessione al marketing: è il prodotto. ## La firma civile dell'Europa {: #firma-civile-delleuropa } Vorrei chiudere uscendo dal terreno operativo per tornare a quello concettuale, perché credo che ci sia una dimensione ulteriore — civile, quasi politica — che vale la pena nominare. L'Europa, come progetto, è un esperimento storico singolare: un'unione di stati che hanno deciso, dopo le catastrofi del Novecento, di mettere in comune sovranità in cambio di regole. Non è un'unione di forza: è un'unione di norme. La nostra ricchezza simbolica, la nostra capacità di proiettare valori, la nostra credibilità internazionale, dipendono in larga misura dall'idea che noi le regole le facciamo, le rispettiamo e le applichiamo a noi stessi. Quando le esportiamo, non lo facciamo con la forza ma con il mercato. Quello che stiamo facendo nel digitale è esattamente questo: trasporre nel cyberspazio la nostra firma civile. L'idea, scandalosa per una parte del mondo, che la tecnologia debba rispondere a chi la subisce, non solo a chi la produce. Che gli effetti dei sistemi tecnici sugli individui non siano un'esternalità ma un oggetto legittimo di regolazione. Che l'innovazione che produce danni non risarciti, esclusioni non rimediate, opacità non spiegabili, non sia innovazione: sia un trasferimento di costi dal produttore al cittadino mascherato da progresso. Si può non condividere questa visione. Ci sono ordinamenti che hanno fatto altre scelte, e li rispettiamo. Ma sostenere — come pure fanno alcuni tra noi — che la nostra visione sia un freno, e che il progresso vero sarebbe altrove, significa non aver capito quale gioco stiamo giocando. Il gioco non è chi arriva prima sul mercato consumer con un nuovo gadget. Il gioco è chi definisce la grammatica entro cui i sistemi tecnici operano nei prossimi cinquant'anni. Il GDPR è già la grammatica della privacy globale. L'AI Act sta diventando la grammatica dell'*accountability* algoritmica globale. Il CRA sta diventando la grammatica della sicurezza dei prodotti software globale. Per chi progetta software in Europa, partecipare a questo gioco è un privilegio che paghiamo con un costo specifico — il costo di costruire prima — ma è anche, esattamente per questo, il nostro principale vantaggio competitivo strutturale. Chi resta fuori, dentro l'Europa stessa, perché trova il quadro fastidioso, sta facendo un calcolo miope: si sta sottraendo all'unico vantaggio che abbiamo, per inseguire un modello di competizione — quello del puro time-to-market — in cui non possiamo vincere comunque, perché non abbiamo la massa di capitale di chi lo definisce. La conformità, intesa correttamente, non è il nostro fardello. È la nostra forma. La nostra forma di costruire, la nostra forma di fare impresa, la nostra forma di proiettare valori. Trattarla come una zavorra è come, per un musicista, trattare la chiave d'armonia come un fastidio. Si può fare, certo. Ma si suona altro, e si suona peggio. Il vincolo, ancora una volta, è la forma. E la forma, per chi sa abitarla, è un vantaggio. --- # DPIA come genere, non come modulo - **URL:** https://margiovanni.it/it/blog/dpia-come-genere-non-come-modulo/ - **Pubblicato:** 2026-04-21 - **Tag:** Compliance, GDPR, Normative Europee, Filosofia Della Tecnica - **Tempo di lettura:** 28 min > Il template EDPB per le DPIA, pubblicato ad aprile, non è un formulario più lungo. È la codificazione di una forma. Sul passaggio da modulo a genere, e su cosa cambia per chi scrive la compliance come pratica di scrittura continua. Il template EDPB è arrivato pubblicamente la settimana scorsa. L'ho aperto la prima volta sul treno tra Pescara e Roma, un PDF di una quarantina di pagine che mi sembrava di conoscere prima ancora di leggerlo, con quella particolare attenzione distratta che si riserva ai documenti di cui sai già tutto. La DPIA la frequento da anni, ne ho aiutate a scrivere decine, mi ero abituato a considerarla un oggetto stabile: un modulo, una checklist, un artefatto di compliance da consegnare al DPO e da archiviare. Aprendo il nuovo template avevo in mano una cosa familiare e leggermente alterata, come quando torni in un appartamento in cui hai vissuto da ragazzo e qualcuno ha spostato i mobili senza dirtelo. Qualcosa mi irritava e non riuscivo a dire cosa. È stato solo qualche giorno dopo, leggendolo con calma sulla scrivania, che ho capito cosa mi stava infastidendo. Il template non era una versione più dettagliata del precedente. Era un'altra cosa. Non un formulario migliorato, non una griglia più fine: il documento che avevo in mano pretendeva qualcosa di diverso da chi lo compila, e in modo più sottile pretendeva qualcosa di diverso anche da chi lo legge. La DPIA stava smettendo di essere un modulo e stava diventando, per riprendere un termine che ho passato gli anni dell'università a rimuginare, un *genere*. ## Cosa è arrivato, e cosa no {: #cosa-e-arrivato-e-cosa-no } Vale la pena di precisare subito cosa è arrivato e cosa non è arrivato, perché la sfumatura fa differenza per tutto il resto del ragionamento. L'EDPB ha adottato il template in versione 1.0 per procedura scritta il 10 marzo, lo ha reso pubblico in aprile insieme a un explainer document che accompagna ciascuna sezione, e lo ha aperto a consultazione pubblica fino al 9 giugno. L'uso del template non è obbligatorio: i titolari possono continuare a usare le metodologie DPIA che preferiscono. Dopo la consultazione, e con le modifiche eventualmente introdotte, tutte le autorità nazionali di protezione dei dati avvieranno i passi per adottarlo come proprio standard o come meta-template a cui i modelli nazionali dovranno uniformarsi. Nulla è ancora chiuso, insomma, ma tutto sta prendendo forma; e la forma che sta prendendo è esattamente il cuore di ciò che voglio discutere qui. So di dover argomentare contro l'intuizione comune. La gran parte delle persone che lavora con la DPIA la considera una scocciatura burocratica, un onere da smaltire, un pezzo di carta che il consulente legale compila e il cliente archivia. In Italia, dove la compliance ha a lungo mantenuto un profilo difensivo, la DPIA è spesso stata scritta per non essere letta, e letta per non essere discussa. La domanda «cosa ti serve davvero in una DPIA fatta bene» riceve in genere risposte pratiche: che sia completa, che copra i casi d'uso, che non contraddica altra documentazione, che sopravviva a un controllo dell'autorità. Sono risposte oneste. Sono anche, a mio avviso, risposte sbagliate, o meglio: sono le risposte che si darebbero se la DPIA fosse davvero un modulo. Ed è precisamente quello che, fino a qualche settimana fa, la DPIA era ancora, almeno in larga parte della pratica italiana. Un documento senza autore, nel senso più debole della parola: qualcuno lo firmava, certo, ma nessuno se ne prendeva la responsabilità in senso editoriale. ## Un template non è un modulo {: #un-template-non-e-un-modulo } Ma qui arriviamo al punto. Un template non è un modulo. Un template, nel momento in cui viene proposto da un'autorità come l'EDPB con l'ambizione esplicita di diventare lo standard comune europeo, smette di essere uno strumento di compilazione e diventa qualcosa di più strano e più potente: la codificazione di una forma. E una forma non si compila. Una forma si scrive, e si scrive avendo ben presente di essere letti dentro attese specifiche, con un lessico, una struttura narrativa, un ritmo retorico che non sono intercambiabili con altri. Questo, in poche parole, è un genere. Per capire perché il passaggio sia importante, serve fare un passo indietro e guardare il percorso con cui la DPIA è arrivata dove è arrivata. Esiste formalmente dal 2018, prevista dall'articolo 35 del GDPR come valutazione obbligatoria nei casi di trattamento ad alto rischio. Nei primi anni è stata gestita come poteva essere gestita: ciascuna organizzazione, ciascuno studio legale, ciascun DPO ha prodotto la sua versione, con una variabilità che chi ha lavorato cross-settore conosce bene. Alcune DPIA erano documenti di cinque pagine che sembravano un verbale di riunione; altre erano tomi di cento pagine che sembravano tesi di dottorato. Alcune erano compilate con matrici di rischio numeriche ereditate da framework di sicurezza, altre con prosa giuridica fitta di rimandi normativi, altre ancora con approcci ibridi che mescolavano le due culture senza riuscire a farle convivere del tutto. La Commissione aveva suggerito alcuni schemi, il Working Party 29 prima e l'EDPB poi avevano pubblicato linee guida, alcune autorità nazionali avevano messo a disposizione modelli più strutturati, ma il panorama restava frammentato. La DPIA stava in quello stato di cosa giovane in cui le forme non sono ancora decantate, in cui ciascuno prova la sua strada e poche di queste strade si incontrano. Le autorità di controllo europee si erano lamentate ripetutamente di questa eterogeneità, che rendeva difficile costruire una giurisprudenza implicita condivisa, quella giurisprudenza non scritta che in ogni settore maturo si costruisce leggendo centinaia di documenti prodotti secondo una forma riconoscibile. ## Quando una forma prende corpo {: #quando-una-forma-prende-corpo } Il template EDPB apre la chiusura di questa fase. Non con l'autorità formale di un regolamento vincolante, che non è, ma con qualcosa di simile all'autorità che una grammatica normativa esercita su una lingua viva: indica, orienta, crea un centro di gravità. Da ora in poi, chi scrive una DPIA in Europa sa che esiste una forma proposta a livello sovranazionale, e sa che quando il processo di consultazione si chiuderà e le autorità nazionali avranno fatto i loro passi di adozione, ogni deviazione da quella forma andrà giustificata. Questo è esattamente, nella storia delle lingue e dei generi letterari, il movimento con cui una forma prende corpo. Prima di Dante il volgare fiorentino era uno dei tanti volgari italiani; dopo Dante ogni uso del volgare fiorentino si misurava su di lui, anche quando se ne voleva allontanare. L'accostamento a Dante è sproporzionato rispetto a un template burocratico, e lo so. Lo lascio comunque perché la meccanica è la stessa, anche se le altezze sono ovviamente incomparabili. Quando un'autorità propone una forma e tutte le autorità sottostanti annunciano che la adotteranno, quella forma smette di essere una possibilità tra le tante e diventa lo sfondo su cui tutte le altre si ritagliano. ## Architesto e autoinquisizione {: #architesto-e-autoinquisizione } Gli studiosi di letteratura chiamano questo fenomeno la stabilizzazione di un *architesto*, termine che devo a Genette ma che girava già in Bachtin sotto il nome di *generi del discorso secondari*. L'architesto non è un'opera singola: è l'insieme delle attese formali che un lettore porta con sé quando apre un certo tipo di documento. Quando apro un giallo so che ci sarà un delitto da risolvere, quando apro un articolo scientifico so che ci sarà una sezione metodologica, quando apro un sonetto conto le righe prima ancora di leggerle. Un architesto stabilizzato produce attese stabilizzate. E produce, inevitabilmente, una forma di scrittura che sa di essere letta dentro quelle attese. Hans Robert Jauss, a partire dal 1970, chiamava *orizzonte d'attesa* questa postura del lettore che incontra un testo dentro una cornice di genere già nota. Ogni testo, per Jauss, si legge sempre due volte: una contro la cornice che il lettore porta con sé, una rimodellando quella cornice in base a ciò che il testo effettivamente dice. Una DPIA scritta dentro il template EDPB, quando sarà diventato lo standard di riferimento, verrà letta così: l'auditor o l'ispettore saprà già cosa cercare, saprà in quale sezione aspettarsi cosa, saprà riconoscere immediatamente quando il testo si discosta dalla forma attesa, e in base a quella deviazione si costruirà un giudizio. C'è un secondo filone teorico che vorrei richiamare, perché illumina il punto in una direzione diversa. Carlo Ginzburg, nei suoi lavori sui processi inquisitoriali friulani del Cinquecento e del Seicento, ha mostrato come i verbali di quei processi fossero un vero genere documentale, con convenzioni retoriche precise, un rapporto codificato tra interrogante e interrogato, una gestione particolare della voce tra discorso diretto e discorso indiretto, una struttura narrativa che traduceva la voce dell'imputato nella cornice processuale dell'inquisitore. Ginzburg leggeva quei verbali come testi, non come pure trascrizioni, e in quella lettura trovava le tracce di una soggettività popolare altrimenti invisibile. Al di là del confronto storico, c'è un'analogia strutturale che mi colpisce da quando rifletto sulla DPIA. La DPIA è, nella sua architettura profonda, un documento auto-inquisitoriale: il titolare del trattamento interroga sé stesso sul proprio operato, ricostruisce le ragioni delle proprie scelte, argomenta di fronte a un lettore assente ma minaccioso (l'autorità) perché quelle scelte sono adeguate. È una forma di discorso che espone la propria razionalità per esserne giudicata. Il fatto che ora abbia un template destinato a diventare genere codificato significa, tra le altre cose, che questa autoinquisizione sta per avere una grammatica. E le grammatiche, come sanno tutti quelli che le hanno studiate sul serio, non sono strumenti neutri: modellano quello che può essere detto, e indirettamente quello che può essere pensato. ## La finestra del canone {: #la-finestra-del-canone } Chi scrive una DPIA nei prossimi mesi si trova in una condizione particolare, che è diversa sia da quella del pioniere sia da quella del compilatore dentro un genere maturo. Il template è sul tavolo ma non è ancora standard, la consultazione è aperta, le autorità nazionali stanno preparando i propri passi di recepimento. Chi scrive una DPIA in questa finestra sta scrivendo dentro una forma in corso di stabilizzazione, il che significa due cose. La prima è che non può più comportarsi come un pioniere: il template è disponibile, le sue sezioni sono chiare, il suo metodo è pubblico, ignorarlo sarebbe un gesto deliberato e andrebbe motivato. La seconda, meno ovvia, è che ha un'opportunità che chi scriverà fra due anni non avrà più: quella di contribuire, con la propria pratica, a definire cosa significherà «scrivere bene» dentro questo genere. Ogni DPIA prodotta adesso che si confronta seriamente con il template, che lo usa come struttura, che ne segnala i limiti, contribuisce alla formazione del canone. Nei generi stabilizzati il canone esiste già; nei generi in formazione il canone si fa scrivendolo. Per chi fa il nostro mestiere, vale la pena di esserci proprio in questa finestra. ## Dal formulario alla prosa {: #dal-formulario-alla-prosa } Mi si potrebbe obiettare che sto romanticizzando una cosa che è soltanto un formulario più lungo. L'obiezione è seria e merita di essere presa sul serio. Se la DPIA fosse soltanto un formulario più lungo, allora la sua evoluzione sarebbe irrilevante al di fuori del perimetro stretto della compliance: un'altra griglia da riempire, un altro tipo di PDF da archiviare, un altro costo marginale per chi tratta dati. Ma c'è un dettaglio del nuovo template che, una volta notato, smonta questa lettura. Il template non chiede più soltanto di elencare. Chiede di argomentare. Chiede, in particolare, di motivare la proporzionalità delle scelte, di ricostruire il ragionamento che porta da una valutazione del rischio a una misura di mitigazione, di mostrare perché un certo bilanciamento tra utilità e rischio residuo è accettabile. Chiede, insomma, una cosa che un formulario non può chiedere: chiede prosa. La comparsa della prosa in un documento di compliance è il sintomo più chiaro del passaggio a genere. Un modulo non ha bisogno di prosa, perché il suo valore informativo è interamente contenuto nella griglia. Un genere, invece, vive nella prosa, perché è nella prosa che si esprimono le connessioni tra i fatti, le gerarchie di importanza, le giustificazioni, le sfumature. Quando il template EDPB chiede di scrivere perché la base giuridica scelta è adeguata al contesto del trattamento, sta chiedendo un piccolo saggio. Il contenuto di quel saggio avrà dei vincoli formali, ma resta un saggio. E chi scrive un saggio, anche un saggio di trecento parole in una casella di un PDF, scrive diversamente da chi compila una casella di un foglio Excel. La prosa costringe a scegliere un punto di vista, a decidere cosa mettere prima e cosa dopo, a mostrare quali informazioni siano accessorie e quali centrali. La griglia, per sua natura, appiattisce queste gerarchie. Il passaggio dalla griglia alla prosa non è un passaggio di pura forma; è un passaggio di epistemologia locale, di cosa un certo testo può raccontare e cosa non può raccontare. ## I molti lettori di una DPIA {: #i-molti-lettori-di-una-dpia } Un aspetto sottovalutato, e che vorrei portare alla luce, riguarda chi legge una DPIA. Nella pratica corrente si pensa quasi sempre a un lettore solo, anzi a un lettore ipotetico e poco caratterizzato: l'ispettore di un'autorità di controllo, figura un po' astratta, con cui in realtà la gran parte delle DPIA non si confronterà mai. Ma un documento di genere ha sempre più lettori reali di quanti ne dichiari, e la DPIA non fa eccezione. La legge il committente pubblico che valuta il fornitore. La legge il compliance officer che fa due diligence in un'acquisizione. La legge l'avvocato che prepara la difesa in un contenzioso. La legge, se ben scritta e se resa accessibile, l'interessato che vuole capire come vengono trattati i suoi dati. La legge, in un contesto sempre più frequente, il fornitore di tecnologia a monte che deve verificare se il proprio ruolo di responsabile del trattamento è stato correttamente perimetrato. Ciascuno di questi lettori porta con sé un orizzonte d'attesa diverso, e il fatto che il template EDPB stia stabilizzando la forma aiuta tutti loro allo stesso tempo: un lettore disciplinato sa dove cercare, sa riconoscere quello che cerca, sa distinguere il testo ben fatto da quello abborracciato. Un modulo è in fondo opaco a qualsiasi lettore esterno al suo compilatore. Un genere, invece, ha il pregio democratizzante di essere leggibile da chiunque ne conosca le convenzioni. ## DPIA-as-code {: #dpia-as-code } Torno per un momento all'esperienza di Oltrematica degli ultimi mesi, perché è stata proprio la quotidianità con certi progetti a farmi capire cosa stesse cambiando. Abbiamo in corso lavori su piattaforme sanitarie per la Regione Abruzzo, su sistemi di people analytics in ambito ospedaliero, su applicativi per la pubblica amministrazione locale, su piattaforme di formazione online con certificazioni ECM, su sistemi di gestione della sosta per municipalizzate. In tutti questi casi abbiamo, o avremo, una DPIA. Fino a un anno fa l'approccio tipico era: fissiamo una call con il DPO del cliente, raccogliamo le informazioni, produciamo un draft, lo rivediamo insieme, lo mettiamo a repository. Il documento era sostanzialmente chiuso alla fine del processo. Si aggiornava al cambiare del trattamento, con un ciclo di revisione annuale o biennale. Era, chiaramente, un modulo. La cosa interessante è che anche internamente al team tecnico trattavamo la DPIA come un modulo: la consideravamo qualcosa che il DPO produceva per noi, non con noi, e che ci riguardava solo se un auditor ci chiedeva di confermare uno dei suoi contenuti. Quando ho letto il nuovo template, la prima cosa che ho fatto è stata scrivere un memo interno su cosa sarebbe cambiato operativamente. La seconda cosa, meno immediata, è stata buttare giù una proposta che ho chiamato per brevità *DPIA-as-code*: portare la DPIA dentro il flusso di versionamento dei progetti, integrarla con Jira e Confluence, renderla un artefatto che vive nello stesso ecosistema in cui vive il codice. Non è un'idea rivoluzionaria. Altri ci stavano già pensando, in particolare in ambienti dove la compliance si è storicamente intrecciata con l'ingegneria del software, penso ad alcuni team security nel mondo cloud-native statunitense. Ma il motivo per cui è diventata una proposta sensata proprio ora, e non due anni fa, è esattamente quello di cui sto scrivendo: solo quando un documento sta diventando un genere, e non più un modulo, ha senso versionarlo come versioneresti un capitolo di un libro. Un modulo lo aggiorni con un nuovo modulo; un capitolo lo revisioni con tracciabilità genetica, con attenzione alle varianti, con un archivio delle decisioni che ti permette di tornare sui tuoi passi e capire perché, un anno fa, avevi scelto una certa formulazione piuttosto che un'altra. I progetti su cui questa trasformazione si sta rivelando più interessante sono quelli in cui il profilo di rischio evolve insieme al prodotto. Una piattaforma di people analytics come quella che sviluppiamo in partnership con Umana Analytics ha un ciclo in cui ogni nuova feature tocca potenzialmente dati sensibili, e ogni modifica ai modelli predittivi ridefinisce i contorni del trattamento. Una DPIA-modulo qui invecchia molto in fretta: la scrivi, la archivi, la rileggi a un anno di distanza e scopri che il suo paragrafo centrale non descrive più fedelmente cosa il prodotto sta facendo. Una DPIA-genere versionata, invece, segue il prodotto. Ogni pull request che tocca il perimetro del trattamento apre una corrispondente discussione sul paragrafo pertinente, che può restare invariato oppure essere aggiornato con un diff che spiega cosa è cambiato e perché. La piattaforma sanitaria per la Regione Abruzzo su cui lavoriamo da anni, con il suo flusso di dati verso un'anagrafica regionale e verso i sistemi nazionali di rilevazione, è un caso ancora più chiaro, perché ogni cambio normativo a monte impone una rilettura del trattamento, e senza una DPIA versionata quella rilettura rischia di perdere il filo delle motivazioni originali. Con una DPIA versionata, invece, puoi partire dal presente e risalire, decisione per decisione, fino al punto in cui il trattamento è stato definito, leggendo insieme al testo le discussioni che lo hanno accompagnato. Un caso ancora diverso è la piattaforma di formazione online che gestiamo per enti che erogano ECM, dove la DPIA deve rendere conto di un trattamento relativamente stabile ma di un pubblico di utenti molto vasto e di una filiera di sub-responsabili articolata. Qui il valore di una DPIA versionata è soprattutto nel mantenere allineata la catena di responsabilità man mano che i fornitori cambiano, e ogni aggiornamento di un fornitore diventa un commit sulla sezione pertinente, con una coerenza che un modulo archiviato una volta all'anno non può avere. ## Filologia d'autore, e il git log {: #filologia-dautore-e-il-git-log } Qui diventa importante chiedersi cosa voglia dire, davvero, versionare un genere. La critica letteraria ha una tradizione consolidata su questo: quella che in Italia chiamiamo *filologia d'autore*, o *critica delle varianti*, associata per il Novecento ai nomi di Contini e di Isella, e che in Francia ha preso il nome di *critique génétique*, con figure come Bellemin-Noël e Pierre-Marc de Biasi. Studia come un testo è cresciuto nel tempo, quali varianti sono state adottate e scartate, quali pressioni esterne hanno modificato la forma, quali riscritture sono state indotte da revisori, committenti, autocensure. Il git log di una DPIA versionata è, banalmente, un *avant-texte* in tempo reale. Mostra quando una misura di mitigazione è stata rafforzata, chi l'ha proposta, in risposta a quale segnalazione, con quali alternative considerate e scartate. Produce, come effetto collaterale, un livello di tracciabilità che nessuna DPIA-modulo ha mai avuto, perché il modulo nasconde la sua storia nella sua versione finale, mentre il genere la esibisce. E la esibisce non per narcisismo archivistico, ma perché in un genere maturo la storia delle scelte è parte dell'argomentazione corrente. Un auditor che sa leggere un git log riesce a capire, senza chiedere conferma a nessuno, se una certa misura è stata implementata in risposta a un'analisi del rischio reale o invece ritagliata a posteriori per giustificare una scelta già presa. La genealogia di un testo è un controllo di qualità molto più efficace di qualsiasi firma in calce. Lavorare dentro questo quadro cambia, in modo che nella mia esperienza si rivela progressivo, alcune dimensioni operative. La prima riguarda la separazione tra la fonte e la resa. Una DPIA-modulo vive nel suo file PDF finale, con tutti i problemi di disallineamento che questo comporta: modifichi la DPIA e poi scopri che la scheda del trattamento in un altro documento dice una cosa diversa, oppure che l'abstract per la direzione è rimasto fermo alla versione di sei mesi prima. Una DPIA-genere vive in una sorgente strutturata, nel nostro caso Confluence con alcune pagine chiave marcate per la pipeline di export, da cui si generano le rese destinate ai diversi lettori. La stessa sorgente produce la DPIA completa per il DPO, un abstract esecutivo per la direzione, una scheda tecnica di mitigazioni per il team di sviluppo, eventualmente anche una versione sintetica per gli interessati qualora il titolare scelga di renderla accessibile. I contenuti sono gli stessi, la forma si adatta. Questo richiede, alla fonte, una disciplina di scrittura più rigorosa di quanto la DPIA-modulo pretendesse, perché ogni paragrafo deve essere pensato per sopravvivere a usi multipli. In cambio, riduce drasticamente la cosa che in compliance fa più danno di qualsiasi altra, cioè la proliferazione di versioni non allineate dello stesso trattamento in documenti diversi. La seconda dimensione riguarda il collegamento con il ticketing di progetto. In ogni nostro lavoro, un'epic o una storia di Jira che tocca un nuovo trattamento di dati personali, o ne modifica uno esistente, apre una richiesta formale di aggiornamento della DPIA corrispondente. Non necessariamente un aggiornamento pieno; anche una verifica di non-impatto è sufficiente, purché sia registrata. Il collegamento rende esplicito quello che nel mondo DPIA-modulo era implicito, e quindi dimenticato: ogni scelta di prodotto è una scelta di compliance, ogni feature che tocca dati è una potenziale modifica al trattamento documentato. Legare il ticket al paragrafo di DPIA significa, in pratica, imporre che il prodotto e il suo atto di scrittura procedano allineati. Il git log diventa una storia genetica del trattamento; la cronologia di Jira diventa la cronologia delle sue motivazioni. Per un team abituato a pensare la compliance come un'attività satellitare rispetto allo sviluppo è un cambio di postura non banale, e va accompagnato. Nei primi mesi abbiamo avuto resistenze da sviluppatori che vedevano l'aggancio Jira-Confluence come burocrazia aggiuntiva; dopo sei mesi, la maggior parte lo considera un aiuto, perché riduce le riunioni di allineamento e rende visibile il contributo tecnico alla costruzione della compliance. ## Il DPO come editor {: #il-dpo-come-editor } La dimensione più delicata riguarda i ruoli. In un modello DPIA-modulo il DPO è tipicamente l'autore principale o il revisore finale, e il team tecnico è un fornitore di informazioni. In un modello DPIA-genere, questa geometria si ribalta parzialmente. Il DPO resta responsabile della conformità, ma diventa più propriamente un editor: stabilisce standard, rivede contributi, garantisce coerenza tra sezioni, richiede riscritture. Chi scrive il primo draft di molte sezioni è chi conosce la materia, cioè il product owner, l'architetto, lo sviluppatore che ha disegnato il data model, il DBA che ha impostato la politica di retention. Il documento finale resta firmato dal DPO e dal titolare, ma il tessuto del testo è tessuto da più mani. È una cosa che chi ha lavorato in redazione riconosce immediatamente, e che chi ha lavorato solo in compliance trova disorientante. Eppure mi sembra, dopo sei mesi di esperimenti, la configurazione più sana. So che sto introducendo una tensione. Un DPO che diventa editor rischia di perdere in autorità formale quello che guadagna in qualità del prodotto. Nella tradizione italiana, dove la figura del DPO è spesso giuridica e spesso esterna all'organizzazione, la proposta di un DPO-editor può suonare come un indebolimento. Credo invece che sia un rafforzamento, per una ragione sottile ma importante. L'autorità di un editor non è l'autorità di chi produce il testo da solo; è l'autorità di chi decide cosa passa e cosa no. Un DPO che scrive tutto da solo può produrre una DPIA formalmente inattaccabile ma distante dalla realtà operativa del trattamento. Un DPO che edita ciò che il team scrive resta nella posizione finale di dire no, ma lo fa su materiale che ha la presa dei fatti. Il risultato è, nella mia esperienza, più difficile da attaccare e più facile da difendere in caso di ispezione. ## Leggibilità non è semplicità {: #leggibilita-non-e-semplicita } Qui arriviamo alla seconda obiezione seria che voglio affrontare, che è stata sollevata in diversi confronti interni negli ultimi mesi. Si potrebbe dire: questo riconoscimento della DPIA come genere non è un progresso, è una sofisticazione inutile, una barocchizzazione della compliance che aggiunge oneri senza aggiungere valore. L'Europa, si dirà, già soffre di inflazione normativa; trasformare la DPIA in un prodotto letterario, per quanto tecnico-letterario, significa aggravare un problema senza risolverlo. Capisco l'obiezione, ma credo sia sbagliata per una ragione specifica. I generi non complicano i testi; li rendono leggibili. L'alternativa a un genere stabilizzato non è un testo più semplice, è un testo più difficile da leggere, perché manca la griglia che permette al lettore di orientarsi. Quando uno stesso documento arriva sul tavolo di un'autorità di controllo in dieci forme diverse, scritte da dieci autori che hanno deciso ciascuno la propria struttura, il lavoro di lettura diventa lentissimo e sconta un margine di errore alto. Quando il genere è stabilizzato, l'autorità può leggere cento DPIA con lo stesso sforzo con cui un critico esperto legge cento romanzi, cioè riconoscendo rapidamente dove cercare cosa, e accorgendosi altrettanto rapidamente delle deviazioni significative. Leggibilità, in questo senso, non è sinonimo di semplicità. Un sonetto è più difficile di un post su un social, ma è immensamente più leggibile per chi conosce il genere, perché sa dove cercare la volta argomentativa, il concetto centrale, la chiusura. Allo stesso modo, una DPIA ben scritta nel nuovo formato sarà più esigente nel dettaglio ma più rapida da leggere per un auditor che conosce il template. E sarà, soprattutto, comparabile con altre DPIA scritte nella stessa forma. La comparabilità è il beneficio invisibile dei generi stabilizzati, e sarà, a mio parere, il guadagno più importante degli anni che vengono per le autorità di protezione dei dati. Fino a oggi ogni ispezione partiva dal leggere un documento come se fosse il primo della sua specie, ricostruendone la forma insieme ai contenuti. Quando il nuovo template sarà lo standard, il confronto tra cento DPIA di cento titolari diversi diventerà un'operazione praticabile, perché la forma sarà condivisa e le differenze saranno informative. C'è un corollario di questa comparabilità che riguarda in modo specifico chi lavora con il committente pubblico, e che voglio sviluppare perché è la parte del nostro portafoglio che sta cambiando più in fretta. Nelle procedure di affidamento e nei capitolati tecnici, la DPIA (o la documentazione di impatto equivalente) è stata spesso richiesta come allegato generico, senza troppe specifiche sul come. L'amministrazione verificava che il documento esistesse, lasciando alla sostanza una revisione di solito tardiva, spesso in fase di esecuzione contrattuale. Con un genere stabilizzato, le stazioni appaltanti avranno la possibilità di fare una cosa diversa e, dal punto di vista di chi compete, molto più esigente: valutare la qualità del documento come criterio di selezione. Una DPIA scritta dentro il template EDPB potrà essere punteggiata in modo consistente, confrontata con quelle dei concorrenti, usata come indicatore del livello di maturità di compliance dell'offerente. Per un fornitore che ha investito nella scrittura come pratica, questo sarà un vantaggio netto, perché trasforma un allegato rituale in uno strumento di differenziazione. Per un fornitore che ha sempre trattato la DPIA come un onere amministrativo da delegare all'ultimo momento, sarà un rischio crescente, perché la distanza tra un documento ben scritto e uno abborracciato diventerà evidente a chiunque legga il template. Nei nostri ambiti specifici, dalla sanità regionale agli enti camerali ai comuni, credo che nei prossimi due anni vedremo esattamente questo tipo di selezione comparsa nei criteri di aggiudicazione: un segnale che il genere è entrato nella contrattualistica pubblica non più come casella di spunta ma come oggetto di lettura vera. ## Il sospetto degli LLM {: #il-sospetto-degli-llm } C'è una terza obiezione che va affrontata, anche se richiede una digressione, e che mi è stata formulata da persone molto vicine alla nostra realtà tecnica. Se la DPIA sta diventando un documento di prosa argomentata, si dice, allora è esattamente il tipo di testo che un modello linguistico di grandi dimensioni può produrre bene, e in pochi minuti. Perché preoccuparsi di tutto questo discorso sulla scrittura, sulla filologia d'autore, sui ruoli editoriali, quando basta un buon prompt e un paio di iterazioni per avere una DPIA formalmente impeccabile? È una domanda legittima e me la sono posta anch'io, avendo lavorato con intensità in questi mesi sugli strumenti AI-native di sviluppo. La risposta breve è che questa obiezione confonde due cose diverse, e la confusione è pericolosa. Un LLM può produrre, effettivamente, un testo che sembra una DPIA e che nella gran parte dei casi supererà una verifica formale superficiale. Ma una DPIA non è solo il suo testo finale; è la traccia documentale di un processo di decisione. Le sue sezioni non sono uno sfoggio retorico autonomo, sono la restituzione di conversazioni reali avvenute tra persone reali su trattamenti reali. Un LLM può aiutarmi a scrivere meglio quelle restituzioni, a dare ritmo al testo, a suggerire formulazioni più efficaci, e lo fa. Non può sostituire le conversazioni che stanno a monte del testo, perché quelle conversazioni sono esattamente ciò di cui la DPIA deve rendere conto. Una DPIA prodotta da LLM senza quelle conversazioni a monte è un simulacro, e la differenza con il genuino si vede presto, soprattutto quando arriva il momento di difenderla davanti a qualcuno che fa domande precise. Il genere, qui, protegge chi lo pratica onestamente e smaschera chi lo finge, perché la profondità di una DPIA ben scritta è inseparabile dalla profondità della riflessione che l'ha prodotta. Questo, tra parentesi, è un punto che la cultura dell'AI-native development sta imparando in ogni dominio in cui si spinge: gli strumenti automatici sono eccellenti amplificatori di pensiero, ma non sostitutivi di pensiero. Ed è proprio nei generi maturi che la differenza tra le due cose si vede meglio. ## Un ecosistema di generi tecnico-normativi {: #un-ecosistema-di-generi-tecnico-normativi } C'è un punto correlato che merita un cenno, anche se meriterebbe un pezzo a parte. La DPIA-genere, proprio perché vive nello stesso ecosistema del prodotto, si presta a integrazioni che la DPIA-modulo non poteva avere. Penso in particolare al nesso con l'SBOM, il software bill of materials, che sta diventando un requisito sempre più formalizzato in ambito Cyber Resilience Act. Le due documentazioni, SBOM e DPIA, hanno storie separate e logiche diverse, ma parlano della stessa piattaforma. Quando entrambe vivono versionate e interrogabili, diventa possibile cose come: identificare quali componenti software sono coinvolti nel trattamento dei dati sensibili descritto nella sezione X della DPIA, o segnalare quando un aggiornamento di dipendenza introduce un componente che cambia il profilo di rischio documentato. Uno sviluppatore che aggiorna una libreria di logging, per dirne una, può ricevere automaticamente un alert che gli dice: «questa libreria è referenziata nella DPIA del progetto Y, paragrafo 4.2, verifica se la nuova versione modifica il comportamento descritto». Sono scenari che, in un'ottica di prodotto integrato, restano fantascientifici; in un'ottica di compliance integrata diventano, se non facili, almeno pensabili. E il motivo per cui diventano pensabili è, ancora una volta, che la DPIA sta diventando un testo governato da convenzioni note, navigabile come si naviga un testo, e non una griglia opaca al mondo esterno. Il nesso tra SBOM e DPIA, peraltro, è il punto in cui mi accorgo che il discorso che sto facendo ha implicazioni più ampie della DPIA stessa. Se la DPIA si sta trasformando in genere, è ragionevole chiedersi se altri artefatti della compliance europea stiano subendo la stessa trasformazione, e in che direzione. Mi sembra evidente, per fare un esempio, che anche il fascicolo tecnico dell'AI Act sia in traiettoria verso un'identità di genere, con le sue sezioni canoniche, il suo ritmo argomentativo, la sua pretesa di leggibilità da parte di un'autorità di mercato. Lo stesso vale, a un livello diverso, per la documentazione di vulnerabilità e per le policy di disclosure che il Cyber Resilience Act sta stabilizzando nel corso dell'anno, con le obbligazioni di reporting che entreranno in vigore a settembre 2026 e le obbligazioni sostanziali piene da dicembre 2027. Stiamo assistendo, in Europa, a una decennale operazione di generazione di generi tecnico-normativi, che avrà conseguenze ancora in buona parte inesplorate sul lavoro di chi produce software. Dieci anni fa la compliance software era una costellazione di moduli. Fra dieci anni sarà, con ogni probabilità, una biblioteca di generi, ciascuno con i suoi canoni, i suoi esemplari di riferimento, la sua critica consolidata, la sua scuola di autori. Questa prospettiva, che può sembrare astratta, ha un risvolto commerciale concreto di cui credo si parli ancora troppo poco. Un'impresa che ha imparato a scrivere dentro generi normativi maturi ha un vantaggio competitivo sostanziale rispetto a un'impresa che ogni volta deve imparare daccapo. E imparare a scrivere dentro un genere non è una cosa che si fa in un corso di una settimana: richiede pratica, correzione, esposizione a buoni e cattivi esemplari, critica tra pari, esperienza progressiva di quale formulazione tiene e quale no. L'Europa sta costruendo, con tempi e modi non sempre coordinati, un ecosistema di generi tecnico-normativi che premierà le organizzazioni capaci di fare di questa scrittura una competenza stabile. Per chi fa il nostro mestiere, il software per la pubblica amministrazione e per la sanità, questo significa che il prossimo quinquennio non sarà vinto da chi scrive codice più elegante ma da chi scrive documenti di compliance migliori, intendendo per migliori non più dettagliati ma più leggibili, più argomentati, più capaci di sostenere un confronto con lettori competenti. È un cambio di paradigma che attraversa trasversalmente le nostre organizzazioni e ridefinisce quali competenze siano scarse e quali no. Torno allora alla DPIA, con un'osservazione che spero non suoni troppo astratta. Il fatto che un modulo si stia trasformando in genere è una di quelle cose che, una volta avvenuta, cambia retrospettivamente il modo in cui leggiamo la storia precedente. Le DPIA scritte negli anni tra il 2018 e il 2025 erano già in qualche misura genere, perché esistevano attese di lettura, perché circolavano esemplari considerati buoni o cattivi, perché le autorità cominciavano a costruire una giurisprudenza implicita di cosa volesse dire una DPIA fatta bene. Era un genere in formazione, fluido, con confini incerti. Il template EDPB, una volta chiusa la consultazione e avviati i passi di adozione nazionali, fisserà quei confini, cristallizzerà quel genere, e nel farlo renderà retroattivamente visibile una traiettoria che prima era ambigua. Da quel momento in poi, la DPIA avrà un prima e un dopo, e la differenza tra i due non sarà una questione di dettaglio ma di natura. La finestra in cui scriviamo adesso è esattamente il momento in cui questo passaggio si compie: non è più prima, non è ancora del tutto dopo, è la soglia. ## Cosa fare domani mattina {: #cosa-fare-domani-mattina } Mi rendo conto che tutto questo discorso può suonare, a un ingegnere pragmatico, come un'astrazione filosofica inutile. A cosa mi serve, nel lavoro concreto di domani, sapere che la DPIA sta diventando un genere? La risposta pratica l'ho già distribuita nei paragrafi precedenti, ma vale la pena ricomporla in una forma più vicina a ciò che un team deve fare quando apre il prossimo progetto. Bisogna smettere di trattare la DPIA come un documento di chiusura, prodotto a valle della progettazione, e cominciare a trattarla come un documento di accompagnamento, che nasce con il progetto e cresce con lui. Bisogna accettare che le persone che contribuiscono alla DPIA non sono più soltanto il legale e il DPO, ma anche chi costruisce il prodotto, e questo richiede un investimento, piccolo ma costante, nella loro capacità di scrivere testi argomentati. Bisogna introdurre nei processi di sviluppo i collegamenti, tecnici e organizzativi, tra i ticket di progetto e i paragrafi di DPIA, in modo che la scrittura non resti un'attività parallela ma diventi parte del lavoro corrente. Bisogna ripensare il ruolo del DPO come editor più che come redattore unico, con tutto quello che questo comporta in termini di relazione con il resto del team. Nessuno di questi cambi è drammatico preso singolarmente. Messi insieme ridisegnano il modo in cui la compliance dati si fa, e fanno emergere la differenza tra organizzazioni che hanno capito il passaggio e organizzazioni che continueranno a produrre moduli in un mondo che legge generi. C'è poi una cosa che voglio segnalare a chi, come noi, sta operando proprio in questa finestra di formazione del genere. La consultazione pubblica aperta dall'EDPB non è un adempimento formale che riguarda solo gli addetti ai lavori della protezione dei dati: è il momento in cui il template viene ancora modellato, ed è quindi il momento in cui una voce informata può lasciare un segno. Un fornitore di software per la PA italiana che manda un contributo ragionato, riferito all'esperienza concreta di scrivere DPIA per enti pubblici, partecipa alla definizione del genere più di quanto immagini. Non è un gesto simbolico: la consultazione è lo strumento attraverso cui le autorità europee raccolgono i casi limite, le difficoltà operative, le incompatibilità con prassi consolidate, e riformulano le sezioni in risposta. Nei prossimi due mesi, da qui al 9 giugno, c'è un tempo utile a contribuire. Dopo sarà tardi nel senso specifico che le forme del canone saranno state scelte. Vale la pena di spenderci una giornata. ## Un'ora di riscrittura {: #unora-di-riscrittura } Vorrei chiudere con un'immagine che mi è venuta in mente qualche settimana fa, rileggendo per l'ennesima volta un paragrafo sulle misure di mitigazione in una DPIA di un progetto sanitario. Il paragrafo era formalmente corretto, copriva i punti richiesti, citava le norme giuste. Ma era scritto male, con quella particolare opacità che hanno i testi tecnici non curati, in cui la sintassi è sostanzialmente un parcheggio di clausole. L'ho riletto pensando: se un auditor legge questo passaggio in fretta, cosa porta a casa? La risposta era: quasi niente, perché il testo non è fatto per essere letto in fretta, anzi non è fatto per essere letto affatto. È fatto per essere presente. È archeologia di compliance prima ancora di essere archiviato. Ho passato un'ora a riscriverlo, senza aggiungere contenuti, soltanto mettendo in ordine il ritmo. Alla fine il paragrafo era lungo il 30% in meno e, soprattutto, diceva le stesse cose con una chiarezza che prima non aveva. La differenza era editoriale, non tecnica. Ma era esattamente la differenza che separa un modulo da un genere. Quell'ora di lavoro, a pensarci bene, è la cifra esatta del cambiamento che sto cercando di descrivere. In un mondo DPIA-modulo, un'ora di riscrittura su un paragrafo che è formalmente corretto è tempo sprecato: il documento è compliant, chiudere il ticket, passare al prossimo. In un mondo DPIA-genere, quell'ora è l'unica parte davvero produttiva della giornata, perché è l'unica che migliora la qualità del testo come testo. La trasformazione che stiamo descrivendo, insomma, cambia anche la definizione di tempo ben speso. Cambia cosa un team è autorizzato a considerare lavoro. E cambia, di conseguenza, come il lavoro va pianificato. Una sprint planning che riserva due ore a settimana alla scrittura e revisione collaborativa della DPIA non è un'eccentricità di un team che ama perdere tempo in letteratura tecnica; è un team che ha capito in quale regime documentale sta cominciando a operare. Un team che continua a trattare la DPIA come un artefatto da produrre in un pomeriggio alla fine del progetto sta, letteralmente, vivendo in un regime che sta smettendo di esistere. Questo piccolo episodio si collega, nella mia testa, a un filo che sto tirando da mesi su cose apparentemente diverse: il software che non invecchia bene, il prodotto che smette di essere una categoria stabile, l'internet che è stata recintata più che degenerata. In tutti questi casi la questione di fondo è la stessa, e riguarda la scrittura. Quando un artefatto tecnico smette di essere autosufficiente e diventa parte di un ecosistema di testi che ne documentano l'esistenza, le proprietà del testo contano quanto e più delle proprietà dell'artefatto. Il software moderno, dicevo in *Cruft, non patina*, non invecchia perché non è mai abbastanza finito per invecchiare. La DPIA, in una piega speculare, non può più essere abbastanza finita per essere archiviata: vive finché vive il trattamento che documenta, e ogni sua versione è una fotografia in movimento, non un monumento. **La compliance sta diventando, senza che quasi nessuno se ne accorga, una pratica di scrittura continua, non di archiviazione finale.** E come ogni pratica di scrittura continua, premia chi la prende sul serio come scrittura, non chi la finge come modulistica. È una direzione che domanderà di più a chi scrive, ma che restituirà anche di più, nel lungo periodo, in termini di qualità delle decisioni prese, di difendibilità delle scelte fatte, di trasmissibilità del sapere accumulato. Tradurla in pratica, nei nostri flussi di lavoro, è il lavoro che ci aspetta per i prossimi mesi. Non è un lavoro urgente nel senso delle deadline; è un lavoro urgente nel senso che più si tarda, più il debito di scrittura si accumula. E un debito di scrittura, in un genere in via di stabilizzazione, è difficile da ripagare quando il momento del giudizio arriva. Chi sta scrivendo adesso le sue prime DPIA nel nuovo template sta anche, senza saperlo del tutto, partecipando alla formazione di un canone. Nei prossimi due o tre anni si deciderà, attraverso la somma delle pratiche concrete di migliaia di organizzazioni europee, quali tratti del genere si consolideranno come normali e quali resteranno marginali. Vale la pena esserci, per una volta, non come spettatori ma come autori. --- # Cruft, non patina - **URL:** https://margiovanni.it/it/blog/cruft-non-patina/ - **Pubblicato:** 2026-04-19 - **Tag:** Sviluppo Software, Software, Filosofia Della Tecnica, Debito Tecnico - **Tempo di lettura:** 25 min > Gli edifici imparano, scriveva Stewart Brand. Il software, invece, accumula commenti che si scusano. Sul perché gli oggetti digitali non sanno invecchiare, e su cosa questo dice della civiltà che li mette al centro. Stewart Brand, trentadue anni fa, ha pubblicato un libro che si chiama *How Buildings Learn*. L'idea di fondo è semplice e scomoda: un edificio ben progettato non è quello che resta identico a sé stesso, ma quello che sa essere modificato, abitato, rattoppato, reinterpretato nel tempo. Brand fotografa gli stessi edifici a distanza di decenni e mostra le alterazioni che ne raccontano la storia. Una scala aggiunta su un lato, un tramezzo abbattuto per unire due uffici, un tetto rifatto dopo l'incendio, una facciata dipinta tre volte e poi lasciata scrostare. La qualità architettonica, sostiene Brand, non si misura nel momento dell'inaugurazione ma in come l'oggetto regge all'uso umano stratificato. La parola che usa per questa condizione è *learning*: gli edifici imparano, nel senso che il loro tessuto fisico accumula informazione attraverso gli anni, e a un certo punto la quantità di informazione accumulata diventa essa stessa parte del valore dell'oggetto. Il software non impara, in questo senso. Il software accumula commenti che si scusano. ## L'archeologia del codice vecchio {: #larcheologia-del-codice-vecchio } Chiunque abbia lavorato su una codebase vecchia più di dieci anni riconosce un certo tipo di commento. `// HACK: rimuovere quando migreremo all'API v2`. `// TODO: capire perché questo funziona`. `// NON TOCCARE: ha rotto la produzione tre volte`. Sono firme di persone che non lavorano più lì, destinate a lettori futuri che non arriveranno mai davvero a risolverle. Sono patina? Sono tessuto cicatriziale, piuttosto. La differenza non è soltanto lessicale. Una sedia di Alvar Aalto del 1932, se è stata usata davvero, oggi ha un valore estetico che la sedia uscita dalla fabbrica nel '32 non aveva. Il legno si è scurito nei punti dove le mani si appoggiano. La finitura opaca ha perso lucentezza in modo non uniforme, ha imparato il corpo di chi ci si è seduto. C'è forse una riparazione nel punto di giunzione tra gamba e seduta, una vite cambiata, un rinforzo fatto con gusto da qualche proprietario intermedio. Tutto questo non la rende peggiore. La rende più bella, più preziosa, più sé stessa. Un restauratore serio rifiuta di rimuovere la patina, perché la patina è diventata parte costitutiva dell'oggetto. Il restauro è l'arte di distinguere il danno dalla storia. Un software PHP del 1998, se è stato usato davvero, oggi non ha nessun valore estetico aggiunto. Ha workaround stratificati per browser che non esistono più. Ha controlli di validazione che sono stati aggiunti tre volte a tre livelli diversi perché a ogni ciclo di manutenzione nessuno si fidava di quelli preesistenti. Ha funzioni di quattrocento righe che gestiscono casi particolari introdotti da clienti che non sono più clienti da dieci anni. Nessuno propone di preservare questa condizione come parte del valore del prodotto. Si parla di debito tecnico, termine rivelatore: debito, non storia. Qualcosa da estinguere, non da onorare. Il vocabolario stesso con cui il settore descrive il proprio rapporto con il tempo rivela che non c'è nessun concetto disponibile per chiamare bello un sistema vecchio. Al massimo si può dire che è "solido", "battle-tested", "proven". Sono virtù di resistenza, non virtù di accumulazione. L'archeologia del codice vecchio è una disciplina informale che ogni sviluppatore senior pratica senza averla mai studiata, e che ha le sue costanti riconoscibili. Ci sono gli strati di compatibilità con browser ormai estinti: `if (window.ActiveXObject)` per riconoscere le vecchie versioni di Internet Explorer, hack CSS che sfruttano bug specifici di Firefox di prima delle grandi rewrite, condizioni che controllano la presenza di `window.attachEvent` per distinguere IE dal resto dei browser quando i browser concorrenti erano molti e tutti diversi. Ci sono feature flag accesi per rollout graduali mai completati, dove metà del codice è dietro una condizione `if (feature_active('new_checkout_flow'))` e l'altra metà nel ramo `else`, e la feature è in produzione al cento per cento da sette anni ma nessuno ha il coraggio di rimuovere il ramo morto perché nessuno ricorda esattamente cosa facesse. Ci sono migrazioni di schema iniziate e mai portate a termine, in cui due colonne coesistono nella stessa tabella, una con il nome vecchio e una con il nome nuovo, scritte entrambe dalla logica applicativa "per sicurezza", lette selettivamente a seconda del punto del codice in cui ci si trova. Ci sono funzioni con nomi come `processOrderLegacy`, `processOrderLegacyV2`, `processOrderFinal`, `processOrderActuallyFinal`, che testimoniano una progressione di tentativi di pulizia nessuno dei quali è stato davvero completato. Nulla di questo è patina. È un registro sedimentario di promesse non mantenute, di intenzioni che la vita aziendale ha sistematicamente superato prima che si realizzassero. Se un restauratore di mobili trovasse in un cassettone del Settecento venti strati sovrapposti di vernice, ognuno steso senza rimuovere il precedente, non direbbe che l'oggetto ha guadagnato valore attraverso le stratificazioni: direbbe che è stato trattato male, e proporrebbe un intervento di rimozione. Il codice vecchio è trattato esattamente così anche dagli addetti ai lavori, che lo chiamano *legacy* con un tono in cui la neutralità tecnica si mescola con un velato disprezzo. La parola stessa è forse la spia più esplicita del rapporto irrisolto del settore con il proprio passato: viene dal latino *legare*, lasciare in eredità, ma nell'uso tecnico ha preso un significato quasi opposto, cioè qualcosa che è stato subìto e di cui ci si vorrebbe liberare. Il lascito come fardello, non come dono. ## Perché il software non invecchia {: #perche-il-software-non-invecchia } La domanda è perché. Perché gli oggetti materiali riescono a guadagnare in qualcosa attraverso il tempo, mentre gli oggetti digitali sembrano poter solo perdere. Una risposta facile è che si tratta di una differenza ontologica: il codice è pura semantica, non ha un substrato materiale su cui possano depositarsi i segni dell'uso. Il legno respira, assorbe umidità, si ossida, si consuma nei punti di attrito. Il byte non fa niente di tutto questo. Un file binario oggi è bit-per-bit identico a quando è stato scritto, salvo corruzioni accidentali del supporto, e anche queste corruzioni non hanno nessun valore semantico: non dicono nulla dell'uso che se ne è fatto. La risposta facile ha il difetto di tutte le risposte facili, che è quello di chiudere il discorso proprio nel punto in cui dovrebbe cominciare. Proviamo ad andare un po' più a fondo. Il motivo per cui una sedia invecchia bene non è che sia fatta di legno, ma che il suo intorno resta sostanzialmente stabile. La gravità non cambia. La fisiologia umana non cambia. La funzione di "sostenere un corpo seduto" non cambia. Le modifiche che la sedia subisce sono modifiche interne al suo tessuto, in dialogo con un ambiente che si muove molto più lentamente di lei. La sedia e il mondo attorno alla sedia invecchiano insieme, e invecchiano alla stessa velocità, e il risultato è una specie di co-evoluzione addomesticata. Il software esiste in un ambiente che si muove molto più velocemente di lui. Il browser cambia versione ogni quattro settimane. Il linguaggio rompe la retrocompatibilità ogni due anni. Le librerie hanno un ciclo di vita più corto di un mandato parlamentare. Il sistema operativo sotto cui gira smette di esistere nella forma in cui era stato compilato. Il software non invecchia internamente, come fa il legno. Si stacca progressivamente dal suo ambiente, come un'astronave che ha finito il propellente e vede la stazione spaziale allontanarsi. Quello che chiamiamo "software aging" non è aging nel senso della sedia. È drift ambientale. È la misura della distanza crescente tra un artefatto fisso e un contesto che si muove. Questa differenza è ontologicamente rilevante. Un edificio e il suo contesto urbano invecchiano insieme in dialogo continuo, e questa co-appartenenza è la condizione stessa del fatto che si possa parlare di "invecchiamento" in senso proprio. Il software non ha co-appartenenza: ha compatibilità, che è una relazione molto più povera. Compatibilità significa solo che due cose che non si parlano possono continuare a far finta di parlarsi per un altro ciclo di rilascio. Quando Stewart Brand scrive che gli edifici imparano, sta descrivendo un processo in cui l'edificio e i suoi abitanti si modificano a vicenda. Quando un sistemista aggiunge un compatibility shim per far girare un vecchio eseguibile sul nuovo kernel, sta mettendo un cuneo tra due mondi che non si parlano più, e sta comprando tempo. Lo shim è l'opposto dell'apprendimento: è l'ammissione che l'apprendimento non è possibile, che si può solo simulare la comunicazione. ## Ruskin, e la verità dell'uso {: #ruskin-e-la-verita-delluso } C'è un passaggio in Ruskin, nelle *Seven Lamps of Architecture*, in cui sostiene che un edificio nuovo è per sua natura falso, e diventa vero solo attraverso la frequentazione degli anni. Ruskin è vittoriano, enfatico, spesso irritante, ma questa frase è una delle cose più precise che siano state dette sull'oggetto costruito. La verità di un edificio non è nel progetto ma nella storia del suo uso. Se applichiamo lo stesso criterio al software, bisogna concludere che il software non diventa mai vero. Resta in uno stato permanente di novità, anche quando la sua data di compilazione è di venticinque anni fa, perché l'accumulazione di storia che dovrebbe renderlo reale in senso ruskiniano non è possibile nel suo mezzo. L'unica cosa che accumula è l'incompatibilità crescente con il suo intorno, e questo non è storia: è erosione. ## L'obiezione Unix {: #lobiezione-unix } A questo punto bisogna affrontare l'obiezione forte, quella che ogni lettore tecnicamente competente ha già formulato mentalmente nei primi paragrafi, e che se non viene affrontata rende tutto il ragionamento precedente sospetto. L'obiezione è: ma Unix è vecchio di più di mezzo secolo, e non solo funziona ancora, ma è diventato più elegante nel tempo, non meno. POSIX, TCP/IP, SQL, il filesystem gerarchico, la pipe. Sono tutte idee che hanno fra i quarant'anni e il mezzo secolo abbondante sulle spalle. Sono ancora al centro dell'infrastruttura digitale del pianeta. Non si comportano come il PHP del 1998 di prima. Si comportano, se vogliamo, esattamente come la sedia di Aalto: oggetti che hanno attraversato il tempo guadagnando, non perdendo. Qualcosa nel ragionamento non torna. L'obiezione è seria e merita una risposta seria. La risposta più facile sarebbe dire che Unix è un'eccezione, un outlier, un caso fortunato che non invalida la regola. Sarebbe una risposta povera. La risposta più interessante è che Unix non contraddice il ragionamento precedente, ma ne mostra il meccanismo esatto, e chiarisce una distinzione che finora è rimasta implicita. La distinzione è tra software come codice e software come specifica. ## Specifica, non codice {: #specifica-non-codice } Quello che chiamiamo "Unix" oggi non è, letteralmente, il software che Ken Thompson e Dennis Ritchie hanno scritto ai Bell Labs tra il 1969 e il 1971. Quel codice è morto da decenni. Il ramo commerciale AT&T è stato venduto, smembrato, riassorbito. BSD è stato forkato molte volte, e ciascun fork è stato a sua volta riscritto. Linux, che è oggi la forma dominante di "Unix" nell'infrastruttura globale, non condivide una singola riga di codice con il Unix originario: è una reimplementazione indipendente, avviata da Linus Torvalds nel 1991, che espone le stesse interfacce di sistema (chiamate, struttura del filesystem, convenzioni) ma è stata scritta da capo. macOS deriva da NeXTSTEP, che a sua volta poggia sul microkernel Mach e su componenti BSD, e anche qui il codice è stato riscritto e rifuso tante volte che la continuità materiale con il punto di partenza è puramente rituale. Quello che è sopravvissuto non è il corpo di Unix, ma la sua forma. La sua interfaccia. La sua grammatica. Il fatto che ci siano chiamate di sistema che si chiamano `open`, `read`, `write`, `close`, e che funzionino più o meno come funzionavano nel 1973, non vuol dire che il codice che le implementa sia invecchiato bene. Vuol dire che la specifica che le definisce è diventata una cosa diversa dal codice: è diventata cultura, convenzione, linguaggio condiviso, norma de facto e poi norma de iure tramite POSIX. Lo stesso vale per TCP/IP. Il protocollo è sopravvissuto, l'implementazione no, o almeno non nella sua forma originaria. Ogni stack TCP/IP moderno, da Linux a Windows a iOS all'ESP32 che alimenta una lampadina intelligente, è stato riscritto o riallineato più volte nei decenni. La 4.4BSD networking code, che per lungo tempo ha fornito la base di riferimento del kernel di rete in molti sistemi, è stata via via assorbita, ramificata e reimplementata al punto che i codici moderni mantengono con essa una parentela storica più che materiale. Quello che persiste, immutato, è l'RFC: un documento di testo che descrive, in inglese tecnico, come due macchine dovrebbero parlarsi. L'RFC non è software. È più simile a un trattato diplomatico che a un programma. È per questo che invecchia bene: perché appartiene alla stessa classe di oggetti di un trattato diplomatico, o di una costituzione, o di una grammatica. È una convenzione condivisa la cui forza non sta nella sua implementazione ma nel numero di attori che la riconoscono come vincolante. SQL è il caso più istruttivo. La sintassi `SELECT ... FROM ... WHERE` è stata definita a metà degli anni Settanta da Donald Chamberlin e Raymond Boyce alla IBM. Oggi la usa chiunque. Ma nessun database relazionale oggi in produzione gira sul codice originale di System R. Postgres è una reimplementazione. MySQL è una reimplementazione. SQLite è stato scritto da zero negli anni Duemila e oggi è probabilmente il database più diffuso al mondo per numero di istanze attive, superato forse solo dai fogli Excel. Il codice che implementa SQL è morto e rinato tante volte che non ha senso parlare di continuità materiale. Quello che è rimasto è il modello relazionale, che è un oggetto matematico, e una certa sintassi, che è un oggetto culturale. Entrambi si sono staccati dal codice che li aveva inizialmente incarnati, e proprio per questo hanno potuto attraversare il tempo. ## TeX, SQLite, e le eccezioni che confermano {: #tex-sqlite-e-le-eccezioni-che-confermano } Ci sono però alcuni casi, rarissimi, in cui il codice stesso sembra essere riuscito in qualcosa che assomiglia davvero alla patina, e vale la pena osservarli perché illuminano per contrasto la condizione generale. TeX, il sistema di composizione tipografica scritto da Donald Knuth a partire dal 1978, è uno di questi. Knuth ha deciso a un certo punto che TeX fosse finito, nel senso letterale del termine: nessuna nuova feature, soltanto correzioni di bug, e il numero di versione che converge asintoticamente verso il valore di pi greco a ogni release, con l'intento esplicito che l'ultima versione, quando Knuth morirà, assuma il valore esatto di pi greco e che il software smetta di cambiare per sempre. Knuth offre una piccola ricompensa monetaria, che raddoppia ogni anno, a chiunque trovi un bug in TeX, e ormai da molti anni nessuno li reclama. Non perché non ci siano, ma perché il software è stato usato così tanto e per così tanto tempo che i bug residui vivono in angoli che non vengono mai visitati. TeX funziona oggi come funzionava a fine anni Ottanta, compila gli stessi file sorgente, produce lo stesso output tipografico. Il suo codice, scritto in WEB (un sistema di literate programming inventato da Knuth stesso, che combina Pascal per la logica di programma e TeX per la documentazione), è stato pubblicato nel 1986 con il titolo *TeX: The Program*, come Volume B di *Computers and Typesetting*, ed è trattato come un'opera letteraria. È stato letto, commentato, studiato. È una delle poche volte in cui il codice ha oltrepassato la soglia dell'implementazione pura ed è diventato esso stesso qualcosa di simile a una specifica, ma nella forma concreta del programma, non nella forma astratta del documento RFC. Knuth ha ottenuto questo risultato imponendo alla propria opera una condizione estrema: rifiutare ogni evoluzione. TeX non invecchia perché ha scelto di non vivere, in un certo senso. Ha accettato la mummificazione come prezzo della permanenza. SQLite è l'altro caso interessante, più recente e meno mistico. I suoi sviluppatori hanno dichiarato pubblicamente, nella documentazione del progetto, l'intenzione di mantenere la libreria almeno fino al 2050, con piena retrocompatibilità dell'API C e del formato on-disk. Questo impegno non è una formula di stile ma un vincolo concreto che deriva dal fatto che SQLite è integrato in sistemi avionici (Airbus A350 tra gli altri), dispositivi medicali, apparati militari, tutti oggetti con cicli di vita che superano i quarant'anni. Per sostenere un simile orizzonte, SQLite ha costruito un apparato di test che, secondo le cifre dichiarate dagli stessi sviluppatori, arriva a circa novantadue milioni di righe di codice di test contro le centocinquantamila righe della libreria vera e propria, un rapporto di quasi seicento a uno. Ogni diramazione condizionale del codice è coperta da test MC/DC, lo standard impiegato nell'avionica per le certificazioni DO-178B. Il codice stesso è scritto con attenzione esplicita al fatto che sarà letto e mantenuto da persone non ancora nate. SQLite ha preso il problema della durata come problema di design fin dall'inizio, e ha trattato la stabilità della propria interfaccia come una questione etica più che tecnica. Il risultato è un pezzo di software che esiste da più di venticinque anni, gira su miliardi di dispositivi, e che nessuno ha mai sentito il bisogno di riscrivere da capo. È un caso in cui il codice stesso, non la sua specifica, sembra essere invecchiato bene. Ma se si guarda più da vicino, si capisce che questo risultato è stato ottenuto solo al prezzo di un'accettazione radicale di vincoli che il resto del settore non sarebbe disposto ad accettare. SQLite non cambia quasi mai, anche a costo di rinunciare a feature che renderebbero il codice più moderno. SQLite non ha dipendenze esterne, quasi una protesta contro il modo in cui il resto del mondo costruisce software oggi. SQLite ha una cultura interna disciplinare che rasenta il monastico. In altre parole, SQLite riesce a invecchiare bene perché si è costruito una nicchia ecologica in cui l'ambiente attorno al codice è stato artificialmente stabilizzato. Ha ricreato, dentro un piccolo perimetro, le condizioni che permettono alla sedia di Aalto di diventare più bella con gli anni: un ambiente che si muove lentamente, un utilizzatore attento, una cultura che riconosce il valore della durata. Non è un caso che questi esempi siano, statisticamente, delle anomalie. Sono le eccezioni che rivelano esattamente quali sono le condizioni necessarie per l'invecchiamento del software, e confermano che queste condizioni, nel corpo principale del settore, non esistono. ## Il corpo muore, la specifica risorge {: #il-corpo-muore-la-specifica-risorge } Se guardiamo la questione da questo angolo, Unix non invecchia bene. Unix è continuamente risorto. Il corpo muore e viene rifatto da zero, a partire da una specifica che nel frattempo è diventata sacra al punto da meritare la riscrittura integrale del corpo ogni venti o trent'anni. È la struttura di una religione più che di un oggetto materiale. La sedia di Aalto, per rimanere sulla nostra metafora, non è mai stata rifatta da zero: la sedia di Aalto del 1932 è fisicamente lì, con le sue ammaccature. Se applicassimo al legno la logica di Unix, dovremmo dire che il concetto di "sedia Paimio modello 41" è sopravvissuto perché Artek, dalla sua fondazione nel 1935, ne ha continuato la produzione per oltre novant'anni, e che le sedie del 2026 sono discendenti di quelle del 1932 ma non sono le stesse sedie. Sarebbe vero, ma spostato: quello che ci interessa della sedia del 1932 è proprio la sua durata materiale, non la persistenza del suo modello. Nel software accade l'opposto. Non ci interessa il codice originario, e nessuno lo conserva come reliquia. Ci interessa la persistenza del modello, e questa persistenza richiede la distruzione e riscrittura periodica del codice. L'obiezione Unix, quindi, non smentisce il ragionamento ma lo ridefinisce. Quello che invecchia bene nel digitale non è codice. Sono specifiche che hanno avuto la fortuna, e il capitale culturale, di sollevarsi al di sopra del loro substrato di implementazione e diventare qualcosa di diverso. Norme. Interfacce stabili. Lingue franche. La maggior parte del codice non raggiunge mai questo livello e non può raggiungerlo. Il 99% del software che gira oggi nel mondo non diventerà POSIX. Il CRM su misura di un'azienda di quattrocento dipendenti non diventerà SQL. Il sito e-commerce di una catena di negozi non diventerà TCP/IP. Non perché sia scritto male, ma perché non è quel tipo di oggetto. È, strutturalmente, implementazione. E l'implementazione, nel digitale, non può invecchiare bene, perché non ha nessuno dei requisiti per farlo: non ha substrato materiale che registri l'uso, non ha ambiente stabile in cui permanere, non ha il peso culturale che permette la reincarnazione periodica. ## Riscrivere non è un peccato {: #riscrivere-non-e-un-peccato } Questa distinzione illumina anche un dibattito interno al settore che è sempre stato mal posto. Joel Spolsky, nel 2000, scrisse un articolo che ha avuto molta fortuna, intitolato *Things You Should Never Do, Part I*, in cui sosteneva che riscrivere da zero un software funzionante è il peggiore errore strategico che un'azienda di software possa commettere. L'argomento era buono e specifico: Netscape aveva perso il mercato perché si era messa a riscrivere il browser da zero, lasciando finestra aperta a Internet Explorer per tre anni. Il problema dell'articolo di Spolsky è che generalizza da un caso particolare senza riconoscere che la maggior parte del software *deve* essere riscritta, prima o poi, perché non può essere mantenuta indefinitamente nella forma in cui è stata concepita. Unix è stato riscritto più volte. Linux stesso, a livello di singoli sottosistemi, viene continuamente riscritto: lo scheduler è stato sostituito, il networking stack è stato rifatto, il filesystem è stato ripensato. Quello che Spolsky chiamava "non riscrivere mai" è in realtà "non perdere la continuità della specifica durante la riscrittura", che è una cosa molto diversa e molto più difficile. La riscrittura fallisce quando perde il contatto con quello che il codice doveva fare per i suoi utenti reali. Riesce quando conserva la specifica e butta via l'implementazione, nello stesso modo in cui il corpo di un cattolico viene sepolto ma l'anima migra altrove. ## Una dignità preclusa {: #una-dignita-preclusa } Se questa lettura è corretta, allora la tristezza sottesa a buona parte del lavoro tecnico quotidiano ha una spiegazione strutturale e non psicologica. Non stiamo scrivendo male. Stiamo scrivendo oggetti che non possono invecchiare, perché non apparteniamo alla classe ristretta degli artefatti che possono elevarsi a specifica culturale. Il 99% di quello che scriviamo è destinato a morire senza lasciare traccia, non per un difetto di fattura ma per una proprietà del mezzo. Un muratore del Duecento sapeva che se il suo muro era fatto bene sarebbe stato lì nel Cinquecento, e probabilmente anche oltre. Un idraulico del Novecento sapeva che i suoi tubi, con un po' di manutenzione, avrebbero servito tre generazioni. Uno sviluppatore del 2026 sa che il codice che sta scrivendo oggi, con buone probabilità, sarà dismesso entro cinque o sette anni. Non perché sia stato scritto peggio dei tubi. Ma perché il tubo e il muro appartengono a un regime in cui l'invecchiamento è possibile, e il codice no. Questo cambia la natura etica del mestiere in modi che non abbiamo ancora metabolizzato. Costruire qualcosa di duraturo è stato per millenni una delle forme più alte di dignità del lavoro umano. La cattedrale, il ponte, il libro stampato, il violino. Oggetti fatti con la coscienza di durare oltre la vita di chi li costruiva. Lo sviluppo software è uno dei pochi mestieri ad alta qualifica in cui questa dignità è strutturalmente preclusa. Non perché nessuno lavori bene, ma perché il mezzo non ammette quel tipo di durata. Il debito tecnico di cui parlavamo all'inizio, visto da questa angolatura, non è un difetto gestibile con migliori pratiche, maggiore disciplina, test più rigorosi, revisioni del codice più attente. È la forma specifica che assume l'inevitabile deterioramento di un artefatto che non ha altro modo di deteriorarsi. È il modo in cui il software invecchia male perché non sa invecchiare in nessun altro modo. ## La lampada della memoria {: #la-lampada-della-memoria } C'è una lettura più ampia di tutto questo, che esce dal dominio strettamente tecnico e tocca qualcosa di più scomodo sulla cultura in cui viviamo. Ruskin, di nuovo, identificava sette virtù dell'architettura, che chiamava lampade. Sacrificio, verità, potenza, bellezza, vita, memoria, obbedienza. La lampada della memoria era, per lui, la virtù degli edifici che si lasciano attraversare dal tempo senza resistergli, che conservano le tracce di chi li ha abitati, che diventano a loro modo archivi biografici del passaggio umano. Una civiltà che non sa costruire oggetti capaci di memoria, diceva Ruskin, è una civiltà che ha rinunciato a una delle sue funzioni fondamentali, che è quella di tramandare sé stessa attraverso le sue cose. Il digitale, da questo punto di vista, è l'opposto esatto dell'architettura ruskiniana. È una cultura materiale, se così si può ancora chiamare, in cui la memoria non si accumula nelle cose ma le lascia. Il software di cinque anni fa è già un'antichità. Il sito web di dieci anni fa non è più accessibile, il suo dominio è scaduto, i suoi link sono tutti rotti, le sue immagini puntano a server dismessi. Gli archivi digitali esistono solo grazie a sforzi eroici e marginali: Internet Archive è un singolo punto di fallimento per la memoria di tre decenni di cultura online, e nessuno ha capito davvero come sostituirlo. Le nostre fotografie sono su server che non possediamo, in formati che potrebbero non essere letti tra vent'anni, protette da contratti di servizio che possono essere modificati unilateralmente. La nostra corrispondenza è in caselle di posta che spariranno quando l'azienda che le ospita deciderà di cambiare modello di business. La continuità materiale del patrimonio umano, che per millenni è stata garantita, sia pure imperfettamente, dalla durata fisica degli oggetti, è diventata precaria in un modo che nessuna civiltà precedente aveva conosciuto. Questa precarietà non è un effetto collaterale ma una proprietà strutturale del mezzo. E il software, che è il cuore di questa nuova condizione, eredita e amplifica la precarietà. Non invecchia perché non sa accumulare memoria nelle sue fibre. Non ha fibre. La sua unica forma di continuità è la riscrittura, che è il contrario esatto della memoria: è la produzione periodica di un nuovo oggetto che finge di essere lo stesso. Qualcuno a questo punto potrebbe obiettare che sto drammatizzando, che ogni epoca ha avuto la sua precarietà, che il papiro si decomponeva e la pergamena veniva raschiata per riusarla e il libro stampato brucia. È vero, ma la differenza quantitativa è tale da diventare qualitativa. La durata media di un libro stampato ben conservato si misura in secoli. La durata media di un file digitale si misura in anni, forse decenni nei casi fortunati. Il delta è di uno o due ordini di grandezza. Una civiltà in cui gli oggetti culturali durano cento volte meno rispetto alla precedente è una civiltà strutturalmente diversa, non solo quantitativamente ma qualitativamente. Ha un altro rapporto con il tempo. Produce un'altra soggettività in chi la abita. Uno sviluppatore sa, in un modo che un tipografo del Cinquecento non sapeva, che il suo lavoro non lo sopravvivrà. ## L'obiezione dell'effimero {: #lobiezione-delleffimero } C'è un modo di leggere tutto questo che è meno tragico, e vale la pena attraversarlo prima di chiudere. L'obiezione possibile è che la permanenza non sia necessariamente una virtù, e che il software potrebbe rappresentare una forma di produzione culturale deliberatamente effimera, nel senso in cui una performance teatrale o un concerto jazz sono effimeri, e che la loro effimerità non è un difetto ma una caratteristica costitutiva del loro modo di essere al mondo. Una funzione lambda che gira per trentasette millisecondi e poi sparisce non è un oggetto fallito perché non dura: è un oggetto pienamente realizzato perché ha fatto esattamente quello che doveva fare nel tempo giusto. La metafora del monumento, ereditata dall'architettura, potrebbe essere semplicemente inadatta al mezzo, e insistere sul fatto che il software "non invecchia bene" potrebbe essere come lamentarsi del fatto che un temporale non invecchia bene: confondere una categoria che non si applica. L'obiezione è interessante ma si rompe nel momento in cui la si prende sul serio. Il problema non è il codice che gira per trentasette millisecondi. Quello è davvero un evento, non un oggetto. Il problema è che la quasi totalità del software di cui dipendiamo nella vita quotidiana non è un evento in questo senso: è infrastruttura. Il sistema con cui la nostra banca gestisce i conti non è una performance jazz. Il software medicale che controlla il ventilatore in terapia intensiva non è un temporale. Il database anagrafico del comune non è una funzione effimera. Sono oggetti che pretendono di essere infrastruttura, che noi trattiamo come infrastruttura, che le istituzioni iscrivono nei loro processi come se fossero infrastruttura, e che però hanno le proprietà di durata e memoria di una nuvola. Questa discrepanza tra la funzione sociale che il software svolge e le sue proprietà materiali di durata è il punto in cui la questione smette di essere filosofica e diventa civile. Una società che affida le sue funzioni vitali a oggetti che non sanno invecchiare sta, silenziosamente, trasferendo il costo della manutenzione della propria continuità a uno strato tecnico che non sa sostenerla. ## Infrastruttura precaria, diritto che rincorre {: #infrastruttura-precaria-diritto-che-rincorre } Il Cyber Resilience Act europeo, adottato come Regulation (EU) 2024/2847 e in piena applicazione a partire dal dicembre 2027, la nuova Product Liability Directive (EU) 2024/2853, le obbligazioni previste dalla NIS2, sono, visti da questa angolazione, tentativi maldestri ma indicativi di forzare il software a comportarsi come infrastruttura seria. Obbligano i produttori a definire un periodo di supporto che rifletta il ciclo di vita atteso del prodotto, con un minimo di cinque anni nella maggior parte dei casi, a mantenere SBOM aggiornati, a rispondere delle vulnerabilità introdotte nel prodotto anche dopo la vendita. Sono, in un certo senso, il tentativo legislativo di imporre all'oggetto software le proprietà di durata che non ha per natura. Il fatto che queste regole esistano, e che siano percepite dal settore come un costo aggiuntivo invece che come un riconoscimento di responsabilità civile, dice qualcosa sul fatto che chi produce software ha internalizzato l'effimerità come privilegio. Il muratore sa di dover rispondere del suo muro per molti anni. Lo sviluppatore è abituato a rispondere del suo codice fino alla fine della garanzia contrattuale, che tipicamente è di dodici o ventiquattro mesi. Le due figure professionali hanno orizzonti temporali di responsabilità che differiscono di un ordine di grandezza, e questa differenza è invisibile nel linguaggio con cui le descriviamo. ## Un'etica della durata {: #unetica-della-durata } Tornando alla domanda iniziale, al perché il software non sa invecchiare, possiamo adesso dare una risposta meno lapidaria. Non sa invecchiare perché è fatto di un materiale che non ha grana, in un ambiente che si muove più velocemente di lui, dentro una cultura produttiva che ha rinunciato a considerare la durata come una delle dimensioni del valore. Ciascuno di questi tre fattori è causa sufficiente del risultato, e sommati rendono il risultato quasi inevitabile. Il primo è ontologico e probabilmente irrisolvibile: il codice non diventerà mai legno. Il secondo è sistemico e potrebbe essere attenuato, se la cultura tecnica imparasse a trattare la stabilità come un pregio invece che come un segno di arretratezza. Il terzo è puramente culturale ed è l'unico su cui si può davvero agire. Agire come? Probabilmente in direzioni che il settore oggi considera regressive. Rallentando i cicli di rilascio. Preferendo la retrocompatibilità all'eleganza. Scrivendo meno codice e più specifica. Trattando le interfacce stabili come monumenti, cioè come oggetti il cui valore sta nella loro resistenza al cambiamento. Accettando che la maggior parte del codice non debba diventare Unix, e che proprio per questo debba essere scritto con una certa consapevolezza del suo destino di transitorietà, senza l'ambizione falsa della durata e senza la disperazione nichilista della sua assenza. Un mestiere che sa di non costruire cattedrali ma che rifiuta di costruire baracche. Una dignità intermedia, che non abbiamo ancora una parola buona per descrivere, e che è forse una delle cose che questa generazione di tecnici dovrebbe provare a formulare. Se c'è una consolazione nel fatto che il software non invecchia bene, è che questa caratteristica ci obbliga a mettere a fuoco, per contrasto, cosa significhi invecchiare bene in generale. Ci costringe a riconoscere che la patina della sedia di Aalto non è un fatto automatico del legno, ma il risultato di una relazione lunga tra un oggetto ben fatto, un ambiente stabile, un utilizzatore attento e una cultura che sa riconoscere il valore di questa triangolazione. Quando uno di questi termini salta, la patina non si forma. Il legno lasciato sotto la pioggia non acquista patina, marcisce. Il legno tenuto chiuso in un deposito non acquista patina, si secca. La patina è un'opera collettiva che richiede tempo, cura e contesto. Il software, allo stato attuale, non ha nessuno di questi tre, e l'idea stessa che potrebbe averli suona come una fantasticheria nostalgica. Non è una fantasticheria. È una domanda di progettazione. **Cosa vorrebbe dire scrivere codice sapendo che deve durare quanto un muro?** Non lo sappiamo ancora davvero, perché non ci siamo quasi mai provati con serietà, e quando ci abbiamo provato lo abbiamo fatto quasi sempre in ambiti marginali rispetto al mainstream: avionica, controllo industriale, sistemi bancari legacy, dove la durata è imposta dall'esterno come vincolo normativo più che scelta culturale. Il software civile, quello che costruisce la vita pubblica e privata della maggior parte delle persone, è stato costruito con l'assunzione implicita che la durata non sia un problema suo. Questa assunzione sta diventando insostenibile proprio mentre la società delega al software funzioni sempre più vitali. Tra le responsabilità di questa generazione di tecnici, probabilmente quella di cominciare a formulare un'etica della durata per il proprio mestiere è una delle più serie, e una delle meno rinviabili. Rimane, alla fine, la questione di fondo. Il software non invecchia bene. Questa frase, all'inizio, sembrava una lamentela tecnica. Arrivati qui, si capisce che è qualcosa di diverso. È una descrizione esatta del tipo di artefatti che abbiamo deciso, collettivamente, di mettere al centro della nostra vita associata, e una richiesta implicita di fare i conti con quella decisione. Gli oggetti che mettiamo al centro di una civiltà dovrebbero, nei limiti del possibile, sapere accompagnarla nel tempo. Se non lo sanno fare, bisogna o cambiarli, o cambiare il posto che occupano. Finora abbiamo fatto né l'una né l'altra cosa. Abbiamo lasciato che occupassero il centro comportandosi come se fossero alla periferia, e abbiamo chiamato questa condizione "progresso". Vale la pena cominciare a chiamarla con un nome più preciso. --- # L'ultima bottiglia di Mrs. Donoghue - **URL:** https://margiovanni.it/it/blog/lultima-bottiglia-di-mrs-donoghue/ - **Pubblicato:** 2026-04-18 - **Tag:** Compliance, PLD, Diritto Digitale, Filosofia Della Tecnica - **Tempo di lettura:** 33 min > Perché il «prodotto» su cui è costruito il diritto della responsabilità civile non esiste più nel software contemporaneo, e cosa potrebbe mettersi al suo posto. Il 26 agosto del 1928 una donna di Glasgow di nome May Donoghue entrò con un'amica in un café di Paisley, una cittadina a circa sette miglia dal centro della città. L'amica ordinò e pagò per lei un *Scotsman ice cream float*, un gelato servito con gassosa allo zenzero. La bevanda fu servita dal proprietario del Wellmeadow Café in una bottiglia opaca di vetro scuro, del tipo che all'epoca era diffuso proprio perché il vetro torbido impediva di vedere eventuali sedimenti nel contenuto. Quando la seconda metà del liquido fu versata nel bicchiere insieme al gelato sciolto, dalla bottiglia uscì, trascinata dalla gassosa, una lumaca in avanzato stato di decomposizione. May Donoghue si ammalò di gastroenterite severa, fu visitata da un medico il 29 agosto e venne ricoverata in emergenza al Glasgow Royal Infirmary il 16 settembre. Quattro anni più tardi, nel 1932, la House of Lords emise una sentenza che è considerata la pietra angolare del moderno diritto della responsabilità da prodotto nel mondo di common law. ## La lumaca nella bottiglia {: #la-lumaca-nella-bottiglia } La decisione venne presa a maggioranza di tre voti contro due. L'estensore del voto di maggioranza fu Lord Atkin, che nel passaggio celebre che tutti gli studenti di giurisprudenza continuano a memorizzare ancora oggi formulò il cosiddetto *neighbour principle*, ovvero l'obbligo di ciascuno di prendersi cura del proprio vicino in senso giuridico, dove vicino significava chiunque fosse ragionevolmente prevedibile come destinatario degli effetti della propria condotta. Da quel momento il produttore risponde del proprio prodotto anche nei confronti di chi non ha contrattualmente rapporti con lui, anche se la bottiglia passa attraverso un distributore e un caffè prima di arrivare al consumatore, anche se tra la fabbrica e la gastroenterite di Mrs. Donoghue si interpongono settimane di magazzino e chilometri di strada. Quello che quasi nessuno nota leggendo la sentenza è che il giudice, per poter scrivere il *neighbour principle*, aveva bisogno di un presupposto ontologico preciso, ovvero di una certa idea di cosa fosse l'oggetto di cui si stava parlando. L'oggetto era la bottiglia. Un artefatto *bounded*, dotato di contorni netti, identificabile, esaminabile, conservabile. La bottiglia veniva prodotta in uno stabilimento specifico, a David Stevenson di Paisley, riempita in un momento datato, sigillata con un tappo che ne garantiva l'integrità fino al punto vendita. Se fosse stato necessario, gli avvocati avrebbero potuto chiedere di esaminare il lotto di produzione, di analizzare la composizione del vetro, di verificare la catena di approvvigionamento degli zuccheri e degli aromi. La causa materiale, nel senso aristotelico, era raggiungibile. La causa efficiente, cioè il processo produttivo, era documentata. La causa formale, ossia la forma tipica di una bottiglia di gassosa, era nota a chiunque. Tutto il diritto moderno della responsabilità da prodotto che si è costruito sopra Donoghue v. Stevenson presuppone questa cosa semplicissima e al tempo stesso cruciale: presuppone che si possa puntare il dito verso un oggetto e dire «questo», e che il dito che punta trovi sempre qualcosa al suo capo terminale. ## La nuova PLD e il problema di una categoria {: #la-nuova-pld-e-il-problema-di-una-categoria } Nel 1985 l'Europa, con la Direttiva 85/374/CEE, ha recepito in forma continentale il principio di Donoghue, estendendolo e sistematizzandolo. La *Product Liability Directive* parla di «prodotti difettosi» e stabilisce una responsabilità oggettiva del produttore, indipendente dalla colpa, per i danni causati dal prodotto. Quarant'anni dopo, il 23 ottobre 2024, è stata adottata la Direttiva 2024/2853, entrata in vigore il 9 dicembre 2024 e da recepire negli ordinamenti nazionali entro il 9 dicembre 2026, data a partire dalla quale la vecchia direttiva del 1985 viene abrogata. La nuova PLD è stata pensata espressamente per il software, e include nella definizione di prodotto i file digitali, i componenti software, le applicazioni, i sistemi di intelligenza artificiale. È una delle più ambiziose riforme del diritto della responsabilità civile mai tentate dall'Unione Europea. Il fatto che abbia richiesto quarant'anni per essere ripensata, e che nonostante lo sforzo enorme dei suoi estensori rischi di essere già inadeguata il giorno in cui entrerà in vigore, non è colpa di nessuno in particolare. È la conseguenza di un problema che il diritto non ha ancora saputo nominare con precisione. Il problema è che il «prodotto» su cui Lord Atkin e i suoi successori hanno costruito due secoli di giurisprudenza, nel software contemporaneo non c'è più. Vale la pena prendersi un minuto per capire dove è andato a finire, perché la diagnosi è il punto di partenza di tutto ciò che segue. ## Dal disco al concerto {: #dal-disco-al-concerto } Per molto tempo il software è stato un prodotto nel senso pieno e convenzionale del termine. Si è usciti dal laboratorio dei Bell Labs e si è entrati nella distribuzione di massa con Unix e poi con i sistemi operativi per personal computer. Un applicativo degli anni Ottanta o Novanta era un insieme di file distribuito su floppy, poi su CD, poi su DVD, con un numero di versione, un hash identificativo, una copia conservabile in cassaforte. Se il software presentava un difetto, si poteva, almeno in teoria, isolare la versione esatta del binario, confrontarla con quella presunta corretta, identificare il bug. Windows 95 era un prodotto. Microsoft Word 97 era un prodotto. Persino un gioco come Baldur's Gate era un prodotto, con le sue patch numerate e conservabili. Certo, anche allora il software dipendeva da cose che non erano il prodotto in senso stretto — dai driver di periferica, dal firmware, dai protocolli di rete, dai servizi di sistema. Ma quelle dipendenze erano statiche, dichiarate, limitate nel numero, e soprattutto erano mediate da un artefatto autosufficiente che poteva essere conservato e riprodotto anche molti anni dopo. La copia del CD di Windows 95 che un archivista digitale conserva oggi è ancora identica a quella del 1995, bit per bit. Il prodotto, come oggetto dotato di continuità nel tempo, esisteva. Nei primi anni Duemila qualcosa comincia a cambiare, e la velocità del cambiamento accelera in modo drammatico nel decennio successivo. La transizione al *software as a service* sposta l'applicazione dal disco locale del cliente al server del fornitore. All'inizio è una semplice questione di distribuzione, ma molto presto diventa una trasformazione ontologica. Quando l'applicazione gira su un server remoto, la versione dell'applicazione che l'utente usa in un dato momento non è più una proprietà stabile, è una proprietà momentanea, rinegoziabile dal fornitore in qualsiasi istante senza neanche avvisare. Il *continuous deployment* porta questa fluidità al suo esito naturale, con aziende che pubblicano in produzione decine o centinaia di cambiamenti al giorno, senza che nessuno, neanche internamente, sia in grado di ricostruire con esattezza quale fosse la configurazione esatta del sistema alle quattordici e ventitré di un martedì di tre mesi fa. Nel frattempo, e parallelamente, la composizione interna del software cambia natura. Dall'inizio degli anni Dieci, grazie agli ecosistemi come npm per JavaScript o Maven per Java o PyPI per Python, scrivere un'applicazione significa importare centinaia o migliaia di pacchetti di terze parti, ciascuno a sua volta composto da pacchetti di terze parti, in un grafo di dipendenze transitive che nessun essere umano legge interamente e che si aggiorna continuamente in modo asincrono rispetto al codice che si è scritto. Il caso di *left-pad* del 2016, quando un singolo sviluppatore cancellò dalla npm un pacchetto di undici righe di codice e rompendolo mandò in crash buona parte delle pipeline di *build* e dei processi di installazione del mondo JavaScript, fu il momento in cui l'industria si accorse, per un istante, di quanto fragile e distribuita fosse diventata la cosa che continuava a chiamare prodotto. L'ultima accelerazione, quella che stiamo vivendo in questi mesi, è l'ingresso dei modelli linguistici nella catena produttiva del software. Qui il salto non è solo quantitativo ma categoriale, perché ciò che entra nel prodotto non è più un insieme di istruzioni deterministiche ma un componente probabilistico i cui output non sono riproducibili esattamente neanche dagli stessi input, e il cui peso, una volta scartato dal fornitore per passare al modello successivo, potrebbe non essere più accessibile. Un'applicazione che gira oggi e usa le API di un modello *frontier* è un'applicazione il cui comportamento osservabile dipende da un componente che domani potrebbe comportarsi diversamente, che fra due anni potrebbe non esistere più in nessuna forma recuperabile, e il cui funzionamento interno non è ispezionabile da nessuno, neanche da chi lo ha addestrato. Chi lavora alla scrittura di software oggi sa perfettamente che se un utente di cinque anni fa ci chiedesse di riprodurre esattamente il bug che aveva visto allora, la risposta onesta sarebbe che non possiamo, perché il sistema che ha prodotto quel bug non esiste più in nessuna configurazione *restorable*. Le dipendenze sono state aggiornate, le API esterne hanno cambiato contratto, il database è stato migrato, il modello di AI è stato sostituito. Abbiamo i log. Abbiamo il codice della nostra applicazione. Ma l'evento che ha prodotto il bug era un concerto, e dei concerti restano le registrazioni, non i concerti. Questa è la metafora che credo renda meglio il salto ontologico in corso. Il software contemporaneo non è più un disco, è un concerto. Il disco è un artefatto stabile, conservabile, confrontabile, un oggetto con una sua identità nel tempo. Il concerto è un evento distribuito nello spazio e nel tempo, co-prodotto da molte agencies in tempo reale, irripetibile, del quale si possono avere tracce ma non originali. Quando riascoltiamo la registrazione di un concerto di Keith Jarrett del 1975 stiamo ascoltando un artefatto derivato, non stiamo ascoltando il concerto, che è avvenuto una volta sola ed è finito. Lo stesso vale per un'applicazione SaaS oggi. Quello che l'utente ha vissuto ieri alle undici del mattino è un evento co-prodotto dall'applicazione, dal browser dell'utente, dalla latenza della rete, dalla versione corrente del modello LLM sottostante, dalla configurazione di dodici API di terze parti, da un *rate limit* che nel momento esatto aveva un certo valore. Quell'evento non è riproducibile, non è conservabile, non è ontologicamente un oggetto. È, appunto, un concerto. ## L'obiezione e la copia che non c'è più {: #lobiezione-e-la-copia-che-non-ce-piu } Qualcuno, a questo punto, potrebbe obiettare che la distinzione è esagerata, che in fondo anche nel 1998 il software girava su un sistema operativo che dipendeva da driver e da hardware, che la contingenza runtime esisteva anche allora, che ogni uso di un'applicazione è sempre stato in qualche misura un evento e non un oggetto. L'obiezione è parzialmente corretta, e prenderla sul serio è importante, perché è l'unica via per evitare di trasformare la diagnosi in nostalgia. La differenza che cambia tutto, però, è una e sola, ed è la differenza che il diritto non ha ancora metabolizzato. Nel 1998 esisteva sempre una copia dell'artefatto. Nel senso più stretto e concreto del termine, nella cassaforte del fornitore o nelle *hard disk* dell'utente o nell'archivio di un archivista digitale, c'era un oggetto materiale che conteneva il software nella sua forma autonoma. Quella copia era il punto di contatto tra il prodotto giuridico e l'evento esecutivo. Era il punto archimedeo che rendeva possibile tornare indietro, esaminare, confrontare, giudicare. Era ciò che permetteva al giurista di dire «questo prodotto era difettoso» perché un prodotto c'era. Oggi quella copia non esiste più, e non esiste non per negligenza o per scelta cattiva, ma per costruzione. L'applicazione SaaS del fornitore X, alle quattordici e ventitré di un martedì di tre mesi fa, non esiste in nessun backup, in nessuna cassaforte, in nessun archivio. Esiste soltanto la possibilità di ricostruire, in modo approssimato e parziale, cosa dovesse essere stata, incrociando log, versioni del codice, configurazioni delle dipendenze, pesi dei modelli, stato del database. È una ricostruzione archeologica, non un accesso all'oggetto. E quando anche questa ricostruzione fosse portata a termine, il risultato sarebbe un'altra cosa ancora, un modello dell'applicazione di quel momento, non l'applicazione di quel momento. Il prodotto, nel senso bicentenario del termine giuridico, è scomparso. Ciò che esiste al suo posto non è mai stato nominato. ## Il corpus europeo e il suo disallineamento {: #il-corpus-europeo-e-il-suo-disallineamento } Il legislatore europeo, bisogna riconoscerglielo, si è accorto che qualcosa non tornava. Negli ultimi anni ha prodotto un pacchetto impressionante di norme che cercano di afferrare il nuovo oggetto con gli strumenti a disposizione. Il Cyber Resilience Act, entrato in vigore nel dicembre 2024 con applicazione piena nel dicembre 2027, introduce il concetto di *security by design* e *security by default* per i prodotti con elementi digitali, impone obblighi di supporto lungo tutto il ciclo di vita, richiede la fornitura di un *Software Bill of Materials*. La nuova Product Liability Directive, quella del 2024 che abbiamo citato all'inizio, estende esplicitamente la responsabilità ai difetti di cybersecurity e ai malfunzionamenti degli aggiornamenti software. L'Artificial Intelligence Act, in vigore dal 1° agosto 2024 con applicazione generale dal 2 agosto 2026 e alcune *provisions* che slittano al 2 agosto 2027, classifica i sistemi di AI per rischio e impone obblighi di documentazione, trasparenza, valutazione di conformità. A questi si aggiungono la NIS2 per la sicurezza delle reti, la DORA per il settore finanziario, il Data Act, l'European Accessibility Act. Messi insieme, formano il corpus normativo più ambizioso mai costruito per disciplinare la produzione di software, e sono uno sforzo serio, tecnicamente informato, culturalmente importante. L'errore sarebbe banalizzarli come burocrazia o come freno all'innovazione, come fa una certa vulgata *libertarian* di matrice californiana. La tesi di questo saggio è invece che, pur essendo seri e pur essendo importanti, questi strumenti stanno cercando di catturare il concerto con le categorie del disco, e il disallineamento categoriale è destinato a generare conseguenze che cominciamo solo ora a intravedere. Il caso del Software Bill of Materials è paradigmatico di questa difficoltà, ed è anche quello che conosco meglio per ragioni professionali. L'SBOM è un documento che elenca tutti i componenti che entrano in un software, le loro versioni, le loro dipendenze, le loro licenze. Sulla carta è uno strumento perfettamente sensato, l'equivalente software della lista degli ingredienti che troviamo sulle confezioni alimentari. Nella pratica, l'SBOM è una fotografia di un concerto, con tutti i limiti epistemici che questa condizione porta con sé. Una fotografia del concerto non è il concerto, è già un altro oggetto, derivato, parziale, datato. Nel momento esatto in cui la fotografia viene scattata, il concerto sta già cambiando, e nel decimo di secondo successivo allo scatto le dipendenze transitive potrebbero già essersi aggiornate, la versione dell'API esterna potrebbe essere cambiata, il peso del modello potrebbe essere stato sostituito dal fornitore. L'SBOM cattura uno stato, ma il software contemporaneo non ha stati stabili, ha soltanto flussi. La normativa chiede quindi agli sviluppatori di mantenere la fotografia aggiornata, il che genera processi di *continuous SBOM generation*, con tool che producono l'SBOM a ogni *build*, a ogni *deploy*, idealmente in tempo reale. Il risultato, paradossalmente, è che il documento che doveva catturare l'identità del prodotto si moltiplica in migliaia di *snapshot* giornalieri, ciascuno dei quali è già obsoleto nel momento in cui viene generato. L'SBOM non cattura il prodotto, perché il prodotto non c'è. L'SBOM cattura il flusso, in forma di fotogrammi discreti, e ogni fotogramma è un documento giuridicamente rilevante. Il carico documentale che ne deriva è enorme, e il suo valore probatorio, quando si tratta di ricostruire chi era responsabile di cosa in un momento preciso, è molto meno netto di quanto i legislatori abbiano assunto. Lo stesso problema, aggravato dalla natura stocastica dei modelli, si pone per l'AI Act. L'articolo 10 chiede che i *dataset* di addestramento siano documentati, tracciabili, governati secondo criteri di qualità. L'articolo 15 chiede che i sistemi di AI ad alto rischio siano accurati, robusti, cibersicuri. L'articolo 72 richiede il monitoraggio *post-market*. Ciascuno di questi obblighi ha senso, preso isolatamente, e rinvia a pratiche che la migliore ingegneria del *machine learning* dovrebbe già adottare. Quello che i legislatori non hanno pienamente assorbito è che il modello di linguaggio che un fornitore offre oggi tramite API è un oggetto la cui identità nel tempo è, nel migliore dei casi, convenzionale. Il peso del modello viene aggiornato, il sistema di RLHF raffinato, i *guardrail* modificati, e quello che continua a chiamarsi GPT-4 oppure Claude Opus o Gemini Ultra è, dal punto di vista del comportamento osservabile, un oggetto diverso da ciò che portava lo stesso nome sei mesi fa. Chiedere la documentazione del *training* significa chiedere la documentazione di qualcosa che, nel momento in cui la documentazione viene prodotta, potrebbe essere già stato superato da un altro *training*. Il monitoraggio *post-market* è un'ottima pratica, ma presuppone un mercato in cui il prodotto sia lo stesso al momento della vendita e al momento dell'uso, il che per i modelli linguistici non è quasi mai vero. Non si tratta di dire che l'AI Act è sbagliato, perché l'AI Act è una delle risposte regolamentari più articolate mai tentate su scala comparabile. Si tratta di dire che l'AI Act eredita dal diritto della responsabilità da prodotto una serie di presupposti ontologici che l'oggetto che cerca di regolare non soddisfa, e che la tensione tra i presupposti e l'oggetto si scaricherà nei prossimi anni sulle spalle dei *practitioner*, sotto forma di adempimenti che avranno un valore ambiguo, documenti il cui rapporto con la realtà sarà difficile da stabilire, controversie in cui il contenzioso tra le parti si ridurrà a una disputa sul fatto se un certo *snapshot* fosse rappresentativo del sistema nel momento del danno. ## CrowdStrike, 19 luglio 2024 {: #crowdstrike-19-luglio-2024 } Un esempio recente, di portata tale da essere entrato nei corsi di *risk management* di tutto il mondo, aiuta a vedere in concreto cosa significhi tutto questo. Il 19 luglio del 2024, un aggiornamento difettoso del sensore Falcon di CrowdStrike causò il crash simultaneo di circa otto milioni e mezzo di macchine Windows in tutto il pianeta, con un *boot loop* che richiedeva intervento manuale su ogni singolo dispositivo per essere risolto. Aeroporti fermi, ospedali che riconvertirono le operazioni in regime cartaceo, banche non operative, emittenti televisive bloccate, chiamate di emergenza non instradate. Delta Airlines da sola dichiarò oltre cinquecento milioni di dollari di danno diretto, le sole aziende Fortune 500 dichiararono perdite non assicurate nell'ordine dei cinque miliardi e mezzo, con stime globali che varie fonti collocano nell'ordine delle decine di miliardi. Nel contenzioso seguito, che è tuttora aperto in varie giurisdizioni, l'intera questione si è concentrata sulla domanda seguente. Chi era responsabile. - **CrowdStrike**, che aveva distribuito un aggiornamento contenente un difetto che sarebbe stato rilevato da qualunque test accurato. - **Microsoft**, che aveva consentito a un software di terza parte di operare con privilegi *kernel* tali da poter mandare in *boot loop* il sistema operativo. - **Le organizzazioni deployer**, che avevano accettato aggiornamenti in *push* automatico senza fasi di *canary*. - **Gli enti di regolamentazione europei**, secondo la difesa di Microsoft, che anni prima avevano imposto al vendor l'apertura del *kernel* per ragioni di concorrenza. Ciascuna di queste quattro attribuzioni di responsabilità, presa singolarmente, coglie un aspetto reale della vicenda. Nessuna, presa singolarmente, racconta l'accaduto. L'accaduto fu un fallimento dell'orchestrazione, un evento in cui molti attori avevano, ciascuno nel proprio grado, un'influenza effettiva sul comportamento *runtime* del sistema, e in cui nessuno aveva esercitato quell'influenza in modo proporzionato alle conseguenze possibili. Il diritto attuale non ha strumenti adeguati per distribuire la responsabilità in questo modo, e il contenzioso sta di conseguenza scivolando verso scenari in cui vince chi ha gli avvocati migliori o chi occupa la posizione contrattuale più difendibile, il che è un altro modo per dire che il diritto ha rinunciato a dire qualcosa di sostantivo sull'incidente. Un caso come CrowdStrike, letto alla luce della categoria di assemblaggio responsabile che sto cercando di tratteggiare, avrebbe dovuto produrre una sentenza che distribuisse la responsabilità in quote identificabili tra i diversi attori in funzione del loro *blast radius* e del loro grado di controllo effettivo, e che creasse un precedente utilizzabile per gli incidenti futuri, che saranno certamente molti. Nulla di tutto questo sta accadendo, perché la categoria per farlo non c'è. ## Latour, Ricœur e la pluralità dell'azione {: #latour-ricoeur-e-la-pluralita-dellazione } Vale la pena, prima di andare oltre, chiarire che l'assemblaggio responsabile non è un'invenzione *ex nihilo*, ma l'adattamento al dominio giuridico di riflessioni che la filosofia del Novecento ha sviluppato in altri ambiti e che non hanno ancora fatto abbastanza strada nelle aule di tribunale. Bruno Latour, con la *actor-network theory*, aveva già mostrato negli anni Ottanta che le azioni complesse non hanno mai un unico agente, ma emergono da reti di attori umani e non umani la cui analisi richiede di sospendere l'ossessione per il soggetto individuale e di seguire le connessioni effettive. Il suo esempio canonico del dosso artificiale, il cosiddetto *sleeping policeman* posto sul manto stradale, è illuminante, perché mostra come il dosso *enforci* il limite di velocità indipendentemente dalla presenza del poliziotto umano, agendo come attore non umano dotato di propria *agency*. Il rallentamento dell'auto è co-prodotto dal guidatore, dal dosso, dal codice stradale, dalla paura di danneggiare la sospensione, dalla cultura condivisa che riconosce il dosso come segnale di cautela. Nessuno di questi attori, preso da solo, spiega il rallentare, e nessuno dei cinque, preso da solo, è pienamente responsabile di ciò che accade quando qualcosa va storto. Il diritto positivo tende a ritagliare la responsabilità sul guidatore per ragioni pratiche, ma la comprensione filosofica dell'evento richiede di vedere tutti e cinque insieme. Il passo che il diritto non ha ancora fatto, e che la filosofia ha fatto da quarant'anni, è accettare che questa distribuzione dell'agenzia sia la norma e non l'eccezione, e derivarne le conseguenze per l'attribuzione della responsabilità. Paul Ricœur, in *Soi-même comme un autre* del 1990 e nella riflessione sull'imputabilità che ne è derivata, aveva aggiunto un tassello complementare, mostrando che l'atto di imputare una responsabilità è un atto narrativo, che richiede di ricostruire una storia plausibile di causazione, e che quando la storia plausibile coinvolge molti agenti la narrazione imputativa non può ridursi a un unico soggetto senza tradire la verità dell'evento. L'imputazione, per Ricœur, è un'ermeneutica della responsabilità, e come ogni ermeneutica richiede pazienza, ascolto dei diversi livelli, rifiuto delle semplificazioni. Il diritto contemporaneo della responsabilità da prodotto semplifica troppo, e lo fa perché ha ereditato una grammatica narrativa ottocentesca in cui il produttore era uno, identificabile, imputabile. Ricostruire l'imputabilità per il software contemporaneo significa accettare la natura plurale dell'azione e restituirla anche nel testo della sentenza. ## L'assemblaggio responsabile {: #lassemblaggio-responsabile } Se ci si ferma qui, la diagnosi rischia di apparire pessimistica o puramente critica, nello stile di una certa letteratura *tech-skeptical* che si compiace delle difficoltà senza proporre nulla di costruttivo. Il punto che vorrei provare a sviluppare è esattamente opposto, perché se è vero che il concetto di prodotto non regge più la sua funzione di attribuzione di responsabilità, diventa necessario iniziare a immaginare quale potrebbe essere la categoria sostitutiva. E questa è un'impresa intellettuale che non si può delegare né ai giuristi puri, che non hanno contatto con il *runtime* dei sistemi reali, né agli ingegneri puri, che tendono a considerare il diritto come un fastidio esterno piuttosto che come un tentativo di attribuire significato morale a ciò che fanno. La categoria sostitutiva deve essere pensata a quattro mani, da chi ha pratica del codice e lettura del diritto, e deve partire dalla constatazione che il software contemporaneo è un'orchestrazione, un assemblaggio, un evento distribuito, non un oggetto. Propongo di chiamarla, provvisoriamente, **assemblaggio responsabile**, consapevole che il nome non è ancora definitivo e che la discussione sul nome è parte integrante della costruzione della cosa. Che cosa sarebbe un assemblaggio responsabile, in prima approssimazione. Sarebbe una configurazione di componenti, umani e non umani, organizzati attorno a una funzione specifica offerta a un utente, di cui nessuno dei partecipanti detiene il controllo integrale ma ciascuno esercita un grado identificabile di influenza effettiva sul comportamento osservabile in *runtime*. La responsabilità, in questa cornice, non segue più la titolarità formale, nello stile «chi è intestatario del contratto risponde di tutto», né segue l'origine storica dei componenti, nello stile «se un bug è nella libreria importata allora la colpa è del manutentore della libreria». La responsabilità segue il gradiente dell'influenza effettiva. Chi ha potuto, nel momento del danno, modificare il comportamento del sistema con un'azione tecnica mirata, risponde proporzionalmente al grado di quella possibilità. Il fornitore del modello di AI che avrebbe potuto aggiornare i *guardrail* e non lo ha fatto risponde di una quota di responsabilità. L'integratore che ha scelto quel modello per una funzione sensibile senza valutare adeguatamente i rischi, pur avendo gli strumenti per farlo, risponde di un'altra quota. L'utente che ha configurato il sistema in modo anomalo, aggirando le avvertenze, risponde di una terza quota. Nessuno dei tre risponde di tutto, nessuno dei tre risponde di niente, ciascuno risponde della propria porzione di orchestrazione. La formula è semplice da enunciare e infernalmente complessa da implementare, come è naturale che sia ogni categoria giuridica nuova nei suoi primi decenni. Le obiezioni si presentano immediate, e vale la pena di scorrerle. La prima obiezione è che l'influenza effettiva è difficile da misurare, e che un sistema giuridico fondato su un concetto così sfuggente sarebbe fonte di incertezza. L'obiezione è vera ma meno grave di quanto sembri, perché già oggi il diritto della responsabilità civile opera con concetti sfuggenti come la colpa, la prevedibilità, la causazione adeguata, e ha sviluppato nel tempo strumenti operativi per trattarli. L'influenza effettiva su un sistema distribuito è misurabile attraverso ciò che gli ingegneri chiamano *blast radius*, ovvero la stima dell'ampiezza delle conseguenze di un'azione tecnica. Un fornitore di API LLM ha un *blast radius* che comprende potenzialmente tutti i suoi integratori, perché una sua modifica si propaga istantaneamente. Un integratore ha un *blast radius* limitato ai propri utenti, che tuttavia può essere amplificato se la sua applicazione è a sua volta infrastruttura di altre applicazioni. Esistono metriche tecniche, grossolane ma trattabili, per stimare il *blast radius* di ciascun attore, e la dottrina giuridica potrebbe costruirci sopra una tassonomia della responsabilità graduata. Non sarebbe più sfuggente di quanto lo fossero le dottrine della colpa aquiliana nell'Ottocento prima che decenni di giurisprudenza le rendessero operative. ## Due deformazioni da resistere {: #due-deformazioni-da-resistere } La seconda obiezione è più politica e viene da due direzioni opposte, entrambe in qualche misura interessate. La prima direzione è quella degli ambienti californiani della grande industria tech, che hanno costruito negli ultimi vent'anni una narrazione secondo cui la natura *open source* e componentizzata del software renderebbe impossibile attribuire responsabilità a qualcuno in particolare, e che dunque la responsabilità andrebbe limitata ai termini contrattuali esplicitamente accettati dalle parti. Secondo questa lettura, se un utente subisce un danno da un'applicazione che usa una libreria *open source* il cui autore è anonimo, e l'applicazione è a sua volta ospitata su un cloud il cui fornitore declina ogni responsabilità nei termini di servizio, allora nessuno risponde di niente, o meglio, risponde solo chi ha deliberatamente assunto la responsabilità firmando un contratto. Questa è la dottrina dell'**irresponsabilità distribuita**, ed è una comoda rendita di posizione per chi occupa i nodi più centrali dell'orchestrazione, perché consente di incamerare il valore e di esternalizzare i rischi. L'assemblaggio responsabile si oppone frontalmente a questa dottrina, perché rifiuta l'idea che l'assenza di un titolare formale equivalga all'assenza di responsabilità sostanziale. Se il tuo modello è il componente critico di migliaia di applicazioni a valle, la tua responsabilità non dipende dal fatto che tu abbia o non abbia firmato un contratto con gli utenti finali di quelle applicazioni. Dipende dal tuo ruolo nell'orchestrazione, e quel ruolo è oggettivamente misurabile. L'altra direzione da cui viene l'obiezione è quella del formalismo europeo continentale, che ha una tradizione opposta ma altrettanto problematica, e che potremmo chiamare la dottrina del **titolare assoluto**. Secondo questa tradizione, il titolare del trattamento del dato, o il fornitore del servizio, o il *deployer* del sistema di AI, risponde di tutto ciò che accade nella catena, a prescindere da dove si sia originata la non conformità o il malfunzionamento. È una dottrina intuitivamente egualitaria, perché tutela l'utente assicurandogli che qualcuno, un'entità giuridica identificabile, risponderà sempre. Nella pratica, però, produce due distorsioni serie. La prima è che scarica sul titolare una responsabilità di cui non ha il controllo tecnico, costringendolo a difendersi da contenziosi per malfunzionamenti originati da componenti che non ha scritto, non ha scelto, non può ispezionare. La seconda distorsione è che de-responsabilizza i nodi a monte della catena, cioè proprio quelli che hanno l'influenza più sistemica, perché sanno che la loro quota di responsabilità sarà scaricata formalmente sul *deployer* finale e che i tribunali continueranno a puntare il dito contro chi si trovava nella posizione più visibile. L'assemblaggio responsabile si oppone anche a questa dottrina, perché la posizione formale del titolare non esaurisce la questione della responsabilità, e una distribuzione solo apparente del carico, che nei fatti si concentra sempre sul nodo più accessibile, mantiene le cose esattamente come sono nei rapporti di forza reali dell'industria. La proposta, quindi, si trova in un territorio scomodo per entrambe le sensibilità prevalenti, e proprio per questo merita di essere articolata con qualche pazienza. Chi lavora nel software sa benissimo che l'idea secondo cui la responsabilità sia un fatto puramente contrattuale è una finzione utile per chi sta nella Silicon Valley e un'esperienza quotidiana di impotenza per chi sta a Pescara o a Milano o a Francoforte e deve consegnare un sistema che funziona davvero in un contesto di vincoli reali. Al tempo stesso, chi lavora con la *compliance* europea sa che la dottrina del titolare assoluto trasforma il *deployer* in un fusibile giuridico, la cui funzione economica è saltare quando il sistema si rompe, consentendo ai componenti a monte di continuare a produrre esternalità. Il software contemporaneo ha bisogno di una categoria che non sia nessuna delle due, e che riesca a distribuire la responsabilità in modo che rifletta la distribuzione effettiva del potere tecnico. Non una distribuzione simmetrica, perché il potere tecnico non è distribuito simmetricamente. Non una concentrazione sul titolare, perché il potere tecnico non è concentrato sul titolare. Una distribuzione che segue il gradiente dell'influenza effettiva, con metriche trasparenti, con una dottrina pratica che i tribunali possano maneggiare, con una *ratio* che i *practitioner* possano riconoscere come aderente alla loro esperienza di lavoro. Ci sono alcuni ambiti in cui qualcosa del genere sta già accadendo, anche se nessuno lo chiama così. Il GDPR, nel suo articolo 28 e nelle linee guida dell'EDPB sulla catena di *sub-processor*, ha iniziato timidamente a riconoscere la gradazione di responsabilità lungo la catena del trattamento, anche se in modo formalistico e senza l'apparato concettuale che sarebbe necessario. Le *Data Protection Impact Assessment*, quando vengono fatte seriamente e non come esercizio di *compliance theatre*, contengono in nuce il germe di un'analisi del *blast radius* applicata al dato personale. La direttiva NIS2, sulla sicurezza delle reti, introduce obblighi per i fornitori di servizi gestiti che riconoscono il loro ruolo sistemico nella catena di sicurezza. La stessa AI Act, con la sua distinzione tra *provider*, *deployer*, *importer*, *distributor*, sta tentando una tassonomia dei ruoli che, pur ancora troppo rigida, va nella direzione di una distribuzione non titolare-centrica della responsabilità. Nessuno di questi strumenti è ancora arrivato al punto di formulare esplicitamente il principio dell'influenza effettiva come gradiente di responsabilità, ma tutti contengono tracce di un ripensamento che aspetta soltanto una sistematizzazione dottrinale. L'impressione è che manchi qualcosa di simile a ciò che fu per Lord Atkin il *neighbour principle*, ovvero una formulazione sintetica, memorabile, operativa, che consenta di orientare cinquant'anni di giurisprudenza successiva. Chi scriverà quella formulazione avrà fatto per il ventunesimo secolo ciò che la House of Lords fece per il ventesimo. Il punto è che, perché quella formulazione possa essere scritta, servirà una categoria di intellettuali che oggi praticamente non esiste. Non servono giuristi puri, perché la grammatica interna dei sistemi distribuiti contemporanei non si apprende nei corsi di diritto. Non servono ingegneri puri, perché la grammatica del diritto e la sua storia bicentenaria di categorie e controcategorie non si apprende nei corsi di *computer science*. Servono ibridi, figure di confine che abbiano praticato entrambi i mestieri abbastanza a lungo da averne capito le logiche interne e i limiti, e che siano disposte a immaginare qualcosa che nessuno dei due corpus disciplinari, preso da solo, è in grado di immaginare. In Italia questa figura non ha ancora un nome consolidato. Nei paesi anglosassoni si è affermato negli ultimi anni il ruolo del *compliance engineer* o del *technical counsel*, ma sono ancora definizioni professionali che si limitano a mettere in comunicazione le due culture senza davvero costruire una terza. Quello che serve è qualcosa di più ambizioso, una figura che non traduca soltanto il gergo tecnico in gergo giuridico e viceversa, ma che elabori categorie nuove capaci di dire cose che nessuno dei due gerghi originari, lasciato a se stesso, saprebbe dire. Il mestiere è in parte teorico, perché richiede una formazione filosofica che permetta di maneggiare categorie astratte, e in parte pratico, perché richiede l'esperienza quotidiana del *deployment*, della dipendenza transitiva, della retrocompatibilità rotta da un *minor release* del fornitore, dello *stack trace* ambiguo che non dice di chi sia la colpa. Senza l'esperienza pratica, le categorie astratte restano sospese nel vuoto. Senza la formazione astratta, l'esperienza pratica si esaurisce in stanchezza e in *ticket* chiusi. La terza via è difficile, non perché richieda doti rare, ma perché il mercato del lavoro non la prezza, le università non la formano, le aziende non la organizzano. Esiste soltanto per volontà individuale, ed è proprio per questo che chi la pratica ha una responsabilità intellettuale sproporzionata rispetto alla sua posizione formale. ## Dal Bill of Materials al Bill of Accountability {: #dal-bill-of-materials-al-bill-of-accountability } A questo punto è utile tornare al problema concreto da cui siamo partiti, cioè alla domanda di come si possa attribuire responsabilità per un danno causato da un software contemporaneo. Se accettiamo che il software non è più un prodotto ma un assemblaggio, e che l'assemblaggio va analizzato secondo il gradiente dell'influenza effettiva, allora il primo passo operativo è costruire una pratica di documentazione dell'assemblaggio che non sia la fotografia statica dell'SBOM ma una mappa dinamica delle relazioni di influenza. Uno strumento del genere dovrebbe permettere di rispondere, per ogni applicazione, a domande come queste. - Quali componenti, se modificati, cambierebbero il comportamento osservabile del sistema. - Quali attori hanno la capacità tecnica di modificare quei componenti. - Quali sono gli obblighi contrattuali e normativi che gravano su ciascuno di quegli attori. - Quali sono le evidenze, nei log e nei sistemi di *audit*, che permettono di ricostruire *ex post* lo stato del sistema in un momento specifico. - Quali sono i canali di comunicazione attraverso cui un attore a valle può far arrivare un segnale di allarme a un attore a monte. - Quali sono i tempi di risposta tipici lungo la catena. Il documento risultante non sarebbe più un *bill of materials*, ma qualcosa di più simile a un ***bill of accountability***, una mappa dei poteri e dei doveri lungo l'intera orchestrazione. Produrlo richiederebbe lavoro, richiederebbe cooperazione tra attori che non sempre hanno interesse a cooperare, richiederebbe norme che ne imponessero la produzione. Ma sarebbe uno strumento che nominerebbe il problema per ciò che è, invece di cercare di ridurlo a un problema di inventario. ## Tre conseguenze per chi sviluppa software {: #tre-conseguenze-per-chi-sviluppa-software } Dal punto di vista della pratica quotidiana di chi sviluppa software per committenti, questa riarticolazione avrebbe conseguenze importanti. La **prima conseguenza** è che il contratto tipo, quello che oggi tende a scaricare tutta la responsabilità sul fornitore finale o, nei casi migliori, a limitarla al canone annuale pagato, diventerebbe un documento con una struttura completamente diversa. Il contratto andrebbe costruito a valle di un'analisi dell'orchestrazione, con una chiara articolazione di quali componenti il fornitore controlla e di quali soltanto integra, di quali rischi si assume pienamente e di quali si fa canale di trasferimento verso i fornitori a monte, di quali obblighi informativi accetta di onorare e di quali non è tecnicamente in grado di onorare. Sarebbe un contratto più lungo, più complesso, più onesto, e a lungo andare anche più difendibile in sede giudiziaria, perché racconterebbe la cosa per quello che è invece di fingerne una forma che non ha. La **seconda conseguenza** è che il processo di sviluppo dovrebbe includere, fin dalle fasi iniziali, una riflessione sull'orchestrazione in cui il sistema si inserirà, non soltanto una riflessione sui requisiti funzionali. - Chi sono gli attori a monte di cui dipenderemo. - Che garanzie ci danno. - Che *blast radius* hanno nei nostri confronti. - Come verificheremo i loro cambiamenti. - Come reagiremo se un loro cambiamento rompe il nostro comportamento atteso. Queste domande, oggi, sono relegate a qualche slide in fase di architettura e poi dimenticate. In una cultura che prendesse sul serio l'assemblaggio responsabile, sarebbero parte integrante della specifica, e la loro assenza in una documentazione di progetto sarebbe un indicatore di immaturità come lo è oggi l'assenza di una *threat model*. La **terza conseguenza** è forse la più interessante dal punto di vista culturale, e tocca direttamente il modo in cui si formano gli sviluppatori. Oggi si impara a scrivere codice che funziona, poi si impara, se si è fortunati, a scrivere codice che funziona in produzione. Quasi nessuno impara a scrivere codice che funziona all'interno di un'orchestrazione di cui è consapevole. La consapevolezza dell'orchestrazione arriva tardi, spesso per via di un incidente, raramente come competenza esplicitata e insegnata. Una formazione che prendesse sul serio la natura distribuita del software contemporaneo dovrebbe partire da qui, dovrebbe mostrare fin dal primo giorno che scrivere un'API significa entrare in un'orchestrazione, che scegliere una libreria significa accettare un fornitore a monte, che *deployare* in cloud significa ospitarsi in un'infrastruttura le cui decisioni architetturali sono altrove. Non si tratta di terrorizzare i giovani sviluppatori, ma di abituarli a vedere ciò che vedono gli sviluppatori esperti dopo vent'anni di cicatrici. L'orchestrazione è l'oggetto del loro lavoro, non uno sfondo. Il codice che scrivono è una partecipazione a un concerto, non un oggetto autosufficiente. Se crescono con questa consapevolezza, la questione della responsabilità non arriverà come un fastidio esterno, arriverà come una dimensione intrinseca del mestiere. ## Quando anche la scrittura è orchestrazione {: #quando-anche-la-scrittura-e-orchestrazione } A chi sospetta che tutto questo sia esagerato dalla lente del *software as a service* e che nei contesti più semplici la categoria di prodotto possa ancora reggere, conviene rispondere che la direzione in cui si sta muovendo lo sviluppo AI-nativo rende il problema più acuto e non meno. Quando si lavora con strumenti come Claude Code o con pratiche come la *specification-driven development* alla SpecKit, il codice cessa di essere l'oggetto che lo sviluppatore scrive direttamente e diventa l'*output* di una catena di generazione che parte dalla specifica, passa per un modello, produce un artefatto e lo integra in un'orchestrazione già di per sé distribuita. La specifica scritta ieri e il codice generato ieri, se rigenerati oggi dallo stesso modello, produrrebbero un codice plausibilmente simile ma non identico, perché il modello nel frattempo è cambiato. Il concetto di versione, già indebolito dal *continuous deployment*, diventa in questo contesto ancora più instabile, perché ora non è più instabile soltanto nel tempo di esecuzione ma anche nel tempo di scrittura. Chi sviluppa in questo modo sa che la riproducibilità esatta è un orizzonte regolativo, non una proprietà effettiva dei suoi artefatti. L'assemblaggio responsabile, in un mondo in cui anche la scrittura del codice è un'orchestrazione tra sviluppatore, specifica, modello, *toolchain* e *pipeline*, diventa la categoria naturale per pensare la responsabilità, perché è l'unica in cui l'assenza di un autore monolitico non si traduce automaticamente nell'assenza di imputabilità. ## La morte di una categoria {: #la-morte-di-una-categoria } Resta una domanda a cui il saggio deve rispondere, perché è la domanda che un lettore paziente avrà tenuto in sospeso fin dall'inizio. La domanda è se davvero abbia senso parlare della morte di una categoria giuridica, o se non stiamo soltanto descrivendo un'evoluzione, una trasformazione, un aggiornamento. Il linguaggio della morte è forte, e potrebbe sembrare esagerato. La giustificazione che offro è che una categoria giuridica muore nel senso in cui lo aveva detto Foucault parlando di categorie più generali, ovvero quando smette di organizzare il campo discorsivo in modo produttivo e comincia a ostacolarlo. Il concetto di prodotto, applicato al software contemporaneo, non organizza più il campo, lo ostacola. Produce adempimenti che non corrispondono a pratiche, documenti che non rappresentano oggetti, contenziosi che si incagliano sulla definizione dell'oggetto prima di potersi occupare della sostanza. Un concetto che ostacola il campo non è un concetto utile, anche se continua a essere formalmente in vigore. Il concetto di etere luminifero, nella fisica di fine Ottocento, non era sbagliato nel senso in cui possono esserlo le affermazioni singolari, era un concetto che aveva smesso di organizzare produttivamente il campo e si era messo a ostacolarlo, finché Einstein non lo ha semplicemente rimosso. Il concetto di prodotto, nel diritto contemporaneo del software, si trova in una fase comparabile. È ancora lì, è ancora nei testi normativi, è ancora nelle aule giudiziarie. Ma non lavora più. E fingere che lavori è più pericoloso che ammettere che non lo fa. Non sto dicendo, sia chiaro, che il legislatore europeo avrebbe dovuto aspettare di avere la categoria giusta prima di intervenire. La posizione sarebbe stata intellettualmente pura e politicamente impresentabile, e comunque il danno prodotto dall'assenza di regolamentazione sarebbe stato maggiore del danno prodotto da una regolamentazione categorialmente imperfetta. Sto dicendo, più modestamente, che la regolamentazione attuale è un *work in progress*, che la sua imperfezione categoriale va riconosciuta apertamente, e che la costruzione della categoria sostitutiva è un compito che non compete solo ai legislatori ma anche a chi nel software lavora quotidianamente e a chi sulla filosofia del diritto ha gli strumenti per pensare. Chi ha entrambi i piedi dentro può contribuire più di chi ne ha uno solo. E il contributo non è un esercizio accademico, perché ogni anno che passa senza che la categoria sostitutiva emerga è un anno in cui il contenzioso si risolve per vie formali che non rispecchiano le responsabilità sostanziali, è un anno in cui i fornitori a monte continuano a trasferire rischio senza pagarne il prezzo, è un anno in cui i *deployer* finali continuano a fare da fusibili senza che il sistema nel suo insieme migliori. ## La stanza di Lord Atkin {: #la-stanza-di-lord-atkin } Mi sono dilungato, e chi mi ha seguito fin qui merita almeno una sintesi onesta di dove siamo arrivati. Siamo arrivati a dire che il concetto giuridico di prodotto, costruito nel Novecento su un'ontologia di oggetti *bounded*, preservabili, identificabili, è insufficiente per il software contemporaneo, che è invece un'orchestrazione di componenti umani e non umani, un evento distribuito più che un oggetto, un concerto più che un disco. Siamo arrivati a dire che la regolamentazione europea, pur essendo lo sforzo più serio mai tentato, sta cercando di catturare il concerto con le categorie del disco e che questa tensione produce adempimenti il cui valore giuridico sostanziale è ambiguo. Siamo arrivati a dire che, al posto della categoria di prodotto, serve costruirne una nuova, provvisoriamente chiamabile **assemblaggio responsabile**, che distribuisca la responsabilità secondo il gradiente dell'influenza effettiva in *runtime* e non secondo la titolarità formale né secondo l'irresponsabilità distribuita. Siamo arrivati a dire che questa costruzione richiede una figura intellettuale ibrida, con pratica del codice e lettura del diritto, che il mercato non prezza e che esiste soltanto per volontà individuale di chi la pratica. E siamo arrivati a dire che, finché la categoria sostitutiva non emerge, i contenziosi continueranno a scaricarsi per vie formali che non rispecchiano le responsabilità sostanziali, con costi reali per chi fa il mestiere onestamente. Il punto che forse vale la pena fissare, alla fine di tutto questo, è che **Lord Atkin nel 1932 non era un giurista puro, era un giudice che aveva visto molte bottiglie rompersi e molte persone ammalarsi, e aveva capito qualcosa di pratico sul mondo industriale che lo strumentario concettuale precedente non riusciva a dire.** La sentenza *Donoghue v. Stevenson* fu possibile perché qualcuno aveva tenuto insieme, in una sola testa, l'esperienza materiale del mondo industriale e la tradizione concettuale del diritto civile. Oggi c'è bisogno di tenere insieme, in una sola testa, l'esperienza materiale dei sistemi distribuiti e la tradizione concettuale del diritto della responsabilità. Non è un compito che si possa delegare a nessuno, e non è nemmeno un compito che si possa finire in un solo saggio. Ciò che si può fare, con un saggio, è provare a nominare il problema, offrire una direzione, invitare chi ha strumenti simili ai miei a continuare il lavoro. La bottiglia di Mrs. Donoghue era opaca, e dentro c'era una lumaca che nessuno aveva visto. Il software contemporaneo è ancora più opaco, e dentro ci sono molte più lumache, e la giurisprudenza che ci protegge è stata scritta per un mondo in cui le bottiglie erano di vetro. È arrivato il tempo di scrivere la giurisprudenza di un mondo in cui le bottiglie non ci sono più. --- # L'ultimo respiro e il primo problema dell'ai - **URL:** https://margiovanni.it/it/blog/lultimo-respiro-e-il-primo-problema-dellai/ - **Pubblicato:** 2026-04-16 - **Tag:** Benessere, Intelligenza Artificiale, Lavoro, Organizzazione - **Tempo di lettura:** 9 min > Gli agenti fanno più lavoro, ma noi lavoriamo di più. Il vero collo di bottiglia non è la produttività: è il corpo, con sonno, limiti e tempo finito. Qualche giorno fa mi è capitata sotto gli occhi una newsletter di swyx su Latent.Space. Si intitola “Humanity’s last gasp”, l’ultimo respiro dell’umanità. Non è un titolo urlato, anzi. È scritto con quel tono pacato e un po’ obliquo che, proprio perché non alza la voce, ti costringe ad ascoltare meglio. Dentro ci sono tre immagini che mi sono rimaste addosso. Aaron Levie dice che in Silicon Valley nessuno sta lavorando meno, semmai il contrario. Tyler Cowen, da economista, sostiene che dovresti lavorare molto più duramente *adesso* , sia se pensi che l’ai svaluterà il tuo lavoro, sia se pensi che lo renderà più prezioso. E poi c’è Simon Last di Notion che parla di notti insonni e di una nuova ansia, la “token anxiety”, una cosa che due anni fa non esisteva nemmeno come concetto. Il paradosso che swyx mette al centro è semplice e, proprio per questo, un po’ inquietante. Gli agenti fanno più lavoro che mai, i benchmark si saturano, i modelli superano esperti umani in percentuali che fino a poco fa avremmo definito fantascienza. Eppure le persone che costruiscono e gestiscono questi sistemi non hanno mai lavorato così tanto. E qui mi si accende una domanda che non riesco a spegnere facilmente: se la promessa era “più produttività”, perché la sensazione diffusa è “più pressione”? ## La spiegazione comoda: è solo una fase {: #la-spiegazione-comoda-e-solo-una-fase } L’obiezione più ragionevole è anche quella che mi viene spontaneo fare, se provo a essere onesto. Forse è una fase transitoria. La solita dinamica della disruption: prima rompe, poi ricompone. Lo abbiamo già visto con il personal computer, con internet, con gli smartphone. I lavori cambiano, alcuni spariscono, altri nascono, la produttività cresce, e alla fine, almeno per chi governa bene la transizione, il benessere medio migliora. È un’obiezione seria. Chi la ignora rischia di scivolare in una forma di luddismo da tastiera, quella cosa per cui ti convinci che il problema sia la tecnologia in sé, invece che il modo in cui la stiamo inserendo nei sistemi economici e sociali. Ma c’è un punto in cui questa obiezione smette di funzionare. E quel punto, per me, è il corpo. ## Il corpo non scala {: #il-corpo-non-scala } Il problema non è solo se l’ai sostituirà i knowledge worker o li potenzierà. Il problema è che il corpo umano non scala. Non scala come scalano i token. Non scala come scala un cluster da decine di gigawatt. Non scala come scala la curva di apprendimento di un modello che ingurgita una quantità di conoscenza enorme in settimane. Il corpo ha un orologio biologico che non si resetta con un aggiornamento. Ha bisogno di sonno, e se glielo togli per mesi magari vai avanti lo stesso, almeno in apparenza, fino al momento in cui qualcosa si rompe. E spesso si rompe in modi che non avevi previsto e che non sono così facili da invertire. Ha bisogno di movimento, di luce naturale, di ritmi. Non è stato progettato per le tre del mattino passate a debuggare un agente che ha generato ottocento righe di codice che “funzionano”, ma che non capisci davvero. Queste cose non sono nuove. Le dice la medicina del lavoro, le dicono le neuroscienze, le dice qualunque medico di base con un minimo di onestà intellettuale. Eppure, nel discorso dominante sull’ai, il corpo sembra un dettaglio implementativo. Un vincolo legacy da aggirare con abbastanza caffeina e abbastanza forza di volontà. ## Da dove lo guardo io {: #da-dove-lo-guardo-io } Io sono partner e responsabile tecnico di una piccola azienda ict a Pescara. Siamo una decina di persone. Da un po’ non scrivo più codice in produzione, o almeno non come prima. Il mio lavoro è diventato ricerca, spike strategici, valutazione di architetture, e anche compliance normativa, che è una parola poco sexy ma molto reale. Passo le giornate a capire dove sta andando il mercato e a decidere cosa ha senso fare e cosa no, per un’azienda che non ha il lusso di un round di investimento per assorbire gli errori. E che ha una responsabilità diretta sulle persone che ci lavorano, persone che la sera tornano a casa, che hanno famiglie, corpi, limiti. Da questa posizione vedo una cosa che, forse, quando sei dentro al flusso quotidiano fai più fatica a mettere a fuoco. L’ai non ha ridotto il carico di lavoro di nessuno nel mio team. Lo ha trasformato. Ha spostato il peso dalla produzione di codice alla supervisione di codice prodotto da altri, dove “altri” in questo caso è un modello statistico che non dorme, non si stanca, non si ammala. Ma sbaglia. E sbaglia in modi creativi e imprevedibili. E qui c’è un dettaglio che mi sembra importante, anche se non so ancora spiegare bene *quanto* lo sia. Leggere codice scritto da un’intelligenza aliena è un lavoro diverso dallo scriverlo. Richiede una vigilanza costante. È una forma di attenzione che ti tiene sempre un po’ in allerta. E questa allerta è incompatibile con una cosa che, nel lavoro cognitivo, è quasi una forma di protezione naturale: il flow, lo stato di concentrazione profonda in cui non sei spezzettato, non sei continuamente interrotto, non sei costretto a fare micro-giudizi ogni trenta secondi. ## La domanda cresce, il controllo scende {: #la-domanda-cresce-il-controllo-scende } C’è un concetto in medicina del lavoro che si chiama “job strain”, nel modello di Karasek. In estrema sintesi descrive la combinazione più tossica: alta domanda lavorativa e basso controllo sulla propria attività. Ecco, io ho l’impressione che l’introduzione massiva degli agenti ai stia facendo esattamente questo: sta mutando il rapporto tra domanda e controllo. La domanda aumenta perché, se gli strumenti sono più veloci, l’aspettativa di output cresce insieme a loro. “Se l’agente può farlo in un’ora, perché ci mettiamo una giornata?” è una domanda che arriva quasi automaticamente, spesso senza cattiveria, solo per inerzia. Il controllo diminuisce perché deleghi una parte crescente del processo a sistemi che non comprendi fino in fondo e che cambiano ogni poche settimane. Anche quando li capisci, li capisci in un modo diverso da come capisci un collega o un componente software tradizionale. È una comprensione più probabilistica, più fragile. In questo senso la “token anxiety” non mi sembra una moda linguistica. Mi sembra un sintomo. L’ansia, dopotutto, è una funzione adattativa. Se compare su scala industriale, forse non è un problema individuale. Forse è un segnale di sistema. ## “Se rallentiamo noi, non rallenta la cina” {: #se-rallentiamo-noi-non-rallenta-la-cina } A questo punto arriva quasi sempre un’altra obiezione, e anche questa ha un nucleo di verità. Se noi rallentiamo, altri non rallentano. Se noi mettiamo limiti, altri spingono. E in una corsa globale, chi arriva primo vince. Però mi chiedo se non ci sia un errore di categoria nascosto dentro questa frase. La competizione tra nazioni e tra aziende è una competizione tra sistemi, non tra individui. Un sistema che brucia le persone che lo compongono non è un sistema competitivo. È un sistema che sta consumando il proprio capitale più prezioso, cioè l’intelligenza e la creatività di esseri umani che funzionano bene solo quando sono sani, riposati e motivati da qualcosa che non sia la paura. La storia del software è piena di aziende che hanno “vinto” nel breve termine con il crunch e hanno perso nel medio termine. Perché i migliori se ne vanno, o si ammalano, o smettono semplicemente di avere idee. Un cervello esausto non è un motore da spremere, è un ecosistema che collassa. ## Forse il primo problema è dentro il torace {: #forse-il-primo-problema-e-dentro-il-torace } Se il punto non è solo la corsa ai benchmark, allora qual è il primo problema? Io credo che sia sotto il nostro naso, anzi dentro il nostro torace. Il problema più prezioso è capire come integrare strumenti di potenza straordinaria nella vita lavorativa senza che la vita lavorativa divori la vita. Non è un problema tecnico, o almeno non è solo un problema tecnico. È un problema di design organizzativo, di cultura manageriale, di politica del lavoro. E alla fine è anche un problema filosofico, perché ti costringe a decidere cosa vale la pena fare con il tempo che abbiamo. Che è finito in un modo che nessuna tecnologia può cambiare. ## Una cosa personale, che però pesa {: #una-cosa-personale-che-pero-pesa } Io ho un figlio. Non è un argomento logico, è un fatto biografico. Ma i fatti biografici, a volte, pesano più degli argomenti. Quando la sera chiudo il portatile e lo guardo, penso che tutto il codice scritto durante il giorno, anche quello “moltiplicato” dagli agenti, non vale un’ora di quel tempo. Non perché il lavoro non conti. Conta eccome. Ma perché quel tempo è irrecuperabile in un senso che il codice non lo è. Il codice si può riscrivere. Un’infanzia no. So che in certi ambienti questo suona come debolezza. Come mancanza di ambizione. Come sentimentalismo che non sopravvive alla prossima valutazione di mercato. Però, forse, è il contrario. Forse la vera ambizione è costruire sistemi, aziende e vite che durino. E durare richiede prendersi cura del mezzo attraverso cui tutto il resto accade. Il corpo umano, con il suo bisogno non negoziabile di riposo, relazione, e di un tempo che non sia misurato in token al secondo. ## L’allineamento che non stiamo guardando {: #lallineamento-che-non-stiamo-guardando } L’industria dell’ai ama parlare di allineamento, di come fare in modo che i modelli facciano ciò che vogliamo. Ma mi chiedo se il primo problema di allineamento non riguardi i modelli. Riguardi noi. Stiamo costruendo un’economia dell’attenzione e della produttività in cui gli incentivi sono spesso disallineati rispetto a ciò che sappiamo essere necessario per la salute umana. Dormiamo poco, ci muoviamo poco, ci fermiamo poco. E poi proviamo a compensare con la tecnologia, con le app di meditazione, con i tracker del sonno, con gli integratori. È come se avessimo creato un sistema produttivo che non produce più benessere come effetto collaterale del lavoro, e poi ci stupiamo che nasca un’industria del benessere a riparare i danni. ## Una direzione, non una soluzione {: #una-direzione-non-una-soluzione } Non ho una soluzione pulita, e diffido di chi ne propone. Però una direzione ce l’ho. Prendere sul serio che *la salute e il tempo umano sono il vincolo primario*. Non l’efficienza dei modelli, non la velocità di deployment, non il numero di righe di codice generate in un’ora. Ogni decisione organizzativa, ogni sprint planning, ogni architettura di sistema dovrebbe essere valutata anche con una domanda molto concreta: quanta vita costa? E se la risposta è “troppa”, allora forse non è il problema giusto. O non è il momento giusto. O non è il modo giusto. Questo non significa “lavorare meno” nel senso banale del termine. Significa lavorare sapendo che il sistema più sofisticato dell’universo conosciuto non è un llm. È il cervello umano che lo ha progettato. E quel cervello funziona secondo regole che non abbiamo scritto noi e che non possiamo riscrivere a piacimento. Quell’ultimo respiro, forse, non è l’ultimo respiro dell’umanità. Forse è l’ultimo respiro di un modo di lavorare che tratta le persone come risorse fungibili dentro una pipeline di ottimizzazione. Se è così, forse non dovremmo cercare di prolungarlo. Forse dovremmo lasciarlo andare e imparare a respirare in un modo diverso. Un modo che tenga conto del fatto che siamo fatti di carne, di tempo e di relazioni. E che nessun agente, per quanto potente, potrà mai vivere al posto nostro. --- # Il comportamento è la nuova credenziale. E questo è un problema. - **URL:** https://margiovanni.it/it/blog/il-comportamento-e-la-nuova-credenziale-e-questo-e-un-problema/ - **Pubblicato:** 2026-04-07 - **Tag:** AI Act, Behavioral Biometrics, Biometric Data, Continuous Authentication - **Tempo di lettura:** 11 min > La cybersecurity sta attraversando una transizione che merita più attenzione di quella che riceve. La cybersecurity sta attraversando una transizione che merita più attenzione di quella che riceve. La domanda fondamentale dell'autenticazione online si sta spostando: non più "cosa sai?" (password, PIN), non più "cosa possiedi?" (token, smartphone), non più "come appari?" (impronta digitale, riconoscimento facciale), ma "come ti comporti?" L'idea è elegante, e il paper che la sostiene è solido. Un recente articolo di Brandon Janes su Towards Data Science, intitolato "Behavior is the New Credential", racconta come i sistemi di biometria comportamentale stiano diventando lo standard nel settore bancario. Il punto di partenza è uno studio del 2012 dell'Università di Berkeley, "Touchalytics", che dimostrò come bastassero undici scroll su uno smartphone per identificare un utente specifico all'interno di un gruppo di quarantuno persone, senza errori. Trenta caratteristiche comportamentali uniche: lunghezza del gesto, velocità, curvatura, traiettoria, tempo tra uno scroll e l'altro, persino l'area del dito utilizzata. La teoria sottostante è quella del controllo motorio computazionale, un campo interdisciplinare tra neuroscienza, biomeccanica e informatica. Le correzioni inconsce che il nostro cervello opera durante ogni gesto, quei microaggiustamenti che avvengono nell'ordine dei millisecondi, sono talmente individuali da rendere il profilo comportamentale di una persona quasi impossibile da replicare. Paradossalmente, è proprio ciò che consideriamo "robotico" (queste correzioni neurali automatiche) a rendere ciascuno di noi irriproducibilmente umano. ## Perché le vecchie difese non bastano più {: #perche-le-vecchie-difese-non-bastano-piu } Il contesto che rende necessaria questa transizione è concreto e documentato. Il malware moderno ha raggiunto capacità che rendono obsoleti i meccanismi tradizionali di verifica. Strumenti come ProKYC, un tool deepfake utilizzato nel cybercrimine, permettono di superare l'autenticazione a due fattori, il riconoscimento facciale e persino le verifiche video in tempo reale. BingoMod, un trojan di accesso remoto distribuito via SMS di phishing, si maschera da antivirus su Android e consente a un attaccante remoto di intercettare credenziali, messaggi e codici OTP, fino a eseguire trasferimenti di denaro dal dispositivo infettato. Quando il dispositivo è compromesso, dal punto di vista della banca tutto appare normale: il fingerprint del device è corretto, l'indirizzo IP è quello giusto, i codici MFA tornano. La verifica tradizionale, che opera in un singolo istante nel tempo (il login), non è più sufficiente. Il perimetro di sicurezza non è più il cancello d'ingresso. È la sessione intera. Qui entra la biometria comportamentale, che opera come autenticazione continua. I modelli di anomaly detection costruiti sul profilo specifico di ciascun utente monitorano la sessione dall'inizio alla fine. Quando i segnali di rischio aumentano, il sistema può richiedere verifiche aggiuntive o bloccare la transazione. Quando il comportamento è coerente con il profilo stabilito, la sessione prosegue senza interruzioni. Il risultato, ironicamente, è un'esperienza utente migliore: meno OTP, meno interruzioni, più fluidità. Sicurezza passiva al posto di sicurezza attiva. ## Il lato oscuro della medaglia {: #il-lato-oscuro-della-medaglia } Fin qui il racconto dell'industria della cybersecurity. È un racconto che funziona, tecnicamente fondato e operativamente efficace. Ma è anche un racconto che evita sistematicamente una domanda: cosa significa, dal punto di vista dei diritti fondamentali, trasformare il comportamento umano in una credenziale? Partiamo da un dato normativo che l'articolo di Janes non menziona. Il GDPR, all'articolo 4(14), definisce i dati biometrici come "dati personali ottenuti da un trattamento tecnico specifico relativi alle caratteristiche fisiche, fisiologiche o comportamentali di una persona fisica che ne consentono o confermano l'identificazione univoca". La parola chiave è "comportamentali". Il legislatore europeo ha incluso esplicitamente i dati comportamentali nella definizione di dato biometrico. L'articolo 9 classifica poi i dati biometrici come "categoria particolare" di dati personali, il cui trattamento è in linea generale vietato, salvo eccezioni specifiche: consenso esplicito, interesse pubblico sostanziale, protezione di interessi vitali. Questo significa che ogni sistema di biometria comportamentale che opera nell'Unione Europea sta trattando dati di categoria speciale. Non dati personali generici. Dati che richiedono consenso esplicito, una valutazione d'impatto sulla protezione dei dati (DPIA), limitazione delle finalità, minimizzazione del trattamento e diritto alla cancellazione. La domanda che nessun vendor di cybersecurity ama affrontare è: come si concilia il diritto alla cancellazione con un profilo comportamentale costruito attraverso l'analisi continua di migliaia di microinterazioni? Puoi cancellare un profilo, certamente. Ma puoi cancellare la conoscenza derivata da quel profilo, una volta che è stata utilizzata per addestrare un modello? Il GDPR pone domande specifiche sulla minimizzazione dei dati e sulla limitazione delle finalità quando i dati sono stati utilizzati per l'addestramento di modelli di intelligenza artificiale. ## Il doppio vincolo dell'AI Act {: #il-doppio-vincolo-dellai-act } Il quadro si complica ulteriormente con l'AI Act, il cui impianto regolatorio per i sistemi ad alto rischio si applica pienamente dal agosto 2026. L'intersezione tra GDPR e AI Act crea un framework normativo stratificato per le tecnologie biometriche. L'AI Act distingue tra diverse tipologie di sistemi biometrici. I sistemi di identificazione biometrica remota in tempo reale sono vietati per le forze dell'ordine, con eccezioni limitate. Tutti gli altri sistemi di identificazione biometrica remota sono classificati come ad alto rischio. I sistemi di categorizzazione biometrica che inferiscono attributi sensibili (razza, opinioni politiche, appartenenza sindacale, orientamento sessuale) sono vietati. I sistemi di riconoscimento delle emozioni sono vietati nei luoghi di lavoro e nelle scuole, e classificati come ad alto rischio negli altri contesti. Dove si colloca la biometria comportamentale bancaria in questa tassonomia? L'AI Act esclude esplicitamente dalla definizione di identificazione biometrica remota gli strumenti di verifica biometrica che confermano che una persona è chi dichiara di essere, purché richiedano la partecipazione attiva dell'individuo. Ma la biometria comportamentale, per definizione, è passiva. L'utente non "partecipa attivamente" alla propria autenticazione comportamentale. Il sistema lo osserva mentre fa altro. Questa zona grigia tra verifica attiva e sorveglianza passiva è precisamente il territorio in cui i diritti fondamentali iniziano a scricchiolare. C'è un elemento aggiuntivo. L'AI Act vieta i sistemi di AI che classificano le persone sulla base del loro comportamento sociale, quando tale classificazione produce un trattamento sfavorevole in contesti non correlati al contesto originale di raccolta dei dati, o un trattamento sproporzionato rispetto alla gravità del comportamento. La linea tra "autenticazione comportamentale per prevenire la frode" e "profilazione comportamentale per classificare gli utenti" non è così netta come l'industria vorrebbe far credere. ## Function creep: il rischio strutturale {: #function-creep-il-rischio-strutturale } La storia della tecnologia ci insegna che i sistemi costruiti per uno scopo specifico tendono a espandere il proprio raggio d'azione nel tempo. Questo fenomeno, noto come function creep, è particolarmente insidioso nel campo della biometria comportamentale. Un sistema che oggi analizza come scorri una pagina per verificare che tu sia tu, domani potrebbe utilizzare gli stessi dati per inferire il tuo stato emotivo, il tuo livello di attenzione, la tua condizione cognitiva, la tua propensione al rischio finanziario. I dati comportamentali sono straordinariamente ricchi di informazioni implicite. Il ritmo con cui digiti può rivelare ansia o fatica. La velocità di scrolling può indicare interesse o noia. La pressione del tocco può suggerire irritazione o calma. Le banche, che oggi utilizzano questi dati per la prevenzione delle frodi, siedono su un patrimonio informativo che ha un valore potenziale enormemente superiore alla sicurezza delle transazioni. La tentazione di monetizzare questi dati, o di utilizzarli per finalità commerciali (personalizzazione dei servizi, scoring creditizio, profilazione per prodotti assicurativi), è una forza economica che le sole policy interne difficilmente riusciranno a contenere nel lungo periodo. In Australia, un database biometrico progettato per prevenire la criminalità transfrontaliera è stato successivamente utilizzato per identificare persone che avevano perso i documenti negli incendi. In quel caso l'uso esteso aveva un intento benevolo. Ma il precedente era stabilito: una volta che il dato esiste e il sistema è operativo, le finalità si espandono. ## Il corpo informatizzato {: #il-corpo-informatizzato } C'è una dimensione più profonda, che va oltre il diritto e tocca l'antropologia della tecnologia. La biometria comportamentale trasforma il modo in cui interagiamo con i nostri dispositivi in un dato di identificazione permanente. Il National Research Council degli Stati Uniti ha descritto questo processo come la creazione di un "corpo informatizzato": un corpo che non è più rappresentato dalle sue caratteristiche anatomiche osservabili dall'occhio umano, ma dalle informazioni digitali sul corpo conservate nei database. Quando il tuo modo di scorrere una pagina diventa una credenziale, il tuo gesto inconscio diventa un dato. La spontaneità del tuo movimento viene catturata, analizzata, modellata, archiviata. Non stai fornendo attivamente un'informazione, come quando digiti una password. Stai semplicemente vivendo, e il sistema estrae valore dalla tua esistenza ordinaria. Shoshana Zuboff ha descritto questa dinamica come la caratteristica fondamentale del capitalismo della sorveglianza: l'appropriazione dell'esperienza personale e la sua trasformazione in dati comportamentali, utilizzati poi per predire e modificare il comportamento stesso. La biometria comportamentale per la cybersecurity è, in un certo senso, la versione "buona" di questo meccanismo. Ma il meccanismo è lo stesso. E la distanza tra la versione buona e le versioni meno buone è solo una questione di finalità dichiarate, che possono cambiare. ## L'asimmetria del consenso {: #lasimmetria-del-consenso } Un aspetto particolarmente problematico riguarda la natura del consenso in questi sistemi. Il GDPR richiede che il consenso sia "libero, specifico, informato e inequivocabile", con un onere ancora maggiore quando si tratta di categorie speciali di dati. Ma come può essere realmente libero il consenso a un sistema di biometria comportamentale nella tua app bancaria, quando l'alternativa è non poter accedere al tuo conto corrente? Le autorità di protezione dei dati europee hanno già affrontato questa questione in contesti analoghi. L'autorità olandese ha sanzionato un'azienda per 725.000 euro perché i dipendenti percepivano la scansione delle impronte digitali come un obbligo, rendendo il consenso non libero. L'autorità svedese ha sanzionato una scuola per l'uso del riconoscimento facciale per monitorare le presenze, rilevando lo squilibrio di potere tra l'istituzione e gli studenti. Nel caso della biometria comportamentale bancaria, lo squilibrio è analogo. Il servizio bancario non è opzionale nella società contemporanea. Se la banca implementa l'autenticazione comportamentale, il cliente non ha una reale alternativa al consenso. La dinamica assomiglia più a una condizione imposta che a una scelta informata. ## Il paradosso dell'irrevocabilità {: #il-paradosso-dellirrevocabilita } A differenza di una password compromessa, che può essere cambiata in pochi secondi, un profilo comportamentale compromesso presenta un problema strutturale: non puoi cambiare il modo in cui scorri una pagina o digiti sulla tastiera con la stessa facilità con cui cambi una stringa di caratteri. I tuoi pattern comportamentali sono intrinsecamente legati alla tua fisiologia e alla tua neurologia. Sono, in un senso molto concreto, te stesso. Questo introduce un rischio di lungo periodo che il settore tende a minimizzare. Se un database di profili comportamentali viene compromesso, i dati esfiltrati non diventano obsoleti con una rotazione delle credenziali. Rimangono utilizzabili fino a quando le caratteristiche biometriche dell'individuo non cambiano significativamente, il che, nella maggior parte dei casi, avviene solo con l'invecchiamento o in seguito a eventi traumatici. I fornitori di questi sistemi sottolineano che i profili vengono tipicamente processati localmente e che viene trasmesso solo un punteggio di rischio, non i dati grezzi. È una mitigazione reale, ma non elimina il problema fondamentale: da qualche parte, in qualche forma, una rappresentazione del tuo comportamento inconscio esiste come dato digitale. ## Discriminazione algoritmica e bias comportamentali {: #discriminazione-algoritmica-e-bias-comportamentali } Un ulteriore aspetto critico riguarda il potenziale discriminatorio dei sistemi di biometria comportamentale. I pattern di interazione con i dispositivi non sono universali. Variano in base all'età, alle condizioni fisiche, alle disabilità motorie, alle differenze culturali nell'uso della tecnologia, al tipo di dispositivo utilizzato. Un utente anziano con artrite alle mani avrà pattern di scroll e digitazione significativamente diversi da un ventenne. Un utente con un dispositivo economico di fascia bassa produrrà dati sensoriali diversi da uno con l'ultimo modello di smartphone. Un utente che alterna tra mano destra e mano sinistra, o che utilizza tecnologie assistive, genererà profili atipici. Se il modello di anomaly detection è stato addestrato prevalentemente su profili di utenti normodotati di fascia media, gli utenti che si discostano da questo profilo medio saranno sottoposti più frequentemente a verifiche aggiuntive, blocchi di sessione, richieste di step-up authentication. In altre parole, la sicurezza "passiva" che l'industria pubblicizza come migliore esperienza utente potrebbe tradursi in un'esperienza sistematicamente peggiore per le categorie più vulnerabili. L'European Accessibility Act (EAA), pienamente applicabile dal giugno 2025, impone che i prodotti e servizi digitali siano accessibili alle persone con disabilità. Un sistema di autenticazione comportamentale che penalizza sistematicamente gli utenti con disabilità motorie o cognitive solleva questioni di conformità non solo rispetto al GDPR e all'AI Act, ma anche rispetto alla normativa sull'accessibilità. ## Il dovere di guardare oltre la soluzione tecnica {: #il-dovere-di-guardare-oltre-la-soluzione-tecnica } Niente di quanto scritto sopra significa che la biometria comportamentale sia una cattiva idea. Il problema della cybersecurity è reale, le perdite sono enormi (l'FBI Internet Crime Report documenta miliardi di dollari di perdite annuali), e le difese tradizionali sono effettivamente inadeguate contro le minacce attuali. L'autenticazione continua è probabilmente il futuro della sicurezza digitale. Ma il modo in cui l'industria racconta questa transizione è incompleto in maniera non accidentale. L'articolo di Janes, come la maggior parte della letteratura tecnica sul tema, presenta la biometria comportamentale esclusivamente dal punto di vista dell'efficacia operativa. Il sottotesto è: funziona meglio, è più sicuro, l'esperienza utente migliora. Tutto vero. Ma non è tutto. Per chi opera nel settore ICT europeo, la responsabilità è doppia. Da un lato, implementare queste tecnologie dove sono necessarie e dove creano valore reale. Dall'altro, farlo con una consapevolezza normativa e etica che il mercato americano, da cui proviene la maggior parte dell'innovazione in questo campo, non ha la stessa urgenza di sviluppare. L'Europa, con il suo framework regolatorio stratificato (GDPR, AI Act, EAA, NIS2), non sta rendendo la vita difficile a chi lavora con la tecnologia. Sta ponendo le domande che il mercato, da solo, non pone. Domande come: chi possiede il tuo modo di muovere il dito su uno schermo? Che diritti hai su un gesto inconscio trasformato in dato? Cosa succede quando il tuo corpo informatizzato diventa una merce? Sono domande scomode. Ma nel momento in cui il comportamento diventa credenziale, non abbiamo il lusso di ignorarle. --- # Microsoft scrive la confessione perfetta e il conto lo pagherai tu - **URL:** https://margiovanni.it/it/blog/microsoft-scrive-la-confessione-perfetta-e-il-conto-lo-pagherai-tu/ - **Pubblicato:** 2026-04-06 - **Tag:** AI Act, Compliance, Microsoft Copilot, PLD - **Tempo di lettura:** 19 min > La tentazione è liquidare la cosa come una gaffe del reparto legale. Non lo è. I Terms of Use non vengono scritti per distrazione. ## I. Il giocattolo da ottanta miliardi {: #i-il-giocattolo-da-ottanta-miliardi } Esiste un documento che dovreste leggere. Non è lungo, non è nascosto, non richiede competenze giuridiche particolari per essere compreso. Si trova all'indirizzo [microsoft.com/en-us/microsoft-copilot/for-individuals/termsofuse](), è stato aggiornato il 24 ottobre 2025 e contiene una frase che merita di essere presa sul serio. La frase si trova nella sezione intitolata, in maiuscolo e grassetto, "IMPORTANT DISCLOSURES & WARNINGS", e dice: Copilot è da considerarsi esclusivamente a scopo di intrattenimento. Può commettere errori e potrebbe non funzionare come previsto. Non fare affidamento su Copilot per consigli importanti. Usare Copilot a proprio rischio. Se vi sembra la clausola di un'app per generare meme, vi capisco. Ma stiamo parlando del prodotto che Microsoft ha integrato in Windows 11, in Excel, in PowerPoint, in Teams, in Outlook, nel cuore pulsante della suite che oltre 430 milioni di persone usano ogni giorno. Stiamo parlando del prodotto per cui Microsoft ha impegnato circa ottanta miliardi di dollari in capital expenditure AI nel solo fiscal year 2025, tra data center, infrastruttura e capacità computazionale, a cui si sommano i circa tredici miliardi investiti cumulativamente in OpenAI, la cui tecnologia alimenta i modelli sottostanti. Stiamo parlando del prodotto venduto alle grandi aziende a trenta dollari per utente al mese, e alle piccole e medie imprese a ventuno (ridotti a diciotto con le promozioni del primo semestre 2026). I Terms of Use di questo prodotto dicono che è un giocattolo. La reazione di Microsoft, quando la clausola ha cominciato a circolare sui social media nei primi giorni di aprile 2026, è stata prevedibile nella sua meccanicità. Un portavoce ha dichiarato a PCMag che si tratta di "linguaggio legacy" che "non riflette più l'uso attuale del prodotto" e che "verrà modificato con il prossimo aggiornamento". Nessuna data. Nessun impegno vincolante. Nessuna spiegazione del perché un linguaggio che non riflette la realtà del prodotto sia rimasto nei documenti legali per mesi dopo l'ultimo aggiornamento, sotto gli occhi dello stesso team legale che lo aveva scritto. Il portavoce ha parlato come se qualcuno avesse dimenticato di togliere un cartello da un cantiere chiuso. Ma i cantieri chiusi non fatturano trenta dollari a posto al mese. La tentazione è liquidare la cosa come una gaffe del reparto legale. Non lo è. I Terms of Use non vengono scritti per distrazione. Vengono scritti da team di avvocati che pesano ogni parola sapendo che quelle parole verranno usate in tribunale. La parola "entertainment" non è un sinonimo svogliato di "sperimentale" o "beta". Entertainment ha un significato giuridico preciso nel diritto anglosassone: è la categoria che protegge chi produce contenuti dichiaratamente non fattuali, come i giochi, le fiction, le simulazioni. Dire che un prodotto è "for entertainment purposes only" significa dire che nessun utente ragionevole dovrebbe aspettarsi che le sue risposte siano accurate, affidabili, o adatte a qualsiasi scopo pratico. Si potrebbe obiettare che i numeri raccontano una storia diversa. Che l'adozione di Copilot è stata più lenta del previsto. Che Microsoft stessa sa che il prodotto ha problemi. E si avrebbe ragione. Al secondo trimestre del fiscal year 2026, solo quindici milioni di posti su quattrocentocinquanta milioni di posti commerciali pagati risultavano abbonati a Microsoft 365 Copilot: il 3,3 percento. La quota di mercato USA dei sottoscrittori a pagamento si è contratta del 39 percento in sei mesi, passando dal 18,8 percento di luglio 2025 all'11,5 percento di gennaio 2026. Il Net Promoter Score sull'accuratezza delle risposte è peggiorato da meno 3,5 a meno 24,1 tra luglio e settembre 2025, secondo Recon Analytics. Il 44,2 percento degli utenti che abbandonano Copilot cita la sfiducia nelle risposte come motivazione principale. Quando i lavoratori possono scegliere liberamente tra Copilot, ChatGPT e Gemini, solo l'8 percento sceglie il prodotto Microsoft. Questi numeri non attenuano il problema. Lo aggravano. Dimostrano che Microsoft sa perfettamente che il prodotto non è affidabile, lo dichiara nei documenti legali, e continua a venderlo come strumento di produttività enterprise. Satya Nadella ha chiamato Copilot "a true daily habit" davanti agli investitori. Il marketing lo presenta come l'assistente che trasforma il modo in cui lavori. I Terms of Use dicono che è un giocattolo. Non è una contraddizione. È una strategia. ## II. Il coro dei disclaimer {: #ii-il-coro-dei-disclaimer } Sarebbe intellettualmente disonesto presentare la clausola di Microsoft come un'anomalia. Non lo è. È il caso più eclatante di un pattern che attraversa l'intera industria AI, e che vale la pena mappare con precisione. OpenAI, nei suoi Terms of Use, avverte gli utenti di non fare affidamento sugli output come unica fonte di verità o informazione fattuale, e limita la propria responsabilità aggregata a cento dollari o all'importo pagato nei dodici mesi precedenti. Google, nei termini di Gemini, scrive di non fare affidamento sui servizi per consulenze mediche, di salute mentale, legali, finanziarie o di altro tipo professionale. xAI, l'azienda di Elon Musk, avverte che la propria AI è "probabilistica per natura" e può produrre output errati. Nessuna di queste aziende, va detto, si è spinta fino alla formula "for entertainment purposes only". Quella resta un'esclusiva Microsoft. La differenza tra Microsoft e gli altri non è però di sostanza. È di sfumatura. Tutti i grandi provider di AI stanno facendo la stessa operazione: costruire un muro legale tra il prodotto che vendono e le conseguenze del suo utilizzo. Lo fanno sapendo che i loro modelli possono e producono output falsi, fuorvianti, potenzialmente dannosi. Nell'agosto 2024, Copilot ha identificato falsamente il giornalista tedesco Martin Bernklau come un pedofilo condannato e un truffatore, fornendo anche il suo indirizzo di casa. Microsoft ha bloccato le query su Bernklau solo dopo un reclamo per protezione dati. Questi non sono casi limite. Sono il funzionamento ordinario di un sistema probabilistico presentato commercialmente come se fosse deterministico. E i disclaimer, in tribunale, funzionano. Il 19 maggio 2025, la Superior Court della contea di Gwinnett, in Georgia, ha emesso un summary judgment a favore di OpenAI nel caso Walters v. OpenAI (23-A-04860-2). Il conduttore radiofonico Mark Walters aveva citato OpenAI dopo che ChatGPT, su richiesta di un giornalista, aveva generato un falso riepilogo di una causa legale in cui Walters risultava accusato di appropriazione indebita ai danni della Second Amendment Foundation. Il tribunale ha rigettato la causa su tre motivi indipendenti: le dichiarazioni non potevano essere ragionevolmente intese come fatti reali (anche perché ChatGPT aveva avvisato il giornalista dei propri limiti e i ToS contenevano disclaimer espliciti sulla possibilità di errori); Walters non aveva dimostrato né negligenza né malice da parte di OpenAI; e lo stesso Walters aveva ammesso di non aver subito alcun danno. Un esito che si regge su più gambe, quindi, non solo sui disclaimer. Ma i disclaimer hanno pesato, e pesano. Il tribunale ha riconosciuto esplicitamente che i ripetuti avvertimenti sulla possibilità di "hallucination" contribuivano a rendere irragionevole qualsiasi aspettativa di accuratezza fattuale da parte dell'utente. È a questo punto che molti commentatori si fermano, indignandosi. Ma è qui che il discorso deve diventare più preciso, perché non tutti i disclaimer sono uguali, non tutti servono allo stesso scopo, e non tutti sono, in sé, una cosa negativa. L'AI Act europeo, il Regolamento 2024/1689, richiede esplicitamente che i provider di sistemi AI comunichino le limitazioni dei propri prodotti. L'Articolo 13 dispone che i sistemi AI ad alto rischio siano progettati in modo sufficientemente trasparente da consentire ai deployer di interpretare gli output e usarli in modo appropriato, e che siano accompagnati da istruzioni d'uso con informazioni concise, complete, corrette e chiare sulle caratteristiche, capacità e limitazioni di performance. L'Articolo 14 impone la supervisione umana effettiva, e prescrive che le persone preposte alla supervisione siano messe in condizione di restare consapevoli della possibile tendenza a fare affidamento automatico o eccessivo sugli output, quello che il Regolamento chiama "automation bias". L'Articolo 50 richiede che gli utenti siano informati quando interagiscono con un sistema AI, e che i contenuti generati siano contrassegnati come tali. Dire "questo sistema AI può sbagliare, verifica sempre, non fidarti ciecamente" non è solo legittimo, dunque. È un obbligo normativo. L'Europa ha sancito che la trasparenza sulle limitazioni dei sistemi AI è un pilastro della sicurezza e della fiducia. L'utente deve sapere con cosa sta interagendo, quali sono i rischi, e deve poter decidere di ignorare o sovrascrivere qualsiasi output del sistema. Questo è il framework che qualsiasi azienda seria dovrebbe seguire. Ma una cosa è dire "questo sistema ha queste limitazioni, ecco come supervisionarlo per usarlo in modo sicuro". Un'altra è dire "questo è un giocattolo per intrattenimento, usalo a tuo rischio, non garantiamo nulla". La prima formulazione è trasparenza. Compliance con l'AI Act. Un atto di responsabilità che mette il deployer in condizione di fare il suo lavoro. La seconda formulazione è uno scarico di responsabilità travestito da trasparenza. Non mette l'utente in condizione di usare il sistema in modo appropriato: lo mette in condizione di non potersi rivalere quando le cose vanno male. L'AI Act chiede al provider di dichiarare le limitazioni per consentire un uso sicuro. I ToS di Microsoft dichiarano le limitazioni per impedire qualsiasi rivalsa. Uno serve l'utente. L'altro serve il reparto legale. E quando un tribunale americano valuta positivamente i disclaimer di un provider nel rigettare una causa per diffamazione, non sta necessariamente premiando la trasparenza. Sta prendendo atto del legalese. ## III. La Direttiva che cambia tutto (e il punto cieco) {: #iii-la-direttiva-che-cambia-tutto-e-il-punto-cieco } Entro il 9 dicembre 2026, gli Stati membri dell'Unione Europea devono recepire nella legislazione nazionale la Direttiva 2024/2853, la nuova Product Liability Directive. È il primo aggiornamento in quarant'anni del regime europeo di responsabilità per prodotti difettosi. Per le aziende che producono, integrano o distribuiscono software e sistemi AI, le conseguenze sono profonde. La Direttiva ridefinisce innanzitutto cosa sia un "prodotto". La vecchia direttiva del 1985 era concepita per un mondo di oggetti fisici: automobili, elettrodomestici, giocattoli. La nuova include esplicitamente il software, indipendentemente dalla modalità di fornitura o utilizzo, che sia embedded, standalone, cloud o SaaS. Include firmware, sistemi operativi, applicazioni. I Considerando chiariscono che rientrano nella definizione anche i sistemi di intelligenza artificiale. Il software non è più un servizio che sfugge alla responsabilità di prodotto. È un prodotto. Come tale è soggetto a responsabilità oggettiva: non serve dimostrare la colpa del produttore. Basta dimostrare che il prodotto era difettoso e che il difetto ha causato un danno. C'è poi la questione delle clausole di esonero. L'Articolo 10 dispone che gli Stati membri garantiscano che la responsabilità di un operatore economico ai sensi della Direttiva non sia, nei confronti della persona danneggiata, limitata o esclusa da una disposizione contrattuale o dal diritto nazionale. La formulazione non ammette ambiguità. I disclaimer nei Terms of Use, le clausole di limitazione di responsabilità, le formulazioni "as is" e "for entertainment purposes only": nel momento in cui un consumatore europeo subisce un danno da un prodotto difettoso, non valgono niente. Questo va capito nella sua portata transatlantica. La clausola "Copilot is for entertainment purposes only" continuerà a funzionare negli Stati Uniti, dove il caso Walters v. OpenAI ha confermato che i tribunali prendono sul serio i disclaimer. In Europa, dopo il recepimento della Direttiva, quella stessa clausola diventa inapplicabile. Se Copilot genera un output difettoso che causa un danno a una persona fisica (morte, lesioni, danni psicologici medicalmente riconosciuti, distruzione o corruzione di dati non professionali, danni a proprietà privata), il provider risponde. A prescindere da cosa c'è scritto nei ToS. La Direttiva riscrive anche le regole sull'onere della prova, e qui la faccenda si complica. Introduce presunzioni a favore del danneggiato. Se il convenuto non divulga le informazioni rilevanti, si presume la difettosità. Se il prodotto non è conforme a requisiti obbligatori di legge nazionale o europea, si presume la difettosità. Se c'è un malfunzionamento evidente durante un uso ragionevolmente prevedibile, idem. Se il danneggiato incontra "eccessive difficoltà" nel provare il difetto a causa della complessità tecnica o scientifica del prodotto, i tribunali possono presumere sia la difettosità sia il nesso causale. Per i sistemi AI, dove l'opacità del funzionamento interno è strutturale e non accidentale, questa presunzione sarà la norma. Il danneggiato non dovrà spiegare come funziona il modello che ha generato l'output falso. Dovrà dimostrare che l'output era difettoso e che il danno ne è conseguito. La PLD si intreccia con l'intero framework normativo europeo. La non conformità ai requisiti del Cyber Resilience Act (obbligo di security-by-design, gestione delle vulnerabilità, aggiornamenti di sicurezza) può costituire presunzione di difettosità. Lo stesso vale per il mancato rispetto degli obblighi NIS2. E lo stesso vale, implicitamente, per i requisiti dell'AI Act: un sistema AI che non rispetta gli obblighi di trasparenza, supervisione umana, accuratezza e robustezza è un sistema che non rispetta requisiti obbligatori di legge europea, e quindi un sistema per il quale la PLD può presumere la difettosità. Il cortocircuito è visibile a occhio nudo. L'AI Act chiede ai provider di dichiarare le limitazioni dei propri sistemi per consentire un uso sicuro. La PLD dice che se il prodotto causa un danno, il provider risponde a prescindere dai disclaimer. Il provider è obbligato a informare che il sistema può sbagliare, e contemporaneamente non può usare quell'informazione per sottrarsi alla responsabilità quando il sistema sbaglia effettivamente. È un regime coerente, progettato per proteggere il consumatore. Ma crea una tensione fortissima tra il dovere di trasparenza e l'impossibilità di usare la trasparenza come scudo. Per Microsoft, questa tensione è gestibile. Per chi sta nel mezzo della catena, è potenzialmente letale. ## IV. Chi modifica, paga: l'integratore come capro espiatorio strutturale {: #iv-chi-modifica-paga-lintegratore-come-capro-espiatorio-stru } La PLD non si limita a dire che il produttore del software risponde. Amplia la catena degli operatori economici potenzialmente responsabili con una logica a cascata pensata per garantire che il consumatore europeo abbia sempre un interlocutore raggiungibile nell'UE. Se il manufacturer è fuori dall'UE, risponde l'importatore. Se non c'è un importatore identificabile, risponde il rappresentante autorizzato. Poi il fulfilment service provider. Poi il distributore, se non identifica l'operatore pertinente nella catena entro un mese dalla richiesta del danneggiato. La responsabilità è solidale: più operatori che rispondono per lo stesso danno sono responsabili insieme, ciascuno per l'intero. Fin qui il sistema sembra ragionevole. Ma c'è una figura nella catena che la PLD tratta con particolare durezza e che è cruciale per capire le implicazioni pratiche della clausola "entertainment only": chiunque modifichi sostanzialmente un prodotto dopo la sua immissione sul mercato è considerato un manufacturer del prodotto modificato ed è responsabile nella misura in cui il difetto risulta dalla modifica. I Considerando chiariscono che una modifica sostanziale può risultare anche da un aggiornamento software, da un upgrade, o dall'apprendimento continuo di un sistema AI. Il prodotto così modificato si considera immesso sul mercato al momento in cui la modifica viene effettivamente operata. Pensate a cosa succede nel mondo reale. Un system integrator, una software house, un consulente IT prende Copilot e lo integra in un workflow aziendale. Configura i prompt, collega le sorgenti dati del cliente, personalizza le risposte, automatizza i flussi. Sta modificando sostanzialmente il prodotto? Secondo la PLD, molto probabilmente sì. Il momento in cui prendi un modello AI generalista e lo specializzi per un contesto specifico, stai creando un prodotto diverso da quello originale. Se quel prodotto modificato genera un output difettoso che causa un danno, l'integratore risponde come manufacturer. L'Articolo 12 della PLD prevede una protezione specifica per le micro e piccole imprese che producono software difettoso integrato in un prodotto altrui. Queste imprese possono concordare contrattualmente con il manufacturer del prodotto finale un accordo che le protegga dalle azioni di regresso. Ma questa protezione ha due limiti che ne riducono drasticamente l'utilità. Il primo: non protegge in alcun caso la micro o piccola impresa da un'azione diretta del consumatore. Il consumatore può sempre agire direttamente contro l'integratore, e l'integratore risponde. Il secondo: la protezione per le azioni di regresso richiede un accordo contrattuale con il manufacturer del prodotto. Microsoft non ha alcun obbligo e nessun incentivo a concedere questo tipo di accordi ai system integrator che usano Copilot. I suoi ToS dicono già che il prodotto è "for entertainment purposes only" e che l'utente è "solely responsible" per qualsiasi azione intrapresa sulla base degli output. In un'eventuale azione di regresso, Microsoft potrà dire: vi avevamo avvisato. Avete scelto voi di integrarlo in un prodotto professionale. Non è colpa nostra se lo avete venduto a un cliente come strumento affidabile quando noi stessi vi avevamo detto che era un giocattolo. La PLD impedisce di scaricare la responsabilità verso il basso nella catena, cioè verso il consumatore, tramite clausole contrattuali. Ma non impedisce ai grandi di rifiutarsi di concedere tutele contrattuali verso l'alto, nel rapporto tra integratore e manufacturer. Il risultato è che l'integratore è esposto al consumatore senza potersi proteggere contrattualmente, e non ha alcuna garanzia di potersi rivalere efficacemente su Microsoft. Microsoft ha i team legali, i rappresentanti autorizzati in ogni stato membro, la massa finanziaria per assorbire il contenzioso. L'integratore da dieci persone a Pescara, a Brno, a Lisbona, no. L'obiezione ovvia è che l'integratore può e deve implementare l'human oversight previsto dall'AI Act. Mettere in piedi processi di verifica, formazione degli utenti, supervisione degli output. Ed è vero, l'integratore responsabile lo farà, e dovrà farlo anche per i propri obblighi come deployer sotto l'AI Act. Ma la PLD non chiede se hai fatto del tuo meglio. La PLD chiede se il prodotto era difettoso e se il difetto ha causato un danno. Un output falso generato da un sistema AI integrato in un workflow professionale che causa un danno a una persona fisica è un prodotto difettoso, indipendentemente da quanti livelli di supervisione umana l'integratore abbia implementato. Puoi aver fatto tutto bene e rispondere comunque. Pensate a cosa succede quando un sistema AI integrato in un software gestionale genera un report finanziario errato che porta a una decisione di investimento sbagliata. O quando un assistente AI integrato in un CRM genera una comunicazione diffamatoria su un cliente. O quando un sistema di analisi integrato in una piattaforma sanitaria fornisce un'indicazione errata che influenza un percorso diagnostico. In tutti questi casi, sotto la PLD, il danneggiato può agire contro l'integratore. L'integratore è lì, è nell'UE, è raggiungibile, ha un codice fiscale e un conto corrente. Microsoft è a Redmond. E nei suoi ToS c'è scritto che Copilot è per intrattenimento. ## V. Il conto e chi lo paga {: #v-il-conto-e-chi-lo-paga } C'è un momento, nella storia della regolazione tecnologica, in cui diventa chiaro che le regole sono state scritte per un mondo che non esiste più. La vecchia Product Liability Directive del 1985 era concepita per un mondo in cui i prodotti erano oggetti fisici fabbricati da aziende identificabili, venduti attraverso catene distributive lineari, e usati da consumatori che potevano ragionevolmente valutarne la sicurezza. La nuova PLD è un aggiornamento necessario e per molti versi ammirevole: estende la protezione al software, abbassa le barriere per i consumatori, introduce presunzioni che riequilibrano l'asimmetria informativa. Ma il mondo che regola non è fatto di catene lineari. È fatto di layer sovrapposti, di API che chiamano API, di modelli probabilistici il cui funzionamento interno non è comprensibile nemmeno a chi li ha costruiti. L'architettura logica del framework normativo europeo è la più avanzata al mondo. L'AI Act stabilisce obblighi di trasparenza, supervisione umana, gestione del rischio. Il Cyber Resilience Act impone security-by-design e aggiornamenti di sicurezza continui. NIS2 estende la cybersecurity a settori critici. La PLD chiude il cerchio stabilendo che chi viola questi obblighi e causa un danno paga. L'obiezione non è alla logica del framework. L'obiezione è alla distribuzione pratica delle conseguenze. Le conseguenze, nella realtà dei fatti, seguono una legge di gravitazione economica che nessuna direttiva può invertire: cadono verso il basso. Verso chi ha meno risorse legali, meno massa finanziaria, meno capacità di assorbire il contenzioso. Microsoft, Google, OpenAI hanno ciascuna centinaia di avvocati, rappresentanti autorizzati in ogni giurisdizione, budget legali che superano il fatturato di intere filiere di PMI. Hanno scritto ToS che, anche se inefficaci sotto la PLD verso il consumatore, restano pienamente operativi come argomento nelle azioni di regresso tra operatori economici. Hanno classificato i propri prodotti come "entertainment", "probabilistic", "not a source of truth" con precisione chirurgica, sapendo quale funzione ogni parola avrebbe svolto in un procedimento futuro. La PLD presenta il conto, ma chi lo paga? Lo paga il system integrator da dieci persone che ha preso Copilot, lo ha integrato nel gestionale del cliente, ha fatto formazione, ha implementato la supervisione umana, e scopre che quando l'output difettoso genera un danno, è lui quello raggiungibile, identificabile, citabile. Il provider è dall'altra parte dell'oceano, o comunque protetto da clausole contrattuali B2B, arbitrati a Dublino, e limitazioni di responsabilità tra operatori economici che la PLD non tocca perché riguardano rapporti tra professionisti e non la protezione diretta del consumatore. Sarebbe sbagliato dire che la PLD è un errore. La PLD è incompleta. La sua incompletezza produce un effetto regressivo che premia chi ha le risorse per navigare il sistema e penalizza chi non le ha. L'Articolo 12 riconosce il problema per le micro e piccole imprese, ma lo risolve in modo circolare: ti proteggiamo dal regresso se hai un accordo contrattuale con il manufacturer. Ma il manufacturer non ha alcun obbligo di concederti quell'accordo. E se nei suoi ToS c'è scritto "entertainment only", il suo incentivo a concedertelo è addirittura negativo: quell'accordo significherebbe ammettere implicitamente che il prodotto ha un uso professionale, contraddicendo il proprio scudo legale. C'è un paradosso ulteriore. Le aziende che prendono più sul serio la compliance, che implementano l'human oversight, che informano i propri clienti, che documentano i processi, sono anche quelle che lasciano la traccia documentale più ricca per un'azione di responsabilità. Chi integra Copilot alla buona, senza processi, senza documentazione, senza supervisione, è paradossalmente più difficile da colpire perché lascia meno prove di un rapporto strutturato con il prodotto. La PLD, nel suo tentativo di proteggere il consumatore, rischia di creare un incentivo alla superficialità: chi fa le cose bene è più esposto di chi le fa male. Va considerata anche la dimensione temporale. La PLD si applica ai prodotti immessi sul mercato o messi in servizio dopo il recepimento. Ma i sistemi AI non sono prodotti statici. Vengono aggiornati continuamente. I modelli cambiano. Gli output cambiano. Un sistema AI che oggi funziona in un modo tra sei mesi potrebbe funzionare in modo completamente diverso dopo un aggiornamento del modello sottostante. Ogni aggiornamento sostanziale, secondo i Considerando della PLD, rimette il prodotto sul mercato. L'integratore che ha costruito un workflow basato su Copilot nel 2025 potrebbe trovarsi, dopo un aggiornamento del modello nel 2027, con un prodotto sostanzialmente diverso che genera output diversi, senza avere alcun controllo sulla modifica e con piena responsabilità per i suoi effetti. Non ho una soluzione ordinata per tutto questo. Ma chi lavora in questo settore dovrebbe cominciare a leggere i ToS dei propri provider AI non per indignarsene ma per capire esattamente cosa il provider si rifiuta di garantire, perché quella lista è la mappa del rischio residuo che resta sulle spalle dell'integratore. Dovrebbe negoziare accordi contrattuali specifici sulla responsabilità prodotto prima del recepimento della PLD, perché dopo il potere negoziale sarà ancora minore. Dovrebbe documentare ogni processo di supervisione umana, ogni valutazione di rischio, ogni informativa al cliente, non perché questo elimini la responsabilità sotto la PLD ma perché in un'azione di regresso verso il provider la documentazione è l'unica arma disponibile. E dovrebbe porsi seriamente la domanda se l'integrazione di sistemi AI di terze parti in prodotti professionali sia sostenibile dal punto di vista assicurativo, perché oggi la maggior parte delle polizze RC professionale non copre i danni da output AI, e domani questa copertura sarà necessaria. Quando Microsoft scrive "for entertainment purposes only", non sta balbettando. Sta parlando in modo chiaro e deliberato. Sta dicendo che la responsabilità per qualsiasi uso professionale del suo prodotto non è sua. Sta dicendo che chi prende quel prodotto e lo vende come strumento affidabile lo fa interamente a proprio rischio. L'Europa ha costruito un framework normativo che in teoria tiene tutti responsabili. In pratica, tiene responsabili quelli che possono meno permetterselo. Il provider che ha scritto "for entertainment purposes only" sapendo perfettamente che nessuno lo avrebbe letto, che ha incassato trenta dollari a posto al mese sapendo perfettamente che il suo prodotto non era affidabile, quello ha ancora i suoi avvocati, le sue clausole, i suoi arbitrati internazionali. La prossima volta che qualcuno gli chiederà conto di quello che ha venduto, mostrerà di nuovo i Terms of Use. C'è scritto tutto. Basta leggere. --- # Gli Annales, o dell'impossibilità di una storia totale - **URL:** https://margiovanni.it/it/blog/gli-annales-o-dellimpossibilita-di-una-storia-totale/ - **Pubblicato:** 2026-04-05 - **Tag:** Annales, Epistemologia, Filosofia, Pensiero Critico - **Tempo di lettura:** 24 min > C’è un momento preciso in cui una rivoluzione intellettuale smette di essere tale e diventa ortodossia. C’è un momento preciso in cui una rivoluzione intellettuale smette di essere tale e diventa ortodossia. Per la scuola delle Annales quel momento è arrivato prima di quanto i suoi eredi vogliano ammettere, e il fatto che nel 2026 si continui a parlarne come di un progetto vivo, capace di rinnovarsi attraverso la storia globale e comparata, non è la prova della sua vitalità ma della sua capacità di mascherare una crisi epistemologica che dura da almeno quarant’anni. Quello che segue non è un tentativo di liquidare Bloch, Febvre o Braudel con una scrollata di spalle. Sarebbe disonesto e anche stupido. È piuttosto un’autopsia condotta su un paziente che tutti continuano a dichiarare in convalescenza, mentre i referti dicono altro. E va detto subito che l’autopsia è resa difficile dal fatto che la scuola delle Annales non è solo un progetto intellettuale: è un’istituzione, con la sua rivista, la sua Maison des sciences de l’homme, le sue cattedre all’EHESS, i suoi rituali di cooptazione, le sue reti internazionali. Criticare gli Annales, nella storiografia francese e in buona parte di quella europea, è un po’ come criticare la Chiesa a Roma: si può fare, ma il costo sociale è alto e i risultati sono incerti. Questo spiega almeno in parte perché le critiche più serie siano arrivate quasi sempre dalla periferia (l’Italia, la Germania, il mondo anglosassone) e quasi mai dal centro. Spiega anche perché il mio tentativo, condotto da qualcuno che non è uno storico di professione ma ha una formazione filosofica e un certo gusto per le demolizioni argomentate, abbia il vantaggio della distanza e lo svantaggio dell’incompletezza. Lo ammetto subito, perché il gioco va fatto a carte scoperte. ## L'intuizione fondativa di Bloch e Febvre Partiamo da dove la seduzione è più forte, perché è lì che bisogna guardare se si vuole capire dove le cose hanno cominciato a scricchiolare. Marc Bloch e Lucien Febvre fondano la rivista nel 1929 con un programma che, riletto oggi, conserva una forza innegabile: basta con la storia dei re e delle battaglie, basta con la narrazione événementielle che riduce il passato a una sequenza di fatti politici e diplomatici. La storia deve dialogare con la geografia, l’economia, la sociologia, l’antropologia. Deve occuparsi delle strutture profonde, dei tempi lunghi, delle mentalità collettive. Deve, in una parola, diventare totale. L’intuizione era genuina e rispondeva a un problema reale. La storiografia positivista dell’Ottocento si era effettivamente ridotta a un catalogo di eventi, e l’idea che esistessero forze più profonde a modellare le società umane era non solo legittima ma necessaria. Nessuno che abbia letto “I re taumaturghi” di Bloch o “Il problema dell’incredulità nel XVI secolo” di Febvre può negare la potenza di quello sguardo. Il problema non è mai stato l’intuizione. Il problema è stato cosa ne hanno fatto. ## Braudel e il vicolo cieco della longue durée Fernand Braudel pubblica “Il Mediterraneo e il mondo mediterraneo all’epoca di Filippo II” nel 1949, e con quel libro la scuola delle Annales trova il suo monumento e, insieme, il suo vicolo cieco. Braudel introduce la tripartizione temporale che diventerà il marchio di fabbrica della scuola: il tempo quasi immobile della geografia e del clima, il tempo lento delle strutture economiche e sociali, il tempo rapido degli eventi politici. La gerarchia è esplicita e non negoziabile. Il Mediterraneo è il protagonista, non Filippo II. Le correnti marine, i venti, le rotte commerciali, i cicli agricoli determinano il quadro entro cui gli esseri umani si muovono come figure secondarie di un dramma che li precede e li eccede. È un capovolgimento radicale. E funziona, almeno finché si resta dentro le pagine di Braudel, perché la sua prosa ha una forza che rende credibile quasi tutto. Ma cosa succede quando si esce dalla suggestione letteraria e si guarda il modello con occhi analitici? Succede che ci si trova davanti a un problema che Braudel non ha mai risolto e che i suoi eredi hanno preferito ignorare: se la longue durée è il livello esplicativo fondamentale, quale spazio resta per l’azione umana? La domanda non è retorica e non è banale. Paul Ricœur, in “Tempo e racconto”, la pone con una chiarezza che gli storici delle Annales non hanno mai eguagliato: il tempo della longue durée è un tempo senza soggetto, un tempo in cui le cose accadono ma nessuno le fa accadere. Braudel lo sapeva? Probabilmente sì, e probabilmente non gli importava. Nel suo schema la storia événementielle è “polvere”, la celebre espressione che liquida secoli di storiografia in una metafora sprezzante. Ma la polvere, a ben guardare, è fatta di persone che prendono decisioni, che agiscono, che sbagliano, che cambiano il corso degli eventi in modi che nessuna struttura profonda poteva prevedere. La scelta di Filippo II di lanciare l’Invincibile Armata nel 1588 non è spiegabile né dal regime dei venti mediterranei né dai cicli del prezzo del grano. È una decisione politica presa da un individuo specifico in un contesto specifico, e ha avuto conseguenze enormi. Relegare tutto questo a “polvere” non è un atto di rigore scientifico, è un atto di arroganza epistemologica. Il punto va spinto più a fondo, perché non riguarda solo Braudel. Riguarda un vizio logico che attraversa tutta la scuola. Se la struttura spiega più dell’evento, e se l’evento è “polvere”, allora il cambiamento storico diventa un problema insolubile. Le strutture, per definizione, sono ciò che persiste. Ma la storia è anche, forse soprattutto, ciò che cambia. Come si passa da una struttura all’altra? Braudel non lo dice, perché nel suo schema il passaggio avviene su tempi talmente lunghi da diventare quasi impercettibile, un movimento geologico che non ha bisogno di attori. Ma questo è credibile solo finché si sceglie di guardare i secoli dall’alto. Quando si scende al livello dove le persone vivono, decidono, si ribellano, inventano, il quadro braudeliano diventa inutilizzabile. La Rivoluzione francese, per fare l’esempio più ovvio, non è spiegabile in termini di longue durée. I fattori strutturali (crisi fiscale, trasformazioni sociali, circolazione delle idee illuministe) creano le condizioni, certo. Ma non spiegano perché nel luglio 1789 e non nel 1785 o nel 1793. Non spiegano perché con quelle forme e non con altre. Non spiegano Robespierre, che resta un individuo irriducibile a qualsiasi struttura. Marc Bloch, paradossalmente, era molto più attento a queste sfumature del suo successore. “La società feudale” è un libro strutturale, sì, ma Bloch non perde mai di vista i meccanismi concreti attraverso cui gli esseri umani costruiscono e riproducono le strutture in cui vivono. Con Braudel quel legame si spezza, e la scuola non è mai riuscita a riannodarlo. Si potrebbe obiettare che questa critica è vecchia, che è stata formulata mille volte, che gli stessi storici delle Annales l’hanno raccolta e metabolizzata. Ed è vero, l’hanno raccolta. Ma come? Qui il discorso si fa interessante, perché il modo in cui la scuola ha gestito le proprie crisi interne rivela molto più delle crisi stesse. ## Le mentalità come ritirata strategica La seconda generazione, quella di Braudel, regna sulla storiografia francese e in buona parte su quella internazionale dagli anni ’50 agli anni ‘70. Il modello è solido, le cattedre sono occupate, la rivista è il centro di gravità della disciplina. Poi, negli anni ‘70 e ‘80, arriva la terza generazione: Jacques Le Goff, Emmanuel Le Roy Ladurie, Georges Duby, e con loro il grande spostamento verso la storia delle mentalità. Non è un’evoluzione naturale, è una ritirata strategica. La longue durée braudeliana aveva mostrato i suoi limiti: troppo deterministica, troppo strutturale, troppo indifferente a tutto ciò che non fosse misurabile. La storia delle mentalità promette di recuperare la dimensione soggettiva senza abbandonare l’ambizione interdisciplinare. Si studiano le rappresentazioni collettive, le credenze, le paure, i sogni, le concezioni della morte e del tempo. È affascinante, per carità. “Montaillou, villaggio occitano” di Le Roy Ladurie è un libro straordinario, e le ricerche di Le Goff sul Purgatorio o sulla nascita dell’idea di tempo del mercante restano tra le cose migliori prodotte dalla storiografia del Novecento. Ma il prezzo pagato è alto, e nessuno lo dice con sufficiente chiarezza. Passare dalla longue durée alle mentalità non significa integrare i due approcci, significa abbandonare il primo perché non funzionava e adottarne un altro sperando che funzioni meglio. Il gesto ha qualcosa di familiare per chiunque abbia frequentato il mondo accademico: non è un cambio di paradigma nel senso kuhniano del termine (con crisi esplicita, anomalie riconosciute, sostituzione argomentata), è un cambio di argomento presentato come evoluzione. La differenza è cruciale. Un cambio di paradigma implica che il vecchio paradigma sia stato confutato o almeno seriamente messo in discussione. Un cambio di argomento implica solo che il vecchio argomento non tira più finanziamenti, non genera più tesi di dottorato, non riempie più i convegni. La storiografia delle Annales, dalla seconda alla terza generazione, assomiglia molto più alla seconda dinamica che alla prima. E le mentalità, a loro volta, pongono problemi enormi. Come si ricostruisce una “mentalità collettiva”? Su quali fonti? Con quale metodo? La risposta, nella pratica, è stata spesso: con molta creatività interpretativa e poca verificabilità. Geoffrey Lloyd, lo storico di filosofia antica e scienza di Cambridge, nel suo “Demystifying Mentalities” del 1990, ha messo in discussione la validità stessa del concetto di mentalità collettiva, argomentando che attribuire “mentalità” distinte a intere società o epoche è un’operazione intellettualmente fragile, che maschera la coesistenza di forme di pensiero diverse dentro ogni singola cultura. E non era il solo. La storia delle mentalità ha prodotto libri bellissimi, ma ha anche aperto la porta a un impressionismo storiografico che rendeva quasi impossibile distinguere tra ipotesi fondata e speculazione elegante. A questo punto qualcuno potrebbe fermarmi e dire: ma non è forse il destino di tutte le scienze umane? Non è forse inevitabile che la storia, occupandosi di esseri umani e non di particelle subatomiche, debba convivere con un margine irriducibile di incertezza interpretativa? Certo che sì. Ma c’è una differenza enorme tra riconoscere questa incertezza e farne un programma. Gli Annales, generazione dopo generazione, hanno trasformato l’incertezza metodologica in un principio di libertà epistemologica, il che è un modo elegante per dire che hanno cambiato metodo ogni volta che quello precedente si inceppava, senza mai ammettere che si era inceppato. Questa è la mossa che va smascherata, perché è la mossa che consente alla scuola di presentarsi come perpetuamente innovativa quando in realtà è perpetuamente in fuga. ## Il tournant critique e la dipendenza dalle scienze sociali Il passaggio successivo lo conferma. Negli anni ‘80 e ‘90 arriva quello che la stessa redazione degli Annales chiamerà il “tournant critique”, la svolta critica, consacrata da un numero speciale della rivista nel 1989 con contributi di Chartier, Lepetit e Revel. Stavolta la crisi è più profonda. Le mentalità hanno mostrato i loro limiti, la microstoria italiana (Ginzburg, Levi, Grendi) ha dimostrato che si possono fare cose straordinarie riducendo la scala anziché ampliandola, l’antropologia di Clifford Geertz ha imposto l’idea della “descrizione densa” che mette in discussione le grandi sintesi. La scuola delle Annales risponde come sa fare: cambiando paradigma. Si passa alla storia culturale, alle “pratiche” e alle “rappresentazioni”, a un dialogo sempre più stretto con la sociologia di Bourdieu e l’ermeneutica. Bernard Lepetit, prima della sua morte prematura nel 1996, tenta una rifondazione teorica che prende molto seriamente le obiezioni, ma il tentativo resta incompiuto e, soprattutto, resta minoritario all’interno della stessa scuola. La rivista cambia nome nel 1994, da “Annales. Économies, Sociétés, Civilisations” a “Annales. Histoire, Sciences sociales”, e il cambio è sintomatico: si riafferma il legame con le scienze sociali proprio nel momento in cui quel legame è più problematico che mai, quasi a voler mascherare con un gesto simbolico una crisi che è sostanziale. Jacques Revel, in quel periodo, propone la nozione di “jeux d’échelles”, il gioco di scale tra micro e macro, come via d’uscita dall’impasse. L’idea è suggestiva: anziché scegliere tra la longue durée braudeliana e il caso singolo della microstoria, si dovrebbe essere in grado di passare da una scala all’altra, mostrando come i fenomeni cambiano aspetto a seconda del livello di osservazione. Ma il suggerimento, per quanto intelligente, resta programmatico. Nessuno, nella pratica, è riuscito a produrre un lavoro che integri davvero le diverse scale in modo coerente. Si salta dall’una all’altra, si giustappone, si accosta, ma l’integrazione resta un desiderio. E forse non potrebbe essere altrimenti, perché le diverse scale non sono semplici zoom diversi sulla stessa realtà: sono modi diversi di costruire l’oggetto storico, e non è detto che siano compatibili. E qui bisogna essere onesti, onesti fino in fondo. Il fatto che una tradizione intellettuale attraversi crisi e si rinnovi non è di per sé un problema. Tutte le tradizioni serie lo fanno. Il problema sorge quando il rinnovamento diventa un meccanismo di sopravvivenza istituzionale anziché intellettuale, quando il cambio di paradigma serve a mantenere le posizioni accademiche, il controllo sulla rivista, l’egemonia sulle cattedre, più che a rispondere a domande genuine. La storia della scuola delle Annales, vista da questa angolazione, è anche una storia di potere accademico francese, e non è un caso che le critiche più feroci siano arrivate spesso dall’esterno: dalla microstoria italiana, dalla storia sociale britannica, dalla Alltagsgeschichte tedesca, dalla storiografia postcoloniale anglosassone. L’accusa, formulata in modi diversi ma con una coerenza impressionante, è sempre la stessa: gli Annales pretendono di offrire un metodo universale, ma quello che offrono è in realtà una sensibilità francese elevata a paradigma globale, con tutti i punti ciechi che questo comporta. Questo ci porta alla questione più profonda, quella che stava lì fin dall’inizio come un difetto strutturale nel progetto stesso. L’histoire totale, la storia totale: il sogno fondativo di Bloch e Febvre, l’orizzonte verso cui ogni generazione ha dichiarato di muoversi, anche quando si muoveva in direzioni opposte. L’idea che sia possibile, e anzi doveroso, scrivere una storia che integri tutti i livelli dell’esperienza umana, dal clima alla preghiera, dal prezzo del grano alle strutture familiari, dalla tecnologia alle emozioni. È un programma magnifico. Ed è un programma impossibile, non per ragioni pratiche ma per ragioni logiche. Ogni atto storiografico è un atto di selezione. Scegliere di studiare il Mediterraneo nel XVI secolo significa non studiare il Baltico. Scegliere la longue durée significa non scegliere l’evento. Scegliere le mentalità collettive significa non scegliere le strategie individuali. Queste scelte non sono accidentali, sono costitutive: definiscono cosa conta come fatto storico e cosa no, cosa merita spiegazione e cosa può essere ignorato. Una storia totale richiederebbe l’assenza di qualsiasi criterio di selezione, il che equivale all’assenza di qualsiasi metodo, il che equivale a non fare storia. Hayden White, con il suo “Metahistory” del 1973, ha mostrato che anche le grandi opere storiografiche sono strutturate da tropi narrativi che ne determinano la forma e, inevitabilmente, il contenuto. Braudel non descrive il Mediterraneo: lo racconta, e lo racconta secondo una logica narrativa che seleziona, ordina, gerarchizza. La pretesa di totalità è esattamente questo, una pretesa, e il fatto che venga mantenuta come orizzonte regolativo non la rende meno incoerente. La rende solo più difficile da criticare, perché chi osa dire che il re è nudo si sente rispondere che la totalità è un ideale, non un risultato, e che il valore sta nel tendere verso di essa. Ma un ideale logicamente impossibile non è un orizzonte, è un miraggio. E qui vale la pena fare un passo indietro filosofico, perché la questione tocca il cuore di cosa significa fare scienza del particolare. Aristotele distingueva tra episteme (la conoscenza del generale e del necessario) e phronesis (la conoscenza del particolare e del contingente). La storia, per Aristotele, non era nemmeno una forma di conoscenza nel senso pieno del termine, perché si occupava di ciò che è accaduto una volta sola e non poteva quindi produrre leggi generali. Gli Annales hanno tentato, in un certo senso, di trasformare la storia da dominio della phronesis a dominio dell’episteme: di estrarre dal particolare il generale, dall’evento la struttura, dal contingente il necessario. Braudel ci è quasi riuscito, ma solo perché ha scelto oggetti di studio (il Mediterraneo, il capitalismo, la civiltà materiale) talmente ampi da rendere plausibile la generalizzazione. Quando si scende di scala, quando si torna al particolare, il programma si dissolve, e la scuola si ritrova puntualmente a fare i conti con il fantasma di Aristotele. Si potrebbe tentare di salvare il progetto ricorrendo a una versione debole della totalità: non la storia di tutto, ma una storia che tenga conto di più dimensioni possibili, che sia consapevole della propria parzialità ma aspiri all’integrazione. È una posizione ragionevole, e probabilmente è quella che molti storici delle Annales, posti di fronte all’obiezione, adotterebbero. Ma è anche una posizione che svuota il programma originario di qualsiasi contenuto specifico. Se la storia totale significa semplicemente “fare storia in modo aperto e interdisciplinare”, allora non è un programma, è un’attitudine, e un’attitudine non fonda una scuola, non giustifica sessant’anni di egemonia istituzionale, non merita di essere trattata come una rivoluzione epistemologica. C’è un altro problema, forse il più insidioso, e riguarda il rapporto degli Annales con le scienze sociali. L’interdisciplinarità è stata il cavallo di battaglia fin dalla fondazione. Storia e geografia, storia e economia, storia e sociologia, storia e antropologia, storia e psicologia collettiva: ogni generazione ha aggiunto un interlocutore privilegiato, e ogni generazione ha presentato questo dialogo come la prova della modernità e della scientificità della scuola. Ma cosa succede quando una disciplina si definisce sistematicamente per ciò che importa dalle altre? Succede che perde il proprio centro. Non il proprio “metodo” in senso stretto, perché la storia non ha mai avuto un metodo unico e probabilmente non ne ha bisogno. Ma qualcosa di più sottile e più importante: la consapevolezza di cosa sia specificamente storico in un’indagine storica. Quando Braudel importa la geografia, il risultato è una storia che assomiglia molto a della geografia con una dimensione temporale. Quando Le Goff importa l’antropologia, il risultato è spesso un’antropologia applicata al passato. Quando la quarta generazione importa la sociologia di Bourdieu, ottiene una sociologia storicizzata. In ciascuno di questi casi il dialogo interdisciplinare non è simmetrico: è la storia che cede terreno, non le altre discipline. E il motivo è semplice: le altre discipline hanno strutture teoriche più forti. L’economia ha modelli formali, la sociologia ha apparati concettuali consolidati, l’antropologia ha la sua tradizione etnografica. La storia, per come la concepiscono gli Annales, dovrebbe integrare tutto questo senza disporre di un quadro teorico proprio altrettanto robusto. Il risultato è un eclettismo che viene spacciato per apertura mentale ma che, nella pratica, produce una vulnerabilità strutturale: ad ogni cambio di moda nelle scienze sociali, gli Annales cambiano interlocutore e, con esso, metodo, domande, oggetti di studio. Non è interdisciplinarità, è dipendenza. E la dipendenza produce un effetto secondario ancora più grave: la perdita di competenza tecnica. Quando Braudel dialogava con Wallerstein, entrambi padroneggiavano la teoria economica a un livello sufficiente per il dialogo. Ma già con la terza generazione il rapporto diventa asimmetrico. Gli storici delle mentalità importano concetti dall’antropologia (la “mentalità primitiva” di Lévy-Bruhl, poi corretta, le strutture di parentela di Lévi-Strauss, i rituali di Van Gennep) senza sempre possedere la formazione tecnica per valutarne la solidità nel contesto originario. Il risultato è che concetti nati per descrivere società contemporanee vengono proiettati su società del passato con aggiustamenti minimi e giustificazioni insufficienti. Quando il “Carnaval de Romans” di Le Roy Ladurie viene letto attraverso la lente bachtiniana del carnevale come rovesciamento sociale (e la tentazione è forte, dato che si parla letteralmente di un carnevale del 1580 finito in massacro), il risultato è brillante ma metodologicamente fragile: Bachtin non era un antropologo, il suo “carnevalesco” è una categoria letteraria, e applicarla a un evento storico specifico richiede una catena di mediazioni che né il testo né i suoi interpreti esplicitano mai del tutto. Non è un caso isolato. È un pattern che si ripete ogni volta che la scuola cambia interlocutore disciplinare: il periodo di luna di miele produce lavori entusiasmanti, poi le crepe emergono, poi si cambia interlocutore. Fernand Braudel, con la sua idea di “economia-mondo”, prendeva da Immanuel Wallerstein almeno quanto gli dava. La storia delle mentalità nasceva all’ombra dell’antropologia strutturale di Lévi-Strauss. La svolta culturale degli anni ‘90 era impensabile senza Bourdieu e senza Geertz. La storia globale che oggi viene presentata come l’ultimo avatar degli Annales deve quasi tutto alla world history anglosassone di Kenneth Pomeranz, Sanjay Subrahmanyam e Christopher Bayly. In ciascuno di questi passaggi la scuola ha funzionato più come ricevitore che come emittente, più come adattatore di paradigmi altrui che come generatore di paradigmi propri. E questo non sarebbe necessariamente un problema se venisse riconosciuto. Diventerebbe anzi una qualità: la capacità di mediare, tradurre, ibridare. Ma non è così che la scuola si racconta. La scuola si racconta come il luogo dove si produce innovazione storiografica, e questa narrazione è sempre meno credibile. Mi si potrebbe obiettare che sto applicando un criterio impossibile, che sto chiedendo alla storia di avere una struttura teorica paragonabile a quella delle scienze naturali, e che questo è un errore categoriale. L’obiezione ha un certo peso, ma manca il bersaglio. Non sto chiedendo alla storia di avere leggi universali o modelli predittivi. Sto chiedendo qualcosa di molto più modesto: che una scuola storiografica sia in grado di formulare con chiarezza i propri criteri di validazione. Come si distingue un buon lavoro annalista da uno cattivo? Come si decide se un’interpretazione è fondata o no? Come si falsifica, o almeno si mette seriamente alla prova, una tesi sulla mentalità medievale o sulla struttura del commercio mediterraneo? La risposta, nella pratica, è stata affidata al giudizio dei pari, il che in una comunità scientifica sana funziona ragionevolmente bene ma in una scuola con una forte identità istituzionale e un meccanismo di cooptazione consolidato diventa un circolo vizioso. I criteri di qualità li stabilisce la scuola, li applica la scuola, li verifica la scuola. Karl Popper non avrebbe faticato a riconoscere il pattern. Ma anche senza scomodare Popper, basta guardare i fatti. Quanti lavori prodotti sotto l’ombrello delle Annales sono stati seriamente confutati dall’interno? Quante tesi di Braudel sulla civiltà materiale sono state sottoposte a revisione critica dai suoi eredi? La risposta è: pochissime, e quasi mai in modo frontale. Le critiche arrivano sempre dall’esterno, vengono assorbite, rielaborate, digerite, e il risultato è sempre lo stesso: la scuola si trasforma quel tanto che basta per sopravvivere, ma non abbastanza da mettere in discussione le proprie fondamenta. È un meccanismo di autoconservazione perfetto, ed è esattamente l’opposto di ciò che una tradizione scientifica seria dovrebbe fare. ## La microstoria come critica radicale E non è un caso che la microstoria italiana sia nata in parte come reazione a questa chiusura. Quando Carlo Ginzburg ricostruisce il cosmo di Menocchio in “Il formaggio e i vermi”, non sta facendo una storia totale in miniatura, sta facendo qualcosa di radicalmente diverso: sta dimostrando che un singolo caso, studiato con rigore filologico e sensibilità interpretativa, può aprire finestre su strutture culturali profonde senza bisogno di quadri sintetici grandiosi. La scala cambia tutto, perché cambia il rapporto con la fonte, con la prova, con la verificabilità. Dove Braudel poteva permettersi di generalizzare su interi secoli e interi bacini marittimi, Ginzburg deve rendere conto di ogni singolo documento, di ogni singola parola pronunciata da Menocchio davanti all’Inquisizione. Questa costrizione non è un limite, è una disciplina, nel senso più nobile del termine. La microstoria dice: non posso sapere tutto, ma quello che so lo so davvero, e posso mostrare come lo so. Gli Annales, nelle loro versioni più ambiziose, dicono il contrario: possiamo sapere tutto, o almeno aspirare a farlo, e il metodo per arrivarci è la sintesi interdisciplinare. La storia ha dato ragione ai primi, non ai secondi. Giovanni Levi, in “L’eredità immateriale”, fa lo stesso: parte da un villaggio piemontese e arriva a ripensare le strategie familiari dell’ancien régime senza mai pretendere di star descrivendo la totalità. La microstoria non è una variante degli Annales, è una critica degli Annales, e il fatto che Le Goff e altri abbiano cercato di annetterla al proprio progetto (“ma anche noi facciamo attenzione ai dettagli, anche noi studiamo casi particolari”) è l’ennesima dimostrazione della capacità della scuola di fagocitare ciò che la minaccia. Lo stesso si può dire, mutatis mutandis, della Alltagsgeschichte tedesca di Alf Lüdtke e Hans Medick, della history from below britannica di E.P. Thompson e di tutta la tradizione postcoloniale che, da Edward Said in poi, ha posto una domanda alla quale gli Annales non hanno mai risposto in modo convincente: la vostra storia totale di chi è totale? Del Mediterraneo di Braudel? Dell’Europa occidentale di Le Goff? Della Francia profonda di Le Roy Ladurie? Il provincialismo geografico della scuola è stato a lungo mascherato dall’universalismo del metodo, ma quando storici come Dipesh Chakrabarty hanno iniziato a “provincializzare l’Europa” nel senso tecnico del termine, cioè a mostrare che le categorie analitiche della storiografia europea non sono universali ma storicamente situate, il gioco si è fatto molto più difficile. La “Histoire mondiale de la France” lo dimostra involontariamente: un libro che si propone di raccontare la Francia attraverso le sue connessioni globali ma che, proprio per questo, finisce per ribadire la centralità della Francia come punto di osservazione. La decentrazione è apparente. Il Mediterraneo di Braudel era già, a ben guardare, un Mediterraneo visto da Parigi, e la storia globale degli Annales contemporanei rischia di essere una storia globale vista dalla stessa finestra, con un grandangolo più ampio ma lo stesso identico punto di fuga. La risposta della scuola, negli ultimi due decenni, è stata la storia globale e connessa. Patrick Boucheron, Serge Gruzinski, Sanjay Subrahmanyam (che però non è propriamente un annalista, e ci tiene a farlo notare) hanno allargato lo sguardo al mondo intero, alle connessioni tra civiltà, ai flussi di persone, merci, idee attraverso i continenti. L’operazione è intellettualmente stimolante, e “Histoire mondiale de la France” curata da Boucheron nel 2017 è un libro che vale la pena leggere. Ma bisogna chiedersi: cosa c’è di specificamente annalista in tutto questo? La world history esisteva prima, esisteva altrove, e la versione degli Annales non si distingue per un metodo proprio ma, ancora una volta, per un’attitudine. Si fa storia globale con sensibilità annalista, il che vuol dire, concretamente, che si fa storia globale prestando attenzione ai tempi lunghi e ai fenomeni strutturali. È un contributo? Forse. È sufficiente a giustificare la pretesa di essere ancora una scuola con un programma riconoscibile? Ne dubito. E il dubbio si fa certezza quando si guarda alla produzione concreta. La rivista “Annales” oggi pubblica articoli di qualità variabile su temi enormemente disparati: storia del diritto islamico, storia economica del Giappone Tokugawa, storia ambientale dell’Amazzonia, storia delle emozioni nella prima modernità. La varietà è impressionante, ma cosa tiene insieme questi lavori se non il fatto di essere pubblicati sulla stessa rivista? Qual è il filo conduttore metodologico, il nucleo duro che distingue un articolo “annalista” da un articolo pubblicato su “Past and Present” o su “Quaderni storici”? La risposta onesta è: nessuno. O meglio: una certa attenzione alle strutture, una certa diffidenza verso la storia politica tradizionale, una certa propensione al dialogo interdisciplinare. Ma “una certa attenzione” e “una certa propensione” non sono un metodo. Sono, appunto, un’attitudine. E un’attitudine che nel 2026 è patrimonio comune di qualsiasi storico serio, annalista o meno, il che rende la specificità della scuola ancora più evanescente. E qui arriviamo al punto che mi sta più a cuore, quello che lega tutti i fili. Il problema degli Annales non è un singolo errore, non è la longue durée in sé, non è l’interdisciplinarità in sé, non è la storia totale in sé. Il problema è la combinazione di questi tre elementi in un progetto che non è mai stato in grado di rendere conto della propria coerenza interna. La longue durée richiedeva un’epistemologia determinista che la storia delle mentalità ha abbandonato. L’interdisciplinarità richiedeva un quadro teorico integrativo che non è mai stato prodotto. La storia totale richiedeva criteri di selezione che la sua stessa definizione esclude. Ciascuno di questi elementi, preso singolarmente, contiene intuizioni preziose. Messi insieme, producono un programma internamente contraddittorio che sopravvive solo grazie alla vaghezza dei propri princìpi e alla forza delle proprie istituzioni. Questo non significa che gli storici delle Annales non abbiano prodotto lavori eccellenti. Li hanno prodotti, e molti di quei lavori restano imprescindibili. Ma li hanno prodotti non grazie al programma della scuola, bensì nonostante quel programma, o più precisamente sfruttandone selettivamente gli aspetti utili e ignorando il resto. Braudel è grande non perché applica la longue durée in modo coerente ma perché è un narratore formidabile. Le Goff è grande non perché la storia delle mentalità sia un metodo solido ma perché la sua erudizione e la sua immaginazione storica sono fuori dal comune. Ginzburg, che la scuola ha cercato di cooptare, è grande proprio perché ha rifiutato il programma annalista e ne ha proposto uno alternativo. Resta la domanda con cui ho aperto, e con cui è giusto chiudere. Gli Annales hanno fallito? La risposta dipende da cosa si intende per fallimento. Se si intende che la scuola non ha mantenuto le sue promesse, che il programma di una storia totale, interdisciplinare e scientificamente fondata si è rivelato irrealizzabile, allora sì, hanno fallito. Ma forse il fallimento più significativo non è il loro, è quello del sogno che li ha generati: l’idea, profondamente radicata nell’illuminismo e rilanciata dal positivismo ottocentesco, che la storia possa diventare una scienza nel senso pieno del termine, con leggi generali, metodi riproducibili e capacità esplicativa cumulativa. Gli Annales hanno tentato questa impresa con più ambizione, più talento e più risorse istituzionali di chiunque altro nel Novecento. Il fatto che non ci siano riusciti non dice nulla contro la loro intelligenza. Dice qualcosa, forse, sulla natura della conoscenza storica, che resiste alla sistematizzazione non per un difetto superabile ma per una caratteristica costitutiva. La storia non è fisica, non è biologia, non è nemmeno economia. Non lo è perché il suo oggetto non è un sistema ma un processo, e un processo il cui senso è retroattivamente costruito da chi lo osserva. La storia è il racconto che gli esseri umani fanno di se stessi, e quel racconto è necessariamente parziale, situato, contestabile. Volerlo rendere totale è come voler fotografare la luce: lo strumento che usi è parte di ciò che stai cercando di catturare. Gli Annales lo hanno scoperto a proprie spese, e il fatto che continuino a non ammetterlo è forse la critica più dura che si possa muovere loro. ## Oltre la totalità Non è un caso, forse, che le tradizioni storiografiche più vitali degli ultimi decenni siano state quelle che hanno rinunciato esplicitamente alla totalità. La microstoria ha scelto la scala ridotta e la densità analitica. La storia orale ha scelto la voce individuale. La storia digitale sta sperimentando con la quantificazione senza pretendere che i numeri esauriscano il senso. Persino la storia globale più interessante, quella di Subrahmanyam per esempio, funziona perché segue connessioni specifiche anziché disegnare affreschi omnicomprensivi. In ciascuno di questi approcci c’è qualcosa che gli Annales avevano intuito (l’importanza delle strutture, il dialogo con altre discipline, l’attenzione ai tempi lunghi) ma depurato dalla hybris sistematica, dalla pretesa che tutto si tenga, che il cerchio si chiuda. Il cerchio non si chiude mai, in storia. Ed è proprio questa incompletezza a rendere la disciplina interessante, non nonostante i suoi limiti epistemologici ma grazie a essi. Gli Annales, nella loro versione più ambiziosa, non l’hanno mai accettato. E questa incapacità di accettare il limite è, alla fine, il loro limite più grande. --- # Il punto cieco dell'advisory: cosa sa un fornitore IT che un analista non sa - **URL:** https://margiovanni.it/it/blog/il-punto-cieco-delladvisory-cosa-sa-un-fornitore-it-che-un-analista-non-sa/ - **Pubblicato:** 2026-03-30 - **Tag:** AI Act, Compliance, Cyber Resilience Act, Governance - **Tempo di lettura:** 6 min > Qualche settimana fa ho ricevuto un report di una nota società di advisory che valutava il mercato dei servizi IT nel nostro segmento. Qualche settimana fa ho ricevuto un report di una nota società di advisory che valutava il mercato dei servizi IT nel nostro segmento. L'ho letto con attenzione, perché i miei clienti leggono queste cose prima di decidere con chi lavorare. Il report era ben scritto, le analisi di mercato erano solide, i trend identificati erano corretti. Eppure, mentre lo leggevo, continuavo a pensare: chi ha scritto questo non ha mai consegnato un progetto software a un cliente della pubblica amministrazione italiana. Non ha mai negoziato un SLA con un ufficio acquisti che non sa cosa sia un SLA. Non ha mai spiegato a un dirigente sanitario perché il suo sistema legacy non può semplicemente "essere aggiornato" senza rifare l'intera integrazione con il sistema informativo regionale. Non è una critica. È un'osservazione su un punto cieco strutturale del mercato dell'advisory IT. Le persone che consigliano alle aziende come comprare tecnologia, nella stragrande maggioranza dei casi, tecnologia non ne hanno mai venduta. E le persone che vendono e consegnano tecnologia non hanno voce nel modo in cui il mercato dell'advisory definisce le best practice di sourcing. Il risultato è un gap informativo che costa denaro reale a chi compra e a chi vende. Lo dico con cognizione di causa. Gestisco una piccola azienda ICT che vive di contratti con clienti mid-market e pubblica amministrazione. Ho scritto preventivi, negoziato contratti, definito SLA, gestito escalation, subito penali, consegnato progetti in ritardo e progetti in anticipo. Ho visto il mercato dei servizi IT dal lato del tavolo che gli analisti di sourcing raramente vedono. E quello che vedo non sempre corrisponde a quello che i framework di advisory descrivono. ## Primo punto cieco: il pricing {: #pricing-blind-spot } La maggior parte dei framework di advisory valuta i fornitori IT in base al costo per giornata-uomo o al costo per punto funzione. Sono metriche comprensibili, comparabili, e fondamentalmente obsolete. Il problema è che l'AI sta rendendo la relazione tra tempo di lavoro e valore consegnato completamente non lineare. Un team di cinque persone che usa coding agentico può consegnare in una settimana quello che un team di quindici persone consegnava in un mese. Il valore per il cliente è identico. Il costo in giornate-uomo è un quinto. Se il cliente paga a giornate-uomo, il fornitore ha un incentivo perverso a non adottare l'AI, perché fattura meno. Se il fornitore adotta l'AI e il cliente continua a valutare per giornate-uomo, il fornitore sembra cinque volte più costoso per giornata anche se il costo totale del progetto è inferiore. Questo non è un problema teorico. È un problema che affronto ogni mese quando presento preventivi. Ho smesso di quotare a giornate-uomo più di un anno fa. Quoto a deliverable: questo è il risultato, questo è il prezzo, queste sono le condizioni. Alcuni clienti lo apprezzano. Altri — soprattutto nella PA, dove i bandi sono strutturati attorno alle giornate-uomo — non sanno come gestirlo. Il framework di acquisto non prevede un fornitore che consegna più valore in meno tempo. ## Secondo punto cieco: la compliance come criterio di sourcing {: #compliance-as-sourcing-criterion } I framework di advisory stanno iniziando ad aggiungere la compliance normativa come criterio di valutazione dei fornitori. Ma la aggiungono come checkbox: "Il fornitore è GDPR compliant? Sì/No." Questo è radicalmente insufficiente. La compliance non è una proprietà binaria. È uno spettro. Un fornitore può avere una privacy policy sul sito web e non avere nessun meccanismo tecnico di data minimization nel codice. Può dichiarare di essere AI Act compliant senza avere idea di cosa sia una valutazione di rischio per sistemi AI ad alto rischio. Può spuntare la casella SBOM senza avere una pipeline che genera SBOM automaticamente ad ogni build. Un framework di sourcing serio, nel contesto normativo europeo di oggi, dovrebbe valutare la compliance non come dichiarazione ma come capacità tecnica. Il fornitore ha un processo documentato di vulnerability handling? La sua pipeline CI/CD include scansione delle dipendenze? I suoi SBOM sono generati automaticamente o compilati a mano? Il suo software ha test automatici che verificano le proprietà di privacy? Queste domande sono più rivelatrici di qualsiasi certificazione. E sono domande che solo chi ha esperienza operativa nella delivery sa formulare. ## Terzo punto cieco: le PMI IT {: #it-smes-blind-spot } Il mercato dell'advisory è strutturato attorno ai grandi system integrator. Le matrici di valutazione, i Magic Quadrant, le Wave, i Provider Lens — tutti questi strumenti sono calibrati su aziende che fatturano centinaia di milioni. Le PMI IT — che in Europa rappresentano la stragrande maggioranza dei fornitori di servizi software — sono invisibili in questi framework. Non perché non consegnino valore, ma perché non hanno la scala per partecipare ai processi di valutazione degli analisti. Questo crea un paradosso. Il cliente mid-market — l'azienda da 200-500 dipendenti, la ASL, il Comune, la Camera di Commercio — legge i report degli analisti e vede solo grandi nomi. Ma i grandi nomi non servono il mid-market italiano, o lo servono con team junior supervisionati da un partner che non si vede mai. Il fornitore che effettivamente consegna il lavoro — la PMI locale con dieci persone, un senior per progetto, e una relazione diretta con il decisore — non compare in nessun framework. Il gap informativo è totale. ## Quarto punto cieco: la governance dei contratti {: #contract-governance-blind-spot } I framework di advisory sono molto bravi a valutare la fase di selezione del fornitore: come scegliere, come comparare, come negoziare. Sono molto meno bravi a valutare la fase di esecuzione: come monitorare, come intervenire quando le cose vanno male, come gestire il cambiamento di scope. E nella mia esperienza, il 90% dei problemi nei progetti IT non nasce dalla scelta sbagliata del fornitore. Nasce dalla gestione sbagliata del contratto dopo che il fornitore è stato scelto. Ho visto progetti fallire non perché il fornitore fosse incompetente, ma perché il cliente non aveva una governance interna capace di prendere decisioni sui cambiamenti di requisito. Ho visto SLA negoziati al centesimo che nessuno monitorava. Ho visto penali contrattuali che non venivano mai applicate perché il cliente dipendeva troppo dal fornitore per permettersi di multarlo. Questi sono pattern ricorrenti che qualsiasi fornitore IT conosce intimamente e che i framework di advisory trattano come eccezioni. ## Quinto punto cieco: qualità tecnica e business {: #technical-quality-and-business } Forse è il più profondo: la relazione tra qualità tecnica e risultato di business. I framework di advisory valutano i fornitori su dimensioni come prezzo, track record, dimensione del team, certificazioni. Raramente valutano la qualità tecnica del software che producono. Quanti test automatici ha il codebase? Qual è la coverage? Come è strutturata l'architettura? Il codice è manutenibile? La documentazione è aggiornata? Queste sono le dimensioni che determinano il costo totale di proprietà del software — il TCO reale, non quello dichiarato — e sono dimensioni che gli analisti di sourcing non sono equipaggiati a valutare. Il risultato è che il mercato premia la capacità di vendere — presentazioni convincenti, referenze solide, team numerosi — piuttosto che la capacità di costruire. E questo spiega perché tanti progetti IT costano il doppio del previsto e consegnano la metà del promesso: la selezione avviene su criteri che non predicono la qualità dell'esecuzione. Scrivo queste cose non per il piacere di criticare un settore che rispetto e che, francamente, mi interessa. Le scrivo perché credo che il mercato dell'advisory IT sia a un punto di inflessione. L'AI sta cambiando l'economia della delivery. La compliance europea sta cambiando i criteri di acquisto. Il mid-market europeo ha bisogno di framework di valutazione che non siano versioni semplificate di quelli enterprise. E i fornitori IT — quelli che effettivamente costruiscono e consegnano il software — hanno un sapere operativo che, se integrato nei framework di advisory, li renderebbe molto più utili. Non pretendo di avere la soluzione. Ma dopo quindici anni dall'altra parte del tavolo, so quali domande andrebbero fatte e non vengono fatte. So quali metriche predicono il successo di un progetto e quali predicono solo la qualità della presentazione iniziale. So cosa cambia nel pricing quando l'AI entra nel ciclo di delivery. So cosa significa compliance in un codebase di produzione, non in un documento di policy. Questa è conoscenza che il mercato dell'advisory non ha, non perché sia incompetente, ma perché è strutturalmente separato dal mondo della delivery. E forse è il momento di costruire un ponte. --- # L'incompetenza come condizione strutturale del presente - **URL:** https://margiovanni.it/it/blog/lincompetenza-come-condizione-strutturale-del-presente/ - **Pubblicato:** 2026-03-28 - **Tag:** Complessità, Epistemologia, Filosofia Della Tecnica, Regolamentazione Europea - **Tempo di lettura:** 12 min > Nessuno sa cosa sta facendo. Non nel senso banale e un po' autoassolutorio che si usa nelle conversazioni tra colleghi, quando qualcuno alza le spalle e dice che improvvisiamo tutti. Nessuno sa cosa sta facendo. Non nel senso banale e un po' autoassolutorio che si usa nelle conversazioni tra colleghi, quando qualcuno alza le spalle e dice che improvvisiamo tutti. In un senso più preciso, più inquietante, e soprattutto più strutturale: la complessità degli oggetti tecnici che abbiamo costruito ha superato la capacità di qualsiasi singolo essere umano di comprenderli. Non per difetto di intelligenza o di formazione. Per una ragione che ha a che fare con la natura stessa di questi oggetti. Per la maggior parte della storia della tecnica, era possibile trovare almeno una persona che capisse un artefatto nella sua interezza. L'acquedotto romano, il telaio meccanico, la locomotiva a vapore, persino un aereo della seconda guerra mondiale: sistemi complicati, certamente, ma in ultima analisi riconducibili a un sapere unitario. Un ingegnere sufficientemente preparato poteva tracciare la catena causale da un capo all'altro. Poteva dire: so come funziona, so perché funziona, so cosa succede se si rompe. Questa possibilità non era un dettaglio. Era il fondamento su cui poggiava l'idea stessa di competenza tecnica, e insieme a lei l'idea di responsabilità. Quel fondamento non c'è più. ## La soglia {: #la-soglia } Il punto di rottura non è stato improvviso. Si è accumulato lungo decenni, invisibile come tutti i cambiamenti che avvengono per stratificazione anziché per frattura. Ogni strato di astrazione aggiunto sopra il precedente risolveva un problema e ne creava un altro: rendeva il livello sottostante opaco. Il programmatore che scrive codice applicativo oggi non conosce davvero il framework che usa. Chi conosce il framework non conosce il runtime. Chi conosce il runtime non conosce il sistema operativo, non fino in fondo. Chi conosce il sistema operativo non conosce il microcodice del processore. E nessuno, proprio nessuno, conosce l'intera catena di dipendenze che un singolo comando di installazione scarica dalla rete e rende parte del proprio software. Questo non è un'esagerazione polemica. È una descrizione fattuale. Un progetto software medio, nel 2026, include centinaia di dipendenze dirette e migliaia di dipendenze transitive. Ciascuna di queste è stata scritta da qualcun altro, con le proprie dipendenze, le proprie vulnerabilità, le proprie decisioni architetturali prese in un contesto che nessun utilizzatore a valle ricostruirà mai. Eseguire software oggi significa fidarsi. Non nel senso nobile della fiducia tra persone, ma nel senso epistemologico di chi rinuncia a verificare perché la verifica è materialmente impossibile. C'è stata un'epoca in cui la parola "ingegnere" implicava la possibilità di un controllo totale sul proprio oggetto di lavoro. Quell'epoca è finita. Non tornerà. ## Il sapere come illusione di scala {: #il-sapere-come-illusione-di-scala } Il problema non è che sappiamo poco. È che il tipo di sapere che possediamo non è commisurato alla complessità di ciò che operiamo. Sappiamo cose, certo. Sappiamo anche molte cose. Ma il sapere che serve per comprendere un sistema distribuito moderno non è la somma dei saperi individuali: è un sapere che richiederebbe una mente capace di tenere insieme simultaneamente strati che per loro natura sono progettati per essere separati. L'astrazione, che è il meccanismo fondamentale del pensiero computazionale, funziona proprio perché nasconde. È il suo merito e la sua trappola. Un'interfaccia ben progettata ti libera dal bisogno di sapere cosa succede sotto. Ma quando qualcosa va storto, quando un sistema si comporta in modo imprevisto, scopri che "sotto" c'è un mondo che nessuno nella stanza conosce, e che forse nessuno al mondo conosce nella sua interezza. Non perché il sapere non esista, ma perché è distribuito in modo irrecuperabile tra migliaia di persone che non si sono mai parlate. È una condizione epistemologica nuova. Non ha precedenti nella storia della tecnica, e ne ha pochi nella storia del pensiero. Il più vicino è forse il problema della divisione del lavoro così come lo descriveva Adam Smith, ma con una differenza sostanziale: Smith parlava di un processo produttivo in cui ogni operaio capiva il proprio pezzo. Qui nessuno capisce davvero nemmeno il proprio pezzo, perché il proprio pezzo poggia su altri pezzi che sfuggono per definizione. ## La catena spezzata della responsabilità {: #la-catena-spezzata-della-responsabilita } Se nessuno comprende il sistema nella sua interezza, la domanda su chi sia responsabile non ha una risposta soddisfacente. Non perché manchino candidati, ma perché il concetto stesso di responsabilità presuppone qualcosa che qui manca: la possibilità di sapere. Responsabilità, nella sua radice, significa capacità di rispondere. Di dare conto delle proprie scelte. Ma come si dà conto di una scelta fatta in un contesto che non si poteva comprendere per intero? Come si risponde di un sistema il cui comportamento emerge da interazioni tra componenti che nessun singolo attore ha progettato né previsto? Il diritto, che su questo ha riflettuto molto più dell'informatica, ha sviluppato nel tempo l'idea di diligenza: non serve capire tutto, basta agire con la cura ragionevolmente attesa da chi svolge quel ruolo. È un compromesso pragmatico e per molti secoli ha funzionato. Ma funzionava perché la distanza tra ciò che si poteva sapere e ciò che si doveva decidere era colmabile con lo studio e l'esperienza. Oggi quella distanza non è colmabile. Non è un divario che si chiude con più formazione o più impegno: è un divario strutturale, prodotto dalla complessità dell'oggetto, non dall'inadeguatezza del soggetto. La legislazione europea recente lo intuisce, anche se non lo dichiara. Il Cyber Resilience Act, la Product Liability Directive, l'AI Act: tutti questi strumenti normativi cercano di ricostruire catene di responsabilità in un contesto dove quelle catene sono fisicamente spezzate. Lo fanno con strumenti classici: obblighi di documentazione, valutazioni di conformità, registri di rischio. Sono tentativi seri e in molti casi benvenuti. Ma poggiano su un presupposto silenzioso che merita di essere messo in luce: presuppongono che da qualche parte ci sia qualcuno che sa. Il produttore deve documentare i rischi del proprio prodotto. Ma il produttore non conosce le dipendenze transitive del proprio codice. L'importatore deve verificare la conformità. Ma la conformità è definita rispetto a standard che descrivono proprietà del sistema che nessuno può verificare nella pratica. L'utente deve dare un consenso informato. Ma l'informazione necessaria per un consenso genuino richiederebbe competenze che nemmeno chi ha scritto il software possiede. Non è cinismo. È la descrizione accurata di una situazione che abbiamo creato passo dopo passo, in buona fede, risolvendo ogni volta il problema immediatamente davanti a noi e aggiungendo ogni volta un grammo di opacità al sistema complessivo. ## Il mito della specializzazione {: #il-mito-della-specializzazione } Una risposta che si sente spesso è che la specializzazione risolve il problema. Nessuno deve capire tutto: basta che ognuno capisca bene il proprio pezzo, e l'insieme funzionerà. È il principio della divisione del lavoro applicato alla conoscenza, ed è enormemente attraente perché permette di non affrontare la questione di fondo. Ma non funziona. Non funziona perché i confini tra i "pezzi" sono arbitrari e permeabili. Un problema di sicurezza attraversa tutti gli strati. Un requisito normativo taglia trasversalmente frontend, backend, infrastruttura, fornitori terzi. Una decisione architetturale presa cinque anni fa in un contesto che non esiste più vincola oggi scelte che chi la prese non avrebbe potuto immaginare. La specializzazione funziona quando i componenti sono davvero indipendenti. Il software non è fatto di componenti indipendenti. È fatto di dipendenze, nel senso più letterale: ogni parte dipende da altre parti, e il comportamento dell'insieme non è deducibile dal comportamento delle parti. È ciò che la teoria dei sistemi chiama emergenza, e l'emergenza è precisamente l'avversario della specializzazione. Il bug più insidioso è sempre quello che vive nello spazio tra le specializzazioni, dove nessuno guarda perché nessuno pensa che sia il proprio territorio. ## L'incompetenza di chi legifera {: #lincompetenza-di-chi-legifera } C'è un caso particolare che merita attenzione, non per spirito accusatorio ma perché è strutturalmente illuminante: l'incompetenza di chi scrive le norme. Un legislatore che scrive regole sul software è nella stessa posizione epistemologica di chiunque altro: non può comprendere il sistema nella sua interezza. Ma a differenza di un programmatore o di un architetto software, il legislatore non ha nemmeno la conoscenza parziale che viene dall'uso quotidiano. Opera su descrizioni di descrizioni, su astrazioni di astrazioni, mediate da consulenti che a loro volta mediano il sapere di specialisti. Questo non è un argomento contro la regolamentazione. Al contrario: è un argomento sulla natura della regolamentazione possibile. Normare ciò che non si comprende per intero non è un fallimento, è la condizione di partenza. La domanda non è se il legislatore sia competente — non può esserlo, nel senso pieno del termine, e non per colpa sua. La domanda è se le norme che produce siano abbastanza robuste da funzionare nonostante l'incompetenza strutturale di chi le ha scritte, di chi le deve applicare, e di chi le deve verificare. A volte la risposta è sì. Il GDPR, con tutti i suoi limiti, ha introdotto un principio di cautela che funziona precisamente perché non richiede comprensione tecnica: tratta i dati personali come se fossero pericolosi, indipendentemente dal fatto che tu capisca i meccanismi specifici del pericolo. È una norma progettata per l'incompetenza, e per questo funziona meglio di molte norme che presuppongono competenza. ## Socrate nel ciclo di sviluppo {: #socrate-nel-ciclo-di-sviluppo } C'è una frase che viene attribuita a Socrate con la frequenza e l'imprecisione riservate a tutte le frasi troppo utili: "so di non sapere." La si cita come gesto di umiltà, a volte come civetteria intellettuale. Ma nella sua versione più radicale, quella dell'Apologia platonica, il punto è diverso e molto più scomodo: Socrate non dice semplicemente che la sua conoscenza è limitata. Dice che chi crede di sapere è in una condizione peggiore di chi sa di non sapere, perché all'ignoranza aggiunge l'illusione. Applicata al presente tecnologico, la tesi socratica acquista un peso che Platone non avrebbe potuto immaginare. L'industria del software è costruita su una doppia illusione di sapere: quella di chi costruisce i sistemi (che crede di controllarli) e quella di chi li usa (che crede di capirli). Entrambe sono funzionali. Senza la prima illusione nessuno scriverebbe codice, perché l'onestà integrale sulla propria ignoranza sarebbe paralizzante. Senza la seconda nessuno userebbe software, perché il consenso informato autentico produrrebbe un rifiuto di massa. Funzioniamo, come individui e come industria, grazie a una sospensione volontaria dell'incredulità epistemologica. Non diversamente da come funziona la finanza, o la politica, o qualsiasi altro sistema complesso in cui la fiducia sostituisce la comprensione. Ma c'è una differenza. La finanza e la politica hanno sviluppato nel tempo una consapevolezza istituzionale della propria fragilità epistemologica. Le banche centrali esistono perché sappiamo che il sistema finanziario non si autoregola. Le costituzioni esistono perché sappiamo che il potere non si autolimita. L'informatica non ha ancora sviluppato nulla di equivalente. Non ha istituzioni progettate per gestire il fatto che nessuno sa. Ha standard, ha best practice, ha framework di certificazione: tutti strumenti che presuppongono la possibilità del sapere anziché fare i conti con la sua impossibilità. ## Decidere senza sapere {: #decidere-senza-sapere } La condizione quotidiana di chi lavora nella tecnologia è questa: decidere senza sapere. Non nel senso drammatico di una scommessa alla cieca, ma nel senso ordinario e un po' logorante di chi ogni giorno compie scelte con conseguenze pluriennali basandosi su informazioni che sa essere incomplete, in contesti che sa destinati a cambiare, per requisiti che sa essere provvisori. Una stima è una dichiarazione di probabilità soggettiva spacciata per previsione. Una scelta architetturale è un atto di fede nella stabilità di condizioni che non sono stabili. Un refactoring è una scommessa sul fatto che il costo presente sarà ripagato da benefici futuri che nessuno può garantire. Ogni sprint è un esercizio di epistemologia applicata sotto costrizione temporale, condotto da persone che non hanno studiato epistemologia e che non vengono pagate per riflettere sulle condizioni di possibilità del proprio sapere, ma per produrre risultati. Questa non è una denuncia. È una descrizione. E il punto non è che le cose dovrebbero andare diversamente: è che non possono andare diversamente. L'incompetenza strutturale non è un problema da risolvere. È la condizione in cui operiamo, e che continueremo a operare finché costruiremo sistemi la cui complessità eccede la capacità di comprensione di chi li costruisce. La questione, allora, non è come eliminare l'incompetenza. È come abitarla. ## Abitare l'incompetenza {: #abitare-lincompetenza } Se la competenza, nel senso classico di padronanza completa del proprio dominio, non è più raggiungibile, allora ciò che chiamiamo con quel nome è diventato qualcos'altro. Non un sapere, ma un saper fare in assenza di sapere. Una forma di saggezza pratica che somiglia più alla phronesis aristotelica che all'episteme: non la conoscenza delle cause prime, ma la capacità di agire bene in situazioni particolari e incerte. Il buon tecnico, oggi, non è chi sa di più. È chi gestisce meglio la propria ignoranza. Chi sa dove sono i confini di ciò che capisce, chi sa chiedere, chi sa quando fermarsi, chi sa costruire sistemi che falliscono in modo prevedibile anziché catastrofico. Sono tutte competenze, ma sono competenze sulla propria incompetenza. Sono meta-competenze, se si vuole usare un termine brutto per un'idea importante. E qui si apre un paradosso che merita di essere guardato in faccia. La cultura professionale del software premia il sapere e punisce il non-sapere. Chi ammette di non capire perde credibilità. Chi dice "non lo so" in una riunione viene percepito come debole. Chi stima con onestà viene punito dal confronto con chi stima con ottimismo. L'intero sistema di incentivi è costruito per mascherare l'incompetenza anziché per gestirla, il che produce il risultato opposto: incompetenza non riconosciuta, non gestita, non metabolizzata. Incompetenza pericolosa. Una cultura professionale matura farebbe il contrario. Partirebbe dall'assunto che nessuno capisce il sistema nella sua interezza, e costruirebbe processi, strumenti, istituzioni progettati per funzionare in quella condizione. Non è utopia: è ingegneria dell'ignoranza, ed è esattamente ciò che facciamo quando scriviamo test automatizzati (verifichiamo perché non ci fidiamo della nostra comprensione), quando facciamo code review (cerchiamo gli errori che il nostro punto cieco ci impedisce di vedere), quando adottiamo il principio del privilegio minimo (limitiamo il danno che la nostra ignoranza può causare). Questi non sono palliativi. Sono le pratiche più sofisticate che l'industria del software abbia prodotto, e sono tutte, alla radice, tecniche per gestire l'incompetenza. Nessuno le chiama così, perché il nome sarebbe scomodo. Ma lo sono. ## L'onestà come metodo {: #lonesta-come-metodo } Forse l'unica risposta disponibile all'incompetenza strutturale non è una soluzione ma un atteggiamento: l'onestà epistemologica come pratica quotidiana. Sapere di non sapere non come formula vuota, ma come punto di partenza operativo di ogni decisione. Questo non significa paralisi. Significa decidere sapendo di decidere al buio, e costruire reti di sicurezza proporzionate a quella consapevolezza. Significa documentare non solo ciò che si è fatto, ma perché lo si è fatto e su quali assunti — perché quegli assunti si riveleranno sbagliati e chi verrà dopo avrà bisogno di capire non la soluzione, ma il ragionamento che l'ha prodotta. Significa smettere di trattare le stime come promesse e le architetture come monumenti. Non è una proposta rivoluzionaria. È la descrizione di ciò che le persone migliori già fanno, spesso in silenzio, spesso in contrasto con la cultura che le circonda. L'incompetenza strutturale non è un nemico da sconfiggere. È il terreno su cui camminiamo, e l'unica scelta disponibile è tra camminarci con gli occhi aperti o con gli occhi chiusi. Noi, come specie, abbiamo costruito un mondo che non siamo in grado di capire. Non è una tragedia. È forse la cosa più umana che abbiamo mai fatto. --- # La maggior parte del software che esiste non dovrebbe esistere - **URL:** https://margiovanni.it/it/blog/la-maggior-parte-del-software-che-esiste-non-dovrebbe-esistere/ - **Pubblicato:** 2026-03-27 - **Tag:** Attention Economy, Innovation, Minimalism, Product Design - **Tempo di lettura:** 8 min > E chi lo costruisce per mestiere è l'ultimo ad ammetterlo. Ho costruito software per vent'anni. Ho spedito progetti, fatto sprint planning, configurato pipeline, scritto specifiche, litigato su architetture. Il software è la mia vita professionale. Ed è da questa posizione, non da quella del critico esterno o dell'opinionista del lunedì mattina, che vi dico una cosa che la nostra industria si rifiuta di sentire: la maggior parte del software che esiste non dovrebbe esistere. Non perché sia mal fatto. Parte lo è, certo, ma non è questo il punto. Non dovrebbe esistere perché non risolve nessun problema. O risolve un problema che nessuno ha. O risolve un problema che era già risolto, e lo fa peggio. O, nel caso più frequente e più insidioso, *crea* il problema che poi finge di risolvere. * * * ## Il cimitero dei problemi inventati {: #il-cimitero-dei-problemi-inventati } Apri il telefono. Conta le app. Quante ne usi davvero? Quante risolvono un problema reale nella tua vita? E quante esistono perché qualcuno ha messo insieme un pitch deck convincente, ha raccolto un round di finanziamento e ha costruito qualcosa che il mondo non aveva chiesto? Non è un fenomeno marginale. È il modello dominante dell'industria del software degli ultimi quindici anni. Il ciclo funziona così: qualcuno identifica un "pain point" (quasi sempre un'inconvenienza minore elevata a tragedia esistenziale), costruisce un MVP, raccoglie investimenti, assume sviluppatori, scala. A un certo punto il software esiste, ha degli utenti, genera fatturato. Ma nessuno si è mai fermato a chiedersi se il mondo ne avesse bisogno. La domanda era irrilevante. La domanda rilevante era: cresce? Ho visto app per condividere liste della spesa con i coinquilini. Piattaforme per prenotare il barbiere con l'intelligenza artificiale. SaaS per gestire le piante da appartamento. Marketplace per scambiare vestiti usati per il cane. Non sto inventando. Ognuno di questi ha ricevuto finanziamenti, ha avuto un team di sviluppatori, ha consumato server, energia, tempo umano. Il problema non è che fossero brutti prodotti. Alcuni erano tecnicamente impeccabili. Il problema è che non avevano ragione di esistere. E nessuno lo diceva, perché dirlo significava essere quello che "non capisce l'innovazione." * * * ## La tassa nascosta {: #la-tassa-nascosta } Il software non è gratis. Mai. Anche quando non costa niente all'utente, costa al mondo. Costa in energia. Ogni app che non dovrebbe esistere gira su server che consumano elettricità. Ogni SaaS inutile ha un database replicato su tre zone di disponibilità, un sistema di monitoring, un CDN globale. Il cloud non è una nuvola: è un capannone pieno di macchine che si surriscaldano, in Irlanda o in Virginia, alimentato da una rete elettrica che ha dei limiti fisici. Costa in attenzione. Ogni software inutile che si installa nel telefono di qualcuno compete per la sua attenzione con tutto il resto. Con il lavoro, con le relazioni, con il sonno, con la noia produttiva, con il pensiero non strutturato. E l'attenzione è una risorsa finita. Ogni app inutile che la cattura la sta rubando a qualcosa di più importante. Costa in complessità. Ogni software aggiunge un'interfaccia, un login, una password, un'altra serie di notifiche, un altro set di termini di servizio che nessuno legge, un altro flusso di dati personali che finisce chissà dove. La complessità del nostro ambiente digitale aumenta di anno in anno, e non perché i problemi aumentano. Perché le soluzioni aumentano più velocemente dei problemi. Costa in talento. Questo è il costo che mi fa più rabbia. Nel mondo ci sono sviluppatori di straordinario talento che passano le giornate a ottimizzare il funnel di conversione di un'app per ordinare caffè con tre tap in meno. Persone che potrebbero costruire software che salva vite, che rende accessibile l'istruzione, che migliora la sanità pubblica. E invece ottimizzano il colore di un bottone "Compra ora." Non è colpa loro. Il mercato paga di più per il bottone. Ma è uno spreco talmente osceno che dovremmo avere la decenza di nominarlo. * * * ## "Ma il mercato decide" {: #ma-il-mercato-decide } Ecco l'obiezione. Se un software esiste e ha utenti, allora il mercato ha deciso che serve. La domanda e l'offerta si incontrano, la mano invisibile fa il suo lavoro, tutti felici. Solo che non è vero. Il mercato del software non funziona come il mercato delle mele. Primo: il costo marginale di distribuzione è vicino a zero. Questo significa che un software può raggiungere milioni di utenti senza che la qualità o la necessità del prodotto vengano testate da nessun meccanismo di feedback naturale. Un fruttivendolo che vende mele marce fallisce in una settimana. Un'app che non risolve nessun problema può sopravvivere per anni, finanziata dal venture capital, crescendo in utenti che non pagano, finché non arriva il prossimo round o l'acquirente. Secondo: il modello pubblicitario ha scollegato il valore dal prezzo. Quando l'utente non paga, il prodotto non ha bisogno di essere utile all'utente. Ha bisogno di essere utile all'inserzionista. E per l'inserzionista, la metrica è l'attenzione, non la soddisfazione. Software che rendono le persone infelici ma le tengono incollate allo schermo sono un successo commerciale straordinario. Il mercato "ha deciso" che servono. Ma il mercato, in questo caso, è malato. Terzo: i network effect creano monopoli naturali. Una volta che tutti usano una piattaforma, non puoi non usarla. Non perché sia buona, ma perché è dove stanno tutti. Il mercato non ha "deciso" che WhatsApp è il modo migliore per comunicare. Ha deciso che è il modo con cui comunicano tutti, che è una cosa completamente diversa. * * * ## L'atto radicale di non costruire {: #latto-radicale-di-non-costruire } Nella cultura del tech, costruire è sempre positivo. "Makers gonna make." "Ship it." "Build in public." Il verbo costruire ha un'aura sacra, e chi costruisce è per definizione dalla parte giusta della storia. Ma c'è un atto più coraggioso di costruire, e nessuno ne parla: decidere di *non* costruire. Decidere che il mondo non ha bisogno di un altro task manager. Che un foglio Excel fa il lavoro meglio della tua app. Che il problema che stai per risolvere non è un problema. Che il tuo talento e il tuo tempo sono meglio spesi altrove. Nella mia esperienza, i migliori tecnici che ho conosciuto erano anche quelli più capaci di dire "non serve." Non per pigrizia, non per cinismo. Per rispetto. Rispetto per il problema, per l'utente, per la complessità del mondo reale. Sapevano che aggiungere software a un contesto significa aggiungere complessità, dipendenze, manutenzione, debito tecnico. E che farlo senza una ragione forte è un atto di irresponsabilità mascherato da produttività. La filosofia Unix lo diceva già quarant'anni fa: fa' una cosa sola, e falla bene. Non "fa' tutto." Non "fa' cose nuove perché puoi." Fa' una cosa sola. Il resto lascialo stare. * * * ## Il software che dovrebbe esistere {: #il-software-che-dovrebbe-esistere } Non sto dicendo che il software sia il nemico. Sarebbe come dire che la scrittura è il nemico perché esistono libri brutti. Il software che dovrebbe esistere è quello che amplia le capacità umane senza creare dipendenza. Che risolve un problema reale e verificabile. Che funziona per chi lo usa, non per chi lo vende. Che puoi smettere di usare senza conseguenze. Che non ha bisogno di catturarti per giustificare la propria esistenza. Il software che dovrebbe esistere è quello che, se scomparisse domani, qualcuno se ne accorgerebbe e ne sentirebbe la mancanza. Non la mancanza compulsiva del tossicodipendente, ma la mancanza concreta di chi ha perso uno strumento utile. Come perdere un buon coltello da cucina. Come perdere una bicicletta affidabile. Questa è la metrica che dovremmo usare: se sparisse, ne sentiresti la mancanza? Se la risposta è "probabilmente no," quel software non dovrebbe esistere. Se la risposta è "non saprei nemmeno che è sparito," quel software sta sprecando le risorse del pianeta e il tempo di chi lo ha costruito. * * * ## La responsabilità di chi costruisce {: #la-responsabilita-di-chi-costruisce } Ogni volta che decidiamo di costruire un software, stiamo prendendo una decisione che riguarda risorse reali. Tempo di sviluppatori. Energia dei server. Attenzione degli utenti. Complessità dell'ecosistema digitale. E in un mondo con risorse finite e problemi enormi, costruire qualcosa di inutile non è neutro. È uno spreco attivo. È un'allocazione sbagliata di intelligenza umana. L'ingegnere civile deve giustificare perché un ponte serve. L'architetto deve dimostrare che un edificio risponde a un'esigenza. Il medico non prescrive farmaci perché esistono. Perché nel software dovrebbe essere diverso? Perché dovremmo accettare che il 90% di quello che costruiamo finirà dimenticato in un App Store, ignorato dai suoi stessi creatori dopo sei mesi, abbandonato con i dati degli utenti dentro e i server ancora accesi? La vera innovazione, nel 2026, non è costruire di più. È costruire meno, meglio, per ragioni migliori. E avere il coraggio di dire, ogni tanto, "no, questo non lo facciamo." Non perché non possiamo. Perché non serve. * * * ## Il lusso della sottrazione {: #il-lusso-della-sottrazione } C'è un concetto in architettura che il mondo del software non ha mai imparato: il valore dello spazio vuoto. Un bravo architetto non riempie ogni metro quadro. Sa che lo spazio vuoto non è assenza. È respiro. È possibilità. È la stanza che serve a chi ci abita per muoversi, per pensare, per vivere. Un edificio pieno fino all'ultimo centimetro non è un capolavoro di efficienza. È una prigione. Il nostro paesaggio digitale è un edificio pieno fino all'ultimo centimetro. Ogni spazio è occupato da un'app, un servizio, una piattaforma, una notifica. Non c'è respiro. Non c'è spazio vuoto. Non c'è silenzio. E in mezzo a tutto questo rumore, il software veramente utile, quello che risolve i problemi veri, si perde. Diventa invisibile. Non perché sia meno buono, ma perché è sommerso da tonnellate di software che non dovrebbe esistere. La sottrazione è un atto creativo. Scegliere di non costruire è una decisione progettuale. E in un'industria che non sa dire di no a niente, è forse la competenza più rara e più preziosa. * * * *Il miglior software che abbia mai scritto è quello che ho deciso di non scrivere.* --- # I tuoi figli non sono i tuoi utenti - **URL:** https://margiovanni.it/it/blog/i-tuoi-figli-non-sono-i-tuoi-utenti/ - **Pubblicato:** 2026-03-26 - **Tag:** Dark Pattern, Design Responsabile, Dipendenza Digitale, Filosofia - **Tempo di lettura:** 8 min > Manifesto per chi costruisce tech ed è anche genitore. Conosci la parola “engagement.” La usi nelle riunioni, nei documenti di progetto, nelle call con i clienti. Sai cosa significa: tempo trascorso sulla piattaforma, frequenza di ritorno, interazioni per sessione. Sai che è la metrica che conta. Sai che il tuo lavoro, in ultima analisi, viene giudicato dalla tua capacità di farla salire. Poi torni a casa. E tuo figlio è davanti a uno schermo. E quello schermo sta facendo esattamente quello che tu sai fare: catturare attenzione, generare engagement, massimizzare il tempo di permanenza. Solo che stavolta l’utente non è un utente. È tuo figlio. * * * ## La dissonanza {: #la-dissonanza } Se lavori nel tech e hai figli, vivi una dissonanza cognitiva che quasi nessuno nomina. Di giorno progetti sistemi pensati per trattenere le persone. Di sera cerchi di staccare tuo figlio da sistemi identici. Di giorno parli di “user retention” come di un successo. Di sera la “retention” di tuo figlio davanti al tablet ti spaventa. Sai come funziona il pull-to-refresh. L’hai implementato, o almeno ne hai discusso l’implementazione. Sai che replica il gesto della leva di una slot machine. Sai che il ritardo prima del caricamento non è un limite tecnico ma un *design pattern* : la pausa calcolata che massimizza il rilascio di dopamina. Lo sai perché è il tuo mestiere saperlo. E sai che tuo figlio, a otto anni, a dieci anni, a dodici anni, non ha nessuno strumento per difendersi da quello che tu sai costruire. Non è una contraddizione personale. È una contraddizione di sistema. Riguarda chiunque lavori nel tech e abbia dei figli, cioè a questo punto milioni di persone. * * * ## Quello che sappiamo e che non possiamo più fingere di non sapere {: #quello-che-sappiamo-e-che-non-possiamo-piu-fingere-di-non-sa } Mettere in fila le cose aiuta a guardarle in faccia. **Sappiamo** che gli schemi di rinforzo a rapporto variabile, quelli su cui si basano i feed dei social media, sono il meccanismo psicologico più potente mai documentato per indurre e mantenere un comportamento compulsivo. Lo sappiamo dagli anni ’50. Skinner lo dimostrò sui piccioni. Noi lo applichiamo ai bambini. **Sappiamo** che il cervello di un adolescente è in piena fase di sviluppo. La corteccia prefrontale, quella che governa il giudizio, il controllo degli impulsi, la capacità di valutare le conseguenze, non completa la maturazione prima dei 25 anni. Progettiamo sistemi che la bypassano deliberatamente per parlare direttamente al sistema limbico. Lo facciamo per mestiere. **Sappiamo** che l’uso abituale dei social media è associato a una riduzione misurabile dello spessore corticale nelle regioni cerebrali legate al controllo cognitivo. Non sono opinioni. Sono dati da risonanza magnetica su migliaia di adolescenti. **Sappiamo** che i tassi di depressione, ansia, autolesionismo e suicidio tra gli adolescenti sono raddoppiati o triplicati dal 2010, in coincidenza con la diffusione degli smartphone, in tutto il mondo occidentale. **Sappiamo** che le piattaforme lo sanno. I documenti interni di Meta, resi pubblici da Frances Haugen, mostravano che Instagram peggiorava i problemi di immagine corporea per una ragazza su tre. L’azienda lo sapeva. Ha continuato. **Sappiamo** tutto questo. E continuiamo a costruire. * * * ## “Ma io non lavoro ai social” {: #ma-io-non-lavoro-ai-social } Lo so. Neanch’io. Costruisco gestionali, piattaforme per la pubblica amministrazione, software B2B. Non progetto feed algoritmici e non ottimizzo sistemi di raccomandazione per adolescenti. Ma il punto non è cosa costruiamo oggi. Il punto è la cultura in cui lo costruiamo. Lavoriamo in un’industria che ha normalizzato l’idea che l’attenzione umana sia una risorsa da estrarre. Che la “user experience” sia sinonimo di “tempo che l’utente passa sulla piattaforma.” Che il successo si misuri in sessioni, click, conversion rate, daily active users. Parliamo di esseri umani con il vocabolario dell’estrazione mineraria, e non ci sembra strano. Questa cultura ci attraversa tutti. Anche chi non lavora ai social ne respira le metriche, i valori, le priorità. Quando torniamo a casa, quella cultura torna con noi. Si insinua nel modo in cui guardiamo lo schermo di nostro figlio. A volte con preoccupazione, certo, ma anche con una sottile, inconfessabile familiarità. Riconosciamo quei meccanismi. Sappiamo che funzionano. E una parte di noi, la parte professionale, non riesce a non ammirarli. È questa familiarità che dobbiamo spezzare. * * * ## Il privilegio della consapevolezza {: #il-privilegio-della-consapevolezza } Chi lavora nel tech e ha figli possiede qualcosa che la maggior parte dei genitori non ha: la conoscenza dell’architettura. Sappiamo *come* funzionano quei sistemi, non solo *che* funzionano. Sappiamo che le notifiche non arrivano a caso ma sono ottimizzate per il momento di massima vulnerabilità psicologica. Sappiamo che lo scroll infinito non è una scelta estetica ma un dispositivo di cattura. Sappiamo che “l’algoritmo” non è un’entità misteriosa: è codice scritto da persone come noi, con obiettivi precisi, ottimizzato su metriche precise. Questa consapevolezza è un privilegio enorme. E il privilegio crea responsabilità. Se vedi il fuoco e gli altri no, non puoi fare finta di niente e dire “non è il mio incendio.” Eppure è esattamente quello che facciamo, come industria. Sappiamo. E taciamo. Perché parlare significherebbe ammettere che il problema non è “là fuori”, nelle cattive abitudini dei ragazzini, nell’incapacità dei genitori, nella mancanza di “educazione digitale.” Il problema è anche *dentro*. Nel modo in cui pensiamo il software. Nelle metriche che scegliamo di ottimizzare. Nelle domande che non ci facciamo. * * * ## Le domande che non ci facciamo {: #le-domande-che-non-ci-facciamo } In vent’anni di carriera nel tech, non ho mai sentito nessuno in una riunione di progetto fare queste domande: *Questo sistema potrebbe creare dipendenza? Se sì, abbiamo la responsabilità di prevenirlo?* *Stiamo progettando per il benessere dell’utente o per la massimizzazione del suo tempo di utilizzo? Sono la stessa cosa?* *Se un minore usasse questo prodotto, sarebbe sicuro? Non “conforme alla normativa.” Sicuro.* *Stiamo misurando il successo con metriche che allineano i nostri interessi a quelli di chi usa il nostro software? O stiamo misurando qualcosa che ci fa comodo misurare?* *Costruiremmo questo sistema esattamente così se sapessimo che il primo utente sarà nostro figlio?* L’ultima domanda è la più importante. Ed è quella che non facciamo mai. * * * ## Il test del figlio {: #il-test-del-figlio } Propongo una regola. Non una legge, non un framework, non un processo. Una regola personale, per chiunque costruisca software e abbia dei figli. **Prima di implementare un sistema, chiediti: va bene se il primo utente è mio figlio?** Non “mio figlio a vent’anni, adulto, consapevole, formato.” Mio figlio *adesso*. Con l’età che ha. Con la corteccia prefrontale che ha. Con la capacità di resistenza agli stimoli che ha. Con la fiducia cieca nella tecnologia che ha. Se la risposta è sì, costruiscilo. Se la risposta è “dipende,” fermati e chiediti da cosa dipende. Se la risposta è no, hai un problema. E il problema non è tuo figlio. Non è un test sentimentale. È un test di progettazione. È il *principio di precauzione* tradotto nel linguaggio dello sviluppo software. La versione applicata dell’imperativo di Hans Jonas: agisci in modo che le conseguenze della tua azione siano compatibili con la permanenza di un’autentica vita umana. Solo che Jonas parlava di bombe atomiche e ingegneria genetica. Noi parliamo di feed algoritmici e notifiche push. Il fatto che sembrino innocui è esattamente ciò che li rende pericolosi. * * * ## Non siamo impotenti {: #non-siamo-impotenti } Lo so cosa stai pensando. “Sono un impiegato. Un freelance. Un team lead in un’azienda di dieci persone. Non decido le politiche di Meta.” È vero. Non le decidi. Ma decidi come costruisci *il tuo* software. Quali metriche ottimizzare. Se implementare dark pattern o rifiutarti. Se mettere un timer di utilizzo o uno scroll infinito. Se progettare un sistema che rispetta l’attenzione dell’utente o uno che la saccheggia. Soprattutto, decidi che tipo di professionista vuoi essere. Puoi essere quello che dice “il mercato lo richiede” e implementa qualsiasi cosa paghi. O puoi essere quello che dice “questo non lo costruisco così” e propone un’alternativa. Non è idealismo, è artigianato. Un falegname serio non usa legno marcio perché costa meno. Un cuoco serio non serve cibo avariato perché aumenta il margine. Un ingegnere serio non firma un progetto strutturalmente insicuro perché il committente ha fretta. Eppure nel software, dove le conseguenze possono riguardare milioni di persone e il cervello di un’intera generazione, accettiamo standard che non accetteremmo in nessun altro mestiere. * * * ## Il manifesto {: #il-manifesto } Lavoro nel tech. Ho un figlio. Non posso più tenere separate le due cose. **Mio figlio non è un utente.** Non è una metrica, non è una sessione, non è un daily active user. È un essere umano con un cervello in sviluppo, una capacità di giudizio in costruzione, una fiducia nel mondo che dipende anche da come io, e le persone come me, costruiamo quel mondo. **Il mio mestiere ha delle conseguenze.** Non le conseguenze astratte e lontane della filosofia morale. Quelle concrete di un sistema che funziona ventiquattr’ore al giorno e che interagisce con milioni di cervelli. Se non me ne assumo la responsabilità, chi dovrebbe farlo? **La compliance non basta.** Rispettare il GDPR, l’AI Act, l’EAA è il minimo sindacale, non il traguardo. La domanda non è “è legale?” La domanda è “è giusto?” Sono due domande diverse, e la seconda è più importante. **La velocità non è un valore.** “Ship fast” non è una virtù quando quello che stai lanciando può fare danni. La fretta è il rifugio di chi non vuole pensare alle conseguenze. Il pensiero critico è lento per natura. Il codice è veloce. La saggezza sta nel non confondere i tempi dell’uno con quelli dell’altro. **La formazione tecnica non basta.** Saper scrivere codice senza saper leggere le implicazioni di quel codice non è competenza, è cecità specializzata. Abbiamo bisogno di ingegneri che abbiano letto Jonas, di sviluppatori che conoscano Mill, di designer che abbiano studiato la psicologia dello sviluppo. Non come cultura generale. Come strumenti di lavoro. **Mio figlio mi giudicherà.** Non per il fatturato che ho generato, non per i progetti che ho consegnato, non per le tecnologie che ho padroneggiato. Mi giudicherà per il mondo che ho contribuito a costruire. E in quel giudizio, “stavo solo eseguendo gli ordini” non sarà una difesa accettabile. Non lo è mai stata. * * * ## A chi costruisce {: #a-chi-costruisce } Se lavori nel tech e hai dei figli, sai di cosa sto parlando. Sai che c’è una conversazione che la nostra industria rifiuta di avere. Sai che il disagio che senti quando tuo figlio scompare dentro uno schermo non è paranoia genitoriale. È competenza professionale che ti sta dicendo qualcosa. Ascoltala. Non sto dicendo di smettere di costruire software. Sto dicendo di costruirlo come se il primo utente fosse tuo figlio. Perché, a tutti gli effetti, potrebbe esserlo. E se non tuo figlio, quello di qualcun altro. Che poi è la stessa cosa. * * * *“Non abbiamo ereditato il mondo dai nostri genitori. Lo abbiamo preso in prestito dai nostri figli.”* — proverbio attribuito ad Antoine de Saint-Exupéry --- # Il progresso non è una direzione: anatomia di un equivoco pericoloso - **URL:** https://margiovanni.it/it/blog/il-progresso-non-e-una-direzione-anatomia-di-un-equivoco-pericoloso/ - **Pubblicato:** 2026-03-25 - **Tag:** AI Act, Dipendenza Digitale, Etica Della Tecnologia, Filosofia - **Tempo di lettura:** 29 min > Quando qualcuno grida che lo Stato "frena il progresso", sta davvero parlando di progresso, o di qualcos'altro? ## Premessa: perché un informatico vi parlerà di Condorcet {: #premessa-perche-un-informatico-vi-parlera-di-condorcet } C'è una cosa che devo dire prima di tutto il resto, perché è la ragione per cui questo articolo esiste. Ho fatto il liceo scientifico. Mi sono laureato in Filosofia a Urbino, una di quelle università dove la filosofia non è un accessorio ma un modo di stare al mondo, dove ti insegnano che le domande contano più delle risposte e che "a cosa serve?" è essa stessa una domanda filosofica. Poi ho scelto la tecnologia. Ho scritto codice, gestito infrastrutture, costruito prodotti digitali per vent'anni. E per vent'anni mi sono sentito ripetere, con sfumature variabili tra il benevolo e il sarcastico, che la filosofia "non serve a niente". Che nel mondo del tech contano i linguaggi di programmazione, i framework, i deployment. Che Kant e Popper sono lussi intellettuali simpatici ma sostanzialmente decorativi, tipo un quadro sopra il divano del salotto. Ho sempre saputo che non era vero. Lo sentivo ogni volta che in una riunione di progetto coglievo un'implicazione etica che gli altri non vedevano. Lo sentivo quando leggevo una normativa europea e, invece di vederci solo un elenco di adempimenti, ci riconoscevo la traduzione giuridica di un principio filosofico preciso. Lo sentivo quando discutevo di architettura software e mi rendevo conto che le decisioni veramente importanti non erano tecniche: erano decisioni su *che tipo di mondo* quel software avrebbe contribuito a creare. Oggi quella sensazione si è trasformata in certezza. La formazione umanistica non è un complemento del pensiero tecnico. Ne è il fondamento etico indispensabile. Senza di essa, la tecnologia è cieca. Potente, velocissima, efficientissima, e cieca. Viviamo in un momento storico in cui i sistemi che costruiamo possono alterare lo sviluppo neurologico di un'intera generazione, influenzare elezioni, decidere chi ottiene un mutuo e chi no, determinare cosa milioni di persone crederanno vero domani mattina. In questo contesto, sapere come si configura un cluster Kubernetes non basta. Bisogna anche sapere cosa pensava Hans Jonas della responsabilità verso il futuro. Bisogna aver letto Mill sul confine tra libertà e danno. Bisogna conoscere il dislivello prometeico di Anders, e riconoscerlo quando lo si vede implementato in un algoritmo di raccomandazione. Non è più una questione accademica. Non è il lusso di chi ha tempo per le letture colte. È una questione esistenziale, nel senso più concreto e meno retorico del termine. Esistenziale per noi come specie, perché le decisioni tecnologiche di questo decennio definiranno le condizioni cognitive e sociali in cui vivranno i nostri figli. Ed esistenziale per i business, perché chi costruisce tecnologia senza una bussola etica non sta solo correndo un rischio morale: sta correndo un rischio di mercato. L'Europa lo ha capito. L'AI Act, il GDPR, il Cyber Resilience Act, la Product Liability Directive sono il segnale che il tempo della tecnologia senza pensiero critico è finito. Chi non sa leggere quel segnale, chi non ha gli strumenti culturali per capire *perché* quelle norme esistono e non solo *come* adempierle, resterà indietro. Non per punizione, ma per inadeguatezza. Quindi sì: dopo vent'anni nel tech, posso dire con ragionevole sicurezza che la laurea in filosofia è stata la decisione professionale più importante della mia vita. Più di qualsiasi certificazione, più di qualsiasi linguaggio imparato, più di qualsiasi progetto consegnato. Perché mi ha dato l'unica cosa che la tecnologia non può darti: la capacità di chiederti se quello che stai costruendo *dovresti* costruirlo. Quello che segue è un tentativo di spiegare perché. * * * ## L'arma retorica più potente del nostro tempo {: #larma-retorica-piu-potente-del-nostro-tempo } C'è una parola che, nel dibattito pubblico contemporaneo, funziona come un passepartout argomentativo. Una parola che chiude le discussioni invece di aprirle, che trasforma chi la invoca in difensore della civiltà e chi la questiona in oscurantista. Quella parola è *progresso*. "L'Europa frena il progresso." "La burocrazia uccide l'innovazione." "Le regolamentazioni incatenano il futuro." Queste frasi le sentiamo quotidianamente, nei talk show, nei thread su X, nelle keynote delle conferenze tech, nei blog post dei venture capitalist della Bay Area. Si presentano come evidenze, ma nascondono una premessa mai esplicitata: che il progresso sia una forza naturale, unidirezionale, intrinsecamente benefica, e che qualsiasi ostacolo sul suo cammino sia per definizione un danno all'umanità. Ma è davvero così? O stiamo confondendo il progresso con qualcosa di molto più banale e molto meno nobile? * * * ## Cos'è il progresso, e cos'è stato {: #cose-il-progresso-e-cose-stato } Per rispondere, dobbiamo prima capire da dove viene l'idea stessa di progresso. Non è un concetto eterno: è un'invenzione storica, e neanche troppo antica. ### L'Illuminismo e la nascita di un'idea L'idea che la storia umana abbia una direzione, che il domani sarà migliore dell'oggi, è un prodotto dell'Illuminismo europeo del XVIII secolo. Prima di Condorcet, Voltaire e Kant, il tempo era percepito come ciclico (nel mondo greco-romano) o come decadenza da un'età dell'oro perduta. L'Illuminismo ha rivoluzionato questa percezione: la ragione umana, applicata sistematicamente, poteva migliorare le condizioni materiali, morali e politiche della specie. Condorcet, nel suo *Esquisse d 'un tableau historique des progrès de l'esprit humain* (1795), immaginava un'umanità che avanza per stadi verso la perfezione attraverso l'educazione, la scienza e l'abolizione dei pregiudizi. Era una visione potente e, per molti aspetti, generosa. Ma conteneva già un germe problematico: l'idea che il progresso fosse *inevitabile* , quasi una legge naturale. Kant, più sottile, distingueva tra progresso tecnico e progresso morale. Nel suo *Idea di una storia universale dal punto di vista cosmopolitico* (1784) suggeriva che l'umanità potesse avanzare verso una società civile universale, ma solo attraverso il conflitto, la fatica, e soprattutto attraverso istituzioni capaci di incanalare la "insocievole socievolezza" degli esseri umani. Per Kant il progresso non era automatico: richiedeva *strutture* , *leggi* , *vincoli reciproci*. Richiedeva politica. ### Il positivismo e l'equivoco fondativo È con Auguste Comte e il positivismo ottocentesco che l'idea di progresso si salda definitivamente a quella di progresso *tecnico-scientifico*. Comte teorizzava una "legge dei tre stadi" (teologico, metafisico, positivo) in cui la scienza avrebbe progressivamente sostituito ogni altra forma di conoscenza, guidando l'umanità verso un ordine razionale. Qui nasce l'equivoco che ci trasciniamo ancora oggi: l'identificazione tra avanzamento tecnologico e miglioramento della condizione umana. Un equivoco che il XX secolo avrebbe dovuto distruggere per sempre, e che invece, con ostinazione quasi inspiegabile, continua a prosperare. ### Il secolo che avrebbe dovuto insegnarci tutto Il Novecento è stato il laboratorio definitivo per testare l'equazione "più tecnologia = più progresso". I risultati sono stati inequivocabili. La stessa scienza che ha prodotto la penicillina ha prodotto il gas nervino. La stessa ingegneria che ha costruito ponti e acquedotti ha costruito le camere a gas, con efficienza industriale, con precisione tecnica, con *progresso* nei metodi. La fissione nucleare ha dato all'umanità una fonte energetica straordinaria e, contemporaneamente, la capacità di autoannientarsi. Günther Anders, nel suo *L 'uomo è antiquato* (1956), ha colto questa frattura con una lucidità che toglie il fiato. Anders ha formulato il concetto di "dislivello prometeico": la nostra capacità tecnica di *produrre* supera radicalmente la nostra capacità di *immaginare* le conseguenze di ciò che produciamo. Possiamo costruire una bomba che uccide centomila persone, ma non possiamo *sentire* , emotivamente e moralmente, cosa significhi la morte di centomila persone. Siamo diventati, scriveva Anders, più piccoli dei nostri prodotti. Hannah Arendt, analizzando il processo Eichmann, ha mostrato qualcosa di ancora più disturbante: che il male più radicale del XX secolo non è stato commesso da mostri, ma da burocrati efficienti. La "banalità del male" è, in un certo senso, il progresso organizzativo applicato alla distruzione. Eichmann non odiava gli ebrei: ottimizzava i processi logistici. Era, a suo modo, un *innovatore*. * * * ## Il pensiero che uccide: un esperimento mentale {: #il-pensiero-che-uccide-un-esperimento-mentale } Facciamo un passo ulteriore. Facciamolo insieme, con la serietà che merita. Immaginiamo che domani, attraverso una qualche convergenza di neuroscienza, nanotecnologia e interfacce cervello-computer, diventi possibile uccidere un altro essere umano con la sola forza del pensiero. Nessuna arma fisica. Nessun intermediario. Un'intenzione mentale sufficientemente focalizzata, e l'altra persona muore. Questo sarebbe progresso tecnologico? La risposta superficiale è sì. È un avanzamento nella comprensione del cervello, nelle capacità delle interfacce neurali, nella miniaturizzazione della tecnologia. Soddisfa tutti i criteri con cui normalmente definiamo il progresso tecnico: è nuovo, è più potente di ciò che c'era prima, rappresenta una frontiera della conoscenza. Ma qualcosa in noi, qualcosa di profondo e pre-argomentativo, si rivolta contro questa risposta. Sentiamo che c'è qualcosa di sbagliato. E quel "qualcosa" è esattamente ciò che dobbiamo esaminare, perché è lì che si nasconde la vera natura del progresso. ### L'etica della responsabilità di Hans Jonas Hans Jonas, nel suo *Il principio responsabilità* (1979), ha anticipato questo tipo di dilemma. Scriveva in un'epoca in cui la manipolazione genetica e l'energia nucleare erano le frontiere della tecnica, ma il suo ragionamento si applica con una pertinenza impressionante al nostro esperimento mentale. Jonas parte da una constatazione: l'etica tradizionale è inadeguata per affrontare il potere tecnologico moderno. L'etica classica, da Aristotele a Kant, presupponeva che la natura fosse sostanzialmente invulnerabile all'azione umana, e che le conseguenze delle nostre azioni fossero circoscritte nello spazio e nel tempo. La tecnologia moderna ha reso queste premesse false: oggi possiamo alterare il clima, modificare il genoma e, nel nostro esperimento, abolire ogni barriera tra intenzione e omicidio. Da qui Jonas formula il suo *imperativo categorico tecnologico* : "Agisci in modo che le conseguenze della tua azione siano compatibili con la permanenza di un'autentica vita umana sulla terra." Non è un imperativo conservatore: è un imperativo di *responsabilità verso il futuro*. La domanda non è "possiamo farlo?", ma "che tipo di mondo creiamo facendolo?". Nel caso del pensiero che uccide, la risposta è chiara: creeremmo un mondo in cui la convivenza umana, il fondamento di ogni civiltà, diventerebbe impossibile. Non ci sarebbe più alcun luogo sicuro, perché la minaccia risiederebbe nella mente stessa. Ogni interazione umana sarebbe avvelenata dal terrore. Non sarebbe la fine della tecnologia: sarebbe la fine della *società*. ### Il filtro di Mill: il danno come confine della libertà John Stuart Mill, nel suo *On Liberty* (1859), ha formulato il principio che dovrebbe essere il faro di ogni discussione sul progresso: la libertà individuale è sacra, ma finisce dove inizia il danno agli altri. È il cosiddetto "harm principle", e nella sua semplicità contiene una saggezza enorme. Applicato al nostro esperimento: la capacità di uccidere con il pensiero non è un'espansione della libertà umana. È la sua negazione assoluta. Se chiunque può uccidere chiunque senza intermediari, non esiste più alcuna libertà, perché la libertà presuppone la sicurezza dell'esistenza fisica. Non puoi esercitare la libertà di parola, di movimento, di pensiero se qualcuno può annientarti con un'intenzione. Mill ci insegna qualcosa che dovremmo tatuarci addosso: non ogni espansione del potere individuale è un progresso. Alcune capacità, se distribuite universalmente, non emancipano: distruggono. Il progresso autentico non è l'aumento illimitato della potenza, ma l'aumento della potenza *entro i confini che rendono possibile la convivenza*. ### Popper: la società aperta e i suoi nemici (anche tecnologici) Karl Popper, ne *La società aperta e i suoi nemici* (1945), ha costruito la difesa filosofica più robusta delle istituzioni democratiche contro ogni forma di utopismo, incluso quello tecnologico. Popper diffidava profondamente delle grandi narrative sul progresso inevitabile. Per lui il progresso non era una marcia trionfale ma un processo di congetture e confutazioni: proviamo, sbagliamo, correggiamo. E, punto cruciale, possiamo correggere solo se esistono istituzioni che ci permettono di farlo *senza violenza*. La società aperta è quella che ha meccanismi di autocorrezione: parlamenti, tribunali, stampa libera, leggi modificabili. Quando qualcuno dice che le regolamentazioni "incatenano il progresso", sta dicendo, consapevolmente o meno, che i meccanismi di autocorrezione sono un ostacolo. Ma un ostacolo a *cosa* , esattamente? Se il "progresso" non può sopravvivere al vaglio democratico, al dibattito pubblico, alla valutazione dei rischi, forse non è progresso. Forse è solo *fretta travestita da visione*. * * * ## Chi grida al progresso incatenato: una tassonomia {: #chi-grida-al-progresso-incatenato-una-tassonomia } Quando nel dibattito pubblico qualcuno lamenta che gli stati o le organizzazioni sovranazionali "frenano il progresso", vale la pena chiedersi: chi sta parlando, e quali interessi rappresenta? ### Il tecno-ottimista in buona fede Esiste certamente chi crede sinceramente che la tecnologia sia la soluzione a tutti i problemi umani. La posizione è comprensibile: la tecnologia *ha* risolto problemi enormi, dalla mortalità infantile alle carestie alle epidemie. Ma il tecno-ottimismo diventa pericoloso quando si trasforma in tecno-determinismo: l'idea che la tecnologia, lasciata a sé stessa, produca *sempre* risultati positivi. La storia dice il contrario. ### L'imprenditore che confonde il proprio interesse con l'interesse generale Qui il territorio si fa più delicato. Quando un CEO della Silicon Valley denuncia la regolamentazione europea sull'AI come "ostacolo al progresso", sta davvero difendendo il futuro dell'umanità o sta difendendo il proprio modello di business? La confusione tra interesse privato e bene comune è antica quanto il capitalismo, ma nell'era tech ha assunto una forma particolarmente insidiosa: si presenta vestita di futuro, di innovazione, di *visione*. Marc Andreessen, nel suo *Techno-Optimist Manifesto* (2023), ha portato questa posizione alle sue conseguenze logiche: i mercati sono il meccanismo di progresso per eccellenza, la regolamentazione è un freno, e chi la difende è un "deceleratore", un nemico del futuro. Posizione che ha il merito della chiarezza e il difetto della cecità: ignora completamente che i mercati, senza regole, non producono progresso ma concentrazione di potere. Lo sapeva già Adam Smith, che ne *La ricchezza delle nazioni* metteva in guardia contro i monopoli con la stessa forza con cui difendeva il libero scambio. ### Il libertario ideologico Per il libertario radicale, ogni forma di regolamentazione è coercizione, e ogni coercizione è male. Posizione filosoficamente coerente, se si accettano le premesse. Ma le premesse sono fragili: presuppongono che gli individui operino in un vuoto sociale, senza asimmetrie di potere, senza esternalità, senza la possibilità che la libertà di uno distrugga la libertà di molti. Robert Nozick, in *Anarchy, State, and Utopia* (1974), ha costruito la versione più sofisticata di questa posizione. Ma persino Nozick ammetteva la necessità di uno "stato minimo" per proteggere i diritti fondamentali. E allora: quando la tecnologia può alterare il clima, manipolare il comportamento di miliardi di persone, o abolire ogni barriera tra intenzione e omicidio, lo "stato minimo" di Nozick è ancora sufficiente? ### Il populista anti-élite Infine c'è chi usa la retorica del "progresso frenato" in chiave populista: le élite burocratiche di Bruxelles impongono regole che il "popolo" non ha chiesto. Posizione che sfrutta la legittima frustrazione democratica per attaccare le istituzioni, ma che raramente propone alternative credibili. Perché la domanda scomoda è: se non le istituzioni democratiche, *chi* dovrebbe decidere i limiti della tecnologia? Il mercato? I programmatori? Gli azionisti? * * * ## L'arma atomica che è già esplosa: i social network e il cervello dei nostri figli {: #larma-atomica-che-e-gia-esplosa-i-social-network-e-il-cervel } Fin qui abbiamo ragionato in modo astratto: esperimenti mentali, ipotesi filosofiche, scenari futuribili. Ma non ce n'è bisogno. L'arma che distrugge senza sparare un colpo esiste già. È nelle tasche dei nostri figli. Ha un'interfaccia colorata, delle notifiche allegre e un modello di business che monetizza l'attenzione umana trasformandola in dati vendibili agli inserzionisti. Parliamo dei social network. E parliamo, con la brutalità che il tema merita, di ciò che stanno facendo al cervello, alla psiche e alla struttura sociale di un'intera generazione. ### L'iceberg sommerso Jonathan Haidt, psicologo sociale e autore di *The Anxious Generation* (2024), ha documentato ciò che i dati epidemiologici mostrano con chiarezza: dopo oltre un decennio di stabilità o miglioramento, la salute mentale degli adolescenti è precipitata nei primi anni 2010. Tassi di depressione, ansia, autolesionismo e suicidio sono aumentati vertiginosamente, più che raddoppiando su molti indicatori. L'impennata coincide con la diffusione capillare degli smartphone. Non con la crisi finanziaria del 2008, non con il terrorismo, non con il cambiamento climatico. Con gli smartphone. Ma quello che vediamo, i numeri che già ci spaventano, è solo la punta dell'iceberg. Guardiamo cosa sappiamo. Il CDC americano riporta che nel 2023, oltre il 40% degli studenti delle scuole superiori ha dichiarato sentimenti persistenti di tristezza o disperazione. Tra le ragazze, il 57% mostrava sintomi depressivi. Quasi una ragazza su tre ha dichiarato di aver "seriamente considerato" il suicidio, un aumento del 60% nell'ultimo decennio. Nel Regno Unito, l'NHS Mental Health Survey 2025 rivela che il 25,8% dei giovani tra i 16 e i 24 anni è colpito da un disturbo mentale comune, contro il 18,9% del 2014. Tra le giovani donne si arriva al 36,1%. Questi sono i dati *emersi*. Quelli che misuriamo perché qualcuno ha chiesto aiuto, è andato in ospedale, ha compilato un questionario. L'iceberg sommerso è fatto di adolescenti che soffrono in silenzio, che sviluppano disturbi subclinici, che perdono capacità cognitive senza che nessuno se ne accorga. Il 70-80% dei minori con disturbi mentali non riceve mai alcun trattamento. ### Il cervello come campo di battaglia La questione più inquietante, però, non è psicologica: è neurologica. E qui siamo in un territorio che dovrebbe togliere il sonno a chiunque abbia figli, nipoti, studenti. Uno studio pubblicato su JAMA Pediatrics dal team della professoressa Eva Telzer dell'Università della North Carolina ha seguito 169 studenti delle scuole medie per tre anni, monitorandone l'attività cerebrale con risonanza magnetica funzionale. I risultati: gli adolescenti che controllano abitualmente i social media mostrano traiettorie di sviluppo cerebrale significativamente diverse da quelli che non lo fanno. Le aree colpite includono l'amigdala (il centro della paura e della reattività emotiva) e la corteccia prefrontale dorsolaterale, responsabile del giudizio, del ragionamento e della valutazione delle ricompense. Uno studio recentissimo, pubblicato nel marzo 2026 su NeuroImage, ha analizzato i dati dell'ABCD Study su oltre 7.000 adolescenti americani, trovando che un maggiore uso quotidiano di social media è associato a una riduzione dello spessore corticale in un'ampia gamma di regioni cerebrali. Non stiamo parlando di "sentirsi un po' tristi". Stiamo parlando di alterazioni strutturali del cervello in fase di sviluppo. La generazione Z, i nati dopo il 1995, è stata la prima generazione ad avere gli smartphone durante la pubertà. Il loro cervello si è sviluppato mentre algoritmi progettati per massimizzare l'engagement competevano per la loro attenzione in ogni momento della giornata. Haidt identifica quattro danni fondamentali: deprivazione sociale (sostituzione delle relazioni reali con quelle digitali), deprivazione del sonno, frammentazione dell'attenzione e dipendenza. E la ricerca lo conferma: il consumo ripetuto di video brevi attiva ripetutamente il circuito della ricompensa cerebrale, portando a disregolazione dopaminergica, riduzione dell'attenzione sostenuta, aumento dell'impulsività e alterazione dei ritmi del sonno. In pratica, il cervello di questi ragazzi viene *riconfigurato* per funzionare in un modo che compromette il controllo cognitivo. ### La slot machine in tasca Qui bisogna essere espliciti su un punto che troppo spesso viene minimizzato: i social network non sono diventati dannosi per caso. Sono stati progettati per esserlo. I meccanismi psicologici che rendono i social media compulsivi sono gli stessi, identici (non "simili": identici), che rendono le slot machine dipendenti. Si chiamano "schemi di rinforzo a rapporto variabile": ricompense imprevedibili, intermittenti, di entità variabile. È il principio che B.F. Skinner documentò negli anni '50 studiando i piccioni: tra tutti gli schemi di rinforzo possibili, quello a rapporto variabile è il più potente nel mantenere un comportamento, e il più resistente all'estinzione. Ogni volta che scorri il feed di TikTok o Instagram, stai tirando la leva di una slot machine. Non sai quale scroll ti porterà qualcosa di interessante. Potrebbe essere il prossimo. O quello dopo. O fra dieci. Questa incertezza genera più attività dopaminergica di una ricompensa prevedibile. L'attesa, il non sapere, è essa stessa la droga. Solo che i casinò sono regolamentati. Devono dichiarare le probabilità di vincita. Non possono far entrare i minorenni. Non possono operare senza licenza. Le piattaforme social non hanno nessuno di questi vincoli. Natasha Schüll, autrice di *Addiction by Design* , lo ha detto con chiarezza: i social network usano gli stessi metodi dell'industria del gioco d'azzardo per mantenere gli utenti online, perché nell'economia dell'attenzione il fatturato è funzione del tempo trascorso sulla piattaforma. Il pull-to-refresh che riproduce il gesto della leva della slot machine. Le notifiche rosse che sfruttano l'effetto Zeigarnik, la tensione psicologica delle cose incomplete. Gli streak di Snapchat che trasformano l'amicizia in una metrica gamificata. L'algoritmo di TikTok che impara in poche ore esattamente quali contenuti ti terranno incollato allo schermo. Chamath Palihapitiya, ex vicepresidente della crescita di Facebook, lo ha ammesso pubblicamente: i cicli di feedback a breve termine basati sulla dopamina che abbiamo creato stanno distruggendo il funzionamento della società. Sean Parker, primo presidente di Facebook, ha dichiarato che l'obiettivo era "consumare la maggior quantità possibile del vostro tempo e della vostra attenzione consapevole" e che la piattaforma sfrutta "una vulnerabilità della psicologia umana". Non sono accuse esterne: sono ammissioni di chi quei sistemi li ha costruiti. Le ricerche interne lo confermavano: i documenti resi pubblici dalla whistleblower Frances Haugen hanno mostrato che Instagram sapeva di peggiorare i problemi di immagine corporea per una ragazza su tre. Lo sapevano. E hanno scelto i profitti. ### La differenza con le armi tradizionali Ed è qui che l'analogia con l'arma atomica del nostro esperimento mentale smette di essere un'iperbole. Un'arma convenzionale uccide il corpo. Il danno è visibile, immediato, documentabile. Il mondo se ne accorge. Ci sono foto, numeri, commemorazioni. Il danno attiva la risposta sociale: si dichiarano guerre, si firmano trattati, si costruiscono memoriali. I social network operano su un registro completamente diverso. Il danno è invisibile, graduale, cumulativo e, soprattutto, normalizzato. Nessuno vede un neurone che si riconfigura. Nessuno sente il rumore di una corteccia prefrontale che si assottiglia. Nessuno percepisce la deprivazione del sonno come un'emergenza quando riguarda cento milioni di adolescenti contemporaneamente. Il danno si nasconde dietro la quotidianità: "è solo il telefono", "tutti i ragazzi sono così", "noi da giovani stavamo davanti alla TV". Ma la TV non era progettata per creare dipendenza attraverso schemi di rinforzo a rapporto variabile. La TV non ti seguiva in camera da letto alle tre di notte. La TV non aveva un algoritmo che imparava quali insicurezze sfruttare per tenerti incollato allo schermo. La TV non ti dava una metrica numerica del tuo valore sociale aggiornata in tempo reale. E poi c'è la questione della scala. Una bomba distrugge una città. I social network stanno alterando lo sviluppo cerebrale di un'intera generazione su scala planetaria. Non di un gruppo specifico, non di una popolazione geograficamente circoscritta: di chiunque, ovunque nel mondo, abbia tra i 3 e i 20 anni e un dispositivo connesso. L'Organizzazione Mondiale della Sanità ha condotto un'indagine su quasi 280.000 giovani adolescenti in 44 paesi: l'11% mostrava segni di utilizzo problematico dei social media. Su scala globale, sono numeri che fanno impallidire qualsiasi altra emergenza sanitaria. E una bomba esplode una volta. I social network operano continuamente, 24 ore al giorno, 7 giorni su 7, 365 giorni all'anno. Non c'è cessate il fuoco. Non c'è trattato di pace. L'esposizione è cronica, ininterrotta, e inizia sempre prima: bambini di 3-4 anni con tablet programmati per intrattenerli, di 8-9 anni con il primo smartphone, di 11-12 anni già immersi nei social. Il 64% dei bambini americani di 11-12 anni usa già i social media. ### La distruzione delle famiglie I numeri non catturano un aspetto che riguarda il tessuto connettivo della società: la famiglia. Chi ha figli in età scolare sa di cosa parlo. Lo smartphone è diventato il principale campo di battaglia domestico. Non è una questione di "regole" o di "limiti al tempo-schermo": è una questione strutturale. Il dispositivo è progettato per essere più attraente, più stimolante, più gratificante di qualsiasi interazione familiare. Un genitore che legge una favola al figlio compete con un algoritmo che ha analizzato miliardi di interazioni per sapere esattamente cosa cattura l'attenzione di quel bambino. È una guerra asimmetrica, e la famiglia la sta perdendo. I genitori si sentono impotenti, inadeguati, costantemente in ritardo rispetto a una tecnologia che evolve più velocemente della loro capacità di comprenderla. I figli si sentono controllati, incompresi, isolati dai coetanei se non hanno accesso alle piattaforme. Il risultato è un'erosione quotidiana della fiducia, del dialogo, della connessione. Proprio le cose che rendono una famiglia una famiglia. Torniamo ad Anders e al suo dislivello prometeico: i genitori di oggi sono la prima generazione nella storia a dover proteggere i propri figli da una minaccia che non possono né vedere né comprendere pienamente. Non è come proteggere un bambino dal traffico o dall'alcol: quelle sono minacce visibili, con dinamiche conosciute. Qui la minaccia è un'architettura invisibile di persuasione algoritmica che opera direttamente sui circuiti neurologici della ricompensa. È come chiedere a un genitore del 1945 di proteggere suo figlio dalle radiazioni senza sapere cosa siano le radiazioni. ### Il mondo che sta già reagendo Il mondo, lentamente e troppo lentamente ma innegabilmente, sta iniziando a reagire. Il Surgeon General degli Stati Uniti, Vivek Murthy, ha paragonato la dipendenza dai social media a quella dalle sigarette e ha chiesto che le piattaforme includano un'avvertenza sanitaria. Nel 2023 ha avvertito che i bambini che passano più di tre ore al giorno sui social media raddoppiano il rischio di problemi di salute mentale. L'Australia, nel dicembre 2025, è diventata il primo paese al mondo a vietare l'accesso ai social media per i minori di 16 anni. La legge impone alle piattaforme di adottare "misure ragionevoli" per impedire ai minori di creare o mantenere account, con sanzioni fino a 49,5 milioni di dollari australiani per le aziende inadempienti. Ad oggi, oltre 4,7 milioni di account sono stati disattivati, rimossi o limitati. Francia, Norvegia, Danimarca, Malaysia, Spagna, Indonesia e l'Italia stessa stanno considerando o implementando misure simili. È un movimento globale che, significativamente, sta trovando resistenza proprio dove ci si aspetterebbe: dalle piattaforme stesse (Reddit ha presentato ricorso alla High Court australiana) e dai gruppi libertari che denunciano la violazione della libertà di espressione dei minori. È la stessa dinamica che abbiamo visto con il tabacco, con l'amianto, con il piombo nella benzina: l'industria che causa il danno combatte la regolamentazione invocando la libertà individuale e il progresso, mentre il danno si accumula silenziosamente nei corpi e nei cervelli delle vittime. ### La domanda che dobbiamo porci Se il progresso è l'espansione della capacità umana collettiva di vivere in modo libero, dignitoso e sostenibile, allora i social network nella loro forma attuale sono progresso? No. Non perché la tecnologia della connessione digitale sia intrinsecamente cattiva, ma perché il *modo* in cui è stata implementata (algoritmi di engagement che sfruttano le vulnerabilità neurologiche, modelli di business basati sulla dipendenza, assenza totale di responsabilità per i danni causati) rappresenta l'antitesi del progresso. È l'utilizzo della conoscenza neuroscientifica più avanzata per *ridurre* la capacità umana invece di espanderla. Se potessimo vedere il danno, se ogni assottigliamento della corteccia prefrontale producesse un rumore, se ogni episodio di autolesionismo adolescenziale fosse un'esplosione visibile, avremmo reagito con la stessa urgenza con cui reagiamo a una bomba. Ma il danno è silenzioso. E il silenzio è il miglior alleato di chi quel danno lo causa e lo monetizza. L'esperimento mentale del pensiero che uccide, a ben vedere, non è poi così ipotetico. Abbiamo già dato a delle aziende il potere di alterare lo sviluppo cerebrale di miliardi di giovani esseri umani. Il fatto che lo facciano per vendere pubblicità anziché per cattiveria non rende il danno meno reale. Lo rende solo più difficile da nominare. * * * ## L'Europa e la scelta umanistica {: #leuropa-e-la-scelta-umanistica } Ed è qui che dobbiamo parlare dell'Europa. Non dell'Europa delle lamentele, quella dei moduli in triplice copia e dei regolamenti sulle dimensioni delle zucchine. Ma dell'Europa come *progetto filosofico*. ### Il quadro regolatorio europeo come scelta di civiltà L'Unione Europea, negli ultimi anni, ha prodotto un corpus normativo sulla tecnologia che non ha equivalenti al mondo: il GDPR per la protezione dei dati personali, il Digital Services Act e il Digital Markets Act per regolare le piattaforme, l'AI Act per l'intelligenza artificiale, il Cyber Resilience Act per la sicurezza dei prodotti digitali, la Product Liability Directive aggiornata per includere il software e l'AI. Vista dalla Silicon Valley, questa è "burocrazia che frena l'innovazione". Vista dalla prospettiva della filosofia morale, è qualcosa di profondamente diverso: il tentativo più ambizioso nella storia di applicare i principi dell'umanesimo europeo alla rivoluzione tecnologica. Prendiamo l'AI Act. La sua struttura, basata sul rischio, con divieti assoluti per le applicazioni più pericolose (scoring sociale, manipolazione subliminale, sorveglianza biometrica di massa) e requisiti crescenti per quelle a rischio elevato, è una traduzione legislativa del principio di Jonas. Non dice "non innovate": dice "innovate, ma non a spese della dignità umana". Non è un freno: è un *timone*. La Product Liability Directive estesa al software è un altro esempio. Per la prima volta chi produce software sarà responsabile dei danni causati dai propri prodotti, esattamente come chi produce automobili, farmaci, elettrodomestici. Per chi ha interiorizzato l'idea che il software sia un'entità eterea, immateriale, esente dalle regole del mondo fisico, questo è uno scandalo. Per chi crede che il potere debba essere accompagnato dalla responsabilità, è una conquista di civiltà. Il Digital Services Act e il Digital Markets Act, poi, sono la risposta diretta alla catastrofe neurologica che abbiamo descritto. Il DSA impone alle piattaforme obblighi di trasparenza sugli algoritmi di raccomandazione, vieta la profilazione dei minori a fini pubblicitari e introduce la possibilità per gli utenti di disattivare i sistemi di raccomandazione personalizzata. Il DMA cerca di spezzare il potere monopolistico delle grandi piattaforme, quei "gatekeeper" che controllano l'accesso digitale di miliardi di persone. Sono strumenti imperfetti? Certamente. Ma sono gli unici strumenti che una democrazia ha a disposizione per rispondere a un potere che, lasciato senza vincoli, sta letteralmente riconfigurando il cervello dei suoi cittadini più giovani. ### L'accessibilità come paradigma del progresso autentico L'European Accessibility Act merita una menzione speciale, perché incarna perfettamente la differenza tra progresso tecnico e progresso umano. L'EAA obbliga i prodotti e i servizi digitali a essere accessibili alle persone con disabilità. Per un'azienda tech focalizzata esclusivamente sulla velocità e sull'efficienza, questo è un costo, un vincolo, un "freno al progresso". Ma fermiamoci un momento: un'innovazione che esclude una parte dell'umanità è davvero progresso? Se definiamo il progresso come l'espansione delle possibilità umane (non le possibilità di *alcuni* umani, ma dell'umanità nel suo insieme) allora l'accessibilità non è un vincolo al progresso. *È* il progresso. Un prodotto digitale che il 15% della popolazione mondiale non può usare non è innovativo: è incompleto. Martha Nussbaum, nel suo *capabilities approach* (sviluppato insieme ad Amartya Sen), ha formulato una teoria del progresso che va esattamente in questa direzione: il progresso si misura non dal PIL, non dal numero di brevetti, non dalla velocità dei processori, ma dalla capacità effettiva degli individui di vivere una vita degna di essere vissuta. Se una tecnologia aumenta questa capacità per tutti, è progresso. Se la aumenta per alcuni a spese di altri, è potere. Non progresso. * * * ## La confusione tra velocità e direzione {: #la-confusione-tra-velocita-e-direzione } C'è un errore categoriale che permea tutto il discorso contemporaneo sull'innovazione: la confusione tra velocità e direzione. "Move fast and break things", il motto originale di Facebook, è l'epitome di questa confusione. Muoversi velocemente è un valore solo se la direzione è giusta. Altrimenti è solo correre verso un precipizio con maggiore efficienza. Quando Sam Altman dice che "la regolamentazione rischia di rallentare lo sviluppo dell'AI", la domanda che nessuno gli fa è: *rallentare verso dove?* Se la direzione è la concentrazione del potere nelle mani di poche aziende, il rafforzamento dei bias algoritmici, la sorveglianza capillare mascherata da personalizzazione, allora rallentare non è un danno. È saggezza. Epicuro, il più materialista e il meno mistico dei filosofi antichi, insegnava che il fine della vita è la *atarassia* : la tranquillità dell'animo, l'assenza di turbamento. Non l'accumulo di potere, non la conquista della natura, non la velocità. La tranquillità. Lezione che la civiltà tech sembra aver dimenticato completamente: non tutto ciò che è possibile è desiderabile. Non tutto ciò che è veloce è buono. Non tutto ciò che è nuovo è migliore. Simone de Beauvoir, ne *L 'etica dell'ambiguità* (1947), offre un altro strumento importante: la libertà non è mai assoluta, ma sempre *situata*. Siamo liberi solo nel contesto di relazioni con altri esseri liberi. La mia libertà ha senso solo se riconosco e preservo la libertà degli altri. Trasferito al contesto tecnologico: la mia libertà di innovare ha senso solo se non distrugge la libertà, la sicurezza, la dignità, l'autonomia di chi sarà toccato dalla mia innovazione. * * * ## Il progresso come costruzione collettiva {: #il-progresso-come-costruzione-collettiva } È tempo di proporre una definizione alternativa. Se il progresso non è semplicemente innovazione tecnica, se non è velocità, se non è accumulo di capacità, cos'è? Propongo questa: il progresso è l'espansione della capacità umana collettiva di vivere in modo libero, dignitoso e sostenibile. Ogni parola conta. Espansione, perché il progresso è un ampliamento, non una sostituzione; non demolisce ciò che funziona per inseguire il nuovo. Capacità umana, non la capacità delle macchine o dei mercati ma la capacità delle persone reali di agire nel mondo. Collettiva, perché se non è per tutti non è progresso: è privilegio. Libero, nel senso milliano di libertà di pensare, dire, vivere come si vuole, nei limiti del danno agli altri. Dignitoso, nel senso kantiano della dignità di ogni persona come fine in sé, mai solo come mezzo. Sostenibile, che non sacrifica il futuro per il presente, che non ruba ai nipoti per regalare ai figli. Con questa definizione, molte cose cambiano. La penicillina è progresso. Il suffragio universale è progresso. L'acqua potabile per tutti è progresso. L'accessibilità digitale è progresso. Il GDPR è progresso. La bomba atomica non è progresso. La sorveglianza di massa non è progresso. Un algoritmo che massimizza l'engagement attraverso la dipendenza non è progresso. Una piattaforma che assottiglia la corteccia prefrontale di milioni di adolescenti per vendere pubblicità non è progresso. E il pensiero che uccide, la nostra ipotesi iniziale, non è progresso. È la fine del progresso. È la fine di tutto. * * * ## L'umanesimo come bussola, non come catena {: #lumanesimo-come-bussola-non-come-catena } Torniamo, per chiudere, alla domanda iniziale. Quando qualcuno dice che lo Stato o l'Europa o le Nazioni Unite "incatenano il progresso", cosa sta realmente dicendo? Sta dicendo, quasi sempre, che il *suo* modo di innovare, il *suo* modello di business, la *sua* visione del futuro viene sottoposta a vincoli che non gradisce. Sta confondendo la propria libertà d'azione con la libertà dell'umanità. Sta scambiando l'assenza di limiti per l'assenza di oppressione. Ma l'assenza di limiti non è libertà: è la legge del più forte. È lo stato di natura hobbesiano, il *bellum omnium contra omnes* , la guerra di tutti contro tutti, in cui la vita è "solitaria, povera, sordida, brutale e breve". Le istituzioni, le leggi, i vincoli reciproci non sono catene: sono le fondamenta della convivenza. Sono ciò che rende possibile non solo la sopravvivenza, ma la fioritura umana. L'umanesimo, quello vero, quello che nasce con Pico della Mirandola e arriva fino a Nussbaum passando per Montaigne, Hume, Voltaire, Mill, Arendt e de Beauvoir, non è mai stato contro la conoscenza o la tecnica. È stato contro l'uso della conoscenza e della tecnica *contro l 'umano*. L'umanesimo è la bussola che ci permette di distinguere il progresso autentico dalla mera accumulazione di potere. Chi costruisce tecnologia oggi ha una responsabilità immensa, probabilmente la più grande che qualsiasi generazione abbia mai avuto. Non perché la tecnologia sia male, ma perché la tecnologia è *potente*. E il potere senza responsabilità, senza limiti, senza la capacità di autocorreggersi, non è progresso. È solo pericolo che si muove veloce. * * * ## Post scriptum: una nota personale {: #post-scriptum-una-nota-personale } Lavoro nella tecnologia da vent'anni. Costruisco software. Gestisco infrastrutture. Configuro pipeline CI/CD, scrivo specifiche, pianifico sprint. La tecnologia è il mio mestiere e, per molti aspetti, la mia passione. Proprio perché la conosco intimamente, le sue meraviglie e le sue miserie, la sua potenza e la sua fragilità, rifiuto con ogni fibra l'idea che regolamentarla sia un atto ostile. Quando implemento il GDPR in un progetto, non sto "frenando l'innovazione": sto proteggendo le persone per cui quel progetto esiste. Quando l'AI Act mi chiede di documentare i rischi di un sistema ad alto rischio, non sto "perdendo tempo": sto facendo il mio lavoro con la serietà che merita. Quando l'EAA mi obbliga a rendere accessibile un'interfaccia, non sto "aggiungendo costi": sto includendo esseri umani che altrimenti resterebbero esclusi. Ma c'è un'altra ragione, più personale e più urgente, per cui questo tema mi brucia. Sono anche padre. E come padre, vivo ogni giorno la consapevolezza che il mondo digitale in cui mio figlio crescerà è stato progettato da persone che fanno il mio stesso mestiere, persone che sanno esattamente cosa stanno facendo ai circuiti della ricompensa di un cervello in sviluppo. Conosco i design pattern, conosco le metriche, conosco il linguaggio con cui si discutono le strategie di "retention" e "engagement". So che dietro parole neutre si nascondono meccanismi di dipendenza deliberatamente ingegnerizzati. E so che la mia competenza tecnica non è sufficiente a proteggere un bambino da un'industria che ha investito miliardi di dollari per imparare a catturare la sua attenzione. Per questo credo che la regolamentazione non sia solo legittima: sia un atto di civiltà. Chi costruisce tecnologia ha l'obbligo morale di costruirla *per* gli esseri umani, non *contro* di loro. E quando non lo fa, è giusto e necessario che la società, attraverso le sue istituzioni imperfette, lente, esasperanti, intervenga. Il progresso autentico non è mai stato veloce. È stato faticoso, conflittuale, pieno di ripensamenti e correzioni di rotta. È stato, per usare la metafora di Popper, un processo di congetture e confutazioni, non una marcia trionfale. E le istituzioni che lo governano, imperfette, lente, a volte esasperanti, sono il prezzo che paghiamo per non affidare il destino dell'umanità a chi corre più veloce. Non è un prezzo alto. È un affare. * * * *" Il grado di civiltà di una società si misura dalla quantità di potere a cui è disposta a rinunciare."* — liberamente ispirato a Norbert Elias, *Il processo di civilizzazione* (1939) --- # Da developer a partner: una carriera nei servizi IT - **URL:** https://margiovanni.it/it/blog/da-developer-a-partner-una-carriera-nei-servizi-it/ - **Pubblicato:** 2026-03-24 - **Tag:** Carriera Tech, Consulenza, Servizi IT, Sourcing IT - **Tempo di lettura:** 7 min > Tre ruoli, tre lenti sul mercato IT: corporate, startup e portfolio clienti. Un percorso non lineare che chiarisce cosa conta davvero nel sourcing. Mi capita spesso di sentire persone parlare di carriera come se fosse una scala. Un gradino dopo l’altro, un titolo dopo l’altro, e alla fine una specie di senso compiuto. Poi guardo la mia e mi viene da sorridere, perché non ci vedo una scala. Ci vedo più una serie di stanze diverse, ognuna con una finestra su un pezzo del mercato dei servizi IT. Non è un racconto “motivazionale”. È più una cosa da taccuino, quasi un’anatomia. Perché a posteriori mi accorgo che ogni fase mi ha lasciato una lente diversa. E oggi, che lavoro come Head of Tech e partner in una piccola realtà ICT, quelle lenti iniziano davvero a sovrapporsi. ## La cosa strana delle carriere non lineari {: #la-cosa-strana-delle-carriere-non-lineari } Le carriere lineari forse non sono mai esistite davvero, ma per un po’ ci abbiamo creduto. Io sicuramente sì. Poi mi sono ritrovato a passare da Interface Developer in uno dei più grandi gruppi e-commerce di lusso europei (prima che entrasse nell’orbita Richemont), a CTO in una startup deep-tech sull’oil & gas, fino a gestire un portfolio di progetti molto diversi tra loro in una società di circa dieci persone. Se devo dire cosa accomuna queste tappe, non è la tecnologia. Quella cambia, e cambia più in fretta di quanto ci piaccia ammettere. Il filo conduttore è un altro: ogni ruolo mi ha fatto vedere *come si comprano e si vendono* servizi IT. E soprattutto perché spesso le decisioni che sembrano tecniche, tecniche non sono. ## Fase 1: dentro un grande player, dal lato del codice {: #fase-1-dentro-un-grande-player-dal-lato-del-codice } Quando sei in una grande organizzazione e non sei nel management, rischi di pensare che certe dinamiche non ti riguardino. In realtà ti attraversano lo stesso, solo che le vivi “di riflesso”. Io ero nel codice, ma lavorare in un gruppo di quella scala ti fa vedere cose che da fuori restano invisibili. Per esempio, come si gestisce davvero la relazione con i fornitori tecnologici. Non in teoria, non nel deck, ma nel quotidiano. Ho visto che dietro una scelta architetturale spesso c’è una scelta organizzativa, di budget, a volte persino di potere. E ho visto anche una differenza che all’inizio mi dava fastidio, poi ho capito che era semplicemente reale: vendor scelti per competenza e vendor scelti per inerzia contrattuale non sono la stessa cosa, ma nei documenti sembrano identici. La prima regola che mi porto dietro da quella fase è questa, e forse è un po’ cinica, ma mi sembra vera. **Il fornitore migliore non è quello con la proposta migliore, è quello che capisce come funziona l’organizzazione del cliente.** È una regola difficile da mettere in un framework. È qualitativa, contestuale. E richiede una comprensione delle dinamiche interne che spesso si acquisisce solo stando lì, per osmosi. Mi chiedo ancora oggi quante gare e quante selezioni falliscano non perché il provider non sia capace, ma perché non ha letto il “sistema nervoso” del cliente. ## Fase 2: la startup, cioè il costo reale delle scelte {: #fase-2-la-startup-cioe-il-costo-reale-delle-scelte } Il salto verso la startup è stato, senza esagerare, quello che mi ha cambiato di più. Come CTO di una startup deep-tech verticale sull’oil & gas mi sono ritrovato a fare tutto. Stack tecnologico, assunzioni, processi, budget, clienti, delivery. Tutto insieme, spesso nello stesso giorno. E lì impari una cosa che nelle grandi aziende resta più sfumata: il costo delle decisioni non è un concetto astratto. È immediato. Ogni scelta ha un impatto diretto sul conto economico, sul time-to-market, sulla sostenibilità del team. In quella fase ho imparato a prezzare i servizi IT non “in base al mercato”, ma in base alla struttura dei costi reali. Che sembra banale finché non ti ci schianti contro. Ho imparato anche che un servizio prezzato troppo basso è più pericoloso di uno prezzato troppo alto, perché prima o poi qualcuno pagherà la differenza. E spesso a pagare è il cliente, sotto forma di debito tecnico, ritardi, turnover, patch messe di corsa. Un altro pezzo importante sono stati i contratti. Non quelli scritti per vincere una trattativa, ma quelli che ti permettono di lavorare. Ho capito che esistono contratti che “proteggono” e contratti che “funzionano”. I primi sono pieni di penali che nessuno vuole applicare. I secondi definiscono incentivi allineati, una zona di collaborazione dove entrambe le parti hanno convenienza a fare la cosa giusta. La seconda regola, qui, è diventata quasi una convinzione. **La qualità di un servizio IT si decide prima che il progetto inizi, nelle scelte architetturali e nei processi che il provider mette in piedi.** Quando il codice comincia a scorrere, molte partite sono già state giocate. Non tutte, certo. Ma tante sì. ## Fase 3: il portfolio multi-cliente, dove i confini sfumano {: #fase-3-il-portfolio-multi-cliente-dove-i-confini-sfumano } Oggi lavoro in una realtà ICT piccola, circa dieci persone, che opera come partner tecnologico B2B. I clienti vanno da grandi corporate a Pubbliche Amministrazioni. Il mio ruolo è un incrocio continuo tra leadership tecnica, sprint planning, DevOps, compliance e architettura. E soprattutto è un lavoro “a portfolio”, quindi con contesti molto diversi che convivono. Nello stesso periodo possiamo essere coinvolti su un sistema informativo sanitario regionale, su una piattaforma SaaS di people analytics, su un’infrastruttura IoT industriale, su servizi di cybersecurity come partner certificato di un vendor leader, su progetti di compliance normativa e su sviluppo custom per la PA. Questa fase è quella in cui le due esperienze precedenti si incastrano. Da un lato ho la memoria del grande player, quindi capisco come ragionano i clienti enterprise, cosa li preoccupa davvero, quali sono i vincoli impliciti. Dall’altro ho la sensibilità della startup, quindi so cosa vuol dire fare efficienza con risorse limitate, e quanto contino automazione e disciplina operativa. Ma la lezione nuova, quella che non mi aspettavo, è un’altra. **Il mercato dei servizi IT è frammentato in modi che molti framework di advisory non catturano.** Non siamo un system integrator generalista, ma non siamo nemmeno una boutique ultra-specialistica. Siamo quella cosa un po’ scomoda da etichettare: un partner tecnologico agile con competenze trasversali. E in certi contesti competiamo con player dieci volte più grandi, non perché siamo “migliori” in assoluto, ma perché i processi sono più snelli e, sempre di più, perché l’AI-assisted development sta cambiando i rapporti tra capacità produttiva e dimensione del team. Forse è qui che mi sono reso conto di quanto la mappa non coincida con il territorio. Nei quadranti e nei report alcune categorie sono nitide. Nella vita reale, molto meno. ## Cosa mi hanno insegnato queste fasi sul sourcing IT {: #cosa-mi-hanno-insegnato-queste-fasi-sul-sourcing-it } Se provo a tradurre tutto questo in implicazioni pratiche per il sourcing, mi vengono in mente tre idee, che poi sono tre “difetti” ricorrenti nel modo in cui si valutano i provider. La prima viene dalla grande azienda: le decisioni di sourcing sono spesso decisioni organizzative mascherate da decisioni tecniche. Quindi chi fa advisory dovrebbe capire le dinamiche interne del cliente tanto quanto capisce le capability del provider. Altrimenti rischia di consigliare il “migliore sulla carta” e ottenere il peggiore in pratica. La seconda viene dalla startup: l’economia dei servizi IT è molto più granulare di quanto appaia nei report di mercato. Il margine di un provider su un singolo progetto può oscillare in modo enorme in base alle scelte architetturali, al livello di automazione, alla maturità dei processi. E se non leggi queste dinamiche, non proteggi davvero il cliente. Lo proteggi solo formalmente. La terza viene dal lavoro a portfolio: il mercato reale è più diversificato di quanto i framework suggeriscano. Le PMI tecnologiche che servono il tessuto economico europeo spesso non appaiono nei quadranti, ma erogano una quota significativa dei servizi IT. Se non conosci quel segmento, stai offrendo ai clienti un set di opzioni incompleto. E magari nemmeno te ne accorgi. ## Il valore cumulativo, e perché conta adesso {: #il-valore-cumulativo-e-perche-conta-adesso } C’è un pattern che noto nelle carriere che producono valore “non convenzionale”. Non è la singola esperienza a fare la differenza, ma l’intersezione. Un analista che ha lavorato solo in consulting conosce i framework, ma magari non ha mai vissuto il delivery quando le cose vanno storte. Un tecnico che ha lavorato solo in development conosce il codice, ma non sempre vede il business. Un manager che ha lavorato solo in corporate conosce le dinamiche politiche, ma rischia di perdere il contatto con i costi reali e con la fatica operativa. Il senso della mia traiettoria, se ne ha uno, è attraversare questi mondi. E mi sembra che oggi questa capacità di connessione non sia più un “plus”. Con ai che entra nei processi, compliance europea che diventa sempre più stringente, modelli di pricing che cambiano, reshoring e nuove aspettative su sicurezza e sovranità del dato, la complessità non diminuisce. Aumenta. E quando la complessità aumenta, le risposte semplici iniziano a suonare sospette. ## Il passo successivo, con un po’ di onestà {: #il-passo-successivo-con-un-po-di-onesta } Negli ultimi tempi sento che la naturale evoluzione di questo percorso sia portare questa prospettiva integrata a chi deve prendere decisioni di sourcing ad alto impatto. Non come consulente operativo, quello lo faccio già. Piuttosto come analista di mercato, ricercatore, advisor strategico. In un contesto in cui la profondità di esperienza operativa e la capacità di produrre insight azionabili siano il cuore della proposta di valore. È il tipo di ruolo che alcune aziende, con molta fatica e molti investimenti, provano ad incarnare bene. Non perché io abbia le risposte giuste. Su molte cose, sinceramente, non sono nemmeno sicuro di avere una risposta unica. Ma perché credo di avere le domande giuste, quelle che vengono dall’aver visto il mercato dei servizi IT da angolazioni diverse. E forse è proprio questo, oggi, che serve di più. *Prossimo nella serie: come la tempesta regolatoria europea sta ridefinendo i criteri di valutazione dei provider IT, e perché il mercato dell’advisory non è ancora pronto.* --- # Cosa sa un provider IT che un analista di sourcing non sa - **URL:** https://margiovanni.it/it/blog/cosa-sa-un-provider-it-che-un-analista-di-sourcing-non-sa/ - **Pubblicato:** 2026-03-23 - **Tag:** Advisory IT, Servizi IT, Sourcing, Consulenza - **Tempo di lettura:** 5 min > Il punto cieco strutturale del mercato dell'IT services advisory. E perché colmarlo è urgente. C'è un paradosso nel mercato dell'advisory sui servizi IT che mi colpisce da anni: le persone incaricate di consigliare alle aziende come scegliere i propri fornitori tecnologici sono, nella stragrande maggioranza dei casi, persone che un servizio IT non lo hanno mai costruito, prezzato, consegnato o difeso davanti a un cliente insoddisfatto. Non è una critica. È un'osservazione strutturale. E ha conseguenze reali su come le decisioni di sourcing vengono prese, e su quante di queste decisioni si rivelano sbagliate. ## Il mestiere visto da dentro {: #il-mestiere-visto-da-dentro } Ho passato più di quindici anni dall'altra parte del tavolo. Non come chi valuta i servizi IT, ma come chi li progetta, li vende, li eroga e ne risponde quando qualcosa non funziona. In YNAP (Yoox per i più vecchietti) ho visto come una delle più grandi piattaforme e-commerce europee gestiva la relazione con i propri fornitori tecnologici. Non in teoria: nella pratica quotidiana delle scelte architetturali, delle negoziazioni sui deliverable, delle decisioni che determinano se un progetto consegna valore o consegna solo codice. Come CTO di Anthis ho costruito da zero l'infrastruttura tecnica e i processi di delivery di un'azienda. È l'esperienza che ti insegna che la differenza tra un servizio IT che funziona e uno che no non sta quasi mai nella tecnologia scelta, ma nella qualità del processo decisionale che porta a quella tecnologia. E oggi, come Head of Tech & Partner di Oltrematica (lo so, non esiste questo ruolo ma ci arriveremo), governo un portfolio di progetti per clienti che vanno da TIM a Randstad, dalla Regione Abruzzo alle Camere di Commercio. Scrivo RFP e rispondo a RFP. Definisco SLA e li devo rispettare. Prezzo servizi gestiti sapendo esattamente quanto costa ogni componente della catena di delivery. Questa esperienza mi ha dato accesso a un tipo di conoscenza che è difficile - forse impossibile - da acquisire dall'esterno. ## Le cose che si vedono solo da dentro {: #le-cose-che-si-vedono-solo-da-dentro } Quando leggo i framework di valutazione dei provider IT (Magic Quadrant, PEAK Matrix, ISG Provider Lens) riconosco la qualità dell'analisi e il rigore metodologico. Ma vedo anche i punti ciechi. E sono sempre gli stessi. ### Il costo reale di un servizio IT non è nel prezzo Il prezzo quotato in un'offerta di servizi gestiti è un numero. Il costo reale è un sistema complesso che include il prezzo, più il costo delle inefficienze di comunicazione, più il costo del debito tecnico che si accumula quando il provider taglia angoli per stare dentro il budget, più il costo opportunità delle funzionalità che non vengono consegnate perché il contratto non le prevede. Un analista che valuta i provider confrontando le tariffe giornaliere sta misurando la variabile sbagliata. Un provider che quota 400€/giorno e consegna in 20 giorni costa meno di uno che quota 300€/giorno e ne impiega 40. Ma per capire chi dei due consegnerà in 20 e chi in 40, devi saper leggere l'architettura tecnica proposta, la composizione del team, il livello di automazione dei processi di delivery. È una competenza che viene dall'aver costruito quei processi, non dall'averli osservati. ### Gli SLA sono un linguaggio, non solo un contratto Nella mia esperienza, la maggior parte dei problemi nei contratti di outsourcing IT non nasce da SLA sbagliati. Nasce da SLA ambigui. Un SLA che dice "disponibilità del 99.9%" è tecnicamente preciso ma operativamente vuoto se non specifica: come si misura la disponibilità? Si include la manutenzione programmata? Quale finestra temporale viene usata per il calcolo? Cosa succede quando il downtime è causato da un terzo (il cloud provider, il CDN, il DNS)? Ho scritto SLA per anni. E ho imparato che un buon SLA non è quello che promette di più, ma quello che definisce con precisione chirurgica cosa succede quando le cose vanno male. Perché nei servizi IT, le cose vanno sempre male prima o poi. La qualità del provider si misura nella risposta, non nella promessa. ### La composizione del team è più importante della dimensione I framework di valutazione tendono a premiare i provider con grandi team e molteplici delivery center. È una metrica rassicurante per chi compra: più persone = più capacità. Ma chi ha gestito team di sviluppo sa che non è così. Un team di 5 sviluppatori senior coordinati bene produce più output di qualità di un team di 15 persone con 3 livelli di management e rotazione continua. Soprattutto quando quel team di 5 usa metodologie AI-native che moltiplicano la produttività individuale. In Oltrematica gestiamo simultaneamente 8-10 progetti attivi con un team di circa 10 persone. Non perché siamo eroi, ma perché abbiamo investito in automazione, in processi di delivery efficienti, in strumenti che eliminano il lavoro a basso valore aggiunto. È il tipo di efficienza che non appare in nessun quadrante. ## Il valore della prospettiva operativa nell'advisory {: #il-valore-della-prospettiva-operativa-nelladvisory } Non sto suggerendo che tutti gli analisti debbano aver lavorato come provider IT. Sto suggerendo che la prospettiva operativa è un asset strategico nell'advisory che oggi è drammaticamente sottorappresentato. Quando un CISO mi chiede se un provider di managed security è affidabile, non devo basarmi solo sulle certificazioni e sulle referenze. Posso leggere l'architettura proposta e capire se è stata progettata per essere operata o solo per vincere la gara. Posso guardare lo Statement of Work e identificare le aree grigie che diventeranno controversie contrattuali tra 18 mesi. Posso valutare se il modello di staffing proposto è sostenibile o se il provider sta promettendo un team che non ha e che dovrà costruire after-the-fact. Questo tipo di insight non viene dal rigore analitico. Viene dall'aver vissuto le stesse dinamiche dall'altra parte. E ha un valore enorme per i clienti enterprise che stanno per prendere decisioni di sourcing da milioni di euro. ## La convergenza necessaria {: #la-convergenza-necessaria } Il mercato dell'IT services advisory sta entrando in una fase in cui la complessità delle decisioni di sourcing sta aumentando esponenzialmente. AI, compliance europea, reshoring, nuovi modelli di pricing, cybersecurity by design: sono tutte dimensioni che richiedono una comprensione tecnica profonda per essere valutate correttamente. I framework generici non bastano più. I clienti chiedono - **e hanno diritto di ottenere** \- advisor che parlino il linguaggio dei provider con la stessa fluenza con cui parlano il linguaggio del business. È una convergenza che il mercato non ha ancora prodotto in modo sistematico. Ma che è inevitabile. E chi la anticiperà avrà un vantaggio competitivo enorme. * * * *Questo articolo è il primo di una serie sulla mia visione del mercato IT services sourcing. Nel prossimo pezzo esplorerò il mio percorso personale - da developer a partner - e come ogni fase ha contribuito a costruire una prospettiva integrata sul mercato dei servizi IT.* --- # Chi possiede il banco da lavoro - **URL:** https://margiovanni.it/it/blog/chi-possiede-il-banco-da-lavoro/ - **Pubblicato:** 2026-03-20 - **Tag:** AI, Anthropic, Coding Agents, Developer Tools - **Tempo di lettura:** 8 min > OpenAI compra Astral, Anthropic ha comprato Bun. La colonizzazione silenziosa dello stack di sviluppo è già iniziata, e non è una questione di open source. C'è una frase su Hacker News che mi è rimasta in testa da ieri sera, da quando ho letto la notizia dell'acquisizione di Astral da parte di OpenAI. La frase dice: "OpenAI and Anthropic are making plays to own the means of production in software." I mezzi di produzione. È una di quelle espressioni che suonano un po' eccessive la prima volta che le leggi, e poi ci pensi, e ci ripensi, e alla fine ti rendi conto che forse non sono eccessive abbastanza. Astral è la startup dietro uv, Ruff e ty, tre strumenti che in pochi anni sono diventati parte dell'infrastruttura quotidiana di milioni di sviluppatori Python. uv ha risolto il problema della gestione degli ambienti e delle dipendenze con un'eleganza e una velocità che pip non ha mai avuto. Ruff ha reso il linting e il formatting talmente rapidi da renderli invisibili, e ty sta facendo lo stesso con il type checking. Sono strumenti scritti in Rust, tutti open source, tutti con licenza permissiva. E da ieri tutti di proprietà di OpenAI, che li integrerà nel team di Codex, il suo agente di coding che ha già superato i due milioni di utenti settimanali attivi. Tre mesi fa, a dicembre, Anthropic aveva fatto una mossa simile comprando Bun, il runtime JavaScript creato da Jarred Sumner. Claude Code, il loro strumento di coding agentico che ha raggiunto un miliardo di dollari di revenue annualizzata in sei mesi, gira come eseguibile Bun. Sumner lo ha detto con una chiarezza quasi brutale nel suo post di annuncio: "If Bun breaks, Claude Code breaks." E quindi Anthropic ha comprato l'infrastruttura su cui il suo prodotto da un miliardo di dollari si regge. Due acquisizioni in tre mesi, da parte delle due aziende che si contendono il mercato degli strumenti di coding assistito da ai. Se le guardi singolarmente, ciascuna ha la sua logica. Se le guardi insieme, il pattern è inequivocabile. E il pattern è questo: le aziende che costruiscono modelli di linguaggio stanno comprando, pezzo dopo pezzo, la toolchain su cui quei modelli operano. Non il cloud, non i chip, non i data center. Gli strumenti che stanno tra il modello e il codice. Il package manager. Il linter. Il runtime. Il type checker. Tutto ciò che serve a un agente ai per non limitarsi a generare codice, ma per eseguirlo, testarlo, validarlo, e rimetterlo in produzione. Questo non è filantropia verso l'open source. È strategia infrastrutturale. ## Il novantacinque per cento è contesto {: #context-is-95-percent } Per capire cosa sta succedendo bisogna partire da un dato che spesso viene sottovalutato: i modelli di linguaggio, da soli, generano codice. Ma generare codice non è sviluppare software. Lo sa chiunque abbia provato a far scrivere un progetto intero a un agente e si sia ritrovato con qualcosa che compila ma non funziona, o che funziona ma non rispetta le convenzioni del repository, o che rispetta le convenzioni ma rompe tre test che nessuno aveva previsto. La generazione è il cinque per cento del lavoro. Il restante novantacinque per cento è contesto: risolvere le dipendenze, far passare il linter, gestire i tipi, eseguire i test, integrare nel flusso di CI/CD, mantenere il codice nel tempo quando le librerie si aggiornano e i requisiti cambiano. E qui sta il punto. Un agente ai che vuole fare quel novantacinque per cento ha bisogno di possedere, o quantomeno di controllare, gli strumenti che lo compongono. Non basta sapere che uv esiste. Serve che uv risponda alle esigenze dell'agente, che sia ottimizzato per i suoi flussi di lavoro, che evolva nella direzione che rende l'agente più efficace. La stessa cosa vale per Ruff, per ty, per Bun. Quando OpenAI scrive nel suo annuncio che l'obiettivo è "move beyond AI that simply generates code and toward systems that can participate in the entire development workflow," non sta facendo marketing. Sta descrivendo esattamente perché ha comprato Astral. Lo vedo tutti i giorni nel mio lavoro. Uso Claude Code su progetti Laravel, gestisco pipeline di CI/CD con GitHub Actions, e la differenza tra un agente che genera un file e un agente che capisce il contesto in cui quel file deve vivere è la differenza tra uno strumento utile e un giocattolo. Quando l'agente conosce le regole del mio linter, sa come sono strutturate le mie dipendenze, capisce il mio flusso di deployment, allora diventa davvero un collaboratore. E per essere quel tipo di collaboratore, deve parlare la lingua degli strumenti che uso. Se chi costruisce l'agente possiede anche quegli strumenti, il vantaggio competitivo è enorme. ## Un lock-in di nuovo tipo {: #new-kind-of-lock-in } Ma è proprio qui che la cosa diventa interessante, e un po' inquietante. Perché quello che sta emergendo è un nuovo tipo di vendor lock-in, diverso da tutto ciò che abbiamo visto prima. Il vecchio lock-in era esplicito: sceglievi un cloud provider, sceglievi un database proprietario, e a un certo punto migrare costava troppo. Lo sapevi, facevi i tuoi conti, prendevi la decisione. Il nuovo lock-in è diverso. È implicito. Non ti accorgi che sta succedendo perché ogni singolo pezzo sembra open source, sembra libero, sembra neutrale. uv è ancora sotto licenza MIT. Bun è ancora sotto licenza MIT. Puoi forkare, puoi usarli senza Codex o Claude Code, puoi fare quello che vuoi. Ma la domanda è un'altra: tra due anni, quando l'ottanta per cento dell'evoluzione di uv sarà guidata dalle esigenze di Codex, quando le feature prioritarie saranno quelle che servono all'agente di OpenAI e non quelle che servono a te che usi uv da terminale, il fork sarà davvero un'opzione praticabile? Simon Willison, che ha una delle menti più lucide dell'ecosistema, ieri ha scritto che lo scenario peggiore ha la forma di "fork and move on." Ma poi ha aggiunto, onestamente, che OpenAI non ha ancora un track record nel mantenere progetti open source acquisiti. E che un'acquisizione che nasce come prodotto più talento può trasformarsi, nel tempo, in un'acquisizione di solo talento. Questo è un punto su cui continuo a tornare. Il codice resta aperto, ma la direzione diventa chiusa. È una forma di controllo che non viola nessuna licenza, non tradisce nessuna promessa esplicita, e che tuttavia concentra potere in modo significativo. Qualcuno su Hacker News ha descritto bene la dinamica: "As they gobble up previously open software stacks, how viable is it that these stacks remain open?" La viabilità tecnica resta, la viabilità pratica si erode. Lo scrivo e sento già le obiezioni, le stesse che mi sono fatto io. "Ma gli incentivi sono allineati," dicono in molti. "Anthropic ha bisogno che Bun funzioni bene per tutti, non solo per Claude Code, perché l'adozione diffusa crea effetti di rete." Ed è vero, almeno oggi. "La licenza MIT protegge la community," dicono altri. Ed è vero anche questo, almeno in teoria. Ma io ho visto abbastanza acquisizioni nella mia carriera per sapere che le promesse del giorno dell'annuncio hanno una data di scadenza non scritta. Il post di Jarred Sumner è stato onesto su questo punto: "No one can guarantee how motives, incentives, and decisions might change years down the line." E aggiungerei che gli incentivi di una startup con zero revenue e quattro anni di runway davanti sono molto diversi dagli incentivi di una divisione dentro un'azienda che brucia due dollari e mezzo per ogni dollaro di fatturato e deve giustificare ogni acquisizione davanti a investitori che aspettano un'IPO. ## La battaglia per il workflow {: #battle-for-the-workflow } C'è anche un altro aspetto che mi colpisce, e che riguarda il modo in cui queste acquisizioni ridefiniscono la competizione. Fino a ieri, la battaglia tra OpenAI e Anthropic si giocava sulla qualità dei modelli. Chi ragiona meglio, chi genera codice più pulito, chi ha il contesto più lungo. Oggi la battaglia si sta spostando su un piano diverso: chi controlla più superficie del flusso di lavoro dello sviluppatore. Non è più solo "il mio modello è più bravo del tuo." È "il mio modello lavora dentro un ecosistema che possiedo e che ottimizza ogni passaggio." La generazione del codice diventa una commodity, e il valore si sposta sull'orchestrazione dell'intero ciclo. Chi possiede il linter, il package manager, il runtime e l'agente di coding ha un vantaggio strutturale che nessun benchmark può catturare. La domanda che mi faccio, e che non ha ancora una risposta chiara, è cosa significhi tutto questo per chi lavora con stack diversi da Python e JavaScript. Il mondo di tanti team ad esempio non ha (ancora) subito questo tipo di concentrazione (pensate a chi lavora su altri Stack). Ma il pattern è chiaro, e si espanderà. Oggi è Python e JavaScript perché sono i linguaggi dell'ai e del web. Domani potrebbe essere qualsiasi ecosistema in cui gli agenti di coding hanno bisogno di tooling affidabile per operare in autonomia. La corsa ad acquisire i mattoni dell'infrastruttura di sviluppo è appena iniziata. Mi viene in mente un'analogia che forse è un po' forzata, ma che mi aiuta a pensare. Per decenni, il petrolio è stato il combustibile dell'economia industriale, e chi controllava le raffinerie e le pipeline aveva più potere di chi estraeva il greggio. Nel software, i modelli di linguaggio sono il greggio. Generano output. Ma il valore reale sta nella raffineria: gli strumenti che prendono quell'output e lo trasformano in software funzionante, testato, conforme, deployato. Le AI company lo hanno capito, e stanno comprando le raffinerie. ## Una scelta politica {: #a-political-choice } E noi siamo al centro di questa transizione senza averla scelta. Usiamo uv perché è il miglior strumento disponibile. Usiamo Bun perché è veloce e risolve problemi reali. Le nostre scelte sono razionali e individuali. Ma l'effetto aggregato di milioni di scelte razionali e individuali è la concentrazione del potere infrastrutturale nelle mani di poche aziende che non hanno costruito quegli strumenti, li hanno comprati. Non so dove porti tutto questo. Forse gli incentivi resteranno allineati abbastanza a lungo da non creare problemi. Forse la licenza MIT si rivelerà una protezione sufficiente. Forse il mercato rimarrà abbastanza competitivo da impedire abusi. Ma forse no. Forse stiamo costruendo una dipendenza che riconosceremo come tale solo quando sarà troppo tardi per uscirne con grazia. **La cosa che so è che la scelta del tuo package manager, del tuo runtime, del tuo linter non è mai stata una scelta solo tecnica. Oggi, che tu lo voglia o no, è anche una scelta politica.** E come tutte le scelte politiche, merita di essere fatta con gli occhi aperti. --- # AI e consulenza IT: addio al time & materials - **URL:** https://margiovanni.it/it/blog/ai-e-consulenza-it-addio-al-time-materials/ - **Pubblicato:** 2026-03-19 - **Tag:** Consulenza IT, Fiducia, Intelligenza Artificiale, Pricing - **Tempo di lettura:** 8 min > L’AI sta rendendo insostenibile il time & materials nella consulenza IT. Cosa resta da vendere: risultati, responsabilità e fiducia, non ore. ## Quando un modello smette di reggere {: #quando-un-modello-smette-di-reggere } C’è un momento strano, silenzioso, in cui ti accorgi che una regola non scritta non vale più. Non perché qualcuno l’ha contestata con coraggio, ma perché la realtà ha smesso di collaborare. Nella consulenza IT quel momento, secondo me, è adesso. Per anni abbiamo vissuto dentro un patto comodo: *tu mi paghi il tempo, io ci provo*. lo chiamavamo time & materials, staff augmentation, body rental. Nomi diversi, stessa idea. Compravi ore umane e speravi che quelle ore diventassero qualcosa di utile. A volte succedeva, a volte no. In entrambi i casi, pagavi. E non è che funzionasse perché fosse giusto. Funzionava perché sembrava l’unico modo possibile. Il software è complesso, stimare è difficile, i requisiti cambiano, la tecnologia pure. Quindi ci siamo raccontati che il tempo fosse una buona approssimazione del valore. Poi è arrivata l’AI e, senza chiedere permesso, ha reso quella finzione molto più difficile da sostenere. ## La bugia comoda del time & materials {: #la-bugia-comoda-del-time-materials } Il time & materials, se lo spogli di tutte le parole eleganti, è soprattutto una cosa: un meccanismo di trasferimento del rischio. Il rischio di stimare male, di scoprire problemi tecnici, di gestire lo scope che si allarga, di accorgersi tardi che l’idea iniziale non sta in piedi. Nel modello a ore quel rischio finisce quasi sempre sul cliente. Il fornitore “mette le persone”, il cliente paga l’esplorazione, anche quando l’esplorazione porta a un vicolo cieco. Se lo descrivi così in altri settori suona assurdo. Immagina un idraulico che fattura ore senza promettere che l’acqua torni a scorrere. O un chirurgo pagato al minuto, indipendentemente da come va l’operazione. Eppure, in it, era normale. Anzi, era *atteso*. Se un cliente chiedeva garanzie veniva spesso etichettato come complicato. Se un fornitore proponeva un prezzo fisso, sembrava ingenuo o pericoloso. La giustificazione era sempre la stessa: “il software è diverso”. Ed è vero, in parte. Ma la conclusione, cioè che l’unico modello onesto sia fatturare il tempo, è sempre stata un salto logico. La verità un po’ triste è che conveniva a tutti, almeno nel breve periodo. Molti clienti non avevano abbastanza competenza interna per distinguere qualità da inefficienza. E molti fornitori, se sono onesto, hanno imparato a vivere bene in quel mondo. Perché il tempo è misurabile, il valore no. E quando non sai misurare il valore, finisci per comprare quello che riesci a contare. Il problema è che gli incentivi diventano strani. A volte addirittura invertiti. Se sei più lento, fatturi di più. Se risolvi in due ore invece che in venti, “lasci sul tavolo” diciotto ore. Nessuno lo direbbe così apertamente, ma il sistema spingeva in quella direzione. ## L’AI entra in stanza e accorcia le ore {: #lai-entra-in-stanza-e-accorcia-le-ore } Poi, nel giro di pochissimo, alcune attività quotidiane hanno iniziato a collassare. Boilerplate, integrazioni ripetitive, scaffolding di migrazioni, test generati, documentazione iniziale, trasformazioni di dati. Non tutto, non sempre, non perfettamente. Però abbastanza da cambiare la matematica. E qui arriva il punto che mette in crisi il modello: se ieri un’integrazione “valeva” 80 ore e oggi ne richiede 15 con assistenza AI, cosa fatturi? Se fatturi 15 ore, il tuo fatturato si riduce drasticamente a parità di risultato. Se fatturi 80 ore lo stesso, stai facendo una cosa che assomiglia molto a una frode, anche se la chiami “buffer”, “contingenza”, “gestione del rischio”. Forse non tutti la vivono così, ma è difficile ignorare la sensazione. Ed è per questo che vedo tre reazioni, tutte fragili: Alcuni nascondono l’uso dell’AI. Altri la vietano, non tanto per qualità quanto per proteggere il modello. Altri la usano e tengono i prezzi a ore, trattenendo il guadagno di produttività. Il punto è che questa finestra si chiude. L’arbitraggio tra “quanto ci metteva un umano” e “quanto ci mette una persona con AI” sta crescendo troppo. Prima o poi qualcuno, lato cliente, farà due conti. Oppure confronterà fornitori. Oppure si chiederà perché la stessa cosa, oggi, costa come due anni fa. ## Se il codice costa meno, cosa resta da vendere? {: #se-il-codice-costa-meno-cosa-resta-da-vendere } Questa è la domanda che, secondo me, divide chi sopravvive da chi resta bloccato. Perché se l’AI ti aiuta a scrivere codice, test e documentazione più velocemente, viene naturale pensare: “ok, allora il mio lavoro vale meno”. Io non ne sono affatto convinto. Forse vale meno *una parte* del lavoro, quella più meccanica. Ma proprio questa riduzione fa emergere il resto, cioè ciò che è sempre stato valore e che spesso abbiamo impacchettato insieme alle ore. Quello che i clienti cercano davvero non è il codice. È un esito. Un prodotto che funziona. Un rischio ridotto. Una capacità nuova. Una decisione presa bene. E ci sono aree in cui l’AI, almeno per ora, non sostituisce davvero la consulenza. La amplifica, semmai. ### Capire il problema, non solo i requisiti I requisiti tecnici spesso sono sintomi. Il problema vero è più sotto: processi, vincoli, persone, politica interna, incentivi. E a volte anche paure non dette. Capire questo richiede ascolto, contesto, e anche una certa dose di coraggio nel dire cose scomode. ### Prendere decisioni difficili e irreversibili Architettura, build vs buy, modello dati, postura di sicurezza. Decisioni che si pagano per anni. L’AI può proporti opzioni, ma scegliere bene, con responsabilità, è un’altra cosa. ### Prendersi la responsabilità Questa è la parte che mi sembra più centrale. L’AI non può essere chiamata alle 3 di notte quando qualcosa va giù. Non può metterci la faccia con il board. Non può assumersi la responsabilità legale o reputazionale. Un fornitore sì. E questa responsabilità, oggi, diventa una componente esplicita del valore. ### Navigare compliance e vincoli reali Non solo “cosa possiamo costruire”, ma “cosa possiamo costruire *senza metterci nei guai* ”. GDPR, NIS 2, Accessibility Act, Cyber Resilience Act, AI Act. In Europa sta diventando sempre più chiaro che il software non è solo un progetto, è un prodotto con obblighi. ## Il pricing a valore: tutti ne parlano, pochi lo fanno {: #il-pricing-a-valore-tutti-ne-parlano-pochi-lo-fanno } Il pricing a valore non è una novità. Eppure, nella consulenza IT, è rimasto spesso un ideale lontano. Perché? Perché richiede una cosa che il time & materials ti permette di evitare: l’assunzione di rischio. Vendere a valore significa vendere risultati. E se vendi risultati, devi essere disposto a dire “se non li raggiungiamo, ne rispondiamo”. Non è solo un cambio di listino. È un cambio di identità. Significa smettere di vendere “giornate uomo” e iniziare a vendere, per esempio, “un’integrazione funzionante tra CRM ed ERP, con monitoraggio, logging, test e criteri di accettazione chiari”. Significa costruire metodi per stimare e governare l’incertezza, invece di scaricarla. Significa investire in processi, qualità, specifiche, e sì, anche in AI, ma in modo trasparente. E qui mi viene un dubbio che non riesco a togliermi: forse molte aziende non hanno paura dell’AI. hanno paura di non poter più nascondere l’inefficienza dietro un timesheet. ## Il vero ostacolo: la paura della responsabilità {: #il-vero-ostacolo-la-paura-della-responsabilita } Ho parlato con tante persone del settore nell’ultimo anno. Quasi tutti dicono che il modello a valore è “il futuro”. Pochi lo applicano davvero. E non credo sia solo per complessità commerciale. Credo sia per paura. Il time & materials è comodo perché ti protegge. Se le cose vanno male, puoi sempre dire che “ci avete chiesto questo”, “abbiamo seguito i requisiti”, “abbiamo messo le ore”. La responsabilità dell’esito si disperde. Quando invece vendi un outcome, quella protezione sparisce. Se non funziona, è un problema tuo. Se non è conforme, lo sistemi tu. Se l’impatto sul business non arriva, devi spiegare perché. È scomodo. Però è anche, finalmente, onesto. ## Una nota per chi compra consulenza {: #una-nota-per-chi-compra-consulenza } Non è solo colpa dei fornitori. Anche chi compra ha contribuito al sistema. Se scegli i partner guardando soprattutto la tariffa giornaliera, stai dicendo al mercato che ti interessa il costo unitario, non il risultato. E poi non dovresti sorprenderti se ricevi conformità, non coraggio. Presenza, non responsabilità. Nel mondo post-AI, secondo me, comprare bene significa fare un salto: Significa chiedere outcome misurabili, anche se non perfetti. Significa pagare di più chi si prende rischio e ci mette trasparenza. Significa smettere di pretendere specifiche tecniche chilometriche come forma di controllo, e iniziare a descrivere problema, vincoli e criteri di successo. Significa costruire un minimo di competenza interna per valutare qualità, perché altrimenti torni sempre a comprare ore, cioè l’unica cosa che sai contare. ## Stiamo entrando in un’economia della fiducia {: #stiamo-entrando-in-uneconomia-della-fiducia } C’è un effetto collaterale dell’AI che mi sembra enorme: produrre è diventato più economico, verificare è diventato più caro. Oggi chiunque può generare codice, documentazione, diagrammi, report “credibili”. Il problema non è ottenere un output. Il problema è capire se quell’output è affidabile, sicuro, manutenibile, conforme. Quindi la domanda cambia. Non è più “me lo sai fare?”. È “posso fidarmi di quello che mi consegni?” E la fiducia non la automatizzi. La costruisci con track record, trasparenza, responsabilità, capacità di ammettere un errore e correggerlo. In questo senso, il pricing a valore è anche un segnale: quando un fornitore accetta di essere pagato per un risultato, sta dicendo che crede abbastanza nel proprio lavoro da scommetterci la pelle. ## Una confessione, perché ci sto dentro anche io {: #una-confessione-perche-ci-sto-dentro-anche-io } Qui per anni abbiamo fatturato a ore. Era normale. Era semplice. Era, in un certo modo, rassicurante. Poi l’AI ha iniziato ad accelerare davvero il lavoro. E ci siamo trovati davanti a una scelta che molte realtà stanno vivendo adesso: fingere niente, oppure cambiare. Cambiare è faticoso. Ti costringe a ripensare offerte, contratti, processi, e anche la cultura interna. Ti costringe a chiederti in cosa sei davvero bravo e in cosa no. Ti costringe a dire dei no. Non so se faremo tutto perfettamente. Probabilmente no. Però una cosa mi sembra chiara: il time & materials non è “morto” perché l’AI scrive codice. È morto perché l’AI ha reso impossibile continuare a far finta che il tempo sia una misura onesta del valore. E forse, se devo dirla tutta, è una buona notizia. Non perché sarà facile, ma perché obbliga tutti a tornare a quello che dovevamo vendere da sempre: risultati, responsabilità e fiducia. --- # Compliance eu 2026: è architettura, non solo legale - **URL:** https://margiovanni.it/it/blog/compliance-eu-2026-e-architettura-non-solo-legale/ - **Pubblicato:** 2026-03-17 - **Tag:** Compliance, Normative Europee, AI Act, Architettura - **Tempo di lettura:** 10 min > Nei prossimi 18 mesi cra, ai act, pld, nis2 ed eaa cambiano il software europeo. La compliance non si “spunta”: si progetta in architettura. Mi capita spesso una scena che ormai riconosco al primo minuto. Qualcuno nomina la compliance, magari in una riunione di progetto o durante una call con un cliente un po’ più strutturato, e la risposta arriva quasi automatica. "ci pensa il legale". Non lo dico per fare il cinico. È proprio che quella frase, nel 2026, rischia di diventare una delle più costose che un’azienda software europea possa pronunciare. Perché quello che sta arrivando non assomiglia a un aggiornamento di policy o a un giro di informative. Assomiglia di più a un cambio di fondamenta. E, cosa ancora più scomoda, ha delle scadenze molto ravvicinate. ## La tempesta perfetta: cinque scadenze in un arco troppo corto {: #la-tempesta-perfetta-cinque-scadenze-in-un-arco-troppo-corto } Se fai software per il mercato europeo, il calendario non è più un dettaglio da tenere in un file condiviso. È una timeline che ti entra in architettura. Tra la fine del 2024 e il 2026 si addensano normative che, prese singolarmente, potresti anche gestire con fatica. Insieme, però, si incastrano apposta. Nis2 è già in vigore da ottobre 2024 e ha allargato il perimetro di chi deve prendersi sul serio la cybersecurity, inclusa la supply chain. E qui spesso scatta la prima sorpresa: non serve essere “critici” per sentirne gli effetti. Basta essere fornitori di qualcuno che lo è. L’european accessibility act è già operativo da giugno 2025 e, al netto di come verrà interpretato nei vari contesti, sposta l’accessibilità dal mondo dei “miglioramenti” al mondo dei “requisiti”. Poi arriva il 2026, che è l’anno in cui si stringe il nodo. Ad agosto 2026 l’ai act entra in piena applicazione per i sistemi ad alto rischio. Non è solo una questione di etica o di trasparenza. Parliamo di valutazioni di conformità, documentazione tecnica, governance dei dati, supervisione umana. E sì, anche di sanzioni reali, fino al 3% del fatturato globale o 15 milioni. A settembre 2026 il cyber resilience act porta obblighi che, per come sono scritti, non puoi “aggiungere dopo”. Tra questi c’è la segnalazione di vulnerabilità attivamente sfruttate entro 24 ore e di incidenti gravi entro 72 ore. E la parte che molti sottovalutano è questa: non vale solo per i prodotti futuri. Vale anche per quello che hai già sul mercato. Legacy incluso. A dicembre 2026 la product liability directive ridefinisce cosa sia un “prodotto” nell’era digitale. Il software, anche standalone o in forma saas, diventa prodotto a tutti gli effetti, con responsabilità oggettiva. I bug smettono di essere solo un fastidio operativo e diventano potenzialmente un difetto del prodotto, con conseguenze legali dirette. E la responsabilità non finisce al rilascio, finisce quando non hai più la capacità di fornire aggiornamenti. E sullo sfondo resta il gdpr, che non se n’è mai andato, con un enforcement sempre meno timido. Forse la cosa più destabilizzante è che queste norme non si sommano in modo lineare. Si *rinforzano*. ## L’errore fondamentale: trattare la compliance come un layer esterno {: #lerrore-fondamentale-trattare-la-compliance-come-un-layer-es } La reazione più comune è comprensibile: “chiamiamo il consulente, aggiorniamo le policy, mettiamo a posto la documentazione, facciamo le checklist”. È l’approccio che potremmo chiamare compliance-as-paperwork. Con il gdpr, per quanto spesso fatto male, questa strategia a volte reggeva. Potevi incollare sopra un sistema esistente una serie di processi, informative, registri, ruoli. Con il pacchetto 2026 non regge più. E non perché manchi la buona volontà. Perché ci sono requisiti che, se non sono supportati dalla tua architettura e dal tuo modo di costruire e rilasciare software, semplicemente non esistono. Prendiamo il caso più concreto possibile: per rispettare il cra, quando emerge una vulnerabilità sfruttata attivamente, devi poter reagire e segnalare nei tempi previsti. Ma per farlo devi sapere con precisione cosa c’è dentro il tuo prodotto. Non “più o meno”. Proprio *esattamente*. Dipendenze dirette, transitive, componenti, versioni, build. Tutto. Questo ti porta dritto a un oggetto che non è legale e non è burocratico: la sbom, software bill of materials. E non una sbom in pdf generata una volta per far contento qualcuno. Una sbom viva, rigenerata a ogni build, in formato leggibile dalle macchine, integrata nella pipeline. Se il tuo processo di build non produce una sbom come output naturale, non è che “sei un po’ indietro con la compliance”. È che non puoi esserlo, punto. E qui secondo me si chiarisce la frase più importante di tutto questo discorso: la compliance non è un requisito che aggiungi. È una proprietà emergente della tua architettura. ## Compliance come vincolo architetturale {: #compliance-come-vincolo-architetturale } In architettura software siamo abituati ai vincoli. Latenza, disponibilità, scalabilità, compatibilità, costi. Sono cose che restringono lo spazio delle soluzioni possibili. Ecco, la compliance eu 2026 è un vincolo architetturale. Non un ticket da assegnare “a fine progetto”, non un documento da produrre “prima della gara”. Un vincolo che attraversa il sistema. E quando lo guardi così, alcune conseguenze diventano quasi ovvie. ### L’observability non è più un extra L’ai act, per certi sistemi, richiede log e tracciabilità. Il cra ti spinge verso capacità di rilevazione e risposta. La pld ti mette nella posizione di dover dimostrare lo stato del software al momento dell’incidente. Se non hai audit trail sufficienti, non è che “monitori poco”. Stai costruendo un sistema che non riesce a sostenere le domande che il mercato e le norme ti faranno. ### La gestione delle dipendenze diventa un processo critico Per anni abbiamo normalizzato l’idea che aggiornare librerie sia un lavoro “da quando avanza tempo”. Un `npm install` fatto di fretta, un lockfile che nessuno guarda, un aggiornamento rimandato perché “tanto funziona”. Con cra e nis2, questa leggerezza diventa rischio di supply chain. E il rischio di supply chain, nel 2026, non resta confinato al reparto tecnico. Si propaga a contratti, gare, partnership. La domanda a cui devi saper rispondere è molto semplice e molto dura: “questo cve appena uscito impatta i nostri prodotti in produzione?”. E la risposta deve arrivare in minuti o ore, non in settimane. ### Il concetto di “prodotto finito” si sfalda La pld e il cra, insieme, rendono meno credibile l’idea che un rilascio chiuda un capitolo. Rilasciare diventa l’inizio di una relazione a lungo termine con un sistema che va mantenuto, monitorato, curato. Questo cambia anche il modo in cui stimiamo, pianifichiamo, vendiamo. Perché una parte del valore, e della responsabilità, vive dopo la consegna. ### L’accessibilità è una proprietà del design system L’eaa non è gentile con i retrofit. Se hai un design system accessibile by default, hai un vantaggio strutturale. Se devi “rendere accessibile” un frontend cresciuto per anni senza regole, la quantità di finding che ti torna indietro può diventare ingestibile. E qui mi chiedo spesso se non stiamo sottovalutando quanto l’accessibilità sia, in realtà, una forma di standardizzazione interna. Non solo un requisito esterno. ### La human oversight non è un bottone Uno dei fraintendimenti più comuni sull’ai act è pensare che “supervisione umana” significhi aggiungere un passaggio di approvazione alla fine. In pratica, è un tema di flussi: dove l’umano può intervenire, con quali informazioni, con quale possibilità di override, e con quale tracciabilità. È architettura del processo decisionale, prima ancora che architettura software. ## L’intersezione che molti non stanno guardando {: #lintersezione-che-molti-non-stanno-guardando } Il punto più interessante, e forse più pericoloso, non sono i singoli obblighi. È come si incastrano. La pld dice che un prodotto software è difettoso se non soddisfa i requisiti di sicurezza informatica applicabili. Il cra definisce una parte importante di quei requisiti. L’ai act aggiunge requisiti specifici quando c’è ai. Quindi la mancata compliance con il cra può diventare un *difetto di prodotto* ai sensi della pld. Non stiamo più parlando solo di una multa amministrativa o di una non conformità “da sistemare”. Stiamo parlando di responsabilità civile per danni, con dinamiche come l’inversione dell’onere della prova. E per difenderti, devi poter dimostrare che il prodotto era conforme al momento dell’incidente. Che, di nuovo, ti riporta a sbom, audit trail, logging, documentazione tecnica. Non come teatro della compliance, ma come architettura difensiva. ## Il paradosso italiano: fragili, ma veloci {: #il-paradosso-italiano-fragili-ma-veloci } Qui entra un pezzo che sento molto vicino, perché è la realtà quotidiana di tante aziende con cui parlo. Il tessuto software italiano è fatto in gran parte di pmi: team da 5 a 20 persone, prodotti verticali, crescita per stratificazione, roadmap dettata dai clienti, debito tecnico accumulato con la logica del feature-first. Molte di queste aziende sono impreparate. Non per incapacità, ma per struttura. Eppure c’è un paradosso: la stessa struttura che le rende vulnerabili può trasformarsi in vantaggio. Un’azienda di 10 persone, se decide davvero, può ridisegnare pezzi importanti della propria architettura in 12 mesi. Una grande organizzazione spesso impiega mesi solo per capire cosa ha in produzione. Un team piccolo conosce il proprio dominio e il proprio prodotto in modo intimo. Può fare una gap analysis realistica in settimane. E un founder-cto che investe oggi in compliance-by-design può muoversi in una finestra che, tra 18 mesi, sarà già chiusa. Non perché sarà impossibile, ma perché sarà troppo tardi per farlo con calma. ## Compliance-by-design: decisioni architetturali, non slogan {: #compliance-by-design-decisioni-architetturali-non-slogan } Quando dico compliance-by-design non intendo “fare le cose per bene” in modo generico. Intendo scelte concrete che puoi iniziare a fare adesso, anche senza rivoluzionare tutto. La sbom come artefatto di prima classe, per esempio. Ogni build produce una sbom in formato cyclonedx o spdx. La pipeline la genera, la conserva, la confronta con database di vulnerabilità, e se serve blocca un deploy. Strumenti come syft, grype o trivy rendono questa cosa molto più accessibile di quanto sembri. Poi c’è l’audit trail, ma non quello dei log di sistema. Un audit trail di dominio: chi ha fatto cosa, quando, perché, con quale ruolo, in quale contesto. Può essere event sourcing o un append-only log, ma l’idea è che sia un cittadino di prima classe del modello dati. La documentazione tecnica come codice è un altro punto chiave. Se la documentazione vive in un wiki aggiornato a mano, prima o poi smette di rappresentare la realtà. Se invece usi adr versionati, specifiche dichiarative, e documentazione generata dal codice, allora la documentazione diventa un sottoprodotto inevitabile del lavoro. E il vulnerability management non può essere un evento annuale. Deve essere un processo continuo: scanning automatico, triage, remediation con tempi definiti. Quando arriva la segnalazione di una vulnerabilità sfruttata, il sistema deve aiutarti a reagire in ore. Sull’accessibilità, la cosa che ho visto funzionare davvero è trattarla come design token e come regola del design system. Se i componenti nascono accessibili, il prodotto tende a restarlo. Se devi correggere dopo, ogni nuova schermata aggiunge debito. ## Ai-native development come acceleratore, non solo come rischio {: #ai-native-development-come-acceleratore-non-solo-come-rischi } C’è una piccola ironia nel fatto che l’ai act arrivi mentre l’ai sta cambiando il modo in cui scriviamo software. Molti vedono lo sviluppo ai-native come un rischio per la compliance: più codice generato, meno controllo. Io sospetto che, in molti casi, sia vero il contrario. Un approccio spec-driven, dove il software nasce da specifiche dichiarative leggibili e verificabili, è *intrinsecamente* più favorevole alla conformità. Perché le specifiche sono documentazione. Perché sono versionate. Perché rendono esplicite assunzioni che altrimenti restano nella testa di chi ha scritto quel pezzo di codice due anni fa. Strumenti come file di progetto tipo claude.md, speckit, pipeline che generano artefatti di compliance come parte del flusso, non sono fantascienza. Sono un modo diverso di lavorare, che può rendere più facile produrre evidenze, tracciabilità, ricostruibilità. Forse il futuro non è “scrivere più documentazione”. È costruire software in modo che la documentazione sia inevitabile. ## Il vero costo della non conformità è molto più vicino di una multa {: #il-vero-costo-della-non-conformita-e-molto-piu-vicino-di-una } Le sanzioni fanno impressione, ma per molte pmi restano astratte. Non è la paura della multa che cambia le priorità. Il costo reale è più quotidiano. È il bando pubblico a cui non puoi partecipare perché non soddisfi i requisiti di sicurezza del capitolato. È il cliente enterprise che ti chiede la sbom e tu non sai da dove cominciare. È un partner che fa supply chain risk management e ti esclude dalla shortlist. È un incidente che non riesci a gestire nei tempi previsti dal cra e che si incastra in un contesto di responsabilità più duro. Per molte aziende italiane, questi non sono scenari teorici. Sono cose che assomigliano molto al 2027. ## La finestra è adesso, e in fondo parla di buona ingegneria {: #la-finestra-e-adesso-e-in-fondo-parla-di-buona-ingegneria } Da architetto software, con la testa spesso divisa tra roadmap, budget, debito tecnico e richieste del mercato, capisco bene che tutto questo possa sembrare schiacciante. Però c’è un aspetto che vale la pena tenere in primo piano: molte delle pratiche richieste da queste normative sono semplicemente buona ingegneria. Generare una sbom è buona ingegneria. Avere un audit trail è buona ingegneria. Gestire le vulnerabilità delle dipendenze è buona ingegneria. Documentare le decisioni architetturali è buona ingegneria. Costruire interfacce accessibili è buona ingegneria. Quello che la compliance eu 2026 sta facendo, forse, è rendere obbligatorio ciò che avremmo dovuto fare comunque. Sta trasformando le best practice in baseline. E sta creando un mercato in cui chi tratta la compliance come un problema architetturale, e non come una pratica da demandare al legale, si ritrova con software più robusto, più manutenibile e anche più vendibile. La finestra per costruire quel vantaggio è aperta ora. Tra diciotto mesi, chi non ha iniziato rincorrerà. Chi inizia adesso, probabilmente, si ritroverà dall’altra parte. --- # Cose che ho smesso di fare negli ultimi quindici anni di lavoro - **URL:** https://margiovanni.it/it/blog/cose-che-ho-smesso-di-fare-in-quindici-anni-di-lavoro/ - **Pubblicato:** 2026-03-16 - **Tag:** Compliance, Crescita Professionale, Leadership Tecnica, Sviluppo Software - **Tempo di lettura:** 8 min > Appunti sulle cose che ho impiegato almeno 15 anni a disimparare. Mi sono accorto che le cose più difficili da imparare non sono quasi mai tecniche. **Sono le cose che devi *disimparare*.** E la parte strana è che, mentre le disimpari, ti sembra di perdere qualcosa. Status, controllo, identità. Poi, se va bene, ti rendi conto che stavi solo lasciando andare un’abitudine che ti teneva fermo. Questi sono appunti sparsi su alcune cose che ho smesso di fare. Ci ho messo quindici anni, più o meno. E su alcune, se devo essere sincero, non ho ancora finito. ## Ho smesso di scrivere codice per dimostrare che sono ancora tecnico {: #ho-smesso-di-scrivere-codice-per-dimostrare-che-sono-ancora- } C’è stato un periodo, subito dopo un passaggio importante della mia carriera, in cui il mio modo di legittimarmi davanti al team era sempre lo stesso: aprivo l’IDE e andavo a prendermi il bug più brutto della settimana. Lo facevo spesso la sera, da solo. La mattina dopo il commit era lì, con il mio nome sopra. Dentro di me lo chiamavo leadership. In realtà era insicurezza. Perché il messaggio implicito era devastante, anche se non lo dicevo mai ad alta voce. Il messaggio era: non mi fido di voi. E ce n’era un altro, ancora più tossico: i problemi si risolvono di notte, in solitaria, senza chiedere aiuto. Senza volerlo, stavo insegnando che il gesto eroico vale più del processo. Che la bravura è una performance individuale. Che la fatica è una medaglia. Poi ho fatto un altro giro di giostra. Ho sostituito il codice con le specifiche. Documenti così precisi che il team, o un agente ai, potessero implementarli con supervisione minima. Per un po’ mi è sembrata la soluzione “adulta”. Ma anche quella fase è passata. Oggi il mio lavoro, quando lo faccio bene, è un altro. È decidere *cosa* costruiamo, *per chi* , e *perché adesso*. È architettura di portfolio, non di codice. È partnership, hiring, posizionamento. È capire dove deve puntare l’azienda tra diciotto mesi, e quali scelte di oggi rendono quella direzione più probabile. Questa distanza dal codice, a volte, fa male. Non perché voglia tornare a programmare ogni giorno. È più sottile. È la sensazione che la legittimità di un tecnico che non tocca più il codice quotidianamente sia una cosa fragile, che va ricostruita su basi diverse. Non più sulla qualità di quello che scrivi, ma sulla qualità delle decisioni che prendi e delle persone che scegli. E poi c’è una frase che mi torna in mente spesso, e che mi aiuta a non ricadere nel vecchio riflesso: ogni riga che scrivo io è una riga che qualcun altro non scrive. Ogni ora che passo nell’IDE è un’ora in cui nessuno sta guardando dove stiamo andando. ## Ho smesso di inseguire lo stack giusto {: #ho-smesso-di-inseguire-lo-stack-giusto } Per anni ho avuto quel riflesso pavloviano da developer. Esce un framework nuovo, devi valutarlo. Esce un linguaggio nuovo, devi almeno provarci. Sotto sotto, credo che il sottotesto fosse questo: esiste una scelta tecnologica “giusta” che ti mette dalla parte dei vincitori. Dei cool kids. Delle conferenze giuste. Degli articoli su Hacker News. Poi ho fatto una cosa impopolare, almeno per come mi ero abituato a pensare: ho scelto un framework. Uno. E ci sono rimasto. Non perché sia il migliore in assoluto. Ma perché mi permette di consegnare valore con poche persone su più progetti, senza impazzire. Perché ha una filosofia che regge i vincoli reali di un’azienda italiana. Convenzione su configurazione, batterie incluse, documentazione maniacale. Non i vincoli immaginari di una startup della Bay Area che vive di slide e runway. La verità scomoda è che tante scelte tecnologiche “coraggiose”, nelle PMI, non sono coraggio. Sono vanità. Scegliere Rust per un gestionale che useranno quaranta persone non è ingegneria. È narcisismo con un compilatore. A un certo punto ho smesso di cercare lo stack giusto e ho iniziato a cercare lo stack onesto. Quello che non mente sulla complessità che introduce. Quello che puoi mantenere quando i senior se ne vanno, quando il budget si stringe, quando il cliente cambia idea tre volte. ## Ho smesso di proteggere il team dal business {: #ho-smesso-di-proteggere-il-team-dal-business } Questo è stato il passaggio più difficile. Per anni ho fatto da scudo. Il cliente chiede una modifica folle? La filtro io. Il commerciale vende qualcosa che non esiste? Gestisco io. Arriva un documento incomprensibile? Lo traduco io e passo al team solo la parte tecnica, pulita, digeribile. Pensavo di essere un buon leader. E invece, probabilmente, stavo creando degli invalidi. Sviluppatori bravissimi, sì, ma scollegati. Non sapevano davvero perché stessero costruendo quello che stavano costruendo. Non sapevano leggere un requisito di business. Non avevano mai parlato con un cliente. E quando incontravano un’ambiguità, invece di alzare il telefono, aprivano un ticket e aspettavano che qualcuno risolvesse. Il cambio, per noi, è stato costruire un percorso interno che abbiamo chiamato “da developer a product owner”. Non per trasformare tutti in PM. Più che altro per togliere il filtro. Per dire una cosa semplice, anche se un po’ scomoda: il casino è anche vostro. Il cliente confuso è anche vostro. Il requisito ambiguo è anche vostro. E, soprattutto, anche la soddisfazione di consegnare qualcosa che funziona davvero per qualcuno è vostra. Pensavo sarebbe stato impopolare. Mi sbagliavo. Mi hanno stupito. Forse aspettavano solo che gli dessimo il permesso di uscire dalla bolla. ## Ho smesso di dire “tanto è pubblico” parlando di compliance {: #ho-smesso-di-dire-tanto-e-pubblico-parlando-di-compliance } Per anni la mia posizione sulla compliance è stata quella tipica del settore IT italiano. Il minimo indispensabile, fatto all’ultimo momento possibile, trattato come un costo e mai come un investimento. GDPR? Un banner sui cookie e una privacy policy copiata. Accessibilità? “Ci pensiamo dopo.” Sicurezza? “Non siamo un target.” Poi ho iniziato a leggere davvero alcune normative europee. Non gli articoli *su* quelle normative, proprio i testi. E lì mi si sono chiarite due cose. La prima: il legislatore europeo, per una volta, non sta scherzando. Le sanzioni sono reali, le timeline sono strette, e la catena di responsabilità arriva fino al fornitore del componente software. Cioè noi. La seconda, più importante: in un mercato dove tutti aspettano l’ultimo momento, chi si muove prima ha un vantaggio competitivo enorme. Non perché è più bravo. Perché è l’unico che può dire al cliente “sì, siamo pronti” quando il cliente, in panico, inizierà a chiederlo. A un certo punto ho smesso di trattare la compliance come un obbligo. Ho iniziato a trattarla come un prodotto. E mi chiedo spesso perché ci abbiamo messo così tanto a capirlo. Forse perché è più comodo pensare che siano solo scartoffie, finché non diventa improvvisamente un problema con una scadenza. ## Ho smesso di assumere per competenze tecniche {: #ho-smesso-di-assumere-per-competenze-tecniche } Questa è recente e, se devo essere sincero, ancora un po’ dolorosa. Ho passato settimane a cercare una figura importante. Candidati con CV eccellenti. Anni di esperienza. Stack solidi. Referenze buone. Ne ho bocciati diversi, non perché non fossero bravi, ma perché usavano l’AI come usavano Stack Overflow dieci anni fa. Come un oracolo. Quello che cercavo, e che faccio ancora fatica a spiegare ai recruiter, è diverso. Cercavo qualcuno che sapesse scrivere una specifica dichiarativa così precisa che un agente AI potesse implementarla con supervisione minima. Non un prompt engineer. Un *pensatore di sistemi* che usa l’AI come runtime, non come stampella. La differenza sembra sottile, ma non lo è. È la differenza tra chi dice “ho chiesto a ChatGPT di scrivermi il codice” e chi mantiene un file *claude.md* nel repository con convenzioni architetturali, pattern, vincoli di dominio. È la differenza tra conversazione e specifica. Tra artigianato e ingegneria. Ho smesso di assumere developer che sanno programmare. Ho iniziato a cercare developer che sanno *specificare* e che poi verificano quello che l’AI ha prodotto con lo stesso rigore con cui verificherebbero il codice di un junior. Il mercato italiano non mi sembra ancora pronto per questa distinzione, purtroppo. Ma ho la sensazione che lo sarà presto. E chi non ci arriva in tempo rischia di ritrovarsi con team che “producono” tanto, ma capiscono poco. ## Ho smesso di parlare italiano al lavoro {: #ho-smesso-di-parlare-italiano-al-lavoro } Sembra una cosa piccola. Non lo è. Quando è arrivato un nuovo junior non italiano, bravissimo, ci siamo trovati davanti a una scelta. Continuare a lavorare in italiano tra di noi e usare l’inglese solo con lui, creando di fatto un team a due velocità. Oppure fare lo switch completo. Abbiamo scelto lo switch completo. Tutto in inglese. Jira in inglese. Chat in inglese. Daily in inglese. Retro in inglese. Per tutti. Non l’ho fatto solo per lui. L’ho fatto per noi. Perché un’azienda di poche persone in una città italiana che lavora solo in italiano è un’azienda che probabilmente resterà di poche persone in quella città. Non c’è niente di male, davvero. Solo che non è quello che volevamo. L’inglese, alla fine, non è una lingua. È un’infrastruttura. Come Git, come la CI/CD, come la documentazione. O ce l’hai, o sei tagliato fuori. È stato scomodo. Qualcuno ha faticato. Ma oggi, quando leggo descrizioni delle pull request, messaggi, email, penso che ne sia valsa la pena. ## Ho smesso di credere che il buon codice parli da solo {: #ho-smesso-di-credere-che-il-buon-codice-parli-da-solo } Questa è forse la bugia più pericolosa dell’ingegneria del software. L’idea romantica che, se il codice è pulito, testato, ben strutturato, allora il suo valore è evidente. Che il merito tecnico si difenda da solo. Non funziona così. Il buon codice che nessuno capisce è indistinguibile dal codice mediocre. Il refactoring che nessuno racconta diventa un costo, non un investimento. La migrazione architetturale senza un business case scritto sembra un capriccio dell’ufficio tecnico. Ho imparato, tardi, che metà del lavoro di un tech leader è *narrare*. Spiegare al board perché una migrazione non è un vezzo ma una riduzione del rischio. Spiegare al cliente perché i test automatizzati che ha pagato sono la ragione per cui dorme tranquillo. Spiegare al team perché la CI/CD non è burocrazia ma libertà e comodità. Se non sai raccontare il valore di quello che costruisci, qualcun altro lo racconterà al posto tuo. E lo racconterà male. ## La cosa che non ho ancora smesso di fare {: #la-cosa-che-non-ho-ancora-smesso-di-fare } Se voglio essere onesto fino in fondo, c’è una cosa che dovrei smettere di fare e non ci riesco ancora. Lavorare come se fossi l’unico che tiene insieme i pezzi. Ancora troppe cose passano da me. Non perché il team non sia capace, anzi, ma perché non ho ancora costruito i sistemi che mi rendano superfluo in ognuno degli ambiti in cui operiamo. Ed è questo che mi spaventa di più. Perché ogni passaggio precedente aveva un sostituto chiaro. Smettere di scrivere codice? Le specifiche. Smettere di scrivere specifiche? La strategia. Smettere di fare code review? Un team lead. Ma smettere di essere il punto di convergenza di tutto è diverso. Il sostituto è la fiducia nei sistemi. E i sistemi, se devo dirla tutta, li devo ancora finire di costruire. Ne riparleremo. --- # Assumere nel 2026: non serve usare l'ai, serve governarla - **URL:** https://margiovanni.it/it/blog/assumere-nel-2026-non-serve-usare-lai-serve-governarla/ - **Pubblicato:** 2026-03-14 - **Tag:** Intelligenza Artificiale, Leadership, PMI, Selezione Del Personale - **Tempo di lettura:** 9 min > Nelle PMI l’AI non è un tema tech. È una competenza trasversale: saperla governare, valutarne l’output e usarla per fare cose nuove. ## Una domanda che le PMI fanno sottovoce {: #una-domanda-che-le-pmi-fanno-sottovoce } Ogni tanto mi capita di parlare con imprenditori che hanno dieci, trenta, ottanta persone. Non hanno un Chief AI Officer, non hanno una roadmap a diciotto mesi, e spesso non hanno nemmeno voglia di sentirsi dire che “devono trasformarsi”. Hanno un’altra urgenza, molto più concreta: far girare l’azienda. Eppure la domanda arriva lo stesso, anche se raramente viene detta così com’è: *ma noi, concretamente, cosa dobbiamo fare con l’AI?* Le grandi aziende se la stanno già ponendo in modo ufficiale, con budget, team dedicati e programmi con sigle che suonano importanti. Le PMI invece sono in un territorio diverso, fatto di confusione e segnali contraddittori. E non è colpa loro. È che la conversazione pubblica sull’AI spesso sembra pensata per chi ha tempo, risorse e strutture che una PMI non avrà mai. Allora provo a metterla semplice, quasi brutale. Quante persone nel tuo team sanno ottenere da un agente AI un risultato migliore di quello che produrrebbero da sole? Non quante “lo usano”. Non quante hanno ChatGPT aperto in una tab. Quante sanno dare istruzioni precise, valutare criticamente l’output, iterare con metodo finché esce qualcosa che regge davvero. In vendite, marketing, operations, finance, legale, prodotto, HR. **Se la risposta onesta è “poche” o “non lo so”, probabilmente hai un problema.** E nelle PMI questo problema pesa di più, perché non hai il lusso di rimandare. ## Il malinteso più costoso del 2026 {: #il-malinteso-piu-costoso-del-2026 } Il malinteso, secondo me, è uno: pensare che l’AI sia una questione tech. Non lo è più. Forse non lo è da almeno un anno. L’AI è diventata un moltiplicatore di capacità individuale, trasversale a ogni ruolo. Un commerciale che sa costruirsi un’analisi competitiva in dieci minuti gioca un’altra partita rispetto a uno che ci mette due giorni. Chi segue l’amministrazione e sa farsi generare un cruscotto sensato sui costi in un’ora compete in una categoria diversa rispetto a chi assembla tutto in una settimana, pescando dati da file excel vecchi e mezzi rotti. E qui non stiamo parlando della solita parola “efficienza”. Efficienza è fare le stesse cose più in fretta. Qui stiamo parlando di persone che iniziano a fare cose che prima non facevano proprio, perché il costo cognitivo era troppo alto. Un’offerta davvero personalizzata per ogni prospect, invece del solito pdf riciclato con il nome cambiato in copertina. Un’analisi del cash flow degli ultimi tre anni che ti fa vedere pattern che nessuno ti aveva mai segnalato. Report di avanzamento progetto che prima non esistevano perché “non c’è tempo”. Potrebbe succedere. Ma solo se qualcuno sa governare lo strumento. Se lo tratta come un collaboratore da dirigere, non come un giocattolo da ignorare o un oracolo da interrogare a caso. ## “Governare” non è “usare” {: #governare-non-e-usare } Questa distinzione è il cuore di tutto, e mi colpisce quanto spesso non venga fatta. Usare l’AI è chiedere qualcosa e accettare quello che arriva. È il prompt-and-pray. Scrivi una richiesta, copi la risposta, la incolli in una mail e speri che vada bene. È comprensibile, all’inizio lo fanno tutti. Ma non vale niente, e in alcuni casi è pure pericoloso. Governare l’AI è un’altra cosa. È sapere cosa chiedere, come chiederlo e soprattutto capire quando la risposta è sbagliata anche se sembra perfetta. Vuol dire dare contesto, vincoli, criteri di successo. Vuol dire iterare sul serio. Non “riscrivi meglio”, ma “riscrivi considerando che il nostro cliente è un ente pubblico, con vincoli di procurement e tempi decisionali di sei mesi”. Chi governa l’AI ha un modello mentale dello strumento. Sa cosa fa bene, dove tende a inventare, dove può diventare un rischio. Sa quando fidarsi e quando verificare. Sa quando l’output è un punto di partenza e quando può essere considerato finito. E no, non è un talento innato. È una competenza che si sviluppa. Però qui arriva la parte un po’ scomoda: non tutti la sviluppano. Non perché non siano intelligenti, ma perché serve una mentalità specifica, e non è così diffusa come ci piace pensare. ## La mentalità che stai ignorando nei colloqui {: #la-mentalita-che-stai-ignorando-nei-colloqui } Quando assumi, di solito guardi esperienza, competenze verticali, cultura aziendale, magari leadership. Tutto giusto. Ma rischi di trascurare una variabile che nei prossimi due anni separerà chi performa da chi arranca. La variabile è questa: la persona che hai davanti sa lavorare a un livello di astrazione superiore rispetto all’esecuzione? Chi lavora al livello dell’esecuzione completa task. Scrive mail, prepara report, analizza dati, produce documenti. Lo fa bene, con mestiere. Ma lo fa una cosa alla volta, e il suo tempo è l’unica risorsa. Chi lavora al livello della specifica e del governo definisce cosa deve essere fatto, con quale qualità, entro quali vincoli, e poi dirige un agente (AI o umano, a quel livello la distinzione inizia a sfumare) per eseguirlo. Supervisiona, corregge, affina. E passa oltre. Non significa che l’esecuzione non conti. Significa che il valore dell’esecuzione pura si sta comprimendo rapidamente, mentre la capacità di governo si sta espandendo. Se non valuti questa capacità in fase di hiring, stai assumendo esecutori in un mondo che premia i direttori. ## Tre domande che cambiano un colloquio {: #tre-domande-che-cambiano-un-colloquio } Non importa se stai assumendo un marketing manager, un controller, un office manager o un CTO. Ci sono tre domande che, secondo me, funzionano quasi sempre. ### “Raccontami l’ultima volta che hai usato un agente AI per un deliverable reale” Non un esperimento. Non un gioco. Un deliverable finito davanti a un cliente, a un capo, a un board. Ascolta come ne parla. Ha dato istruzioni precise o prompt generici? Ha iterato? Ha verificato l’output? Ha integrato il suo giudizio o ha preso tutto così com’era? Se la risposta è “non l’ho mai fatto”, nel 2026, è un dato. Non per forza eliminatorio, ma è un dato da pesare seriamente. ### “Come faresti a sapere se l’output è sbagliato?” Questa è la domanda chiave. L’AI produce risultati convincenti anche quando sono completamente inventati. Un numero plausibile ma falso. Un ragionamento logico che parte da una premessa inesistente. Un testo scritto benissimo che però dice il contrario di quello che serve. Chi sa governare l’AI ha sviluppato anticorpi. Ha un metodo, anche rudimentale, per distinguere output affidabile da output tossico. Chi non ce l’ha è più pericoloso di chi non usa l’AI affatto, perché produce errori con la sicurezza di chi crede di avere ragione. ### “Se avessi un assistente AI dedicato per otto ore al giorno, come riorganizzeresti il tuo lavoro?” Questa domanda separa chi pensa in termini di task da chi pensa in termini di sistema. La risposta mediocre è: “farei le stesse cose più velocemente”. La risposta interessante è: “farei cose diverse”, seguita da una visione concreta. Cosa cambierebbe nelle priorità? Quali output inizierebbero a esistere? Quali attività verrebbero eliminate o ridotte? Chi risponde bene ha già capito che l’AI non è solo uno strumento di efficienza. È uno strumento di leva. E sa dove piazzare la leva. ## L’elefante nella stanza: le persone chiave che hai già {: #lelefante-nella-stanza-le-persone-chiave-che-hai-gia } Il problema più grande, spesso, non è chi assumi. È chi hai già. In una PMI l’organigramma è corto. Non hai strati di middle management. Hai tre, cinque, otto persone chiave che tengono in piedi l’azienda. Il responsabile commerciale che conosce tutti i clienti a memoria. L’amministrativa che fa girare la macchina da quindici anni. Il project manager su cui scarichi tutto quello che non sai dove mettere. Se queste persone non toccano l’AI perché “non è il mio lavoro” o perché “ho sempre fatto così e ha funzionato”, hai un collo di bottiglia che nessuna nuova assunzione può compensare. In una grande azienda puoi aggirare il problema con un team dedicato. In una PMI no. Le persone chiave *sono* l’azienda. Se non cambiano loro, non cambia niente. E qui viene la parte davvero scomoda, quella che di solito fa venire un po’ di fastidio. In molte PMI, la prima persona che non ha ricevuto il messaggio sta molto in cima. Se sei tu, e stai leggendo con un misto di interesse e irritazione, forse vale la pena fermarsi un secondo su quell’irritazione. Mi chiedo spesso se non sia uno dei segnali più utili che abbiamo, quando qualcosa ci riguarda più di quanto vorremmo. La scelta, alla fine, è netta: stabilire che la capacità di governare agenti AI è una competenza attesa per ogni ruolo, a partire dal tuo. Non opzionale. Non “nice to have”. Attesa, valutata, misurata. ## Non è una questione generazionale {: #non-e-una-questione-generazionale } C’è un’altra scorciatoia mentale che sembra comoda, ma non regge: “i giovani sono nativi digitali, quindi capiscono l’AI". Non è vero. Ho visto ventenni usare l’AI come un motore di ricerca un po’ più brillante. E ho visto cinquantenni integrarla nel flusso di lavoro in modi che, sinceramente, non avrei immaginato. La variabile non è l’anagrafe. È la disposizione a ripensare il proprio modo di lavorare. A dire: “forse il modo in cui ho sempre fatto questa cosa non è più il migliore”. Serve umiltà, curiosità e un pizzico di disagio. Tre cose che non hanno età. Quindi no, non basta assumere giovani e sperare che l’AI entri in azienda per osmosi. Serve una scelta deliberata su quali competenze valorizzi, quali premi e, diciamolo, quali pretendi. ## Il costo dell’inerzia, in numeri (più o meno) {: #il-costo-dellinerzia-in-numeri-piu-o-meno } Non sono conti perfetti, ma l’ordine di grandezza è quello. Un knowledge worker che governa bene l’AI spesso ha un output equivalente a 1,5 o 2 volte rispetto a uno che non la usa. Non perché lavori di più, ma perché elimina il lavoro a basso valore: ricerche manuali, prime stesure, analisi esplorative, strutturazione di dati, preparazione di slide. In un team di dieci persone, se cinque governano l’AI e cinque no, è come se tu avessi dodici o tredici persone. Senza assumere nessuno. Ora gira il ragionamento. Se il team del tuo competitor è allineato su questa competenza e il tuo no, il tuo team di dieci resta un team di dieci. Il suo diventa un team da quindici o venti, almeno per alcune attività. E la forbice si allarga ogni mese, perché gli strumenti migliorano e chi li governa cattura il valore incrementale. Chi non li governa resta fermo. Non è futurismo. È aritmetica. ## Cosa fare lunedì mattina {: #cosa-fare-lunedi-mattina } La buona notizia è che non servono task force, consulenti o programmi di trasformazione da dodici mesi e seicentomila euro. Servono tre scelte pratiche, e un po’ di coerenza. La prima è inserire la capacità di governo AI nei criteri di valutazione per ogni posizione aperta. Non come requisito tecnico, ma come competenza trasversale, allo stesso livello della capacità di comunicare o di lavorare in team. Fai quelle tre domande. Ascolta davvero le risposte. La seconda è chiedere ai tuoi riporti diretti come usano l’AI nel lavoro quotidiano. Non con una survey anonima, ma in una conversazione one-to-one. Scoprirai cose sorprendenti in entrambe le direzioni. Chi la usa bene spesso lo fa in silenzio. Chi la usa male a volte non si rende conto di quanto sia fragile il suo metodo. La terza è dare l’esempio. Se sei un imprenditore che non ha mai usato un agente AI per preparare un’offerta, analizzare un bilancio o scrivere una comunicazione importante, il messaggio che stai mandando è chiarissimo: non è importante. E la tua organizzazione ti crederà. In una PMI non puoi delegare il cambiamento. O parte da te, o non parte. ## Non è una morale {: #non-e-una-morale } Tra cinque anni probabilmente guarderemo i processi di hiring del 2025 come oggi guardiamo quelli del 2010, con un misto di tenerezza e incredulità. “Davvero assumevate persone senza verificare se sapevano lavorare con l’AI?” Davvero. E chi smette di farlo prima, senza aspettare che diventi “standard”, avrà un vantaggio che gli altri impiegheranno anni a colmare. Forse la domanda giusta, alla fine, non è se la prossima persona che assumi sappia usare l’AI. È se saprà governarla. E se tu sarai disposto a pretenderlo, anche quando è scomodo. --- # Il paradosso del piccolo: viva la regolamentazione europea - **URL:** https://margiovanni.it/it/blog/perche-bruxelles-puo-salvare-le-pmi-tech-europee/ - **Pubblicato:** 2026-03-11 - **Tag:** Compliance, Cybersecurity, Intelligenza Artificiale, Pmi Tech - **Tempo di lettura:** 10 min > Tra AI Act, CRA e NIS2, l’Europa sta riscrivendo le regole: non vince chi corre di più, ma chi costruisce software serio, sicuro e accessibile. ## Il paradosso del piccolo, visto da Pescara {: #il-paradosso-del-piccolo-visto-da-pescara } Lavoro in una piccola-media impresa tech a Pescara. Siamo una dozzina, non cinquanta, non duecento. Facciamo software per clienti diversi, dalla pubblica amministrazione a piattaforme SAAS, e la cosa che ci tiene in piedi, da sempre, è una specie di ossessione per la solidità. Architetture pensate, codice che regge, sistemi che non si sbriciolano quando qualcuno ci mette dentro dati veri, soldi veri, decisioni vere. Eppure, negli ultimi mesi, mi sono ritrovato a pensare una cosa un po’ amara: **è un momento brutale per avere idee**. Non perché manchi la creatività, anzi. Il problema è che spesso la creatività arriva insieme a una sensazione di impotenza. ## La sindrome del “l’hanno già fatto” {: #la-sindrome-del-lhanno-gia-fatto } Succede così, con una regolarità quasi comica. Lunedì mattina, brainstorming. Qualcuno butta lì un’idea. Ci accendiamo, iniziamo a immaginare come farla bene, quale sarebbe l’architettura giusta, dove stanno i rischi, come la venderemmo senza raccontarcela. Poi arriva mercoledì sera. Scroll su LinkedIn, o su Hacker News, e lì c’è l’annuncio: Google, Microsoft, OpenAI, oppure una startup appena finanziata con cifre che noi vediamo solo nei round raccontati nei podcast, ha appena presentato *la stessa cosa*. O qualcosa di sufficientemente simile da rendere la nostra idea, agli occhi del mercato, un clone in ritardo. Non è nemmeno una questione di “ci hanno copiato”. È più banale e più deprimente: loro hanno la scala. E in questa fase storica, la scala sembra contare più di tutto. Mi chiedo spesso se non stiamo entrando in un’epoca in cui l’innovazione, quella vera, diventa quasi un lusso riservato a chi può permettersi di sbagliare velocemente e in pubblico. ## Quando non ti battono perché sono migliori, ma perché sono più veloci {: #quando-non-ti-battono-perche-sono-migliori-ma-perche-sono-pi } Fin qui sarebbe già frustrante. Ma c’è un livello ulteriore, più difficile da digerire. Perché non sempre ti battono sul tempo con un prodotto migliore. A volte ti battono con qualcosa di mediocre, spedito in fretta, con test minimi e una fiducia quasi arrogante nel fatto che il brand reggerà comunque. Il “vibe coding”, che fino a poco fa sembrava un gioco da indie hacker, è entrato nelle enterprise. E non parlo del junior che usa copilot per scrivere un componente. Parlo di team interi che generano pezzi enormi di applicazione con prompt, fanno due prove al volo e poi mettono tutto in produzione. Negli ultimi mesi ho visto piattaforme con falle che fanno venire i brividi. Xss che si becca in cinque minuti, api senza rate limiting, flussi di pagamento senza idempotenza, gestione dei dati personali che probabilmente farebbe impallidire chiunque abbia mai fatto il DPO sul serio. Eppure sono lì. Sul mercato. Con utenti. Con fatturato. Il messaggio implicito, che ti arriva addosso anche se non vuoi ascoltarlo, è questo: la qualità non conta, conta la velocità. E se la qualità non conta, allora noi piccoli, che sulla qualità ci costruiamo la reputazione e spesso pure la sopravvivenza, che spazio abbiamo? ## L’epifania di Bruxelles (che non mi aspettavo) {: #lepifania-di-bruxelles-che-non-mi-aspettavo } Qui arriva la parte che, fino a un paio d’anni fa, non avrei mai pensato di scrivere. Per molto tempo ho guardato alla regolamentazione europea con fastidio. Il GDPR nel 2018 mi era sembrato un macigno: tanta fatica per chi già lavorava bene, mentre i grandi continuavano a fare i loro comodi e, al massimo, pagavano multe che per loro erano spiccioli. Poi però ho iniziato a guardare il quadro che si sta formando adesso. E ho avuto una sensazione strana, quasi controintuitiva: forse Bruxelles è una delle poche armi che ci restano. Non perché “la burocrazia è bella”, ci mancherebbe. Ma perché quello che sta prendendo forma non è un regolamento isolato. È un ecosistema normativo integrato che cambia il metro con cui si compete. Se l’Europa è fatta al 80% di PMI, e se vuole che queste PMI sopravvivano nell’era dell’AI, allora deve fare una cosa semplice e difficilissima: evitare che la dimensione sia l’unico vantaggio competitivo. E, nel bene e nel male, è esattamente quello che sta provando a fare. ## Sette norme, un’unica direzione {: #sette-norme-ununica-direzione } Le elenco, sì, ma con un’idea precisa: non leggerle come “sette obblighi”. Prova a leggerle come una strategia industriale. ### AI Act, il grande livellatore verso l’alto L’AI Act è in vigore dal 1° agosto 2024, con applicazione progressiva. Divieti da febbraio 2025, obblighi per sistemi ad alto rischio da agosto 2026. La cosa interessante è che non dice “non fate AI”. Dice “fatela bene”. Classifica i sistemi per rischio, e dove il rischio è alto chiede cose che, a dirla tutta, dovrebbero essere normali: gestione del rischio, qualità dei dati, supervisione umana, documentazione, trasparenza. Per una PMI che già lavora in modo ordinato, la compliance è spesso un delta gestibile. Non gratis, certo. Ma gestibile. Per chi ha messo in produzione un sistema critico costruito in tre settimane senza sapere davvero cosa fa, diventa un abisso. Devi ripensare processi, governance, architettura. Devi rallentare. Ed è qui che l’AI Act diventa, paradossalmente, pro PMI. Non perché protegge i piccoli in quanto piccoli, ma perché premia chi ha già una cultura del “facciamolo bene”. C’è anche un punto che mi interessa molto sui modelli general purpose: obblighi di trasparenza e documentazione per i provider, soprattutto per i modelli con rischio sistemico. Tradotto: se io costruisco un prodotto su un modello fondazionale, *ho più diritto* a sapere limiti, rischi e contorni. Oggi spesso lo capisci solo leggendo paper e post aziendali. ### Cyber Resilience Act, la fine del “funziona, non toccarlo” Il CRA è in vigore dal 10 dicembre 2024. Obblighi di segnalazione da settembre 2026, piena applicazione da dicembre 2027. Qui la musica cambia davvero: se metti sul mercato europeo un prodotto con elementi digitali, sei responsabile della sicurezza lungo il ciclo di vita. Aggiornamenti di sicurezza per almeno cinque anni, gestione documentata delle vulnerabilità, segnalazioni rapide, e soprattutto sbom. Lo sbom, detto senza romanticismi, è un inventario: sapere cosa c’è dentro il tuo software, incluse le dipendenze. Quando esce una CVE critica, non devi fare archeologia. Lo sai. E sai chi spesso è già strutturato così? Le PMI che hanno stack moderni, pipeline decenti, dipendenze tracciate. Chi invece soffre? Le organizzazioni enormi con anni di debito tecnico, applicazioni legacy intoccabili, componenti fermi al 2016, e nessuno che abbia davvero la mappa del territorio. Il CRA rende la manutenzione una cosa non più “se avanza tempo”, ma un dovere. E improvvisamente l’attenzione maniacale agli aggiornamenti smette di essere una fissazione personale e diventa una postura competitiva. ### Product Liability Directive, il software non è più intoccabile La nuova PLD è stata adottata nel 2024 e gli stati membri devono recepirla entro dicembre 2026. Qui confesso che un po’ di paura ce l’ho. Perché estende la responsabilità da prodotto difettoso anche al software. E in alcuni casi introduce meccanismi come l’inversione dell’onere della prova: se c’è un nesso plausibile tra difetto e danno, il produttore deve dimostrare che il prodotto non era difettoso. Ora, immagina un’azienda che ha spedito un’app finanziaria senza test seri, senza code review, senza documentazione. Se succede un danno, come lo dimostra? Una PMI che lavora con CI, test automatici, review tracciabili, decisioni architetturali annotate, changelog e release note, si ritrova con una cosa preziosa che non aveva chiamato così: un fascicolo difensivo. La PLD, nel concreto, trasforma la qualità del processo in uno scudo legale. ### European Accessibility Act, il web non è solo per chi ci vede bene L’EAA si applica già dal 28 giugno 2025. Accessibilità significa WCAG 2.1 AA come riferimento: semantica, contrasto, tastiera, screen reader, alternative testuali. Non la “pagina bella”, la pagina usabile anche da chi ha disabilità. Chi ha sempre trattato l’accessibilità come requisito, parte avvantaggiato. Chi ha costruito interfacce splendide e inutilizzabili con uno screen reader, deve correre. E qui c’è un’opportunità molto concreta: l’accessibilità diventa un servizio. Audit, remediation, design system accessibili. C’è anche l’esenzione per le microimprese, che è un dettaglio interessante: puoi essere abbastanza piccolo da non essere obbligato in certi casi, ma abbastanza competente da aiutare gli altri. ### NIS2, la cybersecurity non è più opzionale La NIS2 doveva essere recepita entro ottobre 2024, e in italia il recepimento è arrivato. L’applicazione è progressiva. La parte che colpisce le PMI non è solo “se rientri o no”. È l’effetto supply chain. Se il tuo cliente è soggetto NIS2, ti chiederà garanzie. Procedure. Incident response. Misure. La sicurezza diventa un prerequisito commerciale. Se non dimostri una postura seria, non lavori con certi clienti. Punto. E anche qui, chi ha investito prima, magari con fatica e senza gloria, si ritrova avanti. ### Data Act, i dati generati sono anche tuoi Il Data Act è in vigore dall’11 gennaio 2024 e si applica dal 12 settembre 2025. Il concetto, detto semplice, è questo: i dati generati dall’uso di un prodotto connesso devono essere accessibili all’utente e, su richiesta, condivisibili con terze parti. Per chi vive di lock-in, è una scossa. Per le PMI può essere un varco enorme: se i dati devono essere portabili, qualcuno deve costruire le infrastrutture, le API, i connettori, i formati. È quasi una norma anti-lock-in. E molte PMI, banalmente, non hanno mai avuto la forza di fare lock-in aggressivo. Ora quella “mancanza” può diventare un vantaggio. ### DMA e DSA, i gatekeeper con regole diverse Il DMA è pienamente applicabile da marzo 2024, il DSA da febbraio 2024. Qui il punto è politico ma molto concreto: i gatekeeper non possono più giocare con la stessa impunità di prima. Interoperabilità, divieti di auto-preferenza, più trasparenza. È sufficiente? Probabilmente no. Mi aspetto scappatoie, interpretazioni creative, avvocati molto ben pagati. Però cambia un principio: essere grandi non ti dà automaticamente il diritto di barare. ## Messo insieme, non è compliance: è un cambio di metrica {: #messo-insieme-non-e-compliance-e-un-cambio-di-metrica } Se guardo queste norme come un insieme, vedo un messaggio abbastanza chiaro. Nel mercato europeo, l’idea è che vinca chi fa le cose bene. Bene significa: AI trasparente e supervisionata, software mantenuto e sicuro, responsabilità reale quando fai danni, accessibilità come requisito, cybersecurity come pratica quotidiana, dati meno bloccati, piattaforme dominanti più controllate. E, quasi senza volerlo, questa direzione valorizza alcune caratteristiche tipiche delle PMI serie: attenzione al dettaglio, vicinanza al cliente, stack più aggiornati, meno legacy intoccabile, meno incentivi al “buttiamo fuori e poi si vede”. ## Però la realtà non è tutta rosa {: #pero-la-realta-non-e-tutta-rosa } Sarebbe disonesto dire che la compliance è gratis. Costa tempo, costa soldi, costa focus. E in una azienda di medie (o piccole) dimensioni ogni ora spesa su documentazione e processi è un’ora che non va su prodotto. C’è anche un rischio reale: che la compliance diventi, ancora una volta, un vantaggio dei grandi, quelli che possono permettersi dipartimenti legali e piattaforme di governance. Ma qui, forse, l’Europa ha capito un punto: la proporzionalità. Molte norme distinguono per rischio e dimensione. E poi c’è un’altra strada, che mi sembra molto concreta: trasformare la compliance in servizio. Se capisci davvero CRA, AI Act, NIS2, EAA, non solo come “spunte”, ma come implicazioni tecniche, puoi venderlo. Sbom, audit, hardening, governance AI, assessment di accessibilità. La compliance smette di essere solo un costo e diventa una competenza di mercato. ## Quello che farei lunedì mattina, davvero {: #quello-che-farei-lunedi-mattina-davvero } Non voglio chiudere con la morale. Preferisco chiudere con cose pratiche, perché forse è lì che le PMI possono aiutarsi a vicenda. Noi stiamo provando a costruire un framework interno unico, non sette processi separati. Per forza, siamo piccoli. E questa volta essere piccoli è un vantaggio, perché non possiamo permetterci silos. La documentazione che serve per il CRA aiuta anche con la PLD. Lo sbom serve per CRA, ma diventa anche una base utile per richieste in stile NIS2. La logica risk-based dell’AI Act si incastra bene con l’approccio del GDPR. Stiamo anche cercando di trattare la compliance come prodotto, non solo come adempimento. Se un cliente deve adeguarsi, qualcuno deve accompagnarlo. E se lo accompagni bene, non stai vendendo “burocrazia”. Stai vendendo riduzione del rischio, continuità operativa, reputazione. Poi c’è la formazione. Non quella fatta di slide e basta. Formazione per capire il *perché* delle regole, perché se capisci il perché, la checklist serve meno. Ragioni meglio quando arriva il caso strano, quello che non è scritto da nessuna parte. E infine la rete. Template, processi, lesson learned condivisi. La compliance non è un gioco a somma zero. Se il tuo ecosistema è più solido, lo sei anche tu. ## Forse è questo il punto: non dobbiamo chiedere scusa per essere piccoli {: #forse-e-questo-il-punto-non-dobbiamo-chiedere-scusa-per-esse } Non ho illusioni. Le big tech investiranno in compliance, troveranno modi per adattarsi, faranno lobbying, cercheranno interpretazioni favorevoli. Però qualcosa è cambiato: l’Europa sta dicendo che, nel suo mercato, la velocità senza responsabilità non è più un superpotere. E per chi, come noi, ha sempre costruito con cura non per virtù ma per necessità, questa è una notizia strana e bella. Forse non dobbiamo diventare più grandi. Forse dobbiamo solo continuare a fare le cose con attenzione e responsabilità. Solo che adesso, finalmente, c’è qualcuno che prova a far contare questa scelta. --- # Intervista impossibile a Guglielmo Marconi nel 2026 - **URL:** https://margiovanni.it/it/blog/intervista-impossibile-a-guglielmo-marconi-nel-2026/ - **Pubblicato:** 2026-03-09 - **Tag:** Comunicazione, Cultura Digitale, Intelligenza Artificiale, Social Network - **Tempo di lettura:** 22 min > Un Marconi catapultato nel 2026 commenta smartphone, social, ai e privacy. Un dialogo ironico sul segnale, il rumore e l’attenzione che perdiamo. *Nella serie "Interviste impossibili" faccio quello che la fisica non consente e il buon senso sconsiglia: prendo persone dal passato e le butto nel presente. Oggi tocca a Guglielmo Marconi, Nobel per la Fisica 1909, inventore del telegrafo senza fili, portato con una macchina del tempo dal 1937 al marzo 2026. Lo incontro in un bar di Pescara. Ha ordinato un caffè. Lo beve in silenzio, guardando la gente ai tavoli. Tutti fissano un rettangolo luminoso.* **Signor Marconi, benvenuto nel 2026. Come si sente?** Confuso. Ma meno di quanto pensiate. Ho dedicato la mia vita a eliminare i fili. Vedo che ci siete riusciti. Quello che non avevo previsto è che avreste rimesso i fili per ricaricare gli apparecchi senza fili. **Si riferisce ai caricabatterie.** Mi riferisco al fatto che in questo locale ci sono quattordici persone e undici di loro sono collegate a una presa a muro. Ho eliminato i fili nel 1896 e voi li avete reintrodotti nel 2026 per non restare senza TikTok. Mi sento preso in giro. **In realtà esiste anche la ricarica wireless.** Me l'hanno spiegata. Appoggiate l'apparecchio su un disco e si ricarica. Senza fili. Ma il disco è collegato a un filo. Avete inventato un intermediario tra il filo e l'apparecchio e lo chiamate "wireless". Ai miei tempi un passaggio in più nella catena si chiamava inefficienza. Oggi si chiama innovazione. ## L'etere saturo {: #saturated-ether } **È la prima cosa che ha notato arrivando nel 2026?** No. La prima cosa che ho notato è il rumore. Non il rumore fisico. Quello è diminuito, i vostri motori sono più silenziosi dei nostri, le città sono meno caotiche di quanto immaginassi. Parlo del rumore elettromagnetico. Ai miei tempi, per captare un segnale radio dovevo isolarmi, costruire antenne enormi, eliminare ogni interferenza. Voi vivete immersi in un campo elettromagnetico così denso che se io provassi a fare il mio esperimento del 1901 da questo bar, non sentirei nulla. Siete riusciti a saturare l'etere. Complimenti. **Tecnicamente l 'etere non esiste. Einstein ha...** Sì, sì, me l'hanno detto. Hanno anche detto che Plutone non è più un pianeta. Avete l'abitudine di togliere le cose dopo che la gente ci si è affezionata. ## Lo smartphone e i filtri {: #smartphone-and-filters } **Le abbiamo dato uno smartphone per orientarsi. Come è andata?** Il vostro collega mi ha dato l'apparecchio. Lo chiamate telefono, ma non ha nulla a che fare con un telefono, e mi ha mostrato le funzioni di base. Posso telefonare, che è l'unica cosa che non fate mai con questo oggetto. Posso scrivere messaggi, scattare fotografie, consultare l'intero sapere umano, calcolare la traiettoria di un satellite, e ordinare la cena. È il dispositivo più potente mai costruito dall'uomo. Lo usate principalmente per discutere con sconosciuti. **Non è del tutto...** Mi ha anche mostrato che l'apparecchio ha tre fotocamere sul retro. Tre. La prima fotografia della storia è stata scattata da Niépce nel 1826 con una camera che pesava venti chili e richiedeva otto ore di esposizione. Voi avete tre fotocamere in tasca e le usate per fotografare il piatto di pasta prima di mangiarlo. Niépce fotografò un tetto dal davanzale della sua finestra e ci mise otto ore. Voi fotografate un piatto di carbonara e ci mettete due secondi, poi ne perdete altri quaranta a scegliere il filtro giusto. **I filtri sono una questione estetica.** I filtri sono una questione filosofica. State dicendo alla realtà che non è abbastanza bella così com'è. Il tramonto deve essere più arancione. La pasta deve essere più dorata. Il vostro viso deve essere più liscio. Avete la macchina fotografica più sofisticata della storia e la prima cosa che fate è mentire con essa. **Non direbbe lo stesso della pittura? Anche i pittori interpretavano la realtà.** I pittori ci mettevano anni di studio. Il vostro filtro "Valencia" ci mette un centesimo di secondo. La differenza tra arte e menzogna è il tempo che ci dedichi. **Ha scattato qualche foto lei?** Ho scattato una foto al mare. Da qui si vede il mare, è una cosa che apprezzo molto di questa città. L'ho scattata senza filtri. Poi il telefono mi ha suggerito di "migliorarla" automaticamente. Ho premuto il tasto e il mare è diventato più blu, il cielo più terso, la luce più calda. Ho guardato fuori dalla finestra e poi ho guardato la foto. Erano due posti diversi. Ho cancellato la foto e ho guardato il mare vero. Era meglio. ## Tre punti contro una faccina {: #three-dots-vs-smiley } **Parliamo del suo campo: le comunicazioni. La sua invenzione trasmetteva segnali Morse attraverso l 'Atlantico. Oggi trasmettiamo video in alta definizione via satellite, in tempo reale, ovunque nel mondo. Cosa ne pensa?** Penso che la potenza del segnale sia impressionante. E penso che la qualità di ciò che trasmettete sia inversamente proporzionale alla potenza del segnale. Nel 1901 ho mandato la lettera "S" attraverso l'oceano. Tre punti. Era tutto quello che la tecnologia consentiva, e quei tre punti hanno cambiato il mondo. Oggi potreste trasmettere l'intera Divina Commedia in un centesimo di secondo, e la usate per mandare una faccina gialla che piange dal ridere. **L 'emoji.** L'emoji. Siete tornati ai geroglifici. Tremilacinquecento anni di scrittura alfabetica, e il messaggio più diffuso al mondo è una faccina. **Ma è efficiente. Comunica un 'emozione in un solo carattere.** Anche il punto e virgola comunica un'emozione. Si chiama "sono una persona che sa usare il punto e virgola". Non la sottovaluti. **Ha provato a mandare un messaggio?** Ho mandato un messaggio al vostro collega per ringraziarlo del caffè. Ho scritto: "Egregio collega, la ringrazio per la cortese ospitalità e per l'eccellente caffè. Cordiali saluti, G. Marconi." Mi ha risposto con il pollice in su. Un pollice. Ho scritto trentadue parole e ne ho ricevuta mezza. Se avessi saputo che il futuro della comunicazione era un pollice, avrei fatto l'agricoltore. **Oggi comunichiamo in modo più informale.** Informale. Questa è una parola gentile. Ho letto alcune delle vostre conversazioni, non per indiscrezione, il vostro collega me le ha mostrate per spiegarmi il contesto. Abbreviate le parole. Eliminate le vocali. Usate la lettera "k" al posto di "ch". Scrivete "cmq" e pretendete che significhi "comunque". Io ho lavorato per trasmettere un singolo carattere attraverso l'oceano. Voi ne eliminate il più possibile per risparmiare un decimo di secondo. La differenza è che io non avevo scelta. Voi sì, e scegliete l'analfabetismo. **Non le sembra un giudizio un po ' severo?** Forse. Ma consideri questo: il codice Morse era un sistema di comunicazione limitato. Punti e linee, nient'altro. Eppure i telegrafisti sviluppavano uno stile personale, riconoscibile, elegante. Ogni operatore aveva il suo ritmo, la sua cadenza. Si riconoscevano tra loro dal tocco. Con ventisei lettere e dieci numeri creavano messaggi di una precisione e una concisione ammirevoli. Voi avete a disposizione l'intero alfabeto, la punteggiatura, le emoji, le GIF, i vocali, i video, e il risultato medio è "ok ci sentiamo dopo". Il problema non è lo strumento. Il problema è che avete smesso di rispettare il mezzo. **Eppure la comunicazione non è mai stata così democratica. Tutti possono parlare con tutti.** Questo è vero ed è importante. Ai miei tempi comunicare a distanza era un privilegio di stati, eserciti e aziende. Oggi chiunque può raggiungere chiunque. Ma "poter parlare" e "avere qualcosa da dire" sono due cose diverse, e voi avete risolto magnificamente il primo problema ignorando completamente il secondo. ## I social network {: #social-networks } **Ha avuto modo di esplorare i social network?** Ho capito il meccanismo. Ognuno è diventato una piccola stazione radio. Trasmette in continuazione, su tutte le frequenze, senza sapere chi ascolta. Ai miei tempi si chiamava interferenza ed era un problema tecnico. Oggi è un modello di business. **Quale piattaforma l 'ha colpita di più?** Ho passato due ore su quella che chiamate X, che prima si chiamava Twitter, che adesso forse si chiama di nuovo in un altro modo, non ho capito. È un posto dove le persone si insultano in pubblico con grande convinzione su argomenti di cui sanno poco. Un uomo con un gatto come immagine del profilo stava spiegando a un premio Nobel che sbagliava sulla fisica quantistica. Il premio Nobel ha risposto con la faccina che piange. Il gatto ha avuto più "mi piace". In questo momento sto rivalutando il telegrafo. **E TikTok?** TikTok è la cosa più vicina alla magia che ho visto in questo secolo, e intendo magia nel senso antico, cioè l'arte di catturare l'attenzione di una persona e non lasciarla andare. Ho iniziato a guardare un video di un ragazzo che spiega la teoria della relatività in quindici secondi. Un'ora dopo stavo guardando una donna che impila cereali su un cucchiaio. Non so come ci sono arrivato. Non so come uscirne. Credo di aver capito perché avete bisogno dei caricabatterie. **Ha visto TikTok come un problema?** L'ho visto come un'arma. Non in senso bellico, in senso tecnico. È un dispositivo di cattura dell'attenzione più efficiente di qualunque cosa io abbia mai progettato. La radio catturava l'attenzione con il contenuto: un concerto, un discorso, una notizia. TikTok cattura l'attenzione con il meccanismo stesso. Il contenuto è quasi irrilevante: è il ritmo, il taglio, la promessa del prossimo video che potrebbe essere migliore di questo. È ingegneria applicata al cervello umano. È brillante. È terrificante. È entrambe le cose. **LinkedIn le piacerebbe.** Mi è stato mostrato. Un posto dove le persone si congratulano a vicenda per aver cambiato lavoro. Ho contato: un certo Marco da Brescia ha ricevuto duecentoquattordici "congratulazioni" per essere diventato Regional Sales Manager. Ho inventato la radio, ho preso il Nobel, e mia madre mi ha detto "bravo". Duecentoquattordici persone non le conoscevo in totale. **LinkedIn serve anche per fare networking professionale.** Networking. Un'altra parola che non esisteva ai miei tempi. Io per fare "networking" andavo a cena con il re d'Inghilterra. Voi mandate richieste di collegamento a persone che non avete mai incontrato con un messaggio precompilato. Capisco che sia più democratico, ma è anche più triste. Ho notato anche un genere letterario particolare su questa piattaforma. Lo chiamo "l'epifania del lunedì mattina". Inizia sempre con una storia edificante tipo "ero in fila alla posta e un bambino mi ha insegnato la leadership" e finisce con un insegnamento morale vagamente collegato al management. Ho letto trentasette di questi post. Sono tutti diversi e sono tutti uguali. Qualcuno ci mette anche la foto commossa. Ai miei tempi le epifanie erano riservate ai santi. Ora le ha chiunque abbia un abbonamento Premium. ## Il giornalismo che si controlla da solo {: #journalism-checking-itself } **Lei era anche un uomo di media: la sua compagnia aveva il monopolio delle comunicazioni transatlantiche. Oggi l 'informazione si muove in modi molto diversi. Ha letto qualche giornale online?** Ho provato. Il vostro collega mi ha mostrato un sito di notizie. Prima di leggere l'articolo ho dovuto: rifiutare i cookie, chiudere un banner che mi chiedeva di iscrivermi alla newsletter, chiudere un altro banner che mi proponeva un abbonamento, chiudere una notifica, chiudere una pubblicità video, e scorrere oltre un blocco di "articoli consigliati" che non c'entravano nulla con quello che cercavo. Quando finalmente ho raggiunto l'articolo, avevo dimenticato perché volevo leggerlo. **È il modello economico del giornalismo online. I ricavi vengono dalla pubblicità.** Anche la radio commerciale funzionava con la pubblicità. Ma tra una pubblicità e l'altra c'era il contenuto. Nei vostri giornali online tra un contenuto e l'altro c'è la pubblicità. Avete invertito il rapporto. L'articolo è la pausa tra due spot. **Cosa pensa delle fake news?** Ai miei tempi la propaganda esisteva eccome. Mussolini usava la radio in modo sistematico e molto efficace: lo so bene perché la mia azienda gli forniva l'infrastruttura, e questa è una cosa con cui ho fatto pace solo parzialmente. La differenza è che negli anni Trenta la propaganda aveva una regia. Qualcuno decideva cosa dire e come dirlo. Oggi la disinformazione è democratica: chiunque può inventare una notizia falsa, pubblicarla, e raggiungere milioni di persone prima che qualcuno si prenda la briga di verificarla. Avete eliminato il monopolio della verità, che è una buona cosa. Ma avete eliminato anche il concetto stesso di verità, che è una pessima cosa. **Oggi si parla molto di "fact-checking".** Bellissima espressione. Avete inventato una professione il cui scopo è verificare se le cose che dite sono vere. Ai miei tempi si chiamava "giornalismo". Ora il giornalismo ha bisogno di un reparto apposito per controllare se stesso. È come un ristorante che assume un ispettore a tempo pieno per verificare che il cuoco non stia avvelenando i clienti. Se hai bisogno dell'ispettore, forse il problema è il cuoco. ## L'Italia e l'innovazione {: #italy-and-innovation } **Veniamo alla questione italiana. Lei è uno dei più grandi inventori della storia. Italiano. Eppure il governo italiano inizialmente non credette nel suo lavoro e lei andò in Inghilterra. Oggi l 'Italia ha un rapporto complicato con l'innovazione tecnologica. Qualcosa è cambiato?** Mi faccia capire. Avete inventato la radio, il telefono, contribuito al microprocessore. Avete avuto Fermi, Rubbia, Faggin. Avete un patrimonio scientifico e ingegneristico di tutto rispetto. E oggi importate i software gestionali dalla Germania. Direi che non è cambiato nulla. L'Italia è bravissima a generare genio e pessima a trattenerlo. Ai miei tempi si emigrava con un baule. Oggi si emigra con un laptop. **Però lei alla fine è tornato in Italia.** Sono tornato perché amavo l'Italia. Non perché l'Italia amasse me. C'è una differenza. L'Italia mi ha dato il Nobel... No, aspetti, quello me l'hanno dato gli svedesi. L'Italia mi ha dato un seggio al Senato. Dopo che avevo già vinto il Nobel, fondato un'azienda mondiale, e reso possibile il salvataggio dei passeggeri del Titanic grazie alla radio. Sapete come funziona l'Italia? Fai qualcosa di straordinario, te ne vai, hai successo all'estero, e poi ti invitano a un convegno. Se hai molto successo, ti intitolano un aeroporto. Dopo che sei morto. **Roma Fiumicino si chiama Leonardo da Vinci, in effetti. E l 'aeroporto di Bologna...** Si chiama Marconi, sì. Lo so. Un aeroporto. Ho reso possibile la comunicazione globale e il mio premio è che cinquemila persone al giorno ci parcheggiano la macchina sopra. Ringrazio sentitamente. **Come trova Pescara?** Non la conoscevo. È una bella città, il mare è splendido, il caffè è eccellente, e la gente ha una gestualità che rende superflua qualunque tecnologia di comunicazione. Ho visto due signore al mercato avere una conversazione completa usando solo le mani e le sopracciglia. Nessun telefono, nessun messaggio, nessuna emoji. Comunicazione pura. Probabilmente più efficiente del 5G. **Ha un 'opinione sul sistema burocratico italiano?** Il vostro collega mi ha raccontato che per aprire un'attività servono in media centoventi giorni e trentacinque passaggi burocratici. Io nel 1897 ho convinto il governo britannico a finanziare i miei esperimenti in quattro settimane. Il problema dell'Italia non è la mancanza di innovazione. È che l'innovazione deve passare attraverso un sistema progettato per impedirla. È come costruire un'automobile e poi insistere che debba viaggiare su una strada romana. La strada romana è bella, è storica, è patrimonio dell'umanità. Ma ci mettete tre ore per arrivare in qualunque posto. ## L'intelligenza artificiale {: #artificial-intelligence } **Le abbiamo spiegato cos 'è l'intelligenza artificiale. Che impressione le ha fatto?** Notevole. Avete costruito una macchina che capisce il linguaggio umano, genera testo coerente, risolve problemi complessi, e la prima cosa che le persone le chiedono è di scrivere un'email per dire al collega che il meeting è spostato alle tre. **Be ', è utile.** Anche il telegrafo era utile. Ma nessuno mandava un telegramma per dire "arrivo cinque minuti tardi". C'era un costo per carattere, e quel costo vi costringeva a pensare prima di trasmettere. Avete eliminato il costo e avete eliminato il pensiero. **Ha provato a usare l 'intelligenza artificiale?** Il vostro collega mi ha fatto parlare con uno di questi sistemi. Ho chiesto: "Chi era Guglielmo Marconi?" Mi ha risposto in modo accurato, cortese, e leggermente noioso. Come un'enciclopedia con le buone maniere. Poi ho chiesto: "Marconi aveva ragione su tutto?" E la macchina ha iniziato a elencare le mie posizioni politiche discutibili con la stessa cortesia con cui mi aveva elogiato trenta secondi prima. È una macchina diplomatica. Forse troppo. **Cosa intende?** Intendo che la macchina non ha opinioni. O meglio, le ha ma le presenta come se non le avesse. Dice "da un lato" e "dall'altro lato" con una simmetria che è confortante ma intellettualmente disonesta. La verità non è quasi mai simmetrica. A volte un lato ha ragione e l'altro ha torto. Il telegrafo trasmetteva quello che gli dicevi. Questa macchina ti risponde quello che vuoi sentirti dire, ma in modo che sembri equilibrato. Non so quale sia peggio. **Le ho chiesto di scrivere questa intervista, per curiosità. Ha funzionato?** La macchina ha scritto un'intervista molto ragionevole in cui io dico cose molto ragionevoli in modo molto ragionevole. Non c'era una sola frase che fosse sbagliata. Non c'era nemmeno una sola frase che fosse viva. Era come un ritratto in cui le proporzioni sono perfette ma mancano gli occhi. Tecnicamente corretto. Umanamente vuoto. **Però l 'AI potrebbe democratizzare l'accesso alla conoscenza. Chiunque può chiedere qualunque cosa.** Questo l'ha già fatto il vostro Internet, no? Eppure le persone non sono diventate più colte. Sono diventate più informate, che è una cosa diversa. Sapere dove trovare l'informazione non è la stessa cosa che capirla. L'intelligenza artificiale porta questo un passo avanti: vi dà la risposta già pronta, già digerita, già formattata. Non dovete nemmeno fare lo sforzo di cercare. E lo sforzo, le assicuro, era la parte importante. Non si capisce nulla senza fatica. Il cervello, come il muscolo, ha bisogno di resistenza per crescere. Voi state eliminando la resistenza e vi stupite che il muscolo si atrofizzi. **Ma per un inventore come lei, avere accesso a tutta la conoscenza umana istantaneamente...** Sarebbe stato magnifico. E pericoloso. Quando ho iniziato i miei esperimenti, non sapevo se la curvatura della Terra avrebbe bloccato le onde radio. Nessuno lo sapeva. E proprio perché nessuno lo sapeva, ho dovuto provare. Se avessi avuto la vostra intelligenza artificiale, le avrei chiesto: "Le onde radio possono seguire la curvatura terrestre?" E lei mi avrebbe detto, correttamente, con i dati disponibili a fine Ottocento, che no, non era possibile. E io non avrei provato. E la radio transatlantica non sarebbe nata. A volte il progresso viene dall'ignoranza, non dalla conoscenza. Dall'ostinazione di provare una cosa che tutti i dati disponibili dicono impossibile. **È un argomento contro l 'intelligenza artificiale?** No. È un argomento contro la certezza. L'intelligenza artificiale è addestrata su ciò che è noto. Ma le scoperte avvengono in ciò che è ignoto. Se la macchina vi convince che sa tutto, smetterete di cercare. E quando smetterete di cercare, smetterete di trovare. ## La radio sopravvive {: #radio-survives } **Parliamo di qualcosa di più leggero. La radio. La sua invenzione. Come la trova nel 2026?** Esiste ancora. Questo mi ha commosso. Non me l'aspettavo. In un mondo di podcast, streaming, intelligenza artificiale, la radio è ancora lì. Accendi e qualcuno parla. È la cosa più semplice e longeva che abbia inventato. Sono orgoglioso. **Ma la ascolta poca gente, ormai.** Questo lo dicevano anche nel 1945, quando è arrivata la televisione. Poi lo hanno detto quando è arrivato Internet. Poi quando sono arrivati i podcast. La radio è come un gatto: tutti pensano che stia per morire e invece sopravvive a tutti. Sa perché? **Perché?** Perché non richiede le mani né gli occhi. Potete ascoltarla mentre guidate, cucinate, lavorate. La televisione vi inchioda. Il telefono vi inchioda. La radio vi lascia liberi. Nel 2026 come nel 1920, la libertà è un vantaggio competitivo che non passa mai di moda. **Ha sentito parlare di Spotify?** Tutta la musica del mondo, accessibile in qualunque momento, per il prezzo di dieci caffè al mese. È la cosa più bella e la più triste che abbia visto. Bella perché un ragazzo a Pescara può ascoltare un'orchestra di Vienna con una qualità che nei miei tempi era riservata a chi si sedeva in prima fila. Triste perché quello stesso ragazzo cambierà brano dopo venti secondi perché "non lo prende subito". Avete accesso a tutto e la pazienza per nulla. **La musica oggi è molto diversa da quella del suo tempo.** Ho ascoltato. Alcune cose sono meravigliose. Altre durano due minuti e mezzo, hanno un testo che si ripete identico sei volte, e sono prodotte da un computer. Non sono contrario alla brevità (il codice Morse era brevissimo) ma la brevità funziona quando ogni elemento è essenziale. In molte delle cose che ho ascoltato, la brevità è usata per nascondere il vuoto. Poi mi hanno fatto ascoltare una cosa chiamata "lo-fi beats to study to". Una diretta streaming che dura ventiquattro ore al giorno, sette giorni su sette, di musica senza parole destinata a fare da sottofondo. La radio, la mia invenzione, è diventata tappezzeria sonora. Non so se esserne lusingato o offeso. Forse entrambi. ## Lavoro, dati, ambiente {: #work-data-environment } **Come immagina il lavoro nel 2026, visto da fuori?** Sono stato nel vostro ufficio. Ho visto le persone lavorare. In teoria lavorano otto ore al giorno. In pratica passano tre ore in riunioni, un'ora a rispondere alle email, un'ora a cercare il documento che gli serve in un posto che chiamano "cloud", che è un nome bellissimo per un armadio, e le restanti tre ore a lavorare davvero. Ai miei tempi non avevamo le riunioni. Ci parlavamo. È diverso. **In che senso?** Una riunione è una conversazione con una data di inizio, una durata prevista, un ordine del giorno, e nessuna garanzia che qualcuno dica qualcosa di utile. Ai miei tempi se dovevo parlare con qualcuno andavo nel suo ufficio, dicevo quello che dovevo dire, e tornavo al mio lavoro. Durava quattro minuti. Non aveva bisogno di un "invite" su un calendario condiviso, di un link per il collegamento a distanza, e di un messaggio di follow-up per riassumere quello che ci eravamo appena detti a voce. Voi avete trasformato il parlare in un processo burocratico. **Le riunioni servono a coordinare team distribuiti. Molte persone lavorano da casa.** Questo l'ho trovato incredibile. Potete lavorare da qualunque posto. Dal divano. Da un bar. Da un altro paese. Il vostro collega mi ha detto che un suo collaboratore lavora dalla Romania. Dalla Romania! Ai miei tempi per lavorare con qualcuno in un altro paese dovevi prendere un piroscafo. Adesso accendi il computer e parli con Bucarest. Questa è la vera rivoluzione. Non la macchina intelligente, non il video in alta definizione. Il fatto che il lavoro non ha più bisogno di un luogo. Questo cambia tutto. Avete capito che cambia tutto? **Non tutti l 'hanno capito, in effetti.** Me ne sono accorto. Il vostro collega mi ha spiegato che molte aziende stanno chiedendo ai dipendenti di tornare in ufficio. Avete scoperto che il lavoro è indipendente dal luogo, avete gli strumenti per farlo funzionare, e state tornando indietro perché i dirigenti hanno bisogno di vedere le persone sedute alla scrivania per credere che stiano lavorando. Ai miei tempi questo si chiamava sorveglianza. Oggi si chiama "cultura aziendale". **A proposito di sorveglianza. Oggi c 'è un grande dibattito sulla privacy. I nostri dati personali vengono raccolti da aziende private, governi, piattaforme.** Mi è stato spiegato. Se ho capito bene, ogni volta che usate il telefono, e lo usate sempre, qualcuno registra dove siete, cosa cercate, con chi parlate, cosa comprate, cosa vi piace, cosa vi fa arrabbiare, e quanto dormite. Poi queste informazioni vengono usate per mostrarvi pubblicità su cose che non sapevate di volere finché non ve le hanno mostrate. Corretto? **Più o meno.** Ho una domanda. **Prego.** Ma perché lo accettate? **È complicato. I servizi sono gratuiti e...** No, non è complicato. Ai miei tempi se qualcuno leggeva la vostra posta era un reato. Se qualcuno vi seguiva per strada era un maniaco. Se qualcuno sapeva cosa avevate comprato era il negoziante, e gli davate del lei. Oggi fate volontariamente tutto questo, ogni giorno, in cambio della possibilità di mettere orecchie da coniglio sulla vostra foto. Il rapporto costo-beneficio mi sfugge. **Ma sono servizi utili. Le mappe, il meteo, la posta elettronica...** Ai miei tempi le mappe erano di carta e funzionavano benissimo. Il meteo lo capivate guardando il cielo. La posta arrivava una volta al giorno e nessuno è morto per aver ricevuto una lettera alle dieci invece che alle otto. Voi avete sostituito cose che funzionavano con versioni digitali che funzionano meglio in cambio di un prezzo che non vedete. Il prezzo si chiama "voi". I vostri dati, le vostre abitudini, i vostri desideri. Siete diventati il prodotto. E non ve ne siete nemmeno accorti, perché il prodotto è gratuito e chi vuole lo compra. **L 'Europa ha introdotto il GDPR per proteggere i dati personali.** Sì, me l'hanno spiegato. Ogni sito web ora vi chiede il permesso prima di spiarvi. E voi premete "Accetta tutti i cookie" senza leggere, perché il banner è fastidioso e volete arrivare al contenuto. Avete creato una legge per proteggervi da voi stessi e la aggirate voi stessi. È la cosa più italiana che ho sentito da quando sono arrivato. **Un tema che non esisteva ai suoi tempi: il cambiamento climatico. Le onde radio non inquinano, ma l 'infrastruttura digitale che ne è derivata consuma enormi quantità di energia.** Mi è stato detto che un singolo data center, uno dei magazzini dove tenete il vostro "cloud", consuma l'energia di una piccola città. Che addestrare un modello di intelligenza artificiale produce l'anidride carbonica di cinque automobili per tutta la loro vita. Che guardare un video in streaming per un'ora consuma l'elettricità necessaria per far funzionare un frigorifero per una settimana. Il mondo immateriale che avete costruito ha un costo materiale enorme. Ma siccome non lo vedete fate finta che non esista. **Anche la rivoluzione industriale aveva costi ambientali.** Sì, ma li vedevamo. Il fumo nero delle fabbriche era lì, visibile, tangibile. Non potevamo ignorarlo. Il vostro inquinamento è invisibile. I server sono in edifici anonimi in campagna. L'energia arriva attraverso fili che non guardate. L'anidride carbonica va in alto, dove non la vedete. Avete creato un sistema che distrugge l'ambiente in modo elegante, pulito, e invisibile. È l'unico settore in cui la vostra estetica è impeccabile. **È un 'osservazione dura.** Non è dura, è matematica. Quando la trasmissione è gratuita e istantanea, il valore del singolo messaggio tende a zero. Io ho speso anni per mandare tre punti attraverso l'Atlantico. Voi mandate trecento messaggi al giorno e nessuno di quelli vale quei tre punti. **Non le sembra di idealizzare il passato?** Forse. Il passato non era migliore. Era più lento, più ingiusto, più violento, più ignorante. Non tornerei indietro nemmeno se potessi... Beh, dovrò tornarci, immagino, per la questione della macchina del tempo. Ma il passato aveva una cosa che voi avete perso: il rapporto tra sforzo e valore. Quando comunicare costava fatica, si comunicava solo ciò che valeva la fatica. Quando leggere richiedeva concentrazione, si leggeva solo ciò che meritava concentrazione. Quando ascoltare significava sedersi davanti a una radio e non fare altro, si ascoltava davvero. Voi fate tutto simultaneamente e il risultato è che non fate nulla davvero. **I multitasker non sarebbero d 'accordo.** Il multitasking è l'arte di fare molte cose male contemporaneamente. Io per captare il segnale da Poldhu a Terranova ho dovuto eliminare ogni distrazione, ogni interferenza, ogni rumore. Il segnale era debolissimo. Se avessi fatto multitasking, se avessi cercato di captare il segnale mentre leggevo il giornale e rispondevo alle lettere, non l'avrei mai sentito. I grandi risultati vengono dall'attenzione totale. E l'attenzione totale è la cosa più rara nel vostro mondo. ## Spegnete tutto per un'ora {: #switch-everything-off } **Un 'ultima domanda. Se potesse mandare un messaggio a tutto il mondo, come fece nel 1901, ma stavolta con parole invece che con tre punti, cosa direbbe?** Direi: spegnete tutto per un'ora. Non per luddismo. Non perché la tecnologia sia cattiva. Ma perché non potete sapere cosa vale il segnale se non conoscete il silenzio. Io ho passato anni ad ascoltare il rumore statico dell'atmosfera prima di sentire quei tre punti. Voi non ascoltate più il silenzio. E senza silenzio, anche il segnale più potente è solo rumore. **Non teme che nessuno la ascolterebbe?** Nessuno mi ascoltò nemmeno nel 1895 quando presentai l'idea al governo italiano. E guardate cosa è successo dopo. I messaggi più importanti sono quelli che inizialmente nessuno vuole sentire. Se il vostro messaggio piace subito a tutti, probabilmente non state dicendo nulla di nuovo. **Vuole aggiungere qualcosa?** Voglio ringraziare la signora del bar che mi ha chiamato "giovanotto". Non so se sia per gentilezza o per ignoranza, ma in entrambi i casi mi ha reso felice. E voglio dire che il caffè qui è eccellente. Davvero eccellente. In centotrentadue anni, almeno quello non l'avete rovinato. **Grazie, signor Marconi.** Grazie a voi. Adesso, se non vi dispiace, vorrei guardare il mare per un po'. Senza filtri. * * * *Guglielmo Marconi (1874-1937) è stato un inventore, imprenditore e politico italiano. Premio Nobel per la Fisica nel 1909, è universalmente riconosciuto come il padre delle telecomunicazioni senza fili. Non è mai stato a Pescara, per quanto ne sappiamo. Il caffè, qui, è davvero buono.* *Questa è la prima delle Interviste impossibili. Se avete suggerimenti su chi portare nel 2026, scrivetemi. Ho una macchina del tempo e non ho paura di usarla.* --- # Le mani e la macchina: la fiducia nel software - **URL:** https://margiovanni.it/it/blog/le-mani-e-la-macchina-la-fiducia-nel-software/ - **Pubblicato:** 2026-03-08 - **Tag:** Fiducia, Normative Europee, Open Source, Software - **Tempo di lettura:** 10 min > Il software regge il mondo ma resta invisibile. Tra ai, open source e regole europee, la fiducia si costruisce con cura, scelte e responsabilità. ## Le mani e la macchina {: #le-mani-e-la-macchina } Mio nonno faceva (ANCHE) il falegname. Quando gli chiedevi come facesse a capire se un pezzo di legno era buono, non tirava fuori teorie. Si fermava, lo girava tra le mani, lo annusava, e poi diceva: “lo senti”. Ogni volta che ripenso a quella scena mi viene da sorridere, e poi mi prende una specie di nostalgia strana. Perché io faccio software da vent’anni e quando un cliente mi chiede come faccio a sapere se un sistema è buono, vorrei poter rispondere allo stesso modo. Vorrei poter dire “lo senti” e chiudere lì. Solo che la verità è più complicata, e forse è proprio questo il punto. Il software non lo tocchi. Non lo annusi. Non lo guardi controluce per cercare le venature. Eppure è ovunque. È la cosa più potente e più invisibile che abbiamo costruito. E quando una cosa è così invisibile, la fiducia diventa tutto. ## Il mondo gira su cose che non vedete {: #il-mondo-gira-su-cose-che-non-vedete } Stamattina avete fatto colazione. Il latte che avete comprato è arrivato al supermercato attraversando una catena logistica governata da software. Il pagamento al registratore di cassa è passato attraverso più sistemi di quanti ne immaginiamo, spesso senza che nessuno se ne accorga. Il semaforo che avete incrociato uscendo di casa esegue un algoritmo. L’ascensore ha un firmware. Il vostro stipendio è un numero in un database. Non lo dico per fare scena. È solo il mondo com’è adesso. E qui arriva il paradosso che mi inquieta un po’. Quasi nessuno, tra chi prende decisioni su come funziona la società, ha una comprensione profonda di come funzionano questi sistemi. Non per stupidità o pigrizia. Piuttosto per un difetto strutturale nella nostra cultura: per anni abbiamo trattato la tecnologia come una cosa *da tecnici* , un reparto, un angolo della mappa. Nel frattempo è diventata il tessuto connettivo di tutto. Quando un consiglio di amministrazione approva un sistema basato su ai per filtrare le candidature, sta prendendo una decisione tecnologica? Sì. Ma sta anche prendendo una decisione etica, giuridica, sociale. Sta decidendo quali pregiudizi sono accettabili, quale margine di errore è tollerabile, quanta opacità è ammissibile in un processo che cambia la vita delle persone. E spesso non lo sa. ## Cosa succede quando nessuno capisce la macchina {: #cosa-succede-quando-nessuno-capisce-la-macchina } C’è una storia che nel nostro settore conosciamo bene, ma che raramente raccontiamo fuori dalle nostre stanze. Dentro quasi ogni sistema che usate, dal sito della banca all’app con cui ordinate la cena, ci sono piccoli pezzi di codice scritti da persone che non incontrerete mai. Sono librerie open source: componenti gratuiti, condivisi, mantenuti spesso da singoli individui nel loro tempo libero. Qualche tempo fa qualcuno ha tentato di inserire una porta segreta in una di queste librerie, un componente usato da milioni di server nel mondo. Il tentativo è stato scoperto quasi per caso: un ingegnere si è accorto che il sistema impiegava mezzo secondo in più ad avviarsi. Mezzo secondo. Da quel mezzo secondo si è risaliti a un’operazione sofisticata, probabilmente sponsorizzata da uno Stato, che avrebbe potuto compromettere infrastrutture critiche su scala globale. La cosa che dovrebbe togliere il sonno non è che qualcuno ci abbia provato. È che l’intera catena di sicurezza dipendeva da una persona sola, un volontario, che manteneva quel codice nel tempo libero mentre combatteva con il burnout. Non è un aneddoto isolato. È un modello. E mi chiedo spesso quanto possa reggere. ## L’ai non è intelligente (e va bene così) {: #lai-non-e-intelligente-e-va-bene-cosi } Qui bisogna essere chiari, perché il marketing ha fatto un lavoro incredibile nel confondere le acque. I sistemi che chiamiamo “intelligenza artificiale” non pensano. Non capiscono. Non hanno intenzioni, desideri, obiettivi propri. Sono macchine statistiche di una potenza senza precedenti, capaci di trovare pattern in quantità di dati che nessun essere umano potrebbe processare, e di generare risultati che *appaiono* intelligenti. Questa distinzione non è accademica. È pratica. È una di quelle cose che cambiano il modo in cui prendi decisioni. Se pensate che l’ai capisca, finirete per trattarla come un esperto. Vi fiderete del suo giudizio. Le delegherete scelte. E quando sbaglierà, perché sbaglia e lo fa anche in modi sottili, non avrete gli strumenti per accorgervene. Se invece la vedete per quello che è, uno strumento potentissimo, allora torna tutto in una prospettiva più sana. Uno strumento va guidato, verificato, messo in sicurezza. Un bisturi è straordinario nelle mani di un chirurgo, ed è un pericolo nelle mani di chiunque altro. La differenza non è nel bisturi. Per chi scrive software questa consapevolezza cambia il lavoro. Forse non scriviamo più ogni singola riga, o almeno non nello stesso modo. Ma dobbiamo comprendere ogni singola riga, perché siamo noi a rispondere di ciò che il sistema fa. La macchina genera. L’umano garantisce. E questa garanzia ha un peso che nessun modello statistico può assumersi. ## L’europa fa qualcosa di coraggioso (e quasi nessuno se ne accorge) {: #leuropa-fa-qualcosa-di-coraggioso-e-quasi-nessuno-se-ne-acco } Mentre le big tech americane e cinesi corrono, l’europa fa una cosa diversa. Scrive regole. Lo so, la reazione istintiva è lo sbadiglio. Regole, burocrazia, lentezza, l’ennesimo freno all’innovazione. Però fermatevi un attimo. Forse, e dico forse, è una delle poche mosse davvero politiche che stiamo vedendo. L’europa sta dicendo che la tecnologia non è al di sopra della legge. Che se produci un software che prende decisioni sulle persone, devi poter spiegare come funziona. Che se il tuo prodotto digitale ha una vulnerabilità, ne sei responsabile, come un produttore di automobili è responsabile di un difetto ai freni. Ai Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Nomi aridi, sì. Ma dietro c’è un’intuizione molto concreta: nel ventunesimo secolo, regolare la tecnologia significa regolare la società. Per chi fa impresa questo vuol dire costi e complessità, sarebbe ingenuo negarlo. Ma vuol dire anche un’altra cosa che mi sembra sottovalutata: un vantaggio competitivo potenziale enorme. Quando il mercato globale si sveglierà chiedendo prodotti digitali sicuri, trasparenti, accessibili, chi avrà già costruito queste qualità nel proprio modo di lavorare sarà avanti. La compliance può essere un peso, certo. Ma può anche essere un investimento, se la integri nel processo e non la tratti come un foglio da firmare alla fine. Un sbom compilato per obbligo è un file in una cartella. Un sbom compilato con consapevolezza è una mappa del tuo prodotto, uno strumento di governo, quasi una dichiarazione di maturità. ## Open source: il dono più grande e più fragile dell’era digitale {: #open-source-il-dono-piu-grande-e-piu-fragile-dellera-digital } C’è qualcosa di profondamente bello nell’open source. Qualcuno scrive un pezzo di codice, lo pubblica, e dice al mondo: prendilo, usalo, miglioralo. È generosità, ma non nel senso romantico. È la costruzione di un bene comune. E su questo bene comune poggia l’economia digitale globale. Non è un’esagerazione. Se quel software dovesse essere riscritto da zero, il valore stimato sarebbe nell’ordine di migliaia di miliardi. Ma chi lo mantiene riceve una frazione minuscola di quel valore. Il problema è sistemico. Le grandi piattaforme costruiscono servizi miliardari su librerie mantenute da volontari esausti. I governi usano open source in infrastrutture critiche senza contribuire davvero alla manutenzione. Le aziende integrano componenti aperti nei loro prodotti proprietari senza sapere cosa hanno dentro, fino a quando una vulnerabilità li costringe a scoprirlo nel peggiore dei modi. Cory Doctorow parla di *enshittification* , quel ciclo in cui le piattaforme estraggono valore fino a degradare l’ecosistema. L’open source però non è una piattaforma. È più simile a un giardino. E un giardino, se tutti raccolgono e nessuno annaffia, muore. La buona notizia è che qualcosa si muove. L’europa, con il CRA, inizia a distinguere tra chi mantiene codice per passione e chi lo commercializza. Alcune aziende stanno creando fondi dedicati. Ma la risposta più efficace resta la più semplice, e anche la più scomoda. Se usi open source nel tuo prodotto, contribuisci. Con codice, con fondi, con riconoscimento. Non perché devi. Perché è intelligente, e perché è giusto. ## Accessibilità: il test definitivo delle nostre intenzioni {: #accessibilita-il-test-definitivo-delle-nostre-intenzioni } C’è un modo quasi infallibile per capire se un’azienda prende sul serio i propri valori. Non guardate la pagina “chi siamo”. Guardate se il suo sito funziona con uno screen reader. L’accessibilità è quel punto in cui la retorica incontra la realtà. Puoi parlare di inclusione e diversità quanto vuoi, ma se il tuo prodotto digitale non è utilizzabile da chi ha una disabilità visiva, motoria o cognitiva, quelle parole diventano vuote. E poi, diciamolo, non stiamo parlando di una nicchia. In europa decine di milioni di persone vivono con qualche forma di disabilità. A queste si aggiungono gli anziani, le persone con disabilità temporanee, chiunque si trovi in un contesto sfavorevole: il sole che batte sullo schermo, una connessione lenta, un dispositivo vecchio. L’accessibilità non è un favore. È una misura della qualità del nostro lavoro. Un software accessibile è quasi sempre un software migliore: più pulito nel codice, più chiaro nell’interfaccia, più robusto. L’European Accessibility Act renderà molte cose obbligatorie dal 2025. Ma chi aspetta la legge per fare la cosa giusta, secondo me, ha già perso il punto. ## Ai developer: non siete in pericolo, siete in trasformazione {: #ai-developer-non-siete-in-pericolo-siete-in-trasformazione } Qui parlo a chi fa il mio stesso mestiere. A chi vive tra commit e deploy, tra bug e refactor. Lo so che c’è paura. Lo vedo nelle conversazioni, nei messaggi, a volte nelle battute. La domanda è sempre quella, anche quando non viene detta: “tra cinque anni ci sarà ancora bisogno di me?” Respiro. Siamo passati dai fogli di calcolo ai database relazionali. Dai siti statici ai framework. Dal deploy manuale a ci/cd. E ora dal codice scritto a mano al codice assistito da ai. Ogni volta il terreno ha tremato. Ogni volta, chi ha saputo adattarsi ha scoperto che il nuovo terreno era più fertile del vecchio. Il valore non è mai stato nella digitazione. Era nella comprensione. Nella capacità di guardare un problema e vedere la struttura sotto la superficie. Di parlare con un utente e tradurre frustrazioni in un sistema che funziona. Di scegliere quando costruire e quando riusare. Di sapere che un test non è burocrazia, è amore per il futuro. Queste competenze non sono automatizzabili. Sono *amplificabili*. La macchina che scrive codice è un moltiplicatore delle vostre capacità, ma solo se avete capacità da moltiplicare. Un ide con ai nelle mani di chi capisce cosa sta facendo è uno strumento straordinario. Nelle mani di chi non capisce, è un generatore di debito tecnico ad alta velocità. Studiate, sì, ma non solo i nuovi strumenti, perché cambieranno. Studiate i fondamentali: architettura, design di sistemi, principi di sicurezza, accessibilità. Studiate le persone: come comunicano, cosa temono, cosa sperano. E studiate anche il contesto normativo, non perché sia divertente, ma perché definisce il campo da gioco. E soprattutto non smettete di essere curiosi. La curiosità è una cosa strana, non sempre “produttiva” nel senso aziendale del termine. Però è uno dei pochi vantaggi competitivi che una macchina non può replicare davvero. ## Una questione di fiducia {: #una-questione-di-fiducia } Alla fine, tutta questa conversazione, sull’ai, sull’open source, sulla regolazione, sull’accessibilità, ruota intorno a una parola sola: fiducia. Ci fidiamo dei sistemi che non vediamo? Dovremmo? E a quali condizioni? La fiducia non si costruisce con le dichiarazioni di intenti. Si costruisce con scelte concrete, ripetute nel tempo, verificabili. Si costruisce documentando le dipendenze, testando il codice, rendendo accessibile il prodotto, spiegando le decisioni dell’algoritmo, rispondendo degli errori. Per i decisori, la tecnologia non è un reparto. È il linguaggio in cui è scritta l’organizzazione. Non dovete diventare programmatori, per carità. Però dovete capire abbastanza da fare domande scomode ai fornitori, distinguere un rischio reale da una rassicurazione vuota, capire cosa c’è dentro il software che governa i processi. Per noi developer, il lavoro non è mai stato solo tecnico. Ogni scelta architetturale è una scelta di valori. Ogni dato che decidiamo di non raccogliere è un diritto che scegliamo di rispettare. Ogni interfaccia che rendiamo accessibile è una porta che apriamo. Il codice è potere, e il potere comporta responsabilità. ## E quindi: il legno e il codice {: #e-quindi-il-legno-e-il-codice } Mio nonno non avrebbe capito il mio lavoro. Probabilmente avrebbe scosso la testa davanti a certe parole, e poi avrebbe cambiato argomento. Però credo che avrebbe capito il principio. Lui sapeva che un mobile fatto bene si riconosce dai giunti che non si vedono. Dalla stabilità che dura nel tempo. Dalla cura messa nei dettagli che il cliente non noterà mai, ma che fanno la differenza tra un oggetto che dura vent’anni e uno che scricchiola dopo sei mesi. Il buon software è uguale. Si riconosce da ciò che non si vede: dalla sicurezza che non viene violata, dall’accessibilità che non esclude nessuno, dalla privacy che non viene tradita, dalla documentazione che permette a chi viene dopo di capire cosa hai fatto e perché. Non è un mestiere che l’ai ci porterà via. È un mestiere che l’ai, in un certo senso, ci sta restituendo nella sua forma più pura: non come atto meccanico di traduzione, ma come atto umano di cura. E la cura, come sapeva mio nonno guardando il legno, la senti. *Questo articolo è per chi scrive codice e per chi ne dipende senza saperlo. Per chi decide senza capire e per chi capisce senza poter decidere. Forse per tutti noi, perché alla fine la risposta è sempre la stessa: dipende da noi.* --- # La compliance è roba vostra - **URL:** https://margiovanni.it/it/blog/la-compliance-e-roba-vostra/ - **Pubblicato:** 2026-03-08 - **Tag:** Compliance, Normative Europee, Sicurezza Informatica, Sviluppo Software - **Tempo di lettura:** 7 min > Tra 2026 e 2027 il software diventa un prodotto con responsabilità legale. Se il cliente vuole solo il go-live, il rischio resta a tutti. C'è una frase che mi capita di sentire sempre più spesso, detta quasi di passaggio mentre si chiude una call e si torna alle cose “vere”: *a noi interessa il go-live. La compliance è roba vostra*. Non sempre è arroganza. Anzi, di solito è l'opposto. È una frase detta con la naturalezza di chi pensa che la compliance sia un dettaglio tecnico, come scegliere un framework o decidere se mettere il bottone a destra o a sinistra. Solo che quel “dettaglio” sta cambiando forma. E sta diventando, molto più velocemente di quanto il mercato sembri pronto ad ammettere, una questione di responsabilità. ## Quello che il cliente compra e quello che il fornitore vende {: #quello-che-il-cliente-compra-e-quello-che-il-fornitore-vende } Per anni, nel software su commessa, ci siamo capiti con un patto implicito abbastanza semplice. Il cliente descrive cosa vuole, il fornitore lo costruisce, si concordano tempi e costi, e alla consegna si fa collaudo, si va in produzione, si chiude. In questo modello la responsabilità “pesante” finiva quasi sempre dentro il perimetro del progetto. Se qualcosa andava storto, si parlava di bug, di disservizi, magari di una penale. Fastidioso, certo, ma gestibile. Il punto è che in europa, tra il 2025 e il 2027, sta arrivando un cambio di prospettiva che rende quel patto meno stabile. Non è un singolo regolamento che puoi ignorare finché non arriva la mail del legale. È un insieme di regole che, viste nel loro complesso, spingono in una direzione precisa: il software viene trattato sempre più come un *prodotto*. E quando qualcosa è un prodotto, chi lo “produce” non risponde più solo in termini contrattuali. Risponde anche per i difetti, un po' come succede con un elettrodomestico che fa danni perché è stato progettato o assemblato male. ## Il disallineamento commerciale che crea attrito {: #il-disallineamento-commerciale-che-crea-attrito } Qui nasce la frizione vera, quella che poi esplode nelle trattative e nei preventivi. Il committente ragiona in modo lineare e, dal suo punto di vista, anche corretto. Vuole una piattaforma funzionante, un portale, un'app. La vuole entro una data, con un certo budget, con le feature che servono al business. Il fornitore, però, si trova addosso un carico crescente di requisiti che non compaiono quasi mai nel brief. Non li trovi nelle user story, non li vedi nei mockup, non te li chiede il product owner. Eppure sono cose che, se mancano, trasformano un progetto “consegnato” in un progetto “rischioso”. Parlo di documentazione tecnica fatta in un certo modo, tracciabilità delle componenti, gestione delle vulnerabilità, trasparenza su certe scelte algoritmiche, accessibilità. Tutte attività che hanno una caratteristica comune: costano tempo, competenze, processo. E qui arriva il dilemma che, secondo me, sta diventando sempre più tossico. Se le metti nel preventivo, rischi di essere più caro del concorrente che non le mette. Se non le metti, le assorbi nel margine, lavori in perdita e, in più, ti prendi un rischio che non hai esplicitato. Nessuna delle due strade è sostenibile a lungo. ## Perché “è sempre stato così” non regge più {: #perche-e-sempre-stato-cosi-non-regge-piu } Nel b2b italiano abbiamo vissuto per anni dentro una cultura del “facciamo, poi vediamo”. Contratti leggeri, specifiche vaghe, molta fiducia personale. A volte ha funzionato anche bene, non lo nego. Forse perché il contesto lo permetteva. Ora però stanno cambiando tre cose insieme, e la combinazione è quella che fa paura. La prima è la responsabilità più “oggettiva”. In alcuni scenari non basta più dire “non siamo stati negligenti”. Conta il difetto e conta il danno. E in certi casi il peso di dimostrare che non c'era difetto si sposta su chi ha prodotto o immesso sul mercato. La seconda è l'allargamento del perimetro. Il software non è solo quello che scrivi tu. È anche ciò che integri: librerie open source, servizi cloud, api di terze parti, modelli ai. E quando queste cose entrano nel prodotto finale, qualcuno deve rispondere di come sono state scelte, integrate, monitorate. La terza è il tempo. Non parliamo di un futuro lontano. Parliamo di scadenze tra il 2026 e il 2027. Il codice che stai scrivendo adesso, con buona probabilità, sarà ancora lì quando queste regole saranno pienamente operative. E allora mi chiedo se non sia ingenuo continuare a trattare la compliance come una postilla. ## La conversazione che nessuno vuole avere {: #la-conversazione-che-nessuno-vuole-avere } La parte più difficile non è capire la norma. È parlarne senza far saltare il tavolo commerciale. Prova a dire a un cliente che il preventivo aumenta del 20% perché devi produrre documentazione tecnica conforme, implementare un processo di gestione delle vulnerabilità e mantenere un inventario aggiornato delle componenti. Nel migliore dei casi ti risponde con un silenzio lungo. Nel peggiore ti dice che qualcun altro glielo fa senza. Ed è qui che il mercato si spacca. Perché quel “senza” raramente significa “più efficiente”. Spesso significa “debito di compliance”, cioè lavoro e rischio spostati nel futuro. Un futuro in cui, con le nuove regole, il conto potrebbe arrivare al fornitore, al committente, o a entrambi. Eppure questa conversazione non la sta facendo quasi nessuno, almeno non in modo esplicito. È scomoda. Costringe il cliente ad accettare che la compliance ha un costo reale. E costringe il fornitore a spiegare quel costo senza nascondersi dietro parole che sembrano burocrazia. ## Il costo dell'invisibilità {: #il-costo-dellinvisibilita } C'è un paradosso che rende tutto più complicato. Le attività di compliance, quando sono fatte bene, sono invisibili. Un sistema serio di gestione vulnerabilità si nota quando non succede niente. La documentazione tecnica diventa preziosa quando qualcosa va storto. Un inventario delle componenti (tipo un elenco aggiornato delle dipendenze) vale davvero il giorno in cui esce una vulnerabilità critica e tu devi capire subito se sei esposto. Il cliente vede la feature, vede il go-live, vede l'interfaccia. Tutto quello che tiene in piedi quel risultato nel tempo resta sotto il pavimento. E allora forse il problema non è che il cliente “non vuole pagare”. È che non percepisce cosa sta comprando. Se vai da un imprenditore e gli dici “dobbiamo implementare un software bill of materials conforme”, probabilmente perdi attenzione dopo poche parole. Se invece gli dici “dobbiamo essere in grado, entro 24 ore, di sapere se una vulnerabilità appena uscita mette a rischio il tuo prodotto e quindi la tua responsabilità”, stai parlando la lingua del rischio. Che è una lingua molto più universale. ## Cosa cambia, in pratica, senza trasformare tutto in un incubo {: #cosa-cambia-in-pratica-senza-trasformare-tutto-in-un-incubo } Per i fornitori, la strada è stretta ma abbastanza chiara. Bisogna smettere di trattare la compliance come un costo nascosto e iniziare a trattarla come un servizio esplicito, con un valore che si può raccontare. Vuol dire, per esempio, separare lo sviluppo funzionale dalla manutenzione di sicurezza e conformità. Non dentro un “canone annuale” indistinto, ma con una voce che dica cosa copre davvero. Anche perché, se un domani qualcosa finisce in discussione, l'ambiguità non aiuta nessuno. Vuol dire mettere nero su bianco, nei contratti, chi fa cosa. Chi aggiorna le dipendenze? Chi monitora le vulnerabilità? Chi produce e conserva la documentazione tecnica? Chi decide se una libreria si può usare o no? Chi risponde se un componente si rivela compromesso? Oggi, in molti contratti italiani, queste domande semplicemente non esistono. E quando una domanda non esiste, la risposta arriva sempre nel momento peggiore. Vuol dire anche imparare a vendere queste attività per quello che sono: riduzione del rischio. Perché il cliente non compra “compliance”. Compra la possibilità di non trovarsi con un prodotto fuorilegge, con un incidente di sicurezza gestito male, o con una contestazione in cui non ha prove e documenti per difendersi. Per i committenti il cambio di mentalità è speculare. *La compliance è roba vostra* non è più una posizione comoda, e forse non è mai stata davvero una posizione sicura. Se immetti sul mercato un prodotto digitale, anche se lo hai fatto sviluppare da terzi, la responsabilità non evapora. Al massimo puoi rivalerti contrattualmente sul fornitore. Ma nel frattempo il danno, la reputazione, la gestione dell'incidente e le conseguenze commerciali le affronti tu. ## Una questione di maturità del mercato {: #una-questione-di-maturita-del-mercato } A pensarci bene, quello che sta succedendo assomiglia a una crescita forzata. Il mercato del software, soprattutto quello su commessa, sta passando da un modello artigianale, basato su fiducia e accordi impliciti, a un modello più industriale, dove le responsabilità sono definite, i processi sono documentati e la qualità non è solo “funziona sul mio telefono”. Non è per forza una cattiva notizia. Per i fornitori seri può diventare un modo per distinguersi da chi compete solo tagliando angoli. Per i committenti più consapevoli può essere una garanzia: sapere che il software non è costruito solo per andare online, ma per restare in piedi, reggere gli incidenti, e non trasformarsi in un problema legale al primo scossone. Forse la frase giusta, oggi, non è “la compliance è roba vostra”. È qualcosa di più onesto e più utile: *la compliance è parte del prodotto*. E allora sì, è un costo strutturale del fare software. Prima lo riconosci, prima lo puoi gestire. E magari, con un po' di coraggio, trasformarlo anche in un vantaggio competitivo. --- # Dopo la morte della UI: finisce anche l'idea di app - **URL:** https://margiovanni.it/it/blog/dopo-la-morte-della-ui-finisce-anche-lidea-di-app/ - **Pubblicato:** 2026-03-05 - **Tag:** Design, Intelligenza Artificiale, Prodotto Digitale, SaaS - **Tempo di lettura:** 8 min > Leggendo Mircha ho iniziato a chiedermi cosa succede se davvero la UI muore. Forse non sparisce solo la schermata, ma l’applicazione stessa. Qualche giorno fa ho letto un post di Mircha Emanuel D’Angelo sulla [morte dell’interfaccia utente](). Di quelli che ti rimangono addosso. L’ho letto, l’ho riletto, e poi ho iniziato a farci caso anche nella vita reale: quante energie mentali spendiamo solo per ricordarci *dove* si fa una cosa, in quale tab, in quale menu, in quale prodotto. E mentre cercavo di addormentarmi, la domanda è diventata più fastidiosa e più interessante: se davvero la UI smette di essere il centro del software, cosa succede al resto? Perché forse non muore solo la schermata. Forse muore l’applicazione come l’abbiamo conosciuta. ## Se muore la UI, non cade da sola {: #se-muore-la-ui-non-cade-da-sola } Quando diciamo “app”, di solito intendiamo un oggetto abbastanza chiaro. Ha un nome, un’icona, un posto nel dock, un abbonamento mensile, una personalità. E soprattutto ha un confine. Dentro c’è il mondo di Notion. Dentro c’è Jira. Dentro c’è Salesforce. Fuori c’è tutto il resto. Mi sono accorto che quel confine, spesso, non è lì perché il problema lo richiede. È lì perché il modello economico lo richiede. Un sacco di software moderno è costruito come un recinto. Non per cattiveria, magari. È solo che per anni il modo più semplice di monetizzare è stato questo: prendi un insieme di funzionalità, le impacchetti, ci costruisci intorno un’interfaccia che diventa familiare, ci metti dentro i dati dell’utente e poi fai in modo che uscire sia doloroso. Mircha fa un parallelo che mi sembra illuminante: i server MCP come “nuovi programmi Unix”. E se è vero, allora la conseguenza naturale è un’altra, un po’ più scomoda. Le applicazioni SAAS, viste da lì, somigliano ai mainframe. Grandi monoliti nati in un’epoca in cui distribuire software era costoso e l’unico modo per farlo pagare era costruire muri. In un mondo in cui un agente può comporre capability piccole e precise al volo, quel muro diventa più un ingombro che una protezione. ## L’interfaccia generativa: non progettata, evocata {: #linterfaccia-generativa-non-progettata-evocata } C’è un passaggio del post di Mircha che mi ha fatto fermare a riflettere. L’idea che la GUI passi da control panel a display. E mi è venuto da chiedermi: e se non fosse né l’una né l’altra? Forse l’interfaccia, nel prossimo giro, diventa *effimera*. Oggi un designer, quando progetta una schermata, sta facendo un compromesso. Cerca un layout che funzioni “abbastanza bene” per tante persone, in tanti contesti. Il risultato è spesso un’interfaccia solida, coerente, testata, ma inevitabilmente generica. Deve servire tutti, quindi non serve perfettamente nessuno. Con un agente in mezzo, quel compromesso potrebbe saltare. Non intendo “fare tutto via chat”, che è una caricatura comoda. Intendo un sistema che, data la tua intenzione, genera l’interfaccia giusta per quel momento. Un form non generico, ma con *quei* campi, in *quell’ordine* , con i default sensati per il tuo caso. Una dashboard non standard, ma la visualizzazione che risponde a una domanda precisa, con i dati necessari e niente rumore. Queste UI non vengono mantenute. Non vengono versionate. Non hanno bisogno di una roadmap. Vengono evocate e poi spariscono. E la cosa inquietante è che non è nemmeno più fantascienza. Oggi già vediamo modelli che generano componenti, pagine, piccoli artefatti in React in tempo reale. È ancora grezzo, sì. Ma la direzione è difficile da ignorare. A quel punto il ruolo del designer non sparisce, però cambia pelle. Da progettista di schermate diventa progettista di sistemi generativi. Design system, vincoli, pattern, regole. Un lavoro più simile a costruire una grammatica che a disegnare frasi. ## L’agente come sistema operativo {: #lagente-come-sistema-operativo } Un’altra conseguenza che mi torna in testa è questa: forse la metafora giusta per l’agente non è “assistente”. È “sistema operativo”. Un OS fa cose che diamo per scontate: astrae l’hardware, gestisce risorse, offre un’interfaccia unificata, permette a programmi diversi di convivere e parlarsi. L’agente fa qualcosa di simile, un livello sopra. Astrae i servizi, gestisce contesti, offre un’interfaccia unificata (il linguaggio naturale), orchestra capability diverse. Se questa metafora regge, allora succede una cosa quasi inevitabile: l’agente diventa la piattaforma. Non perché tutto “vive dentro” l’agente, ma perché tutto passa *attraverso* l’agente. Come oggi nessun software gira senza un OS, domani nessun servizio verrà usato senza un agente. E qui entra la parte politica, o economica, che forse è la più delicata. Chi controlla l’agente controlla il punto di accesso al software. È una posizione che abbiamo già visto nella storia, solo con nomi diversi. E mi chiedo se riusciremo a evitare la solita traiettoria. Quella che Cory Doctorow chiama enshittification. Prima tutto è utile e aperto, poi diventa una rendita, poi diventa un pedaggio. ## Dall’app alla capability {: #dallapp-alla-capability } Se l’applicazione perde senso, cosa resta? Resta la capability. Una capability è una funzione atomica esposta via protocollo, descritta in modo umano, invocabile da un agente. “Crea una fattura”. “Cerca questo contatto”. “Riassumi questi ticket e dimmi i rischi”. Non è un prodotto con un brand e un layout. È un mattoncino. E appena pensi in termini di mattoncini, cambia anche l’economia. Oggi paghi un abbonamento per un bundle: cento funzioni, ne usi venti, ma il prezzo è per tutte. Domani potresti pagare a consumo, capability per capability, nel momento in cui serve. Frazioni di centesimo per una singola azione ben fatta. Questo manda in crisi tre vantaggi storici del SAAS: Primo, l’interfaccia come lock-in. Se l’interfaccia è dell’agente, non è più tua. Secondo, i dati come prigione. Se i dati stanno in vault personali e l’accesso è a permessi granulari, il recinto perde potere. Terzo, il bundle. Se l’agente può comporre il meglio per ogni pezzo, il pacchetto monolitico diventa meno attraente. A quel punto resta una cosa sola: la qualità della capability. Fai una cosa sola, falla meglio di tutti. È Unix come filosofia tecnica, ma anche come modello di business. Elegante, e un po’ spietato. ## Il nuovo alfabetismo {: #il-nuovo-alfabetismo } C’è un’altra idea del post di Mircha che mi sembra sottovalutata: “non saper parlare con l’ai” come nuova forma di analfabetismo. Per decenni abbiamo chiamato “alfabetizzazione digitale” una cosa molto specifica: saper usare interfacce. Cliccare, trascinare, navigare menu, compilare form. Abbiamo costruito corsi, certificazioni, ruoli professionali. Se l’agente diventa l’interfaccia principale, tutto questo si sgonfia. La competenza centrale diventa un’altra, e forse è più umana che tecnica. Saper esprimere un’intenzione con chiarezza. Saper dare contesto. Saper scomporre un problema. Saper giudicare un risultato e iterare. E qui c’è un paradosso che mi affascina. Ci sono persone che non hanno mai imparato davvero Excel, ma sanno spiegare cosa vogliono con una precisione chirurgica. E ci sono power user che, messi davanti a un agente, non sanno cosa chiedere. La mappa delle competenze si ridisegna. E sì, il rischio di un nuovo digital divide è reale. Però c’è anche un’opportunità rara: per la prima volta, il vantaggio non è “saper parlare il linguaggio macchina”. È saper pensare e comunicare bene. ## La sorpresa europea: compliance come capability {: #la-sorpresa-europea-compliance-come-capability } C’è un pezzo di questa storia che, secondo me, in Europa non possiamo ignorare. Mentre la narrativa americana tende a vedere la regolazione come freno, qui stiamo costruendo un quadro normativo che tocca proprio i nervi scoperti di un mondo a capability componibili: AI Act, Cyber Resilience Act, Product Liability Directive, EAA. In un sistema dove un agente combina tre capability di tre fornitori diversi, la domanda “chi è responsabile se qualcosa va storto?” diventa esplosiva. **Se la legge ti chiede tracciabilità, sicurezza, audit trail, spiegabilità, allora la compliance smette di essere solo un costo. Diventa una capability differenziante.** Lo SBOM come passaporto del componente. Il log delle azioni dell’agente come requisito. La trasparenza come vantaggio competitivo. E qui c’è un ribaltamento quasi ironico: molte richieste storiche della cultura hacker, apertura, accountability, verificabilità, stanno diventando legge. Forse l’Europa, più che rallentare, sta costruendo l’infrastruttura di fiducia senza cui il mondo degli agenti non regge nelle aziende serie. ## 2030, un giorno qualunque (forse) {: #2030-un-giorno-qualunque-forse } Provo a immaginare una giornata normale, senza voler fare fantascienza. Non hai più “app” sul telefono. Hai un agente. Gli parli, scrivi, magari fai un gesto. Lui orchestra servizi diversi e tu non vedi quasi mai il dietro le quinte. Un po’ come oggi non pensi ai microservizi quando si apre una pagina. L’interfaccia che vedi è stata generata per te, in quel momento. Tra cinque minuti non esiste più. Il commercio diventa conversazione. “Mi servono scarpe da trail, budget 150 euro, terreno misto, preferisco suola Vibram.” L’agente conosce taglia, storico, preferenze, fonti affidabili. Ti propone tre opzioni con una comparazione fatta su misura. Scegli, fine. In ufficio succede qualcosa di simile. Il PM non apre Jira, chiede “come stiamo messi su Alpha?” e ottiene stato, rischi, prossimi passi. Il commerciale non naviga il CRM, chiede “quali deal sono a rischio questa settimana?” e riceve un briefing. Lo sviluppatore descrive un comportamento e il sistema genera, testa, deploya. I dati stanno in un vault personale, cifrato e portabile. Le capability chiedono permessi granulari, revocabili, e tutto è loggato. Ogni azione produce un audit trail. In quel mondo, il valore sta in due cose: capability buone e fiducia. ## Un realismo necessario {: #un-realismo-necessario } È inevitabile? Non lo so. Le transizioni non sono mai lineari. Ci saranno resistenze economiche enormi. L’enterprise si muove con una lentezza quasi geologica. Le abitudini cambiano più lentamente dei comunicati stampa. E ci sono problemi tecnici veri: affidabilità su task complessi, gestione degli errori nelle catene di composizione, sicurezza, costi. Però la direzione che Mircha mette a fuoco mi sembra difficile da ignorare, perché è sostenuta da due forze concrete. Da una parte il costo cognitivo delle interfacce tradizionali, che cresce con ogni nuovo SAAS. Dall’altra la capacità degli agenti di ridurre quel costo, che cresce con ogni iterazione dei modelli. Quando la distanza tra i due supera una soglia, la transizione diventa pratica, non ideologica. E per alcuni casi d’uso, forse, quella soglia è già stata superata. Mircha chiude chiedendo chi costruirà questo futuro e con quali valori. Io mi porto dietro un’altra domanda, un po’ più personale e un po’ più cinica: chi avrà il coraggio di costruire *per* questo futuro, sapendo che significa smontare il modello che oggi paga gli stipendi? Perché il dilemma, alla fine, non è tecnico. È la volontà di cannibalizzare il presente. E il tempo per decidere da che parte stare, probabilmente, non è infinito. *Questo post nasce dalla lettura di["La morte dell’interfaccia utente come la conosciamo"]() di Mircha Emanuel D’Angelo. Se non l’avete letto, secondo me vale la pena partire da lì.* --- # Il mio rapporto complicato con IKEA - **URL:** https://margiovanni.it/it/blog/il-mio-rapporto-complicato-con-ikea/ - **Pubblicato:** 2026-03-02 - **Tag:** Casa, Ikea, Ironia, Vita Quotidiana - **Tempo di lettura:** 17 min > Tra fogli A3 senza parole, brugole infinite e viti avanzate, IKEA diventa una piccola metafora della vita adulta. Ci vediamo al passo 7. ## Tre tipi di persone, e poi ci sono io {: #tre-tipi-di-persone-e-poi-ci-sono-io } Ci sono tre tipi di persone al mondo: quelli che leggono le istruzioni IKEA dall’inizio alla fine prima di toccare qualsiasi cosa, quelli che le buttano direttamente nel sacchetto con le viti avanzate, e quelli che le leggono a metà e poi decidono di andare a istinto. Inutile dire che la terza categoria include me, mia madre, il mio vicino di pianerottolo, e probabilmente il 90% della penisola italiana. E forse c’è anche una quarta categoria, a dire il vero. Quelli che non comprano IKEA *per principio* e poi ti chiamano alle dieci di sera perché hanno comprato un KALLAX e “non si capisce niente”. Ma di loro parliamo dopo, perché prima bisogna rendere omaggio alla vera divinità di tutta questa storia. ## Il foglio A3, ovvero Björn {: #il-foglio-a3-ovvero-bjorn } Partiamo dall’oggetto in sé, perché merita rispetto. Le istruzioni IKEA sono un capolavoro di design minimalista. Nessuna parola. Solo disegni. Un omino stilizzato, chiamiamolo Björn, perché sembra proprio un Björn, che con aria serena e braccia proporzionate in modo strano ti mostra come fare cose che nella realtà richiedono tre mani, una morsa idraulica e un secondo in cui i figli sono fuori casa. Björn non suda mai. Björn non dice mai “aspetta, questo pannello è al contrario”. Björn non ha mai passato quaranta minuti a capire che il pezzo C non era il pezzo C ma il pezzo C speculare, che è una cosa diversa e che IKEA lo sa benissimo, ma ha deciso di non dirtelo esplicitamente perché la vita è breve e il carattere va temprato. Björn è sereno perché Björn non esiste. Ma se esistesse, Björn sarebbe quel tipo di persona che al ristorante ordina subito, non chiede modifiche al piatto, non controlla il conto. Björn parcheggia al primo colpo. Björn non ha mai dovuto fare una inversione a U su una strada statale perché ha mancato l’uscita. Björn non ha un cassetto delle cose che “poi sistemo”. Björn è un sociopatico funzionale, e io lo invidio profondamente. ## Il viaggio verso IKEA, cioè il pellegrinaggio {: #il-viaggio-verso-ikea-cioe-il-pellegrinaggio } Prima di arrivare al montaggio, però, bisogna parlare dell’esperienza IKEA nel suo complesso, perché è un percorso spirituale in sé. Tutto inizia con una promessa: “Andiamo solo a prendere quelle mensole.” Questa frase è l’equivalente logistico di “restiamo solo cinque minuti” a una festa. Non è mai successo, non succederà mai, eppure la ripetiamo ogni volta con la stessa convinzione di chi giura che stavolta smetterà di premere “continua a guardare” su Netflix. Il parcheggio IKEA è un ecosistema a sé. C’è chi gira per venti minuti cercando il posto vicino all’ingresso, e chi parcheggia a trecento metri e cammina con la determinazione di chi ha già fatto i conti con la propria mortalità. Io appartengo a una terza specie: quello che trova un posto buono, ci entra, poi si rende conto che la macchina accanto ha aperto la portiera talmente tanto da aver creato una no-fly zone, esce, riparte, e finisce nel parcheggio del Decathlon a fianco. Poi entri. E qui il genio svedese si manifesta in tutta la sua potenza. Il percorso obbligato. Quel labirinto a senso unico che ti porta attraverso camerette per bambini che non hai, uffici che non ti servono, e cucine in cui il bancone è pulito come se nessuno ci avesse mai cucinato. Che è probabilmente vero, perché è una cucina IKEA in un negozio, ma il punto è che la mia cucina non è *mai* così. Lungo il percorso, raccogli cose. Cose che non ti servivano, non le cercavi, e cinque minuti prima non sapevi neanche che esistessero. Un organizer per cassetti. Un set di barattoli. Un cuscino a forma di nuvola che costa tre euro e novanta e che per qualche ragione ti sembra indispensabile. IKEA ha capito una cosa fondamentale della psicologia umana: noi non sappiamo cosa vogliamo finché qualcuno non ce lo mette davanti a un prezzo che sembra troppo basso per dire di no. Arrivi alle mensole, il motivo per cui eri venuto, dopo quarantacinque minuti, due sacchetti gialli pieni, e una discussione su se servono o no le tende nuove. Servono, ma non lo ammetterai per almeno altri due viaggi. ## Il magazzino, dove la dignità vacilla {: #il-magazzino-dove-la-dignita-vacilla } Ma il vero test psicologico non è il percorso. È il magazzino. Quel capannone di scaffalature alte come cattedrali, dove devi trovare la tua mensola tra mille scatole piatte tutte marroni, tutte uguali, tutte con un codice alfanumerico che hai scritto su quel fogliettino con la matitina IKEA. Sì, quella che è troppo corta per scrivere comodamente e troppo grossa per stare in tasca, e che alla fine ritrovi sei mesi dopo nel portaoggetti della macchina. Corsia 24, scaffale 8. Arrivi. Lo scaffale 8 è in alto. La scatola pesa ventitré chili. Non c’è nessuno intorno. Le opzioni sono: chiedere aiuto (impensabile, sei italiano), arrampicarti (possibile ma sconsigliato dalla postura), o afferrare la scatola con un movimento atletico che non fai dai tempi del liceo e che il tuo fisioterapista definirebbe “una scelta”. Scegli la terza opzione. La scatola scivola. La fermi con un ginocchio. Ti guardi intorno per assicurarti che nessuno abbia visto. Nessuno ha visto. Procedi con la dignità intatta e una contusione futura al ginocchio sinistro. ## L’apertura della scatola, cioè il rito {: #lapertura-della-scatola-cioe-il-rito } C’è un rituale preciso nell’apertura della scatola IKEA e non va sottovalutato. Prima cosa: lo spazio. Hai bisogno di spazio. Il manuale dice “montare in un’area ampia e sgombra”, che nella realtà di un appartamento italiano significa spostare il tavolo, il tappeto, e quella pila di cose che “poi metto a posto” e che staziona accanto al divano dalla scorsa primavera. Apri la scatola. Il cartone si strappa in modo imprevedibile, mai lungo la linea che volevi tu. All’interno, un mare di polistirolo, sacchettini di minuteria, pannelli avvolti in una pellicola protettiva che si appiccica a tutto tranne che a se stessa, e quel foglio. Il foglio A3. Lo apri con una certa riverenza. Primo gesto: guardi il disegno finale. Il mobile completo, con sopra un vaso con un fiore e a fianco una pila di libri disposti con una casualità troppo studiata per essere vera. Pensi: “sì, lo voglio così.” Poi guardi il passo 1, un pannello piatto, due spinotti, una freccia, e il divario tra il sogno e la realtà ti colpisce con la stessa brutalità di quando leggi il tuo estratto conto dopo Natale. Secondo gesto: conti i passi. 24 passi. “Non sono tanti,” ti dici. Questo è l’equivalente emotivo di guardare una serie da sei stagioni e pensare “la finisco questo weekend”. Terzo gesto: controlli le viti. I sacchettini. Li disponi ordinatamente. Li conti. Scopri che ce ne sono di più di quelle previste. Ti chiedi se è un errore, un bonus, o un test psicologico. Non lo saprai mai. ## Il momento della fiducia cieca (di solito al passo 7) {: #il-momento-della-fiducia-cieca-di-solito-al-passo-7 } C’è un momento preciso nel montaggio di qualsiasi mobile IKEA in cui devi fare un atto di fede. Di solito è al passo 7 su 24. Hai appena avvitato qualcosa che non sembra andare da nessuna parte, la struttura è tenuta insieme da due spinotti di legno e dalla speranza, e le istruzioni ti mostrano, con quella calma infuriante, che devi capovolgere tutto. Capovolgere. Tutto. Da solo. Björn lo fa con un dito, naturalmente. Nel disegno, la struttura ruota con una freccia curva e leggera, come se la gravità fosse una suggestione. Nella realtà, stai abbracciando un parallelepipedo instabile di truciolato che pesa quanto un adolescente medio, e lo stai ruotando usando come leva il ginocchio, il gomito, e una fiducia nella colla a legno che non avevi mai provato prima. Ecco, quel momento lì, con il mobile che scricchiola e tu che lo tieni come se stessi abbracciando qualcuno che stai cercando di non far cadere, è esattamente come mi sento davanti alle scadenze di marzo. Stai tenendo tutto insieme con poca roba, non sai ancora se regge, ma il piano dice di andare avanti. E vai avanti. Perché l’alternativa, smontare tutto, ricominciare, rileggere da capo, è talmente deprimente che preferisci rischiare. ## La brugola, piccola e infinita {: #la-brugola-piccola-e-infinita } Apriamo un capitolo a parte sulla brugola, perché la brugola merita un capitolo a parte. La chiave a brugola IKEA è l’utensile perfetto per un mondo imperfetto. È piccola, semplice, apparentemente innocua. Ti viene fornita gratuitamente con ogni acquisto, il che significa che dopo tre mobili hai più brugole che posate. La brugola è anche l’unico attrezzo che IKEA ritiene necessario per il montaggio. Questo è un atto di ottimismo svedese che confina con l’incoscienza. Perché il montaggio IKEA, a un certo punto, richiede sempre qualcosa di più. Un martello, per esempio, per quegli spinotti di legno che non entrano mai al primo colpo e che devi “inserire delicatamente”. Traduzione: picchiare con qualsiasi cosa tu abbia a portata di mano, incluso il fondo di una tazza, un libro pesante, o in un caso memorabile, una scarpa. E poi c’è il momento della brugola, quel momento in cui stai avvitando e avvitando e avvitando, e la brugola è corta, e devi fare mezzo giro alla volta, e il polso inizia a protestare, e ti chiedi: esiste davvero gente che monta una cucina intera IKEA con questa cosa? Una cucina intera? Sì, esiste. È la stessa gente che sale l’Everest. Stessa categoria psicologica. ## Gli aiutanti, cioè il caos organizzato {: #gli-aiutanti-cioe-il-caos-organizzato } Nessun racconto sulle istruzioni IKEA sarebbe completo senza parlare degli aiutanti. L’aiutante volontario è quella persona, partner, amico, genitore, coinquilino, che a un certo punto del montaggio dice: “Ti aiuto io.” Con buone intenzioni. Con la sicurezza di chi non ha letto le istruzioni. L’aiutante volontario tiene il pannello dalla parte sbagliata. L’aiutante volontario ti passa la vite lunga quando serviva quella corta. L’aiutante volontario, a un certo punto, prende in mano le istruzioni, le guarda per trenta secondi, e dice: “Ma non dovevi prima mettere questo?” “Questo” è il pezzo che hai già avvitato. Due passi fa. Con sei viti. E la risposta è sì, avresti dovuto prima mettere quello, ma ormai è andata, e se lo smonti adesso crolla tutto, e quel “tutto” include il mobile, la tua pazienza, e probabilmente la relazione. Poi c’è l’aiutante tecnologico, quello che a metà montaggio tira fuori il telefono e cerca un tutorial su YouTube. “Aspetta, c’è un tizio che lo monta in sei minuti.” Sì, c’è sempre un tizio che lo monta in sei minuti. Quel tizio ha un laboratorio, un avvitatore a batteria, e probabilmente non ha mai avuto un dubbio su nulla nella sua vita. Quel tizio è il Björn di YouTube. Non mi è utile. L’aiutante più pericoloso, però, è il bambino. Il bambino vuole aiutare. Il bambino prende i sacchetti delle viti. Il bambino li apre. Il bambino ti porta una vite. Non la vite giusta. Una vite qualsiasi. Con la gioia innocente di chi non sa che quella vite lì era l’unica vite M6x30 del sacchetto e adesso è sotto il divano, in quel punto esatto dove la tua mano non arriva e dove vivono, da quanto ne so, tutte le viti IKEA perse dal 1987 a oggi. ## Le viti avanzate e il cassetto della coscienza {: #le-viti-avanzate-e-il-cassetto-della-coscienza } Parliamo delle viti avanzate. Ogni montaggio IKEA si conclude con un piccolo gruppo di viti, rondelle e spinotti rimasti sul pavimento. Pezzi che non sai dove vanno. Pezzi che forse vanno da qualche parte, forse non servono, forse sono di un altro mobile, forse IKEA li mette apposta per vedere cosa fai. La reazione italiana standard è raccoglierli, metterli in un cassetto, e dimenticarli per i successivi quattro anni. Quel cassetto è la nostra coscienza. Ho un cassetto così. Lo abbiamo tutti. È il cassetto dove vanno le viti IKEA avanzate, i caricatori di telefoni che non abbiamo più, le pile che forse sono scariche e forse no, i manuali di elettrodomestici che non leggeremo mai, e almeno tre chiavi di cui non conosciamo la serratura. Quel cassetto è l’autobiografia materiale della nostra vita adulta. C’è chi, e lo dico con ammirazione sincera, si siede, riapre le istruzioni dall’inizio, e trova dove vanno quei pezzi. Li cerca. Li trova. Li avvita. Quelle persone fanno anche i backup regolari del computer, leggono il manuale del forno, e hanno un cassetto dei cavi ordinato per tipo e lunghezza. Io le ammiro. Non le capisco, ma le ammiro. Ho provato una volta, per un MALM, a essere quella persona. Ho riaperto le istruzioni. Ho controllato passo per passo. Ho trovato che le due viti avanzate andavano al passo 14, dove diceva chiaramente, chiaramente per Björn, oscuramente per chiunque altro, di fissare un gancio anti-ribaltamento alla parete. Un gancio anti-ribaltamento. Alla parete. Che richiedeva un tassello, un trapano, e la conoscenza approssimativa di dove passano i tubi nell’intonaco. Le viti sono tornate nel cassetto. ## I nomi IKEA, cioè incantesimi nordici {: #i-nomi-ikea-cioe-incantesimi-nordici } Una parentesi sui nomi, perché i nomi IKEA meritano attenzione. BILLY. KALLAX. MALM. LACK. HEMNES. BESTÅ. FJÄLKINGE. Sono nomi di laghi svedesi, paesi, fiumi, aggettivi. Ma suonano come incantesimi. Come creature mitologiche. Come le fasi di un lutto particolarmente complesso. “Ho montato il FJÄLKINGE.” Sembra una frase che diresti dopo una spedizione artica. E in un certo senso lo è. Perché il FJÄLKINGE è uno scaffale metallico che sembra semplice e che, dopo quattro ore di montaggio, ti fa riconsiderare tutte le tue scelte di vita, inclusa quella di non aver comprato una libreria vera dal falegname. E poi ci sono i nomi dei pezzi piccoli. La minuteria. FIXA, TRÅDFRI, SKÅDIS. Li leggi sulla scatola e pensi: “Questo non è un prodotto, questo è il nome del cattivo in un film scandinavo.” “SKÅDIS ha colpito ancora.” ## La telefonata nel momento peggiore {: #la-telefonata-nel-momento-peggiore } A un certo punto del montaggio, di solito tra il passo 12 e il passo 16, nella terra di nessuno dove sei troppo avanti per tornare indietro e troppo confuso per andare avanti, arriva la telefonata. Non è mai una telefonata breve. È tua madre. O un collega. O quel parente che chiama solo quando hai le mani impegnate. Ti trovi con il telefono tra la spalla e l’orecchio, una mano che tiene un pannello e l’altra che cerca di avvitare una vite a brugola con un angolo fisicamente impossibile, mentre rispondi “sì, sì, tutto bene” a qualcuno che ti sta raccontando una cosa che richiede attenzione ma che non otterrà attenzione. Perché la tua attenzione è tutta sul fatto che il pannello sta scivolando e se cade sei punto e a capo con il passo 11. La telefonata finisce. Non sai cosa ti hanno detto. Il pannello non è caduto. Consideri entrambe le cose una vittoria. ## La metafora che non riesci a evitare {: #la-metafora-che-non-riesci-a-evitare } A un certo punto del montaggio, di solito mentre sei inginocchiato sul parquet con la schiena che già protesta, ti rendi conto che le istruzioni IKEA sono, in realtà, una metafora abbastanza precisa della vita adulta. Non ti dicono quanto ci vorrà. Il tempo stimato non c’è, o se c’è è il tempo di Björn, che vive in una dimensione parallela dove le cose si incastrano al primo tentativo e nessuno ti chiama mai mentre stai avvitando. Non ti spiegano perché. Solo: fai questo. Poi questo. Non chiedere. Non ammettono che alcune cose sono difficili. Il passo più complicato, quello dove devi tenere fermi tre pannelli mentre inserisci una vite in un punto accessibile solo ai bambini sotto i sei anni e ai contorsionisti professionisti, ha la stessa identica iconografia di quello dove appoggi due pezzi piatti uno sull’altro. Non prevedono gli imprevisti. Il gatto che si siede sulla scatola. Il bambino che vuole “aiutare”. Il partner che dice “ma non è storto?” nel momento esatto in cui stai per avvitare l’ultimo bullone. La bolla nel pavimento che rende ogni cosa leggermente obliqua. E poi la scoperta più crudele di tutte, che non è il mobile a essere storto, è il muro. Il muro. Non ti dicono cosa fare quando sbagli. Non c’è un passo che dice “se hai avvitato il pannello dal lato sbagliato, torna al passo 4”. Perché Björn non sbaglia. Björn non ha mai sbagliato nulla. Björn è l’utopia svedese in forma di omino stilizzato, e il suo giudizio silenzioso è più pesante di qualsiasi rimprovero. E tuttavia funziona. Non sempre al primo tentativo, non sempre senza ammaccature, non sempre senza quella piccola deviazione dal piano che alla fine non si vede e a cui smetti di pensare dopo un po’. Ma funziona. Il mobile regge. La scrivania regge. Il Billy che hai montato nel 2009 regge ancora, nonostante tutto, e ormai fa parte della famiglia. ## Il Billy, santo patrono del truciolato {: #il-billy-santo-patrono-del-truciolato } A proposito del Billy. Parliamone. Il Billy è il punto fermo dell’universo IKEA. Il meridiano zero. La costante cosmologica del mobile componibile. Ogni italiano ha avuto, ha, o avrà un Billy. È una certezza statistica. Il mio primo Billy lo montai nel 2004. Ero giovane, ottimista, e convinto che “un’ora di montaggio” significasse davvero un’ora. Tre ore dopo, con il parquet rigato e un livido al pollice, il Billy era in piedi. Obliquo, ma in piedi. Quel Billy è ancora lì. Ha attraversato tre traslochi, due relazioni, un cambio di città, e un terremoto. Non ha mai vacillato. O meglio, ha sempre vacillato, ma non è mai caduto. Come tutti noi. Il Billy è la prova che la perfezione non è necessaria. Che si può reggere anche con qualche vite in meno, un pannello leggermente storto, e uno spinotto che forse andava dall’altra parte. Il Billy non giudica. Il Billy contiene i tuoi libri, i tuoi ricordi, e quella foto che avresti dovuto incorniciare tre anni fa. Il Billy è paziente. Se IKEA facesse santi, Billy sarebbe il primo. ## Varianti regionali, coppie e altre forme di coraggio {: #varianti-regionali-coppie-e-altre-forme-di-coraggio } Il montaggio IKEA è universale, ma la reazione al montaggio è profondamente locale. L’italiano del sud monta con passione. Parla al mobile. Lo incoraggia. Lo insulta. Lo tratta come un membro della famiglia particolarmente testardo. “Ma dove vai?! Stai fermo! Che ti ho detto!” Il mobile non risponde, ma l’italiano del sud non se ne preoccupa. È abituato a dialogare con cose che non collaborano. L’italiano del nord monta con metodo. Ha il cacciavite elettrico. Ha il tappetino per non rigare il pavimento. Ha già letto le istruzioni. Monta in silenzio, con una efficienza che è essa stessa una forma di aggressività passiva. Quando finisce, non esulta. Annuisce. Come se il mobile fosse un subordinato che ha finalmente capito. L’italiano del centro, e parlo per esperienza diretta, monta con rassegnazione creativa. Sa che qualcosa andrà storto. Lo accetta in anticipo. Quando va storto, sospira. Quando per miracolo non va storto, sospetta un inganno. E poi ci sono le coppie. Montare un mobile IKEA in coppia è il più affidabile test relazionale mai inventato. Più del primo viaggio insieme. Più di conoscere i suoceri. Più di dividere un bagno per la prima volta. Perché il montaggio IKEA in coppia rivela tutto. Chi legge le istruzioni e chi no. Chi ha pazienza e chi no. Chi dice “dammi quella vite” e intende quella vite specifica, e chi la passa e intende un’altra vite, e l’altro dice “no, quella” e l’altro dice “quale?” e il primo dice “quella” indicando con il mento perché ha entrambe le mani occupate, e l’altro prende una rondella. C’è sempre uno che vuole seguire le istruzioni e uno che vuole improvvisare. Uno che dice “ferma, leggiamo” e uno che ha già avvitato tre pannelli e dice “ma è uguale”. Non è uguale. Non è mai uguale. Ho visto coppie solidissime vacillare davanti a un PAX. Il PAX è l’armadio della discordia. È grande, complesso, ha le ante scorrevoli, e richiede un livello di coordinazione che la maggior parte delle coppie raggiunge solo dopo anni di terapia. Se montate un PAX insieme e alla fine vi parlate ancora, sposatevi. Avete superato la prova. ## La mattina dopo IKEA {: #la-mattina-dopo-ikea } C’è un fenomeno poco documentato che io chiamo “la mattina dopo IKEA”. Ti alzi. Hai i muscoli indolenziti in punti che non sapevi di avere. La schiena protesta. Le ginocchia ricordano le due ore sul parquet. Le dita hanno ancora il segno della brugola. Ma poi lo vedi. Il mobile. Lì. In piedi. Completo. Nella stanza. E c’è un momento, un momento brevissimo, prima del caffè, prima di tutto, in cui lo guardi e pensi: “L’ho fatto io.” Con le mie mani. Con un foglio A3. Con una brugola. È un orgoglio primordiale. È lo stesso orgoglio dell’uomo delle caverne che ha costruito un riparo. Non importa che il riparo sia un comodino con un cassetto che non si chiude perfettamente. L’hai fatto tu. Poi ti siedi per colazione e vedi, sotto il tavolo, una vite. Una vite solitaria. Una vite che non sai da dove viene, che non sai dove va, e che rimarrà lì per tre giorni prima di finire nel cassetto. Il ciclo è completo. ## L’incastro finale, e l’epilogo inevitabile {: #lincastro-finale-e-lepilogo-inevitabile } C’è una soddisfazione specifica nel momento in cui l’ultimo pannello va al suo posto e la struttura, improvvisamente, diventa rigida. Tutto quello che sembrava traballante si solidifica. I rumori spariscono. Björn aveva ragione dall’inizio. Non so dirti se quella sensazione vale le due ore di lavoro, la schiena, le viti misteriose nel cassetto, il momento in cui hai capovolto il mobile da solo tenendolo con un ginocchio e una preghiera laica, l’aiutante che ti ha passato la vite sbagliata, il bambino che ha perso la M6x30 sotto il divano, la telefonata di tua madre, e quella piccola ammaccatura sul lato sinistro che “tanto va contro il muro e non si vede”. So che ogni volta mi convinco che la prossima volta leggerò le istruzioni dall’inizio. E ogni volta arrivo al passo 7, il pannello sembra andare bene, e penso: sì dai, lo so già dove va. Non lo so mai. ### post scriptum Sto guardando il sito IKEA adesso. C’è una libreria nuova. Legno massello, tre ripiani, “montaggio semplice”. Montaggio semplice. Lo so che non è vero. Lo sai anche tu. Lo sa anche Björn, nel suo cuore stilizzato. La ordino lo stesso. Se anche tu hai un cassetto di viti senza nome, un Billy che non è mai stato davvero dritto, e la certezza incrollabile che la prossima volta leggerai le istruzioni, sei dei miei. Ci vediamo al passo 7. --- # Quando il software diventa un'intenzione - **URL:** https://margiovanni.it/it/blog/quando-il-software-diventa-unintenzione/ - **Pubblicato:** 2026-03-01 - **Tag:** Intelligenza Artificiale, Prodotti Digitali, Software, Startup - **Tempo di lettura:** 9 min > Ho creato un’app in 17 minuti senza scrivere codice. Non è la demo che conta, ma cosa succede al mercato consumer quando il software diventa un’intenzione. Stamattina, mentre preparavo la colazione, ho costruito un prodotto digitale pronto per la produzione. Non un prototipo messo lì tanto per, non un mockup con la frase implicita “poi lo sistemiamo”. Intendo proprio qualcosa di vivo, con un dominio, un backend funzionante, un’interfaccia usabile. Qualcosa che un utente vero può aprire adesso e usare. Ci ho messo 17 minuti. Non ho scritto una riga di codice. Ho parlato con uno strumento AI. Il risultato è [music-map.uk](), un’app che risponde a una domanda che forse non ti sei mai fatto: *come suona questo posto nel mondo?* E no, questo post non parla di music-map. O meglio, non parla del prodotto in sé. Parla di cosa significa che una cosa del genere possa esistere così, in quel modo, mentre l’acqua per il caffè sta salendo. ## La distinzione che cambia tutto {: #la-distinzione-che-cambia-tutto } Qui devo fare un chiarimento, perché altrimenti sembra che stia raccontando una storia che esiste già da anni, solo con un po’ di entusiasmo in più. Esistono strumenti consumer che promettono esattamente questo: apri un browser, descrivi l’idea, e in pochi clic hai un’app. Lovable, Bubble, Glide, Softr. L’ecosistema è enorme e cresce continuamente. Il punto è che, oggi, c’è ancora un gap abbastanza netto tra “ho costruito qualcosa che sembra un’app” e “ho costruito qualcosa che regge in produzione”. Non lo dico per snobismo, e nemmeno come giudizio su quei prodotti. In certi casi d’uso sono davvero ottimi. È proprio una questione di sostanza: robustezza, scalabilità, controllo sul codice generato, capacità di intervenire quando qualcosa si rompe, ownership vera dell’infrastruttura. Quella sensazione, molto concreta, di sapere dove stanno i pezzi e cosa succede se uno di quei pezzi smette di funzionare. Io ho usato strumenti pensati per chi, in qualche modo, sa già cosa sta costruendo. Strumenti che danno per scontato che tu abbia contesto tecnico, che tu sappia leggere un errore, che tu possa prendere decisioni architetturali quando te le mettono davanti. Questa differenza oggi è ancora enorme. Ed è esattamente il punto. ## Il b2b non mi spaventa, almeno per ora {: #il-b2b-non-mi-spaventa-almeno-per-ora } Mentre finivo il caffè mi è venuta addosso la domanda che nel settore aleggia sempre, anche quando facciamo finta di niente: *questa cosa mi toglie il lavoro?* Nel b2b la risposta, per come la vedo adesso, è no. O almeno, non nel senso catastrofico che piace alla narrazione mainstream. Perché il lavoro b2b fatto bene non è mai stato “scrivere codice”. È capire il contesto di un cliente, tradurre esigenze spesso confuse in requisiti tecnici precisi, garantire che un sistema regga sotto pressione, navigare compliance e normative, mantenere relazioni di fiducia nel tempo. Nel quotidiano, in Oltrematica, mi capita di avere sul tavolo nello stesso momento una migrazione da Python a Laravel 12, framework di conformità alla Cyber Resilience Act, piattaforme sbom per clienti che devono rendicontare il proprio software a enti pubblici, e soluzioni legate alla Product Liability Directive che entrerà in vigore nel 2026. Non è roba che risolvi con una conversazione di 17 minuti. L’AI ha cambiato *come* faccio quel lavoro. La velocità su certi task è aumentata in modo quasi imbarazzante. Ma il valore che porto non era nella battitura del codice. Era nel sapere *cosa* scrivere, *perché* , e soprattutto *cosa evitare*. Quella parte, per ora, non è sparita. Anzi, forse si è rafforzata, perché mi lascia più spazio per pensare. ## Il consumer è un’altra storia {: #il-consumer-e-unaltra-storia } Sul consumer, invece, mi sento meno tranquillo. Non perché domani spariscono le app, ma perché mi sembra che stia cambiando la forma del mercato. Se prendi la classica curva di adozione, innovatori, early adopter, maggioranza precoce, maggioranza tardiva, ritardatari, e ti chiedi dove siamo con gli strumenti ai per sviluppare software, viene fuori una cosa strana. Per chi sviluppa, siamo già nella maggioranza precoce. Molti li usano ogni giorno, l’integrazione nei workflow è reale, la produttività è misurabile. Per un utente non tecnico, invece, siamo ancora tra innovatori e primissimi early adopter. La soglia tecnica è ancora alta. Non alta come dieci anni fa, ma abbastanza da escludere la maggior parte delle persone. E quella soglia si abbassa ogni mese. Non sempre in modo lineare. A volte succede un salto, magari perché qualcuno trova un’interfaccia che funziona davvero, o perché un modello diventa abbastanza capace da gestire l’ambiguità del linguaggio naturale senza costringerti a correggerlo ogni due minuti. Quando quella soglia scenderà abbastanza da essere attraversata da una persona normale, una che non sa cosa sia un server e non vuole nemmeno saperlo, il mercato consumer del software cambierà in modo irreversibile. ## Il vero “prodotto” delle app consumer {: #il-vero-prodotto-delle-app-consumer } Provo a dirla in modo semplice. Negli ultimi quindici anni un’app consumer ha funzionato così: qualcuno aveva un’idea, e solo chi aveva competenze tecniche, o soldi per comprarle, riusciva a trasformarla in un prodotto. Poi quel prodotto veniva distribuito e usato da altri. Il valore era nell’esecuzione, certo. Ma sotto sotto c’era un’altra cosa: la distanza. La distanza tra l’avere un’intenzione e il poterla usare. Quel gap, tra “vorrei” e “posso”, è stato il mercato. Le app consumer esistevano perché c’era una barriera tecnologica tra chi sapeva costruire e chi voleva usare. Se quella distanza si annulla, se chiunque può descrivere ciò che vuole e ricevere in cambio software funzionante calibrato sui propri bisogni, cosa rimane del modello tradizionale? Non sto dicendo che le app spariscono domani. Sto dicendo che il meccanismo che ha sostenuto una parte enorme del consumer potrebbe smettere di funzionare prima di quanto ci aspettiamo. ## Il software personalizzato diventerà normale? {: #il-software-personalizzato-diventera-normale } Da qualche mese mi ronza in testa un’idea che mi sembra radicale, ma forse lo è solo perché siamo abituati al contrario. Nel mondo fisico la produzione di massa ha senso perché la personalizzazione costa. Una sedia su misura costa molto più di una sedia Ikea. Quindi accetti un compromesso e compri qualcosa di standard, “abbastanza buono”. Il software ha funzionato allo stesso modo. Un’app per prendere note è progettata per milioni di persone, quindi farà scelte che vanno bene per molti e sono perfette per pochissimi. Tu la compri perché costruirtela su misura, fino a ieri, costava anni o migliaia di euro. Ma se il costo della personalizzazione crolla quasi a zero? Se posso descrivere come voglio davvero la mia app per le note, con le categorie che uso io, il flusso che preferisco io, integrata con gli strumenti che ho già, ha ancora senso comprare quella pensata per milioni di utenti? Forse sì, per comodità. Forse no, se la differenza tra “adattarmi” e “averla come la voglio” diventa troppo evidente. Mi chiedo se il software di massa farà la fine della musica commerciale nell’era dello streaming. Rimane, certo, ma smette di essere il centro di tutto, perché accanto crescono esperienze più personali, più su misura. ## Chi potrebbe resistere {: #chi-potrebbe-resistere } Se questo scenario si avvera, e ci metto un “se” non perché dubito della direzione, ma perché la velocità e la forma del cambiamento sono davvero incerte, ci sono modelli consumer che sembrano più solidi di altri. Le piattaforme di rete, per esempio. Twitter, Linkedin, WhatsApp. Il loro valore non sta nell’app in sé, ma nel fatto che ci sono dentro tutti gli altri. Non puoi avere la tua versione personalizzata di una rete, perché una rete senza rete è solo un’interfaccia vuota. Poi ci sono i servizi con dati proprietari. Spotify non vende un player musicale. Vende accesso a cataloghi, metadati, licenze, algoritmi alimentati da miliardi di ascolti. Quella roba non la generi con un prompt. E ci sono i prodotti dove trust e compliance sono parte del pacchetto. Finanza, sanità, legale. Anche se un AI ti generasse il software perfetto, rimane la domanda: chi si prende la responsabilità? Chi certifica? Chi risponde quando qualcosa va storto? Infine, forse, i prodotti di fascia altissima con UX eccezionale. Alcune esperienze sono curate in un modo che non è solo “funziona”, è proprio qualità percepita. Notion, Linear, Figma. Replicare funzionalità è una cosa. Replicare quella coerenza, quel dettaglio, quella fiducia estetica e operativa è un’altra. Quello che rischia di soffrire di più, invece, sono le utility di nicchia. Le app che “fanno una cosa sola”, i micro-saas da 9,99 al mese che vivono perché risolvono un problema specifico meglio degli altri. Se me lo posso costruire in un’ora, quel prezzo inizia a tremare. ## La barriera che rimane, per ora {: #la-barriera-che-rimane-per-ora } C’è un’obiezione legittima, e la sento anch’io. Le persone non vogliono costruire le proprie cose. Vogliono usarle. È vero. E probabilmente lo sarà ancora per un bel po’. C’è comodità, c’è fiducia, c’è risparmio cognitivo. Anche solo formulare bene cosa vuoi è una fatica, figuriamoci iterare, correggere, scegliere. Però quella barriera non è stabile. Si abbassa con l’abitudine. Si abbassa con interfacce migliori. Si abbassa con l’educazione digitale. E si abbassa soprattutto quando il vantaggio di avere qualcosa su misura diventa abbastanza evidente da giustificare lo sforzo, mentre lo sforzo continua a ridursi. Secondo me il punto di inflessione non sarà “lo strumento è diventato accessibile”. Sarà “la prima volta che qualcuno che conosco mi mostra cosa ha fatto in 20 minuti e io penso: potrei farlo anch’io”. Quel momento sta arrivando. Per alcune persone è già arrivato. ## Cosa potremmo vedere nei prossimi anni {: #cosa-potremmo-vedere-nei-prossimi-anni } Non sono un analista e non ho una sfera di cristallo, quindi prendete queste come sensazioni informate, non come previsioni. Penso che vedremo una prima ondata di prodotti consumer che non vengono più acquistati ma costruiti. All’inizio nei segmenti più tech-friendly, developer, designer, studenti universitari, e poi a cerchi concentrici. Penso che vedremo una pressione enorme sui prezzi dei micro-saas. Non perché diventino inutili, ma perché diventa difficile giustificare un abbonamento quando la stessa utilità è generabile su richiesta. Sopravvivrà chi offre qualcosa che non si genera facilmente: dati, network, fiducia, integrazione profonda con ecosistemi esistenti. E penso che emergeranno nuovi intermediari. Non “costruttori di app”, ma curatori e distributori di intenzioni di software. Gente che impacchetta prompt, configurazioni, flussi già testati, così altri possono creare senza partire da zero. Una specie di marketplace di template, ma più profondo, più operativo. Probabilmente arriveranno anche tentativi di regolamentazione, più o meno goffi, su alcuni scenari particolari. ## La colazione come metafora {: #la-colazione-come-metafora } Torno al punto di partenza, perché è lì che mi è rimasta addosso la sensazione. Non è la velocità che mi ha colpito davvero. È il costo cognitivo. Ero distratto, stavo facendo altro, avevo la testa su due cose in parallelo. Non era una sessione di lavoro. Non era “oggi costruisco un prodotto”. Eppure il risultato è abbastanza buono da stare online. Questo, per me, è il segnale. Il fatto che produrre software stia diventando qualcosa che fai *in parallelo ad altro* , come mandare una mail o cercare qualcosa su Google. Un’azione che non richiede più un contesto dedicato, una competenza specifica, un’energia mentale speciale. Quando una cosa diventa così, cambia il suo posto nella gerarchia cognitiva e culturale. E con esso cambia il mercato che ci è cresciuto intorno. Il software sta diventando un’intenzione. Non ancora per tutti, non ancora in modo stabile, ma la direzione è quella, e la velocità sta aumentando. E allora la domanda che mi rimane, stamattina, è questa. > Se stai costruendo un prodotto consumer, il valore sta nella distanza tecnologica tra te e il tuo utente, oppure in qualcosa che esiste anche quando quella distanza non esiste più? **Se non hai una risposta chiara, forse è il momento di trovarne una.** --- # La bellezza dell'email alle 8 di mattina - **URL:** https://margiovanni.it/it/blog/la-bellezza-dellemail-alle-8-di-mattina/ - **Pubblicato:** 2026-02-28 - **Tag:** Comunicazione, Email, Lavoro, Produttività - **Tempo di lettura:** 6 min > Un elogio dell’email come rito mattutino: meno rumore, più chiarezza e memoria. Perché forse non è il nemico, ma l’unica adulta nella stanza. Sono le 7:58. Sono seduto alla scrivania con un caffè che ha esattamente la temperatura giusta, quel momento brevissimo tra “mi ustiono il palato” e “è già freddo” che dura circa quarantacinque secondi e che rappresenta, se ci pensate, la migliore metafora della felicità umana. Apro il client di posta. Ci sono quattordici email nuove. Le scorro. Ne archivio sei, ne cestino tre, ne segno due per dopo. Ne leggo una con attenzione, ci penso, scrivo una risposta di otto righe. Invio. Bevo il caffè. Sono le 8:07 e ho già il controllo della giornata. Ecco, questa piccola liturgia mattutina è la parte più sottovalutata, più disprezzata e, per me, più preziosa della vita lavorativa. E mi viene voglia di difenderla, perché viviamo in un’epoca che ha deciso che l’email è il nemico. ## Il nemico sbagliato {: #il-nemico-sbagliato } Apro LinkedIn e trovo un post che dice: “Ho raggiunto inbox zero e mi ha cambiato la vita.” Un altro: “Ho smesso di leggere le email e la mia produttività è esplosa.” Un altro ancora: “L’email è morta, lunga vita a Slack”. QUATTROCENTOMIA LIKE. Intanto, nel mondo reale, quelli che hanno sostituito l’email con Slack ricevono trecentocinquanta notifiche al giorno distribuite su ventisette canali di cui undici non sanno perché esistono. Quelli che hanno sostituito l’email con WhatsApp ricevono vocali di tre minuti e quaranta che iniziano con “allora...” e finiscono con “vabbè poi ne parliamo”. Quelli che hanno sostituito l’email con le call hanno l’agenda che sembra un Tetris giocato da un sadico, con slot da trenta minuti incastrati uno nell’altro dalle 9 alle 18 senza un buco per andare in bagno. E mi volete dire che il problema era l’email? L’email non ti interrompe. L’email non pretende che tu sia disponibile *adesso* , in questo preciso istante, mentre stai cercando di fare qualcosa che richiede più di undici secondi di attenzione. L’email non ti manda un pallino rosso che attiva nel cervello la stessa risposta chimica di una sirena antiaerea. L’email non fa “ding”. L’email sta lì, nella inbox, educata, paziente, zitta, e aspetta che tu sia pronto. E forse è proprio questo il punto. L’email è uno dei pochi strumenti di comunicazione professionale che, per come è fatta, tende a rispettare il tuo tempo. Ed è per questo che tanti la odiano: perché rispettare il tempo degli altri è diventato quasi un concetto sospetto. ## Elogio della lentezza scritta {: #elogio-della-lentezza-scritta } C’è una cosa che l’email ti costringe a fare e che molti strumenti “moderni” ti permettono di evitare con una facilità disarmante: pensare prima di comunicare. Per scrivere un’email devi organizzare le idee. Devi decidere cosa vuoi dire, a chi, e perché. Devi scegliere un oggetto, e l’oggetto di un’email è un piccolo miracolo di sintesi, una riga che deve convincere qualcuno ad aprire il messaggio in un mare di altri messaggi. Devi scrivere frasi compiute. Devi rileggere. Devi chiederti se quel tono è quello giusto o se stai per scatenare una guerra diplomatica con un avverbio di troppo. Confrontate questo processo con un messaggio Slack, che spesso suona così: > “Ehi” > “Ci sei?” > “Ho una cosa” > “Veloce” > “Anzi due” > “La prima:” > [sta scrivendo...] > [sta scrivendo...] > [sta scrivendo...] > “Niente lascia poi te lo dico a voce” Oppure con un vocale WhatsApp, che è l’equivalente comunicativo di prendere il flusso di coscienza di qualcuno, imbottigliarlo, e costringere qualcun altro ad ascoltarlo a velocità 1x. Il vocale è il monologo interiore di Joyce, ma senza il talento letterario e con il rumore del traffico in sottofondo. L’email è l’opposto di tutto questo. L’email è lenta, e la lentezza è il suo superpotere. Ti obbliga a trasformare un pensiero confuso in un messaggio chiaro. Ti costringe a separare l’urgente dall’importante. Ti dà il tempo di cambiare idea prima di premere invio, che non è poco. Perché la chat è una macchina che premia l’impulso. Premi Enter e il pensiero diventa realtà condivisa. E la funzione “elimina per tutti”, diciamolo, non ha mai eliminato davvero niente per nessuno. ## Il paper trail della civiltà {: #il-paper-trail-della-civilta } C’è un altro aspetto dell’email che nessuno celebra abbastanza: è una prova scritta. Io lavoro spesso con la pubblica amministrazione. Lavoro con aziende che hanno uffici legali. Lavoro in un mondo dove, a un certo punto, qualcuno dirà: “Ma chi l’ha deciso questo?” E in quel momento, quel momento preciso che arriva in ogni progetto con la certezza di una tassa, vuoi avere un’email. Non un messaggio Slack che qualcuno potrebbe aver modificato o perso in un canale che si chiama “varie-ed-eventuali-2”. Non un vocale che nessuno riascolterà mai davvero. Non il ricordo vago di una call di cui non esistono note perché “tanto era informale”. Un’email con data, ora, mittente, destinatari e testo è un piccolo atto notarile della vita lavorativa. È la risposta definitiva a “io non sapevo”, “a me non l’hanno detto”, “non eravamo d’accordo così”. È una memoria esterna che compensa il fatto che gli esseri umani ricordano le conversazioni nel modo che gli conviene. Ogni volta che qualcuno mi dice “ti mando un vocale così facciamo prima”, io penso: prima di cosa? Prima di quando dovrò dimostrare cosa ci siamo detti? ## La call che poteva essere un’email {: #la-call-che-poteva-essere-unemail } Qui divento polemico, e forse dovrei scusarmi in anticipo. Poi però mi dico che no, non mi scuso. Il settanta percento delle call a cui partecipo poteva essere un’email. Lo sapete anche voi. Lo sa chiunque abbia mai vissuto una riunione di trenta minuti di cui venticinque sono stati spesi a cercare di condividere lo schermo, tre a chiacchierare del tempo e due a dire la cosa che si poteva scrivere in quattro righe. “Facciamo una call veloce” è una delle bugie più grandi del lavoro contemporaneo. Non esistono call veloci. Esistono call che iniziano cinque minuti in ritardo perché qualcuno ha problemi col microfono, durano il doppio del previsto perché qualcuno alza un punto che non c’entra niente, e finiscono con “ok, riassumendo, i prossimi passi sono...” che nessuno segnerà davvero. E la prossima call ripartirà da zero, come se la precedente fosse stata un sogno. Sapete cosa non ha problemi col microfono? Un’email. Sapete cosa non dura il doppio del previsto? Un’email. Sapete cosa contiene già i “prossimi passi” nel momento in cui la ricevi? Esatto. Non sto dicendo che le call non servono. Servono, eccome. Quando c’è da discutere qualcosa di complesso, quando c’è un conflitto da risolvere, quando servono le facce e i toni di voce. Ma per tutto il resto, aggiornamenti, decisioni binarie, domande con risposta, condivisione di documenti, l’email è superiore in quasi ogni metrica che conti davvero: tempo, chiarezza, tracciabilità, rispetto per chi è dall’altra parte. ## Il rituale {: #il-rituale } Torno alle 7:58 di mattina. Al caffè alla temperatura giusta. Alla inbox che aspetta. C’è un rituale nell’aprire la posta che gli strumenti istantanei hanno un po’ distrutto. È il rituale di iniziare la giornata con ordine. Di guardare cosa è arrivato, decidere cosa è importante, rispondere a mente fresca. È uno degli ultimi spazi della giornata lavorativa in cui sei tu a decidere il ritmo, prima che Slack, Teams, WhatsApp e il calendario prendano il sopravvento e trasformino le tue ore in una partita di ping-pong giocata su sette tavoli contemporaneamente. L’email non è sexy. Non ha emoji animate. Non ha la spunta blu. Non ti dice se qualcuno “sta scrivendo”. Non ti fa sentire connesso in tempo reale. Però è alle 8 di mattina, con un caffè in mano e quattordici messaggi da gestire in pace, che io faccio il mio lavoro migliore. E nessun pallino verde di stato online potrà mai sostituire quel momento. Quindi no. L’email non è morta. L’email è, forse, l’unica adulta nella stanza. E come spesso succede agli adulti nella stanza, viene ignorata in favore di chi fa più rumore. --- # Il cliente ha sempre torto (e forse è un bene) - **URL:** https://margiovanni.it/it/blog/il-cliente-ha-sempre-torto-e-forse-e-un-bene/ - **Pubblicato:** 2026-02-27 - **Tag:** Consulenza IT, Cultura Del Lavoro, Project Management, Software - **Tempo di lettura:** 7 min > Nella consulenza it il sì automatico uccide i progetti. Dire no, con rispetto, è spesso il servizio migliore: meno sprechi, più fiducia, più verità. C’è una frase che in consulenza, almeno qui da noi, suona quasi come una bestemmia. Una di quelle cose che pensi mentre guardi l’ennesima riunione trasformarsi in un catalogo di richieste, ma che poi non dici. Perché non sta bene, perché “il rapporto col cliente”, perché il commerciale ti fulmina con lo sguardo e qualcuno ti ricorda che “siamo qui per soddisfare le esigenze”. Eppure. Il cliente ha torto. Non sempre, ovviamente. Non su tutto. Però molto più spesso di quanto ci piaccia ammettere. E mi chiedo se il problema vero non sia il cliente in sé, ma la bugia gentile che gli raccontiamo da anni. Quella del “il cliente ha sempre ragione”. Una bugia che nel software italiano ha fatto danni che non si riescono nemmeno a contare bene, perché i fallimenti raramente hanno un cartello con scritto “fallimento”. Di solito sono più silenziosi. Sono progetti che finiscono in produzione e poi nessuno li usa. Sono soldi bruciati in cose che non migliorano niente. Sono notti lunghe di persone che sapevano che stava andando storto, ma non avevano lo spazio, o il permesso, di dirlo. Questo è un pezzo un po’ cattivo, sì. Non vi chiedo di essere d’accordo. Vi chiedo solo di essere onesti, almeno per il tempo di questa lettura. ## Il sì che uccide i progetti {: #il-si-che-uccide-i-progetti } Ho visto morire più progetti per un sì che per un no. Il meccanismo è quasi sempre lo stesso, e proprio per questo fa paura. Il cliente chiede qualcosa. Tu lo sai, lo senti, lo vedi nei dettagli: è sbagliato tecnicamente, o economicamente, o proprio come direzione. Ma dici sì lo stesso. Dici sì perché c’è un contratto. Perché c’è una relazione da proteggere. Perché “poi lo sistemiamo”. Perché la stretta di mano è già avvenuta e tornare indietro sembra una sconfitta. Perché dire no è scomodo, richiede argomenti, richiede energia, e soprattutto richiede coraggio. E allora il progetto non muore in un colpo solo. Muore un sì alla volta. Ogni sì aggiunge una feature che nessuno userà. Ogni sì sposta un pezzo di scadenza, o comprime un pezzo di qualità. Ogni sì rende l’architettura un po’ più fragile e il codice un po’ più contorto, finché quello che stai costruendo non assomiglia più a un prodotto, ma a un compromesso stratificato. Alla fine consegni un software che fa centocinquanta cose, nessuna bene, e il cliente ti guarda e dice: “non è quello che volevo”. E qui c’è la parte che brucia, perché in un certo senso ha ragione. Non è quello che voleva. È quello che ha chiesto. Sono due cose diverse. E forse il nostro mestiere, quello vero, non è eseguire ordini. È riconoscere la differenza. ## Catalogo degli orrori (tutti veri, purtroppo) {: #catalogo-degli-orrori-tutti-veri-purtroppo } Quello che segue è vero. I nomi sono cambiati, ma le dinamiche no. E se vi viene da pensare “ne ho visto uno identico”, ecco, non siete soli. ### Il gestionale infinito Un’azienda medio-grande chiede un gestionale. Fin qui tutto normale. Poi, mentre si sviluppa, ogni reparto aggiunge requisiti. Risorse umane vuole il modulo ferie, marketing vuole la dashboard, amministrazione vuole l’integrazione col commercialista, e ognuno è convinto di essere il centro del mondo. Nessuno ha il potere di dire basta, perché ogni reparto è un “cliente interno” che “ha ragione”. Risultato: diciotto mesi di sviluppo, un prodotto che fa tutto male, e dopo il rilascio l’azienda continua a usare Excel. Che alla fine, nel suo piccolo, almeno non tradisce. ### Il bando fotocopia Un comune deve digitalizzare un servizio. Il bando viene scritto copiando quello di un altro comune, magari tre volte più grande, con bisogni completamente diversi. Dentro ci finiscono requisiti che suonano bene sulla carta, ma che nessun cittadino userà mai. Chi vince l’appalto spesso lo sa. Ma il bando è il bando. Quindi si costruisce esattamente quello che è scritto. Si consegna, si collauda, si spuntano caselle. La piattaforma va online. Sei mesi dopo il servizio viene gestito ancora al telefono. E la cosa più triste è che, formalmente, è andato tutto bene. ### L’app che doveva cambiare tutto Una PA locale vuole un’app mobile per i cittadini. Il decisore è un assessore che ha visto l’app di un altro comune e la vuole uguale. Niente analisi dei bisogni, niente ricerca utente, niente di niente. Solo: “voglio l’app”. Il fornitore la costruisce. Al lancio la scaricano in quattrocento. Dopo tre mesi la usano in dodici, contando i dipendenti del comune. L’assessore fa la conferenza stampa e parla di innovazione. Il fornitore incassa e passa al prossimo. E io non riesco mai a decidere chi mi metta più a disagio in questa storia. ### Il restyling che era una riscrittura Un cliente chiede di “dare una rinfrescata” al sito. Il commerciale vende un restyling. Alla prima riunione operativa emerge che il sito non ha un CMS, il database è un foglio Excel, i contenuti non esistono, e “rinfrescata” significa ripensare tutta la presenza digitale. Ma il preventivo è quello di un restyling, la timeline è quella di un restyling, e le aspettative sono quelle di un restyling. Tutti sanno che non è un restyling. Nessuno lo dice. ### Il progetto zombie Un progetto doveva durare sei mesi e entra nel terzo anno. Non funziona, non viene usato, ma nessuno lo chiude perché chiuderlo significherebbe ammettere che è stato un errore. Il cliente continua a pagare change request. Il fornitore continua a fatturare. Entrambi sanno che è morto. Entrambi fanno finta che sia vivo. Non fallisce mai ufficialmente. Semplicemente smette di essere nominato nelle riunioni, come uno zio scomodo di cui non si parla a pranzo. ## Perché succede davvero {: #perche-succede-davvero } Succede perché il nostro settore ha un problema strutturale con la verità. Il modello di business della consulenza IT italiana è costruito sul sì. Vinci i progetti dicendo sì. Mantieni i clienti dicendo sì. Fai carriera dicendo sì. L’intero sistema, dai commerciali ai project manager fino agli sviluppatori, è ottimizzato per minimizzare il conflitto e massimizzare la fatturazione a breve termine. Il guaio è che breve termine e lungo termine sono in guerra. Dire sì oggi significa quasi sempre pagare domani. Ogni feature in più è debito tecnico. Ogni requisito accettato senza analisi è una bomba a orologeria. Ogni timeline compressa per compiacere qualcuno è una garanzia di straordinari, spesso non pagati, e di qualità sacrificata. E intanto il cliente non impara mai. Non perché sia stupido, ma perché nessuno gli dice che quella richiesta era sbagliata. Nessuno gli dice che quel bando era scritto male. Nessuno gli dice che quell’app non serviva a nessuno. Circondato da gente che annuisce, il cliente continua a chiedere le stesse cose sbagliate, e il ciclo ricomincia. E qui arriva la parte che dà fastidio, perché sposta la responsabilità. Non è colpa del cliente. È colpa nostra. È colpa di un settore che ha rinunciato al proprio ruolo, quello dell’esperto. Quello che sa cose che il cliente non sa e che ha il dovere, non il diritto, di dirle. ## Il no come servizio {: #il-no-come-servizio } Il miglior servizio che puoi rendere a un cliente è dirgli no. No, quella feature non serve. No, quella timeline non è realistica. No, quel bando è scritto male e se lo seguiamo alla lettera costruiremo qualcosa di inutile. No, non ti serve un’app. No, non ti serve l’AI. No, non ti serve un restyling. Ti serve fermarti e capire cosa vuoi fare davvero. Ogni no costa. Costa scomodità, costa tensione, costa qualche telefonata difficile. A volte costa il progetto. Però ogni no è anche un atto di rispetto verso il cliente, perché lo tratta come un adulto capace di ascoltare la verità, non come qualcuno da accontentare per quieto vivere. I clienti migliori che ho avuto nella mia carriera sono quelli a cui ho detto più no. All’inizio si irrigidiscono, com’è normale. Poi, se resisti e se argomenti con calma, succede una cosa: capiscono che quando dici sì puoi essere creduto. La fiducia non si costruisce sull’accordo continuo. Si costruisce sulla sincerità. E la sincerità, nel nostro settore, è rara. Forse più rara di un buon developer. Forse più rara di un progetto consegnato in tempo. Forse più rara di un bando scritto bene. ## Un manifesto minimo, senza eroismi {: #un-manifesto-minimo-senza-eroismi } Non so se questo sia un manifesto, ma se lo è, per me sta in tre righe. Non dire sì quando sai che è no. Non costruire quello che il cliente chiede se sai che non è quello che gli serve. E quando sbagli, perché sbaglierai e sbaglieremo tutti, almeno sbaglia dicendo la verità, non annuendo. **Il cliente non ha sempre ragione. Ma merita sempre qualcuno che abbia il coraggio di dirglielo.** --- # Il parcheggio del supermercato alle 18:30 - **URL:** https://margiovanni.it/it/blog/il-parcheggio-del-supermercato-alle-1830/ - **Pubblicato:** 2026-02-26 - **Tag:** Città, Design, Mobilità, Vita Quotidiana - **Tempo di lettura:** 8 min > Alle 18:30 il parcheggio del supermercato diventa una piccola guerra civile. tra suv, carrelli vaganti e design fuori contesto, cosa dice di noi? Ore 18:27. Esco dall'ufficio con quell'ottimismo ingenuo che mi prende sempre quando penso alla spesa feriale. Mi servono quattro cose, letteralmente quattro: latte, pane, pomodori, detersivo. Dieci minuti, dentro e fuori. Questo è il piano. Il piano non sopravvive mai al parcheggio. Ore 18:34. Arrivo. E il parcheggio del supermercato è pieno. Non pieno come "ci sono pochi posti". Pieno come un posto dove le regole smettono di contare e la geometria diventa un'opinione. Auto in doppia fila, auto sui marciapiedi, auto nelle strisce gialle, auto parcheggiate in diagonale in posti pensati per la sosta parallela. C'è un SUV bianco. È sempre un SUV bianco. Occupa un posto e mezzo con una naturalezza quasi poetica, come se fosse nato così e fossimo noi quelli fuori scala. Poco più in là una Panda è incastrata talmente vicino a un pilastro che mi chiedo, sul serio, se il conducente abbia già previsto l'uscita dal bagagliaio. Magari è una feature. Ore 18:37. Faccio il primo giro. Niente. Secondo giro. Niente. Terzo giro. Una signora sta caricando la spesa. Mi fermo, metto la freccia. Aspetto. Lei carica una busta. Poi un'altra. Poi sistema le buste. Poi prende il telefono. Poi parla al telefono. Poi cerca le chiavi. Io aspetto. Dietro di me si forma una coda. Qualcuno suona. La signora mi guarda come se la stessi aggredendo. E io mi rendo conto che in quel momento sto facendo esattamente la cosa che odio quando la fanno gli altri: sto trasformando un gesto banale in un piccolo braccio di ferro. Ore 18:43. Parcheggio. Ho impiegato nove minuti per fermare l'auto. La spesa ne richiederà sette. Il rapporto è sbagliato. Il rapporto è sempre sbagliato. * * * ## La guerra civile a bassa intensità {: #la-guerra-civile-a-bassa-intensita } Il parcheggio del supermercato alle 18:30 è quel punto strano in cui la società civile si dissolve senza fare rumore. Non succede niente di eclatante, non c'è un evento singolo. È più un cambio di atmosfera. Come se entrassi in una stanza e qualcuno avesse abbassato il livello di fiducia reciproca. Persone che nella vita normale sono educate, ragionevoli, funzionali, gente che dice grazie, che tiene la porta, che fa la raccolta differenziata, entrano nel parcheggio e diventano predatori. Svanisce ogni contratto sociale. Vale la legge del più grosso, del più veloce, del più sfacciato. Le regole ci sono. Le frecce, le strisce, i cartelli. Ma a quell'ora diventano suggerimenti. Decorazioni. Un'arte astratta sull'asfalto. E poi c'è lui, il carrello. Il carrello della spesa è l'emblema perfetto perché è un oggetto semplice, con un posto preciso dove dovrebbe finire: la rastrelliera. È a dieci metri. Dieci. Eppure una percentuale imbarazzante di carrelli finisce abbandonata in mezzo al parcheggio, a occupare un posto auto, o a rotolare piano verso la tua portiera con l'inesorabilità di un destino greco. Mi chiedo sempre chi sia la persona che lascia il carrello lì. E poi penso che forse lo so. Probabilmente è la stessa persona che in ufficio scrive email sulla responsabilità sociale d'impresa. O magari sono io, in una giornata storta, quando mi dico "tanto lo prende qualcuno". Ho una teoria, un po' cattiva ma difficile da scacciare: il modo in cui una persona tratta il carrello del supermercato è uno dei test morali più affidabili che esistano. Non c'è punizione per chi lo abbandona, non c'è ricompensa per chi lo riporta. È puro libero arbitrio. E il parcheggio, ogni sera alle 18:30, ti mostra quanto vale il libero arbitrio della tua comunità. * * * ## Il SUV e la bugia {: #il-suv-e-la-bugia } Parliamo del SUV. Non di tutti i SUV. Del SUV urbano. Quello comprato per andare al supermercato, portare i figli a scuola e fare il tragitto casa-ufficio su strade asfaltate. Il SUV che non vedrà mai una strada sterrata, non supererà mai un guado, non affronterà mai niente di più impervio del dosso artificiale davanti alla scuola elementare. Il SUV urbano è un oggetto progettato per un contesto che non esiste nella vita di chi lo usa. È l'equivalente automobilistico di comprare uno zaino da alpinismo per andare in ufficio. Eppure lo compriamo lo stesso, perché il SUV vende una storia: sicurezza, dominio, controllo. Sei in alto, vedi tutto, sei protetto. Che poi "protetto da cosa" nessuno lo dice davvero. Forse dal traffico che il SUV stesso contribuisce a creare, presumibilmente. Nel parcheggio, però, il SUV rivela la sua natura. È troppo largo per i posti auto progettati negli anni Novanta, quando le macchine erano più piccole e la gente, non so, meno ambiziosa. Non entra. Sporge. Invade il posto accanto. E ci sono dettagli che mi mettono sempre un po' a disagio. Tipo il fatto che il conducente spesso non riesce a vedere un bambino che passa dietro, perché il cofano è all'altezza di un adulto. Allora arriva la telecamera posteriore a compensare. Un problema tecnologico per risolvere un problema che la tecnologia ha creato. Un cerchio perfetto di assurdità. Ma il SUV, a pensarci bene, non è solo un errore del consumatore. È un errore di design. Qualcuno ha progettato un veicolo urbano che non funziona nello spazio urbano. Qualcuno lo ha venduto a persone che vivono in città con strade strette, parcheggi piccoli, marciapiedi dove i pedoni dovrebbero, in teoria, avere la precedenza. Il prodotto non è sbagliato per chi lo ha progettato. È sbagliato per il contesto in cui esiste. E questa cosa, se fai software, ti suona familiare. * * * ## Design per il contesto sbagliato {: #design-per-il-contesto-sbagliato } Io progetto software. E riconosco nel parcheggio lo stesso errore che vedo in tanti progetti falliti: progettare per l'utente ideale invece che per l'utente reale. Il parcheggio del supermercato è stato progettato da qualcuno che pensava, immagino: le persone arriveranno in modo ordinato, parcheggeranno tra le strisce, spegneranno il motore, faranno la spesa, torneranno, ripartiranno. Un flusso lineare, razionale, pulito. Come un diagramma. Le persone non sono un diagramma. Le persone arrivano tutte alle 18:30 perché escono tutte dal lavoro alla stessa ora. Arrivano nervose perché il traffico è stato infernale. Arrivano con la macchina troppo grande perché il mercato gli ha detto che grande è meglio. Arrivano col telefono in mano perché stanno chiamando casa per chiedere se serve anche il parmigiano. Arrivano con i figli che urlano dal sedile posteriore. Arrivano, insomma, da esseri umani. E il parcheggio non è progettato per esseri umani. È progettato per automobili. Che è una cosa diversa. È lo stesso errore che facciamo nel software: progettiamo per il *caso d 'uso felice*. L'utente che legge le istruzioni, che segue il flusso, che compila ogni campo, che clicca dove deve cliccare. Poi arriva l'utente reale, stanco, distratto, con tre tab aperte e il capo che gli scrive su WhatsApp, e il sistema crolla. Non perché l'utente è stupido. Ma perché il design non ha previsto che l'utente fosse umano. Il parcheggio del supermercato è un'interfaccia utente. Una pessima interfaccia utente. E ogni sera alle 18:30 va in crash. * * * ## La città che abbiamo scelto {: #la-citta-che-abbiamo-scelto } A un certo punto mi accorgo che sto dando la colpa al parcheggio, al SUV, alla signora al telefono, ai carrelli vaganti. Ma il parcheggio, in fondo, è solo un sintomo. La malattia è la città. Abbiamo costruito le città intorno alle automobili. Non intorno alle persone, non intorno ai bambini, non intorno agli anziani, non intorno a chi cammina o va in bicicletta. Intorno alle automobili. Ogni decisione urbanistica degli ultimi decenni sembra una risposta alla stessa domanda: dove mettiamo le macchine? Le strade allargate per le macchine. I centri storici svuotati per fare parcheggi. I quartieri residenziali costruiti lontano da tutto, così che per comprare il pane ti serve, indovina, la macchina. A Pescara lo vedi bene. Una città piatta, perfetta per le biciclette, dove quasi nessuno va in bicicletta. Una città sul mare dove il lungomare è un parcheggio per otto mesi all'anno. Una città dove il corso principale è stato pedonalizzato e la gente ha protestato perché "non si può più parcheggiare davanti al negozio", come se il diritto di parcheggiare sotto la vetrina fosse nella Costituzione. Abbiamo progettato la città per l'utente sbagliato. E adesso siamo sorpresi che l'utente giusto, quello che ci vive, non ci stia comodo. Forse la cosa più triste è che ci siamo abituati. Cioè, non è che ci piaccia. Ma lo consideriamo normale. Come se fosse inevitabile che comprare quattro cose richieda una piccola prova di resistenza. * * * ## Ore 18:51 {: #ore-1851 } Esco dal supermercato con la mia busta. Latte, pane, pomodori, detersivo. Sette minuti netti, come previsto. Torno alla macchina. Un carrello è appoggiato alla mia portiera. Lo sposto. Un SUV ha parcheggiato talmente vicino che devo entrare dal lato passeggero e scavalcare il cambio. Lo faccio. Con il latte in mano. Con dignità residua. Esco dal parcheggio. Ci metto quattro minuti perché qualcuno ha bloccato l'uscita in attesa di un posto. Questa cosa mi manda fuori di testa ogni volta, e ogni volta mi dico che è solo un dettaglio. Ma poi penso che i sistemi mal progettati sono fatti di dettagli, di piccoli colli di bottiglia, di micro egoismi che diventano macro problemi. Arrivo a casa. Tempo totale per quattro prodotti: trentasette minuti. Di cui sette di spesa e trenta di infrastruttura. Trenta minuti buttati in un sistema progettato male. Ogni giorno, milioni di persone, la stessa esperienza. Moltiplica il tempo perso per il numero di persone per il numero di giorni e ottieni una cifra che nessuno vuole calcolare perché sarebbe troppo deprimente. E intanto il supermercato ha l'app per la spesa online. Funziona benissimo, dicono. Basta scaricarla, creare un account, accettare i termini di servizio... Ah no. Quella è la lavatrice. Stessa logica, però. Sempre la stessa logica. Progetti fatti per un mondo ordinato, e poi buttati dentro la vita vera, che ordinata non lo è mai. E forse è proprio questo il punto che mi porto a casa, insieme al pane e al detersivo: non è che siamo diventati cattivi. È che ci muoviamo dentro spazi che tirano fuori il peggio, perché sono stati pensati per una versione di noi che non esiste. E domani, alle 18:30, probabilmente ci ricasco. Con lo stesso piano. E lo stesso parcheggio. --- # Non aggiungere AI ai tuoi prodotti. Ripensali da zero. - **URL:** https://margiovanni.it/it/blog/non-aggiungere-ai-ai-tuoi-prodotti-ripensali-da-zero/ - **Pubblicato:** 2026-02-24 - **Tag:** API, Compliance, Prodotto Digitale, Sviluppo Software - **Tempo di lettura:** 8 min > Aggiungere un chatbot non basta. Se metà delle interazioni passerà da agenti AI, serve ripensare software, API, fiducia e compliance. Mi è capitato di pensarci più volte negli ultimi mesi, quasi con un po’ di inquietudine. Ho passato vent’anni a costruire prodotti digitali, abbastanza per ricordarmi bene com’era quando il web 2.0 sembrava la risposta a tutto, e abbastanza per aver vissuto la rivoluzione mobile dall’interno, con quell’aria da “ok, qui cambia davvero qualcosa”. Con l’AI sta succedendo la stessa cosa. Eppure, guardandomi attorno, vedo che molte aziende stanno reagendo come se fosse un aggiornamento qualunque. Un’aggiunta. Un plugin. E forse questo è un problema. ## La trappola del “mettiamoci un po’ di AI” {: #la-trappola-del-mettiamoci-un-po-di-ai } Ormai è quasi un riflesso automatico. Un chatbot nel customer service. Un riassunto generato nel pannello di controllo. Un copilot in una sidebar. Una ricerca “più intelligente”. Sono cose utili, davvero. Non voglio fare il purista che snobba tutto ciò che funziona. Però mi chiedo se non siano anche, allo stesso tempo, cose profondamente conservative. Come mettere un motore elettrico su una carrozza a cavalli e chiamarla rivoluzione. La carrozza resta una carrozza, solo che cambia cosa la traina. Questa dinamica l’ho già vista. Nel 2007 si chiamava “mobile”. Quando è esploso l’iPhone, tantissime aziende hanno preso i siti desktop e li hanno “adattati”. Responsive, bottoni più piccoli, colonne riordinate, hamburger menu, e via. Tecnicamente corretto. Strategicamente… **quasi irrilevante**. Perché a vincere non è stato chi ha adattato il vecchio al nuovo, ma chi ha ripensato tutto. **Uber non è un sito di taxi reso responsive**. È un prodotto che senza GPS, connessione always-on e un dispositivo in tasca non avrebbe avuto senso. Instagram non è Flickr in miniatura. È un linguaggio visivo nato per il mobile, pensato per essere usato con una mano, mentre cammini. WhatsApp non è una mail su smartphone. È comunicazione riprogettata attorno a un presupposto: il dispositivo è personale, sempre con te, sempre connesso. Nessuno di questi prodotti sarebbe nato dalla mentalità del “aggiustiamo quello che c’è”. Sono nati da una domanda diversa. ## La domanda giusta {: #la-domanda-giusta } La domanda non è: *come aggiungo AI al mio prodotto?* La domanda è: **se progettassi questo prodotto oggi, sapendo che metà delle interazioni passeranno attraverso agenti AI, come sarebbe diverso?** Sembra una sfumatura, ma non lo è. Per vent’anni abbiamo progettato software partendo da un assunto quasi invisibile: un essere umano si siede davanti a uno schermo e interagisce con un’interfaccia grafica. Clicca, scorre, compila campi. Quell’assunto non sparirà, ma smetterà di essere l’unico. E quando smette di essere l’unico, tante scelte che sembravano “normali” diventano improvvisamente arbitrarie. Pensate a quante azioni quotidiane facciamo dentro prodotti digitali che, con le API giuste e i permessi giusti, un agente potrebbe fare al posto nostro. Prenotare un ristorante. Confrontare preventivi. Compilare un modulo. Spostare un appuntamento. Analizzare un report. Ordinare la spesa. Pagare una bolletta. Non è fantascienza. I modelli di linguaggio, già oggi, sanno gestire flussi complessi. Il collo di bottiglia spesso non è l’AI. È il modo in cui i prodotti sono costruiti. Molto software è stato progettato per essere *guardato* e *cliccato*. Non per essere *compreso* e *orchestrato*. E questa differenza, secondo me, è enorme. ## Da interfacce a contratti {: #da-interfacce-a-contratti } Qui la cosa diventa concreta. Per anni il “prodotto” è stato l’interfaccia. L’ui era il prodotto. Tutto il resto, backend, API, database, era infrastruttura al servizio degli schermi. Designer che disegnavano schermate, sviluppatori che le implementavano, product manager che misuravano conversioni sui bottoni. Nel paradigma che sta arrivando, il prodotto diventa il contratto. API chiare. Documentazione strutturata. Schemi dati coerenti. Capability esposte in modo semanticamente ricco. Errori che spiegano cosa è successo e cosa fare. Contratti stabili. L’interfaccia grafica non sparisce, ma cambia ruolo. Diventa un *client* del prodotto, non *il* prodotto. Un client tra tanti. E, paradossalmente, questa è una buona notizia. Perché un’API pensata per essere consumata da agenti AI ti costringe a fare buon software. Ti costringe a essere chiaro. Coerente. Affidabile. Componibile. **L’AI non sta abbassando l’asticella. La sta alzando.** ## Da feature a capability {: #da-feature-a-capability } C’è un cambio di mentalità che tocca proprio il cuore del product management. La mentalità tradizionale è feature-driven. Aggiungiamo la feature X. Servono cinque schermate, tre endpoint, due tabelle. Wireframe, user story, criteri di accettazione. e poi un flusso quasi sempre lineare: l’utente arriva in A, clicca B, compila C, ottiene D. La mentalità AI-native, invece, tende a essere capability-driven. Non progetti un percorso. Progetti un mattoncino. Una capability che può essere orchestrata da chiunque: un umano via GUI, un agente via API, un altro sistema via webhook. E spesso verrà combinata con altri mattoncini in modi che non avevi previsto. È più potente, ma anche più difficile. Richiede di pensare in termini di contratti, invarianti, precondizioni e postcondizioni. Richiede un’ingegneria più matura. E qui, lo ammetto, io mi emoziono un po’. Perché è come se la pressione dell’AI rendesse finalmente inevitabili quelle best practice che tanti ingegneri hanno ripetuto per anni, spesso nel vuoto. ## Il paradosso dell’apertura {: #il-paradosso-dellapertura } C’è un altro aspetto che trovo controintuitivo. Per anni il modello dominante è stato il lock-in. Dati chiusi, esportazioni difficili, walled garden. “Così difendiamo il vantaggio competitivo”. In un mondo di agenti AI, la chiusura rischia di diventare un handicap. Un agente lavora meglio con servizi che collaborano. Che espongono dati strutturati. Che hanno API documentate. Che permettono interoperabilità. Se un servizio è opaco e difficile da integrare, l’agente tenderà a bypassarlo e a scegliere alternative più componibili. **E qui c’è un paradosso bellissimo, quasi poetico: per trattenere gli utenti, devi lasciarli liberi di andarsene.** Tra l’altro, questo sposta il campo di gioco anche per le piccole aziende. Perché sull’apertura, sulla qualità delle API, sulla documentazione, sulla pulizia dei contratti, una PMI agile può competere. A volte può persino fare meglio di un colosso pieno di legacy. ## La compliance come superpotere {: #la-compliance-come-superpotere } Questa parte mi sta particolarmente a cuore, perché è il terreno su cui mi ritrovo ogni giorno. GDPR, AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Spesso vengono vissuti come un costo. Un fastidio. Una tassa sul fare business. Io, sempre più, li vedo in modo diverso. In un ecosistema mediato da agenti AI, la fiducia diventa una risorsa computazionale. Non è solo marketing. È un input nelle decisioni. Se un agente deve scegliere tra due servizi simili, tenderà a preferire quello verificabile. Quello con SBOM trasparente. Audit trail completo. Privacy by design documentata. Conformità dichiarata e dimostrabile. In questo senso, la compliance smette di essere solo un costo da sostenere e diventa un segnale di qualità leggibile dalle macchine. Un differenziatore competitivo. Mi rendo conto che suona quasi strano dirlo così, ma credo sia vero: la compliance può diventare un superpotere. E forse l’Europa, con tutta la sua burocrazia che fa sbuffare molti, sta costruendo un terreno dove la fiducia è computabile. Se sai trasformarla in architettura, non è un freno. È un vantaggio. ## Dove tutto questo diventa concreto {: #dove-tutto-questo-diventa-concreto } Potrei lasciarla qui, sul piano delle idee. Ma non sarebbe onesto, perché per me questa transizione è concreta, quotidiana. Quando migriamo un prodotto, non stiamo solo “modernizzando lo stack”. Stiamo preparando un servizio a un futuro in cui gli agenti interagiranno con questi sistemi tanto quanto gli umani. Quando costruiamo una piattaforma SBOM per gestire dipendenze software, non stiamo solo facendo compliance. Stiamo creando un layer di fiducia verificabile. Quando spostiamo il baricentro verso lo sviluppo guidato da specifiche, dove la specifica è il prodotto primario e il codice è un artefatto derivato, non è solo una metodologia. È un modo di lavorare in cui l’AI può essere partner vero, non gadget. A un certo punto ti accorgi che tutto si tiene. Architettura pulita, documentazione rigorosa, compliance by design, API-first, specifiche come oggetto principale. Sono facce della stessa idea. Nel mondo che viene, la chiarezza è potenza. ## Il vero rischio {: #il-vero-rischio } Il rischio più grande, oggi, non è fare “cose sbagliate” con l’AI. È fare cose giuste, ma nel paradigma vecchio. È aggiungere un chatbot invece di ripensare l’architettura dell’interazione. È mettere suggerimenti AI in un’interfaccia che forse non dovrebbe esistere in quella forma. È usare l’AI per scrivere codice più in fretta senza chiedersi se dovremmo scrivere specifiche più chiare. So che è una posizione forte. E so anche che molte aziende stanno ottenendo risultati reali aggiungendo AI ai prodotti esistenti. Non sto dicendo che sia tutto sbagliato. Sto dicendo che è insufficiente. Che rischia di essere il gioco di ieri con i pezzi di oggi. ## Una lettera d’amore alla tecnologia che aiuta {: #una-lettera-damore-alla-tecnologia-che-aiuta } Chiudo con una nota personale, perché questo discorso per me non è solo strategia. Io amo la tecnologia quando aiuta. Quando rende accessibile ciò che era esclusivo. Quando semplifica ciò che era complicato. Quando libera tempo per ciò che conta davvero. Quando penso all’AI nei prodotti digitali non penso, o almeno non solo, a chatbot che rispondono al posto di qualcuno. Penso a un anziano che riesce a interagire con la pubblica amministrazione attraverso un agente che capisce e traduce la burocrazia. Penso a un piccolo imprenditore che gestisce compliance senza un esercito di consulenti perché il software lo supporta nativamente. Penso a un medico che può stare col paziente mentre la parte documentale viene gestita meglio. Penso a uno studente con disabilità che trova un’esperienza davvero accessibile, non una spunta in un foglio excel. Per arrivarci, però, non basta “aggiungere AI”. Bisogna ripensare i prodotti attorno a un mondo in cui umani e agenti coesistono. Non è facile. Richiede di rimettere in discussione assunti che davamo per scontati. Richiede competenze nuove e una certa umiltà. Richiede la domanda più scomoda di tutte: *se partissi da zero oggi, lo farei così?* Però è una sfida bella. Di quelle che ti fanno venire voglia di metterti al lavoro. **Perché dall’altra parte, forse, c’è un software più utile, più accessibile, più affidabile. E, in un senso non banale, più umano.** --- # La mia lavatrice vuole il WiFi - **URL:** https://margiovanni.it/it/blog/la-mia-lavatrice-vuole-il-wifi/ - **Pubblicato:** 2026-02-24 - **Tag:** Internet Delle Cose, Privacy, Tecnologia, Vita Digitale - **Tempo di lettura:** 7 min > Ho comprato una lavatrice e mi ha chiesto app, account e WiFi. Una storia normale, eppure inquietante, su dati, dipendenza e un bottone. Tempo fa ho comprato una lavatrice. Non una lavatrice speciale. Una lavatrice. Di quelle che lavano i panni. Che è, se non sbaglio, l’unica cosa che una lavatrice deve fare. L’ho portata a casa, l’ho attaccata all’acqua, l’ho attaccata alla corrente, ho aperto lo sportello e dentro ho trovato, insieme al manuale in quattordici lingue e al foglietto con le istruzioni per il primo lavaggio, un adesivo con un qr code e la scritta: “scarica l’app per un’esperienza completa”. Un’esperienza completa. Per lavare i panni. Ho scaricato l’app. Per curiosità professionale, mi sono detto. Perché lavoro con la tecnologia e volevo capire. In realtà perché sono debole, come tutti, e quando qualcosa mi dice “scarica l’app” io scarico l’app. È un riflesso condizionato. Siamo tutti cani di pavlov con un id apple. L’app mi ha chiesto di creare un account. Nome, cognome, email, password con almeno una maiuscola, un numero, un carattere speciale e, probabilmente, il nome del tuo primo animale domestico. Poi mi ha chiesto di accettare i termini di servizio. Ventitré pagine che nessun essere umano nella storia dell’umanità ha mai letto, compreso l’avvocato che le ha scritte. Poi mi ha chiesto di connettere la lavatrice al wifi. Poi mi ha chiesto l’accesso alla posizione del telefono. Poi mi ha chiesto di abilitare le notifiche. Ho accettato tutto. Come tutti. Perché l’alternativa era premere “rifiuta” e usare la lavatrice come una lavatrice, il che apparentemente nel 2026 è un atto di resistenza civile. ## Cosa sa la mia lavatrice {: #cosa-sa-la-mia-lavatrice } Adesso la mia lavatrice è connessa. È online. Ha un indirizzo ip. È, tecnicamente, un nodo della rete globale, alla pari di un server di google o del sito del pentagono. La mia lavatrice e il pentagono condividono un’infrastruttura. Questo pensiero mi tiene sveglio la notte. Cosa fa la mia lavatrice con questa connessione? L’app me lo mostra con orgoglio. Può dirmi quanto dura il ciclo in corso. Può mandarmi una notifica quando il lavaggio finisce, informazione che prima ricavavo da un suono rivoluzionario chiamato “bip”. Può mostrarmi statistiche sui miei consumi idrici mensili sotto forma di grafico a torta. Può suggerirmi il programma ottimale in base al tipo di tessuto, cosa che mia nonna faceva a occhio nel 1974 con risultati migliori. In cambio di questi servizi straordinari, la mia lavatrice sa a che ora faccio il bucato, quante volte a settimana, che programmi uso, quanto detersivo consumo, se lavo di più il lunedì o il giovedì, e a che temperatura preferisco lavare le lenzuola. Sa che il sabato mattina faccio un lavaggio lungo e il mercoledì sera uno rapido. Sa che a gennaio lavo più pile e a luglio più cotone. Sa cose di me che io non sapevo di me. E questi dati vanno dove? A chi? Per fare cosa? Non lo so. Era scritto nelle ventitré pagine. Che non ho letto. Come tutti. ## L’internet delle cose inutili {: #linternet-delle-cose-inutili } La mia lavatrice non è sola. È parte di un esercito. Il frigorifero del mio vicino ha una telecamera interna che ti mostra cosa c’è dentro quando sei al supermercato. Idea affascinante, se non fosse che per sapere se hai finito il latte potresti anche, e sto per dire una cosa radicale, aprire il frigorifero prima di uscire. Lo spazzolino elettrico di mia cognata ha il bluetooth e un’app che le dice se spazzola abbastanza a lungo il quadrante superiore destro. Lo spazzolino la giudica. Lo spazzolino le dà un punteggio. Mia cognata ha l’ansia da prestazione dell’igiene orale. Il termostato connesso ti permette di accendere il riscaldamento dal telefono quando sei ancora in ufficio. Comodo, finché il server dell’azienda che lo produce va giù e ti ritrovi a febbraio con un termostato che non funziona perché il cloud ha il singhiozzo. Un termostato che dipende dal cloud. Rilasciate questa frase nel mondo e lasciatela agire. La bilancia smart manda il tuo peso a un’app che lo condivide col tuo profilo fitness che lo incrocia con i dati del tuo orologio che lo correla col tuo sonno. Tutta questa ingegneria per dirti una cosa che la bilancia analogica di tuo nonno ti diceva già: hai mangiato troppo a natale. Nessuno ha chiesto queste cose. Non c’è stato un referendum. Non c’è stata un’indagine di mercato in cui i cittadini hanno dichiarato: sapete cosa ci manca? Che il tostapane parli col router. Eppure eccoci, circondati da oggetti che raccolgono dati su di noi in cambio di funzionalità che non ci servono. ## Intelligente per chi {: #intelligente-per-chi } Fermiamoci un momento sulla parola “smart”. Smart tv. Smart speaker. Smart lock. Smart fridge. Smart toothbrush. Smart washing machine. Tutto è smart. La domanda che nessuno fa è: intelligente per chi? Non per me. Io non ho bisogno che la lavatrice mi mandi una notifica. Sento il bip dall’altra stanza. Ci ho messo quarantacinque anni a sviluppare questa tecnologia, si chiama “orecchie”, e funziona benissimo anche in modalità offline. Non per mia madre. Mia madre non ha l’app. Non ha il wifi vicino alla lavatrice. Non vuole un account. Vuole premere un bottone e trovare i panni puliti. Smart, per mia madre, è la lavatrice che fa il suo lavoro senza chiedere niente in cambio. Smart è per chi raccoglie i dati. Per il produttore che adesso sa come milioni di persone usano le sue lavatrici e può vendere questa informazione. Per l’azienda di detersivi che potrebbe, un giorno, pagare per apparire come “detersivo consigliato” nell’app della tua lavatrice. Sì, le pubblicità nel bucato, ci arriveremo. Per l’assicurazione che potrebbe incrociare i dati del tuo consumo domestico con quelli del tuo profilo di rischio. Per chiunque tranne te. L’internet of things non è stato progettato per rendere la tua vita più comoda. È stato progettato per rendere la tua vita più leggibile. Ogni oggetto connesso è un sensore puntato verso di te, che trasforma le tue abitudini in dati e i tuoi dati in valore, per qualcun altro. ## Il prezzo del bip {: #il-prezzo-del-bip } C’è un aspetto di questa storia che mi inquieta più degli altri, e non è la privacy. È la dipendenza. Un termostato non connesso funziona per vent’anni. Lo attacchi al muro, imposti la temperatura, te ne dimentichi. Non ha bisogno di aggiornamenti firmware. Non ha bisogno che l’azienda che lo ha prodotto continui a esistere. Non smette di funzionare perché qualcuno ha deciso di dismettere un server. Un termostato smart funziona finché il produttore decide che funziona. Quando il modello diventa vecchio, l’app non viene più aggiornata. Quando l’app non viene più aggiornata, il sistema operativo del telefono la rende incompatibile. Quando l’azienda chiude, il server chiude con lei, e il tuo termostato diventa un rettangolo di plastica appeso al muro. Si chiama obsolescenza come servizio. Non è un bug, è il modello di business. Ogni oggetto che dipende da un cloud è un oggetto in affitto. Non lo possiedi. Lo usi finché qualcun altro te lo permette. E il giorno in cui smette di funzionare, non puoi aggiustarlo. Puoi solo ricomprarlo. Mia nonna aveva una lavatrice che è durata ventiquattro anni. Quando si rompeva, veniva il tecnico, cambiava un pezzo, e ripartiva. La mia lavatrice smart probabilmente durerà lo stesso, ma l’app che la controlla no. Tra cinque anni quell’app sarà un reperto archeologico. E io avrò una lavatrice perfettamente funzionante a cui manca il cervello. ## Il bottone {: #il-bottone } Sapete qual è la parte più bella della mia lavatrice? Il bottone. Quello fisico. Quello rotondo, di plastica, che gira e fa click. Quello che non ha bisogno del wifi, non ha bisogno dell’app, non ha bisogno della mia email, non ha bisogno di sapere dove mi trovo. Quello che quando lo premi fa esattamente una cosa: avvia il lavaggio. Nessun account. Nessun termine di servizio. Nessun dato che viaggia verso un server di cui non conosco la posizione. Solo un gesto meccanico, un click, e l’acqua che parte. Il bottone è la tecnologia più avanzata della mia lavatrice. Perché il bottone ha capito una cosa che l’internet of things non ha ancora capito: che la vera intelligenza di un oggetto sta nel fare bene una cosa sola senza chiedere niente in cambio. Ho disinstallato l’app. Uso il bottone. I panni vengono puliti lo stesso. Anzi, forse un po’ meglio. Perché adesso non li lavo più col senso di colpa di chi non ha letto ventitré pagine di termini di servizio. --- # Quarantacinque e il confine tra due mondi - **URL:** https://margiovanni.it/it/blog/quarantacinque-e-il-confine-tra-due-mondi/ - **Pubblicato:** 2026-02-24 - **Tag:** Carriera, Generazioni, Intelligenza Artificiale, Tecnologia - **Tempo di lettura:** 7 min > Dal modem 28.8 all’ai in 11 secondi: cosa significa avere 45 anni nella tech, con memoria analogica e futuro digitale che corre. Mi ricordo ancora il primo sito web che ho visto. Era il 1996, avevo sedici anni, e lo schermo era uno di quei tubi catodici color crema che col tempo diventavano gialli, come se il sole li avesse masticati piano. Il modem era un Hamlet da 28.8 che occupava mezza scrivania e faceva un rumore che oggi, se lo sentissi in salotto, penseresti davvero a un corto circuito. La pagina ci mise quaranta secondi a caricarsi. Quaranta secondi veri, non quelli che oggi chiamiamo “un attimo” mentre già stiamo aprendo un’altra tab. Era grigia, testo blu sottolineato, e poi un tramonto che si materializzava riga per riga dall’alto verso il basso, come una polaroid digitale che non aveva fretta. Non avevo idea di cosa stessi guardando. Sapevo solo che era la cosa più bella che avessi mai visto. Ieri, invece, ho chiesto a un’intelligenza artificiale di analizzare un contratto di sessanta pagine e propormi le clausole critiche. Ha finito in undici secondi. Tra quei due momenti ci sono ventinove anni, un’intera carriera, e un cambio di paesaggio così grande che ogni tanto mi fermo e mi chiedo come sia possibile che la stessa persona abbia vissuto entrambe le cose. Ho quarantacinque anni. Sono nato nel 1980. E ho la sensazione di appartenere a una generazione senza un nome davvero comodo, senza un manifesto, senza un’estetica riconoscibile. Però con una caratteristica che, almeno per me, pesa parecchio: abbiamo attraversato il cambiamento tecnologico più grande nella storia dell’umanità con la piena coscienza di entrambi i lati. ## I figli del confine {: #i-figli-del-confine } Siamo nati analogici e stiamo invecchiando in un mondo digitale che, in parte, abbiamo contribuito a costruire. E forse è questo che rende tutto un po’ strano. Non siamo abbastanza giovani da essere “il futuro”, e non siamo abbastanza vecchi da essere “la memoria”. Stiamo nel mezzo, che è un posto poco fotogenico. Eppure è un punto di osservazione incredibile. Abbiamo imparato a scrivere a mano prima che a digitare. Abbiamo usato le enciclopedie di carta prima di Google. Abbiamo telefonato con il disco combinatorio prima del cellulare, e col cellulare prima dello smartphone. Abbiamo comprato cd, poi scaricato mp3 da Napster, poi pagato Spotify. Abbiamo spedito lettere, poi email, poi messaggi, poi vocali. Ogni passaggio l’abbiamo vissuto in tempo reale, con lo stupore di chi vede qualcosa apparire per la prima volta e la consapevolezza di chi sa cosa sta sostituendo. Questa doppia consapevolezza, secondo me, è il nostro tratto distintivo. I nativi digitali non sanno cosa hanno perso, perché non l’hanno mai avuto. I pre-digitali non sanno cosa hanno guadagnato, perché spesso non l’hanno mai usato davvero. Noi sappiamo entrambe le cose. E questo ci rende, a seconda delle giornate, i più lucidi o i più malinconici nella stanza. ## La generazione sandwich {: #la-generazione-sandwich } A quarantacinque anni sei in una posizione strana anche sul lavoro. In azienda, sei il senior. Quello che ha visto abbastanza da riconoscere i pattern, da sapere che il framework rivoluzionario di quest’anno rischia di diventare il legacy di dopodomani. Quello che i junior guardano come si guarda un monumento: con rispetto, ma anche con quell’idea inconfessabile che forse tu sia già un po’ fuori dal tempo. Eppure non sei “il maestro”. Non hai sessant’anni e quaranta di carriera. Non hai attraversato tutte le guerre. Non hai la patina dell’autorità che arriva solo col tempo puro. Sei in mezzo. Troppo esperto per essere ignorato, troppo giovane per essere un riferimento generazionale. E nel frattempo il mondo accelera in una direzione che non hai scelto. L’ai generativa è arrivata e ha rimescolato le carte in un modo che, se ci penso bene, nessuno aveva previsto così, due anni fa. I ventenni la usano come usano l’aria, senza pensarci. I sessantenni la guardano con diffidenza o la ignorano. E tu sei lì, nel mezzo, che la usi ogni giorno perché sai che è potente, ma la guardi con l’occhio di chi ha già visto abbastanza rivoluzioni da sapere che nessuna è mai pulita come promette. Il cloud doveva risolvere tutto. DevOps doveva risolvere tutto. Agile doveva risolvere tutto. Blockchain doveva risolvere tutto. Ogni volta qualcosa si è risolto, certo. E ogni volta si sono creati nuovi problemi, nuove dipendenze, nuove ansie. A quarantacinque anni ti resta addosso questa capacità un po’ rara: entusiasmarti senza ubriacarti. Adottare senza adorare. Usare lo strumento senza diventare lo strumento. Non so se è saggezza. Forse è solo stanchezza travestita da esperienza. Però è quello che ho, e a volte è l’unica cosa che serve nella stanza. ## Il corpo che ricorda {: #il-corpo-che-ricorda } C’è un aspetto di cui si parla poco, e che invece a me sembra sempre più centrale: il corpo. A quarantacinque anni il corpo comincia a presentarti il conto di vent’anni passati davanti a uno schermo. La schiena. Il tunnel carpale che va e viene. Gli occhi che la sera non mettono più a fuoco come prima. Il sonno che non è più quello di quando avevi trent’anni e potevi stare sveglio fino alle tre a debuggare e poi alle nove essere in ufficio come se niente fosse. Ma il corpo ricorda anche com’era il mondo prima. Le mie mani ricordano il peso di un’enciclopedia. Le mie orecchie ricordano il rumore del modem. I miei occhi ricordano lo schermo che si accendeva lentamente, e l’attesa che era parte dell’esperienza, non un difetto da eliminare. Ricordo la noia dei pomeriggi senza internet. E ricordo che in quella noia nascevano idee, curiosità, tempo per pensare. Non sto idealizzando il passato. Era anche più lento, più limitato, più ingiusto in mille modi. Però averlo vissuto mi dà un metro di paragone che chi è nato nel 2000 non ha. Quando qualcuno mi dice che l’ai cambierà tutto, io ci credo. Ma so anche che “tutto” non cambia mai davvero come immaginiamo, perché le persone restano persone. E le persone sono più lente dei loro strumenti. ## Quello che si vede da qui {: #quello-che-si-vede-da-qui } A quarantacinque anni cominci a guardare il tempo in modo diverso. Non è più una riserva infinita. È una risorsa, e come tutte le risorse ha un vincolo. Questa cosa, lentamente, cambia il modo in cui lavori, in cui scegli i progetti, in cui decidi dove mettere l’energia. A venticinque anni dicevi sì a tutto. A trentacinque dicevi sì alle cose interessanti. A quarantacinque dici sì alle cose che contano. La differenza non è nella parola. È nel filtro. E il filtro è fatto di tutte le volte che hai detto sì a qualcosa che non contava e poi hai pagato il prezzo in tempo, in energia, in opportunità perse altrove. Cominci a capire che la cosa più importante non è quanti progetti porti avanti, ma quanti ne rifiuti. Non è quante tecnologie conosci, ma quante hai il coraggio di non adottare. Non è quante ore lavori, ma cosa fai in quelle ore. E ti rendi conto, con un misto di sollievo e vertigine, che metà delle cose per cui ti sei ammazzato non erano importanti. E le poche che lo erano, forse, le avresti potute fare in un terzo del tempo se avessi avuto il coraggio di eliminare il resto. Il punto è che questa lucidità la puoi avere solo adesso. Non potevi averla a trenta. E forse non la potresti nemmeno spiegare a qualcuno di trenta. È quel tipo di conoscenza che si acquisisce solo vivendola. Quindi è preziosa, ma anche un po’ intrasferibile. Puoi scrivere un articolo, puoi fare un talk, puoi dare un consiglio. Chi lo riceve capirà davvero solo tra quindici anni, quando si guarderà indietro e dirà: aveva ragione. ## Metà {: #meta } Quarantacinque è la metà, se sei ottimista. È più della metà, se sei realista. In entrambi i casi, è il punto in cui il futuro smette di essere più grande del passato. E questa consapevolezza, almeno per me, non è deprimente. È chiarificatrice. A questo punto puoi fare due cose. Puoi aggrapparti a quello che sai, blindare le tue competenze, difendere il tuo territorio. Diventare quello che spiega ai giovani come si facevano le cose una volta, con un misto di nostalgia e risentimento. Ce ne sono tanti, nella tech italiana. Li riconosci perché iniziano le frasi con “ai miei tempi” e le finiscono con un sospiro. Oppure puoi fare l’altra cosa. Puoi prendere tutto quello che sai, il modem, il primo sito web, il primo deploy andato male, il primo cliente perso, il primo team gestito, la prima notte in bianco, la prima volta che hai detto “non lo so” e il mondo non è crollato, e usarlo come lente per guardare quello che viene. Non con la presunzione di chi sa già come andrà. Piuttosto con la calma di chi ha visto abbastanza da non farsi prendere dal panico. Io ho scelto la seconda. Non perché sia più nobile, forse. Ma perché la prima mi sembra una forma lenta di resa, e a quarantacinque anni non ho abbastanza tempo per arrendermi. Quel tramonto che si caricava riga per riga sullo schermo ingiallito era brutto. Sgranato, con colori sbagliati, metà pixel mancanti. Però conteneva una promessa enorme: che il mondo stava per cambiare, e che io ero abbastanza giovane per farne parte. Ventinove anni dopo, il mondo sta cambiando di nuovo. E io sono ancora abbastanza giovane per farne parte. Credo. --- # Il lusso di dire non lo so - **URL:** https://margiovanni.it/it/blog/il-lusso-di-dire-non-lo-so/ - **Pubblicato:** 2026-02-23 - **Tag:** Comunicazione, Consulenza, Intelligenza Artificiale, Lavoro - **Tempo di lettura:** 7 min > Dire “non lo so” sembra una debolezza, ma spesso è il gesto più competente. Una storia di consulenza, ai e del valore della pausa prima di rispondere. Qualche mese fa, durante una call con un potenziale cliente, mi è arrivata addosso una domanda secca, di quelle che sembrano innocue solo finché non devi rispondere. “Secondo voi, questo progetto in quanto tempo si chiude?” Avevo tutto quello che serve per improvvisare una risposta credibile. Anni di esperienza, progetti simili alle spalle, una stima “di pancia” che poteva suonare ragionevole. Sei mesi, forse otto, con un margine prudenziale. Detto con il tono giusto avrebbe fatto la sua figura: competente, rassicurante, da gente che sa il fatto suo. Invece mi è uscito altro. “Non lo so. Non ancora. Dateci due settimane per analizzare il contesto e ve lo diciamo con un numero di cui ci fidiamo anche noi.” In call è calato un silenzio strano. Tre secondi, che in una conversazione commerciale diventano un tempo lunghissimo. Poi il CEO dall’altra parte ha detto una cosa che mi ha spiazzato. “Finalmente qualcuno che non mi spara un numero a caso.” Abbiamo vinto quel progetto. Non *nonostante* quel “non lo so”. Probabilmente *grazie* a quel “non lo so”. ## L’epoca delle risposte istantanee {: #lepoca-delle-risposte-istantanee } Mi chiedo spesso quando abbiamo deciso che la velocità della risposta fosse una prova di intelligenza. O di competenza. O di autorevolezza. Oggi una risposta è sempre disponibile. Su qualunque cosa, in qualunque momento, in meno tempo di quello che serve a formulare bene la domanda. Cerchi su Google e in una frazione di secondo hai risultati a perdita d’occhio. Chiedi a un modello linguistico e ti arriva un testo fluido, ben scritto, persino convincente. E così, senza accorgercene, abbiamo interiorizzato un’equazione un po’ tossica: chi risponde subito sa. Chi esita non sa. Chi dice “non lo so” è fuori gioco. Lo vedi nelle riunioni, dove chi parla per primo spesso “prende” la stanza. Lo vedi nei colloqui di lavoro, dove l’esitazione viene letta come impreparazione, anche quando è solo prudenza. Lo vedi nella consulenza, dove “ci devo pensare” sembra una perdita di valore, come se il cliente stesse pagando per avere certezze pronte in tasca. E poi lo vedi nell’AI, che è forse l’incarnazione più perfetta di questo meccanismo. Un modello linguistico non è progettato per fermarsi e dire “non lo so”. È progettato per produrre una risposta. Strutturata, plausibile, magari brillante. Anche quando non sa. A volte *soprattutto* quando non sa. Le allucinazioni non sono un incidente folkloristico, sono la conseguenza naturale di un sistema addestrato a riempire sempre il vuoto. Abbiamo costruito una macchina perfetta per un’epoca che ha deciso che il silenzio è un difetto. ## Il costo della certezza finta {: #il-costo-della-certezza-finta } La domanda interessante, però, non è perché l’AI non sappia dire “non lo so”. È perché facciamo così fatica a dirlo noi. Ho passato vent’anni tra tecnologia e consulenza. Riunioni, call, presentazioni, workshop. Se ripenso alle volte in cui qualcuno ha detto apertamente “non lo so” senza che sembrasse una confessione di colpa, me ne vengono in mente pochissime. La regola non scritta è chiara: devi avere una risposta. Meglio sbagliata che assente. Il problema è che questa norma ha un costo enorme, solo che è difficile da vedere mentre succede. Si vede dopo, quando un progetto stimato in tre mesi ne dura dodici, e a un certo punto qualcuno dice sottovoce: “in realtà non avevamo abbastanza informazioni per stimare”. Si vede quando si sceglie un’architettura perché in meeting qualcuno ha parlato con grande sicurezza, e la versione onesta sarebbe stata: “facciamo un proof of concept prima di decidere”. Si vede quando un contratto nasce già storto, perché la timeline era stata promessa prima ancora di capire cosa c’era davvero sotto. Ho visto prodotti fallire non perché mancasse competenza, ma perché mancava il coraggio di ammettere un’incertezza. E la parte più amara è che spesso chi finge di sapere viene premiato. La certezza, anche quella fasulla, è rassicurante. Dà l’illusione del controllo. E chi la offre viene percepito come un leader. È un sistema di incentivi un po’ rovesciato: premia la velocità sulla verità, la sicurezza sull’onestà, l’apparenza sulla sostanza. ## Tre parole pericolose {: #tre-parole-pericolose } “Non lo so” sono tre parole pericolose perché rompono una dinamica di potere. In una riunione con un cliente, dire “non lo so” significa ammettere che tu, l’esperto, quello che viene pagato per sapere, in quel momento non sai. È come se incrinassi il patto implicito della consulenza, dove il cliente compra certezze e tu le vendi. Dentro un team, se sei responsabile, dire “non lo so” è ancora più controintuitivo. Perché ci hanno insegnato che guidare significa avere la direzione, avere la risposta, avere il piano. E nessuno vuole seguire qualcuno che ammette di non conoscere la strada. Eppure, se ripenso alle decisioni migliori che ho preso, c’è quasi sempre un “non lo so” all’inizio. Non perché l’ignoranza sia una virtù. Non lo è. È perché “non lo so” è spesso l’unico punto di partenza onesto per una decisione seria. È il momento in cui smetti di performare e inizi a ragionare. È il passaggio dalla risposta preconfezionata alla domanda vera. Quando qualcuno dice “non lo so”, succedono cose curiose. L’aria si alleggerisce, come se diventasse improvvisamente permesso non sapere. Qualcuno trova il coraggio di dire “anche io ho un dubbio”. Spunta un’informazione che era rimasta nascosta perché nessuno voleva sembrare quello che rallenta. Forse è questo il punto che mi interessa di più: “non lo so” non è l’opposto della competenza. È spesso il suo prerequisito. ## Il paradosso dell’AI {: #il-paradosso-dellai } Qui arriva il paradosso. L’AI rende ancora più difficile dire “non lo so”. Perché se una macchina produce una risposta su qualsiasi argomento in due secondi, come giustifichi che tu, professionista con anni di esperienza, non ne abbia una pronta? Il benchmark si sposta. La velocità della macchina diventa lo standard con cui misuriamo la velocità umana. E in questa corsa, fermarsi a pensare diventa un lusso. Solo che è un benchmark sbagliato, fondato su un equivoco: confondere l’avere *una* risposta con l’avere *la* risposta giusta. L’AI ha sempre una risposta. Spesso è buona. A volte è ottima. Ma non sa quando non sa. E questa, paradossalmente, è una delle competenze più preziose che abbiamo noi: riconoscere che manca un pezzo, sentire che qualcosa non torna, intuire che la variabile ignorata è proprio quella che cambia tutto. Socrate ci aveva costruito sopra un’intera filosofia: sapere di non sapere come base per conoscere davvero. Duemilacinquecento anni dopo, abbiamo macchine che non sanno di non sapere, e le usiamo come modello di efficienza cognitiva. Se ci penso, c’è un’ironia quasi perfetta. ## Un vantaggio competitivo silenzioso {: #un-vantaggio-competitivo-silenzioso } La mia esperienza è quella che è, limitata e piena di bias, come tutte le esperienze. Però mi ha lasciato una convinzione abbastanza stabile: le persone e le aziende che sanno dire “non lo so” al momento giusto vincono nel lungo periodo. I clienti con cui lavoro da più tempo sono spesso quelli con cui, all’inizio, ho ammesso di non avere tutte le risposte. Non perché apprezzassero l’incompetenza, ma perché quel gesto creava un tipo di relazione diverso. Una relazione dove era permesso esplorare, fare domande, cambiare idea. Dove la soluzione non doveva essere già pronta alla slide tre. Le persone migliori con cui ho lavorato sono quelle che in mezzo a una riunione piena di acronimi hanno detto “non capisco” o “mi spieghi meglio?”. La famosa domanda “stupida” che tutti hanno in testa e nessuno fa. Quasi sempre è quella che sblocca tutto. E le decisioni migliori, quelle che a distanza di anni si sono rivelate giuste, hanno avuto un momento di sospensione prima di diventare un “sì” o un “no”. Un piccolo spazio di dubbio legittimo. Un rifiuto di rispondere solo per togliersi la pressione di dosso. Non è un metodo. Non è un framework. Non è una slide sulla vulnerabilità. È qualcosa di più semplice e più difficile: accettare che la competenza include il riconoscimento dei propri limiti, e che quei limiti non sono una vergogna. Sono il confine esatto dove il pensiero vero comincia. ## L’ultima parola {: #lultima-parola } Viviamo in un’epoca che ci chiede risposte immediate su tutto. Algoritmi che rispondono in millisecondi, colleghi che si aspettano risposte in minuti, clienti che le vogliono in ore. In questo rumore costante di certezze a buon mercato, dire “non lo so” diventa quasi un atto sovversivo. Una piccola resistenza contro un sistema che scambia la velocità per la verità e la sicurezza per la competenza. Non sto facendo l’elogio dell’ignoranza. Sto facendo l’elogio della pausa. Di quel momento scomodo tra la domanda e la risposta in cui, se resisti alla tentazione di riempirlo con la prima cosa che ti viene in mente, succede qualcosa di raro. Pensi davvero. --- # Quello che l'AI non sa del mio mestiere - **URL:** https://margiovanni.it/it/blog/quello-che-lai-non-sa-del-mio-mestiere/ - **Pubblicato:** 2026-02-22 - **Tag:** Consulenza Ict, Intelligenza Artificiale, Lavoro, Leadership - **Tempo di lettura:** 8 min > Ho chiesto a un modello di scrivere una proposta perfetta. L’ho cancellata: mancava la cosa più importante, quella che non è scritta da nessuna parte. La settimana scorsa ho chiesto a Claude di scrivermi una proposta tecnica per un cliente. Ha prodotto un documento impeccabile in quaranta secondi. Architettura pulita, stima dei costi su tre ambienti, timeline con milestone, analisi dei rischi. Formattazione perfetta. Linguaggio professionale. Ho buttato via tutto. Non perché fosse sbagliato. Era tecnicamente corretto, anzi, probabilmente migliore di quello che avrei scritto io di getto. L’ho buttato via perché quel cliente, tre mesi prima, ci aveva detto in una call che il suo cto era stato licenziato dopo un progetto fallito con un approccio simile a quello proposto. Non lo trovi in nessun dataset. Non c’è in nessun prompt. È una cicatrice organizzativa che vive nella memoria di chi c’era a quella call, e che cambia tutto: il tono della proposta, la scelta della soluzione, persino le parole da usare e quelle da evitare. L’AI aveva prodotto la risposta giusta alla domanda sbagliata. È una cosa che fa benissimo. ## Il lavoro invisibile {: #il-lavoro-invisibile } Faccio i lead in una società volutamente di piccole dimensioni. Il mio lavoro, sulla carta, è prendere decisioni: quale prodotto costruire, per chi, con quali priorità, entro quando. Se guardassi la mia job description, un modello linguistico potrebbe fare il novanta percento di quello che faccio. Forse di più. Ma la job description è una bugia. Come tutte le job description. Il mio lavoro vero è fatto di cose che non stanno in nessun backlog e in nessun documento di progetto. È fatto di silenzi durante le call, quel momento in cui un cliente dice “sì, va bene” con un tono che significa “no, non va bene per niente, ma non ho voglia di discutere adesso”. È fatto di pranzi con un collega che non rende da due settimane e che, al secondo caffè, ti dice che sta attraversando un momento difficile a casa. È fatto della decisione, presa alle undici di sera, di non rispondere a un’email provocatoria di uno stakeholder e aspettare il mattino dopo, quando le parole pesano meno. Niente di tutto questo è computabile. E non credo sia solo un problema di contesto mancante che si risolve con un prompt più lungo o con un rag più sofisticato. **È un tipo di conoscenza diverso. È situato, relazionale, quasi corporeo.** Sai che un meeting sta andando male perché senti la tensione nella stanza. Sai che una stima è gonfiata perché conosci chi l’ha fatta. Sai che un requisito va rifiutato non per ragioni tecniche, ma perché accettarlo sposterà il prodotto in una direzione dalla quale non si torna indietro. E lo sai perché sei già stato in quella direzione tre progetti fa, con un altro cliente, e hai le cicatrici per dimostrarlo. L’AI lavora su quello che è esplicito. Il mio mestiere vive in quello che è implicito. ## Quattro cose che non riesco a delegare {: #quattro-cose-che-non-riesco-a-delegare } Ho provato a fare un esercizio, un po’ per curiosità e un po’ per paura: identificare le parti del mio lavoro che un modello linguistico, per quanto avanzato, non riesce a fare. Non le parti che non fa *ancora*. Quelle che, per come è fatto, probabilmente non può fare. O almeno non nello stesso modo. Ne ho trovate quattro. ### La prima è leggere le persone Non intendo assegnare task o fare performance review. Quello lo può fare un foglio Excel, e spesso lo fa pure meglio. Intendo la parte vera. Capire che un collega che improvvisamente produce lavoro sciatto non ha un problema di competenza, ma un problema di motivazione. E che quel problema di motivazione nasce dal fatto che negli ultimi tre sprint lo hai messo su attività che considerava sotto il suo livello. E che non te l’ha detto perché ha paura di sembrare arrogante. E che tu lo sai perché lo conosci da quattro anni e sai come reagisce quando si sente sottovalutato. Questa catena causale non è scritta da nessuna parte. Metà degli anelli non sono mai stati verbalizzati. Esistono nello spazio tra due persone che lavorano insieme abbastanza a lungo da capirsi senza parlare. Gestire un team non è ottimizzare risorse. È navigare le complessità emotive di un gruppo di esseri umani che passano insieme più tempo di quanto ne passino con le loro famiglie. E farlo senza manuali, senza metriche, spesso senza nemmeno rendertene conto. ### La seconda è capire cosa vuole davvero un cliente Non quello che dice di volere. Quello che vuole davvero. Sono due cose quasi sempre diverse. Un cliente che ti chiede un gestionale documentale spesso non vuole un gestionale documentale. Vuole che il suo capo smetta di chiedergli dove sono i file. Un cliente che ti chiede un’app mobile vuole dimostrare al board che la sua divisione innova. Un cliente della pubblica amministrazione che mette a bando una piattaforma digitale spesso ha bisogno di qualcosa di molto più semplice, ma il bando è stato scritto copiando quello di un altro comune che aveva esigenze completamente diverse. Il mio lavoro è scavare sotto la richiesta fino a trovare il bisogno. **E il bisogno è quasi sempre politico, organizzativo, emotivo. Raramente tecnico.** Ci arrivi facendo domande che non c’entrano niente con la tecnologia. Chi userà questo sistema? Chi ha deciso che serviva? Cosa succede se non lo facciamo? Chi ci guadagna e chi ci perde? Sono domande che un’AI non sa fare perché non sa se e quando vanno fatte. Forse è questa la parte che mi inquieta di più. Non è che la macchina risponda male. È che risponde bene a una domanda che magari nessuno avrebbe dovuto porre in quel modo. ### La terza è dare peso al contesto che non c’è scritto da nessuna parte Ogni prodotto ha una storia. Non quella scritta nella documentazione, che è la versione ufficiale. La storia vera è fatta di compromessi accettati perché il budget era finito, di feature aggiunte per accontentare uno stakeholder che poi ha cambiato ruolo, di scelte che erano sbagliate ma che ormai sono così intrecciate con i processi del cliente che rimuoverle costerebbe più che conviverci. Quando devo decidere se la prossima release deve riscrivere un modulo o aggiungere una funzionalità, non posso chiedere a un modello. Perché la risposta giusta dipende da chi usa quel modulo, come lo usa, cosa stava succedendo nel progetto quando è stato costruito, qual è la relazione attuale con il cliente, e se quel cliente tra tre mesi avrà ancora il budget per la fase due. Un’AI può dirti qual è la roadmap ideale in assoluto. Un product leader sa qual è la roadmap giusta *per quel prodotto, con quel team, per quel cliente, in questo momento*. La differenza tra le due cose è la differenza tra un libro di ricette e un cuoco. ### La quarta è dire no È la più importante e la meno tecnica di tutte. Dire no a una feature che sembra ragionevole ma che porterà il prodotto in un vicolo cieco. Dire no a un cliente che vuole una timeline impossibile, sapendo che perderai la gara. Dire no a uno stakeholder che spinge per un pivot affascinante ma che distruggerebbe il valore costruito in due anni. Dire no a te stesso quando l’entusiasmo per un’idea nuova ti sta facendo perdere di vista che i tuoi utenti hanno bisogno di qualcosa che funzioni, non di qualcosa di innovativo. **Il no è un atto di giudizio che richiede coraggio, contesto e responsabilità.** L’AI non dice mai no. Non può permetterselo. Il suo design è ottimizzato per essere utile, per dare risposte, per risolvere. Ma a volte la cosa più utile è fermarsi. A volte la risposta migliore è “non lo facciamo”. E nessun prompt al mondo può insegnare a un modello quando quel momento è arrivato, perché riconoscerlo richiede qualcosa che nessun training set contiene: *il peso delle conseguenze sulle proprie spalle*. ## Il paradosso dell’amplificazione {: #il-paradosso-dellamplificazione } Sia chiaro, non sto dicendo che l’AI è inutile. Sarebbe disonesto, oltre che stupido. La uso ogni giorno. Il mio team la usa per produrre, documentare, analizzare. Risparmiamo ore, giorni, settimane, mesi. La qualità dei deliverable è salita. Non tornerei indietro. Però c’è un paradosso che vedo emergere e che mi preoccupa. **Più l’AI si occupa delle parti “producibili” del mestiere, quindi documenti, analisi, specifiche, codice, più il valore si concentra nelle parti “imponderabili”: le decisioni, le relazioni, i no.** E queste sono esattamente le parti che non si imparano leggendo documentazione o facendo corsi. Si imparano sbagliando, osservando, stando in una stanza con altre persone per anni. Il rischio, mi chiedo, è che una generazione di professionisti cresca delegando le parti eseguibili senza mai attraversare la fase in cui quelle parti ti insegnano il mestiere. Scrivere una proposta sbagliata, gestire una demo che va in pezzi davanti al cliente, perdere un contratto perché hai sottovalutato un requisito non è solo sofferenza formativa. È il processo attraverso cui sviluppi l’intuizione che poi ti permette di prendere le decisioni che l’AI non può prendere. Se salti quel passaggio, arrivi al tavolo della negoziazione senza aver mai sentito il peso di una scelta sbagliata. E, a quel tavolo, l’AI non ti può aiutare. ## Il mestiere che resta {: #il-mestiere-che-resta } Il mio mestiere sta cambiando. Non sta scomparendo, sta cambiando forma. Il tempo che passavo a produrre deliverable lo passo a ragionare su cosa quei deliverable dovrebbero dire. Il tempo che passavo a cercare informazioni lo passo a decidere cosa farne. Il tempo che spendevo sulle parti ripetitive lo passo a parlare con le persone, colleghi, clienti, utenti. È uno spostamento verso l’alto nella catena del valore, e per certi versi è una liberazione. Ma porta con sé una responsabilità nuova, che forse è anche una responsabilità vecchia vista con occhi diversi: non confondere la velocità con la competenza. Il fatto che uno strumento mi aiuti a produrre di più non significa che sappia di più. Significa che ho più tempo per applicare quello che so, o per scoprire quello che non so, se sono onesto con me stesso. L’AI sa quello che è stato scritto. Il mio mestiere è sapere quello che non è stato scritto, e spesso quello che non può essere scritto. Finché sarà così, e sospetto che sarà così per molto tempo, il mestiere resta. Cambia forma, cambia ritmo, cambia gli strumenti. Ma resta. Quello che l’AI non sa del mio mestiere è, in fondo, quello che lo rende un mestiere e non un algoritmo. --- # L'Europa dice basta: il tuo cervello non è un KPI - **URL:** https://margiovanni.it/it/blog/leuropa-dice-basta-il-tuo-cervello-non-e-un-kpi/ - **Pubblicato:** 2026-02-21 - **Tag:** Attention, Digital Services Act, Regolamentazione Digitale, Social Media - **Tempo di lettura:** 9 min > Il DSA punta l’infinite scroll di TikTok e l’“autopilota” dell’attenzione. Intanto negli USA Meta va a processo. Il design diventa politica. C’è un gesto che facciamo tutti, centinaia di volte al giorno, senza pensarci. Forse è il gesto più ripetuto della nostra epoca, più del camminare, più del bere acqua “con consapevolezza”. Il pollice che scorre verso l’alto su uno schermo. Uno scroll. Un altro. Un altro ancora. Il 6 febbraio 2026 la Commissione Europea ha fatto una cosa che, almeno per come l’ho percepita io, segna un prima e un dopo. Non ha detto “questo contenuto è vietato”. Non ha chiesto di oscurare un hashtag o di rimuovere un video. Ha messo in discussione un *pattern di interazione*. Una scelta di design. Secondo i findings preliminari sotto il Digital Services Act, l’infinite scroll di TikTok spinge gli utenti in una “autopilot mode”, alimentando comportamenti compulsivi. E quindi, dice Bruxelles, la piattaforma deve cambiare il design di base del servizio: disabilitare lo scroll infinito, introdurre pause obbligatorie, ripensare il sistema di raccomandazione. Se non lo fa, la sanzione può arrivare fino al 6% del fatturato globale annuo. Per ByteDance significa cifre che fanno tremare i polsi, nell’ordine di decine di miliardi. Due settimane dopo, dall’altra parte dell’oceano, Mark Zuckerberg è seduto in un tribunale di Los Angeles. È il primo processo con giuria sulla dipendenza da social media nella storia americana. Una donna ventenne, identificata come K.G.M., racconta di essere stata risucchiata da Instagram da bambina, e di aver sviluppato depressione e ideazione suicida. Sullo sfondo ci sono più di 1.600 cause simili in coda. I legali mostrano email interne di Meta. Una frase resta appiccicata addosso: “IG è una droga. stiamo spingendo gli utenti.” Un’altra email suggerisce che l’azienda sapesse che oltre il 30% dei bambini tra i 10 e i 12 anni usava Instagram, violando le sue stesse policy. Zuckerberg risponde che l’obiettivo sarebbe rendere il servizio “utile”, non massimizzare il tempo di permanenza. Intanto il giudice avverte il pubblico di non registrare le udienze con gli occhiali AI. Alcuni membri dell’entourage di Zuckerberg, pare, si erano presentati con i Ray-Ban Meta. Due continenti. Due approcci. Lo stesso problema. ## Il design è politica {: #il-design-e-politica } Vale la pena fermarsi su quello che è successo il 6 febbraio, perché è più radicale di quanto sembri. L’Europa non ha regolamentato un contenuto. **Ha detto che la *forma stessa* dell’interazione tra una persona e un’app può costituire un rischio sistemico.** Che un movimento del pollice, se progettato per non avere fine, non è “una tua debolezza”. È un problema della piattaforma. È, di fatto, la prima volta che un’autorità regolatoria prova a stabilire uno standard legale sul potenziale addittivo del design. Non è una legge “contro lo scroll infinito” in astratto. È un principio più grande: il design addittivo è un rischio, e lo scroll infinito è una delle sue manifestazioni più evidenti. La cosa interessante, e anche un po’ inquietante, è che il principio non si ferma a TikTok. Meta è sotto indagine dal maggio 2024 per ragioni simili. Il famoso “rabbit hole”, il tunnel in cui entri guardando un contenuto e poi l’algoritmo ti spinge verso altri sempre più simili, e a volte più estremi, è nel mirino. X ha già ricevuto una multa da 120 milioni di euro per “pratiche di design ingannevoli”. L’approccio dell’UE sembra sempre più questo: non dice solo “cosa non puoi mostrare”, ma anche “come non puoi far sentire le persone”. E per chi costruisce software, qui cambia davvero il terreno sotto i piedi. **Il codice non è mai stato neutro, lo sappiamo, ma ora diventa ufficialmente anche una questione di responsabilità legale.** La Product Liability Directive che entrerà in vigore il 9 dicembre 2026 include il software tra i prodotti. Il Cyber Resilience Act chiede sicurezza by design. L’AI Act impone valutazioni di rischio. E adesso il DSA suggerisce che anche il modo in cui organizzi un feed può diventare una violazione. Mi viene in mente un’immagine semplice: la maniglia di una porta che non ti lascia uscire. Non è un problema di chi prova a uscire. È un problema della maniglia. ## Il trimestrale contro il neurone {: #il-trimestrale-contro-il-neurone } La domanda, però, resta. Perché siamo arrivati fin qui? Perché servono tribunali e commissioni per dire una cosa che chiunque abbia un figlio, o anche solo un pollice, intuisce già? Una risposta, forse, è nei documenti interni che stanno emergendo dai processi americani. Non sembra negligenza. Sembra una scelta deliberata, ripetuta, guidata da una metrica: l’engagement. E l’engagement, alla fine, è l’anticamera del trimestrale. Da quelle carte emerge che aumentare il tempo trascorso sulle piattaforme e crescere tra i teen non era un effetto collaterale. Era un obiettivo. Email del 2015 e del 2017 discutono di come prioritizzare la crescita tra gli adolescenti. Studi interni registrano che alcuni teenager descrivevano Instagram con parole molto vicine alla dipendenza comportamentale. Eppure non ci si ferma. Si continua a misurare. Adam Mosseri, il capo di Instagram, ha testimoniato che secondo lui non si tratta di “dipendenza clinica” ma di “uso problematico”. Forse la distinzione è importante in un’aula di tribunale. Nella vita reale, mi chiedo quanto cambi. Il punto, comunque, è che sapevano. Sapevano che certi filtri facciali che simulavano la chirurgia plastica potevano avere effetti sulle adolescenti, e dopo un dibattito interno hanno scelto un “ban più mirato” invece di un divieto completo. Sapevano che i parental control erano facili da aggirare, e li hanno presentati come soluzione. Sapevano che i bambini sotto i 13 anni erano presenti a milioni, e hanno continuato a contarli come utenti. Qui entra un concetto economico che trovo utile, anche se fa un po’ paura per quanto calza. Si chiama esternalità: un costo che chi produce scarica sulla collettività senza pagarlo. L’inquinamento è l’esempio classico: la fabbrica produce, il fiume paga. Con i social abbiamo avuto per vent’anni una forma nuova di esternalità. Potremmo chiamarla, senza esagerare, **esternalità attentiva** : il costo che la società paga quando un’azienda estrae attenzione come una miniera estrae carbone, senza compensare il danno. I polmoni diventano neuroni. L’aria diventa tempo. Il fiume diventa l’infanzia di qualcuno. **E la differenza con l’inquinamento industriale, forse, è questa: qui il danno non è solo un effetto collaterale. In molti casi è stato *progettato*. Non è la scoria della produzione. È il prodotto.** ## L’autopilota e la dignità {: #lautopilota-e-la-dignita } Nei findings europei c’è un’espressione che mi è rimasta in testa: “autopilot mode”. Certe funzionalità, scrive la Commissione, spostano il cervello degli utenti in una modalità autopilota, alimentando l’impulso a continuare a scrollare. La ricerca scientifica, aggiungono, mostra che questi meccanismi possono ridurre l’autocontrollo e contribuire a comportamenti compulsivi. Autopilota è una parola strana, perché in altri contesti è quasi positiva. In aviazione ha senso: libera risorse cognitive per decisioni più importanti. In un social media, invece, toglie la risorsa cognitiva più importante che abbiamo in quel momento: la capacità di scegliere quando fermarsi. Byung-Chul Han ha descritto bene il malessere contemporaneo parlando di società della prestazione e di auto-sfruttamento. L’idea, semplificando, è che oggi non serve un padrone esterno. Ci spremiamo da soli: ottimizziamo, performiamo, consumiamo, fino al burnout. E lo smartphone è lo strumento perfetto per farlo. Però c’è un passaggio in più, che il caso TikTok sotto il DSA rende più evidente. L’auto-sfruttamento non è sempre auto-generato. A volte è *progettato* da qualcun altro e poi venduto come libertà. L’infinite scroll non è una decisione dell’utente. È una decisione di un product team, validata da un A/B test, approvata da un VP Of Growth, celebrata in una quarterly business review. L’utente non si auto-sfrutta. Viene sfruttato dentro un’architettura che simula scelta. E qui, volendo, si potrebbe anche tirare in ballo Kant, senza fare filosofia da salotto. Trattare le persone come fine, mai soltanto come mezzo. L’utente-come-kpi è l’utente-come-mezzo elevato a modello di business. Non sei una persona che usa un servizio. **Sei un’unità di attenzione da estrarre, un occhio da monetizzare, un pollice da far muovere.** Forse è per questo che quello che sta facendo l’Europa sembra, sotto sotto, una difesa della dignità. Non solo una tutela del consumatore. L’idea che abbiamo diritto a non essere manipolati, anche quando la manipolazione è elegante, ben progettata e impacchettata in un’interfaccia colorata con i bordi arrotondati. ## Due modelli di mondo {: #due-modelli-di-mondo } Il contrasto tra Bruxelles e Los Angeles racconta due filosofie diverse. Negli Stati Uniti il sistema è adversarial. Una famiglia porta un’azienda in tribunale, mostra documenti, testimoni, perizie. Una giuria decide se Instagram è stato un “fattore sostanziale” nel danno di una persona specifica. È un modello caso per caso, dove il carico della prova pesa soprattutto su chi ha subito il danno. E in quel contesto tutto diventa ambiguo. YouTube, nella stessa causa, prova a difendersi dicendo di essere più simile a Netflix che a un social. Meta dice che il problema non è l’app, è il contenuto, o forse è la vita personale della ragazza. I confini tra “danno della piattaforma” e “danno del contenuto” sono difficili da tracciare. Si litiga sulla definizione di “dipendenza”. Si rinvia. Si negozia. **In Europa l’approccio è più strutturale. Non si aspetta il danno, si regola il design.** Non si chiede alla singola persona di dimostrare che lo scroll infinito le ha rovinato la vita. Si chiede alla piattaforma di dimostrare che il suo design non è intrinsecamente rischioso. Il DSA tratta il design addittivo come un rischio sistemico, alla pari della disinformazione o delle interferenze elettorali. È un’asimmetria che riflette due idee di libertà. Negli Stati Uniti, spesso, la libertà è assenza di vincoli: sei libero di usare o non usare TikTok, e se ti fa male è un problema tuo, o del tuo avvocato. In Europa, almeno in questo impianto, la libertà include la protezione dalla manipolazione: sei libero solo se le condizioni in cui operi non sono progettate per toglierti la capacità di scegliere. Nessuno dei due modelli è perfetto. Però uno dei due, oggi, sta provando a cambiare il gioco prima che milioni di persone debbano andare in tribunale a raccontare la propria infanzia davanti a una giuria. ## La domanda per chi costruisce {: #la-domanda-per-chi-costruisce } Io faccio software. Ogni giorno si prendono decisioni di design che sembrano piccole e invece hanno un peso. Dove mettere un pulsante. Come strutturare una notifica. Quanto rendere facile o difficile uscire da un flusso. Se mostrare un counter, un badge, un pallino rosso. Non faccio social media. Lavoro su piattaforme per la pubblica amministrazione, e-learning, servizi b2b, strumenti legali. Il mio mondo è lontano mille chilometri dall’infinite scroll. Eppure il principio che l’Europa sta cercando di fissare sembra universale: il design non è neutro. Ogni scelta di interfaccia è anche una scelta etica. E adesso, volenti o nolenti, è anche una scelta con conseguenze legali. Per anni le piattaforme social hanno avuto una specie di impunità di fatto, perché la regolamentazione non teneva il passo. Quel tempo sembra finito. Il DSA, la Product Liability Directive, il Cyber Resilience Act, l’AI Act sono pezzi di un mosaico che sta ridisegnando il rapporto tra chi produce tecnologia e chi la usa. Chi la subisce, verrebbe da dire, dopo aver letto certe email interne. Alla fine, ho una convinzione che mi resta appiccicata addosso, e probabilmente si rafforza ogni volta che vedo un prodotto “crescere” grazie a un trucco cognitivo: il software che rispetta chi lo usa è software migliore. **Non perché l’Europa ce lo impone, ma perché è la cosa giusta da fare.** **E forse la cosa più radicale, oggi, è fare qualcosa di radicalmente ovvio. Costruire tecnologia che non ha bisogno che un tribunale le ordini di smettere di fare del male.** L’infinite scroll finirà, in una forma o nell’altra. La domanda vera è cosa metteremo al suo posto. Se sarà solo un altro trucco per tenerti incollato, con un nome diverso e un meccanismo appena più sottile, allora non avremo risolto niente. Se invece sarà un design che parte dalla domanda “di cosa ha bisogno questa persona?” invece che “come posso tenerla qui un altro minuto?”, allora forse il 6 febbraio 2026 sarà una data che vale la pena ricordare. Non per lo scroll che ha messo in discussione, ma per la domanda che ha reso obbligatorio porsi. --- # Segnali di un progetto di digitalizzazione destinato a fermarsi - **URL:** https://margiovanni.it/it/blog/segnali-di-un-progetto-di-digitalizzazione-destinato-a-fermarsi/ - **Pubblicato:** 2026-02-21 - **Tag:** Digitalizzazione, PMI, Product Management, Trasformazione Digitale - **Tempo di lettura:** 6 min > Cinque segnali precoci che spesso anticipano il fallimento: sponsor assente, obiettivi vaghi, decisioni confuse, stack imposto e kpi inutili. C'è una riunione che mi torna in mente ogni tanto, e non perché sia stata particolarmente drammatica. Anzi, era andata benissimo. Slide curate, parole giuste, quel tono da "stavolta facciamo sul serio". Si parlava di trasformazione, di efficienza operativa, di futuro. Tutti annuivano. Il budget era stato approvato. Tre mesi dopo, di quel progetto non c'era più traccia. Non è una storia rara. L'84% delle pmi italiane riscontra criticità nella realizzazione dei progetti digitali, e il 15,8% dichiara un fallimento completo. E a livello globale la musica è simile: circa l'84% delle iniziative di trasformazione digitale non raggiunge i risultati attesi, spesso per ragioni che con la tecnologia c'entrano poco. Il punto, però, non è solo che i progetti falliscono. È che certi progetti *nascono già morti*. I segnali ci sono dall'inizio, solo che sono discreti, quasi educati. E se non sai dove guardare, li scambi per normale complessità. ## Lo sponsor che “supporta da lontano” {: #lo-sponsor-che-supporta-da-lontano } Il primo segnale è quello che sembra meno grave. Sulla carta, il progetto ha uno sponsor importante: titolare, direttore generale, qualcuno che “ci mette la faccia”. Poi però quella faccia non la vedi mai. Lo sponsor delega, manda un’email di endorsement, magari apre il kick-off con cinque minuti di discorso motivazionale. E dopo sparisce dalle riunioni operative, da quelle dove si sbloccano i nodi veri. Il risultato è abbastanza prevedibile: appena arriva la prima resistenza interna, vince la resistenza. Non perché sia più forte, ma perché è più paziente. In molte PMI la resistenza non è nemmeno cattiveria. È routine, urgenza, “prima chiudiamo il mese”, “ne parliamo dopo la fiera”, “adesso non possiamo fermare il magazzino”. Se lo sponsor non è presente quando bisogna scegliere, il messaggio implicito è semplice: > Questo progetto può aspettare. **E le cose che possono aspettare, aspettano per sempre.** Non è solo una sensazione. Il 56% dei progetti di trasformazione digitale non riceve un supporto reale dalla leadership senior. ## Obiettivi scritti con il copia-incolla {: #obiettivi-scritti-con-il-copia-incolla } “Migliorare l’efficienza”. “Ottimizzare i processi”. “Aumentare la competitività digitale”. Quando leggo obiettivi così, mi viene sempre un dubbio: stanno descrivendo qualcosa che vogliono fare davvero, o stanno solo cercando una frase che suoni bene in un documento? Il problema non è che siano falsi. È che non sono verificabili. Non ti aiutano a capire, tra sei mesi, se il progetto ha funzionato oppure no. E soprattutto non ti aiutano a decidere cosa fare domani mattina. Una frase come “ridurre i tempi di evasione ordini del 30% entro sei mesi” cambia tutto. Ti costringe a scegliere un perimetro, a trovare un dato di partenza, a capire dove intervenire. “Digitalizzare i processi aziendali” invece è una nebulosa. Dentro ci sta tutto, e quindi non ci sta niente. Non sorprende che il 64% dei progetti di digitalizzazione parta senza una roadmap chiara. Forse la causa principale è proprio questa difficoltà nel tradurre ambizioni generiche in obiettivi misurabili. E poi c’è un effetto collaterale un po’ tossico: la vaghezza rende facile dichiarare successo senza aver combinato molto. Basta raccontarla bene. ## Nessuno sa chi decide {: #nessuno-sa-chi-decide } Questo segnale è subdolo, perché all’inizio sembra collaborazione. Tante persone coinvolte, tanti reparti invitati, tante opinioni raccolte. Poi, quando arriva una decisione vera, nessuno sa chi ha l’ultima parola. Chi approva le scelte tecnologiche? Chi risolve i conflitti tra commerciale e operations? Chi decide se accettare un cambio di scope proposto dal fornitore? Chi dice “ok, si fa così” quando due alternative sono entrambe scomode? Se non c’è una risposta chiara, succede una cosa che ho visto ripetersi spesso: le decisioni non vengono negate, vengono rimandate. Si trasformano in loop di email, in riunioni che finiscono con “ci aggiorniamo”, in documenti condivisi pieni di commenti. E il progetto non collassa in modo spettacolare. Si dissolve. Un po’ alla volta. Anche qui, la letteratura è meno romantica di quanto vorremmo: una governance efficace richiede un referente interno capace di coordinare scelte tecnologiche, rapporti con i fornitori e monitoraggio dei risultati. Senza, il progetto resta senza direzione. ## Lo stack scelto dal fornitore {: #lo-stack-scelto-dal-fornitore } Questo è quello che mi mette più a disagio, forse perché è il più difficile da riconoscere quando sei dentro l’azienda. Il fornitore arriva con una soluzione già pronta. Magari è anche una buona soluzione, nel suo contesto. Ma la propone come risposta naturale ai problemi dell’azienda, e l’azienda accetta perché non ha fatto un’analisi vera dei bisogni. A volte succede per fretta. A volte perché “loro lo fanno da anni, sapranno cosa serve”. A volte perché nessuno internamente ha le competenze o il tempo per mettere in discussione la proposta. Il risultato però tende a essere sempre lo stesso: si compra una tecnologia costosa che non si adatta ai processi esistenti, oppure li stravolge in un modo che l’organizzazione non è pronta ad assorbire. La sequenza corretta sarebbe banale, eppure è rarissima: prima capisci cosa vuoi risolvere, poi scegli la tecnologia. Quando lo stack è già stato deciso prima della prima riunione strategica, qualcosa non torna. ## I KPI che non si possono misurare {: #i-kpi-che-non-si-possono-misurare } L’ultimo segnale spesso arriva quando ormai si è già speso tempo, energia, reputazione. Si definiscono i KPI. Tutti sono contenti perché “almeno misuriamo”. Poi però nessuno si è chiesto una cosa molto semplice: i dati per misurarli esistono? “Miglioramento della soddisfazione del cliente” è un KPI solo se hai un modo consistente per misurare la soddisfazione prima e dopo. “Riduzione dei costi operativi” funziona solo se sai quali costi stai guardando, e se li tracci in modo pulito. Quando i KPI vengono definiti per rassicurare chi approva il budget, e non per guidare il progetto, diventano numeri elastici. E se un numero si può interpretare in mille modi, non dirà mai chiaramente che il progetto sta fallendo. Sul tema c’è un punto interessante: a volte misurare diventa una specie di teatro, una pratica che sembra seria ma non cambia le decisioni. ## Il PO: la figura che nessuno ha chiamato {: #il-po-la-figura-che-nessuno-ha-chiamato } Se ci pensi, tutti e cinque questi segnali hanno qualcosa in comune. Non sono problemi tecnici. Sono problemi di chiarezza, responsabilità, comunicazione. E c’è una figura che, almeno in teoria, nasce proprio per governare quel tipo di caos: il product owner. In una PMI spesso nessuno ha tempo per fare la parte “noiosa” del progetto. Quella fatta di domande ripetute, definizioni, confini, priorità. Eppure è proprio lì che si decide se un progetto parte davvero. Un PO non accetta “migliorare l’efficienza” come risposta. Insiste, magari anche troppo. Quale processo? Quale metrica? Da quando a quando? Chi ci mette le mani? Cosa cambia per le persone che oggi fanno quel lavoro in un certo modo? Sul tema dello sponsor debole, il PO non può sostituire la leadership, e sarebbe ingenuo pensarlo. Però può renderla più efficace. Può preparare decisioni che costringono lo sponsor a scegliere tra opzioni concrete, invece di annuire davanti a presentazioni vaghe. In pratica riduce l’attrito cognitivo di chi dovrebbe guidare e spesso non sa da dove iniziare. Sulla governance, il PO porta struttura quasi per definizione. Gestisce priorità, esplicita cosa è dentro e cosa è fuori, tiene traccia degli impegni. Non elimina la politica interna, ma la rende visibile, e già questo a volte cambia il gioco. E sul tema dei fornitori, forse è la funzione più preziosa. Il PO si mette davanti al fornitore non come cliente ingenuo, ma come interlocutore che capisce cosa sta comprando. Sa distinguere una proposta costruita attorno alle esigenze dell’azienda da una costruita attorno al catalogo del fornitore. Mi chiedo se il vero problema non sia che nelle PMI italiane questa figura venga ancora percepita come un lusso, qualcosa da grandi aziende o da startup finanziate. Io ho l’impressione opposta. Dove le risorse sono limitate e gli errori costano caro, avere qualcuno che fa le domande giuste all’inizio vale quanto non buttare via sei mesi su un progetto che, in fondo, non sarebbe partito comunque. E forse la domanda più utile, prima ancora di scegliere un software, è questa: chi si prende la responsabilità di rendere il progetto reale, giorno dopo giorno? Se non c’è una risposta che suona credibile, forse conviene fermarsi lì. Non per cinismo, ma per rispetto del tempo di tutti. --- # Tre minuti contro un anno: Università e AI fuori tempo - **URL:** https://margiovanni.it/it/blog/tre-minuti-contro-un-anno-universita-e-ai-fuori-tempo/ - **Pubblicato:** 2026-02-20 - **Tag:** Formazione, Intelligenza Artificiale, Lavoro, Università - **Tempo di lettura:** 10 min > Una demo in tre minuti ha replicato un progetto universitario annuale. Una riflessione su tempi, competenze e il rischio che l’istruzione diventi irrilevante. Tre minuti. Non è una metafora, né un modo di dire. Tre minuti reali, misurabili, quelli che passano mentre in aula qualcuno tossisce, qualcuno prende appunti, qualcuno controlla l’ora. Durante un seminario sull’ai generativa in azienda, all’università, ho aperto Claude Cowork e gli ho dato tre file csv con dati e-commerce e un brief di poche righe. Vendite, clienti, marketing. Poi ho chiesto una cosa molto “da corso”: segmentazione, kpi, roas per canale, grafici, e un report strategico con raccomandazioni di budget. In tre minuti l’ai ha fatto l’analisi, ha costruito una segmentazione rfm, ha calcolato il ritorno sulla spesa pubblicitaria, ha tirato fuori visualizzazioni interattive e ha scritto un report che, a colpo d’occhio, sembrava completo. Non perfetto, no. Non pronto per essere presentato a un board senza una revisione seria. Però era esattamente il tipo di deliverable che spesso viene richiesto come progetto finale. Quello che un corso universitario programma per un anno. Non lo scrivo per sminuire studenti o docenti. Lo scrivo perché quella scena mi ha costretto a guardare in faccia una cosa che, se devo essere sincero, preferirei non vedere: la divergenza silenziosa tra la velocità della tecnologia e la velocità delle istituzioni. ## Due orologi che segnano tempi diversi {: #due-orologi-che-segnano-tempi-diversi } L’università è progettata per muoversi lentamente. E non è necessariamente un difetto, anzi. È il modo in cui garantisce qualità: commissioni, accreditamenti, comitati, revisioni, consenso. È quasi nel DNA di queste istituzioni non correre. Il problema è che fuori dall’aula, nel frattempo, il mondo non sta solo correndo. Sta cambiando scarpe ogni due chilometri. Un curriculum universitario richiede spesso 12-24 mesi per essere progettato, approvato e implementato. I corsi vengono pianificati con largo anticipo. I libri di testo hanno cicli editoriali lunghi, e anche quando sono ottimi, arrivano in un mondo che nel frattempo si è già spostato. L’innovazione invece ragiona per release. Strumenti di AI coding passano da “curiosità” a standard industriale in pochi mesi. Agenti AI completano lavori che prima richiedevano settimane. Startup fondate da neolaureati raggiungono valutazioni enormi in tempi che non assomigliano più ai vecchi cicli industriali. E così ci ritroviamo con due orologi nella stessa stanza. Uno scandisce semestri e piani di studio. L’altro scandisce deploy, aggiornamenti, nuovi modelli, nuove interfacce. La distanza tra i due non è solo organizzativa. Sta diventando culturale. ## La mezza vita delle competenze: da decenni a mesi {: #la-mezza-vita-delle-competenze-da-decenni-a-mesi } C’è un concetto che torna spesso quando si parla di lavoro e tecnologia: la *half-life* delle competenze. Il tempo dopo il quale metà di ciò che hai imparato diventa obsoleto o poco rilevante. Quarant’anni fa poteva essere una decade. Oggi, per molte competenze tecniche, si parla di circa 2,5 anni. Eppure non serve nemmeno chiedersi se 2,5 anni non siano un'era geologica quando parliamo di AI e sviluppo software. Gli assistenti AI per programmare sono passati da esperimento a presenza capillare in pochissimo tempo. Chi ha imparato a programmare nel 2022 senza toccare strumenti di AI coding oggi si trova a lavorare con un pezzo di cassetta degli attrezzi che manca. Le stime globali mettono numeri ancora più netti sul quadro generale: entro il 2030, il 39% delle competenze chiave richieste nel mercato del lavoro cambierà. E il 59% della forza lavoro globale avrà bisogno di reskilling o upskilling. Ora prendi una laurea triennale: tre anni. Aggiungi una magistrale: altri due. Cinque anni. Nello stesso arco temporale in cui uno studente completa il percorso, una parte enorme di ciò che il mercato considera “chiave” sarà cambiata. E qui la domanda smette di essere teorica. Diventa quasi intima: che cosa stiamo promettendo ai giovani che si iscrivono all'Università? ## L’ingresso nel lavoro è un muro, non una porta {: #lingresso-nel-lavoro-e-un-muro-non-una-porta } Se fosse solo un disallineamento di contenuti, potremmo parlarne con calma. Il problema è che i numeri sull’entry-level raccontano una storia più dura. Negli ultimi anni le assunzioni entry-level in molte grandi aziende tech sono calate drasticamente. In diversi mercati si parla di riduzioni importanti, e in europa nel 2024 molte posizioni tech per neolaureati sono diminuite sensibilmente, con prospettive non esattamente rosee. Poi ci sono i tagli dichiarati apertamente come “abilitati” dall’AI. Aziende che riducono ruoli corporate perché l’ai permette strutture più snelle. C’è persino chi ha detto pubblicamente che l’ai gestisce ormai una parte enorme del lavoro. E mentre questo succede, tra i giovani cresce una sensazione che si percepisce anche senza sondaggi: l’idea che il mercato sia diventato più chiuso, più selettivo, più difficile da attraversare. Quasi la metà dei giovani in cerca di lavoro ritiene che l’ai abbia ridotto il valore della propria istruzione universitaria. Non è fantascienza. È presente. E quando il presente ti bussa alla porta, non puoi più rimandare la conversazione. ## Il paradosso dell’entry-level: quando l’ai mangia il primo gradino {: #il-paradosso-dellentry-level-quando-lai-mangia-il-primo-grad } C’è un dettaglio che rende tutto più insidioso. Il patto implicito dell’entry-level, per anni, è stato questo: fai lavoro ripetitivo, ti fai le ossa, impari. In cambio ricevi mentorship, contesto, crescita. Quel lavoro ripetitivo però è esattamente ciò che l’AI assorbe meglio. E quindi sparisce il primo gradino della scala. Questa è la parte che mi inquieta di più, perché è un problema di “trasmissione” delle competenze. Se non assumi junior oggi, chi diventerà senior domani? Qualcuno ha descritto questa scelta come “mangiare il grano da semina”. Risparmi adesso, paghi dopo, e paghi con interessi. Nel frattempo l’università rischia un circolo vizioso: forma persone per ruoli entry-level che si stanno restringendo, usando curricula che possono diventare vecchi prima ancora di arrivare a regime. Il laureato del 2026 esce mediamente con conoscenze del 2023, perché quello era l’anno in cui il curriculum è stato pensato, per un mercato che nel frattempo ha fatto due o tre rivoluzioni. ## Tre minuti vs un anno, e quello che ho visto negli occhi degli studenti {: #tre-minuti-vs-un-anno-e-quello-che-ho-visto-negli-occhi-degl } Torno a quella demo perché lì, più che nei grafici, c’era la parte emotiva. Il brief era una poche righe. Tre csv allegati. Zero configurazione. In tre minuti l’ai ha prodotto metriche aggregate, segmentazione, roas, visualizzazioni, raccomandazioni. Ripeto: non era perfetto. Ma era abbastanza buono da far scattare una domanda silenziosa. E la domanda, in aula, si è vista negli occhi. Non ho visto panico. Ho visto concentrazione. Ho visto quella forma di attenzione che arriva quando capisci che il terreno sotto i piedi si muove davvero. Non so perché, ma questa cosa mi ha dato speranza. Forse perché mi è sembrato che gli studenti non stessero fingendo. Stavano guardando. E forse è da lì che si passa: dal non fare finta. Perché il messaggio, alla fine, era chiaro. Il “cosa” si impara sta diventando meno importante del “come” si impara a imparare. ## Italia: buona volontà, tempi geologici {: #italia-buona-volonta-tempi-geologici } In italia non siamo fermi. Sarebbe ingiusto dirlo. Negli ultimi anni l’offerta formativa in AI è cresciuta, con nuovi corsi di laurea, percorsi magistrali, contaminazioni con altre discipline, alta formazione in ambiti specifici. Ci sono strategie nazionali, collaborazioni università-imprese, piattaforme di e-learning. Sono passi importanti. Ma c’è un “ma” grande: si muovono alla velocità istituzionale. Bandi, commissioni, organi collegiali. Nel frattempo fuori si va alla velocità dei deployment. Quando un corso viene attivato dopo anni (o anche solo mesi) di iter, gli strumenti che insegna rischiano di essere già cambiati due volte. Non perché il corso sia fatto male. Perché il tempo è diventato un avversario. E qui la divergenza fa più male, perché non è questione di incompetenza. È questione di architettura. Le università garantiscono qualità attraverso la lentezza. La tecnologia garantisce rilevanza attraverso la velocità. Per anni queste due logiche hanno convissuto. Ora iniziano a scontrarsi. ## Cosa stiamo insegnando, e cosa forse dovremmo insegnare {: #cosa-stiamo-insegnando-e-cosa-forse-dovremmo-insegnare } Le competenze che crescono più in fretta nei prossimi anni sono un mix strano e bellissimo. Da un lato ai e big data, cybersecurity, literacy tecnologica. Dall’altro pensiero creativo, resilienza, flessibilità, curiosità, apprendimento permanente, leadership. Tecnico e profondamente umano insieme. E allora mi chiedo se il punto non sia proprio questo. Non basta insegnare uno strumento. Bisogna insegnare a pensare, adattarsi, comunicare, decidere sotto incertezza. Perché gli strumenti cambiano. E cambiano in fretta. C’è anche un fenomeno che secondo me stiamo leggendo male: la dipendenza diffusa degli studenti dall’AI. Spesso la chiamiamo pigrizia. A volte lo è, certo. Ma a volte è un segnale. Gli studenti sentono quando gli si chiede di investire energie in competenze che sembrano irrilevanti o già superate. E cercano scorciatoie perché, dal loro punto di vista, il gioco non vale la candela. Le università (o anche le scuole) che rispondono vietando l’AI stanno combattendo una guerra persa. Quelle che la integrano in modo superficiale rischiano di fare un’altra cosa: **normalizzare l’uso senza cambiare davvero l’obiettivo**. Forse serve un ripensamento più radicale di cosa significhi “competenza” nel 2026. ## La fine del curriculum statico {: #la-fine-del-curriculum-statico } Non ho la presunzione di avere soluzioni definitive. Più ci penso e più mi sembra un problema pieno di compromessi reali. Però alcune direzioni, almeno, si intravedono. La prima è la modularità. Abbandonare l’idea del curriculum monolitico pluriennale e spostarsi verso moduli brevi, aggiornabili, componibili. Micro-credenziali che si aggiornano ogni semestre. Non è un capriccio “moderno”. È un modo per riallineare l’educazione a un mondo che non aspetta. La seconda è portare dentro problemi reali, non esercizi. La differenza è semplice: un esercizio ha una soluzione nota, un problema reale no. L’AI è bravissima con le soluzioni note, e infatti rende obsoleti tanti progetti tradizionali. Ciò che resta difficile, invece, è scegliere la domanda giusta, gestire l’ambiguità, negoziare con stakeholder, capire quando un dato è “corretto” ma fuori contesto. La terza è trattare l’AI come ambiente, non come materia. Non un corso isolato, ma una presenza trasversale, come la calcolatrice non ha ucciso la matematica ma ha cambiato cosa significa “saperla”. L’AI probabilmente non ucciderà la formazione, però cambierà cosa significa essere competenti. E poi ci sono le collaborazioni operative con le imprese. Non partnership che producono un paper tra tre anni, ma lavori condivisi su problemi veri, con gli stessi strumenti, nello stesso arco temporale. È complesso, lo so. Però è anche uno dei pochi modi per recuperare tempo. Infine, insegnare a imparare. Sembra una frase da poster, ma oggi è quasi l’unica cosa davvero a prova di futuro e che forse l'Università negli ultimi 30 anni ha perso. Metacognizione, pensiero critico, capacità di valutare strumenti nuovi, di integrarli senza diventarne dipendenti. ## Il vero pericolo non è l’AI, è l’irrilevanza {: #il-vero-pericolo-non-e-lai-e-lirrilevanza } Se l’accademia viene percepita come troppo lenta, troppo costosa, fuori dal tempo, il rischio è che le persone inizino a bypassarla. Non per cattiveria, ma per necessità. E qui arriva la domanda più scomoda, quella che temo molti studenti si stiano già facendo. Quando scopri che puoi ottenere in tre minuti con un assistente AI quello che il tuo corso ti ha insegnato a fare in un anno, non pensi “che bello, ho basi solide”. Pensi: perché ho investito tre anni della mia vita e migliaia di euro? La risposta esiste, ed è anche una buona risposta. Il valore dell’università non dovrebbe essere il trasferimento di competenze puntuali. Dovrebbe essere un framework mentale, il pensiero critico, la capacità di argomentare, **la rete di relazioni** , l’esposizione a discipline diverse, la maturazione personale. Ma se il curriculum è costruito come se il valore principale fosse “imparare a fare un dashboard”, quella risposta suona vuota. E fa male dirlo, perché dietro tanti corsi c’è dedizione vera. ## L’urgenza di agire, senza panico {: #lurgenza-di-agire-senza-panico } Oggi nel mondo investiamo pochissimo, in proporzione, nell’apprendimento permanente degli adulti. Eppure aumentare quell’investimento potrebbe generare un valore enorme entro il 2030. Non è solo un problema educativo. È economico. È sociale. Le università hanno un vantaggio che nessuna piattaforma AI ha: possono insegnare a pensare in modo critico, a collaborare in profondità, a navigare l’ambiguità etica. Ma solo se smettono di competere sul terreno dove l’AI vince, cioè la trasmissione di informazioni e l’esecuzione di compiti strutturati, e si concentrano su ciò che le rende insostituibili. Il tempo per questa transizione non è “nei prossimi anni”. È adesso. Ogni semestre che passa con curricula invariati è un semestre di studenti che escono meno preparati di quanto potrebbero essere. La velocità dell’AI non rallenterà per aspettare i comitati didattici. Quella demo di tre minuti non era una provocazione. Era uno specchio. E la cosa che mi ha colpito di più non è stata la velocità dell’AI. È stata la lentezza di tutto il resto. --- # Il software è un prodotto. E adesso? - **URL:** https://margiovanni.it/it/blog/il-software-e-un-prodotto-e-adesso/ - **Pubblicato:** 2026-02-18 - **Tag:** Compliance, Cybersecurity, Diritto Digitale, Sviluppo Software - **Tempo di lettura:** 10 min > Dal 9 dicembre 2026 la nuova product liability directive include il software tra i prodotti. Cosa cambia per roadmap, contratti, release e open source. ## Un cambio di parola che cambia tutto {: #un-cambio-di-parola-che-cambia-tutto } Per anni ho avuto la sensazione che il software vivesse in una specie di bolla. Non nel senso romantico del termine, più una zona grigia comoda, quasi protettiva. Se un prodotto fisico faceva male a qualcuno, la responsabilità era un tema immediato e concreto. Se invece era “solo” software, la conversazione scivolava spesso su bug, patch, workaround, e su quel sottinteso un po’ indulgente per cui “è normale, tanto si aggiorna”. La direttiva 85/374/cee sulla responsabilità per prodotti difettosi, in fondo, parlava di beni mobili, roba tangibile. Il software, intangibile per definizione, ci stava dentro male. E quando una norma ti sta addosso male, spesso finisce che non ti sta addosso per niente. Dal 9 dicembre 2026, con la direttiva (ue) 2024/2853, questa ambiguità si chiude. La nuova product liability directive (pld) dice esplicitamente che il software è un *prodotto*. E non solo il software “dentro” un oggetto, ma tutto: standalone, embedded, firmware, applicazioni, cloud, saas, sistemi di ai. Indipendentemente da dove gira e da come lo distribuisci. Non è una nota a piè di pagina. È un cambio di paradigma, e forse la cosa più interessante è che non riguarda solo chi scrive codice. Riguarda chi decide cosa costruire, chi lo vende, chi lo rilascia, chi lo mantiene e chi decide quando smettere. ## La responsabilità oggettiva: il punto in cui cambia la prospettiva {: #la-responsabilita-oggettiva-il-punto-in-cui-cambia-la-prospe } La pld si appoggia su un concetto che nel mondo software è facile sottovalutare finché non ti cade addosso: la **responsabilità oggettiva** (strict liability). In pratica, chi subisce un danno da un prodotto difettoso non deve dimostrare che tu sei stato negligente. Non deve ricostruire la tua catena di decisioni, non deve provare che “avresti potuto fare meglio”. Deve dimostrare tre cose: che il prodotto era difettoso, che c’è stato un danno, e che c’è un nesso causale. Per chi è abituato a ragionare in termini di “abbiamo fatto il possibile”, “era un edge case”, “era una dipendenza terza”, è uno spostamento mentale notevole. La diligenza continua a contare, certo, ma non come scudo automatico. E c’è un altro pezzo che rende tutto più concreto: la direttiva introduce meccanismi di *presunzione*. Se per il danneggiato è “eccessivamente difficile” provare il difetto o il nesso causale, cosa che con software complesso o sistemi di ai è quasi la norma, il tribunale può presumere difettosità e causalità. Può anche ordinare al produttore di esibire documentazione tecnica, e deve essere presentata in modo “accessibile e comprensibile”. Se non collabori, quella mancata collaborazione può diventare un elemento a tuo sfavore. Detta senza giri: in molti casi ti troverai a dover dimostrare che il software *non* era difettoso. E per farlo, servono prove. Tracce. Scelte motivate. Dati. ## Chi fa prodotto: la responsabilità inizia molto prima del codice {: #chi-fa-prodotto-la-responsabilita-inizia-molto-prima-del-cod } Quando si parla di responsabilità, l’istinto è guardare allo sviluppo. Ma la pld mette sotto lente anche ciò che viene prima, e cioè le decisioni di prodotto. La difettosità si valuta sulle *aspettative ragionevoli* di sicurezza. Un prodotto è difettoso se non offre il livello di sicurezza che una persona è legittimamente autorizzata ad attendersi. E questo giudizio dipende da come presenti il prodotto, dall’uso ragionevolmente prevedibile, dal momento della messa in servizio. Ma anche da elementi modernissimi, tipo l’interconnessione con altri sistemi, la conformità ai requisiti di cybersecurity, e perfino la capacità di apprendere. Qui mi viene da pensare a quante volte una roadmap nasce da trade-off che sembrano puramente “business”: consegnare prima, tagliare una feature di sicurezza, rimandare la hardening phase, integrare un componente ai perché “fa figo” e perché i competitor lo hanno già. Con la pld, quelle non sono solo scelte di prodotto. Sono scelte che possono diventare rilevanti in una contestazione. Se prometti nelle specifiche commerciali una certa affidabilità o un certo standard di sicurezza, stai creando un’aspettativa. Se integri un componente ai che cambia comportamento nel tempo, ti stai prendendo la responsabilità anche di quel comportamento futuro. E l’imprevedibilità dell’ai, per come è impostata la direttiva, non è una difesa. La conseguenza più pratica, secondo me, è questa: il *risk assessment* entra nel product management. Non come documento che si fa una volta e poi si dimentica, ma come abitudine. E soprattutto entra la documentazione delle decisioni. Non per burocrazia, ma perché tra qualche anno potrebbe essere necessario spiegare perché una certa scelta era ragionevole *in quel momento*. Gli architecture decision record, che oggi molti team usano per non perdersi, iniziano ad assomigliare a un pezzo della tua difesa. ## Chi vende: il contratto non è più uno scudo {: #chi-vende-il-contratto-non-e-piu-uno-scudo } C’è un riflesso condizionato diffuso nel software: se il rischio aumenta, si aggiunge una clausola. Limitazione di responsabilità, cap, manleva, disclaimer nei terms. La pld qui è piuttosto brutale: la responsabilità prevista dalla direttiva non può essere esclusa o limitata contrattualmente quando il danno riguarda una persona fisica. Vale in b2c, e in pratica ti tocca anche in b2b ogni volta che esistono utenti finali persone. Questo non significa che i contratti diventino inutili. Significa che devono cambiare funzione. In particolare, nei rapporti b2b serve chiarire le responsabilità lungo la supply chain. Se sviluppi per un cliente che mette il prodotto sul mercato con il proprio brand, chi è il “fabbricante” ai sensi della pld? Se il tuo software è un componente dentro un sistema più grande, come si gestisce il regresso tra le parti? Non puoi eliminare la responsabilità verso l’esterno, ma puoi e devi chiarire cosa succede tra voi. Poi c’è un pezzo che spesso viene sottovalutato da sales e marketing: le promesse commerciali. Demo, brochure, claim tipo “massimi standard di sicurezza”, slide con “zero downtime”, pagine di pricing che implicano certe garanzie. Tutto questo contribuisce a definire cosa l’utente era legittimato ad aspettarsi. E quindi entra, indirettamente, nella valutazione della difettosità. Infine, il tema assicurativo e di pricing. La rc professionale classica copre la negligenza, non necessariamente la strict liability. È probabile che molte aziende debbano rivedere coperture e massimali, includendo aspetti come cybersecurity, data loss e danni immateriali. E quel costo finirà nel prezzo. Con un effetto collaterale interessante: chi si muove bene prima può trasformare la compliance in un argomento competitivo credibile. ## Chi rilascia: ogni deploy diventa un atto che lascia tracce {: #chi-rilascia-ogni-deploy-diventa-un-atto-che-lascia-tracce } Se lavori su release, devops, qa, o se sei la persona che alla fine dice “ok, si va in produzione”, questa è forse la parte più concreta. Nel software moderno, il rilascio non è la fine. È l’inizio. Perché quasi sempre il produttore mantiene controllo tramite update, accesso remoto, feature flag, patch, aggiornamenti di sicurezza. La pld, letta insieme al contesto normativo, rende molto rischioso un approccio “rilascio e poi si vede”. La mancata fornitura di aggiornamenti di sicurezza per vulnerabilità note può essere considerata essa stessa un difetto. E un aggiornamento che introduce un problema può essere visto come una modifica sostanziale, con effetti anche sui termini. La responsabilità base dura 10 anni, e per lesioni personali latenti può arrivare a 25. Quando leggo questi numeri mi chiedo sempre se abbiamo davvero la cultura della conservazione delle evidenze per un orizzonte simile. Perché non basta aver fatto le cose bene, bisogna poterlo dimostrare. Qui entra la tracciabilità. Sapere cosa conteneva una certa versione in una certa data. Quali dipendenze. Quali vulnerabilità note. Quali test sono stati eseguiti. Chi ha approvato. Cosa è stato deciso e perché. L’sbom (software bill of materials) diventa centrale. Anche perché il cyber resilience act lo rende obbligatorio in molti casi, e la pipeline ci/cd diventa di fatto un’infrastruttura di compliance: generazione automatica sbom (cyclonedx o spdx), scanning vulnerabilità, audit trail dei deploy, conservazione degli artefatti. E c’è un dettaglio che sembra banale finché non lo vivi: anche la decisione di *non* rilasciare una patch è una decisione. Se oggi scegli di rimandare una correzione per ragioni sensate, probabilmente va bene. Ma tra cinque anni potresti dover spiegare perché era sensato. Meglio avere quella spiegazione scritta quando la memoria è fresca. ## Chi sviluppa: documentare non è burocrazia, è memoria difendibile {: #chi-sviluppa-documentare-non-e-burocrazia-e-memoria-difendib } Per gli sviluppatori, la pld non chiede magie. Non ti dice “scrivi codice perfetto”, cosa che non esiste. Ti chiede, in sostanza, di rendere ricostruibile il percorso. Test automatici che dimostrano il comportamento atteso. Code review tracciate. Scan di sicurezza integrati. Commit message che non siano “fix”. Ticket che raccontano il contesto. Sono cose che molti team fanno già, magari in modo irregolare. La differenza è che da “buona pratica” diventano anche un pezzo di tutela. E qui il collegamento con il cyber resilience act è diretto: se non sei conforme a requisiti come secure by design, gestione delle vulnerabilità e sbom, quella non conformità può rafforzare una contestazione di difettosità in ottica pld. Le norme, insomma, non vivono più in compartimenti stagni. ## Il mito del b2b come zona franca {: #il-mito-del-b2b-come-zona-franca } Capisco la tentazione: “noi vendiamo solo ad aziende, quindi non ci riguarda”. Però basta guardare un attimo gli utenti reali. Software per la pa: cittadini. Sistemi hr: dipendenti. E-learning: studenti. Parcheggi: automobilisti. Sanità: pazienti. In tutti questi casi il cliente è un’organizzazione, ma l’impatto ricade su persone fisiche. In più, la pld ragiona anche per componenti. Se fornisci un modulo, un’api, un microservizio che finisce dentro il prodotto di un altro, puoi essere considerato fabbricante del componente. E poi c’è l’estensione dei danni risarcibili: la distruzione o corruzione di dati non usati a fini professionali, senza soglia minima e senza tetto massimo. È un passaggio che molte aziende non hanno ancora metabolizzato. ## Open source: protetto, ma non è una scappatoia {: #open-source-protetto-ma-non-e-una-scappatoia } La direttiva esclude il software open source sviluppato o fornito al di fuori di un’attività commerciale. Ma se c’è un corrispettivo, anche sotto forma di dati personali, il discorso cambia. E soprattutto, se integri open source dentro un prodotto commerciale, la responsabilità per eventuali difetti ricade su chi integra e mette sul mercato. Questo sposta il baricentro: non è più solo un tema di compliance licenze. Diventa gestione del rischio tecnico e legale. Scelta delle dipendenze, processi di vetting, vulnerability management serio, e di nuovo sbom. ## La pld non è sola: un ecosistema che si incastra {: #la-pld-non-e-sola-un-ecosistema-che-si-incastra } La sensazione, guardando il quadro europeo, è che l’ue stia costruendo un’idea precisa di “software come prodotto” e la stia sostenendo da più lati. La pld si incastra con il cyber resilience act (cybersecurity by design, sbom, gestione vulnerabilità), con l’ai act (che rende i fornitori ai fabbricanti anche ai fini pld), con il gdpr (data breach e danni), con nis2, con il gpsr, con la representative actions directive per le azioni collettive, e persino con l’european accessibility act. Il punto non è ricordare tutte le sigle. Il punto è che una lacuna in un’area può propagarsi e rafforzare un contenzioso in un’altra. La compliance diventa un sistema. ## Il recepimento italiano: una scelta da tenere d’occhio {: #il-recepimento-italiano-una-scelta-da-tenere-docchio } L’italia deve recepire la pld entro il 9 dicembre 2026. Essendo una direttiva di massima armonizzazione, non ci sono grandi spazi per “interpretazioni creative”. Però un margine importante c’è: la difesa dello stato dell’arte. In sostanza, lo stato può decidere se mantenere l’idea per cui il fabbricante non risponde se il difetto non era riconoscibile con le conoscenze disponibili al momento della messa in servizio. Oppure può eliminarla. Non è un dettaglio, e vale la pena monitorarlo. Perché cambia il profilo di rischio, specialmente su software complesso e su scenari ai. ## Non solo rischi: la parte che può diventare un vantaggio {: #non-solo-rischi-la-parte-che-puo-diventare-un-vantaggio } Se la leggi tutta in modalità “catastrofe”, la pld sembra solo un costo. Più documentazione, più processi, più assicurazioni, più discussioni interne. Però c’è un’altra lettura, e forse è quella più utile se devi prendere decisioni adesso. La pld crea un terreno di gioco dove qualità, sicurezza e trasparenza della supply chain diventano vantaggi competitivi misurabili. Non più “fidati di noi”, ma “abbiamo processi e prove che reggono a una richiesta formale, e se serve a un tribunale”. Per le software house, arrivare compliant prima della deadline può diventare un argomento forte con enterprise e pa. Per consulenza e system integration, si apre una domanda enorme di competenze che oggi, almeno nel tessuto delle pmi italiane, non è così diffusa. Per chi fa prodotto, è un incentivo a investire in cose che, alla lunga, migliorano davvero il software. ## Una conclusione senza trionfalismi {: #una-conclusione-senza-trionfalismi } Per quarant’anni abbiamo potuto pensare al software come a qualcosa di speciale. Più flessibile, più aggiornabile, più perdonabile. La pld dice che questa eccezionalità è finita. Il software è un prodotto, con responsabilità simili a quelle di un macchinario, di un dispositivo medico, di un’auto. Non riguarda solo chi scrive codice. Riguarda roadmap e trade-off. Riguarda contratti e promesse commerciali. Riguarda release e supporto, e persino l’end-of-life. La cosa che mi sembra più sensata, oggi, è spostare la domanda da “come ci proteggiamo” a “come rendiamo il nostro modo di lavorare dimostrabile”. Perché prepararsi non è solo mettere pezze legali. È fare meglio il proprio lavoro, con più memoria, più tracciabilità e meno fiducia cieca nel fatto che tanto “poi si sistema”. La domanda non è se prepararsi. È quanto velocemente. *fonti principali: direttiva (ue) 2024/2853; cyber resilience act (regolamento ue 2024/2847); analisi di reed smith, iba, fladgate, taylor wessing, clyde & co, dla piper, hogan lovells, iclg, covington.* --- # Il sito senza sito: un nuovo modo di pensare il web - **URL:** https://margiovanni.it/it/blog/il-sito-senza-sito-un-nuovo-modo-di-pensare-il-web/ - **Pubblicato:** 2026-02-15 - **Tag:** Contenuti, SEO, Tecnologia, UX - **Tempo di lettura:** 18 min > Scopri come progettare siti web pensati per i bot, migliorando l'esperienza utente e il posizionamento. Riflessioni su SEO e contenuti chiari. L'altro giorno stavo cercando un fornitore per un servizio abbastanza specifico. Una cosa banale, in teoria: capire cosa fa un'azienda, per chi lavora, quanto costa più o meno, se ha esperienza nel mio settore. Ho aperto il primo risultato di Google e sono finito in un labirinto. Cookie wall a schermo intero, poi un banner con lo sconto del 20% se mi iscrivo alla newsletter, poi una live chat che si apre da sola chiedendomi se ho bisogno di aiuto, poi un video in autoplay con musica epica che racconta la "vision" dell'azienda con parole tipo "innovazione", "eccellenza", "soluzioni su misura a 360 gradi". Ho scrollato per tre minuti buoni cercando di capire concretamente cosa fanno. Non ci sono riuscito. Il sito era bellissimo, intendiamoci. Animazioni fluide, tipografia curata, fotografie professionali. Ma alla fine della visita sapevo meno di prima. Poi ho fatto una cosa che faccio sempre più spesso. Ho preso l'url del sito e l'ho dato in pasto a Claude, chiedendogli: dimmi chi sono, cosa fanno, per chi lavorano, quali sono i loro punti di forza. La risposta è stata desolante. Claude ha estratto una manciata di slogan vaghi, qualche keyword ripetuta, nessun caso concreto, nessun numero, nessuna informazione che permettesse di costruire un giudizio. Il sito era ottimo per far cliccare un umano distratto, pessimo per far capire a una macchina cosa diavolo fa quell'azienda e se è affidabile. E qui mi sono fermato a pensare. Perché se io, che sono un professionista del settore, faccio sempre più spesso questa operazione, se uso un llm come primo filtro per capire se vale la pena approfondire, quante altre persone stanno iniziando a fare la stessa cosa? E soprattutto: quante decisioni vengono già prese da sistemi automatici che leggono il tuo sito al posto di un essere umano? La domanda che guida tutto questo ragionamento è una sola, e me la porto dietro da settimane: e se il prossimo sito non dovesse più essere pensato per l'utente che guarda lo schermo, ma per il visitatore che non ha occhi? Dico "il visitatore che non ha occhi" e mi rendo conto che suona come una provocazione. Ma non lo è, o almeno non solo. Il primo lettore del vostro sito oggi è un crawler di Google. Il secondo è un agent che compone risposte per qualcuno che ha fatto una domanda. Il terzo è un llm che deve sintetizzare chi siete, cosa fate, perché dovrebbe fidarsi di voi. Solo dopo, forse, arriva l'umano. E quell'umano, sempre più spesso, arriva già con un'opinione formata da ciò che la macchina gli ha raccontato. Se la macchina non ha capito niente di voi, l'umano non arriverà nemmeno a vedere il sito. Non sto parlando di seo. La seo è una parte del discorso, certo, ma è una parte che ormai conosciamo e che è diventata quasi una commodity. Sto parlando di qualcosa di diverso: macchine che devono costruirsi un modello mentale della vostra azienda. Non un ranking, non una posizione in una serp. Un modello mentale. Capire chi siete, cosa fate davvero, per chi lo fate, con quali risultati, con quali limiti. È una differenza enorme. Un crawler seo cerca keyword e struttura. Un llm cerca significato, coerenza, credibilità. E se il vostro sito è un monumento al design emozionale ma un deserto di contenuto reale, quel modello mentale sarà vuoto. O peggio, sarà sbagliato. Mi rendo conto che per arrivare qui devo prima spiegare come il web "per gli umani" si è rotto. Perché non è che un giorno qualcuno ha deciso di costruire siti incomprensibili. È successo gradualmente, decisione dopo decisione, layer dopo layer, fino a creare un mostro che nessuno ha progettato consapevolmente. È iniziato con i cookie banner, e fin lì ci poteva anche stare. Poi sono arrivati i pop-up per la newsletter. Poi le notifiche push. Poi le live chat. Poi i video in autoplay. Poi gli interstitial per le app mobile. Poi i banner per gli sconti. Ogni singolo elemento aveva una sua ragione d'essere, un suo business case, un suo A/B test che dimostrava un incremento del 3% in qualche metrica. Ma la somma di tutti questi incrementi del 3% ha prodotto un'esperienza che è diventata, per molti siti, genuinamente ostile. Non solo per le macchine. Anche per gli umani, se siamo onesti. Ma per le macchine in modo particolare, perché tutto quel rumore visivo e interattivo non è semplicemente fastidioso, è opaco. Un llm non può chiudere un pop-up. Non può scrollare oltre un video. Non può cliccare "No grazie" sulla newsletter. Vede il codice sorgente della pagina, e quel codice sorgente è diventato un campo di battaglia dove il contenuto reale è sepolto sotto strati di javascript, tracking, componenti dinamici, contenuti caricati a posteriori. C'è poi il problema del "conversion design", e qui tocco un nervo scoperto perché conosco bene quel mondo, ci ho lavorato. Ogni pixel ottimizzato per la micro-conversione. Ogni frase pensata per generare un click, non per spiegare qualcosa. Ogni pagina strutturata come un funnel che ti spinge verso un'azione, non come un documento che ti aiuta a capire. Il risultato è che molti siti aziendali sono diventati macchine per catturare lead ma hanno smesso di essere fonti di informazione. E quando un llm legge una pagina che è essenzialmente un lungo modulo di contatto con qualche slogan intorno, cosa dovrebbe capire? Che l'azienda fa "soluzioni innovative"? Che è "leader di settore"? Che offre "servizi su misura"? Sono frasi che non significano letteralmente nulla. Nessun umano ragionevole le prenderebbe sul serio, figuriamoci un modello addestrato su miliardi di testi. E poi c'è il lato tecnico, quello che vedo dal mio punto di osservazione come figura che si muove tra codice e strategia. Le single page application pesantissime, con tutto il contenuto generato via javascript lato client. I testi che appaiono solo dopo tre interazioni. Le informazioni cruciali nascoste in accordion che nessun crawler espande. Le landing page duplicate con micro-variazioni per ogni campagna, che creano un rumore semantico pazzesco. I menu con dodici voci che portano a pagine con cinque paragrafi ciascuna di puro filler. Da product owner, da head of tech, da persona che ogni giorno media tra la visione del business e la realtà della tecnologia, vedo chiaramente il paradosso. Abbiamo costruito siti sempre più sofisticati dal punto di vista dell'interazione umana, e nel farlo li abbiamo resi sempre più incomprensibili per le macchine che stanno diventando i nostri intermediari principali con il pubblico. È come aver costruito un negozio bellissimo ma aver murato l'ingresso principale, costringendo i clienti a passare da un vicolo laterale pieno di ostacoli. Ed è qui che arrivo al concetto che mi frulla in testa da un po' e che chiamo, con un po' di autoironia, il "sito senza sito". Non è una provocazione fine a se stessa. È un modello alternativo di architettura dell'informazione che, più ci penso, più mi sembra l'unico sensato per quello che sta arrivando. L'idea è semplice nella formulazione: un insieme coerente di contenuti esposti al web come se fossero un'api per umani e macchine, con un layer di presentazione minimale o addirittura opzionale. La parola chiave è "opzionale". Non sto dicendo che non serve un sito web. Sto dicendo che il sito web dovrebbe essere l'ultimo layer, non il primo. Prima viene l'informazione, strutturata, chiara, completa. Poi, sopra, ci metti la grafica, l'esperienza, il brand. È un ribaltamento totale rispetto a come si costruiscono i siti oggi. Oggi si parte dal design, dall'esperienza, dalla "wow factor". Si scrivono i testi dopo, spesso di fretta, spesso delegati a chi non conosce l'azienda, spesso copiati da competitor. I contenuti sono un riempitivo per un contenitore che è stato disegnato prima ancora di sapere cosa ci sarebbe andato dentro. Il "sito senza sito" parte dall'altra parte. Prima si progetta il grafo di informazioni. Chi siamo, cosa facciamo, per chi, con quali risultati, con quali processi, a che prezzo, con quali limiti, con quali prove. Si mette tutto giù in formato semplice, leggibile, testuale. Si organizza in modo che abbia senso anche senza una singola riga di css. Poi, eventualmente, si costruisce sopra un layer di presentazione che rende tutto più piacevole da navigare per un umano. Ma quel layer è un vestito, non il corpo. Il parallelo che mi viene in mente è con la documentazione tecnica. I progetti open source ben fatti hanno una documentazione che è leggibile in plain text, su un terminale, in un readme su GitHub. Puoi anche renderla più bella con un sito dedicato, certo. Ma la sostanza c'è già prima del vestito. Il "sito senza sito" è trattare l'intero sito aziendale come una documentazione. Non come un pitch di vendita, non come una brochure interattiva, non come un'esperienza emozionale. Come una documentazione. Chiara, completa, navigabile, comprensibile da chiunque, umano o macchina. Scrivo queste parole e sento già le obiezioni arrivare. Ma ci arrivo tra un momento, perché prima voglio spingere la metafora fino in fondo. Se il sito è una documentazione, allora il contenuto è dati. Non dati nel senso tecnico di database e tabelle, ma nel senso che ogni informazione è un oggetto con proprietà chiare. Un servizio ha un nome, una descrizione, un pubblico target, un processo, un prezzo, dei limiti, dei casi di successo. Un caso studio ha un cliente, un problema, una soluzione, dei risultati misurabili. Una persona del team ha un ruolo, delle competenze, un'esperienza. Se strutturi così il contenuto, succede qualcosa di interessante: diventa riusabile. Lo stesso contenuto che alimenta il sito web può alimentare un chatbot, un pdf commerciale, una risposta a un bando, un prompt per un llm, una scheda su un marketplace. È multicanalità nativa, non multicanalità forzata a posteriori. E cambia anche il modo di scrivere. Quando sai che il tuo testo verrà letto da una macchina che cerca di costruire un modello mentale della tua azienda, smetti di scrivere slogan e inizi a scrivere risposte. Risposte a domande precise: per chi è questo servizio? Come funziona? Quanto costa? Cosa include e cosa no? Quali risultati avete ottenuto? Quali sono i vostri limiti? Quest'ultima domanda è la più potente di tutte, e quasi nessuno la include nel proprio sito. Dire cosa *non* fate è informazione preziosissima, sia per un umano che valuta se contattarvi, sia per un llm che deve decidere se raccomandarvi. ## **Come lo costruirei davvero** {: #come-lo-costruirei-davvero } Se dovessi farlo domani per un cliente, e ci ho pensato parecchio, partirei da tre layer. Il primo è una knowledge base pura. Contenuti in markdown, organizzati per entità. Una cartella per l'azienda con storia, valori, team. Una per i servizi, con una scheda per ciascuno strutturata sempre nello stesso modo. Una per i casi studio. Una per i processi. Una per le faq, quelle vere, non quelle inventate dal marketing. Una per le policy. Tutto in testo semplice, leggibile senza browser, comprensibile senza contesto visivo. Il secondo layer è la struttura semantica. Tassonomie coerenti, relazioni esplicite tra le entità, naming degli url che abbia senso, microcopy pensato per rispondere a domande e non per impressionare. Questo è il layer che permette sia a un umano sia a una macchina di navigare l'informazione e di capire come i pezzi si collegano tra loro. Il terzo layer è l'esposizione. Un sito minimale, anche statico, che non aggiunge fronzoli ma rende navigabile ciò che esiste già come knowledge base. Da questo stesso layer si possono generare feed, api, file strutturati per agent. Il sito web diventa una delle possibili interfacce, non l'unica e nemmeno la principale. So cosa state pensando: ma questo funziona per un'azienda tech, non per un brand di moda, non per un ristorante, non per un'azienda che vive di immagine. E avete ragione, in parte. Ma solo in parte. Perché anche il brand di moda ha bisogno che un llm sappia descrivere chi è, cosa fa, qual è il suo posizionamento. Anche il ristorante ha bisogno che quando qualcuno chiede a un assistente "dove mangio bene pesce a Milano?" il sistema trovi informazioni chiare e affidabili. Anche l'azienda che vive di immagine ha bisogno che la sua immagine sia comprensibile oltre il visual. Il layer di presentazione sarà diverso, più ricco, più curato. Ma il layer informativo sottostante ha le stesse esigenze. C'è un aspetto di tutto questo che trovo controintuitivo e per questo particolarmente interessante: progettare per chi non ha occhi migliora l'esperienza anche per chi gli occhi li ha. Pensateci. Se vi costringete a scrivere contenuti che un llm può comprendere, state scrivendo contenuti chiari, concreti, strutturati. Niente slogan vuoti, niente giri di parole, niente fuffa. Un llm non si innamora delle vostre grafiche, ma premia testo coerente con esempi, casi reali, numeri, limiti. Sapete chi altro lo apprezza? Le persone che hanno poco tempo e vogliono capire velocemente se siete il fornitore giusto. Cioè praticamente tutti i vostri potenziali clienti. Se progettate un'architettura pulita per le macchine, state eliminando click inutili, pagine ridondanti, percorsi contorti. State creando quella che nel mondo seo si chiama struttura canonica, ma applicata all'intera narrativa del sito. E sapete cosa? È la stessa cosa che un utente umano vorrebbe: trovare quello che cerca senza perdersi in un labirinto. Se togliete le decorazioni inutili per rendere il sito leggibile a un crawler, state anche rendendolo più veloce, più accessibile, più usabile da mobile, più fruibile per chi naviga con connessioni lente o con dispositivi datati. L'accessibilità e la machine-readability sono quasi la stessa cosa, vista da angolazioni diverse. Eppure c'è una tensione reale che non voglio nascondere, perché sarebbe intellettualmente disonesto. Ogni volta che aggiungete un pop-up, migliorate forse del 2% il tasso di iscrizione alla newsletter, ma rendete la pagina opaca per ogni sistema di crawling, parsing, lettura sequenziale. Ogni volta che scrivete copy "furbo" ma vuoto, ottimo per il pitch in riunione interna, rendete impossibile a un modello capire cosa fate davvero. E se il modello non capisce, non vi citerà, non vi proporrà, non vi raccomanderà. Ogni volta che costruite un design "esperienziale" che spacca, con contenuti frammentati e sparpagliati in componenti javascript che si caricano in momenti diversi, per la macchina quello diventa rumore di fondo, un puzzle da ricostruire senza avere la scatola con l'immagine. Non sto dicendo che qualsiasi decisione presa per l'umano sia sbagliata. Sto dicendo che c'è un trade-off che quasi nessuno sta calcolando. E che quel trade-off, con il passare dei mesi, pende sempre più dalla parte delle macchine. Non perché le macchine siano più importanti degli umani, ma perché stanno diventando sempre di più e sempre meglio il canale attraverso cui gli umani arrivano a voi. A questo punto sento già le obiezioni. Le sento perché me le sono fatte io stesso, e perché conosco abbastanza bene il mondo del design e del marketing da sapere dove colpirebbero. "Così uccidiamo il brand." No. Il brand non è il gradient, non è la micro-animazione, non è il parallax scrolling. Il brand è la coerenza del messaggio, la qualità delle promesse mantenute, la chiarezza con cui comunicate chi siete. Anzi, vi dico di più: un sito pieno di fuochi d'artificio visivi ma con contenuti vuoti *danneggia* il brand, perché crea aspettative che poi l'esperienza reale non soddisfa. Il brand più forte è quello che dice cose vere, in modo chiaro, e le mantiene. "Diventa tutto freddo e tecnico." Questa mi fa sorridere, perché è esattamente il contrario. Quando togli gli slogan e le frasi fatte, quello che resta è spazio per una narrativa onesta. Casi reali con nomi e cognomi. Storie di progetti con i loro problemi e le loro soluzioni. Dettagli concreti che mostrano competenza vera, non dichiarata. I siti più "caldi" che ho visto non erano quelli con le foto stock di gente che sorride in ufficio. Erano quelli dove capivi esattamente con chi avresti lavorato e come. "Ma la concorrenza ha siti super fighi." E questo è esattamente il punto. Se tutti hanno siti super fighi e tutti dicono le stesse cose con le stesse parole, come vi differenziate? Forse il modo migliore per distinguervi è avere un sito che non dà mal di testa ai visitatori umani e che contemporaneamente diventa un alleato dei modelli che devono parlare di voi. Mentre la concorrenza investe in animazioni, voi investite in contenuto. Mentre loro ottimizzano per il wow, voi ottimizzate per la comprensione. È una scommessa, certo. Ma è una scommessa che mi sembra sempre meno rischiosa. Se fate vostra questa visione, e capisco che è un se grande, ecco cosa cambia nella pratica. La ux smette di essere un funnel manipolativo e diventa un percorso chiaro e prevedibile. Ogni elemento che non aggiunge informazione reale viene eliminato. Non perché sia brutto, ma perché è rumore. Le pagine non vengono duplicate per ogni campagna, il contenuto non viene frammentato in dieci micro-sezioni con titolini accattivanti. Si costruiscono percorsi canonici, lineari, che portano il visitatore, umano o macchina, dalla domanda alla risposta nel modo più diretto possibile. La seo cambia pelle completamente. Si passa dal keyword stuffing alla modellazione di entità e relazioni. Il contenuto deve avere senso anche se letto in plain text, senza stile, senza contesto visivo. Deve rispondere a domande reali, non a query inventate da un tool. E le faq smettono di essere quella sezione in fondo alla pagina che nessuno legge e diventano il cuore informativo del sito, perché sono esattamente il formato che un llm sa processare meglio. I contenuti seguono guideline interne rigide. Ogni servizio deve rispondere esplicitamente a: cosa è, per chi è, come funziona, cosa include, cosa esclude, quanto costa, che prove ci sono che funziona. Se non riesci a rispondere a tutte queste domande in modo chiaro, forse il problema non è il sito. È che non hai ancora pensato abbastanza bene a quello che offri. Le metriche cambiano. Meno ossessione per le pageview e il tempo sulla pagina, che sono metriche vanity nella maggior parte dei casi. Più attenzione alla qualità delle richieste che arrivano. I lead sono allineati con quello che fate davvero? I clienti arrivano già sapendo cosa chiedere? C'è coerenza tra ciò che il sito promette e ciò che il cliente si aspetta? Queste sono le metriche che contano. Voglio raccontare una storia che, anche se semplificata, è molto vicina a situazioni che ho visto con i miei occhi. Un'azienda di servizi b2b, una quindicina di persone, con un sito rifatto due anni fa da un'agenzia brava. Sito vistoso, font enormi, storytelling aziendale, hero video con drone, sezione "i nostri valori" con icone disegnate a mano. Tutto bellissimo. Ma se chiedevi a chiunque, compreso il fondatore, di spiegarti in tre frasi cosa faceva l'azienda leggendo solo il sito, non ci riusciva. Le pagine dei servizi erano piene di parole come "approccio integrato", "soluzioni end-to-end", "partner strategico". Informazione reale: zero. Hanno fatto un esperimento. Hanno preso tutto il testo del sito, lo hanno messo in un file, lo hanno dato a un llm chiedendo: chi siamo? Cosa facciamo? Per chi siamo la scelta giusta? Il risultato li ha sconvolti. Il modello aveva capito che facevano "consulenza" di qualche tipo, forse nel digitale, forse nella comunicazione, non era chiaro. Non aveva identificato nessun settore specifico, nessuna competenza distintiva, nessun caso concreto. In pratica, il sito da ottantamila euro raccontava la stessa storia di altri diecimila siti identici. Hanno riprogettato tutto partendo dal contenuto. Hanno riscritto ogni pagina rispondendo alle domande: cosa facciamo esattamente, per chi, come, quanto costa, cosa non facciamo. Hanno documentato i casi studio con numeri veri: problema, soluzione, risultato misurabile. Hanno messo la lista dei settori in cui hanno esperienza e, altrettanto importante, quelli in cui non ne hanno. Il design è diventato minimale, quasi spartano. Il copy è diventato diretto, a tratti brutale nella sua onestà. Il risultato non è stato solo un miglior ranking e una migliore comprensione da parte degli strumenti. Sono arrivati lead diversi. Più qualificati, più consapevoli, che sapevano già cosa chiedere. Le call commerciali sono diventate più brevi perché i clienti arrivavano già con un'idea precisa di cosa aspettarsi. Il tasso di conversione è salito non perché il sito fosse più persuasivo, ma perché attraeva le persone giuste e allontanava quelle sbagliate. Che poi è esattamente quello che un buon sito dovrebbe fare. ## **Il sito come prompt persistente** {: #il-sito-come-prompt-persistente } C'è un aspetto di tutto questo che mi spinge a guardare un po' più avanti nel tempo, e che mi sembra il più strategico di tutti. Il vostro sito sta diventando un prompt persistente. È il testo che addestra gli llm su come parlare della vostra azienda. Ogni parola che pubblicate, ogni informazione che rendete disponibile, ogni assenza che lasciate, contribuisce a formare la rappresentazione che i modelli di linguaggio hanno di voi. Se non lo dite chiaramente voi sul vostro sito, lo inventerà qualcun altro. O peggio, lo inventerà il modello stesso, riempiendo i vuoti con quello che trova altrove, o con la soluzione statisticamente più probabile, che quasi mai è quella giusta. Pensate a quante interazioni stanno già avvenendo senza che l'utente visiti il vostro sito. Qualcuno chiede a un assistente ai: "quale azienda mi consigli per questo tipo di servizio?" L'assistente consulta le sue fonti, tra cui il vostro sito, e formula una risposta. Se il vostro sito è un monumento allo storytelling emozionale ma non contiene informazioni concrete, la risposta sarà vaga, generica, oppure vi escluderà del tutto a favore di un competitor che ha un sito meno bello ma più chiaro. Sempre più spesso il flusso sarà questo: cliente parla con agent, agent legge il sito, agent sintetizza una risposta, cliente decide sulla base di quella sintesi. Il vostro sito non sarà più il punto di arrivo del cliente. Sarà una fonte di dati per un intermediario. E come ogni fonte di dati, verrà giudicata sulla qualità, completezza e affidabilità delle informazioni, non sulla bellezza di contenitore e contenuti. Questo rende ancora più strategica la chiarezza del contenuto grezzo rispetto a qualsiasi campagna, hero video, storytelling patinato. Il vostro contenuto grezzo è quello che il mondo vedrà di voi attraverso le macchine. È il vostro volto per chi non ha occhi. Se siete arrivati fin qui, vi propongo un esercizio che è anche una call to action un po' spietata. Fatelo oggi, ci vogliono dieci minuti. Prendete tutto il testo del vostro sito. Solo il testo, senza grafica, senza layout, senza colori. Mettetelo in un file e datelo a un llm. Chiedetegli: chi siamo? Cosa facciamo? Per chi siamo la scelta giusta? Perché un potenziale cliente dovrebbe sceglierci? Se non vi riconoscete nella risposta, il problema è grave. Non è un problema di seo, non è un problema di design, non è un problema di marketing. È un problema di identità. Il vostro sito non sa raccontare chi siete, e in un mondo dove gli llm sono sempre più spesso il primo punto di contatto, questo significa che nessuno saprà chi siete. La domanda da porsi non è più "come rendiamo più engaging il sito?". La domanda è: come facciamo sì che chiunque, umano o macchina, capisca al volo chi siamo e perché contiamo? Se il vostro visitatore più importante non ha occhi, forse è ora di smettere di progettare solo per chi guarda e cominciare a progettare per chi capisce. --- # Come la GenAI ha cambiato definitivamente il nostro rapporto coi prodotti digitali - **URL:** https://margiovanni.it/it/blog/dal-markdown-al-wysiwyg-cms-su-misura/ - **Pubblicato:** 2026-02-14 - **Tag:** AI, Claude Code, Development, Product - **Tempo di lettura:** 6 min > Si fa prima a costruire un CMS personalizzato che a pensare a soluzioni già fatte: in 25 minuti con AI ho trasformato il mio blog Astro in un sistema dinamico, sicuro e intuitivo. Zero frizioni, totale controllo. Fino a qualche settimana fa, scrivere un articolo per questo blog significava aprire l'editor di codice, creare un file markdown in una cartella specifica, controllare che il frontmatter fosse giusto, fare commit, push, aspettare il deploy. Per un articolo. Ogni volta. Non era terribile: funzionava. Ma era scomodo in quel modo subdolo che ti fa rimandare le cose. "Scrivo quel pezzo domani", che poi diventa la prossima settimana, che poi non lo scrivi mai. ## **Il vecchio sistema: bello in teoria, scomodo in pratica** {: #il-vecchio-sistema-bello-in-teoria-scomodo-in-pratica } ![](/media/images/1771136010757-1760ic.png)Il sito girava su Astro con pagine statiche. Gli articoli erano file `.md` in una cartella del progetto. Ogni post aveva il suo frontmatter YAML in cima (titolo, data, tag, descrizione, immagine) e poi il contenuto in markdown. Per pubblicare serviva: 1. Aprire VS Code 2. Creare il file nella cartella giusta, col nome giusto 3. Scrivere il frontmatter senza errori (una virgola fuori posto e il build esplodeva) 4. Scrivere il contenuto in markdown 5. Testare in locale che tutto fosse a posto 6. Committare, pushare, aspettare il deploy su Cloudflare Pages Sei passaggi. Per pubblicare un pensiero. E non parliamo di modificare un articolo esistente: trovare il file, aprirlo, editare, ri-committare, ri-pushare. O di caricare un'immagine: salvarla nella cartella `public`, referenziarla con il path relativo nel markdown, sperare di non aver sbagliato il percorso. Funzionava, sì. Ma ogni volta c'era quella frizione che trasformava un'operazione da cinque minuti in un rituale da venti. E la frizione, nel tempo, uccide la costanza. ## **L 'idea: e se mi costruissi un pannello admin?** {: #l-idea-e-se-mi-costruissi-un-pannello-admin } A un certo punto mi sono chiesto: quanto ci vorrebbe a farmi un pannello di amministrazione decente? Non WordPress, non Ghost, non un CMS headless con abbonamento mensile. Qualcosa di mio, che faccia esattamente quello che serve, niente di più. La risposta tradizionale sarebbe stata: tanto. Giorni di lavoro per farlo o settimane per adattare un CMS esistente, con le sue opinioni su come dovrebbero funzionare le cose, le sue dipendenze, i suoi aggiornamenti da gestire. Ma la risposta nel 2026 è diversa. ## **Costruire è diventato più veloce che scegliere** {: #costruire-e-diventato-piu-veloce-che-scegliere } ![](/media/images/1771136166224-zkgig5.png)![](/media/images/1771136082006-ku1059.png)![](/media/images/1771136096156-irdb3s.png)Quello che ho fatto è stato sedermi con Claude Code (uno strumento di AI generativa applicata al codice) e costruirmi il sistema pezzo per pezzo. Non generando codice a caso da copiare e incollare, ma lavorandoci insieme come si farebbe con un collega molto competente e molto veloce. Il risultato è un pannello admin completo che mi permette di: * **Scrivere articoli con un editor WYSIWYG** : niente più markdown a mano, scrivo come in un editor di testo normale, con toolbar per grassetto, corsivo, titoli, liste, citazioni, codice, link e immagini * **Trascinare le immagini direttamente nell 'editor**: le carica automaticamente su Cloudflare R2 e le inserisce nel punto giusto * **Gestire metadati in una sidebar chiara** : stato di pubblicazione, data, tag, immagine di copertina, tutto a portata di mano * **Salvare con un click** : come in qualsiasi applicazione normale * **Vedere la lista degli articoli** in una dashboard con statistiche immediate E tutto questo salva i contenuti come markdown nel database, quindi il frontend del blog li renderizza esattamente come prima. ## **Cosa c 'è sotto il cofano** {: #cosa-c-e-sotto-il-cofano } ![](/media/images/1771136209509-msxruw.png)Per chi è curioso della parte tecnica: il sito continua a girare su Astro, ma è passato dalla generazione statica al server-side rendering su Cloudflare Workers. Questo significa che le pagine vengono generate al volo quando qualcuno le visita (per la prima volta), il che mi permette di avere contenuti dinamici senza rinunciare alla velocità. I dati vivono su **Cloudflare D1** , un database SQLite distribuito sul edge network di Cloudflare. Le immagini su **Cloudflare R2** , uno storage oggetti compatibile S3. L'autenticazione usa **JWT** con token firmati via Web Crypto API. L'editor WYSIWYG è basato su **Tiptap** , un framework di editing costruito su ProseMirror (lo stesso motore che sta sotto editor come Notion). L'aspetto interessante è che sotto il WYSIWYG i contenuti vengono convertiti in markdown pulito grazie a un'estensione dedicata. Scrivo visualmente, salvo in un formato portabile. Per la sicurezza, perché un pannello admin esposto su internet deve essere sicuro, ci sono: * **Cloudflare Turnstile** sulla pagina di login (il successore invisibile del CAPTCHA) * **Rate limiting** per prevenire attacchi brute force * **Validazione rigorosa** di ogni input, ogni upload, ogni percorso file * **Confronto a tempo costante** delle credenziali, per prevenire attacchi di timing * **Verifica dei magic bytes** sui file caricati, non solo dell'estensione Nessun framework admin, nessun plugin, nessuna dipendenza pesante. Solo il codice che serve, dove serve. ## **Il vero cambiamento non è tecnico** {: #il-vero-cambiamento-non-e-tecnico } La parte interessante di questa storia non è la tecnologia. È il cambiamento nel calcolo costi-benefici. Fino a poco tempo fa, davanti a un'esigenza come questa le opzioni erano: 1. **Adattare qualcosa di esistente** : WordPress, Ghost, Strapi, decine di CMS con le loro opinioni, le loro curve di apprendimento, i loro costi ricorrenti, le loro vulnerabilità da aggiornare 2. **Farselo fare** : un preventivo, tempi di attesa, iterazioni di feedback, compromessi su come "il framework vuole che funzioni" 3. **Farselo da soli** : settimane di lavoro, testing, debugging, con il rischio concreto di mollare a metà Oggi c'è una quarta opzione: **costruirselo, con l 'AI come acceleratore**. Non come sostituto del pensiero, ma come amplificatore della capacità di esecuzione. Io sapevo cosa volevo. Sapevo come doveva funzionare, che esperienza d'uso cercavo, quali compromessi ero disposto a fare. L'AI ha trasformato quella visione in codice funzionante a una velocità che prima era semplicemente impossibile per una persona sola. E non è codice "generato": è codice che ho guidato, rivisto, testato, e che capisco riga per riga. Perché il punto non è delegare il pensiero: è delegare la battitura. ## **Si fa prima a farla che a chiedere un preventivo** {: #si-fa-prima-a-farla-che-a-chiedere-un-preventivo } Questa frase suona provocatoria, ma per una certa categoria di progetti sta diventando letteralmente vera. **Non sto parlando di sistemi enterprise, piattaforme con migliaia di utenti, o software mission-critical**. Sto parlando di tutti quei progetti "medi" che prima cadevano in una terra di nessuno: troppo specifici per una soluzione off-the-shelf, troppo piccoli per giustificare un investimento serio, troppo tediosi per farseli a mano. Il mio pannello admin è esattamente in quella categoria. Nessun CMS esistente avrebbe fatto esattamente quello che volevo nel modo in cui lo volevo. Farlo fare a qualcuno avrebbe richiesto brief, preventivi, revisioni, deploy. Farlo da solo a mano avrebbe richiesto settimane rubate alle sere e ai weekend. Invece l'ho costruito in 25 minuti. Funziona. È mio. Fa esattamente quello che serve. E se domani voglio cambiare qualcosa, posso farlo in minuti. ## **Il futuro è fatto su misura** {: #il-futuro-e-fatto-su-misura } Credo che stiamo entrando in un'era in cui il software su misura diventa accessibile a chiunque abbia una visione chiara di cosa vuole e decenti capacità tecniche. Non serve più essere un team di sviluppatori. Non serve più un budget importante. Serve sapere cosa si vuole e saper guidare lo strumento. È come il passaggio dalla sartoria artigianale al prêt-à-porter, **ma al contrario** : stiamo tornando al su misura, solo che ora il sarto è velocissimo e costa una frazione di prima. Per chi lavora nel digitale (sviluppatori, designer, marketer, imprenditori) questo cambia ovviamente i calcoli. --- # Chi controlla cosa producono gli agenti AI? - **URL:** https://margiovanni.it/it/blog/chi-controlla-cosa-producono-gli/ - **Pubblicato:** 2026-02-04 - **Tag:** Agenti AI, Etica, Intelligenza Artificiale - **Tempo di lettura:** 8 min > C’è una domanda che mi gira in testa da settimane, una di quelle domande che ti vengono alle undici di sera quando stai... ![](https://substackcdn.com/image/fetch/$s_!XK6c!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fae1632b6-af0b-4412-b8a0-ba1d3d95b186_5352x3648.jpeg) *Photo by Frans van Heerden:* C’è una domanda che mi gira in testa da settimane, una di quelle domande che ti vengono alle undici di sera quando stai ripensando a tutto quello che è stato prodotto durante la giornata. La domanda è semplice, quasi banale nella sua formulazione: come governiamo ciò che non riusciamo più a leggere? Non parlo in astratto. Parlo di quello che succede ogni giorno nelle organizzazioni che usano agenti ai. Parlo di pull request che contengono modifiche generate automaticamente, di documenti di specifica co-scritti con Claude, di configurazioni suggerite da sistemi che comprendono l’infrastruttura meglio di quanto la comprenda chi deve approvarle. Parlo di quella sensazione sottile, quasi impercettibile, di star approvando cose che si capiscono solo in parte. Il fatto che non esista una risposta pulita a questa domanda è già di per sé significativo. E il fatto che la stessa domanda venga posta sempre più spesso, nei consigli di amministrazione, negli uffici legali, nei team di compliance, suggerisce che stiamo attraversando un punto di non ritorno. Non un’evoluzione graduale. Un punto di non ritorno. ## Il presupposto che crolla {: #presupposto-che-crolla } La governance tradizionale si regge su un presupposto così radicato da essere diventato invisibile: che ci sia tempo sufficiente per capire cosa è stato prodotto prima che venga messo in produzione. Revisione del codice. Audit dei documenti. Approvazione dei contratti. Validazione delle analisi. Firma sui deliverable. Tutto questo ha funzionato per decenni perché il collo di bottiglia era la produzione. Il tempo necessario per creare qualcosa era sufficientemente lungo da permettere al processo di validazione di stargli dietro. Ma quando un sistema AI genera in minuti quello che prima richiedeva settimane, quel presupposto crolla. Non si piega, non si adatta: crolla. E questo non riguarda solo il codice. Riguarda tutto. ## Dove crolla, in pratica {: #dove-crolla } Penso ai documenti contrattuali. Un agente ai può oggi redigere bozze di contratti, clausole specifiche, risposte a contestazioni, pareri preliminari. La qualità è spesso sufficientemente plausibile da superare una lettura veloce. Ma sufficientemente plausibile in ambito legale può significare clausole che sembrano tutelanti ma non lo sono, riferimenti normativi obsoleti presentati con sicurezza, omissioni che emergono solo in caso di contenzioso. Il rischio non è l’errore macroscopico. È la sottigliezza dell’errore in un contesto dove la sottigliezza è tutto. Penso alle analisi finanziarie. Dashboard, proiezioni, analisi di scenario, business case. Un CFO che riceve un’analisi generata o co-generata da AI sta approvando qualcosa che comprende? O sta validando la plausibilità superficiale di numeri che seguono una logica che nessuno ha realmente verificato? Il problema non è se i numeri tornano. Il problema è se le assunzioni sottostanti sono corrette, se i modelli applicati sono appropriati, se le fonti dati sono affidabili. Tutte cose che richiedono competenza di dominio per essere valutate, competenza che il processo di review presuppone ma che la velocità di produzione rende sempre più difficile applicare. Penso alle comunicazioni esterne. Email a clienti, risposte a bandi, documentazione di prodotto, manuali d’uso, policy interne. Ogni organizzazione produce quotidianamente migliaia di artefatti testuali. Quando una parte significativa di questi viene generata o assistita da AI, chi garantisce la coerenza con il posizionamento aziendale? Chi verifica che una risposta a un cliente non crei aspettative che poi l’organizzazione non può soddisfare? E poi c’è la compliance. Qui il paradosso è massimo. Siamo nel pieno dell’ondata regolatoria europea: AI Act, Cyber Resilience Act, Product Liability Directive, EAA, GDPR che continua a evolversi. Le organizzazioni devono produrre documentazione di compliance, valutazioni di rischio, registri, policy. La tentazione di usare AI per accelerare questa produzione è fortissima. Ma stiamo parlando di documenti che attestano la conformità a norme che, in alcuni casi, riguardano proprio l’uso dell’AI. C’è qualcosa di circolare e perturbante nell’usare un sistema AI per dichiarare che i propri sistemi AI sono conformi alle regole sull’AI. ## Un problema epistemologico organizzativo {: #problema-epistemologico } Il problema non è solo la velocità. È il volume combinato con l’opacità. Un team che usa AI per generare codice, configurazioni, documenti, analisi, comunicazioni, decisioni architetturali produce una quantità di artefatti che nessun processo di review umano può realisticamente coprire al cento per cento. E forse nemmeno al cinquanta. E forse nemmeno al venti, se siamo onesti con noi stessi. Ma il problema peggiore è un altro: molti di quegli artefatti sono sufficientemente plausibili da passare un controllo superficiale. Il che è quasi peggio che se fossero palesemente sbagliati. Un errore evidente viene intercettato. Un errore plausibile viene approvato, deployato, pubblicato, firmato, e scoperto solo quando produce conseguenze. Mi rendo conto che **stiamo affrontando quello che si potrebbe chiamare un problema epistemologico organizzativo** : l’organizzazione sa meno di quello che produce. E il gap si allarga ogni giorno. ## Tre direzioni, nessuna risolutiva {: #tre-direzioni } Non ho soluzioni definitive. Nessuno le ha, e chi dice di averle probabilmente sta sottovalutando il problema. Ma ci sono alcune direzioni che sembrano sensate, anche se nessuna è risolutiva. La prima è quella che si potrebbe chiamare il **passaggio dal controllo puntuale al controllo strutturale**. Se non puoi controllare ogni output, devi controllare il sistema che produce gli output. Significa investire molto di più nella definizione di vincoli a monte, specifiche rigorose, guardrail automatizzati, policy as code, piuttosto che nella revisione a valle. È il senso dello spec-driven development: se la specifica è solida, il range di errore dell’output si restringe. Non si elimina, ma si contiene. Per i documenti legali, significa template verificati con placeholder chiari, non generazione libera. Per le analisi finanziarie, significa modelli validati con input controllati, non fogli bianchi. Per le configurazioni, significa baseline certificate con variazioni esplicite e giustificate. Il principio sottostante è semplice: sposta l’intelligenza, e quindi la responsabilità, nella definizione del problema, non nella generazione della soluzione. La seconda direzione riguarda cosa verifichiamo. Non puoi leggere tutto il codice generato. Non puoi rileggere ogni documento. Non puoi ricontrollare ogni analisi. Ma puoi definire invarianti che devono essere rispettati e testarli automaticamente. Per il codice: test automatizzati, type checking, analisi statica, verifiche di sicurezza. Per i documenti: checklist automatizzate, validazione di struttura, controlli di coerenza terminologica. Per le configurazioni: policy di compliance as code, drift detection, validazione pre-deploy. **È un cambio di paradigma: passi dal “ho letto e approvato questo artefatto” a “questo artefatto rispetta queste proprietà verificabili”.** Che poi è quello che già facciamo con i test automatizzati nel software. Solo che ora diventa l’unica linea di difesa realistica per tutto. Il limite è ovvio: le proprietà verificabili sono un sottoinsieme delle proprietà desiderabili. Puoi verificare che un contratto contenga certe clausole, non che sia strategicamente appropriato. Puoi verificare che un’analisi sia internamente coerente, non che le assunzioni siano corrette. Ma è comunque molto meglio di niente. La terza direzione è forse la più scomoda da accettare: AI che controlla AI. Reviewer automatici. Validatori specializzati. Sistemi che verificano l’output di altri sistemi. Il problema ricorsivo è ovvio: chi controlla i controllori? Se non mi fido dell’output dell’AI che produce, perché dovrei fidarmi dell’output dell’AI che verifica? Ma probabilmente è inevitabile. E la domanda diventa: come mantenere punti di intervento umano nei momenti che contano davvero? La mia ipotesi, ancora da verificare sul campo, è che il ruolo umano si sposterà verso le decisioni architetturali, le scelte etiche, la gestione delle eccezioni, la calibrazione dei sistemi di controllo. È un ruolo diverso. Meno operativo, più strategico. Meno fare e più decidere le regole del fare. ## Il rischio organizzativo {: #rischio-organizzativo } Cosa mi preoccupa di più in tutto questo? Non è tanto il rischio tecnico. I bug si trovano. Gli errori nei documenti emergono. Le configurazioni sbagliate si manifestano. Quello che mi preoccupa è il rischio organizzativo: team che si abituano a fidarsi degli output senza capirli, che perdono gradualmente la capacità di valutare cosa stanno approvando. Lo vedo già. Sviluppatori che accettano codice generato senza leggerlo. Manager che approvano analisi senza verificare le assunzioni. Responsabili compliance che firmano documenti che hanno solo scorso. È comprensibile, siamo tutti sotto pressione, tutti con più cose da fare di quante ne possiamo gestire. Ma è anche pericoloso. La governance più importante forse non è quella sui sistemi, ma quella sulle competenze delle persone che dovrebbero governarli. **Se perdiamo la capacità di capire cosa stiamo producendo, perdiamo la capacità di governarlo.** Indipendentemente da quanti layer di controllo automatizzato mettiamo in mezzo. ## Chi risponde, e come navigare l'incertezza {: #chi-risponde } C’è poi una questione che in Italia, e in Europa con l’ai Act, diventa particolarmente pressante: chi è responsabile? Quando un contratto generato da ai contiene un errore che causa un danno, chi risponde? L’operatore che l’ha usato? Il fornitore del sistema AI? Il manager che ha approvato? L’organizzazione nel suo complesso? Quando una configurazione suggerita da AI crea una vulnerabilità di sicurezza, la catena di responsabilità diventa improvvisamente molto importante. Il framework normativo europeo sta cercando di dare risposte. L’AI Act definisce obblighi per fornitori e deployer. La Product Liability Directive estende la responsabilità per prodotti difettosi. Il Cyber Resilience Act introduce requisiti di sicurezza by design. Ma la verità è che la normativa corre dietro alla tecnologia, e nel frattempo le organizzazioni devono prendere decisioni. Decisioni che avranno conseguenze legali basate su regole che ancora non sono completamente chiare. Quello che si può fare è costruire traceability. Sapere quali artefatti sono stati generati o influenzati da AI, con quali prompt, in quali condizioni. Non risolve il problema della responsabilità, ma almeno permette di ricostruire cosa è successo. Scrivo tutto questo e mi rendo conto di quanto sia incerto il terreno su cui ci muoviamo tutti. Ci sono principi operativi che sembrano sensati: presunzione di controllo strutturale, invarianti espliciti, tracciabilità obbligatoria, intervento umano strategico, competenza come prerequisito, accettazione dell’incertezza. Ma sono principi in costruzione, imperfetti, in evoluzione, probabilmente destinati a essere superati rapidamente dalla velocità del cambiamento. E c’è qualcosa di profondamente frustrante in questa situazione. Per anni chi lavora in questo campo ha avuto il compito di trovare soluzioni, dare risposte, avere un piano chiaro. Adesso ci troviamo a navigare un territorio dove le domande sono più chiare delle risposte, dove ogni soluzione apre nuovi problemi, dove la cosa più onesta che si può dire è “non lo so, ma sto cercando di capire”. Forse è questo il nuovo ruolo di chi governa sistemi complessi: non avere tutte le risposte, ma fare le domande giuste e costruire strutture che permettano di adattarsi quando le risposte cambiano. È meno rassicurante di un framework definito con cinque best practice e tre pillar strategici. Ma è l’unica governance onesta possibile quando il mondo produce più velocemente di quanto riusciamo a capire. Mi chiedo spesso dove sentono di più la tensione gli altri che sono in mezzo a questa trasformazione. Sulla velocità di produzione, sulla capacità di valutazione, o su qualcosa di completamente diverso che non sto ancora vedendo. Perché forse la cosa che mi preoccupa di più è proprio questa: non sapere cosa non sto vedendo. --- # Da developer a product owner: la trasformazione necessaria nell'era dell'ai - **URL:** https://margiovanni.it/it/blog/da-developer-a-product-owner-la-trasformazione/ - **Pubblicato:** 2026-01-24 - **Tag:** Intelligenza Artificiale, Sviluppo Software, Trasformazione Digitale - **Tempo di lettura:** 6 min > Qualche giorno fa un collega del mio team che usa Claude Code ha implementato una feature che, quando facevo il suo... ![](https://substackcdn.com/image/fetch/$s_!QSPr!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc3e8b7de-a798-4557-854f-24901d5c21d9_6124x4083.jpeg) *Foto di Tara Winstead:* Qualche giorno fa un collega del mio team che usa Claude Code ha implementato una feature che, quando facevo il suo lavoro, mi avrebbe richiesto più di mezza giornata. Lui l’ha completata in quaranta minuti, con qualità e sicurezza. E mentre ci pensavo, non stavo pensando a quanto fosse forte lo strumento. Stavo pensando a quanto il mio percorso professionale, quella transizione da developer a ruoli di product ownership e maggiore leadership che ho fatto negli ultimi anni, si stia rivelando più preveggente di quanto avessi immaginato. Non l’ho fatto per lungimiranza, sia chiaro. L’ho fatto perché a un certo punto scrivere codice tutto il giorno aveva smesso di darmi quello che cercavo. Volevo capire il perché delle cose, non solo il come. Volevo essere nella stanza quando si decideva cosa costruire, non solo ricevere ticket da implementare. È stata una scelta istintiva, in parte egoistica. Ma col senno di poi, mi ha posizionato in un punto interessante per osservare quello che sta succedendo in questo periodo. ## Il valore migra dal come al cosa {: #il-valore-migra } Il punto di inflessione in cui ci troviamo non riguarda l’ai che “ruba il lavoro ai programmatori”, come si legge nei titoli sensazionalistici. **Riguarda qualcosa di più sottile: il valore si sta spostando. Sta migrando dal *****come***** al *****cosa *** **e al *****perché*****.** E io lo vedo ogni giorno, nelle conversazioni con gli altri professionisti e manager che conosco, nelle scelte di hiring che sono già cambiate, nel modo in cui ormai è necessario strutturare i team. Le aziende non si chiedono più “quanti developer posso assumere”. Si chiedono “come massimizziamo la produttività con team più piccoli e strumenti migliori”. È un cambio di prospettiva radicale. Nel mio ruolo, mi trovo sempre più spesso a ragionare su come integrare agenti ai nei workflow esistenti piuttosto che su come scalare il team. E questo ha implicazioni enormi per chi oggi scrive codice come attività principale. Gli agenti ai autonomi che si usano quotidianamente non sono autocomplete glorificati. Fanno cose che fino a due anni fa sembravano fantascienza: prendono un problema mal definito, lo scompongono, cercano contesto nel codebase, implementano, testano, iterano. Li supervisioniamo, certo. Li correggiamo, spesso. Ma la quantità di lavoro che riescono a produrre, con la giusta guida, è impressionante. E questo cambia tutto. ## Cosa cerco oggi nei team {: #cosa-cerco-nei-team } Nel selezionare candidati o valutare le performance del team, dobbiamo cambiare radicalmente le domande che ci facciamo. Non mi interessa più tanto quanto velocemente qualcuno scrive codice. Mi interessa quanto bene capisce il problema che stiamo risolvendo. Mi interessa se fa le domande giuste prima di iniziare, se anticipa i casi limite, se riesce a spiegarmi le sue scelte in termini che hanno senso per il business. Queste sono le cose che l’ai non sa ancora fare bene. Conosco professionisti che si rifiutano di usare Copilot o Claude Code perché “preferiscono scrivere tutto da soli”. Li capisco, davvero. Vengo da lì, conosco quella sensazione di controllo totale, quell’appagamento nel vedere il codice nascere dalle tue dita. Ma da dove sto adesso, vedo anche il rischio. È un po’ come i tipografi che rifiutavano il desktop publishing perché amavano il piombo. Romantico, certo. Sostenibile economicamente, molto meno. La transizione da developer a product owner, o comunque a ruoli dove definisci il cosa invece di implementare il come, non significa smettere di essere tecnici. Anzi, nella mia esperienza richiede *più* competenza tecnica, non meno. Ma una competenza diversa: devo sapere cosa è possibile, cosa è costoso, cosa è rischioso, senza necessariamente essere io a implementarlo. Bisogna guidare l’ai e gli agent come un direttore d’orchestra guida i musicisti: non suoni ogni strumento, ma devi sapere come dovrebbe suonare ogni strumento. I developer che vedo fare meglio questa transizione hanno caratteristiche che riconosco in me stesso. Non sono necessariamente i più brillanti tecnicamente. Sono quelli che hanno sempre fatto tante domande, quelli che volevano capire il perché dietro ogni feature, quelli che si irritavano quando ricevevano spec vaghe. Sono quelli che hanno sempre pensato al prodotto, anche quando il loro ruolo ufficiale era solo scrivere codice. Se ti riconosci in questa descrizione, probabilmente hai già metà del lavoro fatto. C’è poi la questione delle competenze relazionali, e qui devo ammettere che il passaggio è stato duro anche per me. Per anni ho evitato le riunioni con gli stakeholder business, le ho viste come interruzioni del “vero lavoro”. Adesso *sono* il mio lavoro. Tradurre il linguaggio tecnico in termini che un cfo possa capire, negoziare priorità con un team di marketing/commerciale che vuole tutto per ieri, spiegare a un amministratore perché quella feature “semplice” richiede tre mesi: queste sono competenze che nessuna ai sa ancora fare, e forse non saprà fare mai. E sono quelle che mi rendono di grande valore oggi. ## Specificare è il nuovo mestiere {: #specificare-e-il-mestiere } Una cosa che ho imparato sul campo è che la qualità dei requisiti che dai all’ai determina la qualità dell’output che ottieni. Sembra ovvio, ma le implicazioni sono profonde. Quando scrivo spec precise, contestualizzate, con i giusti vincoli e le giuste libertà, ottengo codice che funziona. Quando sono vago, incompleto, contraddittorio, ottengo spazzatura. Questo significa che la competenza critica non è più “saper codare”, è “saper specificare”. E specificare bene richiede una comprensione profonda sia del dominio tecnico che di quello business. Ho già visto team piccoli, cinque persone al massimo, produrre output equivalente a team di dodici semplicemente perché avevano qualcuno che sapeva definire i task nel modo giusto. Non parlo di documentazione formale, di diagrammi uml o specifiche tecniche di cento pagine. Parlo di quella capacità di articolare cosa serve davvero, di fare le domande giuste prima di iniziare, di anticipare i problemi. È una skill che si può imparare, ma richiede un cambio di mindset. ## Il salto richiede umiltà e coraggio {: #il-salto } Detto questo, non voglio dipingere un quadro troppo roseo. La transizione che ho fatto io non è stata lineare, e vedo colleghi che faticano enormemente. Richiede umiltà: accettare che qualcosa che sapevi fare bene sta perdendo valore relativo, e che devi investire in competenze diverse. Richiede anche coraggio: uscire dalla comfort zone del codice, dove le cose sono deterministiche e controllabili, per entrare nel mondo ambiguo delle decisioni di prodotto, dove hai sempre informazioni incomplete e stakeholder con agende contrastanti. C’è anche una dimensione etica in tutto questo che mi preoccupa e mi affascina. Usare l’ai per accelerare lo sviluppo non è neutrale. Ci sono bias nei modelli, ci sono implicazioni sulla qualità del codice prodotto, sulla sicurezza, sulla manutenibilità. Bisogna essere anche un po’ paranoici, bisogna sapere quando l’ai sta facendo qualcosa di sbagliato anche se tecnicamente funziona. È una responsabilità nuova, che richiede consapevolezza e intenzionalità. Non puoi delegare tutto e sperare che vada bene. ## La scommessa da fare ora {: #la-scommessa } **Quello che vedo dal mio punto di osservazione è che i ruoli di leadership tecnica, product management, tech strategy saranno sempre più richiesti e sempre più difficili da riempire.** **Chi viene dal coding ha un vantaggio competitivo enorme rispetto a chi arriva dal business puro: capisce cosa è possibile, cosa è costoso, cosa è rischioso. Ma deve fare il salto. Deve smettere di identificarsi con le righe di codice che scrive e iniziare a identificarsi con i problemi che risolve.** Il falso mito che sento più spesso dai developer con cui parlo è “non ho tempo per imparare queste cose”. Ma il tempo che risparmi usando l’ai per scrivere codice, dove va? Se lo reinvesti nel perfezionare ulteriormente le tue skill di coding, stai ottimizzando qualcosa che sta diventando una commodity. Se lo reinvesti nell’imparare a pensare come un product owner, stai costruendo la tua rilevanza futura. La domanda che mi facevo anni fa, quando ho iniziato questa transizione, era “cosa voglio fare tra cinque anni?”. La risposta non era “scrivere codice ancora più velocemente”. Era “avere più impatto, capire meglio il business, essere nella stanza dove si prendono le decisioni”. Quella domanda oggi è ancora più urgente per chi è all’inizio del percorso. Il futuro appartiene a chi sa definire cosa costruire, non solo a chi sa costruirlo. Io ho fatto questa scommessa qualche anno fa, senza sapere quanto sarebbe diventata rilevante. **Per chi legge oggi, il vantaggio è che può farla con più consapevolezza. Ma deve farla.** --- # Dal software al dato, trasformandoci. - **URL:** https://margiovanni.it/it/blog/dal-software-al-dato-trasformandoci/ - **Pubblicato:** 2026-01-21 - **Tag:** Intelligenza Artificiale, Sviluppo Software, Trasformazione Digitale - **Tempo di lettura:** 9 min > Qualche notte fa ho letto un articolo. Si intitola The Death of Software 2.0 e usa una metafora che mi è rimasta in... ![](https://substackcdn.com/image/fetch/$s_!ZQ2c!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb9d40b58-982c-404f-b18f-f49a58a3ef11_5472x3648.jpeg) *Foto di Karola G:* Qualche notte fa ho letto un articolo. Si intitola [The Death of Software 2.0]() e usa una metafora che mi è rimasta in testa: paragona il software del futuro alle gerarchie di memoria dei computer. La memoria veloce ed effimera, quella che chiamiamo dram, sarebbe l’intelligenza artificiale che processa in modo non deterministico. La memoria persistente, la nand, sarebbe il dato strutturato, le api, quella che chiamiamo single source of truth. La conclusione dell’autore è brutale: **il software orientato all’interfaccia utente sta diventando obsoleto**. Ciò che avrà valore sono i dati e le api attraverso cui gli agenti ai accedono ai sistemi. Leggendo quell’articolo qualcosa ha fatto click nella mia testa. Non perché fosse una teoria affascinante. Perché descriveva esattamente quello che sto cominciando a fare nel mio lavoro, quello che sento necessario fare, anche se una parte di me resiste ancora. Ho passato quindici anni a costruire software con una logica di valore semplice: prima l’interfaccia, poi l’api. Dal punto di vista del cliente la UI era il prodotto, l’API un’aggiunta, un complemento per gli integratori, qualcosa da documentare quando avanzava tempo. Questo modello funzionava perché il software doveva essere usato da persone. **Ora non è più così, o almeno non è più solo così**. ## Gli agenti non cliccano {: #agents-dont-click } Claude, ChatGPT, Gemini, gli agenti ai, gli strumenti agentic in generale non usano il software come lo usa un umano. Non cliccano pulsanti. Non seguono flussi di ux. Non si confondono con i diciassette casi edge nella form di checkout che ho passato settimane a gestire. Hanno bisogno di tre cose: dati strutturati e accessibili tramite API ben disegnate, contesto persistente che possono comprendere in una conversazione, azioni deterministiche e ripetibili che possono orchestrare senza errori. **Se il prodotto che costruisci non è pensato attorno a questi tre pilastri, lo stai costruendo per il 2015**. E qui devo essere onesto con me stesso. Per anni ho messo l’anima nelle interfacce. Ho discusso per ore su quale fosse il colore giusto per un bottone, su come organizzare un menu, su quale microinterazione avrebbe reso l’esperienza più fluida. Non era tempo sprecato, lungi da me dire questo. Ma mi chiedo se non stessi costruendo cattedrali su fondamenta che stavano già iniziando a tremare. ## MCP come ponte {: #mcp-as-bridge } Il Model Context Protocol è lo standard che Anthropic ha rilasciato a novembre 2024. Lo hanno adottato immediatamente OpenAI e Google. È il ponte standardizzato tra un’intelligenza artificiale e i sistemi aziendali. Fino a oggi, ogni integrazione ai era un progetto custom: raw api calls nella app, pipeline rag fragili, tool calling bespoke, nessuna reusabilità, nessuna governance. Con MCP il paradigma cambia. Esponi il tuo sistema come MCP server. L’ai lo consuma come un client standardizzato. Lo autentichi una volta. Lo governi una volta. Lo monitori una volta. Non è poco. È l’equivalente di come http ha standardizzato la comunicazione sul web negli anni novanta. E come http, cambierà tutto senza che la maggior parte delle persone se ne accorga. ## Il flusso riscritto {: #flow-rewritten } **Provo a immaginare cosa significherebbe concretamente per i clienti con cui lavoro.** Oggi il flusso è questo: il cliente accede alla ui, clicca per otto o dieci azioni diverse, esporta dati in csv, li incolla in un’altra app, ottiene il risultato. È un processo che funziona, che abbiamo ottimizzato negli anni, che i clienti conoscono. Ma è anche un processo che richiede tempo, attenzione, competenza specifica su come funziona quel particolare software. Il flusso futuro potrebbe essere questo: il cliente parla a Claude/ChatGPT/Gemini/whatever e dice “processa questi dati e dammi il rapporto”. Claude si connette direttamente al sistema via MCP, legge i dati, li elabora, scrive il risultato nella tabella giusta. Tutto in dieci secondi, nessun clic. Non è ai che conosce il software. È il software che diventa consumabile da ai. E con strumenti che tutti già usano quotidianamente. Scrivo queste parole e sento una resistenza interna. Costruire interfacce è stato il mio lavoro per anni. C’è qualcosa di umano nel disegnare un’esperienza, nel pensare a come una persona interagirà con qualcosa che hai creato. C’è anche, devo ammetterlo, una forma di controllo. Quando progetti un’interfaccia, decidi tu il flusso. Guidi l’utente. Scegli cosa può fare e cosa no, in quale ordine, con quali vincoli. Aprire tutto questo a un agente ai significa cedere quel controllo. Significa fidarsi che il sistema farà la cosa giusta anche quando non puoi prevedere esattamente cosa chiederà l’utente. Ma forse è proprio qui il punto. Forse quel controllo era sempre un’illusione, un modo per gestire la complessità riducendo le opzioni invece di affrontarla davvero. ## Il gap di governance {: #governance-gap } I dati di mercato sono chiari. [Più dell’ottanta per cento dei team di sviluppo]() seguono già una metodologia api-first. Si stima [un miliardo e settecento milioni di api attive nel 2030](), un aumento del trecento per cento rispetto al baseline attuale. Chi adotta api-first rispetto ad approcci tradizionali vede una riduzione del 37% nei costi di integrazione. Ma il dato che mi ha colpito di più è questo: [Gartner stima]() che più del quaranta per cento dei progetti con agenti AI sarà cancellato entro il 2027 se non hanno una governance solida. Ecco il punto dove tutto si complica, dove la visione tecnologica si scontra con la realtà operativa. MCP oggi ha gap importanti. Non c’è uno standard di autenticazione: ogni implementazione è diversa. Il sandboxing è debole: se un agente prende il controllo, dove lo fermi? Ci sono rischi di prompt injection: come garantisci che l’AI non sia manipolata per fare azioni indesiderate? E ci sono lacune nell’auditing: come tracci chi ha fatto cosa e quando? La Commissione Europea e le banche centrali europee stanno già spingendo verso api trasparenti, controllabili, auditabili. Non è solo una scelta tecnica. È una scelta di sopravvivenza normativa. E qui si apre un territorio che conosco bene, quello del bilanciamento tra innovazione e compliance, tra quello che potresti fare e quello che dovresti fare. Mi trovo spesso a riflettere su questo equilibrio. Da una parte c’è la spinta a muoversi velocemente, ad adottare nuove tecnologie prima dei competitor, a essere i primi a offrire ai clienti qualcosa che non sapevano nemmeno di volere. Dall’altra c’è la responsabilità verso quei clienti, verso i loro dati, verso la sostenibilità di lungo periodo. Non sono sempre in conflitto, ma a volte lo sono. E quando lo sono, la scelta non è mai ovvia. Ho visto aziende muoversi troppo velocemente e bruciare la fiducia dei clienti con implementazioni AI che non erano pronte. Ho visto aziende muoversi troppo lentamente e diventare irrilevanti mentre il mercato cambiava attorno a loro. Il tradeoff perfetto non esiste. Esiste solo la capacità di scegliere consapevolmente, sapendo cosa stai sacrificando e perché. ## Il valore non sta nel lavoro {: #value-not-work } Quello che sto esplorando concretamente è un layer backend che espone i dati del cliente come MCP server. Un set di istruzioni e configurazioni per AI che sa come interrogare quel server. Un’interfaccia di governance dove il cliente può decidere cosa l’AI può leggere e cosa no, quale azione può compiere e quale non può. Un audit trail completo che traccia ogni interazione, ogni decisione, ogni errore. Il risultato, se funziona, è che il cliente non avrà bisogno di noi per tre quarti dei task ripetitivi. Avrà bisogno di noi per mantenere il sistema pulito, per aggiungere nuove sorgenti di dati, per governance e compliance, per problemi che richiedono giudizio umano. È un cambio di rapporto: da chi fa il lavoro a chi rende il lavoro automatizzabile. Scrivo questa frase e mi rendo conto di quanto sia radicale. Sto pensando a qualcosa che ridurrà la quantità di lavoro che i clienti mi chiederanno di fare. Dal punto di vista del fatturato immediato, è una follia. Dal punto di vista del valore di lungo periodo, credo sia l’unica strada sensata. I clienti pagano perché amano pagare. Pagano perché hai qualcosa di cui hanno bisogno. Se possiamo dare loro lo stesso valore, o maggiore, con meno frizione, perché non dovremmo? E se non lo fai tu, lo farà qualcun altro. C’è una frase che mi ripeto spesso: il valore non sta nel lavoro che fai, sta nel problema che risolvi. **Per anni ho misurato il mio valore in termini di ore, deliverable, feature rilasciate. Adesso mi chiedo se non dovrei misurarlo in termini di problemi eliminati, attrito ridotto, capacità restituita ai clienti di fare quello che sanno fare meglio**. La finestra temporale per questo cambiamento è adesso, nel 2026. MCP è standard, supportato dai tre principali provider di ai. I gap di sicurezza vengono chiusi progressivamente. I clienti cominciano a capire che vogliono qualcosa tipo “parla a ChatGPT e fatto”. Chi non si muove in questa direzione sarà tagliato fuori. Non domani. Adesso. Ma “adesso” non significa “a qualunque costo”. Non significa sacrificare la sicurezza dei dati per la velocità di implementazione. Non significa promettere ai clienti funzionalità che non sono ancora mature. Non significa ignorare le normative perché sono scomode. Significa **trovare il modo di muoversi velocemente nella direzione giusta, con gli occhi aperti su dove stai andando**. ## Responsabilità di chi costruisce {: #builders-responsibility } C’è qualcosa che mi solletica particolarmente quando penso a tutto questo. Non è la paura di sbagliare tecnicamente. Quella c’è, ma è gestibile. È qualcosa di più profondo. È la consapevolezza che **le decisioni che prendiamo oggi come costruttori di software stanno definendo il rapporto che le persone avranno con la tecnologia domani**. Ogni API che esponiamo, ogni dato che rendiamo accessibile, ogni azione che automatizziamo crea un precedente. Stabilisce cosa è normale, cosa è accettabile, cosa ci si aspetta. Penso ai nostri clienti, persone che gestiscono aziende, che hanno dipendenti, che servono a loro volta altri clienti. Quando apro i loro sistemi all’AI, sto cambiando il modo in cui lavorano. Sto ridefinendo quali competenze saranno necessarie, quali ruoli avranno senso, come sarà strutturata la loro giornata. Non è una responsabilità da prendere alla leggera e dobbiamo aspettarci molta più resistenza perché quello che offriamo non è un software ma un cambiamento (a volte sostanziale) di ruoli e processi interni, nonché di gerarchie. Ma è anche un’opportunità straordinaria. La possibilità di liberare tempo ed energia umana per attività che richiedono davvero intelligenza, creatività, giudizio. Di ridurre il lavoro ripetitivo che consuma le persone senza aggiungere valore. Di rendere le piccole aziende competitive con le grandi, perché l’accesso all’automazione non sarà più una questione di budget per team dedicati. Forse è questo il tradeoff fondamentale. Da una parte il rischio di costruire sistemi che sfuggono al controllo, che creano dipendenze, che concentrano potere in mani sbagliate. Dall’altra la possibilità di costruire qualcosa che davvero aiuta le persone a lavorare meglio, a vivere meglio, a dedicare il loro tempo a ciò che conta. Ed ho la convinzione che restare fermi non sia un’opzione e la determinazione a muovermi nella direzione che mi sembra giusta, un passo alla volta, con gli occhi aperti. E insomma, questo è quello che sto facendo. Se riconosci questa traiettoria e vuoi fare due chiacchiere su dove potrebbe portarci, parliamone. --- # L'architettura invisibile dello streaming musicale - **URL:** https://margiovanni.it/it/blog/larchitettura-invisibile-dello-streaming/ - **Pubblicato:** 2026-01-15 - **Tag:** Musica, Streaming, Tecnologia - **Tempo di lettura:** 12 min > C’è un momento che mi torna spesso in mente. Qualche anno fa ero a un concerto in un piccolo club di Pescara, uno di... ![](https://substackcdn.com/image/fetch/$s_!qBZ-!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F46bb4646-82ab-4913-bffe-039e6117772f_6000x4000.jpeg) *Foto di Anna Pou :* C’è un momento che mi torna spesso in mente. Qualche anno fa ero a un concerto in un piccolo club di Pescara, uno di quei posti dove il palco è alto quanto un gradino e puoi sentire il sudore del bassista. La band era sconosciuta (3 ragazzini completamente fuori di testa e con un odore inconfondibile 😁), il pubblico forse trenta persone, il suono grezzo e imperfetto. Ma c’era qualcosa di vivo in quella stanza, una connessione diretta tra chi suonava e chi ascoltava che non aveva bisogno di algoritmi per esistere. Tornando a casa ho aperto Spotify per cercare quella band. Non c’erano. O meglio, c’erano, ma sepolti sotto migliaia di altri risultati, invisibili a meno di sapere esattamente cosa cercare. E mi sono chiesto: quante band come quella esistono nell’ombra digitale, tecnicamente presenti ma praticamente inesistenti? Ho passato un po’ di tempo a studiare come funzionano davvero le piattaforme di streaming musicale. Non la superficie, quella la conosciamo tutti. Mi interessava capire cosa succede sotto, nelle viscere tecniche di questi sistemi che mediano il nostro rapporto con la musica. Quello che ho trovato mi ha fatto ripensare a tutto quello che credevo di sapere su come scopriamo la musica oggi. ## Una macchina logistica {: #logistics-machine } Partiamo da una verità che raramente viene detta: **quando clicchi play su Spotify, stai attivando una delle macchine logistiche più sofisticate mai costruite**. Non è un’esagerazione. Spotify gestisce oltre cento petabyte di dati e più di duemila microservizi distribuiti. Ogni brano che ascolti non arriva dal nulla, arriva da una catena di server, cache, nodi di distribuzione geografica che lavorano insieme per farti credere che la musica sia semplicemente lì, pronta per te. È un’illusione straordinaria, e come tutte le illusioni ben riuscite, nasconde qualcosa di importante. La prima cosa da capire è che non tutti i brani sono uguali per il sistema. Non parlo di qualità artistica, parlo di qualcosa di molto più prosaico: il costo di distribuzione. Quando ascolti una canzone, quella canzone deve viaggiare da qualche parte fino al tuo dispositivo. Se è già memorizzata in un server vicino a te, il costo è minimo. Se deve essere recuperata da un datacenter dall’altra parte del mondo, il costo sale. Moltiplica questo per miliardi di ascolti al giorno e capisci perché l’ottimizzazione diventa un’ossessione. ## La prevedibilità si decide {: #predictability-decided } **Qui entra in gioco il concetto di prevedibilità, e qui le cose si fanno interessanti**. Il sistema funziona meglio quando sa in anticipo cosa ascolterai. Se può prevedere che domani milioni di persone ascolteranno una certa canzone, può distribuire quella canzone in anticipo su centinaia di server in tutto il mondo. Quando arriva la richiesta, il brano è già lì, pronto. Nessun ritardo, nessun costo extra di trasferimento. È elegante, efficiente, economico. Il problema è questo: come fai a prevedere cosa ascolteranno milioni di persone? **La risposta è tanto semplice quanto inquietante. Non lo prevedi. Lo decidi tu.** **Le playlist editoriali non sono un servizio offerto agli utenti. Sono uno strumento di controllo dei consumi.** Quando Spotify crea una playlist come “Today’s Top Hits” e la propone a cinquanta milioni di follower, non sta semplicemente suggerendo musica. Sta creando un flusso prevedibile di ascolti che può essere ottimizzato a livello infrastrutturale. Il sistema sa che quella playlist verrà ascoltata da centinaia di migliaia di persone, sa che seguiranno l’ordine proposto, sa che i primi quindici brani riceveranno la maggior parte degli ascolti. Con questa certezza, può pre-distribuire quei brani su tutti i server necessari, garantendo che ogni ascolto venga servito dal cache locale invece che dal datacenter centrale. ## Album contro playlist {: #albums-vs-playlists } Ho fatto un calcolo approssimativo. Supponiamo un miliardo e mezzo di stream al giorno, un bitrate medio di 128 kbps, una canzone media di tre minuti. Senza ottimizzazione, il costo giornaliero di banda sarebbe nell’ordine di decine di milioni di dollari. Con il prefetching predittivo reso possibile dalle playlist, quel costo può essere ridotto del sessanta, settanta per cento. Su scala annuale parliamo di miliardi di dollari di risparmio. Non è una speculazione: **Spotify ha investito centinaia di milioni con Google Cloud proprio per ottimizzare questo tipo di flusso.** Gli album, invece, rimangono un problema. Non perché siano tecnicamente diversi, ma perché sono *imprevedibili*. Quando un utente salva un album di dodici tracce, il sistema non sa quali ascolterà, in quale ordine, quando. Potrebbe ascoltare solo i singoli. Potrebbe partire dalla traccia sette. Potrebbe non ascoltarlo mai. Questa incertezza significa che il sistema deve allocare risorse in modo conservativo, preparandosi a ogni eventualità senza sapere quale si verificherà. È inefficiente, costoso, e crea quello che i tecnici chiamano *cache waste* , brani pre-memorizzati che nessuno tocca. La conseguenza è sottile ma profonda: **il sistema ha un incentivo strutturale a promuovere le playlist rispetto agli album**. Non perché qualcuno abbia deciso che gli album sono cattivi, ma perché l’architettura stessa del sistema premia la prevedibilità. E le playlist, per definizione, sono prevedibili. Gli album no. Mi sono chiesto spesso se chi ha progettato questi sistemi fosse consapevole delle implicazioni culturali. Probabilmente no, almeno all’inizio. Gli ingegneri risolvevano un problema di distribuzione, non pensavano di ridefinire il modo in cui la musica viene scoperta e consumata. Ma l’effetto è lo stesso, intenzionale o meno. C’è uno studio del National Bureau of Economic Research che mi ha colpito particolarmente. Ha misurato l’impatto delle playlist editoriali di Spotify sugli ascolti. I risultati sono sconcertanti. Apparire su “Today’s Top Hits” aumenta gli stream di venti, quaranta volte nella settimana successiva. Apparire su “New Music Friday” di cinque, quindici volte. **Questo non è semplicemente promozione. È creazione di successo.** Decidendo quali brani mettere in quelle playlist, Spotify decide letteralmente chi avrà successo e chi no. Il feedback loop che ne deriva è ancora più insidioso. Una canzone entra in una playlist editoriale. Riceve milioni di ascolti. L’algoritmo la percepisce come popolare e inizia a suggerirla organicamente ad altri utenti. La canzone riceve ancora più ascolti. L’infrastruttura la pre-cacha ancora più aggressivamente, riducendo ulteriormente i costi di distribuzione. E intanto, da qualche parte, una band sconosciuta suona in un piccolo club di Pescara, tecnicamente presente sulla piattaforma ma praticamente invisibile. Non voglio dipingere tutto questo come una cospirazione malvagia. È qualcosa di più complesso e, per certi versi, più inquietante. È l’emergenza naturale di una rete di incentivi: tecnici, economici, di mercato. Nessuno ha deciso che la musica sperimentale debba essere penalizzata. **È semplicemente che la musica sperimentale è imprevedibile, e l’imprevedibilità costa.** Nessuno ha deciso che la scoperta organica debba essere soffocata. È semplicemente che **la scoperta controllata è più ottimizzabile**. Il risultato è lo stesso, ma la causa non è un cattivo in una stanza che tira le fila. È un sistema che fa quello per cui è stato progettato. ## Discovery Mode e il sistema a pool {: #discovery-mode-pool } **Discovery Mode è forse l’esempio più chiaro di questa dinamica.** Introdotto nel 2023, permette agli artisti di accettare una riduzione delle royalty, fino alla metà, in cambio di priorità negli algoritmi di raccomandazione. È geniale, in un modo che mi mette a disagio. Spotify non sta manipolando direttamente l’algoritmo, sta incentivando gli artisti a rinunciare volontariamente a una parte dei loro guadagni per ottenere visibilità. Il risultato è che chi può permettersi di guadagnare meno ottiene più esposizione, mentre chi ha bisogno di ogni centesimo rimane nell’ombra. E dal punto di vista infrastrutturale, il sistema ci guadagna due volte: paga meno royalty e ottiene traffico prevedibile, perfettamente ottimizzabile. Il modello economico sottostante amplifica tutto questo. Spotify non paga gli artisti per stream in modo lineare. Usa un sistema a pool: tutti gli abbonamenti finiscono in un calderone, e quel calderone viene diviso proporzionalmente tra gli artisti in base ai loro stream. Questo significa che quando un artista guadagna stream, non sta aggiungendo alla torta, sta prendendo una fetta più grande di una torta che rimane uguale. E chi sono gli artisti che guadagnano più stream? Quelli nelle playlist editoriali. Il sistema premia chi è già premiato, penalizza chi è già penalizzato. Un artista indipendente avrebbe bisogno di duecentocinquantamila stream per guadagnare mille dollari lordi. Se la metà va a distributori e diritti, restano cinquecento dollari netti per il lavoro di composizione, registrazione, promozione. Per un intero album. Nel frattempo, un artista che ottiene una playlist editoriale può ricevere milioni di stream in una settimana, generando decine di migliaia di dollari. È una lotteria, e il banco ha il controllo su chi vince. Mi colpisce come tutto questo sia invisibile all’utente medio. Apri Spotify, vedi una selezione apparentemente infinita di musica, ti sembra di avere il mondo a portata di dita. Ma quella selezione è filtrata, ordinata, prioritizzata da sistemi che hanno i loro incentivi, le loro necessità tecniche, i loro modelli di business. Non stai esplorando un archivio neutrale. Stai navigando un territorio plasmato da forze che non vedi. ## Filter bubble e omogenizzazione {: #filter-bubbles } I ricercatori parlano di filter bubbles ed echo chambers. Gli algoritmi di raccomandazione tendono a proporti musica simile a quella che hai già ascoltato, creando cicli che si autoalimentano. Ascolti indie pop, l’algoritmo ti propone più indie pop, ascolti ancora più indie pop, e prima che tu te ne accorga sei intrappolato in un genere che forse non avresti mai scelto consapevolmente come tua identità musicale. **La diversità dell’offerta non si traduce in diversità dell’esperienza.** C’è qualcosa di profondamente ironico in tutto questo. Lo streaming musicale è nato con la promessa di democratizzare l’accesso alla musica. Qualsiasi artista può caricare la propria musica, qualsiasi ascoltatore può accedere a milioni di brani. In teoria, le barriere all’ingresso sono scomparse. In pratica, sono state sostituite da barriere diverse, più sottili, più difficili da vedere e quindi più difficili da contestare. Non è che non puoi entrare. È che una volta dentro, sei invisibile a meno che il sistema non decida di mostrarti. Penso spesso a cosa significhi tutto questo per la musica come forma d’arte. La musica sperimentale, di nicchia, innovativa, quella che per definizione non si adatta ai pattern prevedibili, quella che non puoi pre-cachare perché non sai chi la ascolterà, viene strutturalmente penalizzata. Non perché qualcuno la odi, ma perché l’architettura del sistema non la favorisce. **L’incentivo economico va verso l’omogenizzazione, verso la ripetizione di formule che funzionano, verso la prevedibilità che riduce i costi.** ## Una resistenza consapevole {: #conscious-resistance } Non ho ovviamente soluzioni. Non credo che Spotify sia il male, né che dovremmo tornare ai vinili o ai cd. Il progresso tecnologico ha portato benefici reali: accesso universale, costi ridotti per gli ascoltatori, possibilità per artisti indipendenti di raggiungere un pubblico globale senza passare per le major. Ma mi sembra importante capire cosa stiamo perdendo mentre guadagniamo tutto questo. Capire che quando apriamo una playlist editoriale non stiamo semplicemente ascoltando musica curata, stiamo partecipando a un sistema economico e tecnologico che ha i suoi interessi, le sue logiche, **le sue conseguenze**. Forse la cosa più importante è mantenere viva una forma di resistenza consapevole. Cercare attivamente musica al di fuori delle raccomandazioni algoritmiche. **Andare ai concerti, scoprire band locali, seguire blog e riviste indipendenti, parlare con amici che hanno gusti diversi dai nostri.** Usare lo streaming per quello che è, uno strumento straordinariamente comodo, senza dimenticare che ogni strumento plasma l’uso che ne facciamo. Quella sera nel club di Pescara, tornando a casa dopo il concerto, mi sono reso conto che l’esperienza che avevo vissuto non era replicabile su Spotify. Non perché la musica fosse diversa, ma perché il contesto era diverso. La scoperta era avvenuta attraverso il caso, la presenza fisica, il passaparola di un amico (grazie Kris!) che mi aveva trascinato lì. Nessun algoritmo l’aveva mediata, nessun sistema l’aveva ottimizzata. Era inefficiente, imprevedibile, impossibile da scalare. E forse proprio per questo era viva in un modo che nessuna playlist editoriale potrà mai essere. Quello che mi lascia di più l’amaro in bocca è la consapevolezza che tutto questo non è un incidente di percorso. È il risultato prevedibile di un sistema che ha messo il business al comando e ha usato la tecnologia come strumento di controllo. **Il cantautorato, l’arte, la ricerca musicale, tutto ciò che per sua natura è imprevedibile, personale, irriducibile a formula, è stato sistematicamente marginalizzato.** Non serviva una cospirazione. Bastava costruire un’infrastruttura che premia l’omogeneo e penalizza il diverso, e poi lasciar fare al mercato. Il risultato lo sentiamo ogni giorno. Canzoni che sembrano uscite dalla stessa fabbrica, strutture identiche, drop prevedibili, testi intercambiabili. Non perché i musicisti siano meno talentuosi di un tempo, ma perché **il talento che non si adatta al formato viene filtrato prima ancora di arrivare alle nostre orecchie**. L’algoritmo seleziona, la playlist amplifica, il loop si chiude. E chi non entra nel loop semplicemente non esiste. ## Il conto con Suno {: #suno-reckoning } La cosa che trovo quasi comica, in modo tragico, è che la stessa industria musicale adesso trema di fronte a Suno e agli altri generatori musicali basati su intelligenza artificiale. **Improvvisamente tutti si accorgono che forse, forse, avrebbero dovuto valorizzare quello che rende un artista insostituibile invece di trattarlo come fornitore di contenuto fungibile. Hanno passato vent’anni a comprimere le royalty, a spingere verso l’omogenizzazione, a costruire sistemi dove la musica è commodity da ottimizzare. E adesso si stupiscono che qualcuno abbia costruito una macchina capace di produrre commodity musicale a costo zero?** L’ironia è perfetta. Hanno allenato il pubblico ad accettare musica generica, prevedibile, intercambiabile. Hanno costruito playlist dove un brano vale l’altro, dove l’identità dell’artista è irrilevante, dove conta solo che il suono riempia lo sfondo senza disturbare. E adesso quella stessa musica può essere generata da un’ai in trenta secondi, senza pagare nessuno. Cosa pensavano che sarebbe successo? Non ho compassione per un’industria che ha scelto di uccidere ciò che la rendeva necessaria. Se hai passato decenni a convincere il mondo che la musica è solo intrattenimento di sottofondo, non puoi lamentarti quando qualcuno trova un modo più economico di produrre intrattenimento di sottofondo. Il valore dell’arte sta nella sua unicità, nella visione personale, nell’imperfezione umana. Tutto quello che hai sistematicamente eliminato in nome dell’ottimizzazione. Quella sera nel club di Pescara, e poi tornando a casa dopo il concerto, ho capito qualcosa che allora non riuscivo ad articolare. La musica che avevo ascoltato non era ottimizzabile. Non entrava in nessuna playlist, non si adattava a nessun algoritmo, non generava pattern prevedibili. Era inefficiente, scomoda, impossibile da scalare. Ed era viva in un modo che nessun sistema basato sulla prevedibilità potrà mai replicare, né umano né artificiale. Il cantautorato magari sopravviverà. L’arte magari sopravviverà. Ma non grazie all’industria dello streaming né all’industria musicale tutta. Sopravviverà nonostante essa, nei piccoli club, nelle produzioni indipendenti, nelle nicchie che gli algoritmi non riescono a vedere. E quando l’attuale modello di business crollerà sotto il peso delle sue stesse contraddizioni, schiacciato da generatori di musica che fanno esattamente quello che il sistema ha sempre chiesto, forse qualcuno si ricorderà che c’era un’alternativa. Che si poteva scegliere di valorizzare l’arte invece di ottimizzarla. **E forse sarà troppo tardi.** --- # Da scrittori di codice ad architetti di specifiche - **URL:** https://margiovanni.it/it/blog/da-scrittori-di-codice-ad-architetti/ - **Pubblicato:** 2026-01-10 - **Tag:** Formazione, Intelligenza Artificiale, Sviluppo Software - **Tempo di lettura:** 7 min > Oggi ho passato la mattina a rivedere il materiale per un corso di formazione interno. Ventisei pagine dense, piene di... ![](https://substackcdn.com/image/fetch/$s_!nPnQ!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F59a15f1a-bc2b-47bb-9899-6ad8d9f873d9_1024x1024.png) Oggi ho passato la mattina a rivedere il materiale per un corso di formazione interno. Ventisei pagine dense, piene di workflow, comandi, checklist. A un certo punto mi sono fermato e ho guardato fuori dalla finestra. Mi sono chiesto: ma quando è successo tutto questo? Un anno fa stavamo ancora discutendo se usare o meno Copilot per l’autocompletamento. Oggi scriviamo documenti chiamati “Constitution” che governano il comportamento di agenti ai che generano intere feature. Il salto non è stato graduale. È stato come svegliarsi una mattina e scoprire che il pavimento si è spostato di qualche centimetro durante la notte. ## Il vibe coding e la sua seduzione {: #il-vibe-coding-e-la-sua-seduzione } C’è un termine che mi ha colpito mentre preparavo il materiale: *vibe coding*. Descrivere vagamente cosa vuoi e lasciare che l’ai produca qualcosa. Lo abbiamo fatto tutti, nei primi mesi. C’era qualcosa di quasi magico nel vedere codice apparire dal nulla partendo da una descrizione approssimativa. Funzionava? A volte sì, spesso no. Ma la sensazione di velocità era inebriante. Il problema è che quella velocità era un’illusione. Il codice generato così, senza specifiche precise, senza un’architettura pensata, accumulava debito tecnico a una velocità impressionante. Ogni funzionalità aggiunta era una scommessa. Forse oggi funziona, forse domani si rompe tutto quando qualcuno tocca qualcos’altro. Ho visto POC partire come razzi e schiantarsi nel giro di poche settimane. Non perché l’ai avesse sbagliato, ma perché nessuno aveva pensato a cosa stavamo costruendo. Stavamo improvvisando con uno strumento potentissimo senza avere una partitura. ## La specifica come nuova forma di espressione {: #la-specifica-come-nuova-forma-di-espressione } La risposta che stiamo esplorando, e che cerchiamo di insegnare nel corso, ribalta completamente l’approccio. Si chiama spec-driven development e l’idea di fondo è semplice, quasi banale: prima scrivi cosa vuoi con precisione maniacale, poi lasci che qualcun altro (in questo caso un agente ai) lo implementi. Ma c’è un aspetto che mi affascina e insieme mi inquieta. Scrivere specifiche precise è tremendamente difficile. Richiede di pensare a ogni edge case, ogni scenario di errore, ogni possibile ambiguità. Richiede di sapere esattamente cosa vuoi prima di averlo visto funzionare. In un certo senso, è l’opposto del modo in cui molti di noi hanno imparato a programmare. Io ho imparato sperimentando, provando, sbagliando, correggendo. Un ciclo continuo di tentativi ed errori che alla fine produceva qualcosa che funzionava. Ora ci viene chiesto di pensare tutto in anticipo, di essere precisi prima di scrivere una singola riga di codice. Non sono sicuro che sia un cambiamento solo positivo. Probabilmente perdiamo qualcosa nella sperimentazione, nella scoperta casuale di soluzioni eleganti che emergono mentre scrivi. Ma forse guadagniamo qualcos’altro: la possibilità di costruire sistemi più grandi e complessi di quanto avremmo mai potuto fare da soli. ## Il paradosso delle competenze {: #il-paradosso-delle-competenze } Una cosa che mi ha fatto riflettere molto è il paradosso delle competenze che emerge da questo nuovo modo di lavorare. Nel documento che ho preparato c’è una frase che ho sottolineato più volte: > Questo non significa che le competenze tecniche diventino obsolete. Al contrario, servono competenze ancora più solide. Sembra controintuitivo. Se l’ai scrive il codice, perché dovrei sapere programmare? La risposta è che devi sapere programmare *meglio* di prima per capire se quello che l’ai ha prodotto ha senso. Per validare l’architettura. Per identificare problemi di sicurezza. Per sapere quando qualcosa è un workaround fragile mascherato da soluzione elegante. Ho visto junior entusiasmarsi per il codice generato dall’ai senza rendersi conto che conteneva vulnerabilità gravi. Query non parametrizzate, validazioni mancanti, secret hardcodati. L’ai aveva copiato pattern insicuri visti nel suo training data. Serviva qualcuno con esperienza per accorgersene. In un certo senso, stiamo diventando reviewer a tempo pieno. Il nostro lavoro si sta spostando dalla produzione alla supervisione, dalla scrittura alla lettura critica. Non so se sia una perdita o un guadagno. Forse entrambe le cose. ## La Constitution e l’illusione del controllo {: #la-constitution-e-lillusione-del-controllo } Nel framework che stiamo adottando c’è un concetto centrale: la Constitution. È un documento che definisce i principi immutabili del progetto. Cose come “nessun any type permesso” o “coverage minimo 80%” o “ogni PR richiede code review umana”. L’idea è che l’ai debba rispettare questi principi in ogni decisione. Funziona? **In larga misura sì**. L’ai segue le regole quando gliele dai in modo chiaro. Ma c’è qualcosa di leggermente ironico in tutto questo. Stiamo scrivendo costituzioni per macchine. Definendo leggi che algoritmi devono seguire. È un’inversione interessante del rapporto tra umani e strumenti. Quello che mi chiedo, e non ho ancora una risposta, è **fino a che punto queste regole scritte possano catturare ciò che intendiamo davvero**. Posso scrivere “nessun workaround o hack nel codice” ma come faccio a definire esattamente cos’è un hack? A volte la distinzione tra una soluzione pragmatica e un hack è sfumata, contestuale, richiede giudizio. **Quel giudizio, per ora, rimane umano**. ## Il tempo che non c’è più {: #il-tempo-che-non-ce-piu } Una cosa che è cambiata in modo sottile ma profondo è il rapporto con il tempo. Prima, quando stimavo quanto ci voleva per implementare una feature, pensavo in termini di ore o giorni di lavoro. Ora penso in termini di quanto tempo mi serve per scrivere una specifica abbastanza precisa e per validare l’output. Paradossalmente, a volte ci vuole più tempo. Scrivere una specifica completa, chiarire tutte le ambiguità, definire ogni edge case può richiedere lo stesso tempo che avrei impiegato a scrivere il codice. Ma il tipo di lavoro è diverso. È più mentale, più astratto. Meno ore a fissare un debugger, più ore a pensare. Non tutti nel team si trovano a loro agio con questo cambiamento. Alcuni colleghi amavano proprio quella sensazione di flow quando il codice scorre dalle dita, quando sei immerso nel problema e le soluzioni emergono quasi da sole. Quello stato mentale è più raro ora. Il lavoro è diventato più frammentato, più fatto di review e validazioni che di creazione continua. ## La sicurezza come ossessione necessaria {: #la-sicurezza-come-ossessione-necessaria } C’è un aspetto del codice ai-generated ovviamente mi rende irrequieto: la sicurezza. Nel materiale del corso ho dedicato un’intera sezione ai rischi specifici. Pattern insicuri, dipendenze vulnerabili, query non parametrizzate. L’ai non ha malizia, ma non ha neanche prudenza. Riproduce quello che ha visto, inclusi gli errori. La cosa che mi preoccupa è che molti di questi problemi non sono evidenti a prima vista. Il codice compila, i test passano, l’applicazione funziona. La vulnerabilità è nascosta, silente, in attesa che qualcuno la trovi e la sfrutti. Serve un occhio esperto per individuarla. Serve tempo per revisioni meticolose. Abbiamo aggiunto tool automatici nella pipeline: audit delle dipendenze, scansione dei secret, analisi statica del codice. Aiutano, ma non bastano. Alla fine, qualcuno deve sedersi e leggere il codice riga per riga chiedendosi: cosa potrebbe andare storto qui? Ed ho imparato (di nuovo) l’importanza dei test e2e. ## Cosa resta di noi {: #cosa-resta-di-noi } A volte mi chiedo cosa resterà del nostro mestiere tra cinque anni. Non nel senso apocalittico di “i programmatori saranno sostituiti”, che mi sembra una semplificazione. Ma nel senso di cosa faremo davvero, giorno per giorno. Probabilmente scriveremo meno codice e più specifiche. Leggeremo più codice di quanto ne scriviamo. **Passeremo più tempo a pensare all’architettura, alla sicurezza, alle implicazioni di ogni scelta. Saremo meno artigiani e più architetti, meno costruttori e più supervisori.** Non so se a qualcuno piacerà. A molti piaceva scrivere codice. A molti piaceva quella sensazione di costruire qualcosa con le proprie mani, anche se le mani erano solo metaforiche. Forse quella sensazione si trasformerà in qualcos’altro. O forse la si cercherà altrove, in progetti personali dove nessuno ti obbliga a essere efficiente. ## Un mestiere in transizione {: #un-mestiere-in-transizione } Quello che sto cercando di trasmettere nel corso, al di là dei comandi e delle checklist, è la consapevolezza che siamo in un momento di transizione. Non sappiamo ancora dove stiamo andando, ma **sappiamo che non torneremo indietro**. Il vibe coding è stato un esperimento, una fase adolescenziale nell’uso di questi strumenti. Ora stiamo cercando di diventare adulti, di costruire processi e discipline che ci permettano di usare questa potenza senza farci male. È un lavoro in corso, ovviamente. Tra qualche mese probabilmente rivedrò questo materiale e lo troverò già obsoleto. Qualcosa sarà cambiato di nuovo. Gli strumenti saranno diversi, i workflow si saranno evoluti. È il bello e il brutto di lavorare in un campo che si muove così velocemente. Per ora, quello che posso fare è documentare quello che impariamo, condividerlo con il team, cercare di costruire competenze che vadano oltre lo strumento specifico. La capacità di pensare in modo strutturato, di scrivere specifiche precise, di validare criticamente l’output di qualcun altro: queste mi sembrano abilità che resteranno utili qualunque cosa succeda e che daranno valore alle persone. O, almeno, è quello che mi ripeto ultimamente. --- # AI e il circolo vizioso che rischia di uccidere l'open source - **URL:** https://margiovanni.it/it/blog/ai-e-il-circolo-vizioso-che-rischia/ - **Pubblicato:** 2026-01-09 - **Tag:** Etica, Intelligenza Artificiale, Open Source - **Tempo di lettura:** 11 min > C’è una frase di Adam Wathan che mi ha colpito e alla quale continuo a pensare da due giorni, quando l’ha pubblicata.... ![](https://substackcdn.com/image/fetch/$s_!7Gjm!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3262bd77-2b59-4412-911e-24d37ba3379b_1934x1378.png) C’è una frase di Adam Wathan che mi ha colpito e alla quale continuo a pensare da due giorni, quando l’ha pubblicata. L’ha scritta appunto l’altroieri, il giorno dopo aver licenziato tre quarti del suo team di ingegneria. Era in [risposta a una pull request su GitHub](), una di quelle richieste tecniche apparentemente innocue che normalmente passano inosservate. Ma la risposta di Wathan non era tecnica. Era un grido di dolore mascherato da spiegazione razionale. Per chi non lo conoscesse, Wathan è il creatore di Tailwind CSS, uno dei framework più usati al mondo per lo sviluppo web. Se avete lavorato con il frontend negli ultimi anni, probabilmente avete incrociato Tailwind. È ovunque, con 75 milioni di download al mese. È il sogno dell’open source realizzato: un progetto gratuito, amato dalla community, che aveva trovato un modello sostenibile per esistere. Aveva. Perché adesso quel modello è in frantumi, e il motivo dovrebbe allarmarci e farci porre domande. Il revenue di Tailwind Labs è crollato dell’80%. In un anno. Non perché il progetto sia in declino, anzi, non è mai stato così popolare. È crollato perché l’intelligenza artificiale ha cambiato il modo in cui gli sviluppatori usano il software. E questa cosa, quando ci penso, mi spaventa molto più di qualsiasi altra conseguenza dell’ai di cui si parla normalmente. Per capire cosa è successo bisogna tornare indietro di qualche anno e guardare come funzionava il modello di business di Tailwind. Il framework è open source, gratuito, accessibile a tutti. Ma il team ha creato anche Tailwind UI, una libreria di componenti premium che vende. È uno dei modelli classici dell’open-source: offri qualcosa di gratuito e di valore, costruisci una community, e una percentuale di quella community finisce per comprare i prodotti a pagamento. Nel 2020, Tailwind UI ha fatto 500.000 dollari nei primi tre giorni dal lancio. Entro cinque mesi aveva superato i due milioni. Nel 2024 il team era cresciuto a otto persone, con stipendi da 250.000-300.000 dollari per gli ingegneri. Era l’esempio vivente che l’open source sostenibile è possibile. ## Il grido di dolore di Wathan {: #wathan-cry-of-pain } E poi è arrivata l’ai. Dal 2023, il traffico alla documentazione di Tailwind è sceso del 40%. Non perché gli sviluppatori abbiano smesso di usare Tailwind. Al contrario, l’utilizzo è ai massimi storici. Ma perché quando hai bisogno di un componente Tailwind, non vai più su tailwindcss.com. Apri Copilot, o Claude, o Cursor, e gli dici “fammi un button con Tailwind”. E l’ai te lo genera. Istantaneamente. Senza mai toccare il sito ufficiale. Ecco il punto che mi ossessiona: la documentazione era il funnel. Era il momento in cui gli sviluppatori scoprivano che esisteva anche Tailwind UI, la versione premium. Ma se gli sviluppatori non visitano mai la documentazione, non scoprono mai i prodotti a pagamento. Il funnel è stato completamente cortocircuitato. Gli ai hanno rimosso l’intermediazione, quella frizione produttiva che permetteva ai progetti open source di monetizzare. Wathan lo dice con una chiarezza che fa quasi male: > Tailwind sta crescendo più velocemente che mai ed è più grande che mai, e il nostro revenue è sceso di quasi l’80%. Al momento non c’è correlazione tra rendere Tailwind più facile da usare e rendere sostenibile lo sviluppo del framework. Ho riletto questa frase diverse volte. Non c’è correlazione tra migliorare il tuo prodotto e renderlo sostenibile. È la morte del modello. È la fine di un’era. ## Il funnel cortocircuitato {: #funnel-short-circuited } La pull request che ha scatenato tutto questo era una richiesta per aggiungere un file llms.txt al repository di Tailwind. È uno standard emergente, un modo per rendere la documentazione più facilmente leggibile per i Large Language Models. Altri progetti l’hanno già adottato. Sembra una cosa innocua, quasi ovvia. Ma Wathan l’ha chiusa con una spiegazione che è diventata un manifesto involontario della crisi dell’open source. > Abbiamo problemi più importanti da affrontare, come raccogliere fondi per mantenere a galla il business. Rendere la nostra documentazione più leggibile per gli llm ridurrà solo ulteriormente gli accessi alla documentazione, e meno utenti scopriranno i nostri prodotti a pagamento, riducendo ulteriormente la sostenibilità del nostro business. Alcuni lo hanno criticato. Gli hanno detto che il messaggio che sta mandando è egoista, che mette i soldi davanti al servizio alla community. Ma è qui che la situazione diventa davvero tragica, perché Wathan ha ragione. Ha completamente ragione. E non c’è una scelta vincente. ## Nessuna scelta vincente {: #no-winning-choice } Ho provato a pensare alle opzioni che avrebbe davanti, e nessuna funziona. Se blocchi gli llm, aggiungi regole aggressive nel robots.txt, impedisci ai crawler di OpenAI e Anthropic e Google di fare scraping della documentazione, cosa succede? Gli llm smettono di conoscere il tuo progetto. Gli sviluppatori che usano ai assistants non ricevono più suggerimenti basati sulla tua documentazione. Il tuo progetto diventa invisibile in un’epoca in cui l’84% degli sviluppatori usa strumenti ai. Perdi userbase. Perdi rilevanza. Perdi tutto. Se non blocchi gli llm, lasci che i bot facciano scraping liberamente. Gli llm si allenano sui tuoi contenuti. Diventano bravissimi a generare codice che usa il tuo framework. Gli sviluppatori lo adorano. Ma non visitano mai il tuo sito. Non scoprono mai i tuoi prodotti a pagamento. Il revenue crolla. Devi licenziare il team. Il progetto diventa insostenibile. Se aggiungi llms.txt per “aiutare” gli llm, rendi la documentazione ancora più facile da digerire per le ai. Gli llm diventano ancora più bravi a rispondere senza mandare gli utenti sul tuo sito. Acceleri la tua stessa obsolescenza economica. È come affilare il coltello per chi ti sta accoltellando. Non c’è una scelta vincente. È letteralmente un circolo vizioso mortale. E la cosa che mi fa rabbrividire è che non è solo Tailwind. ## Non è solo Tailwind {: #beyond-tailwind } Stack Overflow, la Mecca delle domande di programmazione per vent’anni, ha visto le submission crollare dai picchi di 200.000 al mese nel 2014 a meno di 50.000 alla fine del 2025. Il 47% degli utenti attivi giornalieri è semplicemente scomparso. Ora l’81% degli sviluppatori usa ChatGPT (o alternative) per fare le domande che una volta facevano su Stack Overflow. Il traffico è crollato anche dopo che Stack Overflow ha bloccato GPTBot e poi tolto il blocco per una partnership con OpenAI. Non è cambiato nulla: gli utenti hanno ormai cambiato comportamento/abitudini. Business Insider ha registrato cali di traffico tra il 40% e il 48%. Le “zero-click searches”, query in cui l’utente ottiene la risposta direttamente nella pagina dei risultati senza cliccare su nessun sito, rappresentano ormai il 62% di tutte le ricerche. Il 2025 è stato definito “the organic traffic crisis”. Read the Docs, GNOME, SourceHut, LWN, Fedora, tutti progetti open source, tutti sotto assedio dai crawler ai. GNOME GitLab ha avuto downtime significativi. Hanno dovuto implementare reverse proxy con proof-of-work challenges per bloccare i bot più aggressivi. Ma è una battaglia persa in partenza, perché i bot diventano sempre più sofisticati, pagano per account per sembrare umani, falsificano fingerprint TLS. C’è chi sta provando a trovare vie d’uscita. Cloudflare ha lanciato “Pay Per Crawl” a giugno 2025. L’idea è elegante: invece di bloccare o permettere gratuitamente, puoi far pagare i crawler ai per ogni richiesta. Usi il response code 402, “Payment Required”, rimasto dormiente per decenni. Cloudflare agisce come intermediario e tu imposti un prezzo per request. Sulla carta potrebbe spostare oltre due miliardi di dollari dalle ai companies ai publisher entro il 2027. Ma c’è un problema: funziona solo se un numero critico di publisher lo adotta. Se sei il solo a mettere il paywall, le ai companies ti ignorano e vanno altrove. È un classico problema di coordinamento, e storicamente l’ecosistema open source non è mai stato bravo a coordinarsi su questo genere di cose. ## Il prossimo capitolo: model collapse {: #model-collapse } C’è un aspetto di questa storia che trovo particolarmente inquietante, e che pochi stanno notando. Se gli sviluppatori smettono di postare domande su Stack Overflow, se smettono di scrivere documentazione tecnica dettagliata perché “tanto l’ai la genera”, su cosa si alleneranno i futuri modelli ai? È un problema di circolarità. **Gli attuali llm si sono allenati su decenni di contenuti human-generated di alta qualità: tutorial scritti con cura, domande e risposte su forum, documentazione tecnica dettagliata.** Ma se quella fonte si prosciuga, perché economicamente insostenibile, cosa succede? Le ai iniziano ad allenarsi su output generati da altre ai. **È il fenomeno del “model collapse”, e porta a una degradazione progressiva della qualità.** Lo stesso Wathan ha sperimentato una cosa del genere. Ha provato a usare Claude per aggiungere dark mode a oltre 600 componenti di Tailwind UI. Ha detto che i risultati erano così inconsistenti che rivedere e sistemare il lavoro fatto dall’agent ha richiesto più tempo che fare tutto a mano dall’inizio. Anche per task apparentemente semplici, gli llm attuali hanno limiti evidenti in mancanza di codumentazione di qualità. Più ci penso, più mi convinco che non esista una soluzione win-win qui. O almeno, non una che preservi l’attuale modello dell’open source sostenibile. I modelli di monetizzazione tradizionali, open core, SaaS hosting, premium add-ons, professional services, erano tutti basati su un presupposto: che ci fosse un momento di contatto con l’utente. Un momento in cui l’utente veniva a conoscenza del tuo progetto, visitava la tua documentazione, vedeva il tuo brand, scopriva i tuoi prodotti commerciali. Quel momento era il funnel. Era dove potevi convertire utenti gratuiti in clienti paganti. Gli ai tools hanno completamente cortocircuitato quel funnel. Gli sviluppatori non “visitano” più nulla. Chiedono a Copilot e Copilot genera il codice. L’ai è diventata un intermediario totale tra gli utenti e i progetti open source. E quell’intermediario non paga commissioni. Se migliorare il tuo prodotto non porta a maggiore sostenibilità economica, il progetto è destinato a morire o a essere assorbito da una big tech che può permettersi di mantenerlo senza monetizzare. ## La fine di un'era {: #end-of-an-era } Mentre riflettevo su questa cosa, mi sono ritrovato con più domande che risposte. E sono domande pesanti, che mi tengono sveglio. L’open source può sopravvivere senza il backing di big tech? Se i progetti non riescono più a monetizzare, solo quelli sponsorizzati da Google, Meta, Microsoft sopravvivranno. Ma è davvero open source se è controllato da corporazioni? O è solo “source-available” con un’aura di community? **Serve un nuovo social contract? Alcuni parlano di trattare l’open source come “digital public infrastructure” e finanziarla con fondi pubblici.** Ma quale governo vuole finanziare migliaia di progetti software? **E chi decide cosa merita il finanziamento?** Gli ai providers dovrebbero pagare per i training data? Intuitivamente sembra giusto. Ma come lo implementi? Con quale meccanismo legale? E se i dati sono rilasciati con licenza open source, come imponi il pagamento senza violare i principi dell’open source stesso? Questa è una transition temporanea o permanente? Forse tra qualche anno emergeranno nuovi modelli di business che oggi non riusciamo nemmeno a immaginare. O forse no. Forse stiamo assistendo alla fine di un’era, e quello che verrà dopo sarà radicalmente diverso da tutto ciò che conoscevamo. C’è un’ironia quasi comica in questa tragedia. Tailwind è vittima del proprio successo. Gli llm sono così bravi a generare codice Tailwind proprio perché Tailwind ha fatto un lavoro eccezionale nel creare documentazione chiara, esempi pratici, una community attiva. Tutti quei dati di alta qualità hanno allenato perfettamente le ai. Ma quella qualità è ora l’arma che lo sta uccidendo. È come se avessi passato anni a creare il miglior corso di programmazione del mondo, gratuito, accessibile a tutti. E poi qualcuno costruisce un robot che guarda tutti i tuoi video, memorizza tutto, e inizia a rispondere alle domande degli studenti al posto tuo. Più il tuo corso è buono, più il robot è efficace. E tu rimani lì, a guardare mentre gli studenti smettono di visitare il tuo sito, perché hanno il robot. Non so se c’è una via d’uscita da questo circolo vizioso. Non so se Wathan riuscirà a salvare Tailwind Labs. Non so cosa succederà a tutti gli altri progetti open source che si trovano nella stessa situazione. Quello che so è che siamo di fronte a un punto di svolta. L’intelligenza artificiale ha promesso di democratizzare lo sviluppo software, di rendere la programmazione accessibile a tutti. E probabilmente in qualche modo lo sta facendo. Ma il costo potrebbe essere l’intera infrastruttura di progetti open source, documentazione di qualità, community di esperti che per decenni hanno reso possibile quella democratizzazione. Quando l’ultimo progetto open source sostenibile chiuderà i battenti, su cosa si alleneranno le ai del futuro? È una domanda a cui non ho risposta. E forse il fatto stesso che non ci sia una risposta ovvia è la cosa più preoccupante di tutte. **Forse quello che stiamo vivendo è il momento in cui l’ecosistema open source scopre di essere stato troppo generoso, troppo aperto, troppo fiducioso. Il nostro settore è stato l 'unico che ha deciso che la conoscenza e l'innovazione dovesse essere distribuita pubblicamente.** Ha regalato conoscenza al mondo per decenni, costruendo le fondamenta su cui poggia quasi tutto il software moderno. E ora quella conoscenza è stata estratta, processata, e trasformata in prodotti commerciali che ne sono i diretti concorrenti. Non è colpa di nessuno in particolare, forse. È il risultato inevitabile di incentivi disallineati, di un modello economico che premiava l’apertura senza considerare le conseguenze a lungo termine. Ma il risultato è lo stesso: **un’intera generazione di sviluppatori che ha costruito cose incredibili potrebbe ritrovarsi senza i mezzi per continuare a farlo**. E questo, per qualcuno come me che ha sempre creduto nel potere dell’open source, è semplicemente devastante. --- # Quando la verità diventa un processo - **URL:** https://margiovanni.it/it/blog/quando-la-verita-diventa-un-processo/ - **Pubblicato:** 2026-01-08 - **Tag:** Etica, Informazione, Societa - **Tempo di lettura:** 13 min > C’è un momento preciso in cui ho capito che qualcosa si era rotto nel mio rapporto con la conoscenza. Stavo guardando... ![](https://substackcdn.com/image/fetch/$s_!tv-8!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3a6d6885-c45c-4794-927c-074eddd5527f_1013x745.png) C’è un momento preciso in cui ho capito che qualcosa si era rotto nel mio rapporto con la conoscenza. Stavo guardando un video su YouTube, un’intervista a un politico che diceva cose che mi sembravano assurde. Ho pensato: sarà un deepfake. Poi mi sono fermato. Non avevo nessun motivo reale per pensarlo, nessun glitch visivo, nessuna anomalia nel labiale. Semplicemente, il dubbio era diventato la mia reazione predefinita. E questo, mi sono reso conto, cambia tutto. Ho studiato filosofia per anni prima di dedicarmi all’informatica, e questa combinazione mi ha sempre fatto sentire a cavallo tra due mondi che faticano a parlarsi. Da una parte la tradizione epistemologica occidentale, con la sua ossessione per la corrispondenza tra pensiero e realtà, quell’ *adaequatio rei et intellectus* di Tommaso d’Aquino che ancora oggi echeggia nelle nostre intuizioni più basilari su cosa significhi che qualcosa sia vero. Dall’altra il mondo degli algoritmi, dei pattern statistici, delle reti neurali che producono testi e immagini indistinguibili da quelli umani senza avere la minima idea di cosa stiano facendo. Sono due linguaggi diversi, due ontologie diverse, e forse due epoche diverse che si sono trovate a coabitare nello stesso momento storico. ## Il dividendo del bugiardo {: #dividendo-del-bugiardo } La cosa che mi inquieta di più non è che esistano i deepfake. È che la loro sola esistenza ha cambiato il modo in cui guardo tutto il resto. Gli studiosi lo chiamano “dividendo del bugiardo”: anche senza creare un solo video falso, la tecnologia dei deepfake permette a chiunque di screditare qualsiasi prova autentica semplicemente dicendo “sarà stato generato dall’ai”. È geniale, anche se in un modo perverso. Non devi sostituire una verità con un’altra. Devi solo creare abbastanza rumore da rendere impossibile ogni certezza. Mi chiedo spesso se il postmodernismo ci abbia preparato a questo o se ci abbia solo reso più vulnerabili. Lyotard proclamava la fine delle grandi narrazioni nel 1979, Nietzsche già un secolo prima parlava delle verità come “illusioni di cui si è dimenticata la natura illusoria”. C’era qualcosa di liberatorio in quella critica, un modo per smascherare il potere che si nascondeva dietro le pretese di oggettività. Ma adesso mi domando se non abbiamo demolito gli strumenti che ci servirebbero per distinguere la disinformazione deliberata dalla legittima pluralità di interpretazioni. È un pensiero che mi mette a disagio, perché suona reazionario, e non credo di esserlo. Ma il disagio è forse il segnale che c’è qualcosa da capire. Quando leggo che nel 2023 sono stati rilevati quasi centomila video deepfake, con un aumento del 550 per cento dal 2019, quando scopro che oggi si può manipolare una videochiamata in tempo reale con costi inferiori a due euro, mi rendo conto che siamo entrati in un territorio dove le nostre intuizioni epistemologiche non funzionano più. Per millenni abbiamo dato per scontato che vedere fosse credere, che una fotografia fosse una prova, che un video mostrasse la realtà. Tutto questo è finito, e non so se ne siamo davvero consapevoli. ## Algoritmi e bolle filtro {: #algoritmi-bolle-filtro } C’è una frase di Walter Quattrociocchi che mi è rimasta impressa: “nell’era delle piattaforme e dell’intelligenza artificiale, la verità non è più oggettiva ma plasmata dall’algoritmo”. La prima volta che l’ho letta mi è sembrata esagerata, quasi una provocazione retorica. Ma più ci penso, più mi sembra una descrizione accurata di quello che viviamo. Gli algoritmi di raccomandazione non sono strumenti neutrali che ci mostrano informazioni rilevanti. Sono agenti attivi nella costruzione della nostra realtà percepita. Decidono cosa vediamo, in quale ordine, con quale frequenza. E lo fanno ottimizzando metriche di engagement, non di verità. Il risultato sono quelle che Eli Pariser ha chiamato filter bubbles, bolle filtro dove vediamo solo contenuti coerenti con le nostre credenze preesistenti. E le echo chambers, camere d’eco dove le nostre opinioni vengono amplificate e rinforzate da persone che la pensano come noi. Una ricerca su Twitter durante la pandemia ha mostrato che gli utenti con orientamenti politici di destra formavano camere d’eco particolarmente dense, con l’80 per cento del loro pubblico composto da persone simili a loro. Ma non è un problema solo della destra politica. È un problema strutturale, insito nell’architettura stessa delle piattaforme. La cosa che mi colpisce è come questo processo sia invisibile a chi lo subisce. Nessuno ti dice “stai entrando in una bolla”. Semplicemente, il tuo feed si popola di contenuti che ti piacciono, di opinioni che condividi, di persone che la pensano come te. E tu pensi di star vedendo il mondo, quando in realtà stai vedendo un riflesso sempre più distorto di te stesso. ## Post-verità e terreno comune {: #post-verita } Ho passato molto tempo a riflettere sul concetto di “post-verità”, quella parola che l’Oxford Dictionary ha eletto parola dell’anno nel 2016. La definizione ufficiale parla di una condizione in cui “i fatti oggettivi sono meno influenti nel formare l’opinione pubblica rispetto agli appelli all’emozione e alle credenze personali”. Ma mi sembra che manchi qualcosa. Non è solo che le emozioni contano più dei fatti. È che il concetto stesso di “fatto” è diventato contestabile, che la possibilità di un terreno comune su cui costruire il **disaccordo** si è erosa. Forse è questo il punto che mi spaventa di più. Una democrazia può sopravvivere al disaccordo, anzi ne ha bisogno. Ma può sopravvivere quando non c’è più accordo nemmeno su cosa costituisca un fatto? Quando ogni affermazione può essere respinta come fake news, ogni prova come manipolazione, ogni esperto come parte di un complotto? Penso spesso alla pandemia di covid-19 come a un esperimento naturale su larga scala. Avevamo un virus reale, con conseguenze reali, e un sistema scientifico che cercava di capirlo in tempo reale, con tutti i limiti e le incertezze che questo comporta. E abbiamo visto come l’ecosistema informativo digitale abbia amplificato la confusione, trasformando l’incertezza scientifica legittima in materiale per teorie del complotto, creando polarizzazione anche su questioni che in teoria avrebbero dovuto unirci. L’Organizzazione Mondiale della Sanità ha coniato il termine “infodemia” per descrivere quella sovrabbondanza di informazioni, alcune accurate e altre no, che rendeva difficile per le persone trovare orientamento. Ma forse il termine sottovaluta il problema. Non era solo troppa informazione. Era un ecosistema progettato per premiare l’engagement piuttosto che la verità, la polarizzazione piuttosto che la comprensione. Il bias di conferma è vecchio quanto l’umanità. Tendiamo a cercare, interpretare e ricordare informazioni che confermano quello che già crediamo. Ma gli algoritmi hanno trasformato una tendenza psicologica in un’architettura tecnologica. Hanno automatizzato il bias di conferma, lo hanno industrializzato. E così quello che prima era un difetto cognitivo da correggere è diventato un modello di business da ottimizzare. Mi colpisce la velocità con cui le fake news si diffondono rispetto alle informazioni verificate. Uno studio del mit ha mostrato che le notizie false su X si propagano sei volte più velocemente di quelle vere. Non è un caso. Le fake news sono progettate per essere emotivamente coinvolgenti, sensazionalistiche, polarizzanti. Fanno leva sulle nostre reazioni istintive, sui centri del cervello che rispondono prima che la corteccia prefrontale abbia il tempo di analizzare criticamente. È una forma di hacking cognitivo, e funziona perché sfrutta le stesse vulnerabilità che ci hanno permesso di sopravvivere come specie. ## LLM e la fine della verità come stato {: #llm-verita-stato } Quello che mi affascina, ma in un modo inquietante, è come l’intelligenza artificiale stia cambiando non solo la quantità ma la qualità della disinformazione possibile. I large language models come gpt non sanno cosa sia vero. Non hanno accesso a una realtà esterna da verificare. Sono macchine statistiche che predicono quale parola viene dopo l’altra, basandosi su pattern appresi da miliardi di testi umani. Ma il risultato è così convincente, così fluido, così apparentemente ragionato, che è facilissimo dimenticarsi di cosa sta realmente succedendo sotto il cofano. Un filosofo che ho letto di recente poneva una domanda che mi ha fatto riflettere a lungo: “cosa significa che un sistema ‘conosce’ qualcosa se non ha consapevolezza o intenzionalità?”. È una domanda che tocca il cuore di quello che abbiamo sempre pensato fosse la conoscenza. Per Platone la conoscenza era credenza vera giustificata. Ma può esserci credenza senza un soggetto che crede? Può esserci giustificazione senza comprensione? Stiamo forse assistendo all’emergere di una “conoscenza” puramente inferenziale, funzionale, statistica, senza quel legame con il mondo che la filosofia occidentale ha sempre considerato essenziale? Non ho risposte, solo domande. Ma forse è giusto così. Forse in questo momento le domande sono più importanti delle risposte. ## Onlife e ibridazione cognitiva {: #onlife-ibridazione } C’è un concetto che Luciano Floridi ha introdotto e che mi aiuta a pensare alla nostra condizione: “onlife”. L’idea è che i confini tra online e offline, tra digitale e fisico, tra reale e virtuale si stiano dissolvendo. Non viviamo più nel mondo fisico con occasionali escursioni nel digitale. Viviamo in uno spazio ibrido dove le due dimensioni si compenetrano. E questo cambia non solo come conosciamo ma chi siamo. Mi riconosco in questa descrizione. Il mio io digitale non è una maschera che indosso quando vado online. È parte di me, una parte che interagisce con algoritmi, si esprime attraverso avatar, delega porzioni della propria identità a profili su piattaforme che non controllo. È una forma di ibridazione che forse i miei nonni avrebbero faticato a comprendere, ma che per me è semplicemente normale. E questo mi fa pensare a quanto velocemente ci adattiamo a cambiamenti che, visti da una certa distanza, sono radicali. Del resto l’ibridazione non è solo digitale. Milioni di persone vivono con pacemaker, protesi, impianti. La nostra evoluzione verso il cyborg è già in corso, ed è molto meno fantascientifica di quanto immaginiamo. Ma mentre l’ibridazione fisica è stata generalmente accolta come progresso medico, l’ibridazione cognitiva suscita più ambivalenza. Forse perché tocca qualcosa di più intimo, qualcosa che consideriamo il nucleo del nostro essere: il pensiero, la ragione, la capacità di conoscere. Quello che mi preoccupa non è l’ibridazione in sé. È la possibilità che stiamo delegando troppo alle macchine senza capire cosa stiamo perdendo. C’è una citazione di Hannah Arendt che mi perseguita da quando l’ho letta: > Se la conoscenza si separasse irreparabilmente dal pensiero, allora diventeremmo esseri senza speranza, schiavi non tanto delle nostre macchine quanto della nostra competenza, creature prive di pensiero alla mercé di ogni dispositivo tecnicamente possibile. Arendt scriveva negli anni sessanta, molto prima di internet, prima dei social media, prima dell’intelligenza artificiale generativa. Ma le sue parole sembrano descrivere un rischio che oggi è molto più concreto di quanto non fosse allora. Gli studi sui nativi digitali mostrano tendenze preoccupanti: elaborazione superficiale delle informazioni, rapido spostamento dell’attenzione, ridotte capacità di riflessione prolungata. Non è una condanna morale, è una descrizione di come i nostri cervelli si stanno adattando a un ambiente informativo progettato per catturare l’attenzione piuttosto che alimentare la comprensione. E mi chiedo se stiamo creando le condizioni per quella separazione tra conoscenza e pensiero di cui parlava Arendt. Ma forse sono troppo pessimista. Forse ogni generazione ha pensato che la successiva stesse perdendo qualcosa di essenziale, e ogni volta la storia ha smentito quel pessimismo. O forse questa volta è diverso. Non lo so. L’onestà intellettuale mi impone di ammettere che non lo so. ## Fiducia e i limiti dell'alfabetizzazione {: #fiducia-alfabetizzazione } Quello che so è che uno dei risultati di tutto ciò è che i dati sulla fiducia nelle istituzioni sono allarmanti. In Italia la fiducia nel sistema istituzionale è inferiore alla media europea. Solo un cittadino su cinque dichiara di avere fiducia nei partiti politici. La fiducia nel Parlamento è al 37 per cento, nei partiti al 24. Persino la Presidenza della Repubblica, tradizionalmente l’istituzione più rispettata, ha registrato un calo significativo. Non sono numeri astratti. Sono il segno di una frattura tra società e istituzioni che rende più difficile affrontare qualsiasi sfida collettiva, dalla transizione ecologica a quella digitale. La fiducia nei media tradizionali ha seguito una traiettoria simile. E questo crea un circolo vizioso: meno fiducia nei media significa più vulnerabilità alla disinformazione, che a sua volta erode ulteriormente la fiducia. È un sistema che si autoalimenta, e non vedo come possa stabilizzarsi senza interventi strutturali. L’Unione Europea ha provato a rispondere con l’AI Act, un regolamento che introduce obblighi di trasparenza per i contenuti generati dall’intelligenza artificiale, inclusi i deepfake. L’idea è semplice: se non puoi impedire la creazione di contenuti sintetici, almeno puoi obbligare chi li produce a etichettarli come tali. Ma mi chiedo quanto possa funzionare in pratica. Chi crea disinformazione deliberatamente non si farà certo fermare da un obbligo di etichettatura. **E chi la consuma spesso non vuole essere disingannato.** L’alfabetizzazione mediatica viene spesso citata come la soluzione educativa al problema. Insegnare alle persone a verificare le fonti, a riconoscere i segnali della disinformazione, a resistere al bias di conferma. È un obiettivo nobile, e certamente necessario. Ma mi chiedo se sia sufficiente. **I bias cognitivi non sono errori che si correggono con l’istruzione. Sono scorciatoie mentali profondamente radicate nella nostra architettura cognitiva.** E gli algoritmi sono progettati da alcune delle menti più brillanti del pianeta proprio per sfruttarli. È una corsa agli armamenti asimmetrica, e non sono sicuro che l’educazione possa vincerla da sola. Forse la cosa più importante è riconoscere che non stiamo affrontando un problema tecnico che richiede una soluzione tecnica. **Stiamo affrontando una trasformazione antropologica che richiede un ripensamento profondo di cosa significhi conoscere, comunicare, fidarsi.** Non è qualcosa che si risolve con un’app o con un corso di formazione. È qualcosa che richiede un lavoro culturale di lungo periodo, una rinegoziazione collettiva di cosa consideriamo vero e di come arriviamo a considerarlo tale. ## La verità come processo {: #verita-come-processo } C’è una proposta che mi sembra promettente, anche se non so quanto sia realizzabile: passare da una concezione della verità come stato a una concezione della verità come processo. Non più qualcosa che si possiede o si scopre una volta per tutte, ma qualcosa che si costruisce continuamente attraverso validazione, verifica, confronto, revisione. Non un relativismo dove tutto vale ugualmente, ma un realismo critico che riconosce sia l’esistenza di una realtà indipendente sia la natura mediata, parziale, contestuale della nostra conoscenza di essa. È un equilibrio difficile da mantenere. Da un lato c’è il rischio di un oggettivismo ingenuo che ignora quanto le nostre categorie concettuali influenzino ciò che vediamo. Dall’altro c’è il rischio di un relativismo che dissolve ogni criterio di distinzione tra informazione affidabile e disinformazione. Trovare la via di mezzo richiede una forma di saggezza epistemologica che forse dobbiamo ancora imparare a coltivare. Quattrociocchi ha scritto qualcosa che mi sembra catturare bene questa idea: > La verità del futuro non sarà un punto fisso, ma un processo di validazione continua, in cui dati e conoscenza si costruiscono in modo più trasparente e verificabile. Mi piace questa formulazione, anche se non so quanto sia realistica. Ma forse è proprio questo il punto: non sappiamo cosa sia realistico perché siamo nel mezzo di una trasformazione i cui esiti non sono ancora determinati. Possiamo ancora influenzarli, se scegliamo di farlo. Quando ripenso a quel video che mi ha fatto venire il dubbio del deepfake, mi rendo conto che il problema non era il video in sé. Il problema era che il dubbio era diventato il mio stato predefinito. Ho perso qualcosa che non sapevo nemmeno di avere: una fiducia di base nella possibilità di distinguere il vero dal falso, il reale dall’artefatto. E mi chiedo quante altre persone stiano vivendo la stessa cosa, magari senza nemmeno rendersene conto. Non so quale sia la strada per uscire da questa condizione. Non credo che esista una soluzione semplice, un intervento che risolva tutto. Ma credo che il primo passo sia prendere coscienza di dove ci troviamo, della profondità della trasformazione in corso, della posta in gioco. E poi, forse, provare a costruire insieme qualcosa di diverso. Non tornare a un passato che non può tornare, ma immaginare un futuro dove la verità non sia né un idolo intoccabile né un’illusione da abbandonare, ma un progetto collettivo a cui partecipare. L’alternativa, quella che qualcuno ha chiamato “ipnocrazia”, un regime di controllo cognitivo attraverso la manipolazione algoritmica, mi sembra molto peggiore. E dovremmo provare e fallire piuttosto che non provare affatto. E forse questo, alla fine, è l’unico modo di restare umani in un’era dove l’umanità stessa è messa in discussione. Non arrendersi al cinismo, non cedere alla disperazione, ma continuare a cercare, a dubitare, a domandare. Anche quando le risposte non arrivano. **Soprattutto quando le risposte non arrivano.** --- # La fine del Trust and Safety Council di Twitter: quando i controlli scompaiono - **URL:** https://margiovanni.it/it/blog/la-fine-del-trust-and-safety-council/ - **Pubblicato:** 2026-01-03 - **Tag:** Etica, Moderazione, Social Media - **Tempo di lettura:** 12 min > Mi sono accorto che ultimamente, quando penso a Twitter, o X come dovrei ormai chiamarlo, mi viene in mente quella... ![](https://substackcdn.com/image/fetch/$s_!y-qZ!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fccae1fdd-81d9-42ae-b6f4-432c8e9e87bc_1024x1024.png) Mi sono accorto che ultimamente, quando penso a Twitter, o X come dovrei ormai chiamarlo, mi viene in mente quella sensazione che provi quando torni in un posto che amavi e non lo riconosci più. I muri sono gli stessi, ma l’atmosfera è completamente diversa. È quello che mi succede ogni volta che apro l’app, scorro un po’ e poi la chiudo con una vaga sensazione di disagio. Forse è il tono generale che è cambiato, o forse sono le cose che vedo emergere più facilmente, senza filtri. Non lo so. Ma so che c’è stato un momento preciso in cui qualcosa si è rotto, e quel momento risale a dicembre 2022, quando Elon Musk ha sciolto il Trust and Safety Council di Twitter. Ho passato parecchio tempo a ripensare a quella storia, cercando di capire cosa fosse davvero quel consiglio e perché la sua eliminazione mi sembri così significativa. La risposta che mi sono dato non è semplice, e forse è proprio per questo che mi ci sono affezionato. ## Cos'era il Trust and Safety Council {: #cos-era-il-council } Il Trust and Safety Council era nato nel febbraio 2016, come risposta alle critiche che Twitter riceveva per la sua gestione dei contenuti dannosi. Circa cento organizzazioni indipendenti, esperti di diritti civili, accademici, attivisti, si erano messi insieme per dare consigli a Twitter su come affrontare questioni delicate. Hate speech, sfruttamento minorile, prevenzione del suicidio, salute mentale. Non avevano alcun potere decisionale, sia chiaro questo punto. Non decidevano quali account bannare o quali post rimuovere. Erano consulenti, persone che Twitter ascoltava quando doveva prendere decisioni complesse. Patricia Cartes, la dipendente di Twitter che aveva creato questo consiglio, lo aveva immaginato come un modo per portare una prospettiva globale, per evitare che la piattaforma rimanesse troppo ancorata a una visione americana. E per sei anni, con tutti i suoi limiti, aveva funzionato. ## La promessa tradita di Musk {: #promessa-tradita } Quando Elon Musk ha completato l’acquisizione di Twitter per 44 miliardi di dollari, il 27 ottobre 2022, aveva fatto una promessa che sembrava ragionevole. Avrebbe formato un “content moderation council” con “widely diverse viewpoints”, e nessuna decisione importante sarebbe stata presa prima che questo consiglio si riunisse. In quel momento, mi ero detto che forse le preoccupazioni erano esagerate. Sembrava un approccio prudente, quasi rassicurante. Ma quella promessa non si è mai realizzata. Non c’è mai stato un nuovo consiglio. E quello vecchio, quello che esisteva da sei anni, è stato progressivamente marginalizzato fino a scomparire del tutto. A novembre 2022 Twitter ha licenziato circa la metà dei suoi dipendenti, parliamo di 3.700 persone. Il team Trust and Safety è stato ridotto del 15 per cento. Yoel Roth, che guidava questo team, aveva cercato inizialmente di rassicurare tutti, dicendo che le politiche di moderazione dei contenuti non sarebbero cambiate. Ma era una difesa fragile, costruita su fondamenta che stavano già cedendo. **Poche settimane dopo, Roth si è dimesso.** ## Il caso Yoel Roth {: #caso-roth } La storia di Yoel Roth è quella che mi ha colpito di più in tutta questa vicenda, e credo che meriti di essere raccontata per intero. Era a Twitter dal 2014, aveva costruito il team di Site Integrity da zero portandolo a 220 persone. Aveva lavorato su cose importanti: la lotta contro la disinformazione durante le elezioni americane, il contrasto alle operazioni di information warfare. Era, in sostanza, una delle persone che sapeva davvero come funzionava tutto il sistema di moderazione della piattaforma. Dopo le sue dimissioni, Musk ha iniziato ad attaccarlo pubblicamente. Ha preso un paragrafo dalla dissertazione di dottorato di Roth del 2016, uno studio accademico su Grindr e le dinamiche della comunità lgbtq, lo ha citato fuori contesto e ha insinuato che Roth fosse un sostenitore della pedofilia. Era una distorsione totale, una falsità costruita deliberatamente per alimentare la rabbia online. **Le conseguenze sono state immediate e terribili. Roth ha ricevuto migliaia di minacce. Ha dovuto lasciare la sua casa con suo marito. Ha venduto la casa e si è nascosto per mesi. Ha avuto bisogno di protezione armata.** In un’intervista su MSNBC nel 2023, Roth ha detto chiaramente cosa pensava fosse successo: > I believe he was trying to ensure I would not speak up about him or the company in the future. And the way he tried to secure that was intimidating me by violence. Ogni volta che rileggo quella frase mi fermo un momento. Non è solo un licenziamento, non è nemmeno solo una critica pubblica. È un tentativo deliberato di silenziare qualcuno attraverso la paura e l’intimidazione. E il fatto che venga dall’uomo più ricco del mondo, con accesso a milioni di follower, rende tutto ancora più inquietante. A dicembre 2022, tre membri chiave del Trust and Safety Council si sono dimessi: Eirliani Abdul Rahman, Anne Collier e Lesley Podesta. Nella loro lettera di dimissioni hanno scritto qualcosa che, con il senno di poi, suona profetico: > Contrary to claims by Elon Musk, the safety and wellbeing of Twitter’s users are on the decline. Anne Collier, che era stata membro fondatore del consiglio nel 2016, aveva osservato: > It is evident from research findings that, contrary to Elon Musk’s assertions, the safety and well-being of Twitter’s users are deteriorating. Non erano parole in libertà, erano osservazioni basate su anni di esperienza diretta. La risposta di Musk è stata brutale e disonesta. Ha accusato il consiglio, e in particolare quei tre membri che si erano dimessi, di non aver fatto nulla per anni contro lo sfruttamento minorile. Jack Dorsey, l’ex ceo di Twitter, ha risposto semplicemente: “this is false”. E aveva ragione. Il consiglio aveva sempre avuto un gruppo dedicato proprio allo sfruttamento minorile, che includeva organizzazioni come il National Center for Missing & Exploited Children. ## Lo scioglimento e i Twitter Files {: #scioglimento-e-twitter-files } Il 12 dicembre 2022, Twitter ha sciolto completamente il Trust and Safety Council. L’email di comunicazione è arrivata circa un’ora prima di un meeting che era stato programmato con i membri del consiglio. L’email era firmata semplicemente “Twitter”, nessun nome personale. La motivazione ufficiale era che il consiglio “is not the best structure” per ricevere consulenze esterne. Patricia Cartes, che aveva creato il consiglio nel 2016 e aveva lasciato Twitter nel 2018, ha commentato con una frase semplice ma devastante: > means there’s no more checks and balances. Mi sono fermato a lungo su quella frase. I checks and balances, i controlli e i contrappesi, sono quello che impedisce al potere di concentrarsi troppo in un punto. Sono quello che ci protegge dagli abusi. E quando scompaiono, non succede nulla di visibile nell’immediato. Semplicemente si apre uno spazio dove prima c’era un limite. Nel frattempo, Musk aveva lanciato i Twitter Files, una serie di rilasci di documenti interni affidati a giornalisti come Matt Taibbi e Bari Weiss. L’idea dichiarata era quella di mostrare trasparenza, di far vedere come funzionavano davvero le decisioni di moderazione dei contenuti. Ma c’era un problema enorme: i nomi dei dipendenti di Twitter, anche quelli di basso livello, non erano censurati. Uno staff member delle Filippine è stato doxxato e sottoposto a harassment grave. Altri sono diventati bersaglio di teorie cospirative. Decisioni prese da team di dozzine di persone secondo le policy aziendali sono state presentate come capricci arbitrari di singoli individui, ognuno dei quali veniva nominato e additato. [Mike Masnick](), giornalista tech, ha commentato dopo il primo rilascio che in realtà non c’era “absolutely nothing of interest” nei documenti, e i pochi dettagli presenti contenevano significative inesattezze fattuali. Anche Musk alla fine si è stancato dell’iniziativa. Ma il danno era fatto. ## Hate speech e fuga degli inserzionisti {: #hate-speech-advertiser } I numeri raccontano una storia che Musk ha sempre negato, ma che la ricerca ha documentato in modo abbastanza chiaro. Uno studio della Montclair State University ha rilevato che nelle prime 12 ore dopo l’acquisizione di Musk ci sono stati 4.778 tweet contenenti hate speech, mentre prima dell’acquisizione il massimo era 84 tweet all’ora. Non è stato solo un picco temporaneo. Uno studio dell’Università della California Berkeley, pubblicato su PLOS ONE nel 2025, ha analizzato l’hate speech su X dal gennaio 2022 al giugno 2023, rilevando un aumento costante del 50 per cento per almeno otto mesi dopo l’acquisizione. Gli slur transfobici sono passati da circa 115 post a settimana a 418. L’engagement con contenuti di odio è aumentato del 70 per cento. E no, non c’è stata alcuna riduzione degli account bot, contrariamente alle promesse di Musk. Mi chiedo spesso cosa significhi davvero quel 50 per cento in più. Non sono solo numeri su un grafico. Sono persone reali che vedono insulti razzisti, omofobici, transfobici quando aprono l’app. Sono comunità marginalizzate che si sentono meno sicure in uno spazio che prima frequentavano. È un clima che cambia, lentamente ma inesorabilmente, e che influenza il modo in cui le persone si esprimono, cosa dicono e cosa tacciono. Gli advertiser se ne sono accorti subito. A novembre 2022, grandi marchi come General Motors, General Mills, Macy’s e Volkswagen hanno sospeso la pubblicità su Twitter. Musk stesso ha parlato di “massive drop in revenue”. Dati successivi hanno mostrato che Twitter ha perso metà dei suoi ricavi pubblicitari, con oltre 500 advertiser che hanno smesso di spendere sulla piattaforma. Non era solo una questione economica. Era un voto di sfiducia. Gli inserzionisti non volevano che i loro brand apparissero accanto a contenuti d’odio e disinformazione. E quando Musk ha cambiato le policy, reintegrando Donald Trump dopo un sondaggio su Twitter nel novembre 2022, rimuovendo le protezioni per gli utenti transgender dalle linee guida ad aprile 2023, gli advertiser hanno capito che la direzione era chiara. Alcuni sono tornati. Apple, Comcast, Disney, IBM hanno ripreso a fare pubblicità su X nel 2024 e 2025, anche se con budget molto più ridotti rispetto al passato. Ma la fiducia non è tornata. E forse non tornerà mai del tutto. C’è un paradosso interessante nelle statistiche sulla sicurezza dei minori. Musk aveva accusato il Trust and Safety Council di non aver fatto abbastanza contro lo sfruttamento minorile. Ma i numeri raccontano una storia più complessa. Nel secondo semestre 2021, Twitter aveva rimosso circa 600.000 account per sfruttamento minorile. Nel 2022, sotto Musk, sono stati rimossi 2,3 milioni di account. Nel 2023 il numero è schizzato a 12,4 milioni, con 850.000 report inviati al National Center for Missing & Exploited Children, otto volte più del 2022. Sono numeri impressionanti, e sembrano suggerire un miglioramento. Ma ho passato un po’ di tempo a pensarci, e mi sono reso conto che potrebbero significare anche il contrario. Più account da rimuovere potrebbe voler dire più materiale di abuso presente sulla piattaforma. E con un team di Trust and Safety ridotto del 15 per cento e un approccio che privilegia l’automazione rispetto alla moderazione umana, è difficile dire se questi numeri rappresentino un successo o una crisi gestita male. Mi manca la competenza per dare una risposta definitiva, ma il dubbio mi rimane. Del content moderation council promesso da Musk non c’è mai stata traccia. Non è mai stato creato, non c’è mai stata una riunione, non c’è mai stato un annuncio ufficiale che dicesse “abbiamo cambiato idea”. È semplicemente svanito, come se non fosse mai stato promesso. Al suo posto, Musk ha introdotto Community Notes, precedentemente chiamato Birdwatch, un sistema di fact-checking crowdsourced dove gli utenti possono aggiungere contesto ai post. L’idea in teoria è interessante: democratizzare la moderazione, dare voce alla comunità. Ma la ricerca mostra che è problematico. Uno studio ha rilevato che nel 91 per cento dei post dove almeno una nota è stata proposta, nessuna ha raggiunto lo status di “helpful”. Il ritardo medio per ottenere una nota helpful è di 26 ore, ben oltre il momento di massima visibilità di un post. E il 74 per cento delle note accurate relative alle elezioni presidenziali americane del 2024 non sono mai state mostrate agli utenti. Community Notes può funzionare, ma solo se il contesto arriva in tempo. E nella maggior parte dei casi, non arriva. ## Cosa abbiamo davvero perso {: #cosa-abbiamo-perso } Ripensando a tutto questo, mi rendo conto che non abbiamo perso solo un organo consultivo. Abbiamo perso un modello di governance che, per quanto imperfetto, cercava di bilanciare diversi interessi: la libertà di espressione, la sicurezza degli utenti, i diritti delle comunità marginalizzate. Il Trust and Safety Council non era perfetto. Alcuni membri si erano lamentati già prima dell’acquisizione di Musk che Twitter li ignorava. Ma era un tentativo di fare qualcosa che le piattaforme social faticano ancora a fare: ascoltare voci diverse, incorporare expertise esterna, ammettere che le decisioni di moderazione sono complesse e richiedono sfumature. Al suo posto abbiamo un modello diverso: decisioni prese “by edict”, come ha scritto Yoel Roth nel suo op-ed sul New York Times. Un solo uomo, con le sue convinzioni e i suoi pregiudizi, che decide cosa è accettabile e cosa no. E quando qualcuno critica o si dimette, viene attaccato pubblicamente, minacciato, costretto a nascondersi. Una cosa che mi ha colpito particolarmente è stata la lettera congiunta di 16 membri del Trust and Safety Council dopo lo scioglimento. Hanno condannato “the dramatic changes to, and arbitrary enforcement of, content moderation policies and practices at Twitter”. Hanno sottolineato che il consiglio non prendeva decisioni su post o account specifici, non aveva voce in capitolo sugli investimenti o sull’approccio ai contenuti illegali. E poi hanno detto qualcosa che merita di essere ricordato: > We condemn the irresponsible actions of Twitter leadership in jeopardizing the safety of Council members, including those who resigned before Twitter disbanded the Council, by amplifying disinformation about us and the Council’s purely advisory role, sparking huge levels of abuse targeted at the resigning members. Erano persone che avevano dedicato anni, gratis, come volontari, per cercare di rendere Twitter un posto più sicuro. E sono stati ripagati con disinformazione, accuse false e minacce. Quello che è successo al Trust and Safety Council non riguarda solo Twitter. È un precedente. Mostra cosa può succedere quando una piattaforma che ha un impatto enorme sulla vita pubblica viene controllata da una sola persona che non è disposta ad accettare limiti o consigli esterni. Le conseguenze le stiamo vedendo ora. X è diventato un posto diverso. L’hate speech è aumentato in modo misurabile. Gli advertiser sono fuggiti e solo alcuni stanno tornando, con molta cautela. Gli utenti stanno migrando verso altre piattaforme, Bluesky ha visto una crescita enorme proprio mentre alcune aziende tornavano timidamente su X. E soprattutto, abbiamo perso quella piccola illusione che le piattaforme social potessero essere governate attraverso un dialogo con la società civile, con esperti indipendenti, con chi si batte per i diritti umani. Mi viene spesso in mente la frase di Patricia Cartes, “there’s no more checks and balances”. Sembra esagerata, ma non lo è. Quando Musk ha sciolto il Trust and Safety Council, non ha solo eliminato un gruppo di consulenti. Ha mandato un messaggio: non ho bisogno di consigli esterni, non ho bisogno di esperti, non ho bisogno di bilanciare interessi diversi. Io decido. E questo, alla fine, è il punto che mi preoccupa di più. Non è solo Twitter. È un modello che si sta replicando altrove. Altre piattaforme guardano a quello che è successo e pensano di poter fare la stessa cosa, liberarsi delle voci scomode, di quei consulenti che rallentano le decisioni. Ma quelle voci scomode servivano a qualcosa. Servivano a ricordarci che dietro ogni decisione di moderazione ci sono persone reali, comunità reali, vite reali. E che forse, solo forse, le decisioni più difficili sono quelle che richiedono più tempo, più ascolto, più umiltà. Dicembre 2022 sembra lontano, ma le sue conseguenze sono ancora qui, ogni volta che apriamo X e vediamo cosa è diventato. La domanda che mi faccio non è tanto “come ci siamo arrivati”, perché quella risposta ormai la conosco. È piuttosto “dove stiamo andando”. Perché se non troviamo un modo per costruire quei controlli e contrappesi in ogni servizio di pubblica utilità, nelle piattaforme social come altrove, temo che la risposta non ci piacerà. --- # Airbus e il cloud sovrano europeo: il primo segnale credibile di un risveglio? - **URL:** https://margiovanni.it/it/blog/airbus-e-il-cloud-sovrano-europeo/ - **Pubblicato:** 2025-12-29 - **Tag:** Cloud, Europa, Sovranita-digitale - **Tempo di lettura:** 9 min > Qualche giorno fa ho letto una notizia che probabilmente è passata sotto silenzio a molti, nascosta tra i titoli sulla... Qualche giorno fa ho letto una notizia che probabilmente è passata sotto silenzio a molti, nascosta tra i titoli sulla geopolitica e la tecnologia. Airbus, il colosso europeo dell’aerospazio e della difesa, sta preparando una gara da oltre 50 milioni di euro per spostare le sue applicazioni più critiche su un cloud europeo “veramente sovrano”. L’ho letta quasi per caso, scorrendo le news di settore come faccio spesso la mattina presto, quando la testa è ancora abbastanza libera da riuscire a soffermarsi sui dettagli che altrimenti scivolano via. ![](https://substackcdn.com/image/fetch/$s_!aCm9!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fda3be29f-fd2c-4cad-9bb2-faddb367486d_1110x624.jpeg) Non è una notizia tecnica, lo voglio dire subito. È una notizia di strategia industriale, di geopolitica, di come l’Europa sta cominciando a guardarsi intorno e a domandarsi se è veramente costretta a dipendere dalle Big Tech americane. E confesso che mentre leggevo i dettagli, mi è venuto spontaneo chiedermi: è il primo segnale credibile di un possibile risveglio europeo, o stiamo di nuovo assistendo a una grande promessa che finirà in un cassetto pieno di buone intenzioni? La risposta, purtroppo, non è scontata. E forse proprio questa incertezza rende la storia così interessante. ## Cosa mette in gioco Airbus {: #cosa-mette-in-gioco-airbus } Per capire perché Airbus ha deciso di fare questa mossa, bisogna sapere cosa sta mettendo in gioco. Non parliamo di dati ordinari, di email o fogli di calcolo. Stiamo parlando di sistemi mission-critical che toccano i fondamenti dell’azienda: la gestione delle risorse, i sistemi di esecuzione della produzione, la gestione dei rapporti con i clienti, e soprattutto il PLM, il software di gestione del ciclo di vita dei prodotti che contiene tutti i dati di progettazione degli aerei. Questi non sono dettagli. Sono i segreti industriali, i progetti, le innovazioni che fanno di Airbus quello che è. Catherine Jestin, la vicepresidente esecutiva per gli affari digitali, ha detto chiaramente: > parliamo di informazioni estremamente sensibili dal punto di vista nazionale ed europeo. Vogliamo garantire che rimangano sotto controllo europeo. C’è un dettaglio che mi ha colpito particolarmente, e che rivela molto più di quanto sembri a prima vista. Airbus stessa stima soltanto un “80 per cento di probabilità” di trovare un provider completamente europeo all’altezza dei requisiti tecnici e di sicurezza. Un’azienda che vuole affidarsi all’Europa ammette candidamente che potrebbe non trovare nessuno in grado di farlo. Non so voi, ma a me questa cosa fa riflettere parecchio. Da un lato c’è il coraggio di cercare un’alternativa, dall’altro la consapevolezza amara che quell’alternativa potrebbe non esistere. ## Il Cloud Act e la sovranità non negoziabile {: #cloud-act-sovranita } Se vi chiedessi perché Airbus non vuole semplicemente usare Amazon Web Services, Microsoft Azure o Google Cloud, probabilmente molti rispondereste che sono i migliori, i più affidabili, quelli con la tecnologia più avanzata. E avete ragione. Sono tutto questo. Ma c’è un problema più grande, che si chiama Cloud Act. È una legge americana del 2018 che sostanzialmente permette alle autorità degli Stati Uniti di richiedere dati direttamente ai fornitori cloud americani, indipendentemente da dove si trovano i server. Anche se i vostri dati sono ospitati in un data center a Francoforte, Microsoft potrebbe essere legalmente obbligata a consegnarli al governo americano se esiste un ordine legale. Non c’è bisogno di trattati internazionali. Non c’è una procedura diplomatica. La legge americana semplicemente prevale. Ho passato un bel po’ di tempo a studiare questa cosa. All’inizio mi sembrava quasi un’esagerazione, una di quelle preoccupazioni da paranoici della privacy. Poi ho iniziato a vedere le implicazioni pratiche, a capire cosa significhi per un’azienda europea che lavora nella difesa, nell’aerospazio, nella tecnologia sensibile. È una spina nel fianco che non puoi ignorare. E il ritorno di Trump alla Casa Bianca ha amplificato questa preoccupazione. Non dico che Trump farà cose strane domani, ma l’incertezza attorno alle relazioni transatlantiche, ai dazi, ai possibili shutdown federali che potrebbero bloccare i servizi, ha fatto suonare un campanello d’allarme in tutta Europa. La sovranità digitale non è più una parola elegante da mettere nei documenti strategici. È diventata una questione di controllo sui dati, su cosa rimane sotto il tuo controllo e cosa no. ## Il deserto dei provider europei {: #deserto-provider-europei } Qui però comincia la parte frustrante della storia. Se chiedete a Airbus quali siano i candidati europei per gestire questa infrastruttura, la lista non è particolarmente lunga né confortante. C’è OVHcloud, il provider francese che sta cercando di posizionarsi come alternativa europea seria. Deutsche Telekom, attraverso la sua divisione T-Systems. Scaleway, un’altra opzione francese. SAP, che sta sviluppando piattaforme di cloud sovrano. E poi Orange, Telecom Italia, e una miriade di altri player più piccoli e nazionali. Ed ecco i numeri che fanno male. Secondo i dati più recenti, i provider europei controllano solo il 15 per cento del mercato cloud complessivo in Europa. Solo il 15 per cento. Mentre Amazon, Microsoft e Google insieme ne controllano il 70 per cento. SAP e Deutsche Telekom, i due leader europei, hanno ciascuno una quota del 2 per cento del mercato. OVHcloud, con tutta la sua ambizione, opera in 12 regioni nel mondo. AWS opera in 105 zone di disponibilità sparse in 33 regioni. Il divario tecnologico e di scala è semplicemente enorme, e non mi è chiaro come si possa colmare in tempi ragionevoli. E poi c’è il precedente di GAIA-X, che mi brucia ancora adesso quando ci penso. Se vi ricordate, GAIA-X era il progetto lanciato in pompa magna nel 2019 da Francia e Germania per creare un’infrastruttura cloud europea sovrana. Era la risposta europea ai giganti americani. Doveva essere l’Airbus dei dati, il progetto che finalmente avrebbe sottratto l’Europa dalla sudditanza digitale. Sapete come è andata a finire? Finito. Morto. Non per ragioni tecniche, ma per ragioni politiche. La Francia sognava un campione nazionale protetto dallo stato, una cosa alla OVHcloud potenziata. La Germania voleva qualcosa di più aperto, più federale, più incentrato sugli standard. Nel litigio tra i due, hanno lasciato spazi dove Microsoft, Google, Amazon e persino Palantir si sono infiltrati. Quello che doveva essere un’alternativa europea ai giganti americani è diventato un laboratorio burocratico di standardizzazione, completamente disconnesso dal mercato reale. Mentre i comitati di GAIA-X discutevano di norme, le aziende europee continuavano a firmare contratti miliardari con i provider americani. Questo precedente pesa come un macigno su qualsiasi discorso di sovranità digitale europea. Ed è un avvertimento che Airbus conosce benissimo. ## Il paradosso Palantir {: #paradosso-palantir } C’è un’altra cosa che mi preme sollevare, e che emerge leggendo tra le righe di tutta questa vicenda. Una cosa che nessuno vuole nominare esplicitamente, ma che è il vero nodo della questione. Sì, puoi spostare l’infrastruttura in Europa. Puoi avere i data center europei, la governance europea, tutto quello che vuoi. Ma una volta che i dati sono lì, dove vanno per essere analizzati, compresi, trasformati in decisioni intelligenti? Perché Airbus dal 2015 lavora con Palantir per analizzare i dati degli aerei. Hanno una partnership che si chiama Skywise, che sfrutta le tecnologie di Palantir per fare cose straordinarie: identificare difetti di fabbrica negli A350, predire la manutenzione, ottimizzare i flussi di lavoro. Hanno ridotto del 33 per cento i tempi di consegna. È un risultato impressionante. Ma Palantir è americana. E non esiste un equivalente europeo a Palantir. Ecco il paradosso che mi dà da pensare: si può spostare l’infrastruttura, si può avere il cloud sovrano, ma molti dei servizi avanzati, l’intelligenza artificiale, l’analytics di prossimo livello, rimangono comunque in mani americane. È come costruire una fortezza europea e poi scoprire che la chiave della stanza più importante è ancora in mano agli americani. Mi chiedo spesso se questa non sia la vera dipendenza da cui l’Europa fatica a liberarsi. Non tanto i server, ma i cervelli. Non tanto dove stanno i dati, ma chi li sa leggere. ## Segnale credibile o esercizio retorico {: #segnale-o-retorica } Voglio provare a guardarla dai due lati, questa storia, perché sarebbe intellettualmente disonesto fare altrimenti. Da un lato, quando Airbus, un’azienda del calibro di Airbus, manda al mercato un segnale così chiaro, inizia a crearsi una domanda che prima non esisteva. Le aziende si muovono quando vedono denaro e impegno da grandi attori. La scelta di Airbus arriva in un contesto dove altri movimenti stanno accadendo: il Data Act europeo che mira a ridurre il lock-in americano, i progetti militari dell’Unione Europea sul combat cloud, gli investimenti che SAP e Deutsche Telekom stanno facendo sul cloud sovrano. Altre storie stanno emergendo. Amministrazioni pubbliche, enti tedeschi, governi che iniziano a migrare dai servizi Microsoft. Non è un tsunami, ma è un movimento. C’è consapevolezza che dipendere totalmente da tre aziende americane è un rischio. Dall’altro lato, però, 50 milioni di euro in dieci anni sono più un segnale politico che un punto di svolta trasformativo per un settore da decine di miliardi di euro. Il mercato cloud europeo ha raggiunto nel 2024 circa 61 miliardi di euro e nel 2025 è cresciuto ancor più velocemente. 50 milioni sono lo 0,08 per cento di questo mercato. È una goccia nell’oceano. Il gap tra i provider europei e i giganti americani è enorme e non si chiude velocemente: > Gli hyperscaler americani investono circa 10 miliardi di euro ogni trimestre in capex in Europa. È una soglia che sembra impossibile da superare per qualsiasi azienda europea. Senza un cambiamento drastico, alleanze vere, forse anche consolidamenti strategici e vera integrazione industriale europea, il rischio è un altro caso GAIA-X: grandi promesse, impatto limitato. E questo sicuramente preoccupante. ## Cosa guarderò nei prossimi anni {: #cosa-guardare } Se voglio capire se il caso Airbus è davvero l’inizio di un risveglio, so già cosa devo guardare nei prossimi anni. Primo: altri grandi gruppi europei faranno scelte simili? La difesa, l’energia, le utilities, il banking. Inizieranno a spostare carichi di lavoro critici su cloud europeo? Se rimane solo Airbus, siamo davanti a un’eccezione interessante ma irrilevante. Secondo: accadrà un vero consolidamento tra i provider europei? O continueremo a vedere una frammentazione di soluzioni nazionali, ciascuna che serve il suo mercato locale? Perché la dimensione conta, e 15 piccoli player europei non potranno mai competere con tre giganti globali. Terzo: come reagiscono i regolatori europei? E come si evolvono le offerte sovereign cloud degli americani? Perché AWS, Microsoft e Google hanno già capito dove tira il vento. Stanno offrendo servizi sovereign cloud, garantendo residenza dei dati in Europa, creando partnership locali. Se riescono a offrire *tanto europeo quanto basta* mantenendo la loro superiorità tecnologica, allora Airbus potrebbe restare un’eccezione elegante ma solitaria. Quando guardo questa storia, non vedo né il tutto nero del “l’Europa è persa” né il tutto rosa del “il risveglio è arrivato”. Vedo il primo segnale credibile che qualcosa si sta muovendo, ma anche il ricordo di GAIA-X che sussurra: attento, potrebbe finire male anche questa volta. Airbus ha il coraggio di dire a voce alta “vogliamo il cloud sovrano europeo”. È importante. È un segnale. Ma per trasformarlo in un vero cambiamento strutturale del mercato ci vorrebbe una combinazione di cose: investimenti pubblici seri, consolidamento tra player europei, coraggio politico di proteggere i campioni nascenti, e una visione condivisa tra i governi europei su cosa significhi davvero sovranità digitale. E forse, più di tutto, ci vorrebbe smettere di litigare tra Francia e Germania ogni volta che c’è da costruire qualcosa insieme. Perché alla fine è sempre lì che si arena tutto. È sempre quel vecchio vizio europeo di preferire le proprie ragioni nazionali a un progetto comune. **E finché sarà così, gli americani avranno sempre un vantaggio che non dipende dalla tecnologia, ma dalla nostra incapacità di fare squadra**. Intanto, leggerò i prossimi mesi con molta curiosità. Perché non dipende solo da Airbus, ma da quello che faranno gli altri. E soprattutto da quello che saremo capaci di fare noi europei, finalmente insieme. --- # Qualità, velocità e il fantasma dell'artigiano perfetto - **URL:** https://margiovanni.it/it/blog/qualita-velocita-e-il-fantasma-dellartigiano/ - **Pubblicato:** 2025-12-26 - **Tag:** Intelligenza Artificiale, Qualita, Sviluppo Software - **Tempo di lettura:** 9 min > C’è un pensiero che mi accompagna da mesi, forse da quando l’intelligenza artificiale ha smesso di essere una promessa... ![](https://substackcdn.com/image/fetch/$s_!uwAS!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe044beb3-3b8b-4f65-89ca-5226f62d9477_1800x1200.png) C’è un pensiero che mi accompagna da mesi, forse da quando l’intelligenza artificiale ha smesso di essere una promessa lontana ed è diventata uno strumento che usiamo ogni giorno. È un pensiero scomodo, perché mette in discussione alcune convinzioni che mi hanno guidato per anni, e che forse erano più fragili di quanto volessi ammettere. Mi è tornato oggi in mente quando il [Prof. Zanero]() ha rilanciato questo skeet: ![](https://substackcdn.com/image/fetch/$s_!nnqC!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff20904a6-4763-41c8-b80d-65e4aa5ce8e2_1190x1598.png) ## Un pensiero scomodo {: #un-pensiero-scomodo } Il pensiero è questo: la qualità assoluta, quella ricercata come valore in sé, potrebbe essere un lusso che non possiamo più permetterci. Non sempre, non ovunque, non come principio universale. Lo scrivo e sento già le obiezioni, le stesse che mi sono fatto io per lungo tempo. “Ma la qualità paga sempre”, “Il debito tecnico si accumula”, “Chi taglia gli angoli fallisce nel lungo periodo”. Tutte cose vere, in un certo senso. E tutte cose che meritano di essere riesaminate alla luce di un mondo che è cambiato più velocemente di quanto fossimo pronti ad accettare. Ho passato anni a costruire team, a definire standard, a combattere per avere il tempo di fare le cose “per bene”. Ho discusso con commerciali che volevano tutto per ieri, con clienti che non capivano perché servisse più tempo, con sviluppatori che volevano spedire qualcosa di imperfetto. E nella maggior parte dei casi, credo di aver avuto ragione. Ma la ragione di allora non è necessariamente la ragione di oggi, e parte del mio lavoro è distinguere tra principi immutabili e abitudini travestite da principi. Il punto non è mai stato velocità contro qualità, come se fossero due poli opposti da scegliere. Il punto è sempre stato: quale qualità, per chi, quando, e quanto mi costa mantenerla nel tempo. Solo che oggi questa domanda ha risposte diverse da quelle che davo cinque anni fa, perché l’intelligenza artificiale ha cambiato le regole del gioco in modi che stiamo ancora cercando di capire. Quando un modello generativo può scrivere in pochi secondi codice che funziona, codice che un tempo avrebbe richiesto ore, la percezione del valore cambia. Non parlo di valore reale, parlo di percezione. E nel business la percezione conta, a volte più della realtà. Un cliente che vede un competitor sfornare funzionalità a ritmo serrato inizia a chiedersi perché noi siamo così lenti. E non basta spiegargli che il nostro codice è più pulito, più testato, più manutenibile. Queste sono cose che capirà solo quando avrà un problema, e a quel punto potrebbe essere troppo tardi per tutti. ## Quando l'artigianato funziona {: #quando-artigianato-funziona } Il modello artigianale puro, quello del “facciamo tutto a mano, con calma, con cura”, funziona ancora. Ma funziona solo in condizioni specifiche che non sempre si verificano. Hai bisogno di un problema davvero critico, dove un errore costa carissimo. Hai bisogno di pochi competitor credibili, perché se ce ne sono tanti il cliente ha alternative. E hai bisogno di un cliente disposto a pagare parecchio per dormire tranquillo, il che significa un cliente che capisce il rischio e ha le risorse per mitigarlo. Quando queste tre condizioni si allineano, l’artigianato è vincente. Quando manca anche solo una di esse, la promessa “noi facciamo tutto a mano, benissimo” rischia di essere percepita più come lentezza e costo che come valore. E non è colpa del cliente se non capisce, è responsabilità nostra trovare un modo per comunicare quel valore o, se non ci riusciamo, per adattarci al mercato che esiste davvero. ## La qualità come investimento progressivo {: #qualita-investimento-progressivo } Forse il trucco è smettere di pensare alla qualità come a un assoluto e iniziare a trattarla come un investimento progressivo, legato allo stadio del prodotto e alle esigenze reali del momento. È una prospettiva che mi ha richiesto tempo per accettare, perché va contro l’istinto di chi è cresciuto professionalmente credendo che le cose vadano fatte bene o non vadano fatte affatto. All’inizio di un prodotto, quando stai ancora cercando di capire se c’è un mercato, ti serve qualcosa di affidabile abbastanza su un perimetro molto piccolo. Non ti serve perfezione. Ti serve qualcosa che funzioni, che non crolli al primo utilizzo, e che sia progettato in modo abbastanza pulito da poter crescere senza implodere. È l’idea che alcuni chiamano “simple, lovable, complete”: poco, ma fatto bene su ciò che conta davvero. Non tutto lucidato alla perfezione, ma le cose giuste fatte con cura. Man mano che il prodotto trova mercato, che i clienti iniziano a pagare, che il fatturato cresce, alzi il livello di robustezza, sicurezza e rifinitura proprio sui pezzi che generano più valore o più rischio. Non lucidi ovunque in modo uniforme, perché non hai infinite risorse e non tutto merita lo stesso investimento. Concentri l’artigianato dove conta, dove un bug si traduce in danno diretto, dove la qualità fa la differenza tra un cliente che resta e uno che se ne va. E la velocità? La velocità vera non la ottieni scrivendo codice mediocre. Lo so perché ho visto abbastanza progetti affogare nel loro stesso debito tecnico per capire che i tagli agli angoli tornano sempre a morderti. La velocità la ottieni tagliando scope, decidendo cosa non fare, automatizzando i test, spostando i controlli di qualità il più vicino possibile al momento in cui il codice viene scritto. Specialmente quando c’è di mezzo l’intelligenza artificiale, che può produrre montagne di codice in poco tempo ma non ha il giudizio per capire cosa di quel codice meriti di esistere. In questo modo non stai scegliendo tra perfezione e shipping veloce. Stai scegliendo tra varie combinazioni su un fronte di possibilità che puoi spostare in base al contesto. È un modo più onesto di pensare al mestiere, credo. Meno romantico, forse, ma più utile. ## Qualità reale e qualità percepita {: #qualita-percepita } C’è poi una cosa scomoda di cui si parla poco, ed è il divario tra qualità reale e qualità percepita. Per il cliente la qualità è soprattutto esperienza, non implementazione interna. Un’interfaccia chiara, tempi di risposta buoni, assistenza presente e onesta coprono un sacco di difetti tecnici che non rompono il flusso. E paradossalmente puoi avere software tecnicamente molto raffinato ma percepito come mediocre perché lento da evolvere, poco allineato al bisogno, o comunicato male. L’ho visto succedere. Progetti su cui avevamo lavorato mesi per raggiungere standard altissimi, e che il cliente trovava frustranti perché non rispondevano alle sue esigenze reali. E progetti meno curati tecnicamente, ma che i clienti amavano perché risolvevano un problema specifico in modo semplice, e venivano aggiornati spesso senza drammi. Questo non significa che la qualità tecnica non conti. Significa che conta in relazione a tutto il resto, non come valore assoluto sganciato dal contesto. E significa che parte del nostro lavoro è capire cosa il cliente percepisce come qualità, non solo cosa noi sappiamo essere qualità. ## Dove mettere il tempo artigianale {: #dove-mettere-tempo-artigianale } La domanda che mi faccio più spesso ultimamente è: dove metto il mio tempo artigianale in un mondo in cui l’intelligenza artificiale può fare una grossa parte del lavoro standard? Non il sessanta, forse nemmeno l’ottanta per cento come qualcuno sostiene, ma comunque una porzione significativa di quello che una volta richiedeva ore di lavoro umano. A parità di costo, il cliente ti paga volentieri la parte in cui il tuo giudizio riduce un rischio grosso o aumenta tanto il risultato. Non ti paga la parte in cui riscrivi a mano qualcosa che un modello generativo può sfornare in pochi secondi. E se insisti a fatturare il tempo come se l’ai non esistesse, prima o poi troverai qualcuno che offre lo stesso risultato a metà prezzo, perché ha capito come usarla. Ho iniziato a ragionare in termini diversi. Faccio a mano, con standard altissimi, tutto ciò che è vicino al denaro, al rischio legale o reputazionale, alla sicurezza. I pezzi dove un bug si traduce in danno diretto, dove serve giudizio e non solo esecuzione. E lascio fare all’ai, sotto supervisione attenta, tutto ciò che è commodity, ripetitivo, facilmente testabile, sostituibile. Non perché mi fidi ciecamente, ma perché so dove controllare e cosa verificare. Il prezzo, poi, dovrebbe riflettere più il rischio che ti prendi e il valore che abiliti, che non il numero di ore che ci hai messo sopra. È un cambiamento che richiede tempo per essere accettato, sia da parte nostra che da parte dei clienti. Ma è la direzione verso cui stiamo andando, che ci piaccia o meno. ## Chi rischia di fallire {: #chi-rischia-fallire } E chi rischia davvero di fallire in questo nuovo mondo? Mi sono fatto questa domanda molte volte, cercando di capire dove stessero i pericoli veri. Non credo che a rischiare siano quelli che amano la qualità. Credo che a rischiare siano quelli che confondono perfezionismo con professionalità, che rallentano sempre, che non sanno dire “questo oggi non serve”. Quelli che lucidano all’infinito mentre il mercato li sorpassa, convinti che prima o poi il mondo riconoscerà il loro valore. A volte succede. Spesso no. E rischiano anche quelli all’estremo opposto: chi rincorre solo la velocità, satura il sistema di cambiamenti non governati, accumula debito tecnico senza nemmeno rendersene conto. Prima o poi i problemi emergono, i clienti perdono fiducia, e tutto il tempo risparmiato all’inizio si paga con gli interessi. Chi ha una chance migliore, secondo me, è chi riesce a fare tre cose insieme. Usare l’intelligenza artificiale per correre, perché non farlo significa restare indietro. Usare la testa per decidere dove fermarsi a rifinire, perché non tutto merita la stessa cura. E usare l’onestà nel raccontare al cliente che tipo di qualità sta comprando e perché. Quest’ultima parte è forse la più difficile. Richiede di ammettere che non tutto quello che facciamo è perfetto, che ci sono compromessi, che alcune scelte sono fatte per ragioni di tempo o budget e non per ragioni tecniche. Richiede di fidarsi che il cliente possa capire, o almeno di provarci. E richiede di accettare che a volte non capirà, e che dovremo trovare un modo per andare avanti lo stesso. Sono riflessioni in corso, non conclusioni definitive. Il mestiere sta cambiando sotto i nostri piedi, e chi pretende di avere tutte le risposte probabilmente non ha capito bene le domande. Quello che so è che l’equilibrio tra qualità e velocità non è più quello di una volta, che l’intelligenza artificiale ha ridisegnato i confini del possibile, e che il nostro compito è trovare un nuovo modo di creare valore in questo contesto diverso. Non significa abbandonare i principi. Significa capire quali principi sono davvero principi e quali erano solo abitudini che avevano senso in un mondo che non esiste più. **È un lavoro di discernimento che richiede umiltà, onestà intellettuale, e la disponibilità a mettere in discussione le proprie certezze.** E forse, alla fine, è proprio questo che distingue un bravo professionista da uno che sta solo ripetendo formule imparate: **la capacità di adattarsi senza perdersi, di cambiare senza tradire, di evolvere restando fedeli a ciò che conta davvero**. Che non è la qualità in sé, ma il valore che quella qualità crea per chi ne ha bisogno. --- # Una storia di Natale, di occhiali smart e di genitori smarriti - **URL:** https://margiovanni.it/it/blog/una-storia-di-natale-di-occhiali/ - **Pubblicato:** 2025-12-26 - **Tag:** Privacy, Societa, Tecnologia - **Tempo di lettura:** 10 min > È il giorno di Natale e suona il campanello. Apro la porta e mi trovo davanti un parente con un bambino di meno di... ![](https://substackcdn.com/image/fetch/$s_!sW0A!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F351a9924-602f-44c8-9bbe-2bd5829c25c1_1024x1024.png) È il giorno di Natale e suona il campanello. Apro la porta e mi trovo davanti un parente con un bambino di meno di dieci anni che indossa un paio di occhiali Meta Ray-Ban. Il bambino sorride, salta da un piede all’altro con l’entusiasmo che solo i bambini riescono ad avere, e annuncia con voce squillante: “sto facendo le fotoooo!”. L’adulto accanto a lui non batte ciglio, anzi, sembra quasi fiero di questo gadget che il piccolo sfoggia come fosse un trofeo. E io resto lì, sulla soglia, con un misto di incredulità e disagio che fatico a mascherare. ## Il bambino sulla soglia {: #bambino-sulla-soglia } Non è facile spiegare cosa c’è che non va in questa scena senza sembrare quello che rovina la festa, il rompiscatole che vede problemi ovunque. Eppure qualcosa mi si annoda nello stomaco. Perché quel bambino sta entrando in casa mia con un dispositivo capace di registrare video, scattare foto, catturare audio, e nessuno, proprio nessuno, sembra trovarci nulla di strano. Nessuno si è fermato a chiedermi se fossi d’accordo. Nessuno si è posto il problema del consenso, della privacy, del fatto che quegli occhiali stanno potenzialmente immortalando tutto ciò che accade senza che io abbia voce in capitolo. Ma forse il problema più grande non sono nemmeno gli occhiali in sé. È l’atteggiamento, questa leggerezza quasi ostentata con cui si consegna a un bambino uno strumento di sorveglianza trasformandolo in un gioco. È la normalizzazione di qualcosa che, se ci fermassimo un attimo a riflettere, ci farebbe rabbrividire. Perché non stiamo parlando di una Polaroid, di una macchinetta usa e getta, di qualcosa di innocuo e controllabile. Stiamo parlando di un dispositivo connesso, progettato da una delle più grandi aziende tecnologiche del pianeta, che raccoglie dati in modi che la maggior parte delle persone non comprende minimamente. E qui si apre un abisso. ## L'analfabetismo digitale degli adulti {: #analfabetismo-digitale } Perché quel genitore che ha regalato quegli occhiali al bambino probabilmente non ha la minima idea di cosa stia facendo. Non per cattiveria, non per menefreghismo, ma per una forma di analfabetismo digitale che (almeno in questo paese) riguarda più della metà della popolazione. Sono persone che usano WhatsApp senza sapere cosa sia la crittografia end-to-end, che pubblicano foto dei nipoti sui social senza pensarci due volte, che cliccano su “accetta tutti i cookie” perché quella finestra è fastidiosa e vogliono solo farla sparire. Non sono stupidi, sia chiaro. Sono semplicemente persone che la tecnologia l’hanno subita, non l’hanno mai davvero capita, e che nessuno ha mai aiutato a orientarsi in questo mondo che cambia in fretta. Il divario generazionale nel digitale è qualcosa che mi colpisce sempre di più. I miei genitori e quelli della mia età hanno vissuto una transizione epocale: siamo tutti passati dal telefono a rotella allo smartphone in meno di trent’anni, dal televideo a internet, dalla lettera spedita per posta all’email e poi ai messaggi istantanei. Alcuni di noi hanno fatto lo sforzo di capire, di adattarsi, di imparare. Ma molti altri sono rimasti indietro, travolti da un’onda che non hanno mai davvero imparato a cavalcare. E questi sono i genitori che oggi mettono nelle mani dei bambini dispositivi di cui non comprendono le implicazioni. Vedo tanti figli di amici passare svariate ore al giorno online senza alcun tipo di supervisione o limite. Tanti non hanno regole sull’uso dei social media. E non è solo una questione di tempo passato davanti a uno schermo, che già di per sé sarebbe preoccupante. È la totale assenza di accompagnamento, di guida, di educazione. È il fatto che molti adulti hanno semplicemente abdicato al loro ruolo, non perché non gliene importi, ma perché non sanno come fare. Come puoi insegnare qualcosa che non conosci? Come puoi dare regole su strumenti che non capisci? ## La tentazione del paternalismo {: #tentazione-paternalismo } Ecco, di fronte a tutto questo, mi trovo in una posizione scomoda. Perché una parte di me, quella più libertaria, quella che ha sempre creduto nella responsabilità individuale, nella libertà di scelta, nel fatto che le persone dovrebbero essere lasciate libere di fare i propri errori e imparare da essi, quella parte di me si ribella all’idea che qualcun altro debba intervenire. E tuttavia, un’altra parte di me, quella che ha visto quel bambino con gli occhiali smart entrare in casa mia come se niente fosse, inizia a capire perché alcuni legislatori europei hanno adottato un approccio così paternalistico. Quasi lo capisco, questo paternalismo. Quasi. Il Digital Services Act, il Digital Markets Act, le normative europee sulla privacy dei minori, le proposte di legge per limitare l’accesso dei bambini ai social, le discussioni sulla verifica dell’età online: tutto questo nasce da una constatazione amara, e cioè che se i genitori non sono in grado di educare, se la responsabilità individuale sembra essersi dissolta nel nulla, allora forse è necessario che qualcun altro metta dei paletti. Lo Stato, le istituzioni, le scuole. Qualcuno che faccia quello che molti adulti non stanno facendo. Ma il paternalismo porta con sé dei rischi che non posso ignorare. Quando lo Stato decide cosa è appropriato e cosa non lo è, quando impone sistemi di controllo, quando pretende di sapere meglio dei cittadini cosa sia giusto per loro, si apre la porta a derive che mi spaventano. Lo vediamo già in certi paesi, dove la protezione dei minori diventa pretesto per la censura, dove il controllo parentale si trasforma in sorveglianza di massa, dove le buone intenzioni lastricano la strada verso una società sempre meno libera. Il paradosso è evidente: nel tentativo di proteggerci dalla sorveglianza delle big tech, rischiamo di consegnarci a forme di controllo statale ancora più capillari. E quindi? Cosa facciamo? ## Responsabilità individuale e collettiva {: #responsabilita-individuale-collettiva } Forse il nodo da sciogliere è proprio questo: il rapporto tra responsabilità individuale e responsabilità collettiva. Da un lato, credo fermamente che ogni genitore dovrebbe essere responsabile delle proprie scelte educative. Dovrebbe informarsi, capire cosa sta mettendo nelle mani dei propri figli, porre limiti, spiegare, accompagnare. Dall’altro, non posso ignorare che viviamo in una società profondamente disuguale, dove le differenze culturali, economiche, educative rendono impossibile per molti accedere a quella consapevolezza che darei per scontata. È facile dire “i genitori dovrebbero educare” quando hai gli strumenti per farlo. Ma che succede quando quegli strumenti mancano? La responsabilità individuale non può esistere nel vuoto. Ha bisogno di un contesto che la renda possibile. Ha bisogno di educazione digitale nelle scuole, non come optional ma come materia fondamentale quanto la matematica o l’italiano. Ha bisogno di formazione per i genitori, di sportelli informativi, di campagne di sensibilizzazione che vadano oltre gli slogan. Ha bisogno che le aziende tecnologiche si assumano le proprie responsabilità invece di nascondersi dietro linee guida che nessuno legge e termini di servizio scritti in legalese incomprensibile. Meta, per dire, ha pubblicato delle linee guida sull’uso etico dei suoi occhiali smart. Suggerisce di non usarli per registrare persone senza consenso, di rispettare la privacy altrui, di essere trasparenti sul fatto che si sta registrando. Bellissimo. Ma quante persone hanno letto quelle linee guida? Quanti genitori che hanno regalato quegli occhiali a un figlio sanno che esistono? E soprattutto: perché dovrebbe toccare all’utente informarsi, invece che al produttore progettare dispositivi che rendano più difficile l’uso improprio? Quando vedo quel bambino con gli occhiali smart che “fa le fotoooo” a casa mia, provo una miscela di sentimenti difficile da descrivere. C’è irritazione, certo, verso adulti che non si interrogano, che non si informano, che delegano a uno strumento tecnologico il compito di intrattenere i loro figli senza chiedersi quali conseguenze questo possa avere. C’è una certa sfiducia verso la capacità della nostra società di autoregolarsi, di trovare un equilibrio senza che qualcuno debba imporlo dall’alto. E c’è, confesso, una tentazione di rassegnazione: se questi sono i genitori, se questo è il livello di consapevolezza medio, forse davvero è bene che qualcun altro intervenga. Ma non voglio arrendermi alla rassegnazione, perché il paternalismo non può essere una soluzione a lungo termine. Non possiamo costruire una società digitale sana se ci affidiamo solo alle regole imposte dall’alto. Non funziona così. Le regole vengono aggirate, i divieti generano trasgressione, e soprattutto: le leggi non possono sostituire la cultura. Quello di cui abbiamo bisogno è un cambiamento più profondo, che parte dall’educazione e arriva fino al modo in cui concepiamo il nostro rapporto con la tecnologia. ## L'educazione digitale come diritto {: #educazione-digitale-diritto } L’educazione digitale deve diventare un diritto. Non un corso opzionale, non un’ora a settimana se avanza tempo, non una slide mostrata in fretta durante un’assemblea di istituto. Deve essere parte integrante della formazione di ogni cittadino, fin dalla scuola primaria. E non deve riguardare solo i bambini: deve coinvolgere anche gli adulti, quei genitori che oggi si trovano a gestire dispositivi che non capiscono e a prendere decisioni di cui non comprendono le conseguenze. Servono programmi di formazione, risorse accessibili, supporto concreto. Non proclami e buone intenzioni. Ma c’è qualcosa di ancora più fondamentale, credo. C’è la necessità di ripensare il nostro rapporto con la tecnologia. Perché il problema di fondo non sono gli occhiali Meta, non sono gli smartphone, non sono i social network. Il problema è che abbiamo creato una società in cui la tecnologia avanza più velocemente della nostra capacità di comprenderla, metabolizzarla, governarla. Siamo tutti, in qualche misura, in ritardo rispetto agli strumenti che usiamo. E le disuguaglianze educative si traducono in disuguaglianze digitali sempre più profonde, creando una frattura tra chi sa navigare questo mondo e chi viene travolto. Penso spesso a cosa significhi crescere oggi, circondati da dispositivi che registrano, analizzano, profilano. Penso a quei bambini che imparano fin da piccoli che è normale essere ripresi, che la privacy è un concetto vago e negoziabile, che tutto può e deve essere condiviso. Mi chiedo quale idea del mondo stiano sviluppando, quale rapporto con la propria intimità, con i propri confini, con il rispetto degli altri. Mi chiedo se stiamo crescendo una generazione che non saprà nemmeno più cosa significhi avere uno spazio privato, un momento non documentato, un ricordo che esiste solo nella memoria e non in qualche server dall’altra parte del mondo. E mi chiedo, alla fine, perché abbiamo lasciato che si arrivasse a questo punto. Perché abbiamo permesso che la sorveglianza diventasse normale, che il rispetto della privacy diventasse un optional, che l’educazione digitale rimanesse una chimera. Perché non abbiamo investito di più, non abbiamo preteso di più, non abbiamo fatto di più quando ancora era tempo. Forse è ancora tempo. Forse possiamo ancora invertire la rotta. Ma richiede uno sforzo collettivo, un patto educativo che coinvolga famiglie, scuole, istituzioni e sì, anche le aziende tecnologiche. Richiede che smettiamo di considerare l’alfabetizzazione digitale come un lusso e iniziamo a trattarla come una necessità. Richiede che ognuno di noi, nel suo piccolo, faccia la propria parte: informandosi, interrogandosi, non dando nulla per scontato. Quel bambino con gli occhiali smart non ha colpe. Sta giocando, sta esplorando, sta facendo quello che fanno tutti i bambini: provare cose nuove con entusiasmo e senza inibizioni. La responsabilità è degli adulti che gli hanno messo in mano quel dispositivo senza pensarci, senza spiegargli cosa significa, senza porgli alcun limite. E la responsabilità, in senso più ampio, è di una società che non ha fatto abbastanza per preparare quei genitori, per dargli gli strumenti di cui avevano bisogno. ## Stabilire un limite {: #stabilire-un-limite } Ho chiesto di togliere quegli occhiali. L’ho fatto con fermezza, forse più fermezza di quanta ne avrei voluta usare il giorno di Natale. In casa c’erano altri bambini, figli di amici che hanno scelto consapevolmente di non pubblicare mai le loro foto online, di proteggerli da un’esposizione che non hanno chiesto e di cui non possono comprendere le conseguenze. Non potevo permettere che quella scelta venisse vanificata da un gadget nelle mani di un ragazzino inconsapevole. Non so se sono stato capito. Non so se chi mi stava di fronte ha colto davvero il senso di quella richiesta o se mi ha semplicemente catalogato come il solito paranoico, quello che esagera sempre, che vede problemi dove non ce ne sono. Ma in quel momento non mi importava. Perché c’è un limite oltre il quale la cortesia deve cedere il passo al rispetto, e quel limite era stato superato nel momento stesso in cui quegli occhiali avevano varcato la mia soglia. Resto con tante domande e poche certezze. Ma una cosa l’ho capita: se non iniziamo a porre limiti, a stabilire confini, a pretendere rispetto per la nostra privacy e quella degli altri, nessuno lo farà al posto nostro. E a volte questo significa essere disposti a sembrare scomodi, fuori posto, eccessivi. Significa accettare che qualcuno non capirà, che qualcuno si offenderà, che qualcuno penserà che stiamo esagerando. Ma significa anche proteggere qualcosa che, una volta perso, non si recupera più. --- # Mozilla, liberi dai miliardari (più o meno) - **URL:** https://margiovanni.it/it/blog/mozilla-liberi-dai-miliardari-piu/ - **Pubblicato:** 2025-12-17 - **Tag:** Browser, Indipendenza, Open Source - **Tempo di lettura:** 5 min > Stavo navigando sul sito di Firefox qualche ora fa, per controllare le release notes di un aggiornamento, quando mi... Stavo navigando sul sito di Firefox qualche ora fa, per controllare le release notes di un aggiornamento, quando mi sono imbattuto in un banner che mi ha fatto sorridere. Uno di quei sorrisi un po’ amari, tipo quando scopri che il tuo ristorante vegano preferito è di proprietà di una catena di fast food. ![](https://substackcdn.com/image/fetch/$s_!Rymv!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb1d24499-1083-4315-bfda-00f8301f76df_2402x1032.png) ## Il banner {: #il-banner } “Liberi dai miliardari da più di 20 anni”, recita il testo accanto al logo del panda rosso. E sotto: “Non siamo proprietà di nessun miliardario e continuiamo a lavorare per migliorare Internet e valorizzare il tempo che ci dedichi”. Bello. Davvero bello. Peccato che la realtà sia leggermente più sfumata. Perché vedete, Mozilla ha effettivamente una storia gloriosa. Firefox è nato come alternativa libera e open source in un’epoca in cui Internet Explorer dominava il web con il suo monopolio asfissiante. Per anni è stato il browser dei puristi, degli smanettoni, di chi credeva in un internet più aperto e rispettoso della privacy. E per certi versi lo è ancora. Ma parliamo di soldi, che alla fine sono quelli che fanno girare anche le fondazioni non profit. ## I numeri {: #i-numeri } Nel 2023 Mozilla ha incassato circa 653 milioni di dollari. Una cifra rispettabile. Di questi, circa 495 milioni (il 76%) arrivano dalle royalties per il motore di ricerca predefinito. E chi paga queste royalties? Google. Sì, proprio quella Google che appartiene ad Alphabet, il cui valore di mercato supera i 2000 miliardi di dollari. Google, fondata da Larry Page e Sergey Brin, entrambi ampiamente sopra la soglia del miliardario. La cosa bella è che non si tratta di un’anomalia recente. Dal 2005 ad oggi, con una breve parentesi Yahoo tra il 2015 e il 2017, Google ha sempre coperto tra l’80% e il 90% del budget di Mozilla. Sempre. Per vent’anni. ![](https://substackcdn.com/image/fetch/$s_!y0e1!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5a32f389-7483-4c4c-a980-7a6f65505ba1_2208x1012.png) ## Vent'anni di dipendenza {: #venti-anni-di-dipendenza } Se guardiamo l’andamento storico, la dipendenza è impressionante. Nel 2005, quando Firefox era nel pieno della sua crescita esplosiva, le royalties da Google rappresentavano già il 95% delle entrate. Nel 2012, dopo il rinnovo del contratto, si parlava di cifre molto più alte. Nel 2020, l’accordo è stato rinnovato con stime tra i 400 e 450 milioni di dollari annui. C’è un dato curioso nel 2019: i ricavi sono schizzati a 826 milioni. Ma non per meriti particolari di Mozilla. Quell’anno Verizon (che aveva acquisito Yahoo) ha dovuto pagare 338 milioni di dollari di risarcimento per aver rotto anticipatamente il contratto di partnership. Insomma, anche quando Mozilla non dipendeva da Google, il suo bilancio finiva per dipendere da un altro colosso tech. ## L'alibi antitrust {: #alibi-antitrust } E la cosa più interessante? Nonostante la quota di mercato di Firefox sia in costante declino da anni, i ricavi sono rimasti stabili o addirittura cresciuti. Perché? Perché per Google, anche un numero ridotto di utenti Firefox che usano il suo motore di ricerca vale l’investimento. È un modo elegante per evitare accuse di monopolio. Poter dire “guardate, esiste un’alternativa e la supportiamo finanziariamente” fa comodo quando hai l’antitrust che ti guarda storto. Non sto dicendo che Mozilla sia malvagia o ipocrita. Non è così semplice. Mozilla fa un lavoro importante: sviluppa un browser che rispetta la privacy degli utenti più di Chrome, contribuisce a standard web aperti, finanzia progetti interessanti nel campo della sicurezza e dell’intelligenza artificiale etica. Ma quel banner. Quel banner mi fa un po’ ridere. “Liberi dai miliardari” mentre il tuo stipendio arriva grazie a un contratto multimilionario con una delle aziende più ricche del pianeta. È un po’ come se un inquilino che paga l’affitto a un magnate immobiliare si vantasse di non avere nulla a che fare con i ricchi. La differenza tra essere di proprietà di un miliardario e dipendere finanziariamente da un miliardario è sottile, certo. Tecnicamente vera. Ma anche un po’ disonesta intellettualmente. Il vero problema non è nemmeno il marketing creativo. Il vero problema è la fragilità di un modello di business costruito su un singolo cliente. Cosa succede se Google decide di non rinnovare il contratto? Cosa succede se le autorità antitrust intervengono su questi accordi? Cosa succede se Chrome diventa così dominante che supportare Firefox non serve più come alibi? Mozilla lo sa, ovviamente. Negli ultimi anni ha provato a diversificare: VPN, servizi premium, investimenti. Ma i numeri parlano chiaro: la dipendenza da Google non è mai stata davvero scalfita. E forse è proprio questo il punto. Forse il banner dovrebbe dire qualcosa tipo: “Liberi dai miliardari, ma finanziati da loro. È complicato.” Sarebbe meno accattivante, certo. Ma almeno sarebbe onesto. ## Liberi dai miliardari, non dai loro soldi {: #non-dai-loro-soldi } In fondo, la relazione tra Mozilla e Google è una delle più lunghe e stabili del tech. Vent’anni di matrimonio finanziario, con una breve scappatella con Yahoo che si è conclusa con un assegno di risarcimento. C’è qualcosa di quasi romantico, in un modo un po’ cinico. Google paga Mozilla per esistere. Mozilla esiste grazie a Google. E nel frattempo, entrambi possono raccontare storie diverse: Google quella dell’azienda che supporta la competizione, Mozilla quella dell’organizzazione indipendente che lotta per un web migliore. Forse non è ipocrisia. Forse è semplicemente come funziona il mondo del tech nel 2025. Anche le alternative hanno bisogno di sponsor. Anche i ribelli hanno bisogno di finanziamenti. E a volte i finanziamenti arrivano proprio da chi dovresti combattere. Non so se questo renda Mozilla meno valida come alternativa a Chrome. Probabilmente no, in termini pratici. Firefox resta un ottimo browser, con feature di privacy superiori e un’etica di sviluppo che rispetto. Ma ogni volta che vedo quel banner, non posso fare a meno di sorridere. Con un po’ di amarezza, sì. Ma anche con la consapevolezza che la purezza ideologica, nel tech come altrove, è spesso più complicata di quanto i banner pubblicitari vorrebbero farci credere. Almeno sono onesti su una cosa: sono effettivamente liberi dai miliardari da più di vent’anni. Semplicemente, non sono liberi dai loro soldi. --- # Aaron Swartz, il ragazzo che sognava un web libero - **URL:** https://margiovanni.it/it/blog/aaron-swartz-il-ragazzo-che-sognava/ - **Pubblicato:** 2025-12-17 - **Tag:** Activism, Open Source, Web-libero - **Tempo di lettura:** 6 min > L’8 Novembre sarebbe stato il compleanno di Aaron Swartz. Era nato nel 1986, e se ne è andato troppo presto, l’11... ![](https://substackcdn.com/image/fetch/$s_!fuCf!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc373cd8a-93f0-4f57-8f06-13ddab489cd9_3888x2592.jpeg) L’8 Novembre sarebbe stato il compleanno di Aaron Swartz. Era nato nel 1986, e se ne è andato troppo presto, l’11 gennaio 2013. Ogni volta che torno a pensare a lui, sento quella sensazione di vuoto che lasciano le perdite ingiuste, quelle che arrivano quando una mente brillante viene schiacciata da un mondo che non è riuscito a comprenderla. Aaron era fragile e tenace allo stesso tempo. Forse è proprio questa combinazione a renderlo così umano. ## Il genio adolescente che ha cambiato il web {: #il-genio-adolescente-che-ha-cambiato-il-web } Aveva solo pochi anni alle spalle quando iniziò a cambiare il modo in cui il web funzionava. A quattordici anni partecipò alla creazione del formato RSS, quella tecnologia che ancora oggi alimenta i feed dei blog e delle notizie. Non era solo un programmatore precoce: era qualcuno che capiva il potenziale trasformativo della tecnologia. Contribuì alla nascita delle licenze Creative Commons, quel sistema che permette a creatori di tutto il mondo di condividere il proprio lavoro senza rinunciare ai propri diritti. Fu tra i co-fondatori di Reddit, che negli anni sarebbe diventata una delle community più influenti di internet. Ma non si fermò alla tecnologia: fondò Open Library per rendere accessibili i libri a tutti, digitalizando migliaia di volumi per creare una biblioteca universale e gratuita. E poi scrisse il **Manifesto per l’accesso libero alla conoscenza** , un testo che oggi sembra quasi una dichiarazione d’amore alla libertà stessa. In quel manifesto, Aaron scriveva parole che risuonano ancora più forti oggi: > “L’informazione è potere. Ma come ogni potere, ci sono quelli che vogliono tenerlo per sé. L’intero patrimonio scientifico e culturale, pubblicato nel corso dei secoli in libri e riviste, viene sempre più digitalizzato e chiuso a chiave da una manciata di corporation private.” ## La conoscenza come atto politico {: #la-conoscenza-come-atto-politico } Al centro di tutto il suo pensiero c’erano la trasparenza e la condivisione. Aaron credeva che sapere fosse un atto politico, un diritto, una forma di emancipazione. Non era ingenuo: sapeva che la conoscenza concentrata nelle mani di pochi è uno strumento di potere e controllo. Per questo lottava per renderla accessibile a tutti. Diceva che lasciare un segno significa rompere le regole, provare a cambiare il sistema facendo ciò che gli altri non hanno il coraggio di fare. Una frase semplice, ma che col tempo ha assunto un peso immenso. Perché Aaron non parlava per slogan: agiva. E le sue azioni avevano conseguenze. Nel 2008 caricò e rese disponibili gratuitamente circa 2,7 milioni di documenti di atti giudiziari federali dal database PACER, un sistema che faceva pagare 8 centesimi a pagina per l’accesso a documenti pubblici. La sua logica era semplice: se sono documenti pubblici, perché devo pagare per leggerli? Non venne perseguito per questo gesto, ma iniziò ad essere monitorato. ## La persecuzione {: #la-persecuzione } Poi arrivò la parte più buia della sua storia. Nel 2011 venne accusato di aver scaricato milioni di articoli scientifici da JSTOR, un archivio accademico a pagamento. Lo fece dal MIT, usando una connessione alla rete universitaria. Il suo obiettivo, presumibilmente, era rendere disponibile al pubblico ricerca scientifica finanziata con fondi pubblici ma bloccata dietro paywall proibitivi. Le accuse federali furono devastanti: **tredici capi d’imputazione** , con pene che arrivavano fino a 35 anni di carcere e un milione di dollari di multa. Tredici capi d’accusa per aver scaricato articoli accademici. JSTOR stessa decise di non perseguirlo, ma il governo federale andò avanti comunque. Era una persecuzione più che un processo. Il procuratore federale Carmen Ortiz voleva farne un esempio, trasformarlo nel simbolo della lotta contro il “crimine informatico”. Ma Aaron non era un criminale: era un attivista, un idealista, qualcuno che credeva che la conoscenza dovesse essere libera. La pressione divenne insopportabile. Aaron soffriva di depressione, e il peso delle accuse, la prospettiva di anni in carcere, la gogna mediatica, furono troppo. Mi chiedo spesso se fosse davvero inevitabile, se la legge, quella stessa legge che dovrebbe proteggere, possa a volte trasformarsi in un’arma contro chi cerca la verità. L’11 gennaio 2013, Aaron Swartz si tolse la vita. Aveva 26 anni. ## Un’eredità che continua a germogliare {: #uneredita-che-continua-a-germogliare } L’altroieri, nel giorno in cui sarebbe dovuto essere il suo compleanno, la sua eredità è più viva che mai. Vive nei movimenti per l’open access, in chi lotta perché la ricerca scientifica finanziata con soldi pubblici sia accessibile a tutti. Vive in progetti come Sci-Hub, che Alexandra Elbakyan ha creato proprio ispirandosi agli ideali di Aaron. Vive nei progetti di trasparenza digitale, in chi lavora per un web davvero libero, civile, giusto. Vive in chi programma non solo per creare, ma per restituire qualcosa al mondo. Vive in ogni sviluppatore che sceglie una licenza open source, in ogni ricercatore che pubblica su archivi aperti, in ogni attivista che crede che l’informazione debba essere un diritto, non un privilegio. È come se Aaron avesse piantato un seme che continua a germogliare, ogni volta che qualcuno decide di condividere un sapere invece di custodirlo. Ogni volta che qualcuno sceglie la trasparenza invece del segreto. Ogni volta che qualcuno si oppone a sistemi ingiusti che trasformano la conoscenza in merce. ## Il modo migliore per ricordarlo {: #il-modo-migliore-per-ricordarlo } Dopo la sua morte, ci furono reazioni forti. Tim Berners-Lee, l’inventore del World Wide Web, twittò: “Aaron è morto. I criminali sono quelli che hanno chiuso la conoscenza e lo hanno perseguitato. Svegliamoci.” Lawrence Lessig, co-fondatore di Creative Commons e mentore di Aaron, scrisse: “Abbiamo perso un amico. Abbiamo perso un combattente. L’America ha perso una figura straordinaria.” E il fondatore di Reddit Steve Huffman disse: “Aaron non era solo un hacker geniale e attivista politico. Era anche il mio amico.” Ma forse il modo migliore per ricordarlo è proprio questo: **fare ciò che gli altri non cercano di fare**. Sfidare la paura, la burocrazia, l’indifferenza. Continuare il suo lavoro, ognuno a modo proprio, con lo stesso coraggio di chi crede che libertà e conoscenza non siano mai un privilegio, ma un diritto. Puoi farlo nel tuo piccolo: * **Usa e supporta progetti open source**. Contribuisci quando puoi, anche solo con documentazione o segnalazione di bug. * **Condividi la conoscenza**. Se hai competenze, insegnale. Se hai accesso a risorse, rendile disponibili. * **Scegli licenze aperte** per il tuo lavoro, quando possibile. Creative Commons per contenuti, MIT o GPL per codice. * **Supporta l’open access**. Se sei un ricercatore, pubblica su archivi aperti. Se sei uno studente, usa e promuovi alternative libere. * **Lotta contro i paywall ingiusti**. Firma petizioni, sostieni organizzazioni che lavorano per l’accesso libero alla conoscenza. ## “Guerrilla Open Access Manifesto” {: #guerrilla-open-access-manifesto } Vorrei chiudere con le parole di Aaron stesso, dal suo manifesto del 2008: > “Non c’è giustizia nel seguire leggi ingiuste. È tempo di venire alla luce e, nella grande tradizione della disobbedienza civile, dichiarare la nostra opposizione a questo furto privato della cultura pubblica. Dobbiamo prendere l’informazione, ovunque sia conservata, fare copie e condividerla con il mondo. Dobbiamo prendere le cose fuori copyright e aggiungerle all’archivio. Dobbiamo comprare database segreti e metterli sul web. Dobbiamo scaricare riviste scientifiche e caricarle su reti di file sharing. Dobbiamo combattere per il Guerrilla Open Access.” Parole forti, radicali, scomode. Ma necessarie. Perché Aaron ci ha insegnato che il cambiamento non arriva aspettando che qualcuno lo conceda dall’alto. Arriva quando persone coraggiose decidono di agire, nonostante i rischi, nonostante le conseguenze. Oggi Aaron avrebbe 39 anni. Chissà cosa avrebbe creato, cosa avrebbe cambiato, quali battaglie avrebbe combattuto nell’era dell’IA, dei social media, delle fake news. Ma anche se non è più qui, il suo spirito continua a vivere in ogni gesto di condivisione, in ogni atto di ribellione pacifica contro sistemi che vogliono privatizzare la conoscenza. Buon compleanno, Aaron. Il tuo sogno di un web libero è ancora vivo. E continueremo a combattere per renderlo reale. --- # La grande illusione della conciliazione nel tech - **URL:** https://margiovanni.it/it/blog/la-grande-illusione-della-conciliazione/ - **Pubblicato:** 2025-12-17 - **Tag:** Lavoro, Tech, Work-life-balance - **Tempo di lettura:** 12 min > Ho passato gli ultimi giorni a pensare a una conversazione che ho sentito per caso durante un aperitivo di networking.... Ho passato gli ultimi giorni a pensare a una conversazione che ho sentito per caso durante un aperitivo di networking. Due donne, entrambe sulla quarantina, entrambe nel settore tech, parlavano dei loro percorsi di carriera. Una aveva appena ricevuto una promozione importante, l’altra stava valutando di tornare al lavoro dopo la maternità. La prima era single senza figli. La seconda aveva due bambini piccoli. E mentre le ascoltavo, mi sono accorto di quanto fosse diverso il tono delle loro voci quando parlavano del futuro. ![](https://substackcdn.com/image/fetch/$s_!WVko!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7bcf136-42af-4566-8314-0aa4323529c9_640x427.jpeg) Non è una storia nuova, probabilmente. Eppure continua a sembrarmi assurda, quasi surreale, in un settore che non fa altro che parlare di [inclusività e diversità](), di work-life balance, di politiche family-friendly. Ogni azienda tech ha la sua pagina dedicata alla diversità, ogni CEO pronuncia discorsi ispiratori sull’importanza del benessere dei dipendenti, ogni report aziendale celebra iniziative volte a supportare i genitori che lavorano. Ma poi, quando guardi davvero chi arriva ai vertici, chi ottiene le promozioni più significative, chi viene considerato materiale da leadership, emerge un pattern che contraddice tutto questo storytelling patinato. ## Il paradosso che nessuno vuole ammettere {: #il-paradosso-che-nessuno-vuole-ammettere } Le cifre parlano da sole, anche se preferiremmo non ascoltarle. [Il cinquanta percento delle donne lascia il settore tecnologico entro i trentacinque anni](). Non è casuale che questa età coincida con gli anni in cui molte persone decidono di avere figli. Quasi il quaranta percento delle donne che abbandonano il tech cita le responsabilità di cura come fattore determinante. E per quelle che restano? [Due terzi delle madri che lavorano nel settore riportano che la loro carriera ha subito uno stallo dopo la genitorialità](). Mi chiedo spesso cosa pensino i responsabili delle risorse umane quando preparano quelle splendide presentazioni sui congedi parentali e sulle politiche di flessibilità. Forse ci credono davvero, forse pensano che offrire più settimane di congedo parentale faccia davvero la differenza. E in un certo senso la fa, non fraintendimi. Ma è come mettere un cerotto su una frattura esposta. Il problema non è solo nei benefit, per quanto importanti. Il problema è in quella [cultura non scritta, invisibile eppure onnipresente](), che continua a premiare chi può permettersi di essere sempre disponibile. Quella cultura che Google stesso incarnava fino a poco tempo fa, quando il co-fondatore Sergey Brin raccomandava ai dipendenti che lavorano su Gemini di fare sessanta ore a settimana e presentarsi in ufficio “almeno ogni giorno feriale”. Quella cultura che Meta ha abbracciato quando il CEO Mark Zuckerberg ha parlato di un mondo aziendale “culturalmente castrato” che si era allontanato dalla “energia maschile”. ## L’equazione impossibile della disponibilità totale {: #lequazione-impossibile-della-disponibilita-totale } Nel 2025 lavoriamo ancora con un’idea di “lavoratore ideale” che risale a decenni fa, qualcuno sempre presente, sempre raggiungibile, pronto a sacrificare tutto per il lavoro. Qualcuno che, francamente, o non ha famiglia o ha qualcun altro che se ne occupa completamente. [Le ricerche lo confermano](): in ambienti ad alta intensità come il tech, le persone che “accettano” questa cultura del sempre disponibile spesso falliscono nel coltivare interessi esterni e sono lente a riprendersi dai contraccolpi professionali. Ho visto con i miei occhi in passato cosa significa questa aspettativa. Colleghi che rispondono alle email alle undici di sera, non perché ci sia un’emergenza reale, ma perché sanno che qualcuno lo noterà, qualcuno farà il confronto con chi invece ha spento il computer alle sei per andare a prendere i figli all’asilo. E non è paranoia. [Uno studio su Slack ha rivelato]() che chi si sente obbligato a lavorare oltre l’orario riporta una produttività inferiore del venti percento e livelli di stress più che raddoppiati rispetto a chi mantiene orari normali. Eppure questa cultura persiste, anzi si intensifica. Dopo la pandemia, [molte aziende tech hanno invertito la rotta sul lavoro remoto](), non per ragioni di produttività (gli studi dimostrano che le persone lavorano altrettanto bene da casa) ma per ragioni di controllo. Amazon ha imposto il rientro in ufficio cinque giorni a settimana. Meta ha tagliato quattromila dipendenti considerati poco performanti. Microsoft ha rivisto il suo sistema di valutazione per eliminare più rapidamente chi non performa. È interessante notare come [i tech bros più giovani](), quelli che fondano startup e parlano di voler avere quattro figli, lavorino più di ottanta ore a settimana e ammettano candidamente di non avere tempo per frequentare nemmeno un bar. “Probabilmente parlo con i modelli di linguaggio dieci volte più di quanto parli con le persone”, ha scherzato un fondatore ventunenne. Non è divertente, è tragico. E rivela quanto profondamente radicata sia l’aspettativa che il successo richieda il sacrificio di tutto il resto. Piccola digressione su una cosa di cui sono orgoglioso. Il mio CEO qualche tempo fa mi disse: > “Chi non coltiva una vita genitoriale e sociale ricca non può che essere piccolo anche nel lavoro”. ## La penalità invisibile della genitorialità {: #la-penalita-invisibile-della-genitorialita } C’è una frase che ricorre negli studi sulla carriera delle donne in ambito STEM: [“specter of motherhood”](), lo spettro della maternità. Non serve nemmeno diventare madre per subire le conseguenze di questa cultura ostile. Basta che le tue colleghe e i tuoi capi pensino che potresti diventarlo. Dottorande e ricercatrici post-doc hanno raccontato di essere state esplicitamente avvertite dai loro mentori che avrebbero dovuto scegliere tra carriera accademica e famiglia. Alcune hanno nascosto aborti spontanei gravi o hanno dichiarato pubblicamente di non voler avere figli, nel tentativo disperato di essere prese sul serio. E quando poi i figli arrivano davvero? [Le madri in ambito STEM producono in media diciassette pubblicazioni in meno rispetto ai padri]() nei dieci anni successivi alla nascita del primo figlio: un gap che richiederebbe circa cinque anni di lavoro per essere colmato. Non è una questione di capacità o impegno. È una questione di tempo disponibile per la ricerca, tempo che per le madri viene sistematicamente eroso mentre i padri riescono a proteggerlo. Il settanta per cento delle madri che lavorano nel tech ritiene che la propria carriera stia soffrendo a causa delle responsabilità di cura e familiari. Non è una percezione soggettiva. È [una realtà documentata da innumerevoli ricerche](). Le madri hanno una probabilità settantanove percento inferiore di essere assunte, metà delle probabilità di essere promosse e guadagnano significativamente meno rispetto a donne con curriculum comparabili ma senza figli. ## L’altra faccia della medaglia {: #laltra-faccia-della-medaglia } Ma forse la cosa più insidiosa di questa cultura è come crea tensioni anche tra colleghi. Durante la pandemia, quando molte aziende tech hanno offerto congedi aggiuntivi ai genitori per gestire la chiusura di scuole e asili, [è esplosa una vera e propria rivolta tra i dipendenti senza figli](). Su Facebook i dipendenti hanno fatto notare ripetutamente durante le riunioni aziendali che le politiche COVID “hanno favorito prevalentemente i genitori”. Su Twitter è scoppiato un dibattito intenso quando un dipendente senza figli ha criticato un collega in congedo per prendersi cura di un bambino, sostenendo che non stesse facendo la sua parte. E capisci il loro punto. Davvero. [Il sessantatré percento dei lavoratori senza figli]() riferisce di essersi visto negare permessi, il sessantanove percento di aver dovuto fare straordinari e il settanta percento di aver ricevuto un carico di lavoro maggiore. Quasi la metà crede che i dipendenti con figli abbiano più probabilità di essere promossi. Il problema è che questa non è una guerra tra genitori e non-genitori. È una guerra orchestrata da sistemi che richiedono a tutti di dare troppo, e poi ci mettono gli uni contro gli altri per nascondere il vero problema. [Le aziende che offrono benefit straordinari ai genitori]() ma poi si aspettano che i colleghi senza figli coprano il loro lavoro non stanno aiutando nessuno. Stanno semplicemente spostando il problema. ## Il mito della meritocrazia tech {: #il-mito-della-meritocrazia-tech } Forse la parte più frustrante di tutto questo è l’ipocrisia. Il settore tech ama presentarsi come meritocratico, un luogo dove conta solo il talento e le idee migliori vincono. Ma come può essere meritocratico un sistema dove avere una famiglia (o anche solo l’intenzione di averne una) diventa automaticamente un handicap professionale? Tobi Lütke, CEO di Shopify, prima della pandemia scriveva con orgoglio che il suo lavoro era “incredibile, ma è anche solo un lavoro. Famiglia e salute personale vengono prima nella mia lista di priorità”. Quest’anno ha cambiato drasticamente tono: “Sono a casa per cena ma lavoro almeno dieci ore al giorno e molto durante il weekend”. Il messaggio è chiaro: quell’equilibrio di cui parlava prima era un lusso che non possiamo più permetterci. E quando i leader cambiano tono, l’effetto a cascata è immediato. I dipendenti Microsoft descrivono [il cambiamento culturale verso “aspettative di performance più ferme”](). I lavoratori di startup riferiscono che siamo nell’era del “shut up and grind”, stai zitto e macina. [Il CEO di Palantir ha detto esplicitamente alla Gen Z]()che a vent’anni non puoi avere sia una vita sociale che successo professionale. Non è un caso che [le aziende tech più piccole](), quelle sotto i cinquecento dipendenti, offrano l’ottantotto percento delle volte piena flessibilità su dove lavorare, mentre i giganti tech con oltre venticinquemila dipendenti abbiano quasi tutti adottato modelli “ibridi strutturati” con requisiti specifici di presenza in ufficio. Le startup innovative hanno capito che la flessibilità funziona. Le grandi aziende sembrano più interessate al controllo. ## I padri e la penalità della presenza {: #i-padri-e-la-penalita-della-presenza } C’è però un altro lato della medaglia che raramente viene discusso con la dovuta attenzione: cosa succede agli uomini che decidono di essere genitori presenti? Quelli che non si accontentano del ruolo tradizionale di “breadwinner” che passa in ufficio dodici ore al giorno mentre qualcun altro cresce i figli, ma vogliono davvero essere parte attiva della vita familiare? La risposta è complessa e, per certi versi, ancora più insidiosa della penalità che colpisce le madri. Perché se per una donna avere figli è quasi automaticamente percepito come un handicap professionale, per un uomo che sceglie di prendere un congedo parentale prolungato o di chiedere flessibilità oraria la stigmatizzazione può essere ancora più forte. [Studi recenti dimostrano]() che i padri che utilizzano appieno i congedi parentali disponibili vengono spesso percepiti come meno ambiziosi, meno committed al lavoro, meno “leadership material”. È un doppio standard perverso: mentre alle donne viene rimproverato di essere madri, agli uomini viene rimproverato di volerlo essere davvero. Come se la paternità dovesse rimanere confinata alle ore serali e ai weekend, senza mai interferire con la disponibilità totale richiesta dal tech. Un padre che lascia l’ufficio alle sei per andare a prendere i figli all’asilo viene guardato con lo stesso sospetto di una madre che fa lo stesso, ma con un carico aggiuntivo di giudizio: “Non è abbastanza ambizioso”, “Non ha fame di successo”, “Ha perso la grinta”. E quando un uomo sceglie di ridurre le ore lavorative o di rifiutare una promozione che richiederebbe ancora più tempo in ufficio per dedicarsi alla famiglia, il costo in termini di carriera può essere devastante. [La ricerca mostra]() che mentre le madri subiscono una penalità di carriera indipendentemente da quanto tempo dedicano effettivamente ai figli, i padri la subiscono solo quando diventano visibilmente coinvolti nella cura quotidiana. In altre parole: un padre può avere figli senza conseguenze professionali, finché qualcun altro se ne occupa a tempo pieno. Il risultato è una cultura che perpetua dinamiche di genere profondamente antiquate. Le aziende tech possono celebrare quanto vogliono la parità di genere e offrire congedi parentali generosi sulla carta, ma se poi un uomo che li utilizza viene penalizzato nelle valutazioni di performance, nelle promozioni, nelle opportunità di crescita, il messaggio implicito è chiaro: la cura dei figli rimane un lavoro femminile. Questo danneggia tutti. Danneggia le donne, che continuano a portare il carico sproporzionato della cura familiare perché “tanto il suo lavoro è più importante”. Danneggia gli uomini, che vengono privati della possibilità di essere padri presenti senza sacrificare la carriera. E danneggia i bambini, che crescono in un mondo dove la presenza genitorale è ancora considerata un lusso incompatibile con il successo professionale. ## Cosa resta, alla fine {: #cosa-resta-alla-fine } Mentre scrivo questo, penso ancora a quelle due donne all’aperitivo. Mi chiedo cosa farà quella che sta valutando il rientro al lavoro dopo la maternità. Tornerà in un ambiente che statisticamente la penalizzerà per aver fatto una scelta di vita perfettamente normale? Accetterà di essere considerata meno ambiziosa, meno disponibile, meno “leader material” solo perché ha responsabilità al di fuori dell’ufficio? O forse troverà un’azienda diversa, una di quelle rare realtà che hanno davvero interiorizzato il valore della diversità e dell’inclusione, non solo come slogan da mettere sul sito web ma come pratica quotidiana. Esistono, queste aziende. Ci sono leader che modellano l’equilibrio che vogliono vedere nel loro team, che premiano i risultati invece delle ore lavorate, che capiscono che una persona con una vita ricca fuori dal lavoro spesso è più creativa, più resiliente, più capace di vedere prospettive diverse. Ma sono ancora troppo poche. E nel frattempo, troppi talenti vengono persi, troppa potenziale innovazione viene sprecata, troppa sofferenza viene accettata come inevitabile. Il tech continua a parlare di disruption, di cambiare il mondo, di costruire il futuro. Forse dovrebbe iniziare col cambiare se stesso, col costruire un futuro dove non devi scegliere tra avere una famiglia e avere una carriera. Dove la tua disponibilità alle undici di sera non diventa il metro della tua dedizione. Dove puoi essere presente per i tuoi figli senza essere invisibile per i tuoi capi. Non so se ci arriveremo presto. Ma continuo a sperare che un giorno, quando due persone si incontreranno a un aperitivo per parlare delle loro carriere, il fatto di avere o non avere figli sarà irrilevante quanto il fatto di preferire il tè al caffè. Una caratteristica personale, non un fattore determinante per il successo professionale. Forse è ingenuo pensarlo. Ma se c’è un settore che dovrebbe essere capace di immaginare e costruire futuri diversi, dovrebbe essere proprio questo. --- # L'upskilling nell'era dell'AI: necessario, ma non sufficiente - **URL:** https://margiovanni.it/it/blog/lupskilling-nellera-dellai-necessario/ - **Pubblicato:** 2025-12-17 - **Tag:** Formazione, Intelligenza Artificiale, Lavoro - **Tempo di lettura:** 9 min > Mi capita spesso di parlare con responsabili delle risorse umane che mi spiegano le loro esigenze su programmi di... ![](https://substackcdn.com/image/fetch/$s_!sFrh!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F708762c8-657f-4313-ad9f-45194f7de151_1280x853.jpeg) Mi capita spesso di parlare con responsabili delle risorse umane che mi spiegano le loro esigenze su programmi di formazione sull’intelligenza artificiale. Corsi su ChatGPT, workshop sui prompt, sessioni su come usare gli strumenti di AI generativa. E io mi trovo sempre un po’ combattuto, perché da un lato penso che sia assolutamente giusto e necessario, dall’altro ho la sensazione che stiano guardando solo una piccola parte di un quadro molto più grande. L’upskilling - l’aggiornamento mirato delle competenze - è fondamentale. Questo va detto chiaramente. [Il World Economic Forum stima che il 44% dei lavoratori dovrà acquisire nuove competenze entro il 2027](). Non si tratta di una possibilità remota, ma di una necessità concreta. Chi non si forma oggi rischia di trovarsi con un bagaglio di conoscenze obsolete domani. Ma quello che mi preoccupa è quando ci fermiamo lì. Quando pensiamo che basti insegnare alle persone a usare gli strumenti di AI e il gioco è fatto. Perché in quel caso stiamo risolvendo solo la parte superficiale del problema, quella più visibile e immediata, mentre sotto c’è un terremoto strutturale che richiede un ripensamento molto più profondo. ## La formazione che serve davvero {: #la-formazione-che-serve-davvero } Non tutte le forme di upskilling sono uguali. C’è una differenza enorme tra insegnare a qualcuno a usare uno strumento specifico e aiutarlo a sviluppare una comprensione profonda di come l’intelligenza artificiale sta trasformando il suo ambito professionale. Il primo tipo di formazione - quella tecnica, operativa - è importante ma ha un problema intrinseco: invecchia rapidamente. I tool cambiano, le interfacce si evolvono, quello che oggi è all’avanguardia tra sei mesi potrebbe essere superato. È comunque necessario farla, perché le persone hanno bisogno di confidenza con gli strumenti che useranno quotidianamente. Ma se ci fermiamo qui, stiamo costruendo su fondamenta fragili. Il secondo tipo di formazione - quella strategica, critica - è molto più duratura. Parliamo di sviluppare la capacità di capire quando usare l’AI e quando no, di interpretare criticamente i risultati che produce, di identificare i bias nascosti negli output, di integrare l’intelligenza artificiale nel proprio flusso di lavoro in modo creativo. Queste sono [competenze che non diventano obsolete con il prossimo aggiornamento del software](). E poi ci sono le soft skills, quelle competenze trasversali che stanno diventando paradossalmente sempre più importanti proprio mentre la tecnologia avanza. Pensiero critico, creatività, intelligenza emotiva, capacità di collaborare, di comunicare idee complesse. [McKinsey ha identificato ben 56 soft skills essenziali per il futuro del lavoro](). Non è un caso: sono esattamente le aree dove gli esseri umani mantengono un vantaggio netto sulle macchine. ## Il problema sistemico che l’upskilling non risolve {: #il-problema-sistemico-che-lupskilling-non-risolve } Ma anche quando la formazione è fatta bene - mirata, strategica, che bilancia hard e soft skills - resta un limite fondamentale: l’upskilling lavora sui singoli, mentre il problema è sistemico. Ho visto diverse organizzazioni investire risorse significative in programmi di formazione eccellenti, per poi ritrovarsi con persone competenti che tornano a lavorare esattamente come prima. Perché? Perché i processi aziendali non sono cambiati. **Le strutture gerarchiche sono le stesse. I sistemi di valutazione premiano ancora le stesse metriche di sempre**. È un po’ come insegnare a qualcuno a guidare una macchina elettrica all’avanguardia e poi rimandarla a percorrere strade sterrate progettate per le carrozze a cavalli. La competenza c’è, ma il contesto non permette di esprimerla. [Il MIT ha pubblicato dati che dovrebbero farci riflettere: il 95% dei progetti aziendali di AI generativa fallisce](). E **il problema raramente è la tecnologia o la mancanza di competenze tecniche**. Il problema è che stiamo cercando di infilare l’intelligenza artificiale dentro strutture organizzative pensate per un’altra era. ## Accompagnare l’upskilling con la trasformazione profonda {: #accompagnare-lupskilling-con-la-trasformazione-profonda } Quello che serve davvero è un approccio a due livelli. Da un lato, sì, formazione continua e mirata. Dall’altro - e questo è il pezzo che manca quasi sempre - una riprogettazione radicale di come lavoriamo. Non basta insegnare alle persone a usare l’AI. **Bisogna ripensare completamente i loro ruoli** chiedendosi: quali attività possono essere delegate all’intelligenza artificiale? Quali richiedono intuizione umana, creatività, giudizio etico, capacità relazionale? E soprattutto: come liberiamo le persone dai compiti che l’AI fa meglio di loro, per concentrarle su quello che solo gli esseri umani sanno fare? Prendiamo l’esempio di un analista che partecipa a un ottimo corso di upskilling sull’AI per l’analisi dati. Torna in ufficio con nuove competenze. Ma se il suo ruolo resta definito esattamente come prima - stesso carico di lavoro, stesse scadenze, stesse aspettative - cosa cambierà davvero? Immaginiamo invece che [l’organizzazione ripensi completamente il ruolo](): l’AI si occupa di processare dati, identificare pattern, generare report preliminari; l’analista umano si concentra su interpretare quei pattern nel contesto specifico dell’organizzazione, fare domande che la macchina non sa fare, collegare informazioni apparentemente slegate, prendere decisioni che richiedono comprensione profonda del business. Questa non è solo formazione. È ridefinizione del lavoro stesso. ## Creare spazi per la creatività umana {: #creare-spazi-per-la-creativita-umana } E qui arriviamo a quello che per me è il punto centrale. Tutta questa trasformazione - l’upskilling, la riprogettazione dei processi, l’integrazione dell’AI - dovrebbe avere un obiettivo finale: liberare il potenziale creativo delle persone. Oggi la maggior parte dei lavoratori passa le giornate sommersa da compiti operativi, riunioni inutili, email senza fine, report che nessuno leggerà. [Solo il 29% sente di essere incoraggiato a pensare in modo creativo o a trovare nuovi modi di fare le cose](). Il resto? Esegue, risponde, gestisce l’urgente senza mai avere il tempo per l’importante. L’intelligenza artificiale potrebbe - e uso il condizionale con attenzione - essere l’opportunità per cambiare questa situazione. Ma solo se accompagniamo la formazione tecnica con una trasformazione culturale profonda. Solo se decidiamo consapevolmente di usare l’automazione non per fare le stesse cose con meno persone, ma per fare cose diverse e migliori con persone più libere di pensare. Questo significa creare spazi - spazi fisici, temporali, mentali - dove la creatività possa effettivamente emergere. Significa cambiare i sistemi di valutazione per premiare l’innovazione, non solo l’esecuzione. Significa dare alle persone il permesso di sperimentare, di sbagliare, di esplorare senza una destinazione prefissata. ## Riprogettare i processi, non rattopparli {: #riprogettare-i-processi-non-rattopparli } La verità è che la formazione da sola, per quanto eccellente, non può compensare processi inefficienti. È come mettere un motore elettrico su una carrozza a cavalli e aspettarsi che diventi un’auto moderna. **Serve il coraggio di fare Business Process Reengineering vero**. Non aggiustamenti marginali, ma riprogettazione radicale. E oggi abbiamo strumenti - [l’AI stessa]() \- che possono analizzare processi, identificare inefficienze, suggerire ridisegni, adattarsi in tempo reale. > Ma questo richiede di mettere in discussione gerarchie consolidate, ruoli tradizionali, modi di lavorare che esistono da decenni. Richiede di accettare che forse quella mansione che occupava tre persone a tempo pieno può essere gestita da un sistema intelligente, e quelle tre persone possono fare qualcosa di molto più interessante e prezioso per l’organizzazione. Alcune aziende stanno già percorrendo questa strada. [Hanno creato team ibridi dove umani e AI collaborano davvero](), non come utente e strumento ma come partner con competenze complementari. Hanno ridisegnato interi flussi di lavoro partendo da zero, chiedendosi: se dovessimo costruire questo processo oggi, sapendo cosa può fare l’AI, come lo faremmo? ## Il rischio della superficialità {: #il-rischio-della-superficialita } C’è un rischio enorme che mi preoccupa quando parlo di questi temi. Il rischio è trattare l’upskilling come la soluzione totale, come se bastasse organizzare qualche corso e il problema fosse risolto. Ho visto troppe aziende lanciare iniziative AI con grande fanfara, organizzare workshop di due giorni sulla formazione digitale, comprare licenze di strumenti costosi... e poi sei mesi dopo tutto è tornato come prima. Le persone continuano a lavorare esattamente come lavoravano, magari con qualche tool in più che non usano davvero, perché nessuno ha ripensato i processi, nessuno ha dato loro il permesso di lavorare diversamente, nessuno ha tolto dalla loro scrivania le attività inutili che li sommergono. Questa è la differenza tra fare un progetto di formazione e fare una trasformazione sistemica. Il primo ha un inizio e una fine, produce un attestato, si misura in ore di corso. [La seconda è continua, tocca la cultura organizzativa](), cambia il modo in cui le decisioni vengono prese, richiede che la leadership sia disposta a mettere in discussione sé stessa. ## Una visione integrata {: #una-visione-integrata } Quello che propongo, e che vedo funzionare nelle organizzazioni più mature, è un approccio integrato che ha tre pilastri: **Upskilling mirato e continuo** : non corsi spot, ma [percorsi strutturati che bilanciano competenze tecniche e soft skills](), che evolvono con la tecnologia, che sono personalizzati sui reali bisogni delle persone. Formazione che non si limita a insegnare tool ma sviluppa capacità di pensiero critico, di giudizio, di creatività nell’uso della tecnologia. **Riprogettazione dei processi** : analisi radicale di come lavoriamo, con il coraggio di mettere in discussione assunzioni consolidate. Usare l’AI non per automatizzare processi inefficienti, ma per immaginare modi completamente nuovi di creare valore. Coinvolgere le persone in questo ridisegno, perché sono loro che conoscono davvero il lavoro quotidiano. **Trasformazione culturale** : creare un ambiente dove l’apprendimento continuo è valorizzato, dove la sperimentazione è incoraggiata, dove le metriche di successo premiano l’innovazione e non solo l’esecuzione. Dove le persone hanno tempo e spazio per pensare, creare, immaginare soluzioni nuove. ## Verso un nuovo equilibrio {: #verso-un-nuovo-equilibrio } In fondo, credo che ci troviamo di fronte a una scelta fondamentale. Possiamo usare l’upskilling come strumento per aiutare le persone ad adattarsi a un futuro che le schiaccia, inseguendo continuamente tecnologie che evolvono più velocemente di quanto possano apprendere. Oppure possiamo usarlo come parte di una trasformazione più ampia, dove la formazione delle persone va di pari passo con il ridisegno del loro lavoro e la creazione di spazi dove possano davvero esprimere il loro potenziale umano. La seconda strada è più difficile. Richiede investimenti non solo in corsi ma in cultura organizzativa. Richiede tempo, pazienza strategica, leadership coraggiosa. Ma è anche l’unica strada che ha senso se vogliamo davvero sfruttare il potenziale di questa rivoluzione tecnologica senza perdere quello che ci rende umani. L’upskilling funziona quando è ben fatto - mirato, continuo, bilanciato tra hard e soft skills. Ma funziona davvero solo quando è accompagnato da una trasformazione più profonda: quella dei processi, della cultura, del modo stesso in cui concepiamo il lavoro nell’era dell’intelligenza artificiale. Forse è questo che dovremmo insegnare per primo nei nostri programmi di formazione: non come usare l’AI, ma come ripensare insieme - persone, tecnologia, organizzazione - il futuro del lavoro. Un futuro dove la tecnologia amplifica l’ingegno umano invece di sostituirlo, dove l’automazione libera tempo per la creatività invece di generare solo ansia, dove le persone possono finalmente concentrarsi su quello che sanno fare meglio: immaginare, creare, innovare, costruire relazioni autentiche. Perché alla fine, il successo nell’era dell’AI non sarà determinato da quanto bene sapremo usare gli strumenti. Sarà determinato dalla nostra capacità di costruire organizzazioni dove formazione continua, riprogettazione dei processi e valorizzazione della creatività umana lavorano insieme per creare qualcosa che nessuna delle tre potrebbe creare da sola. --- # L'etica come bussola per l'intelligenza artificiale: quando i valori umani diventano valore di business - **URL:** https://margiovanni.it/it/blog/letica-come-bussola-per-lintelligenza/ - **Pubblicato:** 2025-12-17 - **Tag:** Business, Etica, Intelligenza Artificiale - **Tempo di lettura:** 6 min > Mi capita spesso di pensare a quanto l’intelligenza artificiale stia diventando parte del nostro quotidiano, quasi... ![](https://substackcdn.com/image/fetch/$s_!RmDJ!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F40095c6e-87b3-487a-9056-99e5b790e451_1024x1024.jpeg) Mi capita spesso di pensare a quanto l’intelligenza artificiale stia diventando parte del nostro quotidiano, quasi senza che ce ne accorgiamo. Un algoritmo che ci suggerisce cosa guardare su Netflix, un chatbot che risponde alle nostre domande, un sistema che seleziona i curriculum per un’azienda. Sono tutti esempi di come l’AI si sia insinuata nelle pieghe della nostra vita digitale, influenzando decisioni che fino a qualche anno fa erano esclusivamente umane. Ma c’è qualcosa che mi colpisce in questa trasformazione: non si tratta solo di una questione tecnologica. È una questione profondamente etica. E forse, più di quanto immaginiamo, è anche una questione di business. ## Quando l’etica diventa strategia aziendale {: #quando-letica-diventa-strategia-aziendale } L’idea che l’etica nell’AI sia solo una questione morale da affrontare “quando si ha tempo” sta rapidamente diventando obsoleta. [Le ricerche più recenti]() ci dicono qualcosa di interessante: le aziende che investono in pratiche etiche per l’intelligenza artificiale non stanno solo facendo la cosa giusta, stanno anche generando valore concreto. I dati parlano chiaro. Le organizzazioni che adottano principi etici nello sviluppo dell’AI vedono miglioramenti nella qualità dei prodotti, un aumento della fiducia dei clienti e [margini di profitto superiori del 10% rispetto ai concorrenti](). Non è più una questione di “se” implementare l’etica nell’AI, ma di “come” farlo nel modo più efficace. Quello che emerge dalle ricerche è un quadro affascinante: l’etica non è un costo, ma un sofisticato strumento di gestione del rischio finanziario e di generazione di ricavi con [ritorni economici misurabili e sostanziali](). ## La fiducia come valuta del futuro {: #la-fiducia-come-valuta-del-futuro } Forse il punto più interessante di questa trasformazione riguarda la fiducia. [Solo il 42% dei clienti si fida delle aziende nell’uso etico dell’intelligenza artificiale](), un dato in calo rispetto al 58% del 2023. Questo non è solo un numero statistico, è un campanello d’allarme che dovrebbe farci riflettere. La fiducia, in fondo, è diventata una vera e propria valuta nel mercato digitale. E le aziende che riescono a dimostrarla attraverso pratiche etiche concrete stanno guadagnando un vantaggio competitivo significativo. Il 62% dei consumatori si fida di più dei brand quando percepisce che la loro AI è etica, e il [61% condivide esperienze positive con amici e familiari](). Ma cosa significa, in pratica, costruire questa fiducia? Non si tratta solo di dichiarazioni di principio o di policy scritte su carta. Si tratta di trasparenza, di spiegabilità, di dare alle persone il controllo sui sistemi che le riguardano. ## I rischi nascosti dietro l’apparente neutralità {: #i-rischi-nascosti-dietro-lapparente-neutralita } Una delle illusioni più pericolose dell’intelligenza artificiale è quella della neutralità. “È solo un algoritmo”, sentiamo dire spesso. Ma la realtà è molto più complessa. Ogni sistema di AI riflette i dati con cui è stato addestrato, e questi dati spesso contengono [pregiudizi, discriminazioni e distorsioni]() che si amplificano nelle decisioni automatiche. Gli esempi non mancano. Il sistema COMPAS, utilizzato nei tribunali americani per predire il rischio di recidiva, ha mostrato il doppio di falsi positivi per i delinquenti neri rispetto a quelli bianchi. Un algoritmo sanitario utilizzato su oltre 200 milioni di cittadini americani favoriva sistematicamente i pazienti bianchi rispetto a quelli neri per l’accesso alle cure extra. [Amazon ha dovuto abbandonare un sistema di reclutamento]() perché penalizzava i curriculum che contenevano la parola “donne”. Questi non sono difetti tecnici. Sono conseguenze dirette di scelte progettuali che non hanno tenuto conto delle implicazioni etiche. E il costo di questi errori non è solo sociale, è anche economico: [danni reputazionali, cause legali, perdita di clienti](). ## Trasparenza: oltre la scatola nera {: #trasparenza-oltre-la-scatola-nera } Probabilmente una delle sfide più complesse nell’etica dell’AI riguarda la trasparenza. Molti algoritmi, soprattutto quelli basati su reti neurali profonde, funzionano come “scatole nere”: anche chi li ha creati fatica a spiegare come arrivano a certe decisioni. Ma la trasparenza non è solo una questione tecnica. È una questione di design, di esperienza utente, di comunicazione. Non si tratta di spiegare ogni dettaglio matematico, ma di dare agli utenti [informazioni sufficienti per comprendere e fidarsi del sistema](). Prendiamo l’esempio di un sistema di raccomandazioni. Non serve spiegare gli algoritmi di machine learning che ci stanno dietro. Serve dire: “Ti stiamo suggerendo questo prodotto perché hai visualizzato articoli simili di recente” o [“Questa raccomandazione si basa sui tuoi acquisti precedenti”](). È trasparenza umana, non tecnica. ## Il valore concreto dell’etica applicata {: #il-valore-concreto-delletica-applicata } Ma torniamo alla domanda iniziale: quanto l’etica può davvero guidarci nello sviluppo di soluzioni AI che portino più valore? La risposta, secondo i dati che abbiamo raccolto, è “molto più di quanto immaginiamo”. L’etica nell’AI genera valore in modi diversi e spesso complementari. C’è il valore diretto, legato alla riduzione dei rischi operativi e legali. C’è il valore indiretto, legato alla reputazione e alla fiducia del brand. E c’è il valore strategico, legato all’innovazione e alla leadership di mercato. Le aziende che adottano pratiche etiche vedono miglioramenti concreti: qualità dei prodotti superiore, fidelizzazione dei clienti più alta, attrazione e retention dei talenti migliore. E, cosa forse più importante, si posizionano meglio per affrontare le sfide regolatorie che stanno arrivando. ## L’approccio pratico: dai principi alle azioni {: #lapproccio-pratico-dai-principi-alle-azioni } Parlare di etica nell’AI è facile. Metterla in pratica è più complesso. Ma ci sono alcuni principi che possono guidarci. La **trasparenza** : rendere comprensibili i processi decisionali. L’**equità** : garantire trattamenti imparziali evitando discriminazioni. La **responsabilità** : definire chiaramente chi è responsabile delle decisioni dell’AI. La **privacy** : [proteggere i dati personali con misure robuste](). Questi principi devono tradursi in processi concreti. Diversificare i dataset per ridurre i bias. Implementare controlli umani nei processi decisionali critici. Creare interfacce che rendano l’AI comprensibile agli utenti. [Monitorare continuamente le performance etiche dei sistemi](). Non si tratta di aggiungere un livello di complessità allo sviluppo. Si tratta di integrare considerazioni etiche fin dall’inizio del processo, dall’ideazione alla deployment, al monitoraggio continuo. ## Verso un futuro più umano dell’intelligenza artificiale {: #verso-un-futuro-piu-umano-dellintelligenza-artificiale } Quello che mi colpisce di più in questa riflessione è quanto l’etica nell’AI non sia in contrasto con l’innovazione, ma ne rappresenti una forma più evoluta. Non stiamo rallentando il progresso tecnologico, stiamo orientandolo verso direzioni più sostenibili e più utili per le persone. [Il mercato italiano dell’intelligenza artificiale ha raggiunto 1,2 miliardi di euro nel 2024](), con una crescita del 58%. È un dato impressionante, che testimonia quanto rapidamente stiamo adottando queste tecnologie. Ma la domanda è: stiamo costruendo un’AI che serve davvero le persone, o stiamo solo inseguendo l’efficienza a ogni costo? L’etica nell’AI non è un lusso che possiamo permetterci quando tutto il resto funziona. È il fondamento su cui costruire tecnologie che siano non solo potenti, ma anche benefiche. È la differenza tra sviluppare sistemi che le persone subiscono e sistemi che le persone scelgono di utilizzare perché ne traggono valore reale. Forse è il momento di smettere di pensare all’etica come a un vincolo e iniziare a vederla come a una opportunità. L’opportunità di creare tecnologie che non solo funzionano, ma che funzionano per il meglio. L’opportunità di costruire fiducia in un mondo sempre più digitale. L’opportunità di dimostrare che l’innovazione più importante non è quella che va più veloce, ma quella che va nella direzione giusta. In fondo, non si tratta solo di intelligenza artificiale. Si tratta di intelligenza umana applicata alla tecnologia. E questa, forse, è la combinazione più potente che possiamo immaginare. --- # Quando la sicurezza incontra la realtà industriale - **URL:** https://margiovanni.it/it/blog/quando-la-sicurezza-incontra-la-realta/ - **Pubblicato:** 2025-12-17 - **Tag:** Cybersecurity, Industria, Sicurezza - **Tempo di lettura:** 1 min > Il 18 ottobre ero a Bergamo per il NoHat 2025, e mi sono trovato a riflettere su quanto sia facile vivere in una bolla... ![two bullet surveillance cameras attached on wall](https://images.unsplash.com/photo-1496368077930-c1e31b4e5b44?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wzMDAzMzh8MHwxfHNlYXJjaHwxfHxzZWN1cml0eXxlbnwwfHx8fDE3NjU5MDE4MTJ8MA&ixlib=rb-4.1.0&q=80&w=1080) *Photo by Scott Webb on Unsplash* Il 18 ottobre ero a Bergamo per il NoHat 2025, e mi sono trovato a riflettere su quanto sia facile vivere in una bolla quando si lavora con la tecnologia. Pensiamo di conoscere la sicurezza informatica perché sappiamo come funzionano i firewall, come configurare un sistema di autenticazione, come gestire le vulnerabilità in un’applicazione web. E poi senti parlare chi lavora con infrastrutture critiche o con sistemi di intelligenza artificiale, e capisci che il tuo modello mentale copre forse il 20% della realtà. Non è che quello che sappiamo sia sbagliato. È che il mondo è più vasto e più complicato di quanto tendiamo ad ammettere quando siamo immersi nel nostro ambito specifico. --- ## English --- # The Human Is a Stance - **URL:** https://margiovanni.it/en/blog/the-human-is-a-stance/ - **Published:** 2026-05-27 - **Tags:** AI, AI Act, Digital Sovereignty, Compliance, Ethics, Humanism - **Reading time:** 10 min > I am an atheist, I come from philosophy, I work in European compliance. Leo XIV's first encyclical on artificial intelligence is not something I signed, it is something I argued with. And I found in it a vocabulary that Brussels still lacks. ## I Come From Philosophy, and I Stayed an Atheist {: #philosophy-atheist } I come from philosophy. Years when I read Garin and Cassirer in the morning and Foucault and Bobbio in the afternoon, where anti-clericalism and humanism coincided so naturally that you didn't even need to argue it. From then on I have kept two convictions that I still consider the precondition of any serious public discourse. The first is that the historical religions are, in the vast majority of cases, anti-humanist devices, because the defence of the human requires a freedom that clerical structures have never been able to grant except through gritted teeth, under pressure, and almost always late. The second is that humanism, the real kind, the kind that starts with Garin and reaches the continental law of the twentieth century by way of the Italian Constitution and the 1948 Declaration, is a structurally secular ground, where religious traditions enter as guests, and when they try to take over the whole space they either get confused or betray themselves. These are judgments I have kept practising without much disturbance while reading the technical annexes of the AI Act, the latest implementing drafts of the Cyber Resilience Act, the EDPB guidance on DPIA templates for high-risk systems. I work in European compliance, I talk every day with public-administration and healthcare clients, and the only metaphysics I usually need is the already complicated one of Recital 71 of the GDPR. Then *Magnifica Humanitas* came out, and something moved. ## Not an Exhortation, a Treatise on the Human {: #treatise } It took me two evenings to read it. It is not short, and it does not pretend to be. It is a long text, two hundred and forty-five paragraphs across five chapters, with an apparatus of two hundred and twenty-four footnotes, written in that curial prose that at times slows down and at times accelerates in an almost surprising way. I expected yet another moralising exhortation about artificial intelligence, the kind of document that tries to keep pace with an industry conference and ends up arriving two years late and half a thesis short. I found myself in front of something different. Not an exhortation, but a treatise. Not about AI, but about the human, with AI used as a touchstone to restate who we are. It is exactly the thing that secular technical debate struggles to produce, because it presupposes a level of conceptual foundation that we are used to delegating to the laws, hoping the laws will manage on their own. ## Subsidiarity Was Not Born in Brussels {: #subsidiarity } The problem is that the laws do not manage on their own. I see it clearly when I try to explain to a client why digital subsidiarity, the kind that inspires much of the architecture of the Data Act and the operational chapters of the AI Act, is not a Brussels invention but a principle with almost a century of elaboration behind it. Pius XI formulated it in 1931 in *Quadragesimo Anno*, and since then it has passed through case law, German ordoliberalism, Adenauer's work, all the way to Article 5 of the Treaty on European Union. When a European regulator writes that certain decisions should be taken at the level closest to the people affected, it is using a grammar that was born elsewhere, not in Brussels. And when I try to defend that choice in front of a client, I find I lack the right words to explain it. Magnifica Humanitas, on this point, gave me back a vocabulary. ## The Universal Destination of Goods, Applied to Algorithms {: #destination-of-goods } What struck me is not the novelty of the ideas. The encyclical's ideas are largely known. What struck me is the way it holds them together, because they are exactly the ideas I need every time I have to discuss compliance without reducing it to a bureaucratic exercise. The universal destination of goods, for example, applied in paragraph 67 to patents, algorithms, platforms, infrastructure and data. It is not a position you can file away as pre-political or utopian. It is exactly the same problem the Data Governance Act tries to frame with the concept of data altruism, that the DMA chases with its gatekeeper rules, that the future interpretation of European health databases will have to face when the European Health Data Space comes into force. The fact that data is technically collectable and proprietarily assignable does not mean that its final destination is legitimately private. It is an operational statement, not a sermon. ## Above the Citizen There Is No Longer Only the State {: #above-the-citizen } The same goes for subsidiarity in paragraph 71. The encyclical does something few technical documents have the courage to do explicitly: it recalls that, in the digital context, the level above the citizen is no longer the State, but the large economic actor that exercises de facto power over the conditions of common life. It is not a metaphor. When a platform decides what is visible and what is hidden, when an algorithmic scoring system establishes who gets credit and who does not, when a language model becomes the dominant interface for certain kinds of service, a power is exercised that the classical theory of subsidiarity had not foreseen in those terms. Recognising it formally, inside an official document of this authority, shifts the level of the discussion. It stops being a niche opinion. It becomes a grounded position that can be cited in a legal brief, in an impact assessment, in an opinion to a client who asks why all this effort is going into implementing a transparent logging system. ## From Judgment to Calculation, Half a Century After Weizenbaum {: #judgment-calculation } Then there is a passage I did not expect, and it is probably the strongest piece of the whole document. It is in paragraph 198, in the chapter on the culture of power, where the encyclical addresses war, but it holds for everything. *Moral judgment cannot be reduced to a calculation, because it involves conscience, personal responsibility and recognition of the other as a person. It is therefore not permissible to delegate lethal or otherwise irreversible decisions to artificial systems.* Two sentences that contain at least half a century of critical thought on automatic calculation. Joseph Weizenbaum, the MIT engineer who in 1966 had built ELIZA and who a few years later was frightened to see how his secretary confided in it, wrote in 1976 a book whose subtitle was *From Judgment to Calculation*. The whole book was a defence of that preposition, *to*, which marks a loss. Weizenbaum argued that there are tasks computers cannot and must not perform, even if technically they could, because they involve the recognition of the other as a person, and that recognition is not a problem of internal representation. It is an act. Magnifica Humanitas, half a century later, says exactly the same thing with a different vocabulary. It is not a coincidence. It is that certain anthropological truths come back out when material conditions force them to come back out, and today the material conditions are those of automated decision-making applied to real human lives. ## The New Slaveries and Data Colonialism {: #new-slaveries } The encyclical goes further. In paragraph 173 it names things the mainstream debate on AI prefers to leave in the margins of vendor conferences. It explicitly cites data labeling, content moderation, rare-earth extraction, child labor in mines. It calls them new slaveries, and not as rhetoric. It calls them that because they are actually feeding, invisibly to anyone using an API at sixty cents per million tokens, the entire economy of transformer architectures. In paragraph 178 it introduces a concept that technopolitics scholars have been using for at least five years but that makes a certain impression when you see it used in a pontifical document: data colonialism. The key sentence is that whoever owns the health data of entire populations, today often collected under the sign of aid, research or innovation, in fact owns structural leverage on the future. It is an exact description of the strategic risk that weighs on many African, Asian and Latin American contexts, and that should weigh on our procurement choices when we decide where to host data, which vendor to buy a model's training from, which ecosystem to delegate the epidemiological analysis of a region to. It is not a new-age sensibility. It is an impact assessment. ## A Treatise That Holds as a Source for a DPIA {: #source-for-dpia } At this point in the reading I stopped. I was annotating passages in the margin as if I were preparing a technical brief, and I realised that was exactly what I was doing. The encyclical works perfectly well as an anthropological treatise, but it also works as a secondary source for a compliance argument. It is a text that can be cited in a DPIA to justify a restrictive assessment. It is a text that can be attached to an opinion on an AI integration in healthcare. Not because it has legal value, obviously, but because it provides the frame of principle that is often missing when technical choices are discussed, and that when missing turns into decisions made on the sole basis of opportunity cost. Anyone working in European compliance knows what I mean. There is a grey zone, between the recital and the article, between the legislator's intent and the letter of the rule, where the practitioner needs to lean on something solid to explain why one interpretation is preferable to another. Having a text of this weight, written from a position outside the technical system but able to speak about it from the inside, is an asset it would be foolish not to use out of prejudice. ## It Isn't a Conversion, and It Isn't a Perfect Text {: #not-a-conversion } I realise that anyone who knows me might find it strange to read these lines. I am not announcing a conversion, and I am not even saying the document is perfect. There are points where the encyclical slips, especially when it enters the ground of bioethics and the family, where my personal distance stays intact. There are passages where the pastoral tone takes over from conceptual precision, and where I would have wanted less rhetorical charity and more tools of analysis. It is not a text you sign, it is a text you argue with. But it is the kind of argument that I, as an atheist who works on the European regulation of technology, need today more than I needed yesterday. And I think it is needed, in the same way, by anyone trying to build a European technology industry different from the one that reaches us from San Francisco or Hangzhou, because different means founded on something, and something, at this historical stage, cannot be improvised. ## Disarm {: #disarm } In paragraph 110 there is a word that made me smile. *Disarm*. The encyclical says it wants to disarm AI, and immediately specifies that to disarm does not mean to renounce. It means taking it out of the hands of monopolies and the logic of competition, making it debatable and contestable, returning it to the plurality of human cultures. It is a political word, not a religious one. It is exactly the word Brussels still cannot bring itself to say, because Brussels is still hostage to the realism that assumes the arms race as a natural given. A race that has stopped being military and become cognitive, as the encyclical notes with remarkable lucidity, but that keeps the same underlying logic. The fact that the first to say it, in an official document of this reach, was the Vatican and not a European commissioner, says something about the state of our public debate. It is not good news, but it is news to start from. ## Three Things I Borrow {: #three-things } I close with a note that has nothing to do with theology. When you read a text produced inside a tradition that is not your own, there are two roads. One is preventive suspicion, which consists in asking the text to betray its own origin before you accept even to hear it. The other is the loan, which consists in taking what you need, leaving what you don't, and going back to your work with one more tool. As an atheist, I feel I can borrow at least three things from *Magnifica Humanitas*. The explicit recognition that moral judgment cannot be automated, and that whoever tries to automate it is performing a political operation, not a technical one. The naming of the invisible supply chains that feed the digital economy, which is the precondition for any serious request for due diligence. And that word, *disarm*, which I would like to see applied, in the coming years, to the regulatory texts I will happen to read for work. The rest, whoever cares, can argue in the proper places. **For me, today, it is enough to have one more treatise on the nightstand, and a few well-written pages to reread when a client asks me why, after all, deep down, I am taking the trouble to do things properly.** --- # Twelve Jobs in Search of a Market - **URL:** https://margiovanni.it/en/blog/twelve-jobs/ - **Published:** 2026-05-13 - **Tags:** AI Act, AI, Compliance, EU Regulation, IT Market, Work - **Reading time:** 6 min > The first national European standard on AI professional profiles was published on 30 April. It is worth taking seriously, and it is worth mistrusting in the right way. ## The Norm Lands on 30 April 2026 {: #norm-lands } The first reaction to the publication of UNI 11621-8, the Italian standard that defines the twelve professional profiles of artificial intelligence, should be suspicion. Standardising the trades of a field that changes every six months is an almost paradoxical exercise, and doing it before the rest of Europe means taking on the risk of being wrong first. The norm arrived on 30 April 2026, signed by UNINFO with the coordination of the Italian Department for Digital Transformation. The regulatory anchor goes to Regulation EU 2024/1689, the AI Act, and to Italian Law 132/2025 on AI. The Italian Law 4/2013 on non-regulated professions acts as the ramp to certification. ## A Word in Search of a Metric Since February {: #word-metric } For anyone working in compliance every day this closes a circle that had stayed open since 2 February 2025. That day, Article 4 of the AI Act required providers and deployers to ensure a sufficient level of staff literacy, without explaining what, exactly, the adjective sufficient meant. Over the last months, working on compliance projects for clients in highly regulated sectors, that word came back in every conversation as an unanswered question. No document kit and no DPIA template managed to pin down its meaning without circumlocutions. What does "sufficient competence" actually mean? When is a client's request reasonable, and when is it a demand for which no metric yet exists? UNI 11621-8 provides that metric, and it provides it in Italian, with names that the buyer at a healthcare company or a regional public office can read without translating them. ## Twelve Profiles, From the CAIO to the Researcher {: #twelve-profiles } The twelve profiles cover the spectrum from governance to research. They go from Chief AI Officer to AI Research Scientist. For each profile the standard specifies mission and tasks, together with a map of required competences, the expected level and the associated performance indicators. The methodology is the consolidated one of UNI 11621-1, and the anchor is the European e-Competence Framework, UNI EN 16234-1. Technically the work is solid, and it is important to say so before getting to the problems. ## The Material Being Codified Is Still in Motion {: #material-in-motion } The problems start with the material the norm tries to freeze. A profession is codified when it has reached a sufficient degree of stability, and today's AI has not. The Prompt Engineer, present in the list as a separate profile, is already an interesting case. When it existed as a distinct role, it had a short life, and was quickly absorbed by developers and product managers working directly with generative models. Keeping it as a dedicated profile means chasing a practice that has already evolved elsewhere. The same applies, to a different degree, to the sharp separation between Data Scientist and Machine Learning Engineer, two roles that in real practice overlap widely. The boundaries of codified professional figures are much sharper than the boundaries of the competences people actually exercise. A good Data Scientist touches ML engineering, and a competent ML engineer knows how to move in the data pipeline. When an AI Security Specialist does not understand models at the root, they stop being a security professional and become a document reviewer. ## Who Writes the Standard, and Why {: #who-writes } There is a subtler matter, and it concerns the origin of professional-profile standards in Italy. They are produced by committees that include certification bodies and training providers, along with trade associations. Legitimate actors, all of them, and all with an economic interest in the final outcome. This does not make the standard less useful, it changes how it should be read. Under the technical surface there is the construction of a market. The market of professional certification and accredited training. The Italian ITS Academy programmes, the country's higher technical education tracks, are aligning in these very weeks, and certification bodies are preparing their own schemes. Law 4/2013 provides the hook: those who can certify a profile earn from that certification. The question is not whether the system is legitimate, it is. The question is what we are actually buying when we spend to certify an internal Chief AI Officer. ## The Substitution Effect, As With the DPO {: #substitution-effect } A third caution concerns the substitution effect, which is probably the most serious risk. Having UNI-compliant profiles does not mean having competent AI governance. The recent history of the GDPR is full of organisations that had a certified DPO and disastrous processes, because the DPO was an administrative slot, not an operational function. The same can happen with the Chief AI Officer and the Security Specialist. Compliance by checklist produces organisational comfort and little real safety. If UNI 11621-8 is read as a documentary obligation, we will have companies with clean tables and fragile AI systems. If it is read as a skeleton around which to build real practice, we will have something useful. ## A Trajectory We Have Already Seen {: #trajectory-seen } Having said all that, the publication of the standard is worth taking seriously. For a reason that has little to do with technique and a lot to do with the timing of a regulated market. The pattern, in Italy, is one we have already seen. The Cloud Italia Strategy of 2021 generated a framework for the classification of data and services for the public administration. That framework became a regulation of the Italian cybersecurity agency between 2022 and 2023. The catalogue of qualified cloud services then entered public-administration procurement procedures, all the way to Consip MEPA, the Italian central purchasing platform. Initially vague clauses on cloud-service security turned into verifiable technical requirements and conditions for participation. Whoever arrived later competed as a generic supplier against pre-qualified ones, and lost significant tenders. UNI 11621-8, applied within the AI Act frame, follows an analogous trajectory. The standard starts as a voluntary reference and ends in procurement specifications. Passing through the Department's policy directives is almost an administrative detail. The useful window opens now and closes when the first significant tender cites the norm. ## Inside a Multi-Framework Compliance Kit {: #compliance-kit } For those of us, like Oltrematica, who work on multi-framework compliance, the standard is first of all a defensible documentation instrument. The RACI matrix of a high-risk AI project, built on the UNI profiles, becomes evidence that holds up in audit. The internal training plan, mapped to the profiles, stops being an administrative cost and becomes an integral part of the AI risk-management programme. The form we are giving to our internal documentation kits absorbs the standard without effort, because it speaks the same language as the frameworks we already use, from the GDPR to the Cyber Resilience Act. ## An Imperfect Map, But a Map {: #imperfect-map } There is a line of work more interesting than mere conformity, and probably less profitable in the short term. The standard is an **occasion for internal intelligibility**. It allows organisations that adopt AI to talk about it with a shared vocabulary, before they talk to regulators or to certification bodies. It is an imperfect vocabulary, partly dated and built around recognisable economic interests. But it is the first available vocabulary, and its imperfection is smaller than its usefulness. The real question, the one that will decide whether UNI 11621-8 is a good norm or a bad one, is not written in the text. It will be written in the coming months, in the interpretations organisations give it, and in the tenders that use it to filter suppliers. In the meantime, **it is worth reading it for what it is**. An imperfect map of a territory we are already crossing, which at least proposes a shared toponymy so that we do not all get lost in the same way. --- # I Say No at Night, I Use the Same Tools in the Morning - **URL:** https://margiovanni.it/en/blog/the-same-tools/ - **Published:** 2026-05-08 - **Tags:** Responsible Design, Parenting, Attention Economy, Digital Addiction, Ethics - **Reading time:** 8 min > At night I say no to my three-year-old who wants the tablet for a little longer. I say it for one specific reason, and from that reason a free book was born. ## Eight in the Evening {: #eight-in-the-evening } Eight in the evening, more or less. Dinner just ended, the dishes in the sink, the table still to be cleared. My son is three years old and is trying to convince me to let him keep the tablet for a little longer, which in his grammar of time means a span between twenty minutes and infinity. I say no. Not in anger, not with a parenting lecture. I say no with the precise tiredness of someone who repeats the same scene every evening, knowing the next one will be the same. So far it is a scene any parent recognises. It could happen in any home. ## I Know How That Tablet Works {: #how-that-tablet-works } The difference is the reason I say no. It isn't because I read an alarming article on screens, or because I follow a paediatrician on Instagram who recommends the digital detox, or because in my day we played outside. The reason is that I know how that tablet works. Not in the generic sense, not "technology is bad for children." I know in the technical sense. I know how the software running on it is built. I know which design decisions the people who built it made, and I know why they made them. I know what happens when my son touches the screen, what logic decides what to show him next, and what objective that logic is trying to reach. That objective is not his wellbeing. I know this because it is my craft. I have been building software for nearly twenty years. I don't work for the big social platforms, I have never had an office in Menlo Park or Mountain View. I do far more boring things: ERP systems, training platforms, applications that help companies organise data. The kind of stuff that would never end up in a journalistic investigation, because it isn't interesting enough. Someone might object that the problem doesn't concern me, that attention-capture techniques belong to TikTok, to Meta, to ByteDance, and that between a social platform and an ERP system there is the difference between a Formula 1 track and a country road. It would be a sensible objection if it weren't false. The techniques for keeping people glued to a screen are not an industrial secret. They are a shared, documented, taught discipline, discussed at the conferences I attend, debated in the Slack channels where I spend my working days. They are common heritage to anyone who builds digital products. The levers TikTok uses to keep a fifteen-year-old glued to the screen are close cousins of the levers I would use to help a client raise the average session time on a corporate training platform. The context changes, the intensity changes, the user type changes. The basic tools go by the same names, are taught at the same conferences, are found in the same design books. In the evening, at home, I read the floorplan of my son's tablet the way you read the blueprint of a building: this serves that, that serves this, here the design pushes you in this direction, there it stops you from going in that one. In the morning I work with the same tools as the people who drew that floorplan. From this fracture comes a book I wrote and decided to make freely available. It is called *I tuoi figli non sono i tuoi utenti* (Your children are not your users), and it tries to do one very specific thing: transfer a piece of professional knowledge to the people who don't have it, because the difference between having it and not having it, when it concerns your own children, is enormous. ## Skinner, the Pigeon, the Feed {: #skinner-pigeon-feed } To give a sense of what kind of knowledge we are talking about, I'll take a single example among many, the one I think is the most important and the least known. Between the 1940s and the 1950s the psychologist B. F. Skinner ran a series of experiments with pigeons in a cage. If the pigeon pecked a disc with its beak, it got food. Skinner discovered something interesting: if food arrived every time the disc was pecked, the pigeon pecked when it was hungry, and that was it. If instead food arrived unpredictably, every three pecks, every five, every two, the pigeon began to peck the disc continuously, compulsively, even when it wasn't hungry. Variable reward, that mechanism, is the psychological engine of slot machines. It is also the psychological engine of a social network feed, not by poetic analogy but by explicit design. When your child scrolls Instagram for twenty minutes, most of the content seen is trivial, irrelevant, forgettable. Every now and then something good arrives, something that makes him laugh, a piece of news that interests him, a photo that concerns him. He doesn't know when it will arrive. He only knows that if he keeps scrolling, sooner or later it will. His brain is doing, in an elegant digital version, exactly what Skinner's pigeon was doing. ## Personalised Random {: #personalised-random } There is an important difference that makes things worse, and that people outside the industry usually don't consider. Arcade slot machines distribute wins randomly, because they know nothing about the player. A social network's algorithm knows what you like, what you pause on for a second longer, what outrages you, what moves you. It uses this information to calibrate content distribution so the variable-reinforcement effect is maximised on you, specifically. It is no longer random, it is personalised random, paradoxically more effective than pure chance because it keeps the unpredictability (you don't know when the good content will arrive) and adds the relevance (when it does, it is calibrated on your interests). On a teenage brain, whose prefrontal cortex is still under construction, this mechanism is particularly potent. ## The Other Mechanisms {: #other-mechanisms } Variable reward is one of the mechanisms the book describes. There are others: infinite scroll, which removes decision points; autoplay, which makes "keep watching" the default; notifications calibrated to produce an involuntary physical response; dark patterns that make signing up easy and leaving difficult. They are all documented, all taught, all applied without distinction of age, even to the products your child has on his phone. There is nothing clandestine about any of this. It is open literature, accessible to anyone who wants to read it. The problem is that the people who read it are almost always the people who build those products, rarely the people who use them. ## What the Builders Know, and What They Do With Their Own Children {: #what-builders-know } From here comes the question that gives the book its title, and which is the simplest one I know about the whole matter. The Silicon Valley private schools that ban screens in class are not an urban legend. Tim Cook, Apple's CEO, stated publicly that he would not allow his nephew to use social media. Sean Parker, the first president of Facebook, described the platform's design as consciously oriented to exploit a vulnerability of human psychology, and added that only God knows what it is doing to our children's brains. Chamath Palihapitiya, former vice-president of user growth at Facebook, said publicly that his children were not allowed to use that stuff. The testimonies of insiders who admit to protecting their own children from the products they helped build are not hidden, not ambiguous, not scarce. You only need to look. The observation I make in the book, and that I make here too, is smaller and more ordinary than these famous declarations. Among the colleagues working in software I talk to regularly, the ones with children are almost unanimous on one point: stricter rules on phone use than the average non-tech parent, delayed access to social media, careful control over which apps get installed, conversations with the children about how notifications work and why. It is not a scientific datum, it is an anecdotal observation. But it is consistent, it is recurrent, and its very existence proves the point: people who know the mechanism behave differently. If the people who build these things keep their own children away from them, what is it that they know and we don't? ## Informational Asymmetry, and the Book {: #asymmetry-and-book } It is not a rhetorical question. There is no secret room where tech executives plan how to harm the world's children. There is something far more ordinary and far harder to fight, which economists call informational asymmetry. On one side, the people who understand how digital products work, how they are designed, which psychological levers they use and why. On the other side, the people who use them, and let their children use them, without that information. This asymmetry has existed as long as industries have. Food-company chemists know things about food that consumers don't. Automotive engineers know things about cars that drivers don't. The difference is that in those sectors, over time, a system of labels, safety standards, and transparency obligations was built. For digital products that system is still largely to be built, and in the meantime our children spend hours inside them every day. The book tries to close that gap. Not all of it, that would be an excessive claim. A part. It explains how the main mechanisms work in language that doesn't require technical skills, recounts what we know and what we are still trying to understand about the effects on our children, and tries to outline what each of us can do in our own role: as parents, as citizens, as users, and also, for those of us who work in the industry, as people who build this stuff. **It is not a parenting survival manual, and it is not a book against technology. It is an attempt to transfer a small part of professional knowledge to the people who normally don't get it.** **The book is free**, in epub and pdf, at [ebook.margiovanni.it](https://ebook.margiovanni.it). If you read it and find it useful, what I ask is that you pass it on to another parent. That handoff between two people who know each other is worth more than any recommendation algorithm, and it is exactly the kind of thing the mechanisms the book describes cannot do. --- # The Compliance Hourglass - **URL:** https://margiovanni.it/en/blog/the-compliance-hourglass/ - **Published:** 2026-05-07 - **Tags:** Compliance, Italian Market, IT Advisory, Digital Sovereignty, ACN - **Reading time:** 7 min > A map of the Italian compliance market drawn from the inside: specialist advisory at the top, platforms at the bottom, the middle layer crushed between them. And the one specifically Italian piece—ACN—that bends the rules. ## A Map Drawn from the Inside {: #map-from-inside } A large client in a regulated sector asked us, a few months ago, to put the platform on a secure footing. The request came in the usual terms—information security and conformity audit. What they ended up taking home was a DPA Annex 2 articulated across nineteen sections, a technical gap analysis, a remediation roadmap, and a formalised sub-processor chain written to withstand a serious inspection. There wasn't a single new line of code in what we delivered, and not a platform to license either. Structured paperwork and contractual positioning, produced in such a way that they would hold up before anyone who came to ask. The interesting thing is that this wasn't an exception. It's the rule that has settled in over our last twelve months of work. Someone might argue that the map of this market already exists, and that it's enough to read Gartner's Magic Quadrant for GRC tools, or to consult Forrester's reports on privacy-management platforms. That would be a convenient and partly misleading shortcut. Those documents photograph the global platform market—ServiceNow, MetricStream, OneTrust, Drata, and Optro, which has just renamed AuditBoard last March. The Italian compliance market has a structure of its own, shaped by the Agenzia per la Cybersicurezza Nazionale, by the NIS2 transposition through *decreto legislativo* 138/2024 (Italy's NIS2 transposition), by the dominant weight of public administration in total spend, by the irregular pace at which European directives are operationalised by end clients. To read it you need a map drawn from the inside. ## At the Top: Specialist Advisory {: #top-layer } It helps to picture the market as an hourglass. At the top, a thick layer of specialist advisory has formed. The Big Four—Deloitte, PwC, EY, KPMG—run GRC practices that by now look interchangeable on paper, and compete more on the names of their senior partners than on their methodologies. Alongside them, and in some cases at a qualitatively higher level, the structured Italian boutiques operate. P4I, part of the Digital360 group, lists more than one hundred and sixty professionals on its site and sells a methodological brand called Advisory Engine, with a catalogued product registered as Compliance360. ICTLC consolidated the legal-tech angle that's fashionable today, but wasn't when it started. Spike Reply operates inside the Reply group while keeping a recognisable identity, and covers the full spectrum of cybersecurity and data protection with significant weight on financial and manufacturing dossiers. Deda Tech took the multidisciplinary-team route, where lawyers and economists sit beside engineers, and in public interviews the firm openly says it doesn't sell technical solutions but trust. The line sounds like marketing, and it matches the actual positioning. What these firms sell is interpretation. Not a piece of software that does something, but a recognisable person, able to translate a regulation into the specific terms of your supply chain, and to hold the line at the negotiating table on a Data Processing Agreement with an American cloud provider without giving up what shouldn't be given up. The margins are high and the scalability is low. Dependence on the single name with the grey beard or the academic CV is structural to the model. Growth happens by cooptation—hiring heavy names, acquiring smaller firms that bring consolidated client portfolios as dowry. It's a mechanism that resembles the legal world more than the software world. ## At the Bottom: The Platforms {: #bottom-layer } At the bottom, the platform layer has formed. IntelMarket Research projections value the global GRC platform market at $16.7 billion in 2024, with a 2032 horizon at $32.8 billion and a compound rate of 9.9 percent. Other estimates give meaningfully different numbers depending on how the perimeter is drawn, but the direction is the same. ServiceNow GRC is the default for anyone already using ServiceNow for IT service management, and that covers a meaningful slice of the Italian enterprise. MetricStream covers the segment of multinationals with mature GRC programmes. OneTrust turned GDPR into a product and is now repositioning itself on AI governance. Drata and Vanta automate SOC2 and ISO 27001 for startups and scale-ups, with evidence collected continuously and SaaS pricing that fits a CTO's budget without having to go through the CFO. The Italian portion of this layer is thin. The Italian market for compliance-dedicated software has not produced players of international scale, and local attempts remain confined to single verticals or single clients. ## The Compressed Middle Layer {: #middle-compressed } Between these two layers, where the hourglass narrows, sits the middle layer—and that's where the interesting dynamic lives. It's the layer of custom compliance software, of bespoke GDPR back-office tools, of vertical ISO 27001 platforms developed by mid-sized Italian software houses. For years it was a comfortable layer. The client didn't trust American platforms for reasons of data sovereignty, the Big Four were too expensive for the mid-market, and a local software house delivering a branded GDPR portal was the natural answer. Today this layer is compressed from both sides at once. From below, because Drata delivers SOC2 at a fraction of the cost of a bespoke tool, and startups have no reason to commission anything proprietary for a commodity function. From above, because when the problem turns serious—a defensible DPIA, a contract negotiation with Microsoft that doesn't leave gaps—the client realises software isn't enough, and that what they need is a person who speaks their language and can sign documents that hold up. ## ACN, and the Market Inside the Market {: #acn-market-inside } What makes the Italian map structurally different from the global one is ACN. The Regolamento unico per le infrastrutture digitali e i servizi cloud (Italy's unified rulebook for digital infrastructure and cloud services), the *decreto direttoriale* 21007 of 27 June 2024, in full effect since 1 August of the same year, has built a market inside the market. Public administration can only buy cloud services if they are qualified QC1, QC2, QC3 or QC4, delivered on infrastructure rated AI1 through AI4, according to a matrix that ties data classification to the permitted service level. Aruba is qualified at the highest tiers, Polo Strategico Nazionale handles data classified as strategic, and a handful of other providers are filling in the remaining cells of the catalogue. For Italian system integrators working with the public sector, the concrete choice becomes binary. You either resell someone else's qualified cloud, accepting thin margins and an implementer's role, or you build an advisory that guides the public-sector client through architectural choices, capitalising knowledge of the qualified catalogue as a distinctive asset. When I prepared for Pescara Multiservice the proposal for ACN-qualified cloud hosting based on Aruba VPC at QC3 level—against the actual price-list entry ARB-11504-1 of €217.38/month—the part of value the client was buying was my translation work between their application requirements and the catalogue's requirements. Infrastructure was commodity. Interpretation wasn't. ## What System Integrators Are Doing {: #system-integrators } At this point you can see what's happening to Italian system integrators, and why. The large ones—Reply, Engineering, Almaviva, NTT Data Italia, Accenture—already run internal GRC practices that compete directly with the Big Four, and in some cases have outperformed them on public contracts. Spike Reply is the canonical example of this movement, but not the only one. The mid-tier firms—Deda Tech, Var Group, Lutech—build multidisciplinary teams and resell their identity as trusted advisors in a new vocabulary. Implementation revenue is still significant, but the high margin lives where you sell days of interpretation, not sprints of development. The small ones face a tighter choice. They can become someone else's reseller and lose their identity. They can stay specialist implementers in a vertical where domain depth offsets a lack of scale. There's also a third path, riskier than the others—turning into an advisory boutique and selling knowledge first and implementation second, trading a portion of certain revenue for a positioning that's still uncertain. Most aren't choosing—they're passively absorbing the drift of the market. At Oltrematica we made the choice vertically: private healthcare and local public administration, with serious investment in compliance documentation as a product. That DPA, the five-tier formalisation of a sub-processor chain crossing three companies inside the same industrial group, the analysis of the new DPIA template that the EDPB adopted on March 10 and published on April 14 for consultation through June 9—all of these are pieces of work that, five years ago, we would have done as an accessory to the main project. Today they are the main project, and software comes after, if it comes at all. ## Where Value Migrates, and What I Don't Know About 2027–28 {: #value-and-doubt } There's a consequence to all of this that's worth making explicit. Value in the Italian compliance market is migrating to the two ends of the hourglass. International platforms keep pushing the cost of evidence down, and that pressure won't stop, because their business model depends on progressive automation. The advisory boutiques and the GRC practices of the large system integrators keep pushing the price of interpretation up, and there's no technological innovation on the horizon that reduces the cost of an opinion signed by a recognisable name. What's left in the middle—custom compliance software—faces a fork. It can become specialist inside a vertical to the point of no longer being substitutable by generalist platforms, or it can be absorbed into an advisory offering as a capability rather than a standalone product. The Politecnico di Milano figure that estimates the Italian cyber and data-protection segment at €2.78 billion in 2025 with twelve percent growth doesn't distinguish between these layers in its surveys, and that's probably one of the reasons companies in the middle layer keep reading the numbers as good news when in fact they're saying something subtler. The most honest sentence I can write about how this market will look in 2027 and 2028, when the Cyber Resilience Act is operational and the AI Act in full enforcement, is that **I don't know**. It seems plausible to me that a reconfigured middle layer will emerge, where tools like Claude Code, GitHub SpecKit and their derivatives will let software houses like ours produce compliance artefacts treated as code—versioned, tested, generated from traceable formal specifications. It's a direction I'm investing in personally and that I've been writing about here for several months. But it's also possible that the middle layer collapses entirely and that the Italian market polarises onto two sides, the way other mature markets did before ours. Twelve months from now this map will need to be redrawn. That will be one of the exercises I take on. --- # The Spectre We Are - **URL:** https://margiovanni.it/en/blog/the-spectre-we-are/ - **Published:** 2026-05-05 - **Tags:** Digital Sovereignty, GDPR, AI Act, DSA, Politics OF Technology - **Reading time:** 22 min > A long reckoning with European digital regulation seen from the outside—by those who hate it—and a counter-reading from inside, by those who translate those rules into technical objects every working day. ## The Spectre Is Us {: #spectre-is-us } A spectre is haunting Europe, and for once it is not the one Marx had in mind. It is a stranger spectre, because it does not haunt those of us who live here. It haunts those who watch us from the outside, from the other side of the ocean, who look at us the way one looks at an eccentric relative at Christmas dinner—someone you are obliged to put up with, someone you would happily be rid of, who nonetheless stubbornly keeps existing and keeps talking about strange things like the dignity of work, accessibility, child protection, product liability. The spectre is us. Or rather, it is what we are doing here in the area of digital regulation, a series of acronyms that in Brussels are considered ordinary technical work and that in San Francisco are perceived as a near-existential threat. Seen from the outside, and in particular seen from one specific corner of the world that has made itself heard a great deal in the last few years, Europe has become a character. It is no longer an economic subject, nor a political union, nor, by now, the continent of the hundreds of millions of people who actually live here. It is a meme. A meme with a precise narrative function: to embody what the future must not be. Nineteenth-century bureaucracy pasted on top of the twenty-first century. The old world holding back the new. The open-air museum that presumes to dictate rules to tomorrow's factory. It is a caricature, of course, but an effective one, because it works inside a much larger story than itself, and that story is the culture war a slice of American capitalism is waging against the very idea that software can be the object of rules. ## GDPR and the Banner That Sums It Up {: #gdpr-banner } To understand where we are now, it helps to go back a little. The moment when the relationship between Silicon Valley and European regulation cracked in a way that has been hard to mend was GDPR. A regulation from 2016, applied from 2018, technically not revolutionary, drawing largely on principles that already existed in Convention 108 and in directive 95/46. Yet what GDPR did in practice was to declare that certain business models built on indiscriminate collection of personal data would, at some point, have to answer for something. It is no accident that GDPR has become the symbolic target par excellence in the anti-European narrative, and no accident that the prevailing way to attack it is the cookie banner. Here I owe my first concession. The cookie banner as we live with it is a failure. It is a failure from the user's point of view, who clicks it away without reading. It is a failure from the standpoint of effective protection, because that consent is almost always fictitious. It is a failure from the standpoint of the interface designer, forced to accept that every European site opens with a digital customs gate that nobody wants. It is the textbook example of a rule that is correct on the level of principles and that has discharged itself onto the implementation plane in a grotesque way, because the legislator assumed consent was the sovereign act of will of a rational subject, and the designers of digital products knew perfectly well that you only had to design the banner a certain way to get it clicked through in half a second. The dark pattern has eaten the theory of free, specific, informed and unambiguous consent. You can see it every day. It is a real problem. The critics are right on this specific point. But this is where the divergence between useful and instrumental criticism begins, because anyone who is right about the cookie banner is not actually arguing about the cookie banner. They are using the cookie banner as a metonymy to attack the very idea that the collection of personal data is a regulable problem. They are saying, in substance, that if the rule produces an ugly implementation then the rule must be abolished, not that the implementation must be corrected. It is an old rhetorical move, and there is no need to summon any authority here—it is enough to observe that those who call for the abolition of GDPR on the basis of the cookie banner do not usually call for the modification of the technical consent rules, which would be the coherent position. They call for a return to a world in which American platforms can do whatever they want with our data without owing anyone an explanation. The banner was a pretext, not an argument. ## DSA, DMA, and the Business Model {: #dsa-dma } That it was a pretext became definitively clear with the DSA and the DMA. When the Commission began asking gatekeepers to open their platforms, to make certain services interoperable, to stop favouring their own products in their stores, to allow users to uninstall pre-installed applications, the argument "you regulate too much" turned without intermission into the argument "you are attacking our companies". The leap is interesting. For years they explained to us that the problem was the excess of rules, not the identity of those who paid. Once the rules became operational, they explained that the problem was that they hit only American champions. The two theses are not compatible, but they coexist comfortably inside the same line of argument, and that alone should make one suspect that something does not add up. A point worth making about the DMA. The thesis that the DMA specifically targets US firms is factually weak, because ByteDance is also among the gatekeepers, and because thresholds are thresholds. A European company reaching seventy-five billion in capitalisation and forty-five million monthly end users would be a gatekeeper too. The problem is that European companies in that range are extremely rare, and the only recent case, Booking, operates from Amsterdam but reports to a US holding. That absence does not depend on the DMA. It depends on industrial, fiscal, financial and educational choices of the last forty years that the DMA did not cause and will not solve. If we want to talk about that problem, let us talk about it seriously, citing the Draghi report if we need a recent anchor, but let us not confuse it with platform regulation, because the two planes only touch in appearance. This is the point that those who watch us from outside do not want to see, or perhaps see perfectly well and pretend not to. Platform regulation is not in competition with innovation. It is in competition with a specific business model—mass extraction of personal data, attention optimisation pushed to the edge of addiction, capture of adjacent markets through dominant-position leverage, systematic offloading of negative externalities onto the social body. It happens that this business model has been the prevailing model of American digital capitalism for the last twenty years. It happens that the companies practising it are now the largest in the world, and that they have an obvious interest in continuing to practise it. If the European Union says that this specific model has limits, it is touching a raw nerve, and not by accident. It is saying, more or less articulately, that there is another way of doing digital technology. In 2026, that is heresy. ## From Rule to Technical Object {: #rule-to-object } Let me leave analysis aside for a moment and tell a concrete story, because I think it helps to know where I am speaking from. I have worked for several years inside a mid-sized Italian ICT company, outside the major metropolitan areas, that builds software for public administration and healthcare. For the last two years my work has been largely one thing: translating European regulation into technical objects. What it means to have a healthcare platform compliant with GDPR Article 28 when the supplier of a supplier is in Germany and the health data concerns an Italian citizen. What it means, for a training body delivering workplace-safety courses under the Italian *Accordo Stato-Regioni*, to see the Cyber Resilience Act arrive and realise that its LMS falls within scope. What it means, for a software house producing a back-office application, to prepare for the fact that the revised Product Liability Directive has extended the regime of defective-product liability to software—including certain forms of integrated AI components—and that the regime will apply operationally to products placed on the market after December 2026. What it means to design a DPIA following the template approved by the EDPB last March, only to realise that it is not a form but a documentary genre, to be kept alive alongside the system it describes. These are jobs of translation, not of abstraction. The rules that on the other side of the ocean are painted as obstacles to innovation are, for me, the innovation itself, because they define the perimeter inside which one can design well. I do not say this out of romantic adherence to the European project. I say it because, after implementing these requirements dozens of times inside real systems, you see something an Andreessen op-ed cannot. You see that conformity is not an isolated cost, it is a design pressure. Like all design pressures, it narrows the space of choices and in exchange forces you to do things better, at least within the dimension the rule protects. The PLD, for instance, shifts producer liability for software quality in a way that until yesterday did not exist even as a category. For those who sell serious products this is an administrative nuisance. For those who sold junk while promising it was magic, it is an earthquake. Guess which of the two groups produces the most virulent criticism. One could say, and people do say, that this argument holds for my small Italian shop but not for the technological frontier. The Italian shop is not inventing foundation models, not designing gigawatt data centres, not redefining the paradigm of scientific research. True. But that is precisely why my vantage point seems useful to me, because it tells from very close range what the great Californian narratives never manage to see, namely that the vast majority of software running in the world is not frontier, it is everyday infrastructure. It is the healthcare systems handling our clinical data, the public-administration portals handling our relationship with the state, the back-office systems running small businesses, the training systems that certify legally mandated competencies. It is fabric. European regulation is written above all for this fabric, and the fabric, by definition, needs rules in order to exist as fabric and not as a random pile of threads. ## AI Act, Vance, and the Race {: #ai-act-vance } Let me move on, because there is another theme that deserves to be taken seriously, and that is the AI Act. Here too the concession must be made. The AI Act is a difficult regulation, written at a historical moment when the technology it was meant to regulate was changing every four weeks. It had a complicated gestation, took a mid-course turn when foundation models arrived, and produced in the final text certain asymmetries between obligations on providers and obligations on deployers that operators are still trying to figure out how to apply. There are ambiguities in the codes of conduct on general-purpose systems. There are doubts about how to compute compute-thresholds. There are operational difficulties in conformity assessment for high-risk applications in healthcare, and here I speak from direct experience because Trustie, the platform I work on as CTO-as-a-Service for Umana Analytics, has to wrestle with some of these doubts alongside GDPR and other pieces of European discipline that overlap in not always linear ways. All true. All fair. And it is precisely for that reason that the AI Act is not the end of the world. It is a young rule, in its bedding-in phase, dealing with a sector that is itself young and in its bedding-in phase. The application difficulties are reciprocal, because the technology is in the phase of discovering its own space and the rule is in the phase of discovering its own implementation. This is normal. The same has happened with every transformative technology—industrial chemistry in the early twentieth century, nuclear safety in the second half, medical devices in the 1980s, finance after Lehman. New rules live their first years in a state of iteration. The difference today is that American operators consider it normal for the law to chase technology, while they consider it scandalous for the law to stand up first. The scandal is told in almost religious terms. It is not regulation, it is hyper-regulation. It is not caution, it is cowardice. It is not public interest, it is socialism in legal disguise. Vance, in Paris, last year, gave a speech that will go in the textbooks not for its content but for its tone. He explained, to the European audience, that we are strangling AI with our fears, that we are prisoners of our own due-process scruples, that the future will not wait. It was a speech designed to be shared in forty-second clips. It worked very well for that purpose. It worked less well as an analysis of a rule that, let us recall, does not ban the development of AI but articulates it according to risk levels. The conceptual framework of the AI Act is the same framework with which any industrial civilisation regulates dangerous chemical substances, pharmaceuticals, automobiles, food intended for children. No one is asking Vance to stop thinking that regulation is always excessive—it is a legitimate political position with its own tradition. Only, let him present it for what it is, not as the neutral observation of a neutral observer. There is an argument one hears often that I think deserves a reply. It is the argument of the race. AI is a race, we are told, and Europe is losing it. While we write regulations, China builds, the United States builds, and in five years we will be irrelevant. Fine. I concede this too, in part. On computational infrastructure and venture capital availability Europe is in fact behind, and will be for a long time, and this is a serious problem that would require real industrial policy, substantial public investment, integration of the European capital market, reform of academic labour, none of which we have been seriously discussing for decades. But the race, what race exactly. A race is defined by its finish line. What is the finish line. Having our own version of OpenAI. And then. Having our own version of Meta. And then. That is, having companies that do what, for whom, to obtain what, selling what to whom. The question is not idle, because the companies that Vance's friends propose to us as a model are companies whose value is largely built on a precise assumption: that personal data can be collected and used with minimal limits and that attention-based business models can scale without substantive constraints on child protection. If Europe wants to be the one chasing that model and trying to replicate it, then yes, it is losing. If Europe wants to be the one proposing an alternative, the race is a different race. It plays on different ground. It is won by different rules. And in that case regulation is not a brake. It is the product. ## Brussels Effect and the Stars-and-Stripes Regulatory Wall {: #brussels-wall } I realise this sentence sounds presumptuous, and in part it is. But it is the heart of the matter. The Brussels Effect, which Anu Bradford has been writing about for at least a decade, is not a rhetorical invention. It is a concrete mechanism. When the European Union sets a standard, and when the European market is large enough that it cannot be ignored, global firms end up adopting that standard as default, because keeping two parallel architectures costs more than keeping one. GDPR has been an informal default for years in the design of data-management systems inside companies that operate globally. European accessibility specifications end up being implemented everywhere, because anyone selling even a third of their products in Europe designs a single interface. The CRA will produce a similar effect on software. The PLD will produce a similar effect on product liability. The AI Act will produce a similar effect on the risk classification of automated systems. This is not reverse colonial imposition, it is the ordinary functioning of the market, and it is precisely for that reason that it angers the techno-optimists, because their companies are forced to adapt to rules they did not write. Then there is the regulatory-wall argument. Europe, we are told, is building a regulatory wall that excludes American suppliers. This argument deserves to be taken seriously, because part of it is true and part of it is false, and those who use it usually mix the two. The true part is that some regulations, in particular the Data Act, certain provisions on coordinated cybersecurity, certain rules on sovereign clouds, do have an industrial-policy component, in the sense that they try to encourage the emergence of a European technological offering in critical sectors. This is no mystery, it is written in the recitals, and it is a legitimate activity that every state and every economic area in the world undertakes. China does it openly, the United States does it with the CHIPS Act and the Inflation Reduction Act, with the renewed control over foreign investment, with the export bans on advanced GPUs. The novelty is not that Europe is doing it. The novelty is that it is doing it with a European specificity, based on transparency and accountability requirements, on an explicit concern for fundamental rights. To the eyes of an American investor in the Andreessen Horowitz orbit, that is an anomaly. It is one to the extent that the American investor regards regulatory activity as, in itself, a political aberration. The false part, instead, is the claim that the European regulatory wall is different from any other regulatory wall in the world. Try exporting medical software to the United States without the FDA. Try selling a financial service to American consumers without SEC or FINRA authorisation. Try operating an autonomous vehicle at federal level without engaging the NHTSA. Try selling toys for children without the CPSC. The American system is full of regulatory walls, those walls have been there for decades, and they work very well as barriers to entry for foreign suppliers. When a European company complains about their weight, the standard American answer is "rules are rules, if you want to sell here you adapt". It is exactly the same answer we give today to anyone protesting the CRA, and it has exactly the same legitimacy. Only, we give it from a position of narrative-power asymmetry that places us, from the start, on the wrong side of the argument. ## The Narrative Asymmetry {: #narrative-asymmetry } This narrative asymmetry is the real spectre haunting Europe. Not the Europe that frightens others. The Europe that frightens itself, because the only dominant cultural frame in the tech sector is the one elaborated in California over the last twenty-five years, and that frame considers every regulatory act a failure by definition. From inside that frame, every European rule is a symptom of decadence. Every directive is a sign of stagnation. Every attempt to articulate a different vision of the relationship between technology and citizens is dismissed as the resentment of the loser of the race. It is a very effective frame, and it is very hard to contest from inside European tech, because European tech itself has often modelled itself on American tech, reads its blogs, adopts its tools, absorbs its vocabulary, and ends up judging its own continent through someone else's eyes. Let me push one step further. When I say the Californian frame is hegemonic, I am not doing barstool sociology. I am describing the fact that, at any European conference on digital in 2026, a large share of the technical lexicon, of the virtuous examples, of the interpretive frame comes from American industry literature. It is a fact. From here the problem flows, because when the European regulator tries to write a rule, it has to do so in an intellectual environment populated by operators who have absorbed the adversary's grammar. They are not always aware of it. Often they think in good faith they are being "pragmatic", that they stand on the side of the "facts", that they want to "avoid hyper-regulation". But they are using a vocabulary made elsewhere, for someone else's purposes, and they end up producing, even from European positions, an implicit defence of the model they would like to criticise. The result is that in the corridors of Brussels progressive regulations are debated while in the feeds of Italian founders Sacks's clips circulate explaining how those regulations are an aggression against the free market. The two coexist. More than that, they feed each other. Every rule written in Brussels produces a new round of complaints in San Francisco, every round of complaints in San Francisco produces a new cultural concession from a slice of the European business class, every cultural concession produces, downstream, a political weakening of the next legislative process. ## The Project, and Why It Must Be Named {: #the-project } At this point, after two waves of concession and one of analysis, the reader has probably guessed where I am going. I would like us to be very clear on one thing. The hatred for European digital regulation, the real, visceral kind found in David Sacks's posts, in Joe Lonsdale's interviews, in Balaji Srinivasan's paranoias, in JD Vance's set-pieces, is not a technical disagreement. It is a political position, and a precise political position, and it must be recognised for what it is. That position holds that nation states should retreat in the face of tech companies, that tech companies should enjoy a functional sovereignty equal to or greater than that of states in the territories where they operate, that representative democracy is too slow for the rhythm of innovation, and that in case of conflict it is democracy that must adapt. This is a coherent position, and a position with thinkers, books, manifestos, even refined theoretical elaborations behind it, from Ayn Rand's libertarianism to Curtis Yarvin's neo-reaction by way of right-wing accelerationism drawing on Nick Land, all the way to Thiel's most recent syntheses on stagnation. It is not caricature, even if its popular version is. It is a project. It is worth pausing on this project for a moment, because for a long time it was underestimated in Europe, and perhaps still is. The strand starting from Yarvin, in particular, openly maintains that representative democracy is a dysfunctional system and that it should be replaced by forms of government run as enterprises, by CEOs with full powers, untethered from constitutional constraints. Until ten years ago this was a position regarded as folkloristic even by mainstream American conservatism. In the last five years it has normalised, entered the conversations of Sand Hill Road, found implicit and explicit funding inside Thiel's network, colonised parts of the Republican Party, and ended up sitting inside the White House with a vice president who quotes Yarvin in public without embarrassment. To put it another way, a significant slice of the current American ruling class regards the post-war liberal-democratic order as a failed experiment, and regards its own techno-corporate model as the natural historical successor. In that frame, the European Union is not just a commercial nuisance. It is, literally, an embodiment of everything they want to overcome: a supranational subject that imposes transparency standards on firms, that protects competition, that places limits on the producer's freedom in the name of rights that cannot be bought or traded. For those who think the future should be governed by the best, and that the best are the winners of the market, Europe is a historical enemy. I realise that put this way the matter may sound exaggerated, and that many Italian readers, perhaps not prejudicially hostile to American tech culture, will tell me I am caricaturing in reverse. I am not caricaturing. I am simply taking seriously the things the people in question publish openly on their own profiles. Go and read Marc Andreessen's interviews from 2023 and 2024. Go and look at the techno-optimist manifesto. Go and read Yarvin's 2024 book. Go and listen to the All-In podcast, especially the segments commenting on European regulation. Go and watch Vance's speech at the Paris AI summit in February 2025. I am not reading anything between the lines. It is all above the lines, written with a frankness that, from where we stand, is almost disarming. The only thing that stays between the lines is the political conclusion, and the political conclusion goes like this: democratic authority has no standing to set limits on the activity of tech companies, because tech companies are building the future and democratic authority belongs to the past. Against this project, the European Union, with all its slowness, all its imperfections, all its cookie banner, is in fact the principal contemporary geopolitical obstacle. It is not because it has a plan against American tech, but because its model embeds an assumption the Californian project wants to demolish: the assumption that democratic authority can legitimately set limits on the economic activity of firms. That is all. It is an old assumption, present in the constitutional tradition of every European country and of the pre-Reagan United States, but in the cultural climate of 2026 it has become heretical. Our heresy consists in taking up that assumption again and applying it to digital. Nothing more, nothing less. That is why we are a spectre: because we remind the world, by our very institutional existence, that thinking otherwise is possible. ## Coherent Europe, Misplaced China {: #europe-china } Let me pause to answer an objection I can imagine. But is Europe really that coherent. Are there no internal divisions, no lobbies, no national manoeuvres, no regulatory mess. Of course there are. Europe is a complex political system, with diverging interests among member states, with Germany often defending the interests of its automotive industry even when this conflicts with environmental coherence, with France often trying to promote national champions under the cover of European industrial policy, with Italy often weakly represented technically at the tables that matter, with national governments using hostility to European regulation as a tool for domestic consensus. All this exists. But none of it changes the fact that the regulatory output of the European process is, in the end, coherent with a certain model of the relationship between technology and citizens, and that this model is radically different from the American one, and that the difference is the real object of the conflict. Another objection. And China. China, in the anti-European discourse, is always wheeled out as a *reductio ad absurdum*: you regulate, while China builds, and China will win. This is a rhetorical move so ramshackle that often it is not worth engaging with, but one detail is worth noticing. The Chinese model of digital governance is one in which the state, identified with the Party, exercises a very deep control over platform behaviour, content, data, international flows. Beijing has a level of regulatory intervention over the Chinese TikTok algorithm that would make the DSA look like a kitchen-robot instruction booklet. Yet when the techno-optimists cite China as a model of non-regulation, they do not say so. They limit themselves to citing the speed at which infrastructure is built, the speed at which AI applications spread, the speed at which sites like Temu and Shein are shut down. They skip, with notable elegance, the existence of the state. This is because, deep down, their problem is not the state as such, it is a democratic state that imposes constraints on their friends. Faced with an authoritarian state that imposes generic constraints on everyone while guaranteeing itself an unchallengeable dominant position, they have far less to object to. The point is democracy, not regulation. Regulation is just the form that democracy, in a digital world, takes in legal terms. ## Technique in the Service of Politics {: #technique-politics } I would like to close by stitching some of the fabric back together, because I started by quoting Marx and it is right that the circle should close. The spectre of the Manifesto was a promise of transformation. It was something that, in the eyes of the nineteenth-century ruling classes, represented the possibility that the future would not simply be the continuation of the present. The spectre that today disturbs the dreams of Californian venture capitalists promises no revolution. It promises only that the digital future can also be designed by subjects other than their portfolios, according to principles other than theirs, inside an institutional frame that precedes their model and will survive its eventual crisis. It is a modest spectre, and that is precisely why it is unbearable, because it dismantles the claim of exclusivity that the Californian model has arrogated to itself for a quarter of a century. It dismantles the idea that there is only one legitimate way to do digital technology, according to rules written by a specific community of investors in a specific geographic area of the planet. It returns to technology its status as a plural cultural artefact, subject to plural institutions, contestable and contested. For those who believed they had won history, this is an affront. For those of us who do this craft, on this continent, in these years, the spectre is not a nuisance. It is a compass. It is what tells us, every morning, when we open a pull request or write a tender specification, that technical choices have political consequences and that political consequences deserve to be protected by law. We do not do this because we are decadent. We do it because we have a long historical memory, and we know that technologies without limits, in the previous four hundred years, have produced the exact opposite of the freedom they promised. We do it because we have read Polanyi, we have read Hannah Arendt, we have read the constitutional fathers of our continent, we have read the European jurisprudence on fundamental rights, and from all this material we have drawn a simple conclusion. The market is not a fact of nature. It is an institution. And like all human institutions, it has to be built and corrected over time. Digital is a market. Its rules do not descend from the Silicon Valley sky. We write them too, here, in the middle of a continent that is slowly noticing it has become the strangest place in the world: the place where someone still tries to say that technique should serve politics, and not the other way around. There is one last thing I would like to say, and I will say it in a more personal register, because that is the right register to close in. When I happen to talk about these things with American colleagues, usually within three minutes the moment arrives when I am asked, with a shade of sincere pity, whether I do not feel suffocated, in Europe, by all this bureaucracy. The question is asked in good faith. They genuinely think we live in a kind of regulatory cage that prevents us from building. The most honest answer I can give is that no, I do not feel suffocated. I feel I am in the right place. Because here, at least here, the question "what does this software do to people" is a legitimate question, it is a question that can be put to a board of directors, it is a question that has legal consequences if the answer is bad. Elsewhere the same question is considered, at best, naive. At worst, subversive. There. I prefer the state of affairs in which I can ask it, even if to ask it I have to accept a little more paperwork, a few audits, a few EDPB templates, a few conformity assessments. It is a price. You pay it. It is not a cataclysm. If anything, it is the price of civilisation. **The spectre haunting Europe is us. And we will keep on being it as long as someone, somewhere, still considers technique to be a political question and not a question of pure engineering. That is no small thing. That is no small thing at all.** --- # The Contract's Deception - **URL:** https://margiovanni.it/en/blog/the-contracts-deception/ - **Published:** 2026-05-01 - **Tags:** Compliance, PLD, AI Act, CRA, EU Regulation - **Reading time:** 19 min > On why the software supply contract, as we have known it, has stopped being the central instrument of the relationship between vendor and client — and how much it costs to keep pretending it still is. ## A contract between the wrong people {: #wrong-people } The contract had been signed at the end of 2023, and from the prime vendor's standpoint it was a clean, well-structured contract, with all the safeguard clauses the legal department had insisted on over the years. It clearly specified the subject matter of the supply, set out service levels, fixed penalties for non-compliance, defined the perimeter of vendor liability with standard caps at the contract's annual value, excluded indirect damages, and governed subcontracting through a clause that required the client to approve the main subcontractors and that placed on the client the burden of verifying their adequacy. It had been negotiated for four months, gone through three rounds of legal review on both sides, signed by executives with the necessary powers. The prime vendor, a software house of fifty people, considered it a good contract. The client, a private healthcare company with a million enrolled patients, considered it a balanced contract. For two years the relationship went well. At the end of 2025 a patient suffered harm from something the clinical system should have done and didn't do. The technical cause was traced to a risk-evaluation library the system used to classify intervention priorities. The library had been supplied by a subcontractor approved by the client four years earlier, had been silently updated by the subcontractor itself eighty days before the incident with an algorithm change that no one had communicated to the prime vendor, and no one had requested a documentation update because the subcontractor considered its update routine maintenance. The subcontractor was based in a third country, had no legal representative in the Union, and in the months that followed the lawsuit turned out to be effectively unreachable for judicial notices. The prime vendor reacted to the patient's lawyer's damages request by showing the contract. They argued that the subcontractor had been approved by the client, that the change had been introduced unilaterally by the subcontractor without any communication, that the contract excluded indirect damages and capped liability at the annual value, and that in any case material liability fell on the client as the entity that directly managed the relationship with the patient. The patient's lawyer did not contest any of these contractual points. He simply noted that the contract between vendor and client did not concern him, because he had not signed it, and that his action was based on the new European product-liability regime, under which the prime vendor qualified as the producer of the defective product and was strictly liable toward the final injured party regardless of the clauses agreed with the client. Those clauses, he added, governed recourse between the signing parties, not exposure toward third parties. The contract, in other words, was a good contract between the wrong people. ## The traditional objection {: #traditional-objection } The objection I want to address right away, because it is the most rooted and the most sincere, is the one that comes from traditional lawyers I have worked with over the years. It goes like this: this is all a problem of contract drafting. If the clauses are well-written, if the indemnities are complete, if the subcontracting procedures are rigorous, the prime vendor is protected. It is an objection formally consistent with how contract law has functioned for forty years in software. Until a few years ago it was also substantially true, because the software-producer liability regime was weak, third-party injured-party actions almost always passed through the direct client, and the prime vendor could reasonably expect its exposure to be exhausted within the agreed contractual limits. That era is over. The legal regime now consolidating in Europe between 2024 and 2027, which I have already written about in this series with respect to software-as-written-promise and the specification as the legally relevant asset, introduces a level of liability that operates outside the contract and that the contract can only partly govern. The revised Product Liability Directive, applicable from 9 December 2026, explicitly qualifies software as a product and applies a regime of strict liability to the software producer toward final injured parties. The Cyber Resilience Act, fully applicable from 11 December 2027, introduces digital-product security obligations that bear on the producer along the entire lifecycle and extend to integrated components. The AI Act distributes obligations along the chain of AI-system providers so that the provider of the final system has to ensure that integrated components are compliant. The Digital Operational Resilience Act, applicable from 17 January 2025, imposes on financial entities and their critical ICT vendors supply-chain risk-management obligations that cross contractual boundaries. NIS2, applicable from 18 October 2024, makes the same move for the expanded critical sectors. Each of these acts, taken individually, would be manageable with some contractual adjustment. Taken together, and at their intersections, they define a structure of liability that the supply contract is no longer able to contain. ## The four collapsed assumptions {: #collapsed-assumptions } The traditional contractual model of software grew up in an era in which certain implicit assumptions held, and it has become inadequate because all those assumptions collapsed in the same decade. There was, first, the idea that the vendor's liability toward the client exhausted the vendor's exposure, because the intermediate client absorbed and managed any liability toward third parties. There was then the conviction that software was an object delimited at the moment of delivery, assessable on the basis of a static specification at release. It was assumed, third, that the supply chain was essentially bilateral from a legal standpoint — that each link could be governed by a contract between two parties without having to worry about the chain's overall dynamics. And it was assumed, finally, that the liability regime would remain stable over time, enough to make it reasonable to sign multi-year contracts under the legal framework in force at signing. These were assumptions that looked like laws of nature of software contracting until around 2020, and that in retrospect turn out to be merely the characteristics of a specific legal era. The first assumption was eroded by the broadening of the active legitimacy of third-party injured parties under the new PLD. Under the old product-liability regime, the final injured party could act against the producer, but in practice actions mostly went through the reseller or commercial integrator, and the software producer, until 2024, enjoyed interpretive uncertainty about whether it even fell within the definition of producer. The new Directive, by including software explicitly in the definition of product and introducing defect presumptions that lighten the injured party's burden of proof, makes the software producer's position much more exposed. It also adds a documentary disclosure mechanism allowing the judge to order the vendor to produce the technical documentation of the product, and to presume defect in case of non-disclosure. From that moment the injured party's lawyer no longer needs to go through the intermediate client, and can act directly against the prime vendor of the software that caused the harm, ignoring entirely the contractual clauses between vendor and client, because those clauses govern a relationship to which the injured party is a third party. The point is written explicitly into Article 15 of the Directive, titled "Exclusion or limitation of liability", which requires Member States to ensure that the liability of the economic operator toward the injured party cannot be limited or excluded either by contractual clauses or by national-law provisions. It is a short, technical article, but it is the keystone of the entire structure, because it transforms what looked like contractual room for manoeuvre into a zone of legal indisposability. The second assumption was eroded by the Cyber Resilience Act and the AI Act, both of which introduce security and risk-management obligations bearing on the producer along the entire product lifecycle, not only at the moment of delivery. Software has stopped being an object delimited at the time of delivery and now stands as an object continuously exposed to the regulatory regime. Every update, every modification, every integration of new components can be requalified as a substantial modification that brings the product back within the regime, even if the product was placed on the market in an earlier era. The prime vendor that delivered the system in 2023 did not unload its liability in 2026 when a third-party library integrated into that system stopped being maintained and developed security vulnerabilities. Liability simply shifted to the maintenance plane, and the vendor that did not update is a vendor that has failed a continuing obligation, not an obligation limited to the moment of original delivery. The third assumption, the bilateral nature of the supply chain, was also eroded by the introduction of liability chains that cross bilateral contracting. Under the DORA regime, the financial entity must map and manage its ICT third-party risk along the whole chain, and when a vendor is qualified as critical the obligations extend so that the contractual clauses between the financial entity and the critical vendor must contain specific elements imposed by the Regulation, regardless of the parties' will. The CRA, for its part, requires the producer of a digital product to guarantee the security of the integrated product, and that guarantee is not exhausted in contractual relationships with its subcontractors, because the regulator assesses the product as a unitary whole regardless of the internal composition of the supply chain. The revised PLD adds a further complication, providing that the substantial modifier of a product can themselves become liable as the producer, and this opens a circular liability dynamic in which the prime vendor, the intermediate integrator, the subcontractor and the final user can be sued under different titles for the same harm. NIS2 and the AI Act complete the picture, extending analogous obligations to expanded critical sectors and to high-risk AI systems respectively, with the result that every chain segment is today crossed by at least two or three overlapping regimes that bilateral contractual clauses cannot reconcile. The fourth assumption, regulatory stability, is the one whose erosion produces the most insidious effects, because multi-year contracts signed today under the current framework will be applied tomorrow under a framework that will have evolved. The vendor signing a six- or seven-year contract in 2026 will find itself executing it in 2032 or 2033 under regimes that may have changed significantly by then, because the PLD provides for a revision clause, because the CRA will be the subject of guidelines that will modify the interpretation of entire sections, because the AI Act has already been described as an open construction site by the Commission itself. The multi-year contract under the traditional model presupposed a regulatory inertia that no longer exists. ## Four phenomena the contract cannot address {: #four-phenomena } Each of these four phenomena has practical consequences the traditional contract cannot address. Joint liability of critical-component suppliers, introduced in different forms by the PLD and the CRA, means the prime vendor answers for defects of integrated components even when subcontractors are non-compliant or unreachable. The contractual clauses that govern recourse against subcontractors remain valid between the signing parties, but do not shift liability toward the final injured party, who can always act against the prime vendor as the accessible and patrimonially most solid link of the chain. The prime vendor that wanted to shift the risk onto the subcontractor through contractual clauses ends up having to absorb it, and can only later try to recover by way of recourse — assuming the subcontractor is still in existence, solvent and reachable. Documentary disclosure obligations introduced by the new PLD are the second phenomenon, and they are particularly insidious because they turn the vendor into a subject who must show the judge their own technical documentation, even when that documentation includes design choices, security configurations, training datasets, architectural decisions the company would consider trade secrets. The judge must balance the right to disclosure with the protection of trade secrets, but in practice the vendor finds itself exposed to documentary requests the contract with the client cannot limit, because the contract does not bind the judge or the injured party. The vendor may have agreed with the client on the inaccessibility of the documentation, but if the injured party requests production, the vendor must produce, and refusal to disclose generates a presumption of defect under Article 10 of the Directive. Defect presumptions, which the individual vendor cannot rebut alone, are the third phenomenon, and the subtlest of the four. The new PLD provides that the judge may presume the defectiveness of the product when the product is technically or scientifically complex and proof of the defect would be excessively difficult for the injured party. For complex software systems, especially those integrating AI components, this presumption activates almost automatically, and the burden of rebutting it falls on the vendor. Rebutting the presumption requires demonstrating that the product at delivery did not present the defect, or that the defect was introduced later by modifications outside the vendor's control. Both demonstrations require detailed historical documentation of the system, and the vendor that did not maintain such documentation finds itself unable to prove anything, and therefore succumbs to the presumption. Substantial-modifier accountability is the fourth phenomenon, and the one that most radically breaks the bilateral contract structure. When a client or intermediate integrator substantially modifies a software product supplied by a third party, they can themselves become liable as the producer of the modified product, and this opens a dynamic in which the original vendor may no longer be liable for the product as modified, but the modifier may not have the competence, documentation and structure to assume the liability they have materially assumed. The result is a grey zone of liability where the injured party chooses whom to sue based on patrimonial and procedural accessibility, and where the parties involved volley liability among themselves with often paradoxical outcomes. ## The settlement that doesn't arrive soon {: #settlement } One could object, and someone will, that all this is exaggerated and that judicial practice will find a way to bring order back to the system. It is an objection that deserves respect, because judicial practice has always had this stabilising function, and because European regulations, once translated into national case law, often lose the rigidity they have on paper. The answer I am willing to give, after observing how practice is moving in the European jurisdictions where the first cases are emerging, is that the settlement will come, but it will come in five or seven years, and in the meantime the exposure window for vendors operating under traditional contracts is very wide. The first relevant rulings on software-producer liability under the new PLD will not arrive before 2028, because the regime applies to products placed on the market after 9 December 2026 and cases have minimum lead times of a year and a half. From then it will take another three or four years for consolidated case law to form. Meanwhile, every vendor operating with old-model contracts is accumulating retroactive exposure, because many of the systems being delivered today will still be in production when the case law has settled, and they will be assessed against the criteria that have consolidated by then. ## The sectors that came before us {: #sectors-before-us } It would be dishonest not to recognise that there are sectors where these dynamics have existed for decades, and where supply contracts have a structure that recognises the inadequacy of the traditional bilateral model. They are sectors that have lived under tight product-liability regimes long before general-purpose software, and they have developed contractual practices worth studying. Civil aviation is one, and aircraft-component supply contracts have always incorporated obligations of documentary traceability, third-party certification, coordinated handling of non-conformities, joint liability toward regulatory authorities. Medical devices are another, and supply contracts for medical-device components include quality-framework agreements that go beyond the single commercial contract and govern the relationship between the parties as a regulatory relationship as well as a commercial one. Automotive is the third, especially after the introduction of the ISO 26262 functional-safety standards for vehicle electronic systems, and software supply contracts for automotive have for about a decade incorporated chain-of-liability clauses that recognise the impossibility of confining exposure within bilateral relationships. What is happening in general-purpose software is convergence — accelerated by the European regulatory package — toward the model these sectors already practise. The difference is that aviation, medical devices and automotive have had thirty years to build their contractual practices, internal competencies, sector standards and structured supply relationships. General-purpose software has five or seven years to do the same thing, and must do it while continuing to operate in markets where most competitors still reason within the old model. It is an asymmetric transition, in which whoever moves first pays a positioning cost that whoever moves later does not pay — but whoever moves first also builds capacity to absorb the subsequent regulatory evolutions that whoever moves later will have to acquire at consolidated-market prices. ## Five operational dimensions {: #five-dimensions } On an operational plane, the transformation of the software supply contract has five dimensions to be managed simultaneously. The first is the move from contract-as-document to contractual documents as ecosystem. A software supply contract under the new regime is not exhausted in a single document valid until renewal, but constitutes a system of related documents including the master contract, service-level annexes, security annexes, quality agreements similar to those of medical devices, personal-data processing agreements under GDPR Article 28, coordinated vulnerability-handling agreements, mutual supply-chain disclosure agreements. Each of these documents lives with its own update cycle, and the master contract becomes the framework that holds them together, not the container of all clauses. The second dimension is the transformation of the limitation-of-liability clause. Traditional clauses that cap vendor liability at the contract's annual value, or that exclude indirect damages, remain valid between signing parties but produce no effects toward third-party injured parties. For the vendor this means actual exposure is exposure toward the final injured party, not the one agreed with the client, and insurance policies must be sized on that actual exposure, not on contractual caps. Insurance practice in the sector is currently confused, because companies are redefining product-liability products for software producers in light of the new regime, and premiums are rising non-linearly. For mid-size Italian software houses, the insurance cost of product liability is becoming a significant balance-sheet item, where until a few years ago it was a negligible one. The third dimension is the rewriting of subcontracting clauses, which must move from a model in which the client approves the main subcontractors at signing to a model in which there is a continuous procedure of evaluation, monitoring and disclosure of subcontractors throughout the contract's duration. The prime vendor must be able to demonstrate at any moment the composition of its supply chain, must be able to produce the SBOM under the CRA, must be able to respond to audit requests from the client or the regulator, must manage situations in which a subcontractor exits the market or ceases maintenance of a component. All this requires supply-chain management tools that the traditional contractual model took for granted and that today become continuous operational activity. The fourth dimension is the introduction of clauses on coordinated handling of vulnerabilities and security incidents. Under the CRA, under NIS2 and under DORA for the financial sector, vendor and client both have reporting obligations within tight time windows, and meeting these windows requires coordination that the contract must govern operationally, not just formally. A clause that says "the parties shall cooperate in incident handling" is useless if it does not specify who notifies, within what time, through which channels, with what severity thresholds. The clause must be almost a contractual mini-runbook, and its quality is measured in its ability to function during an actual incident, not in its legal elegance. The fifth dimension is the subtlest, and concerns product-lifecycle management. Under the CRA the producer must declare the product's support period and maintain it for that period, and must manage the product's exit from the market so that users are informed and have transition paths. The software supply contract must govern this aspect, because the prime vendor is exposed toward the final injured party even after the end of the contractual relationship with the client, and because end-of-support management becomes a critical moment when residual liabilities can materialise. The traditional clauses of "perpetual licence" or "no warranty after termination" produce no effects toward third-party injured parties, which means the vendor must manage the product lifecycle as a function exceeding the duration of the contract. ## Disclosure: eighteen months of rewriting {: #disclosure } I have to be transparent on one point, because on this subject I am describing transformations I am living through first-hand. The revision of our supply contracts, inside the company where I work, is an activity that has been underway for eighteen months and has not yet arrived at a stable form. We are working with our reference law firm to rewrite the master contract for software services, and what is coming out is far from the clean, elegant contract we hoped to produce — it has the form of a more articulated system of documents than its predecessor, with annexes that exist for different reasons and that cannot be reduced to a single template. Some clients accept the new structure; others find it needlessly complex and ask to go back to the old model. Market pressure toward contractual simplicity is still strong, and in some cases we ourselves accept to sign old-model contracts when the client imposes it, knowing we are accumulating retroactive exposure. It is a choice we make for immediate commercial reasons, and that I have called *compounded exposure* in our internal conversations, because it accumulates non-linearly as the client portfolio grows. ## An opportunity, not just a burden {: #opportunity } I also want to say, because otherwise the piece would sound like a pessimistic forecast about the Italian software industry, that the transformation I am describing is an opportunity before it is a burden. Mid-size Italian software houses that decide to build contractual competencies coherent with the new regime, to pair delivery work with continuous documentary maintenance and supply-chain management, to train internally the hybrid figures I described in the previous piece of this series, will have, in five years, a competitive position hard to erode. Software houses that keep signing traditional contracts in the hope that the regulatory framework won't really apply, or that national case law will soften it, will find themselves exposed and will have to close the gap at far higher costs than today's sustainable ones. It is one of those situations in which the decision not to decide is the most expensive of all, because time works against those who do not move, and because every contract signed today under the old model is a liability that will reveal itself in a few years, when the cases that the PLD has designed as standard scenario start appearing in the news sections of specialised media. ## The centrality that dies {: #centrality-that-dies } Putting the four pieces of this series together, the general argument I am trying to build is the following. Software, as an industrial and as a legal object, is changing nature before our eyes, and the engineering and commercial culture of the sector is not adapting at the speed the moment requires. The first piece, *[Cruft, Not Patina](/en/blog/cruft-not-patina/)*, argued that software does not know how to age the way material objects do. The next, *[The Specification Debt](/en/blog/the-specification-debt/)*, shifted attention to the fact that the written specification has become the legally relevant asset of the product and that our industry lacks the tools to keep it alive. Then came *[The Rise of the Compliance Engineer](/en/blog/the-rise-of-the-compliance-engineer/)*, devoted to the hybrid professional figure emerging to oversee the gap between engineering and regulation. In this fourth piece the argument shifts from the plane of product and labour to the plane of the relationship between organisations, and the thesis is that the supply contract — the classic legal instrument of that relationship — is becoming one instrument among others within a wider, more structured relationship that traditional contract law can only partly govern. The software supply contract is not dead, and nothing of what I have written should be read as a forecast of its disappearance. What is dead is its centrality, the idea that the relationship between vendor and client can be exhaustively described by a bilateral document negotiated at the start and updated at renewals. The contemporary relationship is multilateral, regulatorily loaded, dynamically exposed to third parties the contract does not bind, and crossed by continuous documentary obligations the contract can only summarise. Thinking that better-written clauses are enough is an understandable, human nostalgia — and also the fastest way to accumulate exposure while believing oneself protected. Clauses still matter, and matter more than before, but they matter as elements of a wider device that contains and exceeds them. **The contract, as we have known it, has become the gentle deception that lets software vendors believe they know what they are exposed to.** Traditional contracts will keep being signed for some years more, because the market moves more slowly than the law, and because the old model is familiar and the new ones are still forming. But whoever keeps signing traditional contracts in the next five years is signing, alongside the contract, a quiet bet that things will not really change. It is a bet that my generation of those who make software in Europe will probably lose, because things are already changing — and what today looks like an excess of caution from the few who are moving will turn out, in a few years, to be the prudential minimum that was required from the start. --- # The Rise of the Compliance Engineer - **URL:** https://margiovanni.it/en/blog/the-rise-of-the-compliance-engineer/ - **Published:** 2026-05-01 - **Tags:** Compliance, Work, Software Development, AI Act, Labour Market - **Reading time:** 16 min > On the figure now emerging from the gap between software engineering and European regulation, and on why almost no one is noticing in time. ## The confused job posting {: #confused-posting } The job posting had appeared in February on one of those boards where mid-size Italian companies look for technical people without being too sure what they are looking for. The position title was "Senior Software Engineer with Regulatory Background", and there was already something strange about it, because in Italian a phrase like that does not mean anything precise. The body of the ad clarified little. It asked for at least five years of backend development experience, preferably Java or Python, knowledge of Kubernetes, experience with CI/CD pipelines. Up to here, a normal senior developer profile. Then the text changed register and started asking for in-depth knowledge of the GDPR, command of the AI Act regarding high-risk systems, the ability to draft DPIAs and risk assessments, experience with compliance frameworks such as ISO 27001 and SOC 2, the ability to interface with external auditors. The salary indicated was that of a senior developer at market rate, with a small unquantified premium for the regulatory competencies. I read that posting ten times trying to understand who they were really looking for. A person like that, with that combination of skills, does not exist in Italy in meaningful numbers today, and when they do exist they cost twice what the company was offering. Whether the company knew this or not, hard to say. What is certain is that they had a real need, because they were about to deliver a system to a regulated client and did not have the right person in-house. They had senior developers who could not read a European Regulation, an in-house lawyer who could not read code, and an external compliance consultant who could speak with one of the two but not the other. The person they were looking for existed in their head as a translator between worlds that were not speaking to each other, but that person did not yet have a stable name as a trade. The posting was reissued in March under a different title, "Compliance Engineer", with no other changes to the body. Then it disappeared. I do not know whether the company found someone or gave up. What I do know is that postings like that, with minimal variants, I am seeing one or two a week passing on Italian boards, and many more on European ones. I am watching a craft looking for its name, one that will find it in the next two or three years because it has no alternative. ## The technological objection {: #technological-objection } The objection I want to address right away, because it is the most serious and because it always comes from C-levels who are minding the costs, is the technological one. It goes like this: all the work you describe will be done by AI in three years. An agent will read the system, read the regulation, produce the mapping, update the documentation, flag the inconsistencies. There is no need to build a new professional figure — wait for the technology to mature. It is an objection with apparent plausibility, and it is widespread enough to deserve an answer. The answer is that AI will do ninety per cent of the mechanical work, and I am not making a cautious-cautious forecast here, I am describing what it already does in contexts where it is applied seriously. What remains, the ten per cent, does not correspond to the residual ten per cent we presume will vanish as models improve. It is the interpretive and political ten per cent, and it is precisely the part that requires a human being who understands at the same time the system's architecture and the Regulation's structure, and who knows how to choose how to align the two when the letter of the rule and the reality of the software come into tension — which happens far more often than regulators would care to admit. Inverting the perspective, in fact, it is precisely AI that makes the compliance engineer figure economically viable. Without generative assistance, the volume of documentation required by the new European regime would be unmanageable for anyone who is not a multinational with a dedicated team of thirty. A software house of ten or fifteen cannot afford two full-time figures on this function, and indeed today it does not have them. But with well-configured AI assistance, one well-trained person can oversee the compliance of all the company's projects with a quality that five years ago would have required a small team. The question to ask, then, is not whether AI will replace the compliance engineer — it is the exact opposite. Without AI, the compliance engineer would not exist as a role accessible to SMEs; it would only exist as a department in big companies. With AI, it becomes the synthesis figure that allows even mid-size organisations to operate in regulated markets without externalising their regulatory intelligence. ## An institutional distance {: #institutional-distance } Reconstructing how the conditions for this figure to emerge came about deserves some detail, because its genesis is typically Italian and European, and understanding the genesis helps understand why the trade has the shape it has. The starting point is an institutional distance between two academic and professional traditions that in Italy, more than elsewhere, have never seriously met. On one side computer science engineering, formed in engineering faculties, with historical attention to how software functions as a technical object. On the other side law, formed in law schools, with historical attention to norms understood as texts to be interpreted. The two traditions do not speak to each other — not because there are no people of good will trying to build bridges, but because curricula do not include the bridge as a structured object of study. The engineer leaves university knowing how to write code and design systems, but with an exposure to law that, at best, is limited to a one-semester course in IT law, often delivered by a teacher who studied software as a phenomenon and not as a practice. The lawyer leaves university knowing how to interpret norms, but with an exposure to software that, at best, is limited to a few conferences and a handful of popular manuals. This distance was not a serious problem as long as software was assessed on functional, performance and commercial criteria. When software started to be assessed also on regulatory criteria, the problem exploded, because organisations found themselves having to certify to the regulator that their system met obligations that neither their developers nor their lawyers fully knew how to translate. The GDPR, applied from May 2018, was the first serious test. For years the response of Italian companies was either to outsource compliance to specialised consultants — who produced adequate documents but rarely went into the code — or to appoint an internal or fractional Data Protection Officer who spoke with the lawyer but little with engineering. It worked badly, but it worked enough, because the GDPR alone was not enough pressure to bring a new professional figure into being. The pressure needed has arrived in the past three years with the accumulation of acts in the European digital regulatory package. AI Act, Cyber Resilience Act, revised Product Liability Directive, NIS2, Digital Operational Resilience Act for the financial sector, Data Act, European Accessibility Act. Each of these regulations, taken individually, would have been manageable with traditional methods. Taken together, and in the compressed times in which they have entered or are entering into force between 2024 and 2027, they have made the situation structurally different. Organisations producing software for the European market have found themselves with documentary, risk-assessment, security, traceability and accountability obligations that multiply and intersect in ways that demand an integrated view. The external consultant who produces one document at a time is not enough. The in-house lawyer who does not read code is not enough. The senior developer who explains the system to auditors twice a year is not enough, and neither is the combination of the three figures coordinating in periodic meetings — because coordination by periodic meetings is exactly the device that generates specification debt. You need someone who does only this, and does it every day, inside the organisation. ## Three slices into one person {: #three-slices } On a taxonomy-of-roles level, what is happening is that the compliance engineer is absorbing slices of work currently distributed across three distinct roles. First slice, the senior dev who today explains the system to auditors. It is a figure that exists in almost every organisation of a certain size, almost always a senior who has known the system for years and gets pulled out of development projects to do presentations to third parties. They do the work reluctantly because it is not what they were hired for, they do it with mediocre quality because they lack the documentary tools to do it well, and they fill their time with activities that drain value from the main role. Second slice, the architect who today translates regulatory requirements into design choices. This figure too is present almost everywhere, usually an architect who self-trained on regulation because someone had to, and who does it in the time left over from technical decisions, with the result that their design choices are excessively cautious where the regulations are ambiguous, and that they often over-regulate the system, generating useless operational friction. Third slice, the in-house lawyer or compliance consultant who today tries to read code without knowing how. This is the most frustrated figure of all, because they have formal responsibility but lack the technical tools to exercise it, and they end up asking devs things devs cannot translate into practice, generating a communicative loop that produces formally correct but substantively inert documents. ## A typical day {: #typical-day } The compliance engineer takes the three slices and brings them together in one person, with dedicated time and dedicated tools. A typical day, in a mid-size company that produces software for regulated clients, starts with a review of the week's tickets to identify which code changes impact compliance. It continues with a working session on a specific pull request to discuss with the architectural reviewer the effects of a change on personal data flows. It carries on with a call to the in-house lawyer to clarify a contractual clause the client proposed that might come into tension with our technical security appendix. The afternoon goes to updating the DPIA of project X, because the third-party vendor changed hosting data centre and that modifies the cross-border flow mapping. It closes with a sprint planning meeting where the compliance engineer presents the documentation requirements for the next three tasks, so the team knows what to produce in addition to the code. None of this is legal in the strict sense, none of it is technical in the strict sense. All of it is techno-legal, and it is the hybrid nature of the work that justifies the figure. ## Two degenerations {: #two-degenerations } The risk of the role, which has to be named explicitly because it is the main risk, is that it can degenerate in two pathological directions, both already observable. The first degeneration is the compliance engineer as bureaucratic gate-keeper who blocks releases. It is the most visible and most damaging version, because it pits the compliance presence against delivery, and once that opposition stabilises the organisation loses both speed and compliance quality. The gate-keeper produces ever-longer checklists, demands ever-more articulated approvals, delays releases for reasons that look like formalisms to developers, and ends up being perceived as a cost to minimise rather than an investment to preserve. The second degeneration, opposite in symptoms but identical at the root, is the compliance engineer as policy decorator who signs documents without reading the code. You see this more in companies where the figure is introduced because a regulated client or an imminent audit requires it, and where the role is given to a person chosen for their willingness to bear documentary loads rather than for their actual ability to read the system. The decorator produces formally perfect documents, fills every required field, gets management to sign, and meanwhile the real system evolves in directions the document no longer describes. It is exactly the condition I called specification debt in the previous piece of this series, and that the compliance engineer should counter but instead contributes to generating if interpreted poorly. Both degenerations have a common cause, which is the lack of structured training for the figure. When a trade has no academic reference path, everyone constructs it from their own provenance. The developer who becomes a compliance engineer brings the bias that compliance is a service function of the code, and tends to underestimate the legal consequences of technical choices. The lawyer who becomes a compliance engineer brings the opposite bias, that code is a service function of the norm, and tends to over-regulate with heavy technical and organisational consequences. A third trajectory, increasingly frequent, is that of the sysadmin who becomes a compliance engineer through natural affinity with documentary practices, and tends to build certification pipelines that live parallel to and never joined with the application development cycle. There is also a fourth trajectory, rarer but more promising, of those who arrive at the figure through mixed paths — for instance, those who have worked for years in product management on regulated products and have developed sensibility for both sides of the fracture. None of the first three trajectories produces, on its own, a compliance engineer up to the task. They produce half-figures that work in some companies and some contexts and fail elsewhere. ## A real bicameral competence {: #bicameral-competence } What would be needed, and does not exist today, is a structured training path that starts from the assumption that the discipline is genuinely two-headed, engineering and legal at once, and that both halves require solidity, not superficiality. The compliance engineer's software engineering is distinct from the simplified, generalist version found in popular courses, and demands real software engineering, with command of distributed architectures, application security, code lifecycle, DevOps practices, data modelling. The compliance engineer's compliance, likewise, goes beyond the operational and checklist-driven version found in business school courses, and demands real European jurisprudence, with command of the Regulations, ability to read recitals, knowledge of Court of Justice case law, ability to anticipate the interpretive evolution of national authorities. A person who has all this is not formed in a six-month master's, they are formed in some years of work guided by serious mentors, and serious mentors are still few. The Italian university, from this point of view, is structurally late. Computer science engineering degrees, even the best ones, dedicate to regulatory compliance an amount of hours that is risible compared to the weight this discipline has assumed in the market. Law degrees, even the best ones, dedicate to software-as-regulated-object an amount of hours that is risible compared to software's centrality in the economy. There are post-graduate master's programs that try to fill the gap, and some are well done, but they are master's — that is, six- or twelve-month complementary trainings that do not build the double competence from the ground up, they overlay it on a pre-existing competence. The result is that companies looking for compliance engineers do not find them trained by the university system and have to self-train them internally, with the time and cost that entails. It is a classic market distortion, where demand exists and supply has not yet consolidated, producing positions vacant for months and volatile salaries. ## Big consultancies and the gap {: #big-consultancies } The market segment that has already noticed the phenomenon, and is moving to occupy it before the others, is the big consultancies. It is the most visible and most ambivalent phenomenon, and it has to be assessed without moralism but with realism. Big consultancies have commercial muscle, presence with corporate clients, industrial processes for deploying professional figures, and budgets to produce internal training at speeds universities cannot sustain. They are building "compliance as a service" offerings that package the compliance engineer's work in saleable bundles. The problem, and I say it without naming any specific actor because the problem is categorical and not individual, is that the version of the figure big consultancies are building is almost always the policy-decorator version. It is the most commercially scalable, easiest to sell, easiest to industrialise. The compliance engineer as a real techno-legal translator, the one who enters the code and modifies architectural choices, does not scale well in the consultancy model, because it requires continuity on the client that the project-based model typical of big consultancies does not easily provide. The gap that big consultancies will not manage to cover, and that mid-size software houses could cover, is the compliance engineer internal to organisations producing software for regulated clients. Mid-size software houses, between ten and fifty people, are in a structurally better position to build this figure than either big consultancies or the regulated companies themselves. They have the technical proximity to the code that consultancies lack, the plurality of clients that regulated companies lack, the size that lets them sustain a dedicated person without externalising. What many Italian software houses do not have, and that is why they are not moving fast enough, is the awareness that the transformation is already underway and that whoever covers it first will gain a positional advantage hard to erode in the following five years. On an operational level, building an internal compliance engineer means investing twenty-four to thirty-six months on a person who already has half the necessary skills. The typical candidate is a senior developer with curiosity for the regulatory dimension, an architect with sensibility to security and privacy, or a product manager with a certain taste for formalisation. The growth trajectory includes shadowing on real cases, systematic reading of European regulations in compared language versions, participation in audits with clients, drafting of DPIAs and risk assessments under supervision, building of documentary repositories, gradual exposure to in-house lawyers and external consultants to absorb vocabulary and legal practices by osmosis. It is a significant investment for a small software house, and it is exactly the kind of investment that produces a competitive asset hard to replicate. ## Disclosure: a trajectory I inhabit {: #disclosure } I have to be transparent, because on this topic I am describing a phenomenon I am part of, and the analysis would be dishonest if I did not declare it. The trajectory I am describing is the one I am living personally in my own company, and a non-secondary part of my work in the past two years has been building Oltrematica's compliance engineer in-house, occupying that position directly while at the same time trying to formalise it for whoever will come after. I am not writing this piece as a neutral observer of someone else's trend, I am writing it as someone who is inhabiting it from inside and who, after some years of practice, has the impression of having understood the shape the figure is taking and of having something to say about what works and what does not. I am not particularly happy or particularly proud of this trajectory. It is simply what the moment demands of those who want to keep making software for regulated clients without externalising their regulatory intelligence, and I have accepted it the way one accepts transitional duties, knowing that in ten years the figure will be obvious and that today it has to be built by groping. ## Connection, and a forecast {: #forecast } There is a direct connection, and it is worth making explicit, between the figure I am describing and the two previous essays in this series. In the piece I called *[Cruft, Not Patina](/en/blog/cruft-not-patina/)* I argued that software does not know how to age, because the drift between code and the environment in which it runs erodes it faster than engineering culture can metabolise. In the piece that followed, *[The Specification Debt](/en/blog/the-specification-debt/)*, I argued that the specification of software ages even worse than the code, because the continuous practice that would keep it alive is missing, and that the European regulatory framework is loading this ageing with legal consequences that did not exist before. The compliance engineer is the figure whose trade is precisely fighting specification debt day by day, keeping the specification aligned with the system as the system changes, and doing so with the bicameral competence that lets one fall neither into document formalism nor into code inertia. It is the person who, in an organisation that produces software, oversees the alignment between written promise and observed behaviour, knowing that under the new regime the coherence between the two planes is what the judge will assess if the day of assessment ever comes. The piece closes with a forecast that is also a call to action for anyone reading from inside an organisation that makes software in Europe. In five years, around 2031, the compliance engineer will be obvious. There will be university degrees, there will be serious certifications, there will be professional bodies in some form, there will be regular columns in specialised media. What remains to understand is not whether it will happen, but only how fast. Organisations that are building it now, by hand and out of necessity, will have a structural advantage over those that wait for market maturity. The advantage plays out beyond the commercial plane — it is mostly cognitive, because whoever inhabits the role today is also defining the practices that will become standard, and whoever defines the practices defines them to suit their own way of working. **The compliance engineer figure is not a niche, it is the role redesigning how European software is produced under the new regulatory regime.** It is happening slowly, in silence, in confused job postings looking for people who do not yet exist with titles that change month to month. When the postings find their stable name, and that will happen soon, the industry will split between those who invested in this figure in time and those who will have to import it at consolidated-market prices, three times as expensive. Anyone reading from inside a mid-size Italian software house probably has, in the company right now, the right person to train. It is a senior dev with their head sideways on regulations, or an architect who started reading the GDPR alone out of curiosity, or a sysadmin who took documentation to heart because no one else was looking after it, and in some cases a more hybrid figure arrived through mixed paths that fit none of the three classic trajectories. Recognising them and giving them an explicit mandate, investing time and structured training, is the managerial decision that will produce the most compounded value in the next five years. Not because the figure is fashionable. Because without it, in a few years, making software for regulated clients in Europe will become a craft that Italian software houses can no longer afford. --- # The Specification Debt - **URL:** https://margiovanni.it/en/blog/the-specification-debt/ - **Published:** 2026-05-01 - **Tags:** Compliance, AI Act, PLD, Technical Debt, Philosophy OF Technology - **Reading time:** 19 min > On why the document that certifies the system ages worse than the code that implements it, and why the next generation of civil software-liability cases will be fought over the specification. ## The clinical audit {: #the-clinical-audit } There are documents that get opened only at the wrong moments. The DPIA for the clinical-triage system was signed in April 2024 and filed in the compliance folder, from which it never came back out, the way no DPIA ever comes back out of the compliance folder. Eighteen months later, someone opens it. Not a lawyer — a consultant who has come in for a security audit, opening it for routine reasons, because he wants to verify that the declared measures match the implemented ones. The document describes a system that uses a deterministic scoring model, trained on a closed dataset, with explicit rules for classifying the level of urgency. The processing purposes are four. The legal bases are mapped to the correct recital of the Regulation. Data subjects' rights are listed one by one with the operational procedures to exercise them. Cross-border transfers do not exist, because everything stays in the vendor's European data centre. The consultant reads, takes a few notes, then looks up and asks the CIO if he can see the system in operation. The system in operation is a different one. Three months after the DPIA was signed, the vendor replaced the deterministic model with a neural classifier trained continuously on the last six months of clinical data. The dataset is no longer closed. The classification rules are no longer explicit. The official purposes are still four, but a fifth function has been added at the request of the emergency department, and it is a function the DPIA does not contemplate. Cross-border transfers continue not to exist until one day they do, because the vendor switched hyperscaler and now a portion of the traffic passes through an Irish data centre operated by a US-based subsidiary. None of this is documented elsewhere. The system works. Users are happy. Internal audits pass because they limit themselves to verifying that the system exists and produces coherent output. The consultant turns to the CIO and asks who authorised the fifth function. The CIO replies that it was an urgent request from the emergency lead, handled within a week, with the vendor releasing to production the following Thursday after a staging test. There is a Jira ticket tracking the change, a pull request approved by two reviewers, an internal changelog. Everything in order on the operational plane. The consultant asks whether the DPIA was updated. The CIO looks at him with the expression of someone who never thought it was necessary, because the DPIA belongs to a different circuit, managed by a different person, in a different folder, on a timeline that has nothing to do with the release timeline. The consultant closes the DPIA and stops calling it a DPIA. He calls it a *ghost specification*, because it describes a system that exists only on signed paper. ## An ordinary condition {: #ordinary-condition } The ghost specification, contrary to common belief, is an ordinary condition. Anyone who has worked in an organisation that builds software for a regulated client, or for itself under a regulated regime, knows that between the document describing the system and the system actually in operation, after a few months, a distance opens that grows every week and that nobody has been mandated to close. Not because anyone is lying. Because code has a metabolism the specification does not have, and because the lifecycle of the specification, in the software we actually make, is not managed by any tool comparable to those we have for code. The objection one usually hears against this point is reasonable, and it should be addressed before going further. The objection says: code is the real specification. Documentation is a simplified projection of the system's behaviour, and it is late by definition, so the only sensible strategy is to keep the code in good order and accept that the rest is literature. It is the *code as documentation* principle in slightly more sophisticated form, and it has governed software's engineering culture for at least twenty years. It worked because it rested on an implicit assumption that no longer holds — namely, that software was judged on the basis of what it does when it runs. ## The new evaluative status {: #new-evaluative-status } Software, under the legal regime now consolidating in Europe between 2024 and 2027, is no longer judged only on what it does. It is judged on what it promised to do, and the promise lives in the written specification, not in the executed code. The revision of the Product Liability Directive, adopted at the end of 2024 with a transposition deadline of 9 December 2026, explicitly included software in the notion of product. Which means that the producer of software is liable for damages caused by defects in the product under a strict-liability regime. On this point I have already written an essay titled *[Mrs. Donoghue's Last Bottle](/en/blog/mrs-donoghues-last-bottle/)*, returning to the founding case of producer liability in English law of 1932 and projecting it onto contemporary software. What I only sketched there, and want to bring into focus here, is the epistemological consequence of the new regime. The notion of defect, under strict liability, does not coincide with the bug. It coincides with the gap between what one could legitimately expect from the product and what the product actually did. Legitimate expectations, in the absence of other parameters, are reconstructed from the product's technical documentation, from the producer's declarations, from marketing materials, from compliance requirements mapped in risk assessments. They are reconstructed, in other words, from the specification. The Cyber Resilience Act, fully applicable from 11 December 2027, makes the same move on the security side. Conformity is demonstrated through the technical documentation of the digital product, and that documentation includes the risk assessment, the implemented security measures, the up-to-date SBOM, the vulnerability-handling procedures, the support plan and the updates for the product's lifecycle. The AI Act, for high-risk systems, requires even more extensive technical documentation, defined in Annex IV, including architectural description of the system, training datasets and data-governance procedures, performance and accuracy metrics, the risk-management system foreseen by Article 9, post-market monitoring procedures. They are distinct regulations, with different scopes, but with an identical epistemic structure. The software product has changed evaluative status. It is judged as the correspondence between a written promise and an observed behaviour, and when the two diverge, the judge or the supervisory authority looks at the written promise. Not because they believe the specification is the real system. Because the written specification is the only fixed point on which a judgement can be grounded. A small framing clarification is needed here, to avoid an easy misunderstanding. I am not saying that the European regime turns the specification into a magic object that holds regardless of the system. The judge or the authority does not just read the document and declare conformity. They compare the document with the system, assess the coherence, accept technical expert opinions. What changes from the previous regime is that the document stops being an appendix to the product and becomes a constitutive part of the assessment, on the same plane as the system's behaviour. When the two diverge, the document is no longer automatically dismissed as obsolete. The producer must explain why he released a system different from the one described, and that explanation, in litigation, is much more expensive than it is today. ## Everything for the code, almost nothing for the spec {: #everything-for-code } Against this shift, the industry has an arsenal of tools for managing the lifecycle of code and almost nothing for managing the lifecycle of the specification. Code has atomic versioning, and when a line changes there is a commit with author, date and message. It has blame, allowing you to trace back the origin of every decision visible in the source. It has tests, which fail automatically when behaviour deviates from a codified expectation. It has deprecation warnings, which signal a promise being withdrawn. It has safe refactor, supported by type systems and regression suites. It has code review, ritualised in pull requests that leave a trail. It has continuous integration, which prevents an incompatible change from entering the main branch unseen. It has branch protection rules, which physically prevent you from bypassing the process. It has rollback in one command, which reduces the cost of error. Each of these tools is the product of an engineering pressure accumulated over the last thirty years, and is now infrastructure of daily practice — so thoroughly metabolised that anyone entering the trade today takes it for granted and struggles to imagine a world without it. The specification has its version, and that's it. A DPIA gets signed, dated, archived in PDF, and the moment the system changes there is no automatic mechanism telling the signatory or the delegate that their signature now covers a different system. Architectural decisions recorded in ADRs accumulate in Confluence, in Notion, in SharePoint folders, and nobody re-reads them unless a specific audit demands it. Security requirements attached to contracts get signed, deposited in the CRM, and from that moment exist as back-office attachments until renewal. Risk assessments produced for AI Act compliance on high-risk systems will require periodic updates, but the mechanism linking the update to concrete system changes will be, in the vast majority of cases, a calendar or a contractual trigger, not a code event. The specification, unlike code, has no internal pressure to stay current. It survives in a slow-time zone where the signature counts more than freshness, and where ageing manifests not as functional degradation but as gradual drift away from the reality the document is supposed to describe. The reasons for this asymmetry are cultural. Technically, tools to treat specifications with the same seriousness as code have existed for decades. Executable specifications in BDD style, test specifications written in Gherkin, formal contracts in languages like TLA+ or Alloy, interface specifications in OpenAPI or gRPC, proof assistants like Lean or Coq. Each of these systems assumes the specification is a first-class artefact, executable or verifiable, alive in the repository alongside the code. In industrial practice, none of this is the norm. The norm is that the specification lives in a Word document, gets reviewed by someone in legal or compliance, gets signed, gets filed, and from that point its fate is detached from the fate of the code. ## The agile origin {: #agile-origin } The origin of this separation is historical and worth reconstructing in some detail. Software culture grew up in opposition to documentation culture, because documentation was perceived as an imposition by waterfall-style engineering management, and Agile won, among other reasons, because it promised to reduce the weight of the document in favour of working software. The Agile Manifesto, signed at Snowbird in February 2001, explicitly reads "working software over comprehensive documentation". The wording was cautious, because at the bottom of the document the authors wrote "while there is value in the items on the right, we value the items on the left more", so documentation was downsized, not abolished. But the industrial reading of the two following decades has been more drastic than the original wording. Comprehensive documentation became a synonym for superfluous documentation, and projects that dared produce more than a README, some comments and a handful of diagrams were suspected of residual waterfall practices. The promise made sense in its context, because the software being written in the early 2000s was judged on functional and commercial criteria, and the document was indeed a cost producing little informational value after the project's first weeks of life. It was also a political cost, because it was often used to impose gate-keeping processes that slowed work without adding quality. What has changed, and what engineering culture has not yet metabolised, is the evaluative context. The software we write today is sold in regulated markets, integrated into supply chains that treat it as a certified component, subject to compliance obligations that demand living documentation. The document has stopped being the internal tool of a bureaucracy that wants to control developers. It has become the tool through which the product presents itself to the regulator, to the regulated client, to the eventual judge. Engineering culture continues to treat the specification as a by-product of the process, while the regulatory framework is promoting it to primary artefact. The gap between these two perceptions is the ground in which specification debt grows undisturbed. ## Spec-driven, BDD, and their limits {: #spec-driven-limits } It would be dishonest to pretend there are no attempts to close this gap, and some of those attempts are serious. *Spec-driven development* in the form it has taken over the last two years, with tools like GitHub's SpecKit and the practice of keeping a `CLAUDE.md` per project as context briefing for AI agents, tries to move the centre of gravity upstream of the code. The specification becomes the input for assisted generation by an agent that produces code, tests and accompanying documentation in a single coherent pass. The promise is that the specification is executable, in the sense that it produces a system, and is therefore maintained by the pressure to generate working code. It is an interesting direction, and on the projects where I have applied it, it has changed the economics of the work in non-trivial ways. The time I used to spend translating requirements into code has shrunk, but the time spent writing precise requirements has grown — and that is a favourable trade-off, because precision retains residual value even when the code is rewritten. The limit I see, after some months of practice, is that spec-driven development solves synchronisation between specification and code at the moment of first generation, which is a real gain, but does not solve subsequent drift. Once the system enters production and changes in response to client requests, incidents, shifts in the operational environment, the formalised specification may or may not be updated, and practical incentives play against updating. Updating the specification costs time and rigour, and forces a negotiation between whoever wrote the change on the fly and whoever is custodian of the document. Under delivery pressure, the document loses. Code in production wins always, because it is what users use. The specification goes back to being a ghost, even when written in a formal language. Executable specifications such as BDD have the same problem, in attenuated form. A Gherkin suite describing the system's behaviour stays synchronised as long as someone fails it and realigns it, but when delivery pressure rises, scenarios get skipped, marked pending, deleted. I have seen suites of hundreds of scenarios shrink to a few dozen in a year and a half — not because the behaviours described had disappeared from the system, but because the suite had become friction the team no longer had time to manage. Executable specs remain more resistant than a DPIA, because they are code and therefore subject to the incentives of code, but they are not immune to drift. They are only slower to drift. And there is a second, subtler problem. Executable specifications cover functional behaviour well — the part of the system that can be verified automatically. They cover much less of the part that the new European compliance asks you to document — risk assessments, architectural choices, processing purposes, mitigation measures. That part eludes automation, because it is not behavioural, and it remains constitutive of the product as a legal object. No test framework will tell you whether it is still coherent with the system. ## A subcategory, not a synonym {: #subcategory } One could object, at this point, that specification debt is already included in the general concept of technical debt, and that talking about it separately is an elegant way to rediscover the moon. The objection is formally correct. The taxonomies of technical debt that developed in the two decades after Ward Cunningham's original formulation, in particular Martin Fowler's work and that of those who refined the cause quadrant, include outdated documentation as one form of debt. The distinction I propose is economic rather than conceptual. Classical technical debt has natural incentives toward repayment, because it slows you down, irritates you every day, costs you onboarding and development time. Specification debt has almost no incentives until a triggering event arrives, and the incentives it has are bureaucratic and calendar-driven, not operational. This difference justifies treating it as a subcategory with its own dynamics, especially now that the regulatory framework is loading it with value asymmetrically with respect to other forms of debt. What I call specification debt is the invisible version of technical debt. Technical debt is the price you pay in the form of slower development, recurring bugs, harder onboarding. It is a price you pay continuously, in small instalments, that motivates you to invest in refactoring because you feel the pain. Specification debt you don't feel. It doesn't slow down development, because whoever develops doesn't read the specification, and when they do read it they find it useful as a historical reference but not binding. It doesn't generate bugs, because the code is already the real specification from the standpoint of execution. It doesn't impede onboarding, because whoever joins the team learns from the code and from colleagues, not from archived documents. Specification debt produces only one kind of damage, and produces it when an event arrives that forces you to confront the specification as a binding object. A third-party audit. A security incident that becomes a court case. A data subject access request you cannot answer because the processing map was made for a different system. A complaint from a client who has read the contract and declares, with some reason, to have purchased something that was not delivered. When that event arrives, specification debt becomes visible all at once, and the price is asymmetric with respect to technical debt. Technical debt you pay in instalments; specification debt you pay in a single lump sum, usually higher than the sum of the instalments you would have paid by managing it over time. There is also a difference in the nature of the cost. Technical debt you pay in development time, and that time is yours to control. Specification debt you pay in lawyer time, in external consultants, in extraordinary audits, in imposed remedies, and in reputation — which is the most expensive currency of all because it does not refinance. There is finally a temporal difference no one notices until it lands on them. Technical debt is paid gradually, while you work. Specification debt is paid suddenly, while you are doing something else, usually at a moment when you have no margin. The crises that reveal it always arrive at the worst possible moment, because they are the moment when someone else has decided to look at what you did not look at. ## Archaeology and asset {: #archaeology-and-asset } In recent months I happened to work on a compliance assessment for a clinical-flow management system built for a large research hospital, and the client of the client — that is, the final clinical foundation — had requested a security appendix with ten control domains to map against GDPR Article 28 and a list of sector-specific requirements. The original specification of the system had been drafted three years earlier, when the system was a relatively simple data-collection platform. In the meantime the system had grown, had acquired processing modules, had been connected to third-party systems, had changed hosting provider. The distance between the starting document and the current system was enormous. The work I had to do for six weeks consisted essentially of rebuilding the specification from the system — that is, reverse-engineering behaviour to write a new document that would be coherent with reality. The operational detail of this work is instructive, because it tells you what it actually means to manage specification debt when it is called in. I had to talk to six different people, each holder of an undocumented piece of knowledge. I had to read the code of three microservices that had been added after the DPIA was signed. I had to track down an external vendor to ask which anonymisation algorithm they applied to the data passed through them, because no one on the internal team knew with precision. I had to reconstruct the flow of personal data across five different systems by looking at network configurations and application logs, because the original diagram had become unusable. All this work was foreign to development. It was pure reconstruction of a documentary truth that should have been maintained over time and that instead had to be rewritten from scratch. It was exactly the operation the regulatory regime assumes is never necessary, because the specification should have been maintained along the way, and it was exactly the operation that is almost always necessary, because the way is never managed like that. On another project, a legal-risk assessment platform for a specialised firm, we decided at some point to migrate the entire stack from Python to Laravel 12. The migration is in progress and we are around seventy-eight per cent done. What I have learned from this migration is that the real asset transferred was not the code, it was the functional specification. The Python code has been largely thrown away and rewritten, the data model has been redesigned, the framework choices have changed radically. What survived is the precise knowledge, formalised in product documentation and in client contracts, of what the system has to do, in what order, with what constraints, against what external interfaces. Without that specification, the migration would have been impossible. With that specification, and with a team that treated it as an active reference during the work, the migration has been hard but feasible. The difference between this project and the clinical case told earlier is a difference of practice, not of the nature of the specification. In both cases there was a written specification. In the clinical case the specification had been signed and then abandoned. In the migration case the specification was read every two weeks in retrospective, contested when the team found inconsistencies, modified when a product choice changed, integrated when a function was added. It was a living object in the process, not a compliance heirloom. It is the same distinction that separates a flight manual the pilot reads before every take-off from the same manual archived in a library. The same text, two completely different functions, two operational values that cannot be compared. The specification as a transferable asset, and the specification as an asset that ages or does not age depending on how we treat it, are two faces of the same thing. ## The tools we still don't have {: #tools-still-missing } A reasonable hypothesis is that the next decade of software engineering will be defined by tools for the specification lifecycle analogous to those the past decade has defined for the code lifecycle. The first serious attempts are already visible. Traceability systems linking specification requirements to the tests that verify them, and the tests to the code changes that touch them, so that when a test changes the system knows which requirement has been impacted and asks for the document update. Drift-detection tools on architectures, comparing declared service topology with observed topology and flagging divergences. Versioning of DPIAs in git repositories with mandatory reviews on every structural change of the system. Product specifications living as versioned objects beside code, with CI failing when the gap between specification and implementation exceeds a threshold. Let me try to imagine what daily practice might look like in five years, in a team that has metabolised this turn. The DPIA has changed form and lives as a YAML file in a protected repository, with version history, modification authors, an approval process via pull request. When a developer introduces a new processing of personal data, a static-analysis pipeline on the code detects the new flow and automatically marks the pull request as "DPIA-impacting". The merge stays blocked until the data protection officer reviews and approves the corresponding change to the processing document. AI Act risk assessments follow an analogous mechanism, with drift detectors flagging when the model in production deviates from the metrics declared in the technical documentation. SBOMs update automatically on every build and produce readable diffs that enter product changelogs. None of this eliminates compliance work, but it transforms it from reconstructive archaeology — like the six weeks I spent on the clinical system — into continuous maintenance, integrated into the same rhythm as development. The cultural leap is to understand that documenting the system, under this new regime, is the construction of the legally relevant asset of the product, and not an administrative cost to minimise. Whoever does not do it now will do it in five years after losing a case, and at that point it will be more expensive. ## Body and soul {: #body-and-soul } A few months ago, on this blog, I wrote a piece titled *[Cruft, Not Patina](/en/blog/cruft-not-patina/)*, and the central argument was that software does not know how to age the way material objects do, because the drift between code and the environment in which it runs erodes it faster than engineering culture can metabolise. There was a passage about Unix as an exception, because in Unix the specification detached from the code and became culture, surviving across cycles of full rewriting of the body. That passage closed with a note of cautious optimism on the fact that the specification, when it detaches, is the stable plane that crosses change. I need to qualify that note. The specification detaches from the code in two different ways, and the difference between the two decides everything. The first way is the Unix one, in which the specification becomes shared culture, described in canonical books, maintained by a community that knows how to apply it to new contexts, and therefore renews itself without losing identity. The second way is that of the archived DPIA, in which the specification becomes a signed document that no one reads anymore, and therefore stays identical to itself while the system becomes something else. In the first case the detachment produces continuity. In the second case the detachment produces a ghost specification. The difference between the two ways does not lie in the nature of the specification. It lies in the practices of those who use it. A specification that is read, contested, modified, re-discussed, applied to new cases, is a specification that lives. A specification that is written, signed, archived, and then ignored until the next audit, is a specification that dies slowly while no one is looking. Putting the two essays together, the general argument I am trying to build is this. Software has a double problem with time. On the one hand, code does not know how to age, because its environment changes too fast and drift turns it into *cruft* rather than into patina. On the other hand, the specification, which could be the stable plane that crosses the rewriting of the code, manages to be that only when a constant practice keeps it alive — and in the vast majority of cases that practice is missing. The result is that software, under the legal regime now consolidating in Europe, is entering an era in which both the body and the soul of the product are fragile, and in which the only thing that can hold the two planes together is a discipline of documentary maintenance that engineering culture has yet to build. Software's engineering culture has not yet drawn the distinction between the two with the clarity that is needed, because it has long treated the specification as a by-product. The regulatory framework now consolidating in Europe is forcing it to draw that distinction, and the price of the next few years will be paid by those who do not notice in time. **Specification debt is the technical debt you don't see until someone gets hurt.** We are accumulating it in silence, in SharePoint folders no one opens, in signed PDFs that are no longer a faithful representation of the systems they certify, in DPIAs filed on the compliance server like monuments. The first major European court case on software product liability under the new regime of the Product Liability Directive will be fought over the specification. When it arrives, and it will arrive soon, the industry will split between those who kept their specification alive and those who only kept on signing it. --- # The Shape the Day Lost - **URL:** https://margiovanni.it/en/blog/the-shape-the-day-lost/ - **Published:** 2026-04-29 - **Tags:** Wellbeing, AI, Work, Time, Philosophy OF Technology - **Reading time:** 7 min > There's a diffuse tiredness we don't know how to name. It doesn't come from doing more: it comes from living inside a time that has lost its shape. AI doesn't speed the activity up — it replaces it with another, and the body, calibrated over years, can no longer read the day. ## The suspended Wednesday {: #suspended-wednesday } It's Wednesday afternoon. You've just finished, in twenty minutes, a task that six months ago would have taken you half a day. The screen is still. The afternoon opens out in front of you. By every external metric you ought to feel something close to triumph. Instead there's a dull, unjustified tiredness you can't quite trace. The hours saved haven't been added to your life. They've only made the day strange. The default explanation — that we're tired because we've crammed more things into the same day — is wrong, or at least insufficient. Many of us are doing less, in clock-time terms, and feel more hollowed out. The fatigue isn't quantitative, it's a matter of texture. Something in the very way we inhabit the working day has shifted, and we don't yet have the words for it. ## Clock time, lived time, and a third thing {: #third-thing } For more than a century, philosophy has distinguished two ways of inhabiting time. There's mathematical time — the time of clocks and schedules, divisible and uniform. And there's lived time, what Bergson called *durée*: the time of experience, in which ten minutes of waiting feel longer than an hour of immersion. The two were always in tension, but they ran roughly parallel. A working day had eight hours of clock time and a felt shape that more or less corresponded to it, with a heavy start and a close you could see coming. We knew where we were inside the day even without checking the time. AI introduces a third thing that has never existed before. The clock keeps ticking uniformly. Lived experience still has its variations. But the cost surface of activities has become wildly irregular, and not in a way the body can predict. A task that consumed three hours yesterday takes twenty minutes today. Another task, similar on the surface, still takes three hours. There's no rule. The asymmetry is local, and arrives without warning. You move from a regime in which work is hard to one in which it's trivial, and back again, several times in the same afternoon, with no signals that allow you to adjust. ## The body that no longer reads the map {: #body-no-longer-reads-map } The body had calibrated itself, over years, on a precise cadence. It knew how to distribute energy across a day, when to push and when to slow down. That calibration assumed a relatively stable map of activity costs: writing a report took hours, answering an email took minutes, and most intellectual work fell within that range. The map is no longer accurate. The body keeps making its calculations on costs that no longer hold, and there is a silent, persistent expenditure of energy in this constant recalibration that we don't even manage to observe while it's happening. ## A tiredness without shape {: #tiredness-without-shape } It's a tiredness different from the ones we knew. It isn't the tiredness of effort. It's the tiredness of time without shape, which is harder to name because we have so few examples of it in our history. Even the most severe constraints — prison, illness — tend to impose a rhythm of their own, and indeed people who come out of them often describe the absence of that rhythm as one of the most disorienting things about returning to free life. Even leisure has a rhythm: weekends against weekdays, meals, habits. What we're inside now is something else: a working day whose shape changes while we're working it, and that doesn't settle into any pattern stable enough for us to lay ourselves down inside it. ## It isn't just transition {: #not-just-transition } You could object that this is only transition. Give the system time. We'll learn the new map and a new rhythm will emerge, as has always happened. Perhaps. But the analogy with previous technological transitions is misleading in a way worth naming. The factory imposed a brutal but legible cadence, and within a few decades the collective body of workers recalibrated around that new shape. The personal computer accelerated certain tasks but kept their inner phenomenology intact: writing was still writing, on a different surface. What's changing now is more fundamental. AI doesn't accelerate the activity, it replaces it with a different one. The thirty minutes you used to spend formulating a paragraph aren't compressed into three minutes of faster formulation. They're replaced by ninety seconds in which you describe what you want and a few minutes in which you edit what comes back. These aren't the same activity, faster. They're different activities, with different costs and different felt shapes. The body has nothing to recalibrate against, because no new normality is forming long enough to be read. ## The thoughts that aren't reached {: #thoughts-not-reached } There's also something we lose when the texture of the day flattens, and it's worth looking in the face. The *deep work* tradition, even after being absorbed into a certain productivity rhetoric, was pointing at something real and subtle: certain kinds of thinking only happen in prolonged uniform stretches. The morning hours we used to protect for the difficult task weren't simply higher-quality hours. They were hours that made the task itself possible. Some thoughts are only reached after forty minutes of sustained attention, and you can't reach them in eight minutes of attention repeated four times. When the texture of the day becomes fragmented and unpredictable, those thoughts simply aren't reached. We don't notice their absence directly, because what isn't thought leaves no sensible trace. We notice it as a kind of cognitive thinning, a faster output that is somehow lighter, the strange sensation of producing a lot and thinking little without quite being able to say what the difference consists of. ## Scaffolding against asymmetry {: #scaffolding-against-asymmetry } I don't have a formula for what to do with all of this, and I distrust anyone who has one ready. The *productivity genre* answers — which mostly suggest imposing artificial structure on the new chaos through armoured calendars and morning rituals erected against the asymmetry — can help in individual cases. They don't address the underlying phenomenon, which is that the natural shape of the day was a real thing, held up by the relative costs of activities, and those costs have changed structurally. Artificial structure is a scaffolding trying to hold up a building whose foundations have shifted. It can work for a while, and it wears down whoever maintains it. What I notice in myself, and in colleagues who talk to me about it when there's enough trust to step out of productivity rhetoric, is that the fatigue is sharpest on the days when we tried hardest to use the time we'd saved. The Wednesday afternoon when the task collapsed into twenty minutes and we filled the remaining hours with other tasks ends in a particular tiredness that doesn't come from the work but from the inner violence of pretending that the time we lived was the time we measured. The Wednesday afternoon when the task collapsed into twenty minutes and we stopped — when we went out to walk, or stayed and looked at the strangeness of the afternoon without trying to renormalise it — ends differently. Not productively, in the old sense. But the body recognises that something has been honoured, and that cleaner tiredness is a different thing from the first. ## A new respect for the absence of rhythm {: #respect-for-absence-of-rhythm } Maybe what we need isn't a new rhythm but a new respect for the absence of rhythm, at least while it lasts. The old day had a shape because work had a shape because costs had a shape. None of that is coming back in the form we knew it. Trying to rebuild it by force, through ever more elaborate scaffolding, will keep producing the diffuse tiredness all of us are carrying without naming. Letting the day be the strange thing it has become — now a sprint, now an empty stretch — might at least give us back the energy we're spending on the useless project of pretending nothing has changed. It's a partial surrender, sure. But some surrenders are the prelude to a way of being inside things that resistance would never have given us. This isn't optimism. The asymmetric day might be a worse day to live in than the structured one we had before, and I'm not sure how it ends. What I am sure of is that calling fatigue by its real name is the first thing we owe ourselves and our colleagues: we aren't tired because we've done more — we're tired because we've lived inside a time that had lost its shape, and we kept behaving as if the shape were still there. --- # The Shape of Constraint - **URL:** https://margiovanni.it/en/blog/the-shape-of-constraint/ - **Published:** 2026-04-27 - **Tags:** Compliance, EU Regulation, AI Act, CRA, Philosophy OF Technology, Architecture, Strategy - **Reading time:** 16 min > Treating regulatory compliance as the adversary of the technical project means you haven't understood what the technical project is. An essay on the category error weakening Europe's software industry — and on how the European framework, read as a system rather than as a list, configures a structural competitive advantage for those who learn to inhabit it. > "The more constraints one imposes on oneself, the more one frees oneself of the chains that shackle the spirit." > — Igor Stravinsky, *Poetics of Music* ## The story we've been told {: #story-weve-been-told } A story has settled, in recent years, at the centre of the European debate about technology. You all know it. In its compressed form it goes: "America innovates, China copies, Europe regulates." It's a quip you hear at conferences, read in newspapers, find in think-tank reports, and that found its formal consecration in the Draghi report on European competitiveness — an honest, dramatic document that named regulatory fragmentation as one of the causes of our structural lag. There's a kernel of truth in it. The European regulatory frame is dense. The piling up of requirements — AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act, NIS2, GDPR, Data Act, DSA, DMA — does produce non-trivial cognitive load on whoever builds software. Many Italian SMEs are gasping for air, specialised consultancy is expensive, mature tooling is still missing. But the story, as often happens, is more interesting than how it's told to us. Because there is another way to read the same scenario, and that's what I want to articulate in these pages. A reading that doesn't deny the difficulties but rejects the apparently obvious conclusion: that regulation and innovation are opposed, and that being in Europe means losing simply by being there. The thesis I'm defending is simple at its core, complex in its implications. Regulatory compliance, properly understood, is not a cost of the competition: it is one of its terrains. And the European framework, read as a coherent technical project, configures a competitive advantage that companies who understood it are already monetising — while those who keep treating it as a nuisance are progressively excluding themselves from the higher-value markets. ## The category error {: #category-error } The first step in defusing the false dilemma "regulation versus innovation" is to recognise that the dilemma is, before being a debatable position, a category error. When an architect designs a building, she works inside a tight web of constraints: laws of physics, seismic codes, urban planning rules, energy requirements, accessibility, fire safety, landscape protections. Nobody, looking at a well-designed building, says it would have been "more innovative without the laws of statics." It would be absurd. Gravity isn't a brake on architecture: it's the condition that makes architecture possible as a discipline. It is what distinguishes building from piling up materials. The same is true of software. The constants, standards, protocols, specifications — TCP/IP, ANSI SQL, POSIX, IEEE 754, RFC 7231 — are constraints. Severe constraints. And yet no serious engineer treats them as obstacles to innovation. They are the opposite: the shared grammar that makes it possible to compose complex systems out of independent pieces. Without those constraints we wouldn't have the Internet, we wouldn't have databases, we wouldn't have interoperability. We'd have an archipelago of incompatible proprietary solutions — exactly what European regulation, in its intent, is trying to prevent for the next layer of the technology stack: data, AI, security, accessibility. Constraint, in other words, isn't design's enemy: it's its shape. Schönberg knew it with the twelve-tone system, the Oulipo knew it with their literary algorithms, Calvino knew it when he praised exactness as a value of literature, every experienced developer knows it when she finally understands that static types don't slow development down — they structure it. Absolute freedom in engineering is called chaos, and it produces fragile systems, incomparable, unmaintainable. Disciplined freedom produces architecture. Treating compliance as the adversary of the technical project means you haven't understood what the technical project is. ## The European framework as a system, not a list {: #framework-as-system } The second step is to read the European regulatory body the right way. Almost all the conventional critique — even the well-intentioned kind — makes the same mistake: it treats the regulations as a list. A list of disconnected obligations, each one adding friction, each one to be assessed individually on cost-benefit terms. But that isn't the shape the European framework has actually taken. If you look at the overall weave of the regulations of the past decade — from GDPR to the AI Act, through CRA, PLD, EAA, NIS2, Data Act, DSA, DMA — it isn't a list, it's a system. And like every designed system, it has its own architectural logic. That logic can be summed up in one sentence: make accountable, *by design*, the technical systems that materially affect people's rights and goods. Everything else is a domain-specific declension of that principle. GDPR makes flows of personal data accountable. GDPR doesn't tell you how to design the database: it tells you that you must be able to answer — always, for anyone who asks — who touches whose data, why, for how long, on what legal basis. The Cyber Resilience Act does the same thing for software product security: it doesn't tell you which language to use, but it requires you to know and demonstrate what's inside your product, to keep it secure over time, to manage vulnerabilities through traceable processes. The Product Liability Directive extends the producer's liability to software itself, declaring explicitly that a bug can be a product defect. The European Accessibility Act extends accountability to inclusion: digital products above a certain market threshold must be usable by anyone. NIS2 does it for critical infrastructure. The AI Act does it for systems that meaningfully decide on, or influence, human choices. Seen this way, European compliance isn't a jungle of rules. It is one grammar applied to different domains: design things so you can answer for what you do, *by design*. Not as a fallback. Not as a coat of paint added later. As architecture. And here is the often-missed point: once you have built an organisation that thinks in accountability terms — with SBOM, audit trails, threat modelling, privacy impact assessments, tested accessibility, formalised vulnerability management — the marginal cost of conforming to regulation N+1 drops sharply. The cost curve is the inverse of what naive critique imagines: high at the start, falling over time, while for whoever treats every regulation as a fresh emergency the curve starts low but diverges. Organisations that understand this don't "get compliant." They *are* compliant, in the strong sense: they have a shape compatible with the framework. The others chase. ## The Brussels Effect, ten years on {: #brussels-effect } There is also a market dimension we tend to forget, and which on its own should dissuade anyone from dismissing European regulation as ballast. Anu Bradford, a Columbia legal scholar, coined the term *Brussels Effect* to describe a well-documented empirical phenomenon: when the European Union regulates a market this size — second by nominal GDP, third on a purchasing-power basis, in any case one of the three biggest markets in the world — multinationals tend to adopt the European standard as their global standard, because maintaining two parallel regimes costs more than adopting the stricter one everywhere. The paradigmatic case is the GDPR. Approved in 2016, applicable from 2018, it is today the de facto regulatory base orienting privacy policies at the largest tech companies in the world. You see it in cookie banners everywhere, in the privacy dashboards of the big tech platforms, in the California Consumer Privacy Act (which echoes its principles and structure with a lighter, opt-out-based architecture), in the Brazilian, South African, and Indian laws. Almost eight years after enforcement began, we can say with reasonable certainty: the grammar of global privacy speaks European. The AI Act looks set on the same trajectory. Not because it's perfect — it isn't — but because it's the first *horizontal and organic* regulatory framework in the world for AI systems. China got there first, in 2023, with binding rules on generative AI: but those are sectoral rules with a different emphasis — mandatory labelling, registration with the authority, user identity verification, content control — more oriented to informational stability than to fundamental-rights protection. The AI Act was the first attempt at a general, risk-tiered architecture, applicable to all AI systems across all sectors. The major AI companies are already structuring their internal processes against European requirements. In the United States, in a turn few would have predicted, state-level regulation is picking up — particularly in Colorado, with echoes in California and in some local New York legislation — the risk-categorisation logic, although the path has not been linear: the Colorado AI Act, originally in force from 2026, has been postponed and is being reworked as I write. For a European company designing software, this means something very concrete: you are already working inside the standard that, statistically, will be the global standard within five years. Your American and Asian competitors will have to adapt to a frame you have already metabolised. This isn't a detail: it is the operational definition of first-mover advantage. The reply usually is: but if the Brussels Effect is so powerful, why are European companies struggling? The honest answer is that many European companies have not in fact metabolised the framework — they suffer it. They treat the GDPR as a nuisance to minimise, the AI Act as an unknown to defer, the EAA as something to do when the inspection comes. They pay twice that way: the cost of compliance (which, badly run, is high) and the missed opportunity of turning that compliance into positioning. Meanwhile non-European companies, forced to comply to access the market, do so structurally — and the competitive advantage that could have been ours becomes theirs. The Brussels Effect is an arrow flying toward a target. We get to decide whether the target is us or them. ## The asymmetry that decides {: #asymmetry-that-decides } Now to the heart of the argument, the operational part. There's a fundamental asymmetry between two kinds of company operating in the European market, and that asymmetry — silent, accumulating, today barely visible, tomorrow decisive — will determine who wins and who exits the higher-value segments. The first kind treats compliance as *paperwork*. It's the default position, and perfectly understandable: the regulation arrives, you appoint a person responsible, you fill in checklists, you produce documents, you update the privacy policy, you add the banners, you commission assessments when needed. Compliance is a cost to minimise, a defensive activity, something you do to avoid fines. It's an activity outsourced as soon as possible: an on-demand consultant beats a structured internal process. The second kind treats compliance as *architecture*. The difference is that regulatory requirements are not addressed at the moment of their applicability but taken as project constraints from the start. The SBOM isn't a document produced after the fact: it's an artefact generated by the CI/CD pipeline at every build. Privacy isn't a checklist to fill in: it's a dimension of the data model. Accessibility isn't a final check: it's a UI component set that guarantees it. Security isn't an annual audit: it's a threat model revisited at every meaningful architectural change. AI accountability isn't a response to an inspection: it's a battery of tests, training documentation, evaluation suites. For the first two or three years, the difference between the two is hard to spot from the outside. The first company even looks more efficient: it ships the same products with less overhead. The second invests in things that can't yet be seen: pipelines, frameworks, processes, training, structured documentation. Then something changes. It changes when the relevant market becomes healthcare, public administration, finance, energy, critical infrastructure — the segments where the customers have their own regulatory exposure, and where their compliance depends on their suppliers'. At that point something happens that anyone who works in regulated B2B has already seen: the RFP arrives with a thirty-page technical annex, and the "paperwork" company discovers that many of the requirements are not incremental but structural. Full SBOM for every component. Vulnerability traceability with remediation SLAs. Documented and audited SDLC processes. Annual penetration tests with traceable remediation. Backup, disaster recovery, business continuity policies that have actually been tested. Demonstrable privacy by design for every flow. Verified accessibility. Auditability of any AI models in use. The "paperwork" company has two options: either it transforms into an "architecture" company — investing suddenly, under pressure, in everything it never built — or it withdraws. Transforming under pressure is expensive, slow, and never clean: it produces approximate documentation, processes that survive at most until contract renewal, fragility that surfaces at the first serious audit. Withdrawing means stepping down a market tier. The "architecture" company participates, wins, and — this is the point — wins at higher margins, because in those segments pricing rewards demonstrability, not just functionality. I'm describing, as should be clear, something I live first-hand. Over the last three years I've watched healthcare projects where the discriminator was neither price nor *feature parity* but the ability to produce, on time, governance, security and accessibility documentation coherent with the customer's requirements. I've seen public-administration tenders where ACN qualification was a gate, and where the absence of a qualified vendor translated into mechanical exclusion. I've seen negotiations where a security-focused technical annex redefined the entire axis of the conversation: no longer "what does your product do," but "how do you demonstrate you can run it for years." In these contexts, compliance isn't the final irritation of the negotiation. It is *the* terrain of the negotiation. ## Trust as product {: #trust-as-product } There's a phrasing I find useful: in regulated B2B you don't sell features, you sell documented trust. Features matter, obviously. But features become commodity faster than people think. All CRMs look alike. All LMSs look alike. All telemetry platforms look alike. Differences are incremental, and after a certain level they stop being the buying discriminator. What becomes the discriminator is what isn't a feature in the classical sense: the ability to sign a contract with precise liability clauses, to pass an audit, to guarantee operational continuity, to document your software supply chain, to respond within 24 hours to a data-subject request, to demonstrate the non-discriminatory behaviour of a decision system, to keep your products accessible for years. None of these is a feature in the classical sense. They are *demonstrable organisational capabilities*. And they are exactly what the European regulatory framework forces you to build. Here, in my view, lies the fundamental conceptual inversion. For a paperwork company, documentation is a by-product: the thing you produce so that inspectors are content. For an architecture company, documentation *is the product* — or rather, it is a constitutive part of the product, because what you sell isn't the software but the organised capacity to run it over time, and that capacity is demonstrable only through documentation. You see, from this angle, why the SBOM isn't a paper exercise: it's the manifest of your software supply chain, and it's what lets the customer manage *their own* exposure. You see why the audit log isn't a cost: it's a reliability property the customer will buy anyway, and one that will be mandatory soon. You see why an EN 301 549-conforming accessibility report isn't a formality: it's what lets the public-sector customer win their own tender, and so it's what makes you a preferred supplier. When you sell trust, the documentation is the product, and compliance is the product's instruction manual. ## The honest objection {: #honest-objection } It would be dishonest to lay out this reading without acknowledging the serious objections. There are at least three, and they deserve to be taken seriously. The first is **disproportion**. The regulatory load resting today on a ten-person software house is, structurally, very close to the load on a major corporation. Not in absolute terms — there are thresholds and exemptions — but structurally: the processes required to be genuinely compliant with the CRA, AI Act, GDPR are at points the same as a multinational's, simply with fewer people running them. This disproportion is real, and it's the main reason many European SMEs are struggling. It's a serious problem, and it asks Brussels to do better on proportionality, on simplified regimes for SMEs, on the availability of accessible compliance tooling. It is not, however, an argument against compliance as such: it is an argument for implementing it better. The second objection is **implementation heterogeneity**. The European regulation, once it lands in national legal systems, gets translated in ways that vary from country to country — competent authorities, certification schemes, supervisory tools, thresholds. That heterogeneity is genuinely a cost, especially for cross-border work. It is a specifically European weakness, tied to our institutional history, and it isn't easily resolved. But — and this is the point — it isn't a weakness of compliance: it is a weakness of single-market integration. Two different problems. Dismissing European regulation because it gets applied unevenly is a bit like dismissing the idea of a language because dialects exist. The third objection is the most interesting, and deserves the most articulated answer. It is the **time-to-market** objection: if our American competitors don't have to do AI Act compliance, and we do, they get to market first. This collides with the Brussels Effect but doesn't entirely cancel it: there is a real window where asymmetry of constraint produces asymmetry of speed. The thing is, that window applies to a specific subset of products — the ones aimed at the consumer mass market, where time-to-market often beats robustness — and not to those aimed at regulated segments. For whoever sells to hospitals, banks, public administration, critical infrastructure, speed is rarely the discriminator: demonstrable robustness is. And there the European framework is an advantage, not a handicap. There are European companies winning in regulated B2B precisely because the American product arrives without the documentation, without the processes, without the culture — and has to be rebuilt under pressure to pass audits. Rebuilding under pressure is expensive: their margins drop, ours go up. All three objections, in short, have a kernel of truth, but none of them justifies the catastrophist conclusion that often comes attached. The right answer is: implement compliance better, not refuse it. ## What a compliant-by-design organisation does {: #compliant-by-design } So far, the conceptual level. I want to close with something more operational, because an essay on compliance that doesn't go down to specifics risks being appreciated and then forgotten. An organisation that has turned compliance into competitive advantage, in my experience, has these traits. It has *one accountability model* spanning the software lifecycle. Not one model for security, one for privacy, one for accessibility, one for AI: a single model with domain-specific declensions, where all requirements converge on the same pipelines and the same documentation. The SBOM, the PIA, the threat model, the accessibility test record, the model card live in the same repository, are versioned, are updated at every release, are linkable from anywhere else in the organisation. It has *automation of the compliance artefact*. Generation of SBOM, SPDX, license reports, vulnerability reports, accessibility scans, model evaluation reports is automatic. Not something someone produces by hand in anticipation of an audit: something the pipeline produces at every build, with timestamp and reference commit. The result is that, when a customer request lands, the answer is available in minutes, not weeks. It has *contracts as specifications*. Customer contracts — especially in healthcare and public administration — are not legal texts disjoint from technical work, but technical specifications living inside the backlog. Security clauses are mapped onto requirements, requirements onto tests, tests onto pipelines. When a customer asks you to certify conformity to a clause, the answer isn't "let's ask the consultant": it's a query against your own system. It has *internalised legal competence*. That doesn't mean having a lawyer on the org chart. It means tech leads know the regulations applying to their domain, understand their logic, know how to translate their requirements into architectural choices. The external consultant is a resource for specialised cases, not the owner of compliance. It has *a culture of explicit trade-offs*. It knows when a compliance requirement imposes a cost, declares it, debates it, makes a motivated decision. It doesn't pretend compliance is free. It doesn't pretend it's impossible. It treats compliance as one of the project's constraints, to be balanced against the others. And, above all, it has *a commercial narrative grounded in compliance*. It can tell customers why its product is better, and that "why" includes — alongside the features — the documented reliability structure. It knows that the healthcare customer, the public-sector customer, the banking customer is buying exactly that: the guarantee that, three years out, five years out, in front of an inspection, in front of an incident, in front of a regulatory shift, you will still be a solid supplier. That isn't a concession to marketing: it is the product. ## Europe's civic signature {: #civic-signature } I want to close by stepping out of the operational terrain and returning to the conceptual one, because there is a further dimension — civic, almost political — that is worth naming. Europe, as a project, is a singular historical experiment: a union of states that decided, after the catastrophes of the twentieth century, to pool sovereignty in exchange for rules. It isn't a union of force: it's a union of norms. Our symbolic wealth, our capacity to project values, our international credibility, depend in large measure on the idea that we make rules, abide by them, and apply them to ourselves. When we export them, we don't do it through force, we do it through the market. What we are doing in the digital domain is precisely this: transposing our civic signature into cyberspace. The idea, scandalous to part of the world, that technology should answer to those who suffer it, not only to those who produce it. That the effects of technical systems on individuals are not an externality but a legitimate object of regulation. That innovation producing unrepaired harms, unremedied exclusions, unexplainable opacities is not innovation: it's a transfer of costs from producer to citizen, dressed up as progress. You don't have to share this view. There are legal systems that have made other choices, and we respect them. But arguing — as some of us still do — that our view is a brake, and that real progress is somewhere else, means not having understood the game we're playing. The game isn't who reaches the consumer market first with a new gadget. The game is who defines the grammar inside which technical systems will operate for the next fifty years. The GDPR is already the grammar of global privacy. The AI Act is becoming the grammar of global algorithmic accountability. The CRA is becoming the grammar of global software product security. For whoever designs software in Europe, taking part in this game is a privilege we pay for with a specific cost — the cost of building first — but it is also, precisely for that reason, our principal structural competitive advantage. Whoever stays out, inside Europe itself, because the framework is a nuisance, is making a short-sighted bet: removing themselves from the only advantage we have, in pursuit of a competitive model — pure time-to-market — in which we cannot win anyway, because we don't have the capital mass of those who define it. Compliance, properly understood, is not our burden. It is our shape. Our shape of building, our shape of doing business, our shape of projecting values. Treating it as ballast is, for a musician, like treating the key signature as a bother. You can do that, sure. But you'll be playing something else, and you'll be playing it worse. Constraint, once again, is shape. And shape, for those who learn to inhabit it, is an advantage. --- # DPIA as a Genre, Not a Form - **URL:** https://margiovanni.it/en/blog/dpia-as-a-genre-not-a-form/ - **Published:** 2026-04-21 - **Tags:** Compliance, GDPR, EU Regulation, Philosophy OF Technology - **Reading time:** 26 min > The EDPB's DPIA template, released in April, isn't a longer form. It codifies a form. On the shift from module to genre, and what changes for anyone who writes compliance as continuous writing practice. The EDPB template dropped publicly last week. I opened it for the first time on the train between Pescara and Rome — a PDF of about forty pages that felt familiar before I'd even read it, read with that particular distracted attention one reserves for documents one already knows everything about. I've been living with the DPIA for years, helped write dozens of them, grown accustomed to treating it as a stable object: a form, a checklist, a compliance artefact to hand to the DPO and file away. Opening the new template, I had in my hands something familiar and slightly altered, the way it feels to return to a flat you lived in as a young person and discover someone has moved the furniture without telling you. Something irritated me, and I couldn't name it. It was only a few days later, reading it calmly at my desk, that I understood what had been bothering me. The template wasn't a more detailed version of the previous one. It was something else. Not an improved form, not a finer grid: the document in my hands demanded something different from whoever filled it in and, more subtly, demanded something different from whoever read it. The DPIA was ceasing to be a form and turning into — to borrow a term I spent my university years chewing over — a *genre*. ## What has arrived, and what hasn't {: #what-has-arrived-and-what-hasnt } It's worth stating straight away what has and hasn't arrived, because the nuance matters for the rest of the argument. The EDPB adopted the template in version 1.0 by written procedure on 10 March, released it publicly in April alongside an explainer document accompanying each section, and opened it to public consultation until 9 June. The template's use is not mandatory: controllers may continue to use whatever DPIA methodologies they prefer. After the consultation, and with whatever revisions are made, every national data protection authority will take steps to adopt it either as its own standard or as a meta-template with which national models will have to align. Nothing is yet closed, in short, but everything is taking shape — and the shape it's taking is precisely what I want to discuss here. I'm aware I have to argue against the common intuition. Most people working with DPIAs treat them as bureaucratic bother, a burden to dispatch, a piece of paper the legal consultant fills in and the client archives. In Italy, where compliance has long kept a defensive profile, DPIAs have often been written not to be read, and read not to be discussed. The question «what do you actually need from a well-done DPIA?» tends to yield practical answers: that it be complete, cover the use cases, not contradict other documentation, survive an authority's inspection. These are honest answers. They are also, I'd argue, the wrong ones — or rather, they are the answers one gives if the DPIA really were a form. And that is precisely what, until a few weeks ago, the DPIA still was across much of Italian practice. An author-less document in the weakest sense: someone signed it, yes, but no one took responsibility for it in an editorial sense. ## A template is not a form {: #a-template-is-not-a-form } But here we reach the point. A template is not a form. A template, the moment it is proposed by an authority like the EDPB with the explicit ambition of becoming the common European standard, ceases to be a filling-in instrument and becomes something stranger and more powerful: the codification of a form. And a form is not filled in. A form is *written*, and it's written with full awareness of being read within specific expectations, with a lexicon, a narrative structure, a rhetorical rhythm that are not interchangeable with others. That, in short, is a genre. To see why the shift matters, it helps to step back and look at how the DPIA got here. It has existed formally since 2018, mandated by Article 35 GDPR as a required assessment for high-risk processing. In the early years it was handled as it could be handled: each organisation, each law firm, each DPO produced its own version, with a variability anyone who's worked cross-sector knows well. Some DPIAs were five-page documents that read like meeting minutes; others were hundred-page tomes that read like doctoral theses. Some were compiled with numerical risk matrices inherited from security frameworks, others in dense legal prose laden with normative references, still others with hybrid approaches that mixed the two cultures without quite making them cohabit. The Commission had suggested certain outlines, first Working Party 29 and then the EDPB had published guidelines, some national authorities had made more structured models available, but the landscape remained fragmented. The DPIA sat in that state of a young thing whose forms haven't yet settled, where everyone tries their own path and few of those paths meet. European supervisory authorities had complained repeatedly about this heterogeneity, which made it hard to build the kind of implicit, shared jurisprudence every mature field builds by reading hundreds of documents produced according to a recognisable form. ## When a form takes shape {: #when-a-form-takes-shape } The EDPB template opens the closure of this phase. Not with the formal authority of a binding regulation, which it is not, but with something like the authority a normative grammar exerts over a living language: it indicates, orients, creates a centre of gravity. From now on, anyone writing a DPIA in Europe knows there is a form proposed at the supranational level, and knows that when the consultation closes and national authorities have taken their adoption steps, every deviation from that form will require justification. This is exactly, in the history of languages and literary genres, the movement by which a form takes shape. Before Dante, Florentine vernacular was one of many Italian vernaculars; after Dante, every use of Florentine vernacular measured itself against him, even when it wanted to move away. Comparing Dante to a bureaucratic template is disproportionate, I know. I leave it anyway because the mechanics are the same, even if the altitudes are obviously incomparable. When an authority proposes a form and all the authorities beneath it announce they will adopt it, that form ceases to be one possibility among many and becomes the background against which all the others stand out. ## Architext and self-inquisition {: #architext-and-self-inquisition } Literary scholars call this phenomenon the stabilisation of an *architext*, a term I owe to Genette but which was already circulating in Bakhtin under the name *secondary speech genres*. The architext is not a single work: it is the set of formal expectations a reader brings to a certain type of document. When I open a detective novel I know there will be a crime to solve; when I open a scientific article I know there will be a methods section; when I open a sonnet I count the lines before reading them. A stabilised architext produces stabilised expectations. And it produces, inevitably, a form of writing that knows it is being read within those expectations. Hans Robert Jauss, from 1970 onwards, called this reader's stance — encountering a text within an already known genre frame — *horizon of expectations*. For Jauss, every text is read twice: once against the frame the reader brings, once reshaping that frame according to what the text actually says. A DPIA written inside the EDPB template, once that template has become the reference standard, will be read this way: the auditor or inspector will already know what to look for, in what section to expect what, will recognise immediately when the text departs from the expected form, and will construct a judgement from that deviation. There is a second theoretical thread I want to invoke, because it illuminates the point in a different direction. Carlo Ginzburg, in his work on the sixteenth- and seventeenth-century inquisitorial trials of Friuli, showed how the transcripts of those trials were a genuine documentary genre, with precise rhetorical conventions, a coded relation between interrogator and interrogated, a particular handling of voice between direct and indirect discourse, a narrative structure that translated the defendant's voice into the inquisitor's procedural frame. Ginzburg read those transcripts as texts, not as pure transcriptions, and in that reading found traces of a popular subjectivity otherwise invisible. Beyond the historical comparison, there is a structural analogy that has struck me since I started thinking about the DPIA. A DPIA is, in its deep architecture, a self-inquisitorial document: the controller interrogates itself about its own conduct, reconstructs the reasons for its choices, argues before an absent but threatening reader (the authority) why those choices are adequate. It is a form of discourse that exposes its own rationality in order to be judged on it. The fact that it now has a template destined to become a codified genre means, among other things, that this self-inquisition is about to have a grammar. And grammars, as anyone who has studied them seriously knows, are not neutral instruments: they model what can be said, and indirectly what can be thought. ## The window of canon formation {: #the-window-of-canon-formation } Anyone writing a DPIA in the coming months finds themselves in a particular position, different from both the pioneer's and the practitioner-inside-a-mature-genre's. The template is on the table but isn't yet a standard, the consultation is open, national authorities are preparing their transposition steps. Writing a DPIA in this window means writing inside a form that is still stabilising, which means two things. First, one can no longer behave as a pioneer: the template is available, its sections are clear, its method is public, ignoring it would be a deliberate gesture that needs motivation. Second, less obviously, there is an opportunity that writers two years from now won't have: the chance to contribute, through one's practice, to defining what «writing well» will mean inside this genre. Every DPIA produced now that engages seriously with the template, that uses it as structure, that flags its limits, contributes to forming the canon. In stabilised genres the canon already exists; in forming genres the canon is made by writing it. For those of us who do this work, it's worth being present precisely in this window. ## From form to prose {: #from-form-to-prose } It could be objected that I'm romanticising what is merely a longer form. The objection is serious and deserves to be taken seriously. If the DPIA were only a longer form, its evolution would be irrelevant outside the narrow perimeter of compliance: another grid to fill, another kind of PDF to archive, another marginal cost for those processing data. But there's a detail in the new template that, once noticed, dismantles this reading. The template no longer asks merely to list. It asks to argue. It asks, in particular, to justify the proportionality of choices, to reconstruct the reasoning that leads from a risk assessment to a mitigation measure, to show why a given balance between utility and residual risk is acceptable. It asks, in short, something a form cannot ask: it asks for prose. The appearance of prose in a compliance document is the clearest symptom of the shift to genre. A form doesn't need prose, because its informational value is entirely contained in the grid. A genre, by contrast, lives in prose, because it is in prose that connections between facts, hierarchies of importance, justifications, and nuances are expressed. When the EDPB template asks you to write why the chosen legal basis is adequate to the context of the processing, it is asking for a small essay. The content of that essay will have formal constraints, but it remains an essay. And whoever writes an essay — even a three-hundred-word essay in a PDF box — writes differently from whoever fills a cell in a spreadsheet. Prose forces a point of view, forces decisions about what comes first and what comes later, forces showing which information is accessory and which is central. The grid, by its nature, flattens these hierarchies. The shift from grid to prose is not a shift of pure form; it is a shift of local epistemology, of what a given text can tell and what it cannot. ## The many readers of a DPIA {: #the-many-readers-of-a-dpia } An underrated aspect, and one I want to bring to light, concerns who actually reads a DPIA. Current practice almost always imagines a single reader, or rather a hypothetical, under-characterised one: the inspector from a supervisory authority — a somewhat abstract figure most DPIAs will in fact never meet. But a document of genre always has more real readers than it declares, and the DPIA is no exception. The public buyer assessing a vendor reads it. The compliance officer doing due diligence on an acquisition reads it. The lawyer preparing a defence in litigation reads it. The data subject who wants to understand how their data is processed reads it — if it is well written and made accessible. Increasingly, the upstream technology vendor who needs to verify whether its processor role has been correctly scoped reads it. Each of these readers brings a different horizon of expectations, and the fact that the EDPB template is stabilising the form helps all of them at once: a disciplined reader knows where to look, knows how to recognise what they're looking for, can distinguish a well-made text from a botched one. A form is ultimately opaque to any reader external to its filler. A genre, by contrast, has the democratising virtue of being legible to anyone who knows its conventions. ## DPIA-as-code {: #dpia-as-code } Let me return for a moment to Oltrematica's experience in recent months, because it was exactly the day-to-day of certain projects that made me understand what was changing. We have ongoing work on healthcare platforms for the Abruzzo region, on people analytics systems in hospital settings, on applications for local public administration, on online training platforms with ECM certifications, on parking management systems for municipal utilities. In every one of these cases we have, or will have, a DPIA. Until a year ago the typical approach was: set up a call with the client's DPO, gather information, produce a draft, review it together, put it in the repository. The document was essentially closed at the end of the process. It was updated when processing changed, on an annual or biennial review cycle. It was, clearly, a form. What's interesting is that internally within the tech team we also treated the DPIA as a form: we considered it something the DPO produced for us, not with us, and that concerned us only if an auditor asked us to confirm some of its contents. When I read the new template, the first thing I did was write an internal memo about what would change operationally. The second, less immediate, was to draft a proposal I briefly called *DPIA-as-code*: bringing the DPIA inside the project's versioning flow, integrating it with Jira and Confluence, making it an artefact that lives in the same ecosystem as the code. It isn't a revolutionary idea. Others were already thinking along these lines, particularly in environments where compliance has historically been entangled with software engineering — I'm thinking of certain security teams in the US cloud-native world. But the reason the proposal makes sense precisely now, and not two years ago, is exactly what I'm writing about: only when a document is becoming a genre, and no longer a form, does it make sense to version it the way you'd version a chapter of a book. A form is updated with a new form; a chapter is revised with genetic traceability, attention to variants, an archive of decisions that lets you retrace your steps and understand why, a year ago, you chose a certain phrasing over another. The projects where this transformation is proving most interesting are the ones whose risk profile evolves with the product. A people analytics platform like the one we're building in partnership with Umana Analytics has a cycle in which every new feature potentially touches sensitive data, and every change to the predictive models redefines the contours of the processing. A DPIA-as-form ages fast here: you write it, archive it, reread it a year later and discover its central paragraph no longer faithfully describes what the product is doing. A versioned DPIA-as-genre, by contrast, follows the product. Every pull request touching the processing perimeter opens a corresponding discussion on the relevant paragraph, which may stay unchanged or be updated with a diff that explains what changed and why. The healthcare platform for the Abruzzo region we've worked on for years, with its data flow towards a regional registry and national reporting systems, is an even clearer case, because every upstream regulatory change forces a re-reading of the processing — and without a versioned DPIA that re-reading risks losing the thread of the original motivations. With a versioned DPIA, you can start from the present and work backwards, decision by decision, to the point at which the processing was defined, reading the text alongside the discussions that accompanied it. A different case again is the online training platform we run for ECM-delivering bodies, where the DPIA must account for a relatively stable processing but a very large user base and an articulated chain of sub-processors. Here the value of a versioned DPIA lies mostly in keeping the accountability chain aligned as providers change, with every provider update becoming a commit on the relevant section — a coherence a form archived once a year cannot achieve. ## Authorial philology and the git log {: #authorial-philology-and-the-git-log } It becomes important to ask what it really means to version a genre. Literary criticism has a consolidated tradition here: what in Italy we call *filologia d'autore*, or *critica delle varianti* — authorial philology, the critique of variants — associated in the twentieth century with the names of Contini and Isella, and which in France took the name *critique génétique*, with figures like Bellemin-Noël and Pierre-Marc de Biasi. It studies how a text has grown over time, which variants were adopted and discarded, what external pressures modified the form, what rewrites were induced by revisers, commissioners, self-censorship. The git log of a versioned DPIA is, plainly, an *avant-texte* in real time. It shows when a mitigation measure was strengthened, who proposed it, in response to what report, with what alternatives considered and discarded. It produces, as a side effect, a level of traceability no form-DPIA ever had — because the form hides its history in its final version, whereas the genre puts it on display. And it displays it not out of archival narcissism, but because in a mature genre the history of choices is part of the current argument. An auditor who can read a git log can tell, without asking anyone, whether a given measure was implemented in response to real risk analysis or retrofitted to justify a choice already made. The genealogy of a text is a far more effective quality check than any signature at the bottom. Working inside this framework changes, in ways my experience shows to be progressive, certain operational dimensions. The first concerns the separation between source and rendering. A form-DPIA lives in its final PDF, with all the misalignment problems that brings: you modify the DPIA and then discover the processing record in another document says something different, or that the executive abstract is still at the version of six months ago. A genre-DPIA lives in a structured source — in our case Confluence, with certain key pages marked for the export pipeline — from which renderings for different readers are generated. The same source produces the complete DPIA for the DPO, an executive abstract for the board, a technical sheet of mitigations for the development team, and optionally a synthetic version for data subjects if the controller chooses to publish it. The content is the same; the form adapts. This demands, at the source, a more rigorous writing discipline than the form-DPIA ever required, because every paragraph must be built to survive multiple uses. In return, it drastically reduces what does most damage in compliance: the proliferation of misaligned versions of the same processing across different documents. The second dimension concerns the link with project ticketing. In every engagement of ours, a Jira epic or story that touches new processing of personal data, or modifies existing processing, opens a formal request to update the corresponding DPIA. Not necessarily a full update; even a no-impact check is enough, provided it's recorded. The link makes explicit what in the form-DPIA world was implicit, and therefore forgotten: every product choice is a compliance choice, every feature that touches data is a potential change to the documented processing. Linking the ticket to the DPIA paragraph is, in practice, enforcing that product and its act of writing proceed in lock-step. The git log becomes a genetic history of the processing; the Jira timeline becomes the history of its motivations. For a team used to treating compliance as a satellite activity to development, it's a non-trivial posture change, and it has to be supported. In the early months we had resistance from developers who saw the Jira–Confluence link as additional bureaucracy; six months in, most of them now consider it a help, because it reduces alignment meetings and makes the technical contribution to compliance visible. ## The DPO as editor {: #the-dpo-as-editor } The most delicate dimension concerns roles. In a form-DPIA model, the DPO is typically the main author or the final reviewer, and the technical team is an information supplier. In a genre-DPIA model this geometry partially inverts. The DPO remains responsible for compliance, but becomes more properly an editor: sets standards, reviews contributions, ensures consistency across sections, demands rewrites. Whoever writes the first draft of many sections is whoever knows the matter — the product owner, the architect, the developer who designed the data model, the DBA who set the retention policy. The final document is still signed by the DPO and the controller, but the weave of the text is woven by many hands. It's a thing anyone who has worked in editorial recognises immediately, and that anyone who has only worked in compliance finds disorienting. And yet, after six months of experimenting, it seems to me the healthiest configuration. I know I'm introducing a tension. A DPO who becomes an editor risks losing in formal authority what they gain in product quality. In the Italian tradition, where the DPO role is often legal and often external to the organisation, proposing a DPO-as-editor can sound like a weakening. I think, instead, it's a strengthening — for a subtle but important reason. The authority of an editor is not the authority of someone who produces the text alone; it's the authority of someone who decides what passes and what doesn't. A DPO who writes everything alone can produce a formally unassailable DPIA that is distant from the operational reality of the processing. A DPO who edits what the team writes remains in the final position of saying no, but does so on material that has a grip on the facts. The result, in my experience, is harder to attack and easier to defend in an inspection. ## Legibility is not simplicity {: #legibility-is-not-simplicity } Here we come to the second serious objection I want to address, raised in several internal discussions in recent months. One could say: this recognition of the DPIA as a genre isn't progress, it's needless sophistication, a baroquefication of compliance that adds burden without adding value. Europe, goes the argument, already suffers from regulatory inflation; turning the DPIA into a literary product — however technical-literary — means worsening a problem without solving it. I understand the objection, but I think it's wrong for a specific reason. Genres don't complicate texts; they make them legible. The alternative to a stabilised genre is not a simpler text, it's a text that's harder to read, because the grid letting the reader orient themselves is missing. When the same document reaches a supervisory authority's desk in ten different forms, written by ten authors each having decided their own structure, reading becomes extremely slow and carries a high margin of error. When the genre is stabilised, the authority can read a hundred DPIAs with the effort an experienced critic reads a hundred novels — by rapidly recognising where to look for what, and noticing just as rapidly the significant deviations. Legibility, in this sense, is not synonymous with simplicity. A sonnet is harder than a social-media post, but it's immensely more legible to anyone who knows the genre, because they know where to look for the argumentative turn, the central concept, the closing. In the same way, a well-written DPIA in the new format will be more demanding in detail but faster to read for an auditor who knows the template. And above all, it will be comparable with other DPIAs written in the same form. Comparability is the invisible benefit of stabilised genres, and it will be — I believe — the most important gain in the years ahead for data protection authorities. Until now, every inspection started from reading a document as if it were the first of its kind, reconstructing its form along with its contents. Once the new template is the standard, comparison across a hundred DPIAs from a hundred different controllers will become a feasible operation, because the form will be shared and the differences will be informative. There is a corollary of this comparability specific to those working with public-sector clients, and I want to develop it because it's the part of our portfolio changing fastest. In procurement procedures and technical specifications, the DPIA (or equivalent impact documentation) has often been requested as a generic attachment, with little specification on the «how». The administration verified the document existed, leaving substantive review to an often belated stage during contract execution. With a stabilised genre, contracting authorities will be able to do something different — and, from the competitor's point of view, far more demanding: to assess the document's quality as a selection criterion. A DPIA written inside the EDPB template can be scored consistently, compared to competitors', used as an indicator of the bidder's compliance maturity. For a supplier that has invested in writing as a practice, this will be a clear advantage, because it turns a ritual attachment into a differentiation tool. For a supplier that has always treated the DPIA as an administrative burden delegated at the last minute, it will be a growing risk, because the distance between a well-written document and a botched one will become obvious to anyone reading the template. In our specific sectors — regional healthcare, chambers of commerce, municipalities — I believe we'll see precisely this kind of selection appearing in award criteria over the next two years: a signal that the genre has entered public-sector contracting no longer as a box to tick but as an object of genuine reading. ## The LLM suspicion {: #the-llm-suspicion } There is a third objection that must be faced, even if it requires a digression, and which has been put to me by people very close to our technical practice. If the DPIA is becoming a document of argued prose, the argument goes, then it's exactly the kind of text a large language model can produce well in minutes. Why worry about all this talk of writing, of authorial philology, of editorial roles, when a good prompt and a couple of iterations will give you a formally impeccable DPIA? The question is legitimate, and I've asked it of myself, having worked intensively in recent months with AI-native development tools. The short answer is that the objection conflates two different things, and the conflation is dangerous. An LLM can indeed produce text that looks like a DPIA and will, in most cases, pass a superficial formal check. But a DPIA is not just its final text; it is the documentary trace of a decision process. Its sections are not an autonomous rhetorical display; they are the return of real conversations that took place between real people about real processing activities. An LLM can help me render those returns better, give the text rhythm, suggest more effective phrasings — and it does. It cannot substitute for the conversations upstream of the text, because those conversations are exactly what the DPIA has to account for. A DPIA produced by an LLM without those upstream conversations is a simulacrum, and the difference from the genuine becomes visible soon — particularly when the moment comes to defend it before someone asking precise questions. The genre, here, protects those who practise it honestly and exposes those who fake it, because the depth of a well-written DPIA is inseparable from the depth of the reflection that produced it. This, parenthetically, is a point the culture of AI-native development is learning in every domain it reaches: automatic tools are excellent amplifiers of thought, but not substitutes for thought. And it is precisely in mature genres that the difference between the two becomes clearest. ## An ecosystem of techno-normative genres {: #an-ecosystem-of-techno-normative-genres } There's a related point worth flagging, though it deserves an essay of its own. The genre-DPIA, precisely because it lives in the same ecosystem as the product, lends itself to integrations the form-DPIA could not have. I'm thinking in particular of the link with the SBOM, the software bill of materials, which is becoming an increasingly formalised requirement under the Cyber Resilience Act. The two documentations, SBOM and DPIA, have separate histories and different logics, but they speak about the same platform. When both live versioned and queryable, things become possible like: identifying which software components are involved in the sensitive-data processing described in Section X of the DPIA, or flagging when a dependency upgrade introduces a component that changes the documented risk profile. A developer updating a logging library, say, can automatically receive an alert: «this library is referenced in the DPIA for project Y, paragraph 4.2, check whether the new version changes the described behaviour». These are scenarios that, under an integrated product perspective, remain science-fictional; under an integrated compliance perspective they become — if not easy — at least thinkable. And the reason they become thinkable is, once again, that the DPIA is turning into a text governed by known conventions, navigable as a text is navigable, and no longer a grid opaque to the outside world. The SBOM–DPIA link, incidentally, is the point at which I realise the argument I'm making has implications wider than the DPIA itself. If the DPIA is turning into a genre, it's reasonable to ask whether other artefacts of European compliance are undergoing the same transformation, and in what direction. It seems to me evident, for example, that the AI Act technical file is also on trajectory towards a genre identity, with its canonical sections, its argumentative rhythm, its claim to legibility by a market surveillance authority. The same holds, at a different level, for vulnerability documentation and disclosure policies the Cyber Resilience Act is stabilising over the course of this year, with reporting obligations kicking in in September 2026 and full substantive obligations from December 2027. We are witnessing, in Europe, a decade-long operation of techno-normative genre generation, whose consequences for software work remain largely unexplored. Ten years ago, software compliance was a constellation of forms. Ten years from now, in all likelihood, it will be a library of genres, each with its own canons, its reference specimens, its consolidated criticism, its school of authors. This perspective, abstract as it may sound, has a concrete commercial implication that I think is still discussed too little. A firm that has learned to write inside mature normative genres has a substantial competitive advantage over one that has to learn from scratch every time. And learning to write inside a genre isn't something done in a one-week course: it requires practice, correction, exposure to good and bad specimens, peer critique, progressive experience of which phrasing holds and which doesn't. Europe is building, with uneven timing and coordination, an ecosystem of techno-normative genres that will reward organisations capable of making this writing a stable competence. For those of us who do this work — software for public administration and healthcare — it means the next five years will not be won by those who write more elegant code, but by those who write better compliance documents. By «better» I mean not more detailed but more legible, more argued, more capable of sustaining scrutiny from competent readers. It's a paradigm shift that cuts across our organisations and redefines which competences are scarce and which are not. I return, then, to the DPIA, with an observation I hope doesn't sound too abstract. The fact that a form is turning into a genre is one of those things that, once it has happened, retroactively changes how we read the preceding history. DPIAs written between 2018 and 2025 were already, to some extent, genre — because reading expectations existed, because specimens considered good or bad circulated, because authorities were starting to build an implicit jurisprudence of what a well-done DPIA meant. It was a genre in formation, fluid, with uncertain boundaries. The EDPB template, once the consultation closes and national adoption steps are under way, will fix those boundaries, crystallise the genre, and in doing so make retroactively visible a trajectory that was previously ambiguous. From that moment on, the DPIA will have a before and an after, and the difference between them will not be a matter of detail but of nature. The window in which we're writing now is exactly the moment this transition is completing: no longer before, not entirely after — it is the threshold. ## What to do tomorrow morning {: #what-to-do-tomorrow-morning } I realise all of this may sound, to a pragmatic engineer, like useless philosophical abstraction. What does it help me tomorrow, in concrete work, to know the DPIA is becoming a genre? I've already scattered the practical answer through the preceding paragraphs, but it's worth recomposing it into a form closer to what a team needs to do when opening the next project. Stop treating the DPIA as a closing document produced downstream of design, and start treating it as an accompanying document born with the project and growing with it. Accept that the people who contribute to the DPIA are no longer only legal and the DPO, but also whoever builds the product — and this requires a small but continuous investment in their ability to write argued text. Introduce, in development processes, the technical and organisational links between project tickets and DPIA paragraphs, so writing stops being a parallel activity and becomes part of current work. Rethink the DPO's role as editor rather than sole author, with everything that implies for relations with the rest of the team. None of these changes is dramatic on its own. Together they redesign how data compliance is practised, and surface the difference between organisations that have understood the shift and those that will keep producing forms in a world that reads genres. There is, then, something I want to flag to anyone, like us, operating precisely in this window of genre formation. The public consultation the EDPB has opened isn't a formal exercise concerning only data protection specialists: it's the moment when the template is still being shaped, and therefore the moment when an informed voice can leave a mark. A software supplier to Italian public administration sending a reasoned contribution, grounded in concrete experience writing DPIAs for public entities, participates in defining the genre more than they might imagine. This isn't a symbolic gesture: the consultation is the instrument through which European authorities gather edge cases, operational difficulties, incompatibilities with consolidated practice, and reformulate sections in response. In the next two months, from now to 9 June, there is time to contribute. After that, it will be late in the specific sense that the canon's forms will have been chosen. It's worth spending a day on it. ## An hour of rewriting {: #an-hour-of-rewriting } I want to close with an image that came to me a few weeks ago, re-reading for the umpteenth time a paragraph on mitigation measures in the DPIA for a healthcare project. The paragraph was formally correct, covered the required points, cited the right norms. But it was badly written, with that particular opacity that uncared-for technical texts have, where syntax is essentially a parking lot for clauses. I re-read it thinking: if an auditor reads this passage quickly, what do they take home? The answer was: almost nothing — because the text isn't made to be read quickly; in fact, it isn't made to be read at all. It's made to be present. It's compliance archaeology before it's even been filed. I spent an hour rewriting it, without adding content, merely ordering the rhythm. By the end the paragraph was 30% shorter and, most importantly, said the same things with a clarity it hadn't had before. The difference was editorial, not technical. But it was exactly the difference that separates a form from a genre. That hour of work, I think, is the exact measure of the change I'm trying to describe. In a form-DPIA world, an hour of rewriting on a formally correct paragraph is wasted time: the document is compliant, close the ticket, move on. In a genre-DPIA world, that hour is the only truly productive part of the day, because it's the only part that improves the text's quality as text. The transformation we're describing, in short, also changes the definition of time well spent. It changes what a team is authorised to consider work. And therefore it changes how work is to be planned. A sprint planning that reserves two hours a week to collaborative DPIA writing and review is not the eccentricity of a team that enjoys wasting time on technical literature; it's a team that has understood which documentary regime it is starting to operate in. A team that keeps treating the DPIA as an artefact to produce in one afternoon at project's end is, literally, living in a regime that is ceasing to exist. This small episode connects, in my head, to a thread I've been pulling on for months across apparently different things: software that doesn't age well, the product ceasing to be a stable category, the internet having been enclosed rather than degraded. In all these cases the underlying question is the same, and it concerns writing. When a technical artefact ceases to be self-sufficient and becomes part of an ecosystem of texts that document its existence, the text's properties matter as much as — and often more than — the artefact's. Modern software, I argued in *Cruft, Not Patina*, doesn't age because it's never finished enough to age. The DPIA, in a mirror image, can no longer be finished enough to be archived: it lives as long as the processing it documents lives, and each of its versions is a photograph in motion, not a monument. **Compliance is becoming, almost without anyone noticing, a practice of continuous writing rather than of final archiving.** And like every practice of continuous writing, it rewards those who take it seriously as writing, not those who fake it as form-filling. It's a direction that will demand more of whoever writes, but will also give back more, in the long run, in terms of decision quality, defensibility of choices, transmissibility of accumulated knowledge. Translating it into practice, into our own workflows, is the work ahead for the coming months. It's not urgent in the sense of deadlines; it's urgent in the sense that the longer one delays, the more writing debt accumulates. And writing debt, in a genre still stabilising, is hard to repay when the moment of judgement arrives. Anyone writing their first DPIAs in the new template now is also, perhaps without fully realising, taking part in the formation of a canon. Over the next two or three years, the aggregate of thousands of European organisations' concrete practices will decide which features of the genre become normal and which remain marginal. It's worth being there — for once, not as spectator but as author. --- # Cruft, Not Patina - **URL:** https://margiovanni.it/en/blog/cruft-not-patina/ - **Published:** 2026-04-19 - **Tags:** Software Development, Software, Philosophy OF Technology, Technical Debt - **Reading time:** 23 min > Buildings learn, Stewart Brand argued. Software, instead, accumulates comments that apologize. On why digital objects can't grow old — and what that says about the civilization that has put them at its center. Thirty-two years ago, Stewart Brand published a book called *How Buildings Learn*. Its thesis is simple and uncomfortable: a well-designed building isn't one that stays identical to itself, but one that knows how to be modified, inhabited, patched, reinterpreted over time. Brand photographs the same buildings decades apart and shows the alterations that tell their story. A staircase added to one side. A wall knocked down to merge two offices. A roof rebuilt after a fire. A façade painted three times and then left to flake. Architectural quality, Brand argues, isn't measured at the ribbon-cutting but in how the object holds up under stratified human use. The word he uses is *learning*: buildings learn, in the sense that their physical fabric accumulates information over the years, and at some point the accumulated information itself becomes part of the object's value. Software doesn't learn, in that sense. Software accumulates comments that apologize. ## The archaeology of old code {: #the-archaeology-of-old-code } Anyone who has worked on a codebase older than ten years recognizes a particular kind of comment. `// HACK: remove when we migrate to API v2`. `// TODO: figure out why this works`. `// DO NOT TOUCH: broke production three times`. They are signed by people who no longer work there, addressed to future readers who will never quite get around to resolving them. Are they patina? No — they are scar tissue. The difference isn't just lexical. An Alvar Aalto chair from 1932, if it has been genuinely used, now carries an aesthetic weight that the chair off the factory floor in '32 didn't have. The wood has darkened where hands rest. The matte finish has lost sheen unevenly; it has learned the body that sat in it. There may be a small repair at the joint between leg and seat, a replaced screw, a reinforcement tastefully done by some intermediate owner. None of this makes the chair worse. It makes it more beautiful, more valuable, more itself. A serious restorer refuses to strip patina, because patina has become constitutive of the object. Restoration is the art of distinguishing damage from history. A PHP application from 1998, if it has been genuinely used, carries no added aesthetic weight at all. It carries layered workarounds for browsers that no longer exist. It carries validation logic added three times at three different levels because at every maintenance cycle no one trusted what was already there. It carries four-hundred-line functions handling edge cases introduced by customers who stopped being customers a decade ago. No one proposes preserving this condition as part of the product's value. The industry word for it is *technical debt*, and the vocabulary gives the game away: debt, not history. Something to retire, not honor. The very words we use to describe our relationship with time reveal that we have no concept for calling an old system beautiful. The best we can manage is "solid," "battle-tested," "proven." These are virtues of resistance, not virtues of accumulation. The archaeology of old code is an informal discipline every senior engineer practices without ever having studied it, and it has its recognizable constants. There are the compatibility strata for long-extinct browsers: `if (window.ActiveXObject)` to detect old Internet Explorer, CSS hacks that exploited specific Firefox bugs from before the great rewrites, conditionals checking for `window.attachEvent` back when the browser field was genuinely plural and incompatible. There are feature flags still switched on for gradual rollouts that were never completed — half the code sitting behind `if (feature_active('new_checkout_flow'))` and the other half in the `else` branch, the feature at one hundred percent rollout for seven years, but no one brave enough to cut the dead branch because no one remembers exactly what it did. There are schema migrations begun and never finished, where two columns coexist in the same table, one with the old name and one with the new, both written by the application "just in case," read selectively depending on where in the code you happen to be. There are functions with names like `processOrderLegacy`, `processOrderLegacyV2`, `processOrderFinal`, `processOrderActuallyFinal` — a sedimentary log of cleanup attempts, none of which was ever really completed. None of this is patina. It is a sedimentary log of unkept promises, of intentions the business outran before they could be realized. If a furniture restorer found twenty overlapping coats of paint on an 18th-century dresser, each applied without stripping the last, he would not say the object had gained value through the layers: he would say it had been mistreated, and he would propose to remove them. Old code is treated exactly that way even by its practitioners, who call it *legacy* in a tone that mixes technical neutrality with a faint disdain. The word itself is perhaps the clearest tell of the field's unresolved relationship with its past: it comes from the Latin *legare*, "to bequeath," but in technical use it has come to mean nearly the opposite — something inherited against one's will. A burden, not a gift. ## Environmental drift, not aging {: #environmental-drift-not-aging } Why? Why do material objects gain something through time, while digital objects seem only to lose? An easy answer is that the difference is ontological: code is pure semantics; it has no material substrate on which the marks of use can settle. Wood breathes, absorbs moisture, oxidizes, wears at points of friction. A byte does none of this. A binary file today is bit-for-bit identical to the day it was written, barring accidental corruption of the storage medium, and that corruption carries no semantic value anyway: it tells you nothing about how the thing was used. The easy answer has the defect of every easy answer, which is to close the conversation at precisely the point where it ought to start. Let's go deeper. The reason a chair ages well isn't that it's made of wood; it's that its surroundings remain substantially stable. Gravity doesn't change. Human physiology doesn't change. The function of "supporting a seated body" doesn't change. The modifications the chair undergoes are internal modifications to its fabric, in dialogue with an environment that moves much more slowly than it does. The chair and the world around the chair age together, at roughly the same pace, and the result is a kind of domesticated co-evolution. Software exists in an environment that moves much faster than it does. The browser ships a new major version every four weeks. The language breaks backwards compatibility every two years. Libraries have a shelf life shorter than a parliamentary term. The operating system under it stops existing in the form it was compiled against. Software doesn't age internally, the way wood does. It progressively detaches from its environment, like a spacecraft that has run out of propellant and watches the station drift away. What we call "software aging" isn't aging in the chair's sense. It is environmental drift. It measures the growing distance between a fixed artifact and a context in motion. This difference is ontologically decisive. A building and its urban context age together in continuous dialogue, and that co-belonging is the very condition on which we can speak meaningfully of "aging" at all. Software has no co-belonging: it has *compatibility*, which is a much poorer relation. Compatibility means only that two things that don't speak to each other can keep pretending to, for one more release cycle. When Brand writes that buildings learn, he is describing a process in which the building and its inhabitants modify one another. When a systems engineer adds a compatibility shim to run an old binary on a new kernel, she is driving a wedge between two worlds that have stopped talking, and she is buying time. The shim is the opposite of learning: it is the admission that learning is not possible, and that only the appearance of communication can still be kept up. ## Ruskin, and the truth of use {: #ruskin-and-the-truth-of-use } There's a passage in Ruskin, in *The Seven Lamps of Architecture*, where he argues that a new building is by its nature false, and only becomes true through the frequentation of years. Ruskin is Victorian, emphatic, often insufferable, but that sentence is one of the most precise things ever said about the built object. The truth of a building lies not in the blueprint but in the history of its use. Apply the same criterion to software and you have to conclude that software never becomes true. It stays in a permanent state of newness even when its compile date is twenty-five years old, because the accumulation of history that would make it real in the Ruskinian sense isn't possible in its medium. The only thing it accumulates is mounting incompatibility with its surroundings — and that isn't history. It's erosion. ## The Unix objection {: #the-unix-objection } Here we have to face the strong objection — the one every technically literate reader has already been composing in their head, and which, left unanswered, makes everything above suspect. The objection is: Unix is more than half a century old, and not only still works but has become *more* elegant over time, not less. POSIX, TCP/IP, SQL, the hierarchical filesystem, the pipe. These are all ideas somewhere between forty and sixty-plus years old. They sit at the center of the planet's digital infrastructure. They don't behave like the 1998 PHP from earlier. They behave, if you like, exactly like Aalto's chair: objects that have crossed time gaining, not losing. Something in the argument doesn't add up. The objection is serious and deserves a serious answer. The easy response would be to call Unix an exception, an outlier, a lucky case that doesn't invalidate the rule. That would be a weak response. The more interesting answer is that Unix doesn't contradict the previous argument but exhibits its exact mechanism, and clarifies a distinction that has so far stayed implicit. The distinction is between software as code and software as specification. ## Spec, not code {: #spec-not-code } What we call "Unix" today is not, literally, the software Ken Thompson and Dennis Ritchie wrote at Bell Labs between 1969 and 1971. That code has been dead for decades. The commercial AT&T branch was sold, split, re-absorbed. BSD was forked many times, and every fork has since been rewritten. Linux — today the dominant form of "Unix" in global infrastructure — shares not a single line of code with the original Unix: it is an independent reimplementation, begun by Linus Torvalds in 1991, that exposes the same system interfaces (calls, filesystem structure, conventions) but was written from scratch. macOS descends from NeXTSTEP, which in turn rests on the Mach microkernel and BSD components, and here too the code has been rewritten and recast so many times that material continuity with the starting point is purely ritual. What has survived isn't Unix's body; it's its form. Its interface. Its grammar. The fact that there are system calls named `open`, `read`, `write`, `close`, working more or less as they worked in 1973, doesn't mean the code implementing them has aged well. It means the specification defining them has become a different kind of thing from code entirely. It has become culture, convention, shared language, norm de facto and then norm de jure via POSIX. The same goes for TCP/IP. The protocol survived; the implementation did not, or at least not in its original form. Every modern TCP/IP stack — from Linux to Windows to iOS to the ESP32 powering a smart bulb — has been rewritten or realigned many times over the decades. The 4.4BSD networking code, long a reference base for kernel networking in many systems, has been absorbed, branched, and reimplemented to the point that modern stacks hold a historical rather than material kinship with it. What persists, unchanged, is the RFC: a text document describing, in technical English, how two machines ought to speak to each other. The RFC isn't software. It is closer to a diplomatic treaty than to a program. That's why it ages well: it belongs to the same class of objects as a diplomatic treaty, a constitution, a grammar. It is a shared convention whose force comes not from its implementation but from the number of actors who recognize it as binding. SQL is the most instructive case. The `SELECT ... FROM ... WHERE` syntax was defined in the mid-1970s by Donald Chamberlin and Raymond Boyce at IBM. Today everyone uses it. But no relational database in production today runs on the original System R code. Postgres is a reimplementation. MySQL is a reimplementation. SQLite was written from scratch in the 2000s and is now probably the world's most widely deployed database by number of active instances, arguably outnumbered only by Excel spreadsheets. The code implementing SQL has died and been reborn so many times that material continuity is beside the point. What remained is the relational model, which is a mathematical object, and a certain syntax, which is a cultural one. Both detached from the code that first embodied them, and precisely because they did, they were able to cross time. ## TeX, SQLite, and the telling exceptions {: #tex-sqlite-and-the-telling-exceptions } There are, however, a handful of rare cases in which the code itself seems to have achieved something like patina, and they are worth looking at because they illuminate the general condition by contrast. TeX, the typesetting system Donald Knuth began writing in 1978, is one such case. At some point Knuth declared TeX finished, in the literal sense: no new features, only bug fixes, with the version number converging asymptotically to pi with each release — the explicit intent being that when Knuth dies, the version number will equal pi exactly, and the software will stop changing forever. Knuth offers a small monetary reward, doubling every year, to anyone who finds a bug in TeX, and for many years now no one has claimed it. Not because there aren't bugs left, but because the software has been used so thoroughly, for so long, that the remaining ones live in corners no one ever visits. TeX works today as it worked in the late 1980s; it compiles the same source files and produces the same typographic output. Its source code, written in WEB (Knuth's own literate-programming system combining Pascal for logic and TeX for documentation), was published in 1986 as *TeX: The Program*, Volume B of *Computers and Typesetting*, and is treated as a literary work. It has been read, commented on, studied. It is one of the rare times code has crossed the threshold from pure implementation into something like specification — but in the concrete form of the program, not in the abstract form of an RFC. Knuth achieved this by imposing an extreme condition on his own work: refuse every evolution. TeX doesn't age because, in a sense, it chose not to live. It accepted mummification as the price of permanence. SQLite is the other interesting case, more recent and less mystical. Its developers have publicly declared, in the project's documentation, the intention to maintain the library at least through 2050, with full backwards compatibility of the C API and the on-disk format. That commitment isn't boilerplate; it is a concrete constraint that follows from the fact that SQLite is embedded in avionics systems (the Airbus A350 among others), medical devices, and military equipment — all objects whose life cycles exceed forty years. To sustain such a horizon, SQLite has built a test apparatus that, according to figures its own developers publish, runs to roughly ninety-two million lines of test code against one hundred fifty thousand lines of actual library, a ratio of nearly six hundred to one. Every conditional branch is covered by MC/DC tests, the standard used in avionics for DO-178B certification. The code itself is written with explicit attention to the fact that it will be read and maintained by people not yet born. SQLite took duration as a design problem from the start, and has treated the stability of its own interface as an ethical question more than a technical one. The result is a piece of software that has existed for more than twenty-five years, runs on billions of devices, and has never prompted anyone to rewrite it from scratch. It's a case where the code itself, not just its specification, seems to have aged well. But look a little closer and you see the result was achieved only by accepting constraints the rest of the industry would refuse. SQLite almost never changes, even at the cost of giving up features that would make it more modern. SQLite has no external dependencies, almost as a protest against the way the rest of the world builds software today. SQLite has an internal culture that borders on monastic. In other words, SQLite ages well because it built itself an ecological niche in which the environment around the code has been artificially stabilized. It recreated, inside a small perimeter, the conditions that let an Aalto chair become more beautiful with the years: an environment that moves slowly, a user who pays attention, a culture that recognizes the value of duration. It is no accident that these examples are, statistically, anomalies. They are the exceptions that reveal exactly which conditions are necessary for software to age — and confirm that in the main body of the field, those conditions do not exist. ## The body dies, the spec resurrects {: #the-body-dies-the-spec-resurrects } Viewed from this angle, Unix doesn't age well. Unix is continuously resurrected. The body dies and is remade from scratch, starting from a specification that has meanwhile become sacred enough to warrant wholesale rewriting of the body every twenty or thirty years. It has the structure of a religion more than of a material object. Aalto's chair, to stay with the metaphor, has never been rebuilt from scratch: the chair from 1932 is physically there, dents and all. If we applied the logic of Unix to wood, we would have to say the concept "Paimio chair model 41" survived because Artek, since its founding in 1935, has continued production for over ninety years, and the chairs of 2026 are descendants of those from 1932 without being the same chairs. It would be true, but beside the point: what interests us about the 1932 chair is precisely its material duration, not the persistence of its model. With software it is the opposite. We don't care about the original code, and no one preserves it as a relic. We care about the persistence of the model, and that persistence requires the periodic destruction and rewriting of the code. The Unix objection, then, doesn't refute the argument; it sharpens it. What ages well in the digital isn't code. It is specifications that have been lucky enough, and well-capitalized enough, to rise above their implementation substrate and become something else. Standards. Stable interfaces. Lingua francas. Most code never reaches that level and cannot reach it. Ninety-nine percent of the software running today will not become POSIX. The custom CRM for a four-hundred-person company will not become SQL. A retail chain's e-commerce site will not become TCP/IP. Not because it's badly written, but because it isn't that kind of object. It is, structurally, implementation. And implementation, in digital, cannot age well, because it has none of the requirements for doing so: no material substrate to register use, no stable environment to persist in, none of the cultural weight that permits periodic reincarnation. ## Rewriting isn't a sin {: #rewriting-isnt-a-sin } This distinction clarifies an old debate inside the field that has always been badly framed. In 2000, Joel Spolsky wrote a widely circulated article, *Things You Should Never Do, Part I*, arguing that rewriting functioning software from scratch is the worst strategic mistake a software company can make. The specific case was good: Netscape had lost the market because it decided to rewrite its browser from scratch, leaving the window open for Internet Explorer for three years. The problem with Spolsky's essay is that it generalizes from that one case without acknowledging that most software *has* to be rewritten, sooner or later, because it cannot be maintained indefinitely in the form it was conceived. Unix has been rewritten many times. Linux itself, at the level of individual subsystems, is being continuously rewritten: the scheduler has been replaced, the networking stack has been redone, the filesystem has been rethought. What Spolsky called "never rewrite" was really "don't lose the continuity of the specification during the rewrite," which is a very different and much harder thing. A rewrite fails when it loses contact with what the code was doing for its actual users. It succeeds when it preserves the specification and throws the implementation away — the way a Catholic body is buried but the soul moves on. ## A dignity denied {: #a-dignity-denied } If this reading is correct, then the low-grade melancholy running through much of everyday technical work has a structural, not psychological, explanation. We aren't writing badly. We are writing objects that cannot age, because we don't belong to the narrow class of artifacts that can rise to the level of cultural specification. Ninety-nine percent of what we write is destined to die without trace — not through poor craftsmanship but through a property of the medium. A thirteenth-century mason knew that a good wall would still be standing in the sixteenth century, and probably much later. A twentieth-century plumber knew that his pipes, with a bit of maintenance, would serve three generations. A developer in 2026 knows that the code she is writing today will, with reasonable probability, be decommissioned within five to seven years. Not because it's written worse than pipes. Because the pipe and the wall belong to a regime in which aging is possible, and code does not. This changes the ethical character of the trade in ways we have not yet metabolized. For millennia, building something durable was among the highest forms of dignity in human work. The cathedral, the bridge, the printed book, the violin. Objects made with the consciousness of lasting beyond the life of their maker. Software development is one of the few highly skilled trades in which that dignity is structurally foreclosed. Not because no one works well, but because the medium does not admit that kind of duration. The technical debt we opened with, seen from this angle, is not a defect manageable through better practice, tighter discipline, more rigorous testing, sharper code review. It is the specific form the unavoidable deterioration takes in an artifact that has no other way to deteriorate. It is how software ages badly because it does not know how to age any other way. ## The lamp of memory {: #the-lamp-of-memory } There is a broader reading here, one that leaves the strictly technical domain and touches something more uncomfortable about the culture we live in. Ruskin, again, identified seven virtues of architecture, which he called lamps. Sacrifice, truth, power, beauty, life, memory, obedience. The lamp of memory was, for him, the virtue of buildings that let themselves be crossed by time without resisting it, that preserve the traces of those who inhabited them, that become, in their way, biographical archives of human passage. A civilization that cannot build objects capable of memory, Ruskin said, is a civilization that has given up one of its fundamental functions: the transmission of itself through its things. The digital, from this point of view, is the exact opposite of Ruskinian architecture. It is a material culture — if it can still be called that — in which memory doesn't accumulate in things but leaves them. Five-year-old software is already an antique. A website from ten years ago is no longer reachable; its domain has lapsed, its links are all broken, its images point to decommissioned servers. Digital archives exist only thanks to heroic and marginal efforts: the Internet Archive is a single point of failure for three decades of online culture, and no one has really figured out how to replace it. Our photographs sit on servers we don't own, in formats that may not be readable in twenty years, protected by service agreements that can be changed unilaterally. Our correspondence is in mailboxes that will vanish when the company hosting them changes business model. The material continuity of human inheritance — imperfectly guaranteed for millennia by the physical persistence of objects — has become precarious in a way no previous civilization had known. That precariousness is not a side effect but a structural property of the medium. And software, which is at the heart of this new condition, inherits and amplifies the precariousness. It doesn't age because it cannot accumulate memory in its fibers. It has no fibers. Its only form of continuity is rewriting, which is the exact opposite of memory: the periodic production of a new object that pretends to be the same. Someone at this point may object that I am dramatizing, that every era has had its precariousness, that papyrus decayed and parchment was scraped and the printed book burns. True — but the quantitative difference is so large it becomes qualitative. The average durability of a well-kept printed book is measured in centuries. The average durability of a digital file is measured in years, perhaps decades in lucky cases. The delta is one or two orders of magnitude. A civilization in which cultural objects last a hundred times less than in the previous one is a structurally different civilization, not merely quantitatively but qualitatively. It has a different relationship with time. It produces a different subjectivity in those who live inside it. A developer knows, in a way a sixteenth-century printer did not, that his work will not outlive him. ## The ephemeral objection {: #the-ephemeral-objection } There is a less tragic way of reading all this, and it's worth working through before closing. The objection runs like this: maybe permanence isn't necessarily a virtue; maybe software is a form of deliberately ephemeral cultural production, in the sense in which a theatrical performance or a jazz set are ephemeral — and their ephemerality is not a defect but a constitutive feature of how they exist in the world. A lambda function that runs for thirty-seven milliseconds and disappears isn't a failed object because it doesn't last; it is a fully realized object because it did exactly what it needed to do in the time it needed to do it. The monument metaphor, inherited from architecture, may simply be the wrong fit for the medium, and insisting that software "doesn't age well" may be like complaining that a thunderstorm doesn't age well — a category error. The objection is interesting, but it breaks the moment you take it seriously. The problem is not the code that runs for thirty-seven milliseconds. That really is an event, not an object. The problem is that nearly all the software we depend on in daily life is not an event in that sense: it is infrastructure. The system our bank uses to manage accounts is not a jazz performance. The medical software running the ICU ventilator is not a thunderstorm. The municipal registry database is not an ephemeral function. They are objects that claim to be infrastructure, that we treat as infrastructure, that institutions embed in their processes as if they were infrastructure, and yet that have the durational and memorial properties of a cloud. This discrepancy — between the social function software performs and its material durational properties — is the point at which the question stops being philosophical and becomes civic. A society that entrusts its vital functions to objects that cannot grow old is, quietly, shifting the cost of maintaining its own continuity onto a technical layer that cannot carry it. ## Precarious infrastructure, law playing catch-up {: #precarious-infrastructure-law-playing-catch-up } Seen from this angle, the European Cyber Resilience Act — adopted as Regulation (EU) 2024/2847, fully applicable from December 2027 — along with the new Product Liability Directive (EU) 2024/2853 and the obligations under NIS2, are clumsy but telling legislative attempts to force software to behave like serious infrastructure. They require producers to define a support period reflecting the product's expected life cycle — at least five years in most cases — to keep SBOMs up to date, to answer for vulnerabilities introduced into the product even after sale. They are, in a sense, a legislative attempt to impose on software the durational properties it does not naturally have. That these rules exist, and that the industry perceives them as an added cost rather than an acknowledgment of civic responsibility, says something about how deeply developers have internalized ephemerality as a professional privilege. A mason knows he must answer for his wall for many years. A developer is used to answering for her code until the end of the contractual warranty — typically twelve or twenty-four months. The two trades have horizons of responsibility that differ by an order of magnitude, and the difference is invisible in the language we use to describe them. ## An ethics of duration {: #an-ethics-of-duration } Coming back to the initial question — why software cannot age — we can now give a less lapidary answer. It cannot age because it is made of a material without grain, in an environment that moves faster than it does, inside a productive culture that has given up on considering duration one of the dimensions of value. Each of these three factors is a sufficient cause of the result, and together they make the result nearly inevitable. The first is ontological and probably unresolvable: code will never become wood. The second is systemic and could be mitigated, if the technical culture learned to treat stability as a virtue rather than a sign of being behind. The third is purely cultural, and it is the only one on which we can really act. Act how? Probably in directions the field currently considers regressive. By slowing release cycles. By preferring backwards compatibility to elegance. By writing less code and more specification. By treating stable interfaces as monuments — objects whose value lies in their resistance to change. By accepting that most code will not become Unix, and that precisely for that reason, it ought to be written with some consciousness of its transient destiny — without the false ambition of duration and without the nihilistic despair of its absence. A trade that knows it isn't building cathedrals but refuses to build shacks. An intermediate dignity, for which we don't yet have a good name, and which may be one of the things this generation of technologists should try to articulate. If there is any consolation in the fact that software doesn't age well, it is that this property forces us, by contrast, to bring into focus what aging well means in general. It forces us to recognize that the patina on Aalto's chair is not an automatic fact of wood, but the result of a long relationship between a well-made object, a stable environment, an attentive user, and a culture that knows how to recognize the value of that triangulation. When one of those terms drops out, patina doesn't form. Wood left in the rain doesn't acquire patina; it rots. Wood sealed in storage doesn't acquire patina; it desiccates. Patina is a collective work that requires time, care, and context. Software, as things stand, has none of the three, and the idea that it might sounds like a nostalgic fantasy. It isn't. It's a design question. **What would it mean to write code knowing it had to last as long as a wall?** We don't really know yet, because we've almost never tried in earnest, and when we have, it has almost always been in domains marginal to the mainstream: avionics, industrial control, legacy banking systems — places where duration is imposed from outside as a regulatory constraint rather than chosen as a cultural value. Civil software — the software that builds the public and private life of most people — has been built on the implicit assumption that duration isn't its problem. That assumption is becoming untenable just as society is delegating more and more vital functions to software. Among the responsibilities of this generation of technologists, formulating an ethics of duration for the trade is probably among the most serious, and among the least postponable. What remains, in the end, is the underlying question. Software doesn't age well. At the start, that sentence sounded like a technical grievance. Arrived here, it's clear it is something different. It is an exact description of the kind of artifacts we have collectively decided to place at the center of our shared life, and an implicit demand to reckon with that decision. The objects at the center of a civilization ought, within the limits of the possible, to know how to accompany it through time. If they don't, we should either change them or change the place they occupy. Thus far we have done neither. We have let them occupy the center while behaving as though they were at the periphery, and we have called that condition "progress." It's worth starting to call it by a more accurate name. --- # Mrs. Donoghue's Last Bottle - **URL:** https://margiovanni.it/en/blog/mrs-donoghues-last-bottle/ - **Published:** 2026-04-18 - **Tags:** Compliance, PLD, EU Regulation, Philosophy OF Technology - **Reading time:** 30 min > Why the «product» on which modern liability law is built no longer exists in contemporary software — and what we might put in its place. On 26 August 1928, a Glasgow woman named May Donoghue walked into a café in Paisley, a town about seven miles from the city centre, with a friend. Her friend ordered and paid for a *Scotsman ice cream float* — ice cream served with ginger beer. The drink was served by the owner of the Wellmeadow Café in an opaque bottle of dark glass, of the kind common at the time precisely because cloudy glass hid any sediment in the contents. When the second half of the liquid was poured into the glass along with the melted ice cream, a snail in an advanced state of decomposition came out of the bottle, carried along by the fizz. May Donoghue fell severely ill with gastroenteritis, was seen by a doctor on 29 August, and was admitted as an emergency to the Glasgow Royal Infirmary on 16 September. Four years later, in 1932, the House of Lords handed down a ruling that is considered the cornerstone of modern product liability law in the common law world. ## The snail in the bottle {: #the-snail-in-the-bottle } The decision was taken by a majority of three votes to two. The majority opinion was written by Lord Atkin, who in the famous passage every law student still memorises today formulated what became known as the *neighbour principle*: the legal duty each of us owes to take care of our neighbour, where «neighbour» means anyone who could reasonably be foreseen as affected by our conduct. From that moment on, a manufacturer is liable for its product even to those with whom it has no contractual relationship — even if the bottle passes through a distributor and a café before reaching the consumer, even if weeks of warehousing and miles of road lie between the factory and Mrs. Donoghue's gastroenteritis. What almost no one notices, reading the judgment, is that in order to write the neighbour principle the court needed a precise ontological presupposition: a certain idea of what the object in question actually was. The object was the bottle. A *bounded* artefact, with sharp edges, identifiable, examinable, preservable. The bottle was produced in a specific plant — at David Stevenson's in Paisley — filled at a dated moment, sealed with a stopper that guaranteed its integrity up to the point of sale. If necessary, lawyers could have demanded to examine the production batch, analyse the composition of the glass, trace the supply chain of sugars and flavourings. The material cause, in the Aristotelian sense, was reachable. The efficient cause — the production process — was documented. The formal cause — the typical shape of a ginger beer bottle — was known to anyone. The whole modern law of product liability built on top of *Donoghue v. Stevenson* presupposes this utterly simple and absolutely crucial thing: that you can point your finger at an object and say «this», and that the finger finds something at the other end. ## The new PLD and the problem of a category {: #the-new-pld-and-the-problem-of-a-category } In 1985, Europe, with Directive 85/374/EEC, adopted the Donoghue principle in continental form, extending and systematising it. The *Product Liability Directive* speaks of «defective products» and establishes a strict, no-fault liability for the producer for damages caused by the product. Forty years later, on 23 October 2024, Directive 2024/2853 was adopted, entered into force on 9 December 2024, and must be transposed into national law by 9 December 2026, the date on which the 1985 directive is repealed. The new PLD was designed expressly for software, and includes in the definition of product digital files, software components, applications, and AI systems. It is one of the most ambitious reforms of civil liability law ever attempted by the European Union. The fact that it took forty years to be rethought, and that despite the enormous effort of its drafters it risks being inadequate the day it enters into force, is no one's fault in particular. It is the consequence of a problem that the law has not yet been able to name precisely. The problem is that the «product» on which Lord Atkin and his successors built two centuries of jurisprudence no longer exists in contemporary software. It is worth taking a minute to understand where it went, because diagnosis is the starting point for everything that follows. ## From record to concert {: #from-record-to-concert } For a long time, software was a product in the full, conventional sense of the word. It emerged from the Bell Labs lab and entered mass distribution with Unix, then with operating systems for personal computers. An application of the 1980s or 1990s was a set of files distributed on floppy disks, then on CDs, then on DVDs, with a version number, an identifying hash, a copy that could be kept in a vault. If the software had a defect, you could, at least in principle, isolate the exact version of the binary, compare it with the supposedly correct one, identify the bug. Windows 95 was a product. Microsoft Word 97 was a product. Even a game like *Baldur's Gate* was a product, with its numbered, archivable patches. Of course, even then software depended on things that were not the product in the strict sense: device drivers, firmware, network protocols, system services. But those dependencies were static, declared, limited in number, and above all mediated by a self-sufficient artefact that could be preserved and reproduced many years later. The copy of the Windows 95 CD that a digital archivist keeps today is still identical to the one from 1995, bit for bit. The product, as an object with continuity in time, existed. In the early 2000s something began to change, and the pace of change accelerated dramatically over the following decade. The transition to *software as a service* moved the application from the customer's local disk to the vendor's server. At first it was a simple matter of distribution, but very quickly it became an ontological transformation. When the application runs on a remote server, the version of the application the user is using at any given moment is no longer a stable property, it is a momentary one, renegotiable by the vendor at any instant without even notice. *Continuous deployment* takes this fluidity to its natural conclusion, with companies shipping tens or hundreds of changes to production per day, and no one — not even internally — able to reconstruct exactly what the system's configuration was at 2:23 p.m. on a Tuesday three months ago. Meanwhile, and in parallel, the internal composition of software changes in nature. From the early 2010s onward, thanks to ecosystems like npm for JavaScript or Maven for Java or PyPI for Python, writing an application means importing hundreds or thousands of third-party packages, each in turn made up of third-party packages, in a graph of transitive dependencies that no human reads in full and that updates continuously and asynchronously with respect to the code you yourself wrote. The *left-pad* incident of 2016 — when a single developer unpublished an eleven-line package from npm and broke a large fraction of JavaScript build pipelines and install processes worldwide — was the moment when the industry noticed, for an instant, how fragile and distributed the thing it still called a product had become. The latest acceleration, the one we are living through right now, is the entry of language models into the production chain of software. Here the leap is not only quantitative but categorial, because what enters the product is no longer a set of deterministic instructions but a probabilistic component whose outputs are not exactly reproducible even from the same inputs, and whose weights, once retired by the vendor in favour of a successor, may no longer be accessible at all. An application running today and using the API of a frontier model is an application whose observable behaviour depends on a component that tomorrow may behave differently, that two years from now may no longer exist in any recoverable form, and whose internal workings are not inspectable by anyone — not even by those who trained it. Anyone writing software today knows perfectly well that if a user from five years ago asked us to reproduce exactly the bug they had seen back then, the honest answer would be that we can't: the system that produced that bug no longer exists in any restorable configuration. Dependencies have been updated, external APIs have changed contract, the database has been migrated, the AI model has been replaced. We have the logs. We have the code of our application. But the event that produced the bug was a concert, and what's left of concerts is recordings, not concerts. This is the metaphor that I think captures the ontological shift underway best. Contemporary software is no longer a record. It's a concert. A record is a stable, preservable, comparable artefact — an object with its own identity in time. A concert is an event distributed in space and time, co-produced by many agencies in real time, unrepeatable, of which you can have traces but not originals. When we listen to the recording of a Keith Jarrett concert from 1975, we are listening to a derived artefact — we are not listening to the concert, which happened once and is over. The same holds for a SaaS application today. What the user experienced yesterday at 11 a.m. was an event co-produced by the application, by the user's browser, by network latency, by the current version of the underlying LLM, by the configuration of twelve third-party APIs, by a rate limit that at that exact moment had a certain value. That event is not reproducible, not preservable, ontologically not an object. It is, precisely, a concert. ## The objection and the copy that isn't there {: #the-objection-and-the-copy-that-isnt-there } Someone, at this point, might object that the distinction is overstated, that after all even in 1998 software ran on an operating system that depended on drivers and hardware, that runtime contingency existed back then too, that every use of an application has always been, in some measure, an event rather than an object. The objection is partly correct, and taking it seriously matters, because it is the only way to keep diagnosis from collapsing into nostalgia. The difference that changes everything, however, is one and only one — and it is the difference the law has not yet metabolised. In 1998 there was always a copy of the artefact. In the strictest, most concrete sense of the term, in the vendor's vault or on the user's hard drive or in some digital archivist's storage, there was a material object that contained the software in its autonomous form. That copy was the point of contact between the legal product and the executive event. It was the Archimedean point that made it possible to go back, examine, compare, judge. It was what let the lawyer say «this product was defective» because a product was there. Today that copy no longer exists, and it does not exist not because of negligence or bad choice, but by construction. Vendor X's SaaS application at 2:23 p.m. on a Tuesday three months ago exists in no backup, no vault, no archive. What exists is only the possibility of reconstructing, approximately and partially, what it must have been, by cross-referencing logs, code versions, dependency configurations, model weights, database state. This is an archaeological reconstruction, not an access to the object. And even when such a reconstruction is complete, the result would be yet another thing — a model of the application at that moment, not the application at that moment. The product, in the two-century-old legal sense, has vanished. What exists in its place has never been named. ## The European corpus and its categorical misalignment {: #the-european-corpus-and-its-categorical-misalignment } To their credit, European legislators have noticed that something isn't adding up. In recent years they have produced an impressive package of rules trying to grasp the new object with the tools at hand. The Cyber Resilience Act, which came into force in December 2024 with full application in December 2027, introduces the concepts of *security by design* and *security by default* for products with digital elements, imposes support obligations across the full lifecycle, requires the provision of a *Software Bill of Materials*. The new Product Liability Directive, the 2024 one mentioned above, explicitly extends liability to cybersecurity defects and to malfunctions from software updates. The Artificial Intelligence Act, in force since 1 August 2024 with general application from 2 August 2026 (and some provisions slipping to 2 August 2027), classifies AI systems by risk and imposes obligations of documentation, transparency, and conformity assessment. Add to these NIS2 for network security, DORA for the financial sector, the Data Act, the European Accessibility Act. Together they form the most ambitious regulatory corpus ever built to govern software production, and they are a serious, technically informed, culturally important effort. It would be a mistake to dismiss them as bureaucracy or as a brake on innovation, as a certain libertarian Californian vulgate likes to do. The thesis of this essay, rather, is that — serious and important though they are — these instruments are trying to capture the concert with the categories of the record, and the categorical misalignment is bound to generate consequences we are only beginning to glimpse. The case of the Software Bill of Materials is paradigmatic of this difficulty, and it is also the one I know best for professional reasons. An SBOM is a document that lists all the components that enter a software product, their versions, their dependencies, their licences. On paper it's a perfectly sensible tool, the software equivalent of the ingredients list on food packaging. In practice, an SBOM is a photograph of a concert, with all the epistemic limits that condition entails. A photograph of a concert is not the concert — it is already another object: derived, partial, dated. In the very moment the photograph is taken, the concert is already changing, and a tenth of a second after the shutter closes, transitive dependencies may have updated, the external API version may have changed, the model weights may have been swapped by the vendor. The SBOM captures a state, but contemporary software has no stable states, only flows. The regulation therefore requires developers to keep the photograph up to date, which in turn generates processes of *continuous SBOM generation*, with tools producing the SBOM on every build, every deploy, ideally in real time. The paradoxical result is that the document that was supposed to capture the identity of the product multiplies into thousands of daily snapshots, each of which is already obsolete the moment it is generated. The SBOM does not capture the product, because there is no product. It captures the flow, in the form of discrete frames, and each frame is a legally relevant document. The resulting documentary load is enormous, and its probative value, when it comes to reconstructing who was responsible for what at a precise moment, is far less clean than legislators assumed. The same problem, compounded by the stochastic nature of the models, arises for the AI Act. Article 10 asks that training datasets be documented, traceable, governed according to quality criteria. Article 15 asks that high-risk AI systems be accurate, robust, cybersecure. Article 72 requires post-market monitoring. Each of these obligations, taken in isolation, makes sense, and points to practices that the best machine learning engineering should already be adopting. What legislators have not fully absorbed is that the language model a vendor offers today via API is an object whose identity in time is, at best, conventional. The model's weights get updated, the RLHF system gets refined, the guardrails modified, and what continues to be called GPT-4 or Claude Opus or Gemini Ultra is, from the standpoint of observable behaviour, a different object from what bore the same name six months ago. Asking for training documentation means asking for documentation of something that, by the time the documentation is produced, may already have been superseded by another training run. Post-market monitoring is excellent practice, but it presupposes a market in which the product is the same at the time of sale and at the time of use — something that is almost never true for language models. This isn't to say the AI Act is wrong, because the AI Act is one of the most articulate regulatory responses ever attempted at comparable scale. It is to say that the AI Act inherits from product liability law a set of ontological presuppositions that the object it tries to regulate does not satisfy, and that the tension between presuppositions and object will fall, in the coming years, onto the shoulders of practitioners — in the form of compliance obligations of ambiguous value, documents whose relation to reality is hard to establish, controversies in which the dispute between parties shrinks to a debate over whether a given snapshot was representative of the system at the moment of harm. ## CrowdStrike, July 19, 2024 {: #crowdstrike-july-19-2024 } A recent example, of such reach that it has entered risk management courses all over the world, helps to see concretely what all this means. On 19 July 2024, a faulty update of CrowdStrike's Falcon sensor caused the simultaneous crash of roughly 8.5 million Windows machines around the planet, with a boot loop that required manual intervention on each device to resolve. Airports grounded, hospitals reverting to paper operations, banks offline, broadcasters dark, emergency calls not routed. Delta Airlines alone declared over half a billion dollars in direct damages, Fortune 500 companies declared uninsured losses in the order of $5.4 billion, with global estimates placed by various sources in the tens of billions. In the ensuing litigation, still open in multiple jurisdictions, the whole question has focused on one point: who was responsible? - **CrowdStrike**, which pushed an update containing a defect any careful test would have caught. - **Microsoft**, which allowed third-party software to operate with kernel-level privileges sufficient to boot-loop the operating system. - **The deployer organisations**, which accepted auto-push updates without canary stages. - **European regulators**, according to Microsoft's defence, which years earlier had forced the vendor to open the kernel on competition grounds. Each of these four attributions of responsibility, taken singly, captures a real aspect of the affair. None, taken singly, tells what happened. What happened was an orchestration failure: an event in which many actors each held, at their own level, actual influence over the system's runtime behaviour, and in which no one had exercised that influence in proportion to the possible consequences. Current law has no adequate tools to distribute liability this way, and litigation is sliding, as a result, toward scenarios where the better-lawyered party wins or where the most defensible contractual position prevails — which is another way of saying the law has given up on saying anything substantive about the incident. A case like CrowdStrike, read through the lens of the responsible-assemblage category I am trying to sketch, should have produced a ruling that distributed liability in identifiable shares across the various actors as a function of their blast radius and their degree of effective control, and that created a precedent usable for future incidents, which will certainly be many. None of this is happening, because the category for doing it isn't there. ## Latour, Ricœur, and the plurality of action {: #latour-ricoeur-and-the-plurality-of-action } Before going further, it is worth clarifying that responsible assemblage is not an invention *ex nihilo*. It is the adaptation, to the legal domain, of reflections twentieth-century philosophy developed in other fields and that have not yet made sufficient inroads into courtrooms. Bruno Latour, with *actor-network theory*, had already shown in the 1980s that complex actions never have a single agent — they emerge from networks of human and non-human actors whose analysis requires suspending the obsession with the individual subject and following the actual connections. His canonical example of the artificial speed bump — the so-called *sleeping policeman* placed on the road surface — is illuminating, because it shows how the bump enforces the speed limit independently of any human officer's presence, acting as a non-human actor endowed with its own agency. The car slowing down is co-produced by the driver, the bump, the traffic code, the fear of damaging the suspension, and the shared culture that recognises the bump as a signal to slow. None of these five actors, taken alone, explains the slowing down, and none of them, taken alone, is fully responsible for what happens when something goes wrong. Positive law tends to place responsibility on the driver for practical reasons, but the philosophical understanding of the event requires seeing all five together. The step the law has not yet taken, but philosophy has taken for forty years, is to accept that this distribution of agency is the rule, not the exception, and to derive its consequences for the attribution of responsibility. Paul Ricœur, in *Oneself as Another* (1990) and in the subsequent reflection on imputability, added a complementary piece, showing that the act of attributing responsibility is a narrative act — it requires reconstructing a plausible story of causation, and when the plausible story involves many agents, imputative narration cannot be reduced to a single subject without betraying the truth of the event. For Ricœur, imputation is a hermeneutics of responsibility, and like any hermeneutics it demands patience, attention to different levels, refusal of simplification. Contemporary product liability law simplifies too much, and does so because it has inherited a nineteenth-century narrative grammar in which the producer was one, identifiable, imputable. Reconstructing imputability for contemporary software means accepting the plural nature of action and letting it show through in the text of the judgment itself. ## Responsible assemblage {: #responsible-assemblage } If we stop here, the diagnosis risks looking pessimistic or purely critical, in the style of a certain tech-sceptical literature that takes pleasure in difficulties without proposing anything constructive. The point I want to try to develop is the opposite, because if it's true that the concept of product no longer sustains its function of attributing responsibility, we have to start imagining what its replacement category might look like. This is an intellectual undertaking that cannot be delegated either to pure lawyers, who have no contact with the runtime of real systems, or to pure engineers, who tend to treat law as an external annoyance rather than as an attempt to attribute moral meaning to what they do. The replacement category must be thought out with four hands — by those who have code practice and legal reading — and it must start from the observation that contemporary software is an orchestration, an assemblage, a distributed event, not an object. I propose to call it, provisionally, **responsible assemblage**, aware that the name is not yet final and that the argument over the name is part of building the thing. What would a responsible assemblage be, in first approximation? It would be a configuration of components — human and non-human — organised around a specific function offered to a user, in which no participant holds integral control but each exercises an identifiable degree of effective influence over the observable behaviour at runtime. Liability, in this framework, no longer follows formal ownership («whoever holds the contract answers for everything»), nor the historical origin of components («if the bug is in the imported library, then the library maintainer is to blame»). Liability follows the gradient of effective influence. Whoever was able, at the moment of the harm, to change the system's behaviour through a targeted technical action answers in proportion to the degree of that possibility. The AI model vendor who could have updated the guardrails and didn't answers for a share of liability. The integrator who chose that model for a sensitive function without adequately assessing the risks — while having the tools to do so — answers for another share. The user who configured the system in an anomalous way, bypassing the warnings, answers for a third. None of the three answers for everything, none answers for nothing. Each answers for their portion of the orchestration. The formula is easy to state and infernally complex to implement, as is natural for every new legal category in its first decades. The objections come fast, and it is worth running through them. The first objection is that «effective influence» is hard to measure, and that a legal system built on so slippery a concept would be a source of uncertainty. The objection is true but less grave than it seems, because civil liability law already operates with slippery concepts like fault, foreseeability, proximate causation, and has developed operational tools to handle them over time. Effective influence on a distributed system is measurable through what engineers call *blast radius* — an estimate of the reach of the consequences of a technical action. An LLM API vendor has a blast radius that potentially encompasses all of its integrators, because a change on its side propagates instantly. An integrator has a blast radius limited to its own users, though this can be amplified if its application is itself infrastructure for other applications. There are technical metrics — rough but tractable — for estimating each actor's blast radius, and legal doctrine could build on top of them a graduated taxonomy of responsibility. It would be no more slippery than the doctrines of fault in the nineteenth century were before decades of case law made them workable. ## Two deformations to resist {: #two-deformations-to-resist } The second objection is more political and comes from two opposite directions, both in their own way invested in the outcome. The first direction is that of the big-tech Californian environment, which has built over the past twenty years a narrative according to which the open-source and componentised nature of software makes it impossible to attribute responsibility to anyone in particular — and therefore responsibility should be limited to contract terms explicitly accepted by the parties. On this reading, if a user is harmed by an application that uses an open-source library whose author is anonymous, and the application is in turn hosted on a cloud whose provider disclaims all liability in its terms of service, then no one answers for anything — or rather, only those who have deliberately assumed responsibility by signing a contract do. This is the doctrine of **distributed irresponsibility**, and it is a comfortable ground rent for those occupying the most central nodes of the orchestration, because it lets them capture the value and externalise the risks. Responsible assemblage opposes this doctrine frontally, because it rejects the idea that the absence of a formal title-holder amounts to the absence of substantive responsibility. If your model is the critical component of thousands of downstream applications, your responsibility does not depend on whether you signed a contract with those applications' end users. It depends on your role in the orchestration, and that role is objectively measurable. The other direction from which the objection comes is European continental formalism, which has an opposite but equally problematic tradition, which we might call the doctrine of the **absolute controller**. On this tradition, the data controller, or the service provider, or the AI system deployer, answers for everything that happens along the chain, regardless of where the non-conformity or malfunction originated. It is an intuitively egalitarian doctrine, because it protects the user by guaranteeing that someone — an identifiable legal entity — will always answer. In practice, however, it produces two serious distortions. The first is that it loads the controller with responsibility over which it has no technical control, forcing it to defend against litigation over malfunctions originating in components it did not write, did not choose, cannot inspect. The second is that it de-responsibilises the nodes upstream of the chain — precisely those with the most systemic influence — because they know their share of responsibility will be formally dumped on the final deployer and that courts will keep pointing at whoever sits in the most visible position. Responsible assemblage opposes this doctrine too, because the controller's formal position does not exhaust the question of responsibility, and a merely apparent distribution of the load — which in fact always concentrates on the most accessible node — keeps things exactly as they are in the industry's real power relations. The proposal, therefore, sits in territory uncomfortable for both prevailing sensibilities, and for that very reason deserves to be articulated with some patience. Anyone who works in software knows perfectly well that the idea of responsibility as a purely contractual fact is a convenient fiction for those in Silicon Valley and a daily experience of powerlessness for those in Pescara or Milan or Frankfurt who have to deliver a system that actually works in a context of real constraints. At the same time, anyone working with European compliance knows that the absolute-controller doctrine turns the deployer into a legal fuse, whose economic function is to blow when the system breaks, so that the upstream components can keep producing externalities. Contemporary software needs a category that is neither of these, one that manages to distribute liability in a way that reflects the actual distribution of technical power. Not a symmetric distribution, because technical power is not symmetrically distributed. Not a concentration on the controller, because technical power is not concentrated on the controller. A distribution that follows the gradient of effective influence, with transparent metrics, with a workable doctrine courts can handle, with a rationale practitioners can recognise as matching their working experience. There are some areas where something like this is already happening, even if no one calls it that. The GDPR, in Article 28 and in the EDPB guidelines on the chain of sub-processors, has begun, tentatively, to recognise graduated responsibility along the processing chain — though in a formalistic way and without the conceptual apparatus that would be needed. Data Protection Impact Assessments, when done seriously rather than as an exercise in compliance theatre, contain in embryo a blast-radius analysis applied to personal data. The NIS2 directive on network security introduces obligations for managed-service providers that recognise their systemic role in the security chain. The AI Act itself, with its distinctions among provider, deployer, importer, distributor, attempts a taxonomy of roles that — still too rigid — points in the direction of a non-controller-centric distribution of responsibility. None of these instruments has yet reached the point of explicitly formulating the principle of effective influence as a gradient of responsibility, but all contain traces of a rethinking that awaits only doctrinal systematisation. The impression is that what's missing is something analogous to what the neighbour principle was for Lord Atkin: a synthetic, memorable, operational formulation capable of orienting fifty years of subsequent jurisprudence. Whoever writes that formulation will have done for the twenty-first century what the House of Lords did for the twentieth. The problem is that for that formulation to be written, a category of intellectuals that essentially does not yet exist will be required. Pure lawyers won't do, because the internal grammar of contemporary distributed systems isn't taught in law schools. Pure engineers won't do, because the grammar of law and its two-century history of categories and counter-categories isn't taught in computer science. What's needed is hybrids — border figures who have practised both trades long enough to have grasped their internal logics and limits, and who are willing to imagine something neither disciplinary corpus, taken alone, can imagine. In Italy this figure does not yet have a settled name. In the anglosphere the roles of *compliance engineer* or *technical counsel* have emerged in recent years, but these remain professional labels that merely put the two cultures in contact without really building a third. What's needed is something more ambitious: a figure who doesn't just translate technical jargon into legal jargon and vice versa, but who elaborates new categories capable of saying things neither of the two original jargons, left to itself, could say. The trade is partly theoretical, because it requires a philosophical training that lets you handle abstract categories, and partly practical, because it requires daily experience of deployment, transitive dependencies, backward compatibility broken by a vendor's minor release, ambiguous stack traces that don't say whose fault it is. Without practical experience, abstract categories hang in mid-air. Without abstract training, practical experience exhausts itself in fatigue and closed tickets. The third way is hard — not because it requires rare talents, but because the labour market does not price it, universities do not train it, companies do not organise it. It exists only through individual will, and it is precisely for this reason that those who practise it carry intellectual responsibility disproportionate to their formal standing. ## From Bill of Materials to Bill of Accountability {: #from-bill-of-materials-to-bill-of-accountability } At this point it's useful to come back to the concrete problem we started from: how can we attribute responsibility for harm caused by contemporary software? If we accept that software is no longer a product but an assemblage, and that assemblage is to be analysed according to the gradient of effective influence, then the first operational step is to build a practice of documenting the assemblage — one that is not the static photograph of the SBOM but a dynamic map of relationships of influence. Such a tool should make it possible, for any application, to answer questions like these. - Which components, if modified, would change the system's observable behaviour? - Which actors have the technical capacity to modify those components? - What contractual and regulatory obligations bear on each of those actors? - What evidence, in logs and audit systems, lets us reconstruct ex post the state of the system at a specific moment? - Through what channels can a downstream actor get an alarm signal to an upstream actor? - What are the typical response times along the chain? The resulting document would no longer be a bill of materials — it would be something closer to a ***bill of accountability***, a map of powers and duties along the entire orchestration. Producing it would require work, would require cooperation between actors who don't always have an interest in cooperating, would require rules that mandated its production. But it would be a tool that names the problem for what it is, rather than reducing it to an inventory problem. ## Three consequences for software practice {: #three-consequences-for-software-practice } From the standpoint of the daily practice of those who build software for clients, this re-articulation would have important consequences. The **first consequence** is that the typical contract — the one that today tends to dump all liability on the final vendor or, at best, to cap it at the annual fee paid — would become a document with a completely different structure. The contract would be built downstream of an analysis of the orchestration, with a clear articulation of which components the vendor controls and which it merely integrates, which risks it fully assumes and which it passes through to upstream providers, which disclosure obligations it accepts to honour and which it is technically unable to honour. It would be a longer, more complex, more honest contract — and, over time, also a more defensible one in court, because it would tell the thing for what it is rather than pretending a shape it doesn't have. The **second consequence** is that the development process would have to include, from its earliest phases, a reflection on the orchestration in which the system will be embedded — not only a reflection on functional requirements. - Who are the upstream actors we will depend on? - What guarantees do they give us? - What blast radius do they have in our regard? - How will we verify their changes? - How will we react if a change of theirs breaks our expected behaviour? Today these questions are relegated to a few slides at the architecture stage and then forgotten. In a culture that took responsible assemblage seriously, they would be part of the specification, and their absence from project documentation would be a marker of immaturity the way the absence of a threat model is today. The **third consequence** is perhaps the most interesting culturally, and it touches directly on how developers are trained. Today you learn to write code that works, then, if you're lucky, to write code that works in production. Almost no one learns to write code that works within an orchestration they are aware of. Orchestration awareness arrives late, usually through an incident, rarely as an explicit, taught competence. A training that took seriously the distributed nature of contemporary software would have to start here — it would have to show from day one that writing an API means entering an orchestration, that choosing a library means accepting an upstream vendor, that deploying to cloud means hosting yourself inside an infrastructure whose architectural decisions are elsewhere. It's not about terrifying young developers, it's about getting them used to seeing what experienced developers see after twenty years of scars. Orchestration is the object of their work, not a background. The code they write is a participation in a concert, not a self-sufficient object. If they grow up with this awareness, the question of responsibility won't arrive as an external annoyance — it will arrive as an intrinsic dimension of the craft. ## When even the writing is orchestration {: #when-even-the-writing-is-orchestration } To anyone suspecting that all this is exaggerated by the SaaS lens, and that in simpler contexts the product category might still hold, it is worth answering that the direction AI-native development is moving makes the problem more acute, not less. When you work with tools like Claude Code, or with practices like *specification-driven development* à la SpecKit, code stops being the object the developer writes directly and becomes the output of a generation chain that starts with a spec, passes through a model, produces an artefact, and integrates it into an orchestration that is already itself distributed. The spec written yesterday and the code generated yesterday, if regenerated today by the same model, would produce code plausibly similar but not identical, because the model has changed in the meantime. The concept of version, already weakened by continuous deployment, becomes even more unstable in this context, because it is now unstable not only at execution time but at writing time too. Anyone developing this way knows that exact reproducibility is a regulative horizon, not an actual property of their artefacts. Responsible assemblage, in a world where even writing code is an orchestration among developer, spec, model, toolchain, and pipeline, becomes the natural category for thinking about responsibility — because it is the only one in which the absence of a monolithic author does not automatically translate into the absence of imputability. ## The death of a category {: #the-death-of-a-category } A question remains that the essay owes its answer, because it is the question a patient reader will have held in suspense from the start. The question is whether it really makes sense to speak of the death of a legal category, or whether we are just describing an evolution, a transformation, an update. The language of death is strong, and might look exaggerated. The justification I offer is that a legal category dies in the sense Foucault meant when he spoke of categories more broadly — that is, when it stops organising the discursive field productively and starts obstructing it. The concept of product, applied to contemporary software, no longer organises the field — it obstructs it. It produces compliance that doesn't match practice, documents that don't represent objects, litigation that gets stuck on the definition of the object before it can address the substance. A concept that obstructs the field is not a useful concept, even if it remains formally in force. The concept of luminiferous ether, in late-nineteenth-century physics, wasn't wrong the way singular claims can be wrong — it was a concept that had stopped organising the field productively and had started obstructing it, until Einstein simply removed it. The concept of product, in contemporary software law, finds itself at a comparable stage. It is still there, still in the normative texts, still in courtrooms. But it is no longer working. And pretending it works is more dangerous than admitting it doesn't. I'm not saying, let me be clear, that the European legislator should have waited to have the right category before acting. That position would have been intellectually pure and politically unpresentable, and in any case the damage from the absence of regulation would have been greater than the damage from a categorially imperfect one. I am saying, more modestly, that current regulation is a work in progress, that its categorical imperfection must be acknowledged openly, and that the construction of the replacement category is a task that falls not only to legislators but also to those who work in software every day and to those who have, from philosophy of law, the tools to think. Those with both feet inside can contribute more than those with only one. And the contribution is no academic exercise, because every year that goes by without the replacement category emerging is another year in which litigation resolves through formal paths that don't mirror substantive responsibilities, another year in which upstream vendors keep transferring risk without paying for it, another year in which final deployers keep acting as fuses while the system as a whole does not improve. ## Lord Atkin's room {: #lord-atkins-room } I have gone on at length, and those who have followed me this far deserve at least an honest summary of where we have arrived. We have arrived at saying that the legal concept of product, built in the twentieth century on an ontology of bounded, preservable, identifiable objects, is insufficient for contemporary software, which is instead an orchestration of human and non-human components — a distributed event rather than an object, a concert rather than a record. We have arrived at saying that European regulation, for all its being the most serious effort ever attempted, is trying to capture the concert with the categories of the record, and that this tension produces compliance whose substantive legal value is ambiguous. We have arrived at saying that, in place of the category of product, we need to build a new one, provisionally called **responsible assemblage**, which distributes liability according to the gradient of effective influence at runtime rather than according to formal ownership or distributed irresponsibility. We have arrived at saying that this construction requires a hybrid intellectual figure, with code practice and legal reading, that the market does not price and that exists only through the individual will of those who practise it. And we have arrived at saying that, until the replacement category emerges, litigation will keep resolving through formal paths that don't mirror substantive responsibilities, with real costs for those who do the craft honestly. The point perhaps worth fixing, at the end of all this, is that **Lord Atkin, in 1932, was not a pure jurist — he was a judge who had seen many bottles break and many people fall ill, and had understood something practical about the industrial world that the prior conceptual toolkit could not say.** *Donoghue v. Stevenson* was possible because someone had held together, in a single head, the material experience of the industrial world and the conceptual tradition of civil law. Today what is needed is to hold together, in a single head, the material experience of distributed systems and the conceptual tradition of liability law. It is not a task that can be delegated to anyone, and it is not even a task that can be completed in a single essay. What can be done, with an essay, is to try to name the problem, offer a direction, invite those with tools similar to mine to continue the work. Mrs. Donoghue's bottle was opaque, and inside it was a snail no one had seen. Contemporary software is even more opaque, and inside it are many more snails, and the case law that protects us was written for a world in which bottles were made of glass. The time has come to write the case law of a world in which there are no bottles left. --- # The Last Gasp and AI's First Problem - **URL:** https://margiovanni.it/en/blog/the-last-gasp-and-ais-first-problem/ - **Published:** 2026-04-17 - **Tags:** Wellbeing, AI, Work, Organization - **Reading time:** 9 min > Agents do more work, but we work more too. The real bottleneck isn’t productivity: it’s the body—sleep, limits, and finite time. A few days ago, a swyx newsletter on Latent.Space happened to catch my eye. It’s titled “Humanity’s last gasp,” the last breath of humanity. It’s not a shouted title—quite the opposite. It’s written in that calm, slightly oblique tone that, precisely because it doesn’t raise its voice, forces you to listen more closely. Inside there are three images that stuck with me. Aaron Levie says that in Silicon Valley nobody is working less—if anything, the opposite. Tyler Cowen, as an economist, argues that you should work much harder *now* , both if you think AI will devalue your work and if you think it will make it more valuable. And then there’s Simon Last from Notion talking about sleepless nights and a new anxiety, “token anxiety,” something that two years ago didn’t even exist as a concept. The paradox swyx puts at the center is simple and, for that very reason, a bit unsettling. Agents do more work than ever, benchmarks saturate, models outperform human experts by percentages that until recently we would have called science fiction. And yet the people building and managing these systems have never worked this much. And here a question lights up for me that I can’t easily turn off: if the promise was “more productivity,” why is the widespread feeling “more pressure”? ## The convenient explanation: it’s just a phase {: #the-convenient-explanation-its-just-a-phase } The most reasonable objection is also the one that comes to me naturally, if I try to be honest. Maybe it’s a transitional phase. The usual disruption dynamic: first it breaks things, then it recomposes them. We’ve already seen it with the personal computer, with the internet, with smartphones. Jobs change, some disappear, others are born, productivity grows, and in the end—at least for those who manage the transition well—average well-being improves. It’s a serious objection. Ignoring it risks sliding into a kind of keyboard luddism, that thing where you convince yourself the problem is technology itself, rather than the way we’re inserting it into economic and social systems. But there’s a point where this objection stops working. And that point, for me, is the body. ## The body doesn’t scale {: #the-body-doesnt-scale } The problem isn’t just whether AI will replace knowledge workers or empower them. The problem is that the human body doesn’t scale. It doesn’t scale the way tokens scale. It doesn’t scale the way a cluster of tens of gigawatts scales. It doesn’t scale the way a model’s learning curve scales when it gulps down an enormous amount of knowledge in weeks. The body has a biological clock that doesn’t get reset with an update. It needs sleep, and if you take it away for months you might keep going anyway—at least on the surface—until the moment something breaks. And often it breaks in ways you didn’t anticipate and that aren’t so easy to reverse. It needs movement, natural light, rhythms. It wasn’t designed for 3 a.m. spent debugging an agent that generated eight hundred lines of code that “work,” but that you don’t really understand. These things aren’t new. Occupational medicine says them, neuroscience says them, any primary care doctor with a minimum of intellectual honesty says them. And yet, in the dominant discourse on AI, the body seems like an implementation detail. A legacy constraint to work around with enough caffeine and enough willpower. ## Where I’m looking from {: #where-im-looking-from } I’m a partner and technical lead at a small ICT company in Pescara. We’re about ten people. For a while now I haven’t been writing production code anymore, or at least not like before. My work has become research, strategic spikes, architecture evaluation, and also regulatory compliance, which is an unsexy word but a very real one. I spend my days figuring out where the market is going and deciding what makes sense to do and what doesn’t, for a company that doesn’t have the luxury of an investment round to absorb mistakes. And that has direct responsibility for the people who work there—people who go home in the evening, who have families, bodies, limits. From this position I see something that, maybe, when you’re inside the daily flow you have a harder time bringing into focus. AI hasn’t reduced anyone’s workload on my team. It has transformed it. It shifted the weight from producing code to supervising code produced by others—where “others,” in this case, is a statistical model that doesn’t sleep, doesn’t get tired, doesn’t get sick. But it makes mistakes. And it makes them in creative, unpredictable ways. And here there’s a detail that seems important to me, even if I still can’t explain well *how* important it is. Reading code written by an alien intelligence is a different job than writing it. It requires constant vigilance. It’s a form of attention that keeps you always a bit on alert. And this alertness is incompatible with something that, in cognitive work, is almost a natural form of protection: flow, the state of deep focus where you aren’t fragmented, you aren’t continuously interrupted, you aren’t forced to make micro-judgments every thirty seconds. ## Demand goes up, control goes down {: #demand-goes-up-control-goes-down } There’s a concept in occupational medicine called “job strain,” in Karasek’s model. In very simple terms it describes the most toxic combination: high job demand and low control over your own activity. Well, I have the impression that the massive introduction of AI agents is doing exactly this: it’s changing the relationship between demand and control. Demand increases because, if the tools are faster, the expectation of output grows along with them. “If the agent can do it in an hour, why are we taking a day?” is a question that arrives almost automatically, often without malice, just out of inertia. Control decreases because you delegate an increasing part of the process to systems you don’t fully understand and that change every few weeks. Even when you do understand them, you understand them in a different way than you understand a colleague or a traditional software component. It’s a more probabilistic, more fragile understanding. In this sense “token anxiety” doesn’t seem to me like a linguistic fad. It seems like a symptom. Anxiety, after all, is an adaptive function. If it shows up at industrial scale, maybe it’s not an individual problem. Maybe it’s a system signal. ## “If we slow down, China won’t slow down” {: #if-we-slow-down-china-wont-slow-down } At this point another objection almost always comes up, and this one too has a core of truth. If we slow down, others won’t. If we set limits, others push. And in a global race, whoever gets there first wins. But I wonder whether there isn’t a category error hidden inside that sentence. Competition between nations and between companies is competition between systems, not between individuals. A system that burns the people who make it up is not a competitive system. It’s a system that is consuming its most precious capital—namely the intelligence and creativity of human beings who function well only when they’re healthy, rested, and motivated by something other than fear. The history of software is full of companies that “won” in the short term with crunch and lost in the medium term. Because the best people leave, or get sick, or simply stop having ideas. An exhausted brain isn’t an engine to squeeze—it’s an ecosystem that collapses. ## Maybe the first problem is inside the chest {: #maybe-the-first-problem-is-inside-the-chest } If the point isn’t only the race for benchmarks, then what is the first problem? I believe it’s right under our nose—actually, inside our chest. The most valuable problem is figuring out how to integrate tools of extraordinary power into working life without working life devouring life. It’s not a technical problem, or at least it’s not only a technical problem. It’s a problem of organizational design, managerial culture, labor policy. And in the end it’s also a philosophical problem, because it forces you to decide what is worth doing with the time we have. Which is finite in a way no technology can change. ## Something personal, but it weighs {: #something-personal-but-it-weighs } I have a son. It’s not a logical argument, it’s a biographical fact. But biographical facts, sometimes, weigh more than arguments. When in the evening I close the laptop and look at him, I think that all the code written during the day—even the code “multiplied” by agents—is not worth an hour of that time. Not because work doesn’t matter. It matters a lot. But because that time is unrecoverable in a way code is not. Code can be rewritten. A childhood can’t. I know that in certain environments this sounds like weakness. Like a lack of ambition. Like sentimentality that won’t survive the next market evaluation. But maybe it’s the opposite. Maybe the real ambition is to build systems, companies, and lives that last. And lasting requires taking care of the medium through which everything else happens. The human body, with its non-negotiable need for rest, relationship, and time that isn’t measured in tokens per second. ## The alignment we’re not looking at {: #the-alignment-were-not-looking-at } The AI industry loves to talk about alignment, about how to make models do what we want. But I wonder if the first alignment problem doesn’t concern the models. It concerns us. We’re building an economy of attention and productivity in which incentives are often misaligned with what we know is necessary for human health. We sleep little, we move little, we pause little. And then we try to compensate with technology—with meditation apps, sleep trackers, supplements. It’s as if we created a productive system that no longer produces well-being as a side effect of work, and then we’re surprised an industry of well-being pops up to repair the damage. ## A direction, not a solution {: #a-direction-not-a-solution } I don’t have a clean solution, and I distrust those who offer one. But I do have a direction. Take seriously that *human health and human time are the primary constraint*. Not model efficiency, not deployment speed, not the number of lines of code generated in an hour. Every organizational decision, every sprint planning, every system architecture should also be evaluated with a very concrete question: how much life does it cost? And if the answer is “too much,” then maybe it’s not the right problem. Or it’s not the right time. Or it’s not the right way. This doesn’t mean “working less” in the banal sense of the term. It means working knowing that the most sophisticated system in the known universe isn’t an llm. It’s the human brain that designed it. And that brain works according to rules we didn’t write and can’t rewrite at will. That last gasp, maybe, isn’t humanity’s last gasp. Maybe it’s the last gasp of a way of working that treats people as fungible resources inside an optimization pipeline. If that’s the case, maybe we shouldn’t try to prolong it. Maybe we should let it go and learn to breathe in a different way. A way that takes into account that we’re made of flesh, time, and relationships. And that no agent, however powerful, will ever be able to live in our place. --- # Behavior Is the New Credential. And That's a Problem. - **URL:** https://margiovanni.it/en/blog/behavior-is-the-new-credential-and-thats-a-problem/ - **Published:** 2026-04-07 - **Tags:** AI Act, Behavioral Biometrics, Biometric Data, Continuous Authentication - **Reading time:** 10 min > Cybersecurity is undergoing a transition that deserves more attention than it gets: online authentication is shifting from what you know to how you behave. Cybersecurity is going through a transition that deserves more attention than it's getting. The foundational question of online authentication is shifting: no longer "what do you know?" (password, PIN), no longer "what do you have?" (token, smartphone), no longer "what do you look like?" (fingerprint, facial recognition), but "how do you behave?" The idea is elegant, and the science behind it is solid. A recent article by Brandon Janes on Towards Data Science, titled "Behavior is the New Credential," describes how behavioral biometrics systems are becoming standard practice in banking. The starting point is a 2012 study from U.C. Berkeley called "Touchalytics," which demonstrated that just eleven scroll strokes on a smartphone were enough to identify a specific user within a group of forty-one people, with zero errors. Thirty unique behavioral features: stroke length, velocity, curvature, trajectory, inter-stroke time, even the area of the finger used turned out to be individually distinctive. The underlying theory is computational motor control, an interdisciplinary field bridging neuroscience, biomechanics, and computer science. The unconscious corrections our brain performs during every gesture, those micro-adjustments happening at the millisecond scale, are so individual that a person's behavioral profile becomes nearly impossible to replicate. Paradoxically, what we think of as "robotic" (these automatic neural corrections) is exactly what makes each of us irreproducibly human. ## Why the old defenses are no longer enough {: #why-the-old-defenses-are-no-longer-enough } The context driving this transition is concrete and well documented. Modern malware has reached capabilities that render traditional verification mechanisms obsolete. Tools like ProKYC, a deepfake tool used in the cybercrime world, allow threat actors to bypass two-factor authentication, facial recognition, and even live video verification checks. BingoMod, a remote access trojan distributed via SMS phishing, masquerades as an antivirus app on Android and allows a remote attacker to intercept credentials, messages, and OTP codes, all the way to executing money transfers from the infected device. Once the device is compromised, everything looks normal from the bank's perspective: the device fingerprint is correct, the IP address checks out, MFA codes align. Traditional verification, which operates at a single point in time (the login), is no longer sufficient. The security perimeter is no longer the gate. It's the entire session. This is where behavioral biometrics enters, operating as continuous authentication. Anomaly detection models built on each user's specific profile monitor the session from start to finish. When risk signals spike, the system can request additional verification or halt the transaction entirely. When behavior matches the established profile, the session continues seamlessly. The result, ironically, is a better user experience: fewer OTPs, fewer interruptions, more fluidity. Passive security replacing active security. ## The other side of the coin {: #the-other-side-of-the-coin } So far, this is the cybersecurity industry's narrative. It works, it's technically sound, and it's operationally effective. But it's also a narrative that systematically avoids a question: what does it mean, from a fundamental rights perspective, to turn human behavior into a credential? Let's start with a regulatory fact that Janes's article doesn't mention. The GDPR, in Article 4(14), defines biometric data as "personal data resulting from specific technical processing relating to the physical, physiological or behavioral characteristics of a natural person, which allow or confirm the unique identification of that natural person." The key word is "behavioral." The European legislator explicitly included behavioral data in the definition of biometric data. Article 9 then classifies biometric data as a "special category" of personal data, whose processing is generally prohibited except under specific conditions: explicit consent, substantial public interest, protection of vital interests. This means that every behavioral biometrics system operating in the European Union is processing special category data. Not generic personal data. Data that requires explicit consent, a Data Protection Impact Assessment (DPIA), purpose limitation, data minimization, and the right to erasure. The question no cybersecurity vendor likes to face is: how do you reconcile the right to erasure with a behavioral profile built through continuous analysis of thousands of micro-interactions? You can delete a profile, certainly. But can you delete the knowledge derived from that profile, once it has been used to train a model? The GDPR raises specific questions about data minimization and purpose limitation when data has been used for AI model training. ## The AI Act's double bind {: #the-ai-acts-double-bind } The picture gets more complex with the AI Act, whose regulatory framework for high-risk systems fully applies from August 2026. The intersection of GDPR and AI Act creates a layered regulatory framework for biometric technologies. The AI Act distinguishes between several types of biometric systems. Real-time remote biometric identification systems are prohibited for law enforcement, with narrow exceptions. All other remote biometric identification systems are classified as high-risk. Biometric categorization systems that infer sensitive attributes (race, political opinions, trade union membership, sexual orientation) are prohibited. Emotion recognition systems are banned in workplaces and schools, and classified as high-risk in other contexts. Where does banking behavioral biometrics fall in this taxonomy? The AI Act explicitly excludes from the definition of remote biometric identification those verification tools that confirm a person is who they claim to be, provided they require the individual's active participation. But behavioral biometrics, by definition, is passive. The user does not "actively participate" in their own behavioral authentication. The system observes them while they do something else. This grey zone between active verification and passive surveillance is precisely the territory where fundamental rights start to strain. There's an additional element. The AI Act prohibits AI systems that classify people based on their social behavior when such classification leads to unfavorable treatment in contexts unrelated to the original data collection context, or treatment disproportionate to the gravity of the behavior. The line between "behavioral authentication for fraud prevention" and "behavioral profiling for user classification" is not as sharp as the industry would like to believe. ## Function creep: the structural risk {: #function-creep-the-structural-risk } The history of technology teaches us that systems built for a specific purpose tend to expand their scope over time. This phenomenon, known as function creep, is particularly insidious in the field of behavioral biometrics. A system that today analyzes how you scroll a page to verify you are who you claim to be could tomorrow use the same data to infer your emotional state, your attention level, your cognitive condition, your appetite for financial risk. Behavioral data is extraordinarily rich in implicit information. Your typing rhythm can reveal anxiety or fatigue. Your scrolling speed can indicate interest or boredom. Your touch pressure can suggest irritation or calm. Banks using this data for fraud prevention today are sitting on an informational asset whose potential value vastly exceeds transaction security. The temptation to monetize this data, or to repurpose it for commercial goals (service personalization, credit scoring, insurance product profiling), is an economic force that internal policies alone will struggle to contain over the long term. In Australia, a biometric database originally designed to prevent cross-border criminal activity was later used to identify individuals who had lost their documents in bushfires. In that case, the expanded use was well-intentioned. But the precedent was set: once the data exists and the system is operational, purposes expand. ## The informatized body {: #the-informatized-body } There's a deeper dimension here, one that goes beyond law and touches the anthropology of technology. Behavioral biometrics transforms the way we interact with our devices into a permanent identification datum. The U.S. National Research Council has described this process as the creation of an "informatized body": a body no longer represented by anatomical features observable to the human eye, but by digital information about the body stored in databases. When your way of scrolling a page becomes a credential, your unconscious gesture becomes a data point. The spontaneity of your movement is captured, analyzed, modeled, stored. You are not actively providing information, as you do when typing a password. You are simply existing, and the system extracts value from your ordinary existence. Shoshana Zuboff described this dynamic as the fundamental characteristic of surveillance capitalism: the appropriation of personal experience and its transformation into behavioral data, subsequently used to predict and modify behavior itself. Behavioral biometrics for cybersecurity is, in a sense, the "good" version of this mechanism. But the mechanism is the same. And the distance between the good version and the less good ones is only a matter of declared purposes, which can change. ## The asymmetry of consent {: #the-asymmetry-of-consent } A particularly problematic aspect concerns the nature of consent in these systems. The GDPR requires consent to be "freely given, specific, informed and unambiguous," with an even higher bar when special categories of data are involved. But how can consent to a behavioral biometrics system in your banking app be genuinely free when the alternative is not being able to access your bank account? European data protection authorities have already addressed this question in analogous contexts. The Dutch DPA fined a company €725,000 because employees perceived fingerprint scanning as an obligation, rendering consent unfree. The Swedish DPA sanctioned a school for using facial recognition to track attendance, citing the power imbalance between the institution and the students. In the case of banking behavioral biometrics, the imbalance is analogous. Banking services are not optional in contemporary society. If your bank implements behavioral authentication, you have no real alternative to consent. The dynamic resembles an imposed condition more than an informed choice. ## The irrevocability paradox {: #the-irrevocability-paradox } Unlike a compromised password, which can be changed in seconds, a compromised behavioral profile presents a structural problem: you cannot change how you scroll a page or type on a keyboard with the same ease with which you change a string of characters. Your behavioral patterns are intrinsically tied to your physiology and neurology. They are, in a very concrete sense, you. This introduces a long-term risk that the industry tends to downplay. If a database of behavioral profiles is breached, the exfiltrated data doesn't become obsolete through credential rotation. It remains usable for as long as the individual's biometric characteristics don't change significantly, which in most cases happens only through aging or following traumatic events. Vendors of these systems emphasize that profiles are typically processed locally and that only a risk score is transmitted, not raw data. That's a real mitigation, but it doesn't eliminate the fundamental problem: somewhere, in some form, a representation of your unconscious behavior exists as digital data. ## Algorithmic discrimination and behavioral bias {: #algorithmic-discrimination-and-behavioral-bias } A further critical aspect concerns the discriminatory potential of behavioral biometrics systems. Device interaction patterns are not universal. They vary by age, physical condition, motor disabilities, cultural differences in technology use, and the type of device being used. An elderly user with arthritic hands will have significantly different scroll and typing patterns from a twenty-year-old. A user with a budget smartphone will produce different sensor data from someone with the latest flagship. A user who alternates between left and right hands, or who uses assistive technologies, will generate atypical profiles. If the anomaly detection model was trained predominantly on profiles of able-bodied, middle-demographic users, those who deviate from this average profile will be subjected more frequently to additional verification, session blocks, and step-up authentication requests. In other words, the "passive" security that the industry advertises as a better user experience could translate into a systematically worse experience for the most vulnerable categories. The European Accessibility Act (EAA), fully applicable since June 2025, requires digital products and services to be accessible to people with disabilities. A behavioral authentication system that systematically penalizes users with motor or cognitive disabilities raises compliance questions not only under the GDPR and the AI Act, but also under accessibility regulation. ## The duty to look beyond the technical solution {: #the-duty-to-look-beyond-the-technical-solution } Nothing written above means behavioral biometrics is a bad idea. The cybersecurity problem is real, losses are enormous (the FBI Internet Crime Report documents billions of dollars in annual losses), and traditional defenses are genuinely inadequate against current threats. Continuous authentication is probably the future of digital security. But the way the industry tells this story is incomplete in a manner that is not accidental. Janes's article, like most of the technical literature on the subject, presents behavioral biometrics exclusively from the standpoint of operational effectiveness. The subtext is: it works better, it's more secure, the user experience improves. All true. But not the whole truth. For those of us working in European ICT, the responsibility is twofold. On one hand, implementing these technologies where they are needed and where they create real value. On the other, doing so with a regulatory and ethical awareness that the American market, from which most of the innovation in this field originates, does not have the same urgency to develop. Europe, with its layered regulatory framework (GDPR, AI Act, EAA, NIS2), is not making life difficult for those who work with technology. It is asking the questions that the market, left to its own devices, does not ask. Questions like: who owns the way you move your finger across a screen? What rights do you have over an unconscious gesture turned into data? What happens when your informatized body becomes a commodity? These are uncomfortable questions. But the moment behavior becomes a credential, we don't have the luxury of ignoring them. --- # Microsoft Wrote the Perfect Confession—and You'll Pay the Bill - **URL:** https://margiovanni.it/en/blog/microsoft-wrote-the-perfect-confession-and-youll-pay-the-bill/ - **Published:** 2026-04-06 - **Tags:** AI Act, Compliance, Microsoft Copilot, PLD - **Reading time:** 19 min > It’s tempting to dismiss it as a legal team slip-up. It isn’t. Terms of Use aren’t written by accident—and every word is meant for court. ## I. The eighty-billion-dollar toy {: #i-the-eighty-billion-dollar-toy } There’s a document you should read. It’s not long, it’s not hidden, it doesn’t require any special legal expertise to understand. It lives at [microsoft.com/en-us/microsoft-copilot/for-individuals/termsofuse](), it was updated on October 24, 2025, and it contains a sentence that deserves to be taken seriously. The sentence is in the section titled, in uppercase and bold, "IMPORTANT DISCLOSURES & WARNINGS", and it says: Copilot is to be considered solely for entertainment purposes. It may make mistakes and may not work as expected. Do not rely on Copilot for important advice. Use Copilot at your own risk. If that sounds like the kind of clause you’d find in a meme generator app, I get it. But we’re talking about the product Microsoft has integrated into Windows 11, into Excel, into PowerPoint, into Teams, into Outlook, into the beating heart of the suite that over 430 million people use every day. We’re talking about the product for which Microsoft committed about eighty billion dollars in AI capital expenditure in fiscal year 2025 alone, across data centers, infrastructure, and compute capacity, on top of the roughly thirteen billion invested cumulatively in OpenAI, whose technology powers the underlying models. We’re talking about the product sold to large enterprises at thirty dollars per user per month, and to small and medium businesses at twenty-one (cut to eighteen with first-half 2026 promotions). The Terms of Use for this product say it’s a toy. Microsoft’s reaction, when the clause started circulating on social media in the first days of April 2026, was predictably mechanical. A spokesperson told PCMag that it’s “legacy language” that “no longer reflects the product’s current use” and that it “will be revised with the next update.” No date. No binding commitment. No explanation for why language that doesn’t reflect the reality of the product stayed in legal documents for months after the last update, in plain sight of the same legal team that wrote it. The spokesperson spoke as if someone had forgotten to take down a sign from a closed construction site. But closed construction sites don’t bill thirty dollars per seat per month. It’s tempting to dismiss this as a legal department gaffe. It isn’t. Terms of Use aren’t written by accident. They’re written by teams of lawyers who weigh every word knowing those words will be used in court. The word “entertainment” isn’t a lazy synonym for “experimental” or “beta.” Entertainment has a precise legal meaning in Anglo-Saxon law: it’s the category that protects those who produce content that is explicitly non-factual, like games, fiction, simulations. Saying a product is “for entertainment purposes only” means saying that no reasonable user should expect its answers to be accurate, reliable, or fit for any practical purpose. You could argue the numbers tell a different story. That Copilot adoption has been slower than expected. That Microsoft itself knows the product has problems. And you’d be right. By the second quarter of fiscal year 2026, only fifteen million seats out of four hundred and fifty million paid commercial seats were subscribed to Microsoft 365 Copilot: 3.3 percent. The US market share of paying subscribers contracted by 39 percent in six months, going from 18.8 percent in July 2025 to 11.5 percent in January 2026. Net Promoter Score on answer accuracy worsened from minus 3.5 to minus 24.1 between July and September 2025, according to Recon Analytics. 44.2 percent of users who abandon Copilot cite distrust in the answers as the main reason. When workers can freely choose between Copilot, ChatGPT, and Gemini, only 8 percent choose Microsoft’s product. These numbers don’t soften the problem. They make it worse. They show Microsoft knows perfectly well the product isn’t reliable, says so in legal documents, and keeps selling it as an enterprise productivity tool. Satya Nadella called Copilot “a true daily habit” in front of investors. Marketing presents it as the assistant that transforms the way you work. The Terms of Use say it’s a toy. That’s not a contradiction. It’s a strategy. ## II. The disclaimer chorus {: #ii-the-disclaimer-chorus } It would be intellectually dishonest to present Microsoft’s clause as an anomaly. It isn’t. It’s the loudest case of a pattern that runs through the entire AI industry, and it’s worth mapping precisely. OpenAI, in its Terms of Use, warns users not to rely on outputs as the sole source of truth or factual information, and caps its aggregate liability at one hundred dollars or the amount paid in the previous twelve months. Google, in Gemini’s terms, says not to rely on the services for medical, mental health, legal, financial, or other professional advice. xAI, Elon Musk’s company, warns that its AI is “probabilistic by nature” and can produce incorrect outputs. None of these companies, it should be said, has gone as far as the formula “for entertainment purposes only.” That one remains a Microsoft exclusive. The difference between Microsoft and the others, though, isn’t substantive. It’s tonal. All major AI providers are doing the same thing: building a legal wall between the product they sell and the consequences of using it. They do it knowing their models can and do produce false, misleading, potentially harmful outputs. In August 2024, Copilot falsely identified German journalist Martin Bernklau as a convicted pedophile and a fraudster, also providing his home address. Microsoft blocked queries about Bernklau only after a data protection complaint. These aren’t edge cases. They’re the ordinary operation of a probabilistic system marketed as if it were deterministic. And in court, disclaimers work. On May 19, 2025, the Superior Court of Gwinnett County, Georgia, issued a summary judgment in favor of OpenAI in Walters v. OpenAI (23-A-04860-2). Radio host Mark Walters sued OpenAI after ChatGPT, at a journalist’s request, generated a false summary of a lawsuit in which Walters was described as accused of embezzlement against the Second Amendment Foundation. The court dismissed the claim on three independent grounds: the statements could not reasonably be understood as actual facts (also because ChatGPT had warned the journalist about its limitations and the ToS contained explicit disclaimers about the possibility of errors); Walters had shown neither negligence nor malice by OpenAI; and Walters himself admitted he suffered no damages. An outcome supported by multiple legs, then, not just disclaimers. But disclaimers mattered, and they matter. The court explicitly recognized that repeated warnings about the possibility of “hallucination” helped make any expectation of factual accuracy by the user unreasonable. This is where many commentators stop, outraged. But this is where the conversation needs to get more precise, because not all disclaimers are the same, not all serve the same purpose, and not all are, in themselves, a bad thing. The European AI Act, Regulation 2024/1689, explicitly requires providers of AI systems to communicate the limitations of their products. Article 13 provides that high-risk AI systems be designed with sufficient transparency to enable deployers to interpret outputs and use them appropriately, and that they be accompanied by instructions for use with concise, complete, correct, and clear information on characteristics, capabilities, and performance limitations. Article 14 imposes effective human oversight, and requires that the people tasked with oversight be put in a position to remain aware of the possible tendency to automatically or excessively rely on outputs—what the Regulation calls “automation bias.” Article 50 requires that users be informed when they are interacting with an AI system, and that generated content be labeled as such. Saying “this AI system can be wrong, always verify, don’t blindly trust it” isn’t just legitimate, then. It’s a regulatory obligation. Europe has established that transparency about AI system limitations is a pillar of safety and trust. The user must know what they’re interacting with, what the risks are, and must be able to decide to ignore or override any system output. This is the framework any serious company should follow. But one thing is saying “this system has these limitations; here’s how to supervise it to use it safely.” Another is saying “this is a toy for entertainment; use it at your own risk; we guarantee nothing.” The first formulation is transparency. Compliance with the AI Act. An act of responsibility that puts the deployer in a position to do their job. The second formulation is a liability dump dressed up as transparency. It doesn’t put the user in a position to use the system appropriately: it puts them in a position where they can’t seek recourse when things go wrong. The AI Act asks the provider to declare limitations to enable safe use. Microsoft’s ToS declare limitations to prevent any recourse. One serves the user. The other serves the legal department. And when a US court looks favorably on a provider’s disclaimers in dismissing a defamation claim, it isn’t necessarily rewarding transparency. It’s acknowledging the legalese. ## III. The Directive that changes everything (and the blind spot) {: #iii-the-directive-that-changes-everything-and-the-blind-spot } By December 9, 2026, EU Member States must transpose Directive 2024/2853, the new Product Liability Directive, into national law. It’s the first update in forty years to Europe’s defective product liability regime. For companies that produce, integrate, or distribute software and AI systems, the consequences are profound. The Directive first redefines what a “product” is. The old 1985 directive was designed for a world of physical objects: cars, appliances, toys. The new one explicitly includes software, regardless of the mode of supply or use, whether embedded, standalone, cloud, or SaaS. It includes firmware, operating systems, applications. The Recitals clarify that AI systems also fall within the definition. Software is no longer a service that slips out of product liability. It’s a product. As such it is subject to strict liability: you don’t need to prove the producer’s fault. You just need to show the product was defective and that the defect caused damage. Then there’s the question of exemption clauses. Article 10 provides that Member States ensure that an economic operator’s liability under the Directive is not, vis-à-vis the injured person, limited or excluded by a contractual provision or by national law. The wording leaves no ambiguity. Disclaimers in Terms of Use, limitation-of-liability clauses, “as is” formulations, and “for entertainment purposes only”: the moment a European consumer suffers harm from a defective product, they’re worth nothing. This needs to be understood in its transatlantic scope. The clause “Copilot is for entertainment purposes only” will keep working in the United States, where Walters v. OpenAI confirmed that courts take disclaimers seriously. In Europe, after the Directive is transposed, that same clause becomes unenforceable. If Copilot generates a defective output that causes harm to a natural person (death, personal injury, medically recognized psychological harm, destruction or corruption of non-professional data, damage to private property), the provider is liable. Regardless of what the ToS say. The Directive also rewrites the rules on the burden of proof, and this is where things get complicated. It introduces presumptions in favor of the injured person. If the defendant does not disclose relevant information, defectiveness is presumed. If the product does not comply with mandatory requirements of national or EU law, defectiveness is presumed. If there is an obvious malfunction during reasonably foreseeable use, same. If the injured person faces “excessive difficulties” in proving the defect due to the technical or scientific complexity of the product, courts may presume both defectiveness and causation. For AI systems, where opacity of internal functioning is structural rather than accidental, this presumption will be the norm. The injured person won’t have to explain how the model that generated the false output works. They’ll have to show the output was defective and that the damage followed. The PLD interlocks with the entire European regulatory framework. Non-compliance with the Cyber Resilience Act requirements (security-by-design obligations, vulnerability handling, security updates) can constitute a presumption of defectiveness. The same goes for failure to meet NIS2 obligations. And the same goes, implicitly, for AI Act requirements: an AI system that doesn’t meet transparency, human oversight, accuracy, and robustness obligations is a system that doesn’t meet mandatory requirements of EU law, and therefore a system for which the PLD may presume defectiveness. The short circuit is visible to the naked eye. The AI Act asks providers to declare their systems’ limitations to enable safe use. The PLD says that if the product causes harm, the provider is liable regardless of disclaimers. The provider is required to inform that the system can be wrong, and at the same time cannot use that information to escape liability when the system is in fact wrong. It’s a coherent regime, designed to protect the consumer. But it creates an extremely strong tension between the duty of transparency and the impossibility of using transparency as a shield. For Microsoft, this tension is manageable. For those in the middle of the chain, it’s potentially lethal. ## IV. Whoever modifies it, pays: the integrator as a structural scapegoat {: #iv-whoever-modifies-it-pays-the-integrator-as-a-structural-s } The PLD doesn’t just say the software producer is liable. It expands the chain of potentially liable economic operators with a cascading logic designed to ensure that the European consumer always has a reachable counterpart in the EU. If the manufacturer is outside the EU, the importer is liable. If there is no identifiable importer, the authorized representative is liable. Then the fulfilment service provider. Then the distributor, if it fails to identify the relevant operator in the chain within one month of the injured person’s request. Liability is joint and several: multiple operators liable for the same damage are liable together, each for the whole. So far the system seems reasonable. But there’s a figure in the chain that the PLD treats with particular harshness and that is crucial to understanding the practical implications of the “entertainment only” clause: anyone who substantially modifies a product after it has been placed on the market is considered a manufacturer of the modified product and is liable to the extent that the defect results from the modification. The Recitals clarify that a substantial modification may also result from a software update, an upgrade, or the continuous learning of an AI system. The product as modified is considered placed on the market at the moment the modification is actually performed. Think about what happens in the real world. A system integrator, a software house, an IT consultant takes Copilot and integrates it into a corporate workflow. They configure prompts, connect the client’s data sources, customize responses, automate flows. Are they substantially modifying the product? Under the PLD, very likely yes. The moment you take a general-purpose AI model and specialize it for a specific context, you’re creating a product different from the original. If that modified product generates a defective output that causes harm, the integrator is liable as a manufacturer. Article 12 of the PLD provides a specific protection for micro and small enterprises that produce defective software integrated into someone else’s product. These enterprises can contractually agree with the manufacturer of the final product on an arrangement that protects them from recourse actions. But this protection has two limits that drastically reduce its usefulness. First: it does not in any case protect the micro or small enterprise from a direct action by the consumer. The consumer can always sue the integrator directly, and the integrator is liable. Second: protection against recourse actions requires a contractual agreement with the product’s manufacturer. Microsoft has no obligation and no incentive to grant this kind of agreement to system integrators who use Copilot. Its ToS already say the product is “for entertainment purposes only” and that the user is “solely responsible” for any action taken based on outputs. In a potential recourse action, Microsoft will be able to say: we warned you. You chose to integrate it into a professional product. It’s not our fault if you sold it to a client as a reliable tool when we ourselves told you it was a toy. The PLD prevents pushing liability downward in the chain—toward the consumer—via contractual clauses. But it doesn’t prevent big players from refusing to grant contractual protections upward, in the relationship between integrator and manufacturer. The result is that the integrator is exposed to the consumer without being able to protect itself contractually, and has no guarantee of being able to effectively seek recourse against Microsoft. Microsoft has the legal teams, the authorized representatives in every Member State, the financial mass to absorb litigation. The ten-person integrator in Pescara, in Brno, in Lisbon doesn’t. The obvious objection is that the integrator can and must implement the human oversight required by the AI Act. Set up verification processes, user training, output supervision. And it’s true: the responsible integrator will do it, and will have to do it for its own obligations as a deployer under the AI Act. But the PLD doesn’t ask whether you did your best. The PLD asks whether the product was defective and whether the defect caused damage. A false output generated by an AI system integrated into a professional workflow that causes harm to a natural person is a defective product, regardless of how many layers of human oversight the integrator implemented. You can do everything right and still be liable. Think about what happens when an AI system integrated into management software generates an incorrect financial report that leads to a bad investment decision. Or when an AI assistant integrated into a CRM generates a defamatory communication about a customer. Or when an analysis system integrated into a healthcare platform provides an incorrect indication that influences a diagnostic pathway. In all these cases, under the PLD, the injured person can act against the integrator. The integrator is there, in the EU, reachable, has a tax ID and a bank account. Microsoft is in Redmond. And in its ToS it says Copilot is for entertainment. ## V. The bill—and who pays it {: #v-the-billand-who-pays-it } There’s a moment in the history of tech regulation when it becomes clear the rules were written for a world that no longer exists. The old 1985 Product Liability Directive was designed for a world where products were physical objects made by identifiable companies, sold through linear distribution chains, and used by consumers who could reasonably assess their safety. The new PLD is a necessary and in many ways admirable update: it extends protection to software, lowers barriers for consumers, introduces presumptions that rebalance information asymmetry. But the world it regulates isn’t made of linear chains. It’s made of stacked layers, of APIs calling APIs, of probabilistic models whose internal functioning isn’t understandable even to those who built them. The logical architecture of the European regulatory framework is the most advanced in the world. The AI Act sets obligations for transparency, human oversight, risk management. The Cyber Resilience Act imposes security-by-design and continuous security updates. NIS2 extends cybersecurity to critical sectors. The PLD closes the circle by establishing that whoever violates these obligations and causes harm pays. The objection isn’t to the framework’s logic. The objection is to the practical distribution of consequences. In reality, consequences follow a law of economic gravity that no directive can reverse: they fall downward. Toward those with fewer legal resources, less financial mass, less ability to absorb litigation. Microsoft, Google, OpenAI each have hundreds of lawyers, authorized representatives in every jurisdiction, legal budgets that exceed the revenue of entire SME supply chains. They have written ToS that, even if ineffective under the PLD vis-à-vis the consumer, remain fully operational as an argument in recourse actions between economic operators. They’ve classified their products as “entertainment,” “probabilistic,” “not a source of truth” with surgical precision, knowing what function each word would serve in a future proceeding. The PLD presents the bill, but who pays it? The ten-person system integrator who took Copilot, integrated it into the client’s management system, did training, implemented human oversight, and discovers that when the defective output causes harm, they are the reachable, identifiable, sue-able party. The provider is on the other side of the ocean, or in any case protected by B2B contractual clauses, arbitrations in Dublin, and limitations of liability between economic operators that the PLD doesn’t touch because they concern relationships between professionals and not the consumer’s direct protection. It would be wrong to say the PLD is a mistake. The PLD is incomplete. Its incompleteness produces a regressive effect that rewards those with the resources to navigate the system and penalizes those who don’t. Article 12 recognizes the problem for micro and small enterprises, but solves it in a circular way: we protect you from recourse if you have a contractual agreement with the manufacturer. But the manufacturer has no obligation to grant you that agreement. And if its ToS say “entertainment only,” its incentive to grant it is actually negative: that agreement would implicitly admit the product has a professional use, contradicting its legal shield. There’s a further paradox. The companies that take compliance most seriously, that implement human oversight, that inform their customers, that document processes, are also the ones that leave the richest documentary trail for a liability action. Whoever integrates Copilot sloppily, without processes, without documentation, without oversight, is paradoxically harder to hit because they leave less evidence of a structured relationship with the product. The PLD, in its attempt to protect the consumer, risks creating an incentive toward superficiality: those who do things well are more exposed than those who do them badly. The time dimension also matters. The PLD applies to products placed on the market or put into service after transposition. But AI systems aren’t static products. They’re updated continuously. Models change. Outputs change. An AI system that works one way today might work in a completely different way six months from now after an update to the underlying model. Every substantial update, according to the PLD Recitals, puts the product back on the market. The integrator who built a workflow based on Copilot in 2025 could find themselves, after a model update in 2027, with a substantially different product producing different outputs, without having any control over the change and with full liability for its effects. I don’t have a neat solution for all of this. But anyone working in this sector should start reading their AI providers’ ToS not to get outraged, but to understand exactly what the provider refuses to guarantee—because that list is the map of the residual risk that remains on the integrator’s shoulders. They should negotiate specific contractual agreements on product liability before the PLD is transposed, because after that bargaining power will be even lower. They should document every human oversight process, every risk assessment, every customer disclosure, not because this eliminates liability under the PLD but because in a recourse action against the provider documentation is the only weapon available. And they should seriously ask whether integrating third-party AI systems into professional products is sustainable from an insurance standpoint, because today most professional liability policies don’t cover damages from AI outputs, and tomorrow that coverage will be necessary. When Microsoft writes “for entertainment purposes only,” it isn’t stammering. It’s speaking clearly and deliberately. It’s saying that liability for any professional use of its product isn’t theirs. It’s saying that whoever takes that product and sells it as a reliable tool does so entirely at their own risk. Europe has built a regulatory framework that in theory holds everyone accountable. In practice, it holds accountable those who can least afford it. The provider that wrote “for entertainment purposes only” knowing perfectly well no one would read it, that collected thirty dollars per seat per month knowing perfectly well its product wasn’t reliable—that provider still has its lawyers, its clauses, its international arbitrations. The next time someone asks it to account for what it sold, it will point again to the Terms of Use. It’s all written there. You just have to read. --- # The advisory blind spot: what an IT vendor knows that an analyst doesn't - **URL:** https://margiovanni.it/en/blog/the-advisory-blind-spot-what-an-it-vendor-knows-that-an-analyst-doesnt/ - **Published:** 2026-03-30 - **Tags:** AI Act, Compliance, Cyber Resilience Act, Governance - **Reading time:** 6 min > A few weeks ago I received an advisory report on IT services in our segment. It was solid, but it missed what only delivery-side vendors learn. A few weeks ago I received a report from a well-known advisory firm that assessed the IT services market in our segment. I read it carefully, because my customers read this stuff before deciding who to work with. The report was well written, the market analyses were solid, the trends identified were correct. And yet, as I read it, I kept thinking: whoever wrote this has never delivered a software project to an Italian public administration customer. They’ve never negotiated an SLA with a procurement office that doesn’t know what an SLA is. They’ve never had to explain to a healthcare executive why their legacy system can’t simply “be upgraded” without rebuilding the entire integration with the regional information system. This isn’t a criticism. It’s an observation about a structural blind spot in the IT advisory market. The people who advise companies on how to buy technology, in the vast majority of cases, have never sold technology. And the people who sell and deliver technology have no voice in how the advisory market defines sourcing best practices. The result is an information gap that costs real money to both buyers and sellers. I say this with firsthand knowledge. I run a small ICT company that lives on contracts with mid-market and public administration customers. I’ve written quotes, negotiated contracts, defined SLAs, managed escalations, taken penalties, delivered projects late and projects early. I’ve seen the IT services market from the side of the table that sourcing analysts rarely see. And what I see doesn’t always match what advisory frameworks describe. ## First Blind Spot: Pricing {: #pricing-blind-spot } Most advisory frameworks evaluate IT vendors based on cost per person-day or cost per function point. They’re understandable, comparable metrics, and fundamentally obsolete. The problem is that AI is making the relationship between work time and delivered value completely non-linear. A five-person team using agentic coding can deliver in a week what a fifteen-person team used to deliver in a month. The value to the customer is identical. The cost in person-days is one fifth. If the customer pays by person-day, the vendor has a perverse incentive not to adopt AI, because they bill less. If the vendor adopts AI and the customer keeps evaluating by person-days, the vendor looks five times more expensive per day even if the total project cost is lower. This isn’t a theoretical problem. It’s a problem I face every month when I present quotes. I stopped quoting by person-day more than a year ago. I quote by deliverable: this is the outcome, this is the price, these are the conditions. Some customers appreciate it. Others—especially in the public sector, where tenders are structured around person-days—don’t know how to handle it. The purchasing framework doesn’t account for a vendor that delivers more value in less time. ## Second Blind Spot: Compliance as a Sourcing Criterion {: #compliance-as-sourcing-criterion } Advisory frameworks are starting to add regulatory compliance as a vendor evaluation criterion. But they add it as a checkbox: “Is the vendor GDPR compliant? Yes/No.” That’s radically insufficient. Compliance isn’t a binary property. It’s a spectrum. A vendor can have a privacy policy on their website and have no technical mechanism for data minimization in the code. They can claim to be AI Act compliant without having any idea what a risk assessment for high-risk AI systems is. They can tick the SBOM box without having a pipeline that generates SBOM automatically on every build. A serious sourcing framework, in today’s European regulatory context, should evaluate compliance not as a statement but as a technical capability. Does the vendor have a documented vulnerability handling process? Does their CI/CD pipeline include dependency scanning? Are their SBOM generated automatically or compiled by hand? Does their software have automated tests that verify privacy properties? These questions are more revealing than any certification. And they’re questions that only someone with operational delivery experience knows how to ask. ## Third Blind Spot: IT SMEs {: #it-smes-blind-spot } The advisory market is built around the big system integrators. The evaluation matrices, the Magic Quadrant, the Wave, the Provider Lens—all of these tools are calibrated for companies with hundreds of millions in revenue. IT SMEs—which in Europe represent the vast majority of software services providers—are invisible in these frameworks. Not because they don’t deliver value, but because they don’t have the scale to participate in analysts’ evaluation processes. This creates a paradox. The mid-market customer—the 200–500 employee company, the ASL, the Municipality, the Chamber of Commerce—reads analyst reports and sees only big names. But the big names don’t serve the Italian mid-market, or they serve it with junior teams overseen by a partner you never actually see. The vendor that actually delivers the work—the local SME with ten people, a senior per project, and a direct relationship with the decision-maker—doesn’t appear in any framework. The information gap is total. ## Fourth Blind Spot: Contract Governance {: #contract-governance-blind-spot } Advisory frameworks are very good at evaluating the vendor selection phase: how to choose, how to compare, how to negotiate. They’re much less good at evaluating the execution phase: how to monitor, how to intervene when things go wrong, how to manage scope change. And in my experience, 90% of problems in IT projects don’t come from choosing the wrong vendor. They come from managing the contract poorly after the vendor has been chosen. I’ve seen projects fail not because the vendor was incompetent, but because the customer didn’t have internal governance capable of making decisions about requirement changes. I’ve seen SLAs negotiated down to the last cent that nobody monitored. I’ve seen contractual penalties that were never applied because the customer depended too much on the vendor to be able to afford to fine them. These are recurring patterns that any IT vendor knows intimately and that advisory frameworks treat as exceptions. ## Fifth Blind Spot: Technical Quality and Business {: #technical-quality-and-business } Perhaps the deepest: the relationship between technical quality and business outcome. Advisory frameworks evaluate vendors on dimensions like price, track record, team size, certifications. They rarely evaluate the technical quality of the software they produce. How many automated tests does the codebase have? What’s the coverage? How is the architecture structured? Is the code maintainable? Is the documentation up to date? These are the dimensions that determine the total cost of ownership of software—the real TCO, not the declared one—and they’re dimensions that sourcing analysts aren’t equipped to assess. The result is that the market rewards the ability to sell—convincing decks, solid references, large teams—rather than the ability to build. And that explains why so many IT projects cost twice what was expected and deliver half of what was promised: selection happens on criteria that don’t predict execution quality. I’m writing these things not for the pleasure of criticizing a sector I respect and that, frankly, interests me. I’m writing them because I believe the IT advisory market is at an inflection point. AI is changing the economics of delivery. European compliance is changing purchasing criteria. The European mid-market needs evaluation frameworks that aren’t simplified versions of enterprise ones. And IT vendors—those who actually build and deliver the software—have operational knowledge that, if integrated into advisory frameworks, would make them far more useful. I don’t claim to have the solution. But after fifteen years on the other side of the table, I know which questions should be asked and aren’t being asked. I know which metrics predict a project’s success and which only predict the quality of the initial presentation. I know what changes in pricing when AI enters the delivery cycle. I know what compliance means in a production codebase, not in a policy document. This is knowledge the advisory market doesn’t have, not because it’s incompetent, but because it is structurally separated from the world of delivery. And maybe it’s time to build a bridge. --- # Incompetence as a Structural Condition of the Present - **URL:** https://margiovanni.it/en/blog/incompetence-as-a-structural-condition-of-the-present/ - **Published:** 2026-03-28 - **Tags:** Complexity, Epistemology, European Regulation, Philosophy OF Technology - **Reading time:** 12 min > Nobody knows what they’re doing—not as a cliché, but as a structural fact: our technical systems are now too complex for any single person to understand. Nobody knows what they are doing. Not in the casual, half-joking sense people use in corridor conversations, when someone shrugs and says we are all making it up as we go. In a more precise, more unsettling, and fundamentally structural sense: the complexity of the technical objects we have built has exceeded the capacity of any single human being to understand them. Not for lack of intelligence or training. For a reason that has to do with the very nature of these objects. For most of the history of technology, it was possible to find at least one person who understood an artefact in its entirety. The Roman aqueduct, the mechanical loom, the steam locomotive, even a Second World War aircraft: complicated systems, certainly, but ultimately reducible to a unitary body of knowledge. A sufficiently prepared engineer could trace the causal chain from one end to the other. Could say: I know how it works, I know why it works, I know what happens if it breaks. This possibility was not a detail. It was the foundation on which the very idea of technical competence rested, and alongside it the idea of responsibility. That foundation is gone. ## The threshold {: #the-threshold } The breaking point was not sudden. It accumulated over decades, invisible in the way all changes that happen by layering rather than fracture are invisible. Every layer of abstraction added on top of the previous one solved a problem and created another: it made the layer below opaque. The programmer writing application code today does not truly know the framework they use. Whoever knows the framework does not know the runtime. Whoever knows the runtime does not know the operating system, not all the way down. Whoever knows the operating system does not know the processor microcode. And nobody, absolutely nobody, knows the entire chain of dependencies that a single install command pulls from the network and makes part of their software. This is not polemical exaggeration. It is a factual description. An average software project in 2026 includes hundreds of direct dependencies and thousands of transitive ones. Each of these was written by someone else, with their own dependencies, their own vulnerabilities, their own architectural decisions made in a context that no downstream user will ever reconstruct. Running software today means trusting. Not in the noble sense of trust between people, but in the epistemological sense of someone who gives up verifying because verification is materially impossible. There was an era when the word "engineer" implied the possibility of total control over one's object of work. That era is over. It will not return. ## Knowledge as an illusion of scale {: #knowledge-as-an-illusion-of-scale } The problem is not that we know little. It is that the kind of knowledge we possess is not commensurate with the complexity of what we operate. We know things, certainly. We know many things. But the knowledge needed to comprehend a modern distributed system is not the sum of individual knowledge: it is a knowledge that would require a mind capable of holding together simultaneously layers that are, by their very nature, designed to be separate. Abstraction, the fundamental mechanism of computational thinking, works precisely because it hides. This is both its merit and its trap. A well-designed interface frees you from needing to know what happens underneath. But when something goes wrong, when a system behaves in unexpected ways, you discover that "underneath" there is a world that nobody in the room knows, and that perhaps nobody in the world knows in its entirety. Not because the knowledge does not exist, but because it is distributed in an irrecoverable way among thousands of people who have never spoken to one another. This is a new epistemological condition. It has no precedent in the history of technology, and few precedents in the history of thought. The closest may be the problem of the division of labour as Adam Smith described it, but with a substantial difference: Smith was talking about a production process in which each worker understood their own piece. Here, nobody truly understands even their own piece, because their own piece rests on other pieces that escape comprehension by definition. ## The broken chain of responsibility {: #the-broken-chain-of-responsibility } If nobody understands the system in its entirety, the question of who is responsible has no satisfying answer. Not because candidates are lacking, but because the very concept of responsibility presupposes something that is missing here: the possibility of knowing. Responsibility, at its root, means the capacity to respond. To give an account of one's choices. But how does one give an account of a choice made in a context that could not be fully understood? How does one answer for a system whose behaviour emerges from interactions between components that no single actor designed or foresaw? The law, which has thought about this far more than computer science has, developed over time the idea of due diligence: you do not need to understand everything, you just need to act with the care reasonably expected of someone in your role. It is a pragmatic compromise and for many centuries it worked. But it worked because the gap between what could be known and what had to be decided was bridgeable with study and experience. Today that gap is not bridgeable. It is not a gap that closes with more training or more effort: it is a structural gap, produced by the complexity of the object, not by the inadequacy of the subject. Recent European legislation intuits this, even if it does not say so openly. The Cyber Resilience Act, the Product Liability Directive, the AI Act: all these regulatory instruments attempt to reconstruct chains of responsibility in a context where those chains are physically broken. They do so with classical tools: documentation obligations, conformity assessments, risk registers. These are serious and in many cases welcome attempts. But they rest on a silent assumption that deserves to be brought into the light: they assume that somewhere, there is someone who knows. The manufacturer must document the risks of their product. But the manufacturer does not know the transitive dependencies of their own code. The importer must verify conformity. But conformity is defined against standards that describe system properties that nobody can verify in practice. The user must give informed consent. But the information needed for genuine consent would require competences that not even those who wrote the software possess. This is not cynicism. It is an accurate description of a situation we have created step by step, in good faith, solving each time the problem immediately in front of us and adding each time a gram of opacity to the overall system. ## The myth of specialisation {: #the-myth-of-specialisation } A response one hears often is that specialisation solves the problem. Nobody needs to understand everything: it is enough that each person understands their own piece well, and the whole will work. It is the principle of the division of labour applied to knowledge, and it is enormously attractive because it allows one to avoid confronting the underlying question. But it does not work. It does not work because the boundaries between the "pieces" are arbitrary and permeable. A security vulnerability crosses every layer. A regulatory requirement cuts across frontend, backend, infrastructure, third-party suppliers. An architectural decision made five years ago in a context that no longer exists constrains today choices that whoever made it could not have imagined. Specialisation works when components are genuinely independent. Software is not made of independent components. It is made of dependencies, in the most literal sense: every part depends on other parts, and the behaviour of the whole is not deducible from the behaviour of the parts. It is what systems theory calls emergence, and emergence is precisely the adversary of specialisation. The most insidious bug is always the one that lives in the space between specialisations, where nobody looks because nobody thinks it is their territory. ## The incompetence of those who legislate {: #the-incompetence-of-those-who-legislate } There is a particular case that deserves attention, not in an accusatory spirit but because it is structurally illuminating: the incompetence of those who write the rules. A legislator who writes rules about software is in the same epistemological position as everyone else: they cannot comprehend the system in its entirety. But unlike a programmer or a software architect, the legislator does not even have the partial knowledge that comes from daily use. They operate on descriptions of descriptions, on abstractions of abstractions, mediated by consultants who in turn mediate the knowledge of specialists. This is not an argument against regulation. On the contrary: it is an argument about the nature of possible regulation. Regulating what one does not fully understand is not a failure, it is the starting condition. The question is not whether the legislator is competent — they cannot be, in the full sense of the word, and not through any fault of their own. The question is whether the rules they produce are robust enough to function despite the structural incompetence of those who wrote them, those who must apply them, and those who must verify them. Sometimes the answer is yes. The GDPR, with all its limitations, introduced a principle of caution that works precisely because it does not require technical understanding: treat personal data as though it were dangerous, regardless of whether you understand the specific mechanisms of the danger. It is a regulation designed for incompetence, and for that reason it works better than many regulations that presuppose competence. ## Socrates in the development cycle {: #socrates-in-the-development-cycle } There is a sentence attributed to Socrates with the frequency and imprecision reserved for all sentences that are too useful: "I know that I know nothing." It is cited as a gesture of humility, sometimes as intellectual coquetry. But in its most radical version, the one in Plato's Apology, the point is different and far more uncomfortable: Socrates does not simply say that his knowledge is limited. He says that those who believe they know are in a worse condition than those who know they do not know, because to ignorance they add the illusion. Applied to the technological present, the Socratic thesis acquires a weight that Plato could not have imagined. The software industry is built on a double illusion of knowledge: that of those who build the systems, who believe they control them, and that of those who use them, who believe they understand them. Both illusions are functional. Without the first, nobody would write code, because complete honesty about one's own ignorance would be paralysing. Without the second, nobody would use software, because authentic informed consent would produce mass refusal. We function, as individuals and as an industry, thanks to a voluntary suspension of epistemological disbelief. Not unlike the way finance functions, or politics, or any other complex system in which trust replaces understanding. But there is a difference. Finance and politics have developed over time an institutional awareness of their own epistemological fragility. Central banks exist because we know the financial system does not self-regulate. Constitutions exist because we know that power does not self-limit. Computing has not yet developed anything equivalent. It has standards, it has best practices, it has certification frameworks: all tools that presuppose the possibility of knowledge rather than reckoning with its impossibility. ## Deciding without knowing {: #deciding-without-knowing } The daily condition of those who work in technology is this: deciding without knowing. Not in the dramatic sense of a blind gamble, but in the ordinary, slightly wearing sense of someone who every day makes choices with multi-year consequences based on information they know to be incomplete, in contexts they know will change, for requirements they know to be provisional. An estimate is a declaration of subjective probability passed off as a prediction. An architectural choice is an act of faith in the stability of conditions that are not stable. A refactoring is a wager that present costs will be repaid by future benefits that nobody can guarantee. Every sprint is an exercise in applied epistemology under time constraint, conducted by people who have not studied epistemology and who are not paid to reflect on the conditions of possibility of their own knowledge, but to produce results. This is not an indictment. It is a description. And the point is not that things should be different: it is that they cannot be different. Structural incompetence is not a problem to be solved. It is the condition in which we operate, and in which we will continue to operate for as long as we build systems whose complexity exceeds the comprehension of those who build them. The question, then, is not how to eliminate incompetence. It is how to inhabit it. ## Inhabiting incompetence {: #inhabiting-incompetence } If competence in the classical sense — complete mastery of one's domain — is no longer attainable, then what we call by that name has become something else. Not a knowing, but a knowing-how-to-act in the absence of knowing. A form of practical wisdom that resembles Aristotle's phronesis more than his episteme: not knowledge of first causes, but the capacity to act well in particular and uncertain situations. The good technologist, today, is not the one who knows the most. It is the one who manages their own ignorance best. Who knows where the boundaries of their understanding lie, who knows how to ask, who knows when to stop, who knows how to build systems that fail predictably rather than catastrophically. These are all competences, but they are competences about one's own incompetence. They are meta-competences, if one wants to use an ugly term for an important idea. And here a paradox opens that deserves to be looked at squarely. The professional culture of software rewards knowing and punishes not-knowing. Whoever admits they do not understand loses credibility. Whoever says "I don't know" in a meeting is perceived as weak. Whoever estimates honestly is punished by comparison with whoever estimates optimistically. The entire incentive system is built to mask incompetence rather than manage it, which produces the opposite result: unrecognised, unmanaged, unmetabolised incompetence. Dangerous incompetence. A mature professional culture would do the reverse. It would start from the assumption that nobody understands the system in its entirety, and build processes, tools, institutions designed to function under that condition. This is not utopia: it is the engineering of ignorance, and it is exactly what we do when we write automated tests (we verify because we do not trust our own understanding), when we conduct code reviews (we look for the errors that our blind spots prevent us from seeing), when we adopt the principle of least privilege (we limit the damage our ignorance can cause). These are not palliatives. They are the most sophisticated practices the software industry has produced, and they are all, at root, techniques for managing incompetence. Nobody calls them that, because the name would be uncomfortable. But that is what they are. ## Honesty as method {: #honesty-as-method } Perhaps the only available response to structural incompetence is not a solution but an attitude: epistemological honesty as a daily practice. Knowing that one does not know, not as an empty formula, but as the operational starting point of every decision. This does not mean paralysis. It means deciding in the knowledge that one is deciding in the dark, and building safety nets proportionate to that awareness. It means documenting not only what was done, but why it was done and on what assumptions — because those assumptions will prove wrong and whoever comes after will need to understand not the solution, but the reasoning that produced it. It means ceasing to treat estimates as promises and architectures as monuments. This is not a revolutionary proposal. It is the description of what the best people already do, often quietly, often against the grain of the culture that surrounds them. Structural incompetence is not an enemy to be defeated. It is the ground we walk on, and the only choice available is between walking on it with our eyes open or with our eyes shut. We, as a species, have built a world we are unable to understand. This is not a tragedy. It may be the most human thing we have ever done. --- # Most software that exists shouldn't exist at all - **URL:** https://margiovanni.it/en/blog/most-software-that-exists-shouldnt-exist/ - **Published:** 2026-03-27 - **Tags:** Attention Economy, Innovation, Minimalism, Product Design - **Reading time:** 8 min > And the people who build it for a living are the last to admit it. I've been building software for twenty years. I've shipped projects, run sprint planning, configured pipelines, written specs, argued about architecture. Software is my professional life. And it's from that position, not as an outside critic or a Monday-morning quarterback, that I'm telling you something our industry refuses to hear: most software that exists shouldn't exist. Not because it's poorly made. Some of it is, sure, but that's not the point. It shouldn't exist because it doesn't solve a problem. Or it solves a problem nobody has. Or it solves a problem that was already solved, and does it worse. Or, in the most common and most insidious case, it *creates* the problem it then pretends to solve. * * * ## The Graveyard of Invented Problems {: #the-graveyard-of-invented-problems } Open your phone. Count the apps. How many do you actually use? How many solve a real problem in your life? And how many exist because somebody put together a convincing pitch deck, closed a seed round, and built something the world never asked for? This isn't a fringe phenomenon. This is the dominant model of the software industry for the last fifteen years. The cycle goes like this: someone identifies a "pain point" (almost always a minor inconvenience inflated into an existential crisis), builds an MVP, raises funding, hires developers, scales. At some point the software exists, it has users, it generates revenue. But nobody ever stopped to ask whether the world needed it. The question was irrelevant. The only question that mattered was: is it growing? I've seen apps for sharing grocery lists with your roommates. Platforms for booking your barber with artificial intelligence. SaaS products for managing your houseplants. Marketplaces for swapping used dog outfits. I'm not making these up. Every single one of these received funding, had a development team, burned server capacity, energy, human time. The problem isn't that they were bad products. Some were technically flawless. The problem is they had no reason to exist. And nobody said so, because saying so meant being the person who "doesn't get innovation." * * * ## The Hidden Tax {: #the-hidden-tax } Software isn't free. Ever. Even when it costs the user nothing, it costs the world. It costs energy. Every app that shouldn't exist runs on servers consuming electricity. Every pointless SaaS has a database replicated across three availability zones, a monitoring stack, a global CDN. The cloud is not a cloud. It's a warehouse full of machines overheating in Oregon or Northern Virginia, powered by a grid that has physical limits. It costs attention. Every useless piece of software installed on someone's phone competes for their attention with everything else. With work, with relationships, with sleep, with productive boredom, with unstructured thought. Attention is a finite resource. Every useless app that captures it is stealing it from something more important. It costs complexity. Every piece of software adds an interface, a login, a password, another batch of notifications, another set of terms of service nobody reads, another stream of personal data flowing to God knows where. The complexity of our digital environment grows every year, and not because problems are multiplying. Because solutions are multiplying faster than problems. It costs talent. This is the one that makes me angriest. There are extraordinarily talented developers out there spending their days optimizing the conversion funnel of an app that lets you order coffee with three fewer taps. People who could be building software that saves lives, makes education accessible, improves public health. Instead they're A/B testing the color of a "Buy Now" button. It's not their fault. The market pays more for the button. But it's a waste so obscene we should at least have the decency to call it what it is. * * * ## "But the Market Decides" {: #but-the-market-decides } Here's the objection. If a piece of software exists and has users, then the market has decided it's needed. Supply meets demand, the invisible hand does its thing, everybody's happy. Except it's not true. The software market doesn't work like the apple market. First: the marginal cost of distribution is near zero. This means software can reach millions of users without the quality or necessity of the product ever being tested by any natural feedback mechanism. A greengrocer selling rotten apples goes under in a week. An app that solves no problem can survive for years, funded by venture capital, growing in users who don't pay, until the next round or the acqui-hire. Second: the advertising model has decoupled value from price. When the user doesn't pay, the product doesn't need to be useful to the user. It needs to be useful to the advertiser. And for the advertiser, the metric is attention, not satisfaction. Software that makes people miserable but keeps them glued to the screen is an extraordinary commercial success. The market "decided" it's needed. But the market, in this case, is sick. Third: network effects create natural monopolies. Once everyone uses a platform, you can't not use it. Not because it's good, but because it's where everyone is. The market didn't "decide" that WhatsApp is the best way to communicate. It decided it's the way everyone communicates, which is a completely different thing. * * * ## The Radical Act of Not Building {: #the-radical-act-of-not-building } In tech culture, building is always positive. "Makers gonna make." "Ship it." "Build in public." The verb *build* has a sacred aura, and whoever builds is by definition on the right side of history. But there is a braver act than building, and nobody talks about it: deciding *not* to build. Deciding that the world doesn't need another task manager. That a spreadsheet does the job better than your app. That the problem you're about to solve isn't a problem. That your talent and your time are better spent elsewhere. In my experience, the best engineers I've ever worked with were also the ones most capable of saying "we don't need this." Not out of laziness, not out of cynicism. Out of respect. Respect for the problem, for the user, for the complexity of the real world. They knew that adding software to a context means adding complexity, dependencies, maintenance, technical debt. And that doing it without a strong reason is irresponsibility dressed up as productivity. The Unix philosophy said it forty years ago: do one thing, and do it well. Not "do everything." Not "do new things because you can." Do one thing. Leave the rest alone. * * * ## The Software That Should Exist {: #the-software-that-should-exist } I'm not saying software is the enemy. That would be like saying writing is the enemy because bad books exist. The software that should exist is the kind that expands human capability without creating dependency. That solves a real, verifiable problem. That works for the people who use it, not for the people who sell it. That you can stop using without consequences. That doesn't need to trap you to justify its own existence. The software that should exist is the kind that, if it vanished tomorrow, someone would notice and miss it. Not the compulsive missing of an addict, but the concrete missing of someone who lost a useful tool. Like losing a good kitchen knife. Like losing a reliable bike. That's the metric we should be using: if it disappeared, would you miss it? If the answer is "probably not," that software shouldn't exist. If the answer is "I wouldn't even know it was gone," that software is wasting the planet's resources and the time of everyone who built it. * * * ## The Responsibility of Those Who Build {: #the-responsibility-of-those-who-build } Every time we decide to build a piece of software, we're making a decision about real resources. Developer time. Server energy. User attention. The complexity of the digital ecosystem. And in a world with finite resources and enormous problems, building something useless is not neutral. It's active waste. It's a misallocation of human intelligence. A civil engineer has to justify why a bridge is needed. An architect has to demonstrate that a building meets a need. A doctor doesn't prescribe drugs just because they exist. Why should software be different? Why should we accept that 90% of what we build will end up forgotten in an App Store, abandoned by its own creators after six months, left with user data inside and the servers still running? Real innovation, in 2026, is not building more. It's building less, building better, building for better reasons. And having the guts to say, once in a while, "no, we're not doing this one." Not because we can't. Because it doesn't need to exist. * * * ## The Luxury of Subtraction {: #the-luxury-of-subtraction } There's a concept in architecture that the software world has never learned: the value of empty space. A good architect doesn't fill every square foot. They know that empty space isn't absence. It's breathing room. It's possibility. It's the room that the people who live there need to move, to think, to live. A building packed to the last inch isn't a masterpiece of efficiency. It's a prison. Our digital landscape is a building packed to the last inch. Every space is occupied by an app, a service, a platform, a notification. There's no breathing room. There's no empty space. There's no quiet. And in the middle of all that noise, the software that's actually useful, the kind that solves real problems, gets lost. It becomes invisible. Not because it's any worse, but because it's buried under tons of software that shouldn't exist. Subtraction is a creative act. Choosing not to build is a design decision. And in an industry that can't say no to anything, it might be the rarest and most valuable skill there is. * * * *The best software I ever wrote is the software I decided not to write.* --- # Your kids are not your users - **URL:** https://margiovanni.it/en/blog/your-kids-are-not-your-users/ - **Published:** 2026-03-26 - **Tags:** Dark Pattern, Design Responsabile, Dipendenza Digitale, Filosofia - **Reading time:** 8 min > A manifesto for people who build tech and are also parents: on engagement, attention extraction, and a simple rule—build as if your child were the user. You know the word “engagement.” You use it in meetings, in project docs, on calls with clients. You know what it means: time spent on the platform, return frequency, interactions per session. You know it’s the metric that matters. You know your work, ultimately, is judged by your ability to make it go up. Then you go home. And your child is in front of a screen. And that screen is doing exactly what you know how to do: capturing attention, generating engagement, maximizing time-on-platform. Only this time the user isn’t a user. It’s your child. * * * ## The dissonance {: #the-dissonance } If you work in tech and you have kids, you live with a cognitive dissonance that almost no one names. By day you design systems meant to keep people in. By night you try to pull your child away from identical systems. By day you talk about “user retention” as a success. By night your child’s “retention” in front of the tablet scares you. You know how pull-to-refresh works. You implemented it, or at least you discussed implementing it. You know it replicates the lever gesture of a slot machine. You know the delay before loading isn’t a technical limitation but a *design pattern* : the calculated pause that maximizes dopamine release. You know it because it’s your job to know it. And you know your child, at eight, at ten, at twelve, has no tools to defend themselves against what you know how to build. It’s not a personal contradiction. It’s a system contradiction. It concerns anyone who works in tech and has kids—which at this point means millions of people. * * * ## What we know and can’t pretend not to know anymore {: #what-we-know-and-cant-pretend-not-to-know-anymore } Lining things up helps you look them in the face. **We know** that variable-ratio reinforcement schedules—the ones social media feeds are built on—are the most powerful psychological mechanism ever documented for inducing and maintaining compulsive behavior. We’ve known since the ’50s. Skinner proved it on pigeons. We apply it to children. **We know** that an adolescent’s brain is in full development. The prefrontal cortex—the part that governs judgment, impulse control, the ability to evaluate consequences—doesn’t finish maturing before 25. We design systems that deliberately bypass it to speak directly to the limbic system. We do it for a living. **We know** that habitual social media use is associated with a measurable reduction in cortical thickness in brain regions linked to cognitive control. These aren’t opinions. These are MRI data on thousands of adolescents. **We know** that rates of depression, anxiety, self-harm, and suicide among adolescents have doubled or tripled since 2010, in step with the spread of smartphones, across the Western world. **We know** that platforms know it. Meta’s internal documents, made public by Frances Haugen, showed that Instagram worsened body image issues for one in three girls. The company knew. It kept going. **We know** all of this. And we keep building. * * * ## “But I don’t work on social” {: #but-i-dont-work-on-social } I know. Me neither. I build management software, platforms for public administration, B2B software. I don’t design algorithmic feeds and I don’t optimize recommendation systems for teenagers. But the point isn’t what we build today. The point is the culture we build it in. We work in an industry that has normalized the idea that human attention is a resource to extract. That “user experience” is synonymous with “time the user spends on the platform.” That success is measured in sessions, clicks, conversion rate, daily active users. We talk about human beings with the vocabulary of mining, and it doesn’t seem strange. This culture runs through all of us. Even those who don’t work on social breathe in its metrics, its values, its priorities. When we go home, that culture comes home with us. It seeps into the way we look at our child’s screen. Sometimes with concern, sure, but also with a subtle, unconfessable familiarity. We recognize those mechanisms. We know they work. And a part of us—the professional part—can’t help admiring them. That’s the familiarity we have to break. * * * ## The privilege of awareness {: #the-privilege-of-awareness } Anyone who works in tech and has kids has something most parents don’t: knowledge of the architecture. We know *how* those systems work, not just *that* they work. We know notifications don’t arrive at random but are optimized for the moment of maximum psychological vulnerability. We know infinite scroll isn’t an aesthetic choice but a capture device. We know “the algorithm” isn’t a mysterious entity: it’s code written by people like us, with specific goals, optimized to specific metrics. This awareness is an enormous privilege. And privilege creates responsibility. If you see the fire and others don’t, you can’t pretend nothing’s happening and say “not my fire.” And yet that’s exactly what we do, as an industry. We know. And we stay quiet. Because speaking up would mean admitting the problem isn’t “out there,” in kids’ bad habits, in parents’ inability, in the lack of “digital education.” The problem is also *inside*. In how we think about software. In the metrics we choose to optimize. In the questions we don’t ask. * * * ## The questions we don’t ask {: #the-questions-we-dont-ask } In twenty years in tech, I’ve never heard anyone in a project meeting ask these questions: *Could this system create addiction? If so, do we have a responsibility to prevent it?* *Are we designing for the user’s well-being or for maximizing their time of use? Are those the same thing?* *If a minor used this product, would it be safe? Not “compliant with regulations.” Safe.* *Are we measuring success with metrics that align our interests with those of the people using our software? Or are we measuring something that’s convenient for us to measure?* *Would we build this system exactly like this if we knew the first user would be our child?* The last question is the most important one. And it’s the one we never ask. * * * ## The child test {: #the-child-test } I’m proposing a rule. Not a law, not a framework, not a process. A personal rule, for anyone who builds software and has kids. **Before you implement a system, ask yourself: am I okay with the first user being my child?** Not “my child at twenty, an adult, aware, trained.” My child *now*. With the age they have. With the prefrontal cortex they have. With the resistance to stimuli they have. With the blind trust in technology they have. If the answer is yes, build it. If the answer is “it depends,” stop and ask what it depends on. If the answer is no, you have a problem. And the problem isn’t your child. This isn’t a sentimental test. It’s a design test. It’s the *precautionary principle* translated into the language of software development. The applied version of Hans Jonas’s imperative: act so that the consequences of your action are compatible with the permanence of an authentic human life. Except Jonas was talking about atomic bombs and genetic engineering. We’re talking about algorithmic feeds and push notifications. The fact they seem harmless is exactly what makes them dangerous. * * * ## We are not powerless {: #we-are-not-powerless } I know what you’re thinking. “I’m an employee. A freelancer. A team lead at a ten-person company. I don’t decide Meta’s policies.” True. You don’t. But you decide how you build *your* software. Which metrics to optimize. Whether to implement dark patterns or refuse. Whether to add a usage timer or infinite scroll. Whether to design a system that respects the user’s attention or one that loots it. Above all, you decide what kind of professional you want to be. You can be the one who says “the market demands it” and implements whatever pays. Or you can be the one who says “I’m not building it like this” and proposes an alternative. That’s not idealism, it’s craftsmanship. A serious carpenter doesn’t use rotten wood because it’s cheaper. A serious cook doesn’t serve spoiled food because it increases margin. A serious engineer doesn’t sign off on a structurally unsafe design because the client is in a hurry. And yet in software—where the consequences can involve millions of people and the brain of an entire generation—we accept standards we wouldn’t accept in any other trade. * * * ## The manifesto {: #the-manifesto } I work in tech. I have a child. I can’t keep the two separate anymore. **My child is not a user.** Not a metric, not a session, not a daily active user. They are a human being with a developing brain, a judgment still under construction, a trust in the world that depends also on how I—and people like me—build that world. **My work has consequences.** Not the abstract, distant consequences of moral philosophy. The concrete ones of a system that runs twenty-four hours a day and interacts with millions of brains. If I don’t take responsibility for it, who should? **Compliance is not enough.** Respecting the GDPR, the AI Act, the EAA is the bare minimum, not the finish line. The question isn’t “is it legal?” The question is “is it right?” Those are two different questions, and the second matters more. **Speed is not a value.** “Ship fast” isn’t a virtue when what you’re shipping can cause harm. Hurry is the refuge of those who don’t want to think about consequences. Critical thinking is slow by nature. Code is fast. Wisdom is not confusing the timelines of one with the timelines of the other. **Technical training is not enough.** Knowing how to write code without knowing how to read the implications of that code isn’t competence—it’s specialized blindness. We need engineers who have read Jonas, developers who know Mill, designers who have studied developmental psychology. Not as general culture. As work tools. **My child will judge me.** Not by the revenue I generated, not by the projects I delivered, not by the technologies I mastered. They’ll judge me by the world I helped build. And in that judgment, “I was just following orders” won’t be an acceptable defense. It never has been. * * * ## To those who build {: #to-those-who-build } If you work in tech and you have kids, you know what I’m talking about. You know there’s a conversation our industry refuses to have. You know the discomfort you feel when your child disappears into a screen isn’t parental paranoia. It’s professional competence telling you something. Listen to it. I’m not saying stop building software. I’m saying build it as if the first user were your child. Because, for all intents and purposes, it could be. And if not your child, someone else’s. Which is the same thing. * * * *“We have not inherited the world from our parents. We have borrowed it from our children.”* — proverb attributed to Antoine de Saint-Exupéry --- # Progress Is Not a Direction: Anatomy of a Dangerous Misconception - **URL:** https://margiovanni.it/en/blog/progress-is-not-a-direction-anatomy-of-a-dangerous-misconception/ - **Published:** 2026-03-25 - **Tags:** AI Act, Digital Addiction, EU Regulation, Humanism - **Reading time:** 29 min > When people shout that the state is "holding back progress," are they really talking about progress: or something else entirely? ## Preamble: Why a Software Engineer Is About to Talk to You About Condorcet {: #preamble-why-a-software-engineer-is-about-to-talk-to-you-abo } There's something I need to say before anything else, because it's the reason this article exists. I did my A-levels in science. Then I read Philosophy at the University of Urbino — one of those places where philosophy isn't a bolt-on but a way of inhabiting the world, where they teach you that questions matter more than answers and that "what's the point?" is itself a philosophical question. After that, I chose technology. I've been writing code, managing infrastructure and building digital products for twenty years. And for twenty years, with varying shades of goodwill and sarcasm, I've been told that philosophy "isn't good for anything." That in the tech world, what counts is programming languages, frameworks, deployments. That Kant and Popper are charming intellectual indulgences but fundamentally decorative — a bit like a nice print above the sofa that nobody ever looks at. I always knew that wasn't true. I felt it every time I caught an ethical implication in a project meeting that everyone else had missed. I felt it when I read a piece of European legislation and, instead of seeing nothing but a compliance checklist, recognised the legal translation of a precise philosophical principle. I felt it when I discussed software architecture and realised that the truly important decisions weren't technical — they were decisions about *what kind of world* that software would help to create. Today that feeling has hardened into certainty. A humanities education is not a complement to technical thinking. It is its indispensable ethical foundation. Without it, technology is blind. Powerful, lightning-fast, ruthlessly efficient — and blind. We live at a moment in history when the systems we build can alter the neurological development of an entire generation, sway elections, decide who gets a mortgage and who doesn't, determine what millions of people will believe to be true tomorrow morning. In this context, knowing how to configure a Kubernetes cluster is not enough. You also need to know what Hans Jonas thought about responsibility towards the future. You need to have read Mill on the boundary between liberty and harm. You need to understand Anders's Promethean gap — and recognise it when you see it implemented in a recommendation algorithm. This is no longer an academic question. It's not the luxury of people with time for highbrow reading. It's an existential question — in the most concrete, least rhetorical sense of the word. Existential for us as a species, because the technological decisions of this decade will define the cognitive and social conditions in which our children will live. And existential for business, because anyone who builds technology without an ethical compass isn't just running a moral risk: they're running a market risk. Europe has grasped this. The AI Act, the GDPR, the Cyber Resilience Act, the Product Liability Directive — these are the signal that the era of technology without critical thinking is over. Those who cannot read that signal — who lack the cultural tools to understand *why* those regulations exist and not merely *how* to comply with them — will fall behind. Not as punishment, but through inadequacy. So yes: after twenty years in tech, I can say with reasonable confidence that reading Philosophy was the most important professional decision of my life. More important than any certification, any language learnt, any project delivered. Because it gave me the one thing that technology cannot give you: the ability to ask yourself whether the thing you're building *ought* to be built. What follows is an attempt to explain why. * * * ## The Most Powerful Rhetorical Weapon of Our Time {: #the-most-powerful-rhetorical-weapon-of-our-time } There is a word that, in contemporary public debate, functions as an all-purpose skeleton key. A word that shuts down discussions rather than opening them, that casts whoever invokes it as a champion of civilisation and whoever questions it as an obscurantist. That word is **progress**. "Europe is holding back progress." "Bureaucracy is killing innovation." "Regulations are shackling the future." We hear these phrases daily — on talk shows, in X threads, in tech conference keynotes, in Bay Area venture capitalists' blog posts. They present themselves as self-evident truths, yet they conceal a premise that is never made explicit: that progress is a natural force, unidirectional, intrinsically benign, and that any obstacle in its path is by definition a harm to humanity. But is that really the case? Or are we confusing progress with something far more ordinary and far less noble? * * * ## What Progress Is, and What It Has Been {: #what-progress-is-and-what-it-has-been } To answer that, we first need to understand where the very idea of progress comes from. It is not an eternal concept: it is a historical invention, and not a particularly ancient one. ### The Enlightenment and the Birth of an Idea The idea that human history has a direction — that tomorrow will be better than today — is a product of the eighteenth-century European Enlightenment. Before Condorcet, Voltaire and Kant, time was perceived as cyclical (in the Greco-Roman world) or as decline from a lost golden age. The Enlightenment revolutionised this perception: human reason, systematically applied, could improve the material, moral and political conditions of the species. Condorcet, in his *Esquisse d 'un tableau historique des progrès de l'esprit humain* (1795), imagined humanity advancing by stages towards perfection through education, science and the abolition of prejudice. It was a powerful and, in many respects, generous vision. But it already contained a problematic seed: the idea that progress was *inevitable* , almost a law of nature. Kant was subtler. He distinguished between technical progress and moral progress. In his *Idea for a Universal History with a Cosmopolitan Purpose* (1784), he suggested that humanity could advance towards a universal civil society — but only through conflict, toil, and above all through **institutions** capable of channelling what he called humanity's "unsocial sociability." For Kant, progress was not automatic: it required *structures* , *laws* , *mutual constraints*. It required, in a word, politics. ### Positivism and the Foundational Fallacy It was with Auguste Comte and nineteenth-century positivism that the idea of progress became permanently welded to *scientific and technological* progress. Comte theorised a "law of three stages" — theological, metaphysical, positive — in which science would progressively replace every other form of knowledge, guiding humanity towards a rational order. Here lies the root of the fallacy we still drag around today: the identification of **technological advancement** with **improvement of the human condition**. A fallacy the twentieth century should have destroyed once and for all — and which, with almost inexplicable stubbornness, continues to thrive. ### The Century That Should Have Taught Us Everything The twentieth century was the ultimate laboratory for testing the equation "more technology = more progress." The results were unequivocal. The same science that produced penicillin produced nerve gas. The same engineering that built bridges and aqueducts built the gas chambers — with industrial efficiency, with technical precision, with *progress* in methods. Nuclear fission gave humanity an extraordinary energy source and, simultaneously, the capacity for self-annihilation. Günther Anders, in *Die Antiquiertheit des Menschen* (*The Obsolescence of Human Beings* , 1956), captured this rupture with breathtaking clarity. Anders formulated the concept of the "Promethean gap": our technical capacity to *produce* radically outstrips our capacity to *imagine* the consequences of what we produce. We can build a bomb that kills a hundred thousand people, but we cannot *feel* — emotionally, morally — what the death of a hundred thousand people means. We have become, Anders wrote, smaller than our products. Hannah Arendt, analysing the Eichmann trial, revealed something more disturbing still: that the most radical evil of the twentieth century was perpetrated not by monsters but by efficient bureaucrats. The "banality of evil" is, in a sense, organisational progress applied to destruction. Eichmann did not hate the Jews: he optimised logistical processes. He was, in his own way, an *innovator*. * * * ## The Thought That Kills: A Thought Experiment {: #the-thought-that-kills-a-thought-experiment } Let us take a further step. Let us take it together, with the seriousness it deserves. Imagine that tomorrow — through some convergence of neuroscience, nanotechnology and brain-computer interfaces — it became possible to kill another human being by sheer force of thought. No physical weapon. No intermediary. A sufficiently focused mental intention, and the other person dies. Would this be technological progress? The superficial answer is yes. It represents an advance in understanding the brain, in the capabilities of neural interfaces, in the miniaturisation of technology. It satisfies all the criteria by which we normally define technical progress: it is new, it is more powerful than what came before, it represents a frontier of knowledge. But something within us — something deep, pre-argumentative, almost visceral — rebels against that answer. We sense that something is wrong. And that "something" is precisely what we need to examine, because it is there that the true nature of progress lies hidden. ### Hans Jonas and the Ethics of Responsibility Hans Jonas, in *The Imperative of Responsibility* (1979), anticipated precisely this kind of dilemma. He was writing in an era when genetic engineering and nuclear energy were the frontiers of technology, yet his reasoning applies with striking pertinence to our thought experiment. Jonas starts from an observation: **traditional ethics is inadequate** to confront modern technological power. Classical ethics — from Aristotle to Kant — presupposed that nature was substantially invulnerable to human action, and that the consequences of our actions were circumscribed in space and time. But modern technology has made these premises false: today we can alter the climate, modify the genome, and — in our experiment — abolish every barrier between intention and homicide. From this Jonas formulates his *technological categorical imperative* : "Act so that the effects of your action are compatible with the permanence of genuine human life on earth." This is not a conservative imperative: it is an imperative of *responsibility towards the future*. The question is not "can we do it?" but "what kind of world do we create by doing it?" In the case of the thought that kills, the answer is clear: we would create a world in which human coexistence — the foundation of every civilisation — would become impossible. There would be no safe place left, because the threat would reside in the mind itself. Every human interaction would be poisoned by terror. It would not be the end of technology: it would be the end of *society*. ### Mill's Filter: Harm as the Boundary of Liberty John Stuart Mill, in *On Liberty* (1859), formulated the principle that should be the lodestar of every discussion about progress: **individual liberty is sacred, but it ends where harm to others begins**. It is the so-called "harm principle," and in its simplicity it contains enormous wisdom. Applied to our experiment: the capacity to kill with thought is not an expansion of human freedom. It is its absolute negation. If anyone can kill anyone without intermediaries, no freedom exists at all — because freedom presupposes the security of physical existence. You cannot exercise freedom of speech, of movement, of thought if someone can annihilate you with an intention. Mill teaches us something we ought to have tattooed on our forearms: **not every expansion of individual power is progress.** Some capabilities, if universally distributed, do not emancipate — they destroy. Genuine progress is not the unlimited increase of power, but the increase of power *within the boundaries that make coexistence possible*. ### Popper: The Open Society and Its Enemies (Technological Ones Included) Karl Popper, in *The Open Society and Its Enemies* (1945), built the most robust philosophical defence of democratic institutions against every form of utopianism — including the technological variety. Popper was deeply distrustful of grand narratives about inevitable progress. For him, progress was not a triumphal march but a process of **conjectures and refutations** : we try, we err, we correct. And — crucially — we can only correct if institutions exist that allow us to do so *without violence*. The open society is one that has mechanisms of self-correction: parliaments, courts, a free press, laws that can be amended. When someone says that regulations "shackle progress," they are saying — consciously or not — that the mechanisms of self-correction are an obstacle. But an obstacle to *what* , exactly? If "progress" cannot survive democratic scrutiny, public debate, risk assessment — then perhaps it isn't progress. Perhaps it's just *haste dressed up as vision*. * * * ## Those Who Cry "Progress in Chains": A Taxonomy {: #those-who-cry-progress-in-chains-a-taxonomy } When, in public debate, someone complains that states or supranational organisations are "holding back progress," it is worth asking: who is speaking, and whose interests do they represent? ### The Techno-Optimist in Good Faith There are certainly people who sincerely believe that technology is the solution to every human problem. The position is understandable — technology *has* solved enormous problems: infant mortality, famines, epidemics. But techno-optimism becomes dangerous when it morphs into techno-determinism: the idea that technology, left to its own devices, *always* produces positive outcomes. History says otherwise. ### The Entrepreneur Who Mistakes Self-Interest for the Common Good Here we enter more delicate territory. When a Silicon Valley CEO denounces European AI regulation as an "obstacle to progress," is he really defending the future of humanity — or defending his own business model? The confusion between private interest and public good is as old as capitalism, but in the tech era it has taken on a peculiarly insidious form: it arrives wearing the clothes of the future, of innovation, of *vision*. Marc Andreessen, in his *Techno-Optimist Manifesto* (2023), took this position to its logical conclusion: markets are the supreme mechanism of progress, regulation is a brake, and those who defend it are "decelerationists" — enemies of the future. A position that has the merit of clarity and the defect of blindness: it entirely ignores the fact that markets, without rules, do not produce progress — they produce concentration of power. Adam Smith already knew this; in *The Wealth of Nations* , he warned against monopolies with the same vigour with which he championed free trade. ### The Ideological Libertarian For the radical libertarian, every form of regulation is coercion, and every coercion is evil. A philosophically consistent position — if one accepts the premises. But the premises are fragile: they presuppose that individuals operate in a social vacuum, without asymmetries of power, without externalities, without the possibility that one person's freedom destroys the freedom of many. Robert Nozick, in *Anarchy, State, and Utopia* (1974), constructed the most sophisticated version of this position. But even Nozick conceded the necessity of a "minimal state" to protect fundamental rights. The question is: when technology can alter the climate, manipulate the behaviour of billions of people, or abolish every barrier between intention and homicide, is Nozick's "minimal state" still sufficient? ### The Anti-Élite Populist Finally, there are those who deploy the rhetoric of "stifled progress" in a populist key: the bureaucratic élites of Brussels impose rules that "the people" never asked for. A position that exploits legitimate democratic frustration in order to attack institutions, yet rarely proposes credible alternatives. Because the awkward question is: if not democratic institutions, *who* should decide the limits of technology? The market? The programmers? The shareholders? * * * ## The Bomb That Has Already Gone Off: Social Media and Our Children's Brains {: #the-bomb-that-has-already-gone-off-social-media-and-our-chil } So far we have been reasoning in the abstract — thought experiments, philosophical hypotheses, future scenarios. But there is no need. The weapon that destroys without firing a shot already exists. It is in our children's pockets. It has a colourful interface, cheerful notifications, and a business model that monetises human attention by converting it into data sold to advertisers. We are talking about social media. And we must talk — with the bluntness the subject demands — about what they are doing to the brains, the psyches, and the social fabric of an entire generation. ### The Submerged Iceberg Jonathan Haidt, social psychologist and author of *The Anxious Generation* (2024), has documented with surgical precision what the epidemiological data show: after more than a decade of stability or improvement, adolescent mental health plummeted in the early 2010s. Rates of depression, anxiety, self-harm and suicide soared, more than doubling on many measures. The spike coincides with the mass adoption of smartphones. Not with the 2008 financial crisis, not with terrorism, not with climate change. With smartphones. But what we can see — the numbers that already alarm us — is only the tip of the iceberg. Consider what we know. The US Centers for Disease Control reported that in 2023, over 40% of high school students described persistent feelings of sadness or hopelessness. Among girls, 57% displayed depressive symptoms. Nearly one in three girls reported having "seriously considered" suicide — a 60% increase in the past decade. In the United Kingdom, the NHS Mental Health Survey 2025 revealed that 25.8% of young people aged 16 to 24 are affected by a common mental health disorder, up from 18.9% in 2014. Among young women, the figure reaches 36.1%. These are the *visible* data. The ones we measure because someone sought help, went to hospital, filled in a questionnaire. The submerged iceberg is made up of adolescents suffering in silence, developing subclinical disorders, losing cognitive capacity without anyone noticing. Between 70% and 80% of children with mental health disorders never receive any treatment at all. ### The Brain as Battlefield But the most unsettling dimension of this crisis is not psychological: it is neurological. And here we enter territory that should keep anyone with children, grandchildren or students awake at night. A study published in JAMA Pediatrics by Professor Eva Telzer's team at the University of North Carolina tracked 169 middle-school students over three years, monitoring their brain activity with functional MRI. The results: adolescents who habitually check social media show significantly different trajectories of brain development compared to those who do not. The affected areas include the amygdala — the centre of fear and emotional reactivity — and the dorsolateral prefrontal cortex, responsible for judgement, reasoning and reward evaluation. A very recent study, published in March 2026 in NeuroImage, analysed ABCD Study data from over 7,000 American adolescents, finding that greater daily social media use is associated with reduced cortical thickness across a wide array of brain regions. We are not talking about "feeling a bit down." We are talking about **structural alterations to the developing brain**. Generation Z — those born after 1995 — were the first generation to have smartphones during puberty. Their brains developed while algorithms designed to maximise engagement competed for their attention every waking moment. Haidt identifies four foundational harms: social deprivation (real relationships replaced by digital ones), sleep deprivation, attention fragmentation, and addiction. And the research confirms it: repeated consumption of short-form video repeatedly activates the brain's reward circuitry, leading to dopamine dysregulation, reduced sustained attention, increased impulsivity and disrupted sleep patterns. In practical terms, these young people's brains are being *reconfigured* to function in ways that compromise cognitive control. ### The Slot Machine in Your Pocket Here we must be explicit about a point that is too often played down: **social media did not become harmful by accident. They were designed to be this way.** The psychological mechanisms that make social media compulsive are the same — identical, not "similar": identical — as those that make slot machines addictive. They are called "variable ratio reinforcement schedules": unpredictable, intermittent rewards of varying magnitude. This is the principle B.F. Skinner documented in the 1950s studying pigeons: of all possible reinforcement schedules, the variable ratio is the most powerful at maintaining behaviour — and the most resistant to extinction. Every time you scroll through a TikTok or Instagram feed, you are pulling the arm of a fruit machine. You do not know which scroll will bring something interesting. It might be the next one. Or the one after. Or ten scrolls away. This uncertainty generates more dopaminergic activity than a predictable reward. The anticipation, the not knowing, is itself the drug. The crucial difference: casinos are regulated. They must declare the odds. They cannot admit minors. They cannot operate without a licence. Social media platforms have none of these constraints. Natasha Schüll, author of *Addiction by Design* , has put it plainly: social media companies use exactly the same methods as the gambling industry to keep users online, because in the attention economy revenue is a function of time spent on the platform. The pull-to-refresh gesture that mimics pulling a slot machine lever. The red notification badges that exploit the Zeigarnik effect — the psychological tension of incomplete tasks. Snapchat streaks that turn friendship into a gamified metric. TikTok's algorithm, which learns within hours precisely which content will keep you glued to the screen. Chamath Palihapitiya, former vice-president of growth at Facebook, admitted it publicly: the short-term, dopamine-driven feedback loops we have created are destroying how society works. Sean Parker, Facebook's first president, declared that the objective was "to consume as much of your time and conscious attention as possible" and that the platform exploits "a vulnerability in human psychology." These are not accusations from outsiders: they are admissions by the people who built the systems. And the internal research confirmed it: documents made public by whistleblower Frances Haugen showed that Instagram knew it was making body image issues worse for one in three teenage girls. They knew. And they chose profits. ### The Difference from Conventional Weapons This is where the analogy with the atomic bomb from our thought experiment stops being hyperbole. A conventional weapon kills the body. The damage is visible, immediate, documentable. The world notices. There are photographs, casualty figures, memorials. The damage activates a social response: wars are declared, treaties are signed, monuments are erected. Social media operate on an entirely different register. The damage is **invisible** , **gradual** , **cumulative** and — this is the critical point — **normalised**. Nobody sees a neuron being reconfigured. Nobody hears the sound of a prefrontal cortex thinning. Nobody perceives sleep deprivation as an emergency when it affects a hundred million adolescents simultaneously. The damage hides behind the everyday: "it's just the phone," "all kids are like that," "we used to sit in front of the telly for hours." But the telly was not engineered to create addiction through variable ratio reinforcement schedules. The telly did not follow you into your bedroom at three in the morning. The telly did not have an algorithm that learnt exactly which insecurities to exploit to keep you staring at the screen. The telly did not give you a real-time numerical metric of your social worth. And then there is the question of scale. A bomb destroys a city. Social media are altering the brain development of **an entire generation on a planetary scale**. Not a specific group, not a geographically bounded population: anyone, anywhere in the world, between the ages of 3 and 20 who has a connected device. The World Health Organisation surveyed nearly 280,000 young adolescents across 44 countries: 11% showed signs of problematic social media use. At global scale, these are numbers that dwarf any other public health emergency. And a bomb goes off once. Social media operate continuously — 24 hours a day, 7 days a week, 365 days a year. There is no ceasefire. There is no peace treaty. The exposure is chronic, uninterrupted, and starting ever earlier: children of 3 or 4 with tablets programmed to entertain them, 8- or 9-year-olds with their first smartphone, 11- and 12-year-olds already immersed in social platforms. Sixty-four per cent of American children aged 11–12 already use social media. ### The Destruction of Families There is an aspect the numbers do not capture, one that concerns the connective tissue of society itself: the family. Anyone with school-age children knows exactly what I mean. The smartphone has become the principal domestic battleground. This is not a matter of "rules" or "screen time limits" — it is structural. The device is engineered to be more attractive, more stimulating, more rewarding than any family interaction. A parent reading a bedtime story is competing with an algorithm that has analysed billions of interactions to know precisely what captures that child's attention. It is an asymmetric war, and the family is losing it. Parents feel powerless, inadequate, perpetually behind a technology that evolves faster than their ability to understand it. Children feel controlled, misunderstood, cut off from their peers if they lack access to the platforms. The result is a daily erosion of trust, dialogue and connection — the very things that make a family a family. Here we return to Anders and his Promethean gap: today's parents are the first generation in history to have to protect their children from a threat they can neither see nor fully comprehend. It is not like protecting a child from traffic or alcohol: those are visible threats with known dynamics. Here the threat is an invisible architecture of algorithmic persuasion operating directly on the neurological reward circuits. It is like asking a parent in 1945 to shield their child from radiation without knowing what radiation is. ### The World Is Already Reacting The world — slowly, far too slowly, but undeniably — has begun to react. The US Surgeon General, Vivek Murthy, compared social media addiction to cigarettes and called for the platforms to carry a health warning. In 2023 he cautioned that children spending more than three hours a day on social media double their risk of mental health problems. In December 2025, Australia became the first country in the world to ban social media access for under-16s. The law requires platforms to take "reasonable steps" to prevent minors from creating or maintaining accounts, with fines of up to AUD 49.5 million for non-compliant companies. To date, over 4.7 million accounts have been deactivated, removed or restricted. France, Norway, Denmark, Malaysia, Spain, Indonesia and Italy itself are considering or implementing similar measures. It is a global movement that, tellingly, is encountering resistance exactly where one would expect: from the platforms themselves (Reddit has filed a challenge in the Australian High Court) and from libertarian groups denouncing the infringement of minors' freedom of expression. It is the same dynamic we saw with tobacco, with asbestos, with lead in petrol: the industry that causes the harm fights regulation by invoking individual liberty and progress, while the harm accumulates silently in the bodies and brains of the victims. ### The Question We Must Ask Ourselves If progress is the expansion of our collective human capacity to live freely, with dignity and sustainably, then are social media — in their current form — progress? The answer, it seems to me, is no. Not because the technology of digital connection is inherently bad, but because the *way* it has been implemented — engagement algorithms that exploit neurological vulnerabilities, business models built on addiction, a total absence of accountability for the damage caused — represents the antithesis of progress. It is the deployment of the most advanced neuroscientific knowledge to *reduce* human capacity rather than expand it. If we could see the damage — if every thinning of the prefrontal cortex made a noise, if every episode of adolescent self-harm were a visible explosion — we would have reacted with the same urgency with which we react to a bomb. But the damage is silent. And silence is the greatest ally of those who cause and monetise it. The thought experiment of the thought that kills, on reflection, is not so hypothetical after all. We have already given corporations the power to alter the brain development of billions of young human beings. The fact that they do so to sell advertising rather than out of malice does not make the damage less real. It only makes it harder to name. * * * ## Europe and the Humanist Choice {: #europe-and-the-humanist-choice } This is where we must talk about Europe. Not the Europe of grumbling — the Europe of triplicate forms and regulations on the curvature of bananas. But Europe as a *philosophical project*. ### The European Regulatory Framework as a Choice of Civilisation In recent years, the European Union has produced a body of technology regulation without parallel anywhere in the world: the GDPR for personal data protection, the Digital Services Act and Digital Markets Act for platform regulation, the AI Act for artificial intelligence, the Cyber Resilience Act for the security of digital products, and the updated Product Liability Directive extending to software and AI. Seen from Silicon Valley, this is "bureaucracy stifling innovation." Seen from the perspective of moral philosophy, it is something profoundly different: the most ambitious attempt in history to apply the principles of European humanism to the technological revolution. Take the AI Act. Its structure — risk-based, with outright prohibitions on the most dangerous applications (social scoring, subliminal manipulation, mass biometric surveillance) and escalating requirements for high-risk ones — is a legislative translation of Jonas's principle. It does not say "do not innovate": it says "innovate, but not at the expense of human dignity." It is not a brake: it is a *rudder*. The extension of the Product Liability Directive to software is another example. For the first time, software producers will be liable for damage caused by their products — exactly as manufacturers of cars, medicines and household appliances already are. For those who have internalised the notion that software is an ethereal, immaterial entity exempt from the rules of the physical world, this is scandalous. For those who believe that power must be accompanied by responsibility, it is a civilisational advance. The Digital Services Act and Digital Markets Act, moreover, are a direct response to the neurological catastrophe we have described. The DSA imposes transparency obligations on recommendation algorithms, bans the profiling of minors for advertising purposes, and gives users the option to switch off personalised recommendation systems. The DMA aims to break the monopolistic power of the major platforms — the "gatekeepers" who control digital access for billions of people. Are these imperfect instruments? Certainly. But they are the only instruments a democracy has at its disposal to respond to a power that, left unchecked, is quite literally rewiring the brains of its youngest citizens. ### Accessibility as a Paradigm of Genuine Progress The European Accessibility Act deserves special mention, because it perfectly embodies the difference between technical progress and human progress. The EAA requires digital products and services to be accessible to people with disabilities. For a tech company focused exclusively on speed and efficiency, this is a cost, a constraint, a "drag on progress." But let us pause for a moment: **is an innovation that excludes a portion of humanity really progress?** If we define progress as the expansion of human possibilities — not the possibilities of *some* humans, but of humanity as a whole — then accessibility is not a constraint on progress. *It is* progress. A digital product that 15% of the world's population cannot use is not innovative: it is incomplete. Martha Nussbaum, in her *capabilities approach* (developed with Amartya Sen), formulated a theory of progress that points in precisely this direction: progress is measured not by GDP, not by the number of patents, not by processor speed, but by **the effective capability of individuals to live a life worthy of being lived**. If a technology increases this capability for everyone, it is progress. If it increases it for some at the expense of others, it is power — not progress. * * * ## Confusing Speed with Direction {: #confusing-speed-with-direction } There is a category error that pervades the entire contemporary discourse on innovation: the confusion between **speed** and **direction**. "Move fast and break things" — Facebook's original motto — is the epitome of this confusion. Moving fast is only a virtue if the direction is right. Otherwise, it is simply running towards a cliff with greater efficiency. When Sam Altman says that "regulation risks slowing the development of AI," the question nobody asks is: *slowing it towards where?* If the direction is the concentration of power in the hands of a few companies, the reinforcement of algorithmic bias, ubiquitous surveillance masquerading as personalisation — then slowing down is not a harm. It is wisdom. Epicurus — the most materialist and least mystical of the ancient philosophers — taught that the purpose of life is *ataraxia* : tranquillity of mind, freedom from disturbance. Not the accumulation of power, not the conquest of nature, not speed. Tranquillity. A lesson the tech world appears to have forgotten entirely: not everything that is possible is desirable. Not everything that is fast is good. Not everything that is new is better. Simone de Beauvoir, in *The Ethics of Ambiguity* (1947), offers another vital tool: freedom is never absolute, but always *situated*. We are free only in the context of relationships with other free beings. My freedom has meaning only if I recognise and preserve the freedom of others. Translated to the technological context: my freedom to innovate has meaning only if it does not destroy the freedom — the safety, the dignity, the autonomy — of those who will be affected by my innovation. * * * ## Progress as Collective Construction {: #progress-as-collective-construction } It is time to propose an alternative definition. If progress is not simply technical innovation, if it is not speed, if it is not the accumulation of capability — what is it? I propose this: **progress is the expansion of our collective human capacity to live freely, with dignity and sustainably.** Every word matters. *Expansion* , because progress is an enlargement, not a replacement; it does not demolish what works in pursuit of the new. *Human capacity* , not the capacity of machines or markets but the capacity of real people to act in the world. *Collective* , because if it is not for everyone it is not progress: it is privilege. *Freely* , in the Millian sense of freedom to think, speak and live as one wishes, within the limits of harm to others. *With dignity* , in the Kantian sense of every person as an end in themselves, never merely a means. *Sustainably* , because it does not sacrifice the future for the present, does not steal from grandchildren to give to children. With this definition, a great deal changes. Penicillin is progress. Universal suffrage is progress. Clean drinking water for all is progress. Digital accessibility is progress. The GDPR is progress. The atomic bomb is not progress. Mass surveillance is not progress. An algorithm that maximises engagement through addiction is not progress. A platform that thins the prefrontal cortex of millions of adolescents to sell advertising is not progress. And the thought that kills — our opening hypothesis — is not progress. It is the end of progress. It is the end of everything. * * * ## Humanism as Compass, Not Chain {: #humanism-as-compass-not-chain } Let us return, in closing, to the opening question. When someone says that the state, or Europe, or the United Nations is "shackling progress," what are they really saying? They are saying — almost always — that *their* way of innovating, *their* business model, *their* vision of the future is being subjected to constraints they dislike. They are confusing their own freedom of action with the freedom of humanity. They are mistaking the absence of limits for the absence of oppression. But the absence of limits is not freedom: it is the law of the strongest. It is the Hobbesian state of nature — the *bellum omnium contra omnes* , the war of all against all — in which life is "solitary, poor, nasty, brutish, and short." Institutions, laws, mutual constraints are not chains: they are the foundations of coexistence. They are what makes possible not merely survival, but human flourishing. Humanism — the real thing, the tradition that begins with Pico della Mirandola and runs through Montaigne, Hume, Voltaire, Mill, Arendt and de Beauvoir to Nussbaum — has never been against knowledge or technology. It has been against the use of knowledge and technology *against the human*. Humanism is the compass that enables us to distinguish genuine progress from the mere accumulation of power. Those who build technology today bear an immense responsibility — probably the greatest any generation has ever borne. Not because technology is evil, but because technology is *powerful*. And power without responsibility, without limits, without the capacity to self-correct, is not progress. It is just danger moving fast. * * * ## Postscript: A Personal Note {: #postscript-a-personal-note } I have worked in technology for twenty years. I build software. I manage infrastructure. I configure CI/CD pipelines, write specifications, plan sprints. Technology is my trade and, in many respects, my passion. Precisely because I know it intimately — its wonders and its miseries, its power and its fragility — I refuse, with every fibre, the idea that regulating it is a hostile act. When I implement the GDPR in a project, I am not "stifling innovation": I am protecting the people for whom that project exists. When the AI Act asks me to document the risks of a high-risk system, I am not "wasting time": I am doing my job with the seriousness it deserves. When the EAA obliges me to make an interface accessible, I am not "adding costs": I am including human beings who would otherwise be shut out. But there is another reason, more personal and more urgent, why this subject burns. I am also a father. And as a father, I live every day with the awareness that the digital world in which my child will grow up was designed by people who do the same job I do — people who know exactly what they are doing to the reward circuits of a developing brain. I know the design patterns, I know the metrics, I know the language in which "retention" and "engagement" strategies are discussed. I know that behind neutral words lie deliberately engineered mechanisms of addiction. And I know that my technical expertise is not sufficient to protect a child from an industry that has invested billions learning how to capture their attention. This is why I believe that regulation is not merely legitimate: it is an act of civilisation. Those who build technology have a moral obligation to build it *for* human beings — not *against* them. And when they fail to do so, it is right and necessary that society — through its imperfect, slow, maddening institutions — should intervene. Genuine progress has never been fast. It has been arduous, contentious, full of second thoughts and course corrections. It has been — to use Popper's metaphor — a process of conjectures and refutations, not a triumphal march. And the institutions that govern it — imperfect, slow, occasionally exasperating — are the price we pay for not entrusting the fate of humanity to whoever happens to be running fastest. That is not a high price. It is a bargain. * * * *" The degree of civilisation of a society can be measured by the amount of power it is willing to relinquish."* — freely inspired by Norbert Elias, *The Civilizing Process* (1939) --- # From developer to partner: a career in IT services - **URL:** https://margiovanni.it/en/blog/from-developer-to-partner-a-career-in-it-services/ - **Published:** 2026-03-24 - **Tags:** Tech Career, Consulting, IT Services, IT Sourcing - **Reading time:** 8 min > Three roles, three lenses on the IT market: corporate, startup, and a client portfolio. A non-linear path that clarifies what really matters in sourcing. I often hear people talk about careers as if they were a ladder. One step after another, one title after another, and in the end some kind of neat, complete meaning. Then I look at mine and I can’t help but smile, because I don’t see a ladder. I see more like a series of different rooms, each with a window onto a piece of the IT services market. This isn’t a “motivational” story. It’s more of a notebook thing, almost an anatomy. Because in hindsight I realize that every phase left me with a different lens. And today, as I work as Head of Tech and partner in a small ICT company, those lenses are finally starting to overlap. ## The strange thing about non-linear careers {: #the-strange-thing-about-non-linear-careers } Linear careers may have never really existed, but for a while we believed in them. I definitely did. Then I found myself moving from Interface Developer at one of Europe’s largest luxury e-commerce groups (before it entered the Richemont orbit), to CTO at a deep-tech startup in oil & gas, all the way to managing a portfolio of projects that are very different from one another in a company of about ten people. If I have to say what these stages have in common, it’s not the technology. That changes, and it changes faster than we like to admit. The common thread is something else: every role made me see *how IT services are bought and sold*. And above all, why decisions that look technical often aren’t technical at all. ## Phase 1: inside a big player, from the code side {: #phase-1-inside-a-big-player-from-the-code-side } When you’re in a large organization and you’re not in management, you risk thinking certain dynamics don’t concern you. In reality they still run right through you—you just experience them “by reflection.” I was in the code, but working in a group at that scale makes you see things that stay invisible from the outside. For example, how the relationship with technology vendors is actually managed. Not in theory, not in the deck, but day to day. I saw that behind an architectural choice there’s often an organizational choice, a budget choice, sometimes even a power choice. And I also saw a difference that annoyed me at first, then I understood it was simply real: vendors chosen for competence and vendors chosen due to contractual inertia are not the same thing, but on paper they look identical. The first rule I carry with me from that phase is this—and maybe it’s a bit cynical, but it feels true. **The best vendor isn’t the one with the best proposal, it’s the one that understands how the client organization works.** It’s a rule that’s hard to put into a framework. It’s qualitative, contextual. And it requires an understanding of internal dynamics that you often only pick up by being there, by osmosis. I still wonder today how many bids and selections fail not because the provider isn’t capable, but because they didn’t read the client’s “nervous system.” ## Phase 2: the startup, i.e., the real cost of choices {: #phase-2-the-startup-ie-the-real-cost-of-choices } The jump to the startup was, without exaggeration, the one that changed me the most. As CTO of a deep-tech startup vertical in oil & gas, I found myself doing everything. Tech stack, hiring, processes, budget, clients, delivery. All at once, often on the same day. And there you learn something that stays more blurred in big companies: the cost of decisions isn’t an abstract concept. It’s immediate. Every choice has a direct impact on the P&L, on time-to-market, on the team’s sustainability. In that phase I learned to price IT services not “based on the market,” but based on the structure of real costs. Which sounds trivial until you crash into it. I also learned that a service priced too low is more dangerous than one priced too high, because sooner or later someone will pay the difference. And often the one who pays is the client, in the form of technical debt, delays, turnover, rushed patches. Another important piece was contracts. Not the ones written to win a negotiation, but the ones that let you work. I understood that there are contracts that “protect” and contracts that “work.” The first are full of penalties no one wants to enforce. The second define aligned incentives, a collaboration zone where both parties have a reason to do the right thing. The second rule, here, became almost a conviction. **The quality of an IT service is decided before the project starts, in the architectural choices and in the processes the provider sets up.** When the code starts flowing, many games have already been played. Not all of them, of course. But many. ## Phase 3: the multi-client portfolio, where boundaries blur {: #phase-3-the-multi-client-portfolio-where-boundaries-blur } Today I work in a small ICT company, about ten people, that operates as a B2B technology partner. Clients range from large corporates to Public Administrations. My role is a continuous intersection of technical leadership, sprint planning, DevOps, compliance, and architecture. And above all it’s “portfolio” work, so with very different contexts living side by side. In the same period we might be involved in a regional healthcare information system, a people analytics SaaS platform, an industrial IoT infrastructure, cybersecurity services as a certified partner of a leading vendor, regulatory compliance projects, and custom development for the PA. This phase is the one where the two previous experiences lock together. On one side I have the memory of the big player, so I understand how enterprise clients think, what truly worries them, what the implicit constraints are. On the other I have the startup sensitivity, so I know what it means to be efficient with limited resources, and how much automation and operational discipline matter. But the new lesson—the one I didn’t expect—is another. **The IT services market is fragmented in ways many advisory frameworks don’t capture.** We’re not a generalist system integrator, but we’re not an ultra-specialized boutique either. We’re that slightly awkward thing to label: an agile technology partner with cross-cutting skills. And in certain contexts we compete with players ten times larger, not because we’re “better” in absolute terms, but because processes are leaner and, more and more, because AI-assisted development is changing the relationship between productive capacity and team size. Maybe it’s here that I realized how much the map doesn’t match the territory. In quadrants and reports some categories are crisp. In real life, much less so. ## What these phases taught me about IT sourcing {: #what-these-phases-taught-me-about-it-sourcing } If I try to translate all this into practical implications for sourcing, three ideas come to mind—which are also three recurring “flaws” in the way providers are evaluated. The first comes from the big company: sourcing decisions are often organizational decisions disguised as technical decisions. So whoever does advisory should understand the client’s internal dynamics as much as they understand the provider’s capabilities. Otherwise they risk recommending the “best on paper” and getting the worst in practice. The second comes from the startup: the economics of IT services are far more granular than they appear in market reports. A provider’s margin on a single project can swing enormously based on architectural choices, the level of automation, process maturity. And if you don’t read these dynamics, you don’t truly protect the client. You only protect them formally. The third comes from portfolio work: the real market is more diverse than frameworks suggest. The tech SMEs that serve Europe’s economic fabric often don’t show up in the quadrants, but they deliver a significant share of IT services. If you don’t know that segment, you’re offering clients an incomplete set of options. And you might not even realize it. ## The cumulative value, and why it matters now {: #the-cumulative-value-and-why-it-matters-now } There’s a pattern I notice in careers that produce “non-conventional” value. It’s not the single experience that makes the difference, but the intersection. An analyst who has only worked in consulting knows the frameworks, but maybe has never lived through delivery when things go wrong. A technician who has only worked in development knows the code, but doesn’t always see the business. A manager who has only worked in corporate knows the political dynamics, but risks losing touch with real costs and operational grind. The meaning of my trajectory, if it has one, is crossing these worlds. And it seems to me that today this ability to connect is no longer a “nice to have.” With AI entering processes, European compliance becoming increasingly stringent, pricing models changing, reshoring and new expectations around security and data sovereignty, complexity isn’t going down. It’s going up. And when complexity goes up, simple answers start to sound suspicious. ## The next step, with a bit of honesty {: #the-next-step-with-a-bit-of-honesty } Lately I feel that the natural evolution of this path is to bring this integrated perspective to those who have to make high-impact sourcing decisions. Not as an operational consultant—that’s what I already do. Rather as a market analyst, researcher, strategic advisor. In a context where depth of operational experience and the ability to produce actionable insights are the core of the value proposition. It’s the kind of role that some companies, with a lot of effort and a lot of investment, try to embody well. Not because I have the right answers. On many things, honestly, I’m not even sure I have a single answer. But because I believe I have the right questions—the ones that come from having seen the IT services market from different angles. And maybe that’s exactly what’s most needed today. *Next in the series: how the European regulatory storm is redefining the criteria for evaluating IT providers, and why the advisory market still isn’t ready.* --- # What an IT Provider Knows That a Sourcing Analyst Doesn't - **URL:** https://margiovanni.it/en/blog/what-an-it-provider-knows-that-a-sourcing-analyst-doesnt/ - **Published:** 2026-03-23 - **Tags:** IT Advisory, IT Services, Sourcing, Consulting - **Reading time:** 5 min > The structural blind spot of the IT services advisory market—and why closing it is urgent, before sourcing decisions keep going wrong at scale. There’s a paradox in the IT services advisory market that has been hitting me for years: the people tasked with advising companies on how to choose their technology vendors are, in the vast majority of cases, people who have never built, priced, delivered, or defended an IT service in front of an unhappy customer. This isn’t a critique. It’s a structural observation. And it has real consequences on how sourcing decisions are made, and on how many of those decisions turn out to be wrong. ## The job, seen from the inside {: #the-job-seen-from-the-inside } I spent more than fifteen years on the other side of the table. Not as someone who evaluates IT services, but as someone who designs them, sells them, delivers them, and is accountable when something doesn’t work. At YNAP (Yoox for the older folks) I saw how one of the largest European e-commerce platforms managed the relationship with its technology vendors. Not in theory: in the day-to-day practice of architectural choices, negotiations over deliverables, decisions that determine whether a project delivers value or delivers only code. As CTO of Anthis I built from scratch the technical infrastructure and delivery processes of a company. It’s the kind of experience that teaches you that the difference between an IT service that works and one that doesn’t is almost never in the technology chosen, but in the quality of the decision-making process that leads to that technology. And today, as Head of Tech & Partner at Oltrematica (I know, this role doesn’t exist but we’ll get there), I run a portfolio of projects for clients ranging from TIM to Randstad, from the Abruzzo Region to the Chambers of Commerce. I write RFPs and respond to RFPs. I define SLAs and I have to meet them. I price managed services knowing exactly how much each component of the delivery chain costs. This experience gave me access to a kind of knowledge that is hard—maybe impossible—to acquire from the outside. ## The things you can only see from the inside {: #the-things-you-can-only-see-from-the-inside } When I read provider evaluation frameworks (Magic Quadrant, PEAK Matrix, ISG Provider Lens) I recognize the quality of the analysis and the methodological rigor. But I also see the blind spots. And they’re always the same. ### The real cost of an IT service isn’t in the price The quoted price in a managed services offer is a number. The real cost is a complex system that includes the price, plus the cost of communication inefficiencies, plus the cost of technical debt that accumulates when the provider cuts corners to stay within budget, plus the opportunity cost of features that don’t get delivered because the contract doesn’t include them. An analyst who evaluates providers by comparing day rates is measuring the wrong variable. A provider that quotes €400/day and delivers in 20 days costs less than one that quotes €300/day and takes 40. But to understand which one will deliver in 20 and which in 40, you need to know how to read the proposed technical architecture, the team composition, the level of automation in delivery processes. It’s a competence that comes from having built those processes, not from having observed them. ### SLAs are a language, not just a contract In my experience, most problems in IT outsourcing contracts don’t come from wrong SLAs. They come from ambiguous SLAs. An SLA that says “99.9% availability” is technically precise but operationally empty if it doesn’t specify: how is availability measured? Is scheduled maintenance included? What time window is used for the calculation? What happens when downtime is caused by a third party (the cloud provider, the CDN, the DNS)? I’ve written SLAs for years. And I learned that a good SLA isn’t the one that promises more, but the one that defines with surgical precision what happens when things go bad. Because in IT services, things always go bad sooner or later. Provider quality is measured in the response, not in the promise. ### Team composition matters more than size Evaluation frameworks tend to reward providers with large teams and multiple delivery centers. It’s a reassuring metric for buyers: more people = more capacity. But anyone who has managed development teams knows it’s not like that. A team of 5 well-coordinated senior developers produces more high-quality output than a team of 15 people with 3 layers of management and constant turnover. Especially when that team of 5 uses AI-native methodologies that multiply individual productivity. At Oltrematica we simultaneously run 8–10 active projects with a team of about 10 people. Not because we’re heroes, but because we invested in automation, efficient delivery processes, tools that eliminate low value-added work. It’s the kind of efficiency that doesn’t show up in any quadrant. ## The value of an operational perspective in advisory {: #the-value-of-an-operational-perspective-in-advisory } I’m not suggesting that all analysts should have worked as IT providers. I’m suggesting that the operational perspective is a strategic asset in advisory that today is dramatically underrepresented. When a CISO asks me whether a managed security provider is reliable, I don’t have to rely only on certifications and references. I can read the proposed architecture and understand whether it was designed to be operated or just to win the bid. I can look at the Statement of Work and identify the gray areas that will turn into contractual disputes 18 months from now. I can assess whether the proposed staffing model is sustainable or whether the provider is promising a team they don’t have and will have to build after-the-fact. This kind of insight doesn’t come from analytical rigor. It comes from having lived the same dynamics on the other side. And it has enormous value for enterprise clients who are about to make multi-million-euro sourcing decisions. ## The necessary convergence {: #the-necessary-convergence } The IT services advisory market is entering a phase where the complexity of sourcing decisions is increasing exponentially. AI, European compliance, reshoring, new pricing models, cybersecurity by design: these are all dimensions that require deep technical understanding to be evaluated correctly. Generic frameworks are no longer enough. Clients ask for—**and have the right to get** —advisors who speak the providers’ language with the same fluency with which they speak the language of business. It’s a convergence that the market hasn’t produced systematically yet. But it’s inevitable. And whoever anticipates it will have an enormous competitive advantage. * * * *This article is the first in a series on my view of the IT services sourcing market. In the next piece I’ll explore my personal journey—from developer to partner—and how each phase helped build an integrated perspective on the IT services market.* --- # Who Owns the Workbench - **URL:** https://margiovanni.it/en/blog/who-owns-the-workbench/ - **Published:** 2026-03-20 - **Tags:** AI, Anthropic, Coding Agents, Developer Tools - **Reading time:** 8 min > OpenAI buys Astral, Anthropic bought Bun. The quiet colonization of the development stack has already begun, and it's not about open source. There's a line on Hacker News that's been stuck in my head since last night, ever since I read the news about OpenAI acquiring Astral. It goes: "OpenAI and Anthropic are making plays to own the means of production in software." The means of production. It's one of those phrases that sounds a bit overblown the first time you read it. Then you sit with it. And you sit with it some more. And eventually you realize it might not be overblown enough. Astral is the startup behind uv, Ruff, and ty—three tools that in just a few years have become load-bearing infrastructure for millions of Python developers. uv solved environment and dependency management with an elegance and speed that pip never had. Ruff made linting and formatting so fast they became invisible. ty is doing the same for type checking. They're written in Rust, all open source, all permissively licensed. And as of yesterday, all owned by OpenAI, which will fold the team into Codex, its coding agent that already counts over two million weekly active users. Three months ago, in December, Anthropic made a similar move by acquiring Bun, the JavaScript runtime created by Jarred Sumner. Claude Code, their agentic coding tool that hit one billion dollars in annualized revenue in six months, ships as a Bun executable. Sumner put it with almost brutal clarity in his announcement post: "If Bun breaks, Claude Code breaks." So Anthropic bought the infrastructure that its billion-dollar product runs on. Two acquisitions in three months, by the two companies fighting for dominance in AI-assisted coding. Look at them individually and each one makes sense. Look at them together and the pattern is unmistakable. Here's what the pattern is: the companies building language models are buying, piece by piece, the toolchain those models operate on. Not the cloud. Not the chips. Not the data centers. The tools that sit between the model and the code. The package manager. The linter. The runtime. The type checker. Everything an AI agent needs to go beyond generating code and actually run it, test it, validate it, and push it back to production. This isn't philanthropy toward open source. It's infrastructure strategy. ## Ninety-Five Percent Is Context {: #context-is-95-percent } To understand what's happening, you have to start with something that's often underestimated: language models, on their own, generate code. But generating code is not building software. Anyone who's tried to have an agent write an entire project knows this—you end up with something that compiles but doesn't work, or works but doesn't follow the repo's conventions, or follows the conventions but breaks three tests nobody anticipated. Generation is five percent of the job. The other ninety-five percent is context: resolving dependencies, passing the linter, managing types, running tests, integrating into CI/CD, maintaining code over time as libraries update and requirements shift. And here's the point. An AI agent that wants to handle that ninety-five percent needs to own, or at least control, the tools that compose it. It's not enough to know that uv exists. uv needs to respond to the agent's needs, be optimized for its workflows, evolve in the direction that makes the agent more effective. The same goes for Ruff, for ty, for Bun. When OpenAI writes in its announcement that the goal is to "move beyond AI that simply generates code and toward systems that can participate in the entire development workflow," that's not marketing. It's a precise description of why they bought Astral. I see this every day in my work. I use Claude Code on Laravel projects, I manage CI/CD pipelines with GitHub Actions, and the difference between an agent that generates a file and an agent that understands the context that file has to live in is the difference between a useful tool and a toy. When the agent knows the rules of my linter, understands how my dependencies are structured, grasps my deployment flow—that's when it actually becomes a collaborator. And to be that kind of collaborator, it has to speak the language of the tools I use. If whoever builds the agent also owns those tools, the competitive advantage is enormous. ## A New Kind of Lock-In {: #new-kind-of-lock-in } But this is exactly where things get interesting. And a little unsettling. Because what's emerging is a new kind of vendor lock-in, unlike anything we've seen before. The old lock-in was explicit: you chose a cloud provider, you chose a proprietary database, and at some point migration became prohibitively expensive. You knew it, you did the math, you made the call. The new lock-in is different. It's implicit. You don't notice it happening because every single piece looks open source, looks free, looks neutral. uv is still MIT-licensed. Bun is still MIT-licensed. You can fork them, you can use them without Codex or Claude Code, you can do whatever you want. But the real question is different: two years from now, when eighty percent of uv's evolution is driven by Codex's needs, when the priority features are the ones that serve OpenAI's agent rather than you running uv from the terminal—will forking actually be a viable option? Simon Willison, who has one of the sharpest minds in the ecosystem, wrote yesterday that the worst-case scenario takes the shape of "fork and move on." But then he added, honestly, that OpenAI doesn't yet have a track record in maintaining acquired open source projects. And that an acquisition that starts as product-plus-talent can turn, over time, into a talent-only acquisition. This is a point I keep coming back to. The code stays open, but the direction becomes closed. It's a form of control that doesn't violate any license, doesn't betray any explicit promise, and yet concentrates power in significant ways. Someone on Hacker News captured the dynamic well: "As they gobble up previously open software stacks, how viable is it that these stacks remain open?" Technical viability persists. Practical viability erodes. I write this and I already hear the objections—the same ones I've made to myself. "But the incentives are aligned," many say. "Anthropic needs Bun to work well for everyone, not just Claude Code, because broad adoption creates network effects." And that's true, at least today. "The MIT license protects the community," others say. And that's true too, at least in theory. But I've seen enough acquisitions in my career to know that the promises made on announcement day come with an unwritten expiration date. Jarred Sumner's post was honest on this point: "No one can guarantee how motives, incentives, and decisions might change years down the line." And I'd add that the incentives of a startup with zero revenue and four years of runway ahead look very different from the incentives of a division inside a company that burns two and a half dollars for every dollar of revenue and needs to justify every acquisition to investors waiting for an IPO. ## The Battle for the Workflow {: #battle-for-the-workflow } There's another dimension that strikes me, and it has to do with how these acquisitions are redefining competition itself. Until yesterday, the battle between OpenAI and Anthropic was fought on model quality. Who reasons better, who generates cleaner code, who has the longer context window. Today the battle is shifting to a different plane: who controls more surface area of the developer's workflow. It's no longer just "my model is better than yours." It's "my model works inside an ecosystem I own and that optimizes every step." Code generation becomes a commodity, and value migrates to orchestrating the entire cycle. Whoever owns the linter, the package manager, the runtime, and the coding agent has a structural advantage that no benchmark can capture. The question I keep asking myself, and one that doesn't have a clear answer yet, is what all of this means for those working with stacks other than Python and JavaScript. Many teams haven't (yet) experienced this kind of concentration. But the pattern is clear, and it will expand. Today it's Python and JavaScript because those are the languages of AI and the web. Tomorrow it could be any ecosystem where coding agents need reliable tooling to operate autonomously. The race to acquire the building blocks of development infrastructure has only just begun. An analogy comes to mind—maybe a bit strained, but it helps me think. For decades, oil was the fuel of the industrial economy, and whoever controlled the refineries and pipelines held more power than whoever extracted the crude. In software, language models are the crude. They produce output. But the real value lies in the refinery: the tools that take that output and turn it into working, tested, compliant, deployed software. The AI companies have figured this out. And they're buying the refineries. ## A Political Choice {: #a-political-choice } And we're caught in the middle of this transition without having chosen it. We use uv because it's the best tool available. We use Bun because it's fast and solves real problems. Our choices are rational and individual. But the aggregate effect of millions of rational, individual choices is the concentration of infrastructural power in the hands of a few companies that didn't build those tools. They bought them. I don't know where this leads. Maybe the incentives will stay aligned long enough to avoid real problems. Maybe the MIT license will prove to be sufficient protection. Maybe the market will remain competitive enough to prevent abuse. But maybe not. Maybe we're building a dependency we'll only recognize as such when it's too late to walk away gracefully. **What I do know is that choosing your package manager, your runtime, your linter has never been a purely technical decision. Today, whether you like it or not, it 's also a political one.** And like all political choices, it deserves to be made with open eyes. --- # AI and IT consulting: goodbye to time & materials - **URL:** https://margiovanni.it/en/blog/ai-and-it-consulting-goodbye-to-time-and-materials/ - **Published:** 2026-03-19 - **Tags:** AI, Digital Transformation, IT Consulting, IT Strategy - **Reading time:** 24 min > AI is making time & materials unsustainable in IT consulting. What’s left to sell: outcomes, accountability, and trust. Not hours. There is a moment, in every industry, when a silent agreement between buyer and seller, an agreement so old it feels like natural law, suddenly cracks open. Not because someone was brave enough to challenge it. But because reality made it impossible to maintain. In IT consulting, that moment is now. The silent agreement was this: *you pay us for our time, and we 'll do our best with it.* It went by many names. Time & Materials, Staff Augmentation, Body Rental. The underlying pact was always the same. You rented human hours. You hoped those hours would produce something useful. Sometimes they did. Sometimes they didn't. Either way, you paid. For decades, this model worked well enough. Not because it was fair, or efficient, or good for anyone in particular. It worked because there was no alternative. Software was hard. Estimating it was harder. And nobody, not the client, not the vendor, not the developer staring at a blinking cursor at 2 AM, could reliably predict how long anything would take. So we all agreed to pretend that time was a reasonable proxy for value. We built entire industries, entire careers, entire pricing spreadsheets on this fiction. And then AI walked in and set the spreadsheet on fire. * * * ## I. The Comfortable Lie {: #i-the-comfortable-lie } Let me be precise about what Time & Materials actually is, because the industry has done an excellent job of dressing it up in language that obscures its fundamental nature. T&M is a risk-transfer mechanism. That's it. The vendor transfers the risk of estimation, of scope creep, of technical uncertainty, all of IT, to the client. The client pays for the attempt, regardless of the outcome. The vendor's only obligation is to show up and try. Now, if you described any other professional relationship this way, people would laugh you out of the room. Imagine hiring a plumber who bills by the hour with no guarantee your pipes will work. Imagine a lawyer who charges for research time but won't commit to a legal strategy. Imagine a surgeon who bills per minute in the operating room, regardless of whether your appendix comes out or stays in. And yet, in IT consulting, this was standard practice. Not just standard, but *expected.* Clients who pushed back were labeled "difficult." Vendors who offered fixed prices were considered either naive or reckless. The reason was always the same: *software is different.* Software is complex, unpredictable, creative work. You can't estimate it like bricklaying. Requirements change. Technology evolves. The only honest pricing model is one that acknowledges this uncertainty. This argument was not entirely wrong. Software *is* complex. Estimation *is* hard. But the conclusion, that the only honest response is to charge by the hour, was a spectacular non sequitur. The honest response would have been to get better at managing uncertainty, to build models that account for it, to develop shared-risk frameworks. Instead, the industry chose the path of least resistance: make it the client's problem. And clients went along with it, for the most intellectually depressing reason possible: they didn't know any better. Most organizations buying IT services had no internal technical capability to evaluate what they were getting. They couldn't distinguish between a developer who spent eight hours solving a problem elegantly and one who spent eight hours creating a new problem. The only metric they had was time. So time is what they bought. This created a market where the incentives were not just misaligned but *inverted.* The worse you were at your job, the more you could charge. The longer something took, the more revenue you generated. Efficiency was not rewarded; it was punished. A consultant who solved a problem in two hours instead of twenty was leaving eighteen hours of billable time on the table. Every honest person in the industry knew this. Most of us made peace with it. Some of us told ourselves stories about "investing in quality" and "thoroughness." We weren't lying, exactly. We were just not confronting the structural absurdity of a model that could not, by design, distinguish between thoroughness and waste. * * * ## II. Enter the Machine {: #ii-enter-the-machine } In 2023, something changed. Not gradually, not subtly. Like a light switch. Large language models (ChatGPT, Claude, Copilot, and a growing menagerie of AI coding assistants) started doing things that developers used to do. Not all things. Not perfectly. But a non-trivial portion of the daily work of software development suddenly became automatable. Boilerplate code. API integrations. Test generation. Data transformations. Documentation. Migration scaffolding. The repetitive, mechanical, *billable* parts of the job. The numbers varied depending on who you asked and what they were measuring, but the direction was unmistakable. Tasks that used to take hours now took minutes. Work that required a senior developer could be roughed out by a junior with AI assistance. Entire categories of effort, the kind that padded project timelines and kept T&M invoices healthy, started evaporating. Now, if you were a consultant billing by the hour, this created an existential problem. Not a strategic challenge, not a market shift. An *existential* problem. Because the value you were selling was, at its core, the *time* it took a skilled human to do something. And suddenly, that time was collapsing. Let me make this concrete. Say you're a consulting firm, and a client asks you to build an integration between their CRM and their ERP. In 2022, your senior developer would scope it at 80 hours. In 2024, with AI-assisted development, the same work takes 25 hours. The quality is the same. The outcome is the same. The client gets the same integration. What do you charge? If you bill 25 hours, you've just lost 69% of your revenue on that project. If you bill 80 hours anyway, padding time sheets, inventing complexity, stretching the work, you're committing fraud, or something close enough to fraud that the distinction is academic. This is not a hypothetical dilemma. This is happening right now, in every consulting firm that hasn't yet figured out how to escape the T&M trap. And the uncomfortable truth is that most of them haven't. They're doing what humans always do when the ground shifts under their feet: pretending it isn't shifting. Some firms are hiding AI usage from clients, billing full human hours for AI-assisted work. Some are explicitly banning AI tools internally, not for quality reasons, but because their entire business model depends on human inefficiency. Some are using AI internally while maintaining T&M pricing, pocketing the productivity gains without passing them to clients. None of these strategies are sustainable. All of them are, in various degrees, dishonest. And all of them will fail, because the arbitrage between what AI can do and what humans used to do is growing too fast to conceal. * * * ## III. What Actually Has Value Now? {: #iii-what-actually-has-value-now } Here is the question that keeps thoughtful consultants awake at night: if AI can generate the code, write the tests, draft the documentation, and scaffold the architecture, what exactly is left for us to sell? The answer is everything that matters. The great irony of the AI revolution in IT consulting is that it didn't destroy value. It *revealed* it. For decades, the real value of good consulting was buried under layers of mechanical work. The strategic thinking, the domain expertise, the architectural judgment, the ability to translate business needs into technical decisions: all of this was mixed in with the grunt work and charged at the same hourly rate. You couldn't separate the wisdom from the typing. Now you can. Or rather, you have to. What clients actually need from IT consultants has never been code. It has never been hours. It has always been (though the industry was remarkably good at obscuring this) *outcomes.* A working product. A solved problem. A risk mitigated. A capability unlocked. When a manufacturing company hires an IT firm to build a predictive maintenance system, they don't care how many hours it takes. They care whether it works. They care whether it reduces downtime. They care whether the investment pays for itself. The hours are an input, not an output. They were always an input. But T&M trained everyone, buyers and sellers alike, to confuse the two. The things that actually create value in IT consulting are precisely the things that AI can't easily replicate: **Understanding the problem.** Not the technical requirements, which are usually symptoms. The actual business problem. The organizational dynamics. The political constraints. The unspoken assumptions. This requires human judgment, empathy, and often the willingness to tell a client something they don't want to hear. **Making irreversible decisions well.** Architecture. Technology selection. Build-vs-buy. Data modeling. Security posture. These are decisions that compound over time, that are expensive to reverse, and that require the kind of experience that comes from having made the wrong choice before and lived with the consequences. **Taking responsibility.** This is the big one, and I'll come back to it. AI can generate options. It can analyze tradeoffs. But it cannot take responsibility for a decision. It cannot stake its reputation on a recommendation. It cannot be held accountable when something goes wrong at 3 AM on a Friday. This is not a limitation of the technology. It is a feature of being human. **Navigating complexity.** Not technical complexity, but organizational complexity. Compliance requirements, regulatory constraints, security obligations, accessibility mandates, data governance. The kind of complexity that requires understanding not just what to build, but what you're *allowed* to build, what you're *required* to build, and what you'll be *liable for* if you build it wrong. **Building trust.** In an era where AI can generate plausible-looking anything (code, documentation, security reports, compliance matrices) the question shifts from "can you produce this?" to "can I trust what you produced?" Trust is a human commodity. It requires track record, accountability, transparency, and skin in the game. * * * ## IV. The Value-Based Revolution (That Everyone Talks About and Nobody Does) {: #iv-the-value-based-revolution-that-everyone-talks-about-and- } Value-based pricing is not a new concept. Management consultants have been talking about it for thirty years. McKinsey doesn't charge by the hour. Neither does a good surgeon. Neither does an architect who designs a building that will stand for a century. But in IT consulting, value-based pricing has always been the thing you admired from a distance, like a beautiful car you couldn't afford. The industry had a hundred reasons why it wouldn't work: *" We can't estimate accurately enough."* *" Scope always changes."* *" Clients won't pay upfront."* *" It's too risky for us."* These objections were all valid, and they were all excuses. They were valid because T&M had created an ecosystem that made them true. When you've spent decades avoiding estimation risk, you never develop the muscles to manage it. When you've never committed to an outcome, you don't learn how to deliver one reliably. The model was self-reinforcing: T&M created the conditions that made T&M seem necessary. AI has broken this cycle. Not by solving estimation (estimation is still hard) but by making the alternative untenable. When the time component of your value proposition collapses, you don't have the luxury of comfortable excuses anymore. You have to figure out value-based delivery, or you die. Here's what value-based IT consulting actually looks like in practice: **You sell outcomes, not effort.** The deliverable is not "200 developer-hours." It's "a working predictive maintenance system that reduces unplanned downtime by 15%." The client doesn't care whether it takes you 200 hours or 20. They care whether it works. **You absorb risk, not transfer it.** This is the fundamental inversion. In T&M, the client bears all the risk. In value-based models, the vendor bears some or all of it. If the system doesn't work, the vendor doesn't get paid, or gets paid less. This requires confidence in your ability to deliver, which means you have to actually be good at what you do, not just good at billing for it. **You price based on the value created, not the cost incurred.** If a system saves a client $2 million per year, a fee of $300,000 is reasonable even if it only took you a month to build. This makes some people uncomfortable. It shouldn't. The alternative, charging $50,000 because it only took 500 hours, rewards inefficiency and penalizes expertise. **You invest in capabilities, not headcount.** Under T&M, revenue scales with the number of billable humans. Under value-based models, revenue scales with the ability to solve increasingly complex problems. This means investing in AI tools, methodologies, domain knowledge, and process, not just hiring more bodies. **You build long-term relationships, not projects.** When you sell outcomes, the relationship doesn't end at deployment. You're accountable for the ongoing performance of what you delivered. This creates recurring revenue, deeper client relationships, and a natural moat against competitors who are still selling hours. * * * ## V. The Responsibility Problem (Or: Why Most Consultancies Will Fail) {: #v-the-responsibility-problem-or-why-most-consultancies-will- } I've talked to dozens of IT consultants in the past year about the shift to value-based models. Almost all of them agree it's the right direction. Almost none of them are doing it. The reason is not strategic complexity or market conditions. The reason is fear. Specifically, the fear of responsibility. T&M is comfortable because it is fundamentally *irresponsible,* in the literal sense. The vendor is not responsible for outcomes. They are responsible for showing up and trying. If the project fails, if the software doesn't work, if the client's business suffers... well, the vendor did their best. They logged their hours. They followed the requirements (that the client wrote). The failure, structurally, belongs to the client. Value-based models obliterate this safety net. When you sell an outcome, you own that outcome. When it doesn't work, it's your problem. When the client isn't happy, you can't point to a timesheet and say "but we put in the hours." You are, in the most uncomfortable possible way, *accountable.* Most consultancies, if they're honest with themselves, are not equipped for this. Not because they lack technical talent (many of them have excellent people) but because their entire organizational structure, culture, and incentive system is built around T&M. Their project managers track hours, not outcomes. Their quality processes measure effort, not results. Their commercial teams sell rates, not capabilities. Transforming a T&M consultancy into a value-based one is not a pricing change. It's an identity change. It requires: * **Ruthless honesty about what you 're actually good at.** T&M lets you fake it: take on projects outside your competence and figure it out on the client's dime. Value-based models don't. If you commit to an outcome, you'd better be damn sure you can deliver it. * **Genuine investment in methodology.** You need estimation frameworks that work, delivery processes that are predictable, and quality assurance that catches problems before they reach the client. T&M firms often neglect these because they don't need them. If the project runs over, they just bill more hours. * **A different kind of leadership.** T&M leaders manage utilization rates and headcount. Value-based leaders manage client outcomes and delivery risk. These require fundamentally different skills, temperaments, and metrics. * **Skin in the game.** This is the hardest part. Value-based models require you to put your money where your mouth is. To accept that if you fail, you lose. To operate with the kind of commercial courage that T&M was specifically designed to avoid. Most firms will not make this transition. Not because they can't, but because they won't. The comfort of T&M is a powerful narcotic. Many consultancies would rather die slowly on hourly billing than take the risk of committing to results. And many of them will die. Slowly, then quickly. * * * ## VI. A Letter to the Buyer {: #vi-a-letter-to-the-buyer } So far, I've been hard on vendors. Fairly, I think. But the T&M problem is not just a supply-side problem. Buyers are complicit. And if AI is going to improve IT consulting, buyers need to change too. Dear CTO / CIO / VP of Technology / Procurement Director / Whoever Signs the Checks: You need to hear something uncomfortable. You helped create this mess. For years, you've been buying IT consulting like you buy office supplies, by unit cost. You compared vendor proposals by looking at daily rates. You chose the cheapest option. You measured success by hours consumed versus hours budgeted. You treated software development like an assembly line, where more hours in meant more product out. And when projects failed, as they so often did, you blamed the vendor for poor execution, never examining whether you had created the conditions for failure by buying the cheapest time at the lowest rate. You rewarded the wrong things. You incentivized volume over value, speed over quality, compliance over courage. And then you complained that vendors never challenged your thinking, never pushed back on bad requirements, never told you that your project was doomed from the start. They didn't tell you because you were paying them by the hour. A consultant who tells you "this project shouldn't exist" is a consultant who just talked themselves out of six months of billing. T&M punishes honesty. You built the system. You get the behavior the system incentivizes. Here's how to buy IT consulting in the post-AI era: **Stop buying hours. Start buying outcomes.** Define what success looks like, in business terms, not technical terms, and ask vendors to commit to it. Yes, it will cost more upfront. No, it won't cost more in total. You've been paying for failed projects for years; you just spread the cost across enough timesheets that it didn't look like failure. **Pay more for better vendors.** The cheapest vendor is never the cheapest. This has always been true, but AI makes it even more true. A vendor who uses AI effectively and commits to outcomes will charge a higher fixed price than a vendor who bills junior developers at $40/hour. The first vendor will cost you less. The math is not complicated. **Stop writing detailed technical requirements.** I know this sounds heretical. But detailed technical requirements are the client's way of pretending they can manage risk by specifying everything upfront. They can't. Requirements are always wrong, always incomplete, always outdated by the time the project starts. Instead, describe the problem. Describe the desired outcome. Describe the constraints. And then let the professionals figure out the solution. That's what you're paying them for. **Demand transparency, not timesheets.** You don't need to know how many hours someone worked. You need to know whether the project is on track, whether the risks are manageable, and whether the outcome is still achievable. Ask for those things. Build relationships with vendors who will tell you the truth, even when the truth is uncomfortable. **Accept that good work costs money.** The race to the bottom on consulting rates has produced exactly what you'd expect: an industry full of mediocre work by underpaid, unmotivated people managed by firms whose primary competence is bench management. If you want excellent work, pay for it. If you want accountability, pay for that too. Value-based pricing means you're paying for the vendor's confidence in their ability to deliver. That confidence is worth something. **Build internal capability.** This is the one that hurts the most, because it means spending money on your own team instead of outsourcing everything. But in the AI era, the organizations that thrive will be the ones that can evaluate what they're getting. You don't need to build everything in-house. But you need enough internal expertise to be an *intelligent buyer,* to evaluate proposals, challenge architectures, and recognize quality when you see it. * * * ## VII. The Trust Economy {: #vii-the-trust-economy } Let me zoom out for a moment and talk about what's really happening here. Not just in IT consulting, but in the economy at large. AI is creating a world where production is cheap and verification is expensive. Any consultant can now produce a working prototype in hours. Any developer can generate thousands of lines of code in minutes. Any firm can create polished documentation, architecture diagrams, and compliance reports at the push of a button. The question is no longer "can you produce this?" The question is "should I trust what you produced?" This is a profound shift. For most of industrial history, production was the bottleneck. If you could make something, you had value. The ability to produce was scarce, and scarcity creates value. AI is making production abundant. And when production is abundant, the bottleneck moves elsewhere. It moves to trust. Can I trust that this code is secure? Can I trust that this architecture will scale? Can I trust that this system complies with regulations? Can I trust that the vendor will support this when something goes wrong? Can I trust that the AI-generated test suite actually covers the edge cases that matter? Trust is not automatable. It is built through demonstrated competence, through transparency, through accountability, through the slow accumulation of evidence that someone knows what they're doing and will stand behind their work. It requires reputation, track record, and, critically, the willingness to be wrong and make it right. In the trust economy, the winning IT consultancy is not the one with the most developers. It's not the one with the lowest rates. It's not even the one with the best AI tools (though those help). It's the one that clients believe. The one that has earned the right to say "trust us, this is the right approach" and be believed. This is why the shift from T&M to value-based pricing is not just a commercial strategy. It is a trust signal. When a vendor says "we'll charge you $200,000 for this outcome, and if we don't deliver, we'll make it right," that vendor is putting their money where their competence is. They are saying, in the most credible way possible: we are confident enough in our abilities to accept the risk. T&M sends the opposite signal. It says: we're not confident enough to commit to an outcome, so we'll charge you for the attempt. In a world awash with AI-generated output, where anyone can produce *something,* the vendor who won't commit to the quality of their output is telling you everything you need to know about how much they trust their own work. * * * ## VIII. What This Means for Developers {: #viii-what-this-means-for-developers } I want to address the engineers directly, because they're the ones most anxious about all of this, and they're also the ones best positioned to thrive. If you're a developer who has built your identity around writing code, I understand the discomfort. Code was your craft. You were proud of elegant solutions, clean architectures, well-tested systems. And now an AI can produce something similar in seconds. But here's what you need to understand: your value was never the code. Your value was the judgment that produced the code. The decision about *what* to build. The understanding of *why* this approach and not that one. The knowledge of what will break at scale, what will be impossible to maintain, what will create security vulnerabilities, what will violate compliance requirements. AI is a lever. It amplifies capability. If you're a developer with deep understanding, AI makes you devastatingly effective. You can now execute at ten times the speed, which means your judgment, the thing that was always your real value, is applied ten times more often. You're not less valuable. You're more valuable, if you invest in the things that matter. What matters now: **Domain expertise.** Understanding the business problem, the regulatory environment, the operational constraints. A developer who understands healthcare compliance and can build systems that satisfy it is worth ten developers who can write code but can't navigate HIPAA. **Architectural thinking.** The ability to make system-level decisions that compound over time. AI can generate components. It cannot design systems. Not yet, and not well. The developer who can look at a business requirement and design an architecture that will serve it for five years, considering scalability, maintainability, security, compliance, and cost: that developer is irreplaceable. **Quality judgment.** AI generates plausible output. But plausible is not correct. The ability to evaluate AI-generated code, to spot the subtle bugs, the security holes, the performance antipatterns: this is a new and critical skill. It requires deep knowledge, not just of coding, but of systems, of failure modes, of edge cases. **Communication.** The ability to explain technical decisions to non-technical stakeholders. To translate between business language and engineering language. To write specifications that are precise enough for AI tools and clear enough for humans. This was always valuable. It's now essential. **Specification-driven development.** This is where the industry is heading. The developer's primary artifact is no longer code but the specification. The detailed, precise description of what needs to be built, how it should behave, what constraints it must satisfy. AI turns specifications into code. The developer's job is to write specifications that produce the right code. This is a fundamentally different skill from writing code directly, and it rewards the same things that good engineering has always rewarded: clarity of thought, precision of expression, and deep understanding of the problem. If you invest in these things, the AI era is not a threat. It's a liberation. You can stop spending 70% of your time on boilerplate and start spending it on the work that actually matters. * * * ## IX. The Compliance Accelerator {: #ix-the-compliance-accelerator } There's a dimension to this that most commentators miss, because most commentators don't think about regulatory compliance until it bites them. In Europe, and increasingly everywhere else, software is becoming a regulated product. The AI Act, the Cyber Resilience Act, the Product Liability Directive, the European Accessibility Act, NIS2, GDPR. The regulatory landscape is not just growing, it's *compounding.* Each new regulation adds requirements that interact with existing regulations in complex ways. This changes the IT consulting equation in two critical ways. First, it makes value-based pricing *easier to justify.* When the cost of non-compliance is measured in millions of euros in fines, the value of compliant software becomes quantifiable. A consultancy that can demonstrate compliance, with SBOMs, with security audits, with accessibility testing, with AI governance frameworks, can price based on the risk they're mitigating, not the hours they're spending. Second, it makes T&M *actively dangerous.* Under the Product Liability Directive, software is a product. If it harms someone, someone is liable. Under T&M, who is liable? The vendor provided hours. The client accepted the deliverable. The responsibility is diffused to the point of evaporation. Under value-based models, the vendor commits to an outcome that includes compliance. If it's not compliant, it's the vendor's problem to fix. This is not just better pricing. It's better accountability. Compliance is not a cost center. It's a trust signal. In a market flooded with AI-generated software of uncertain quality, the firm that can prove its output meets regulatory requirements has a massive competitive advantage. Not because compliance is exciting (it isn't) but because it's *verifiable.* In a trust economy, verifiable quality is the scarcest commodity there is. * * * ## X. The Uncomfortable Predictions {: #x-the-uncomfortable-predictions } Let me end with some predictions. They're uncomfortable. I believe they're correct. **Within five years, T &M will be a niche model.** It won't disappear entirely. There will always be genuine exploration and research work where time-based billing makes sense. But for mainstream software development and IT consulting, T&M will become what it always should have been: an exception, not the default. Clients will demand outcome-based contracts. Vendors who can't provide them will lose business to those who can. **The IT consulting industry will consolidate dramatically.** The AI productivity gains create enormous economies of scale. A small firm with excellent methodology, deep domain knowledge, and effective AI tools can deliver what used to require a large team. This favors small, specialized, high-competence firms over large, generalist body shops. The middle will hollow out. You'll have boutique experts and commodity platforms, with very little in between. **Developers who resist the shift will struggle.** Not because their skills are worthless (coding knowledge is foundational) but because the market will increasingly reward the *application* of that knowledge, judgment, architecture, specification, over the *mechanical expression* of it. Developers who cling to coding as an identity rather than a tool will find themselves competing with AI on AI's terms. They will lose. **Clients who continue buying hours will get worse outcomes.** As the best vendors shift to value-based models, the T&M market will be left with the vendors who can't or won't commit to outcomes. These are, almost by definition, the worst vendors. Buying hours will become a signal of unsophistication, a way of telling the market that you don't know how to evaluate quality, so you're settling for the only metric you understand. **Trust will become the primary differentiator.** Not technology, not price, not speed. Trust. The ability to say "we will deliver this, and we stand behind it" and have that statement be credible. Every other competitive advantage, AI tools, methodology, domain expertise, will be in service of this one thing. * * * ## Epilogue: A Confession {: #epilogue-a-confession } I work in a small IT company. We build software for healthcare organizations, public administration, finance, manufacturing. We have, for most of our existence, billed by the hour. T&M. Staff augmentation. The works. I'm not writing this from a position of superiority. I'm writing this from a position of reckoning. When AI started accelerating our development, we had the same uncomfortable conversations every honest consultancy is having. Our developers were suddenly three, four, five times more productive. Our project timelines were collapsing. And our billing model, the model that paid our salaries and our rent, was predicated on those timelines being long. We could have hidden the AI usage. We could have padded timesheets. We could have maintained the fiction. Some of our competitors are doing exactly that. We chose not to. Not because we're morally superior (we're not). But because we could see where it was heading. The arbitrage is too large and growing too fast. Clients will figure it out. Some already have. And when they do, the firms that were honest about the shift will be the ones they trust. The ones that hid it will be the ones they never work with again. So we're making the transition. Painfully, imperfectly, but deliberately. We're restructuring our proposals around outcomes. We're investing in compliance capabilities that justify value-based pricing. We're training our team to think in specifications rather than code. We're building the processes and methodologies that allow us to commit to outcomes with confidence. It's terrifying. It's also the most honest thing we've ever done. Because the truth is, T&M was never honest. It was never fair. It was just familiar. And in an industry that claims to be about innovation, clinging to a broken model because it's familiar is the most inexcusable thing of all. AI didn't kill Time & Materials. AI just made it impossible to pretend it was ever alive. --- # EU compliance 2026: it's architecture, not just legal - **URL:** https://margiovanni.it/en/blog/eu-compliance-2026-its-architecture-not-just-legal/ - **Published:** 2026-03-17 - **Tags:** Compliance, EU Regulation, AI Act, Architecture - **Reading time:** 11 min > Over the next 18 months CRA, AI Act, PLD, NIS2 and EAA will reshape European software. Compliance isn’t a checkbox: it’s designed into architecture. I often find myself in a scene I can recognize within the first minute. Someone mentions compliance—maybe in a project meeting or during a call with a slightly more structured client—and the response comes almost automatically. "legal will handle it". I’m not saying it to be cynical. It’s just that, in 2026, that sentence risks becoming one of the most expensive ones a European software company can say. Because what’s coming doesn’t look like a policy update or a round of notices. It looks much more like a change of foundations. And, even more inconveniently, it comes with very tight deadlines. ## The perfect storm: five deadlines in far too short a window {: #the-perfect-storm-five-deadlines-in-far-too-short-a-window } If you build software for the European market, the calendar is no longer a detail to keep in a shared file. It’s a timeline that seeps into your architecture. Between the end of 2024 and 2026, regulations pile up that, taken one by one, you might manage—barely. Together, though, they slot together on purpose. NIS2 has already been in force since October 2024 and it expanded the perimeter of who needs to take cybersecurity seriously, including the supply chain. And here the first surprise often hits: you don’t have to be “critical” to feel the effects. You just have to be a supplier to someone who is. The European Accessibility Act has already been in effect since June 2025 and, regardless of how it will be interpreted in different contexts, it moves accessibility from the world of “improvements” to the world of “requirements”. Then 2026 arrives, which is the year the knot tightens. In August 2026 the AI Act enters full application for high-risk systems. It’s not just a matter of ethics or transparency. We’re talking conformity assessments, technical documentation, data governance, human oversight. And yes, real penalties too, up to 3% of global turnover or 15 million. In September 2026 the Cyber Resilience Act brings obligations that, as they’re written, you can’t “add later”. Among these is reporting actively exploited vulnerabilities within 24 hours and serious incidents within 72 hours. And the part many underestimate is this: it doesn’t apply only to future products. It also applies to what you already have on the market. Legacy included. In December 2026 the Product Liability Directive redefines what a “product” is in the digital era. Software, even standalone or in SaaS form, becomes a product in every sense, with strict liability. Bugs stop being just an operational annoyance and become potentially a product defect, with direct legal consequences. And responsibility doesn’t end at release, it ends when you no longer have the ability to provide updates. And in the background there’s GDPR, which never went away, with enforcement that’s getting less and less shy. Maybe the most destabilizing thing is that these rules don’t add up linearly. They *reinforce* each other. ## The fundamental mistake: treating compliance like an external layer {: #the-fundamental-mistake-treating-compliance-like-an-external } The most common reaction is understandable: “let’s call the consultant, update the policies, fix the documentation, do the checklists”. It’s the approach we could call compliance-as-paperwork. With GDPR, as badly as it was often done, this strategy sometimes held. You could paste a set of processes, notices, registers, roles on top of an existing system. With the 2026 package it doesn’t hold anymore. And not because there’s a lack of goodwill. Because there are requirements that, if they aren’t supported by your architecture and by how you build and ship software, simply don’t exist. Let’s take the most concrete case possible: to comply with the CRA, when an actively exploited vulnerability emerges, you must be able to react and report within the required timeframes. But to do that you have to know precisely what’s inside your product. Not “more or less”. *Exactly*. Direct dependencies, transitive ones, components, versions, builds. Everything. That takes you straight to an object that is not legal and not bureaucratic: the SBOM, Software Bill of Materials. And not an SBOM in PDF generated once to make someone happy. A living SBOM, regenerated on every build, in a machine-readable format, integrated into the pipeline. If your build process doesn’t produce an SBOM as a natural output, it’s not that “you’re a bit behind on compliance”. It’s that you can’t be compliant, period. And here, in my opinion, the most important sentence in this whole discussion becomes clear: compliance isn’t a requirement you add. It’s an emergent property of your architecture. ## Compliance as an architectural constraint {: #compliance-as-an-architectural-constraint } In software architecture we’re used to constraints. Latency, availability, scalability, compatibility, costs. They’re things that narrow the space of possible solutions. Well, EU compliance 2026 is an architectural constraint. Not a ticket to assign “at the end of the project”, not a document to produce “before the tender”. A constraint that cuts across the system. And when you look at it that way, some consequences become almost obvious. ### Observability is no longer an extra The AI Act, for certain systems, requires logs and traceability. The CRA pushes you toward detection and response capabilities. The PLD puts you in a position where you must be able to prove the state of the software at the time of the incident. If you don’t have sufficient audit trails, it’s not that “you monitor too little”. You’re building a system that can’t withstand the questions the market and regulations will ask you. ### Dependency management becomes a critical process For years we normalized the idea that updating libraries is work you do “when there’s time”. A rushed `npm install`, a lockfile nobody looks at, an update postponed because “it works anyway”. With CRA and NIS2, that lightness becomes supply chain risk. And supply chain risk, in 2026, doesn’t stay confined to the technical department. It propagates into contracts, tenders, partnerships. The question you must be able to answer is very simple and very hard: “does this newly released CVE impact our products in production?”. And the answer has to come in minutes or hours, not weeks. ### The concept of “finished product” falls apart The PLD and the CRA, together, make the idea that a release closes a chapter less credible. Shipping becomes the start of a long-term relationship with a system that must be maintained, monitored, cared for. This also changes how we estimate, plan, sell. Because part of the value, and of the responsibility, lives after delivery. ### Accessibility is a property of the design system The EAA isn’t kind to retrofits. If you have an accessible-by-default design system, you have a structural advantage. If you have to “make accessible” a frontend that grew for years without rules, the amount of findings you get back can become unmanageable. And here I often wonder whether we’re underestimating how much accessibility is, in reality, a form of internal standardization. Not just an external requirement. ### Human oversight isn’t a button One of the most common misunderstandings about the AI Act is thinking that “human oversight” means adding an approval step at the end. In practice, it’s a flows topic: where a human can intervene, with what information, with what ability to override, and with what traceability. It’s decision-process architecture even before software architecture. ## The intersection many aren’t looking at {: #the-intersection-many-arent-looking-at } The most interesting point, and maybe the most dangerous, isn’t the individual obligations. It’s how they fit together. The PLD says a software product is defective if it doesn’t meet applicable cybersecurity requirements. The CRA defines an important part of those requirements. The AI Act adds specific requirements when there’s AI. So non-compliance with the CRA can become a *product defect* under the PLD. We’re no longer talking only about an administrative fine or a non-conformity “to fix”. We’re talking about civil liability for damages, with dynamics like reversal of the burden of proof. And to defend yourself, you must be able to prove the product was compliant at the time of the incident. Which, again, brings you back to SBOM, audit trail, logging, technical documentation. Not as compliance theater, but as defensive architecture. ## The Italian paradox: fragile, but fast {: #the-italian-paradox-fragile-but-fast } Here comes a piece that I feel very close to, because it’s the everyday reality of many companies I talk to. The Italian software fabric is largely made of SMEs: teams of 5 to 20 people, vertical products, growth by layering, roadmaps dictated by customers, technical debt accumulated with a feature-first logic. Many of these companies are unprepared. Not out of inability, but because of structure. And yet there’s a paradox: the same structure that makes them vulnerable can turn into an advantage. A 10-person company, if it truly decides to, can redesign important parts of its architecture in 12 months. A large organization often takes months just to understand what it has in production. A small team knows its domain and its product intimately. It can do a realistic gap analysis in weeks. And a founder-CTO who invests today in compliance-by-design can move within a window that, in 18 months, will already be closed. Not because it will be impossible, but because it will be too late to do it calmly. ## Compliance-by-design: architectural decisions, not slogans {: #compliance-by-design-architectural-decisions-not-slogans } When I say compliance-by-design I don’t mean “doing things properly” in a generic way. I mean concrete choices you can start making now, even without revolutionizing everything. The SBOM as a first-class artifact, for example. Every build produces an SBOM in CycloneDX or SPDX format. The pipeline generates it, stores it, compares it with vulnerability databases, and if needed blocks a deploy. Tools like Syft, Grype, or Trivy make this much more accessible than it sounds. Then there’s the audit trail, but not the one from system logs. A domain audit trail: who did what, when, why, with what role, in what context. It can be event sourcing or an append-only log, but the idea is that it’s a first-class citizen of the data model. Technical documentation as code is another key point. If documentation lives in a manually updated wiki, sooner or later it stops representing reality. If instead you use versioned ADRs, declarative specs, and documentation generated from code, then documentation becomes an inevitable byproduct of the work. And vulnerability management can’t be an annual event. It has to be a continuous process: automated scanning, triage, remediation with defined timelines. When the report of an actively exploited vulnerability comes in, the system must help you react within hours. On accessibility, the thing I’ve seen truly work is treating it as design tokens and as a rule of the design system. If components are born accessible, the product tends to stay that way. If you have to fix it later, every new screen adds debt. ## AI-native development as an accelerator, not just a risk {: #ai-native-development-as-an-accelerator-not-just-a-risk } There’s a small irony in the fact that the AI Act arrives while AI is changing the way we write software. Many see AI-native development as a risk for compliance: more generated code, less control. I suspect that, in many cases, the opposite is true. A spec-driven approach, where software is born from declarative, readable and verifiable specifications, is *inherently* more favorable to conformity. Because specs are documentation. Because they’re versioned. Because they make explicit assumptions that otherwise stay in the head of whoever wrote that piece of code two years ago. Tools like project files such as claude.md, Speckit, pipelines that generate compliance artifacts as part of the flow, aren’t science fiction. They’re a different way of working, one that can make it easier to produce evidence, traceability, reconstructability. Maybe the future isn’t “writing more documentation”. It’s building software so that documentation is inevitable. ## The real cost of non-compliance is much closer than a fine {: #the-real-cost-of-non-compliance-is-much-closer-than-a-fine } Penalties are impressive, but for many SMEs they remain abstract. It’s not fear of the fine that changes priorities. The real cost is more everyday. It’s the public tender you can’t participate in because you don’t meet the security requirements in the specs. It’s the enterprise customer who asks you for the SBOM and you don’t know where to start. It’s a partner who does supply chain risk management and excludes you from the shortlist. It’s an incident you can’t handle within the timeframes required by the CRA and that gets entangled in a tougher liability context. For many Italian companies, these aren’t theoretical scenarios. They’re things that look a lot like 2027. ## The window is now, and deep down it’s about good engineering {: #the-window-is-now-and-deep-down-its-about-good-engineering } As a software architect, with my head often split between roadmap, budget, technical debt, and market demands, I understand well how all this can feel overwhelming. But there’s one aspect worth keeping front and center: many of the practices required by these regulations are simply good engineering. Generating an SBOM is good engineering. Having an audit trail is good engineering. Managing dependency vulnerabilities is good engineering. Documenting architectural decisions is good engineering. Building accessible interfaces is good engineering. What EU compliance 2026 is doing, perhaps, is making mandatory what we should have been doing anyway. It’s turning best practices into a baseline. And it’s creating a market where those who treat compliance as an architectural problem, and not as a practice to delegate to legal, end up with software that’s more robust, more maintainable, and also more sellable. The window to build that advantage is open now. In eighteen months, those who haven’t started will be chasing. Those who start now will probably find themselves on the other side. --- # When Software Becomes an Intention - **URL:** https://margiovanni.it/en/blog/when-software-becomes-an-intention/ - **Published:** 2026-03-17 - **Tags:** AI, Product, Software, Startup - **Reading time:** 9 min > I built an app in 17 minutes without writing code. The point isn’t the demo, but what happens to consumer markets when software becomes intention. This morning, while I was making breakfast, I built a production-ready digital product. Not a prototype thrown together just because, not a mockup with the implicit “we’ll fix it later.” I mean something actually alive, with a domain, a working backend, a usable interface. Something a real user can open right now and use. It took me 17 minutes. I didn’t write a single line of code. I talked to an AI tool. The result is [music-map.uk](), an app that answers a question you may have never asked yourself: *what does this place in the world sound like?* And no, this post isn’t about music-map. Or rather, it isn’t about the product itself. It’s about what it means that something like this can exist like that, in that way, while the water for coffee is coming up. ## The distinction that changes everything {: #the-distinction-that-changes-everything } Here I need to clarify something, otherwise it sounds like I’m telling a story that’s already existed for years, just with a bit more excitement. There are consumer tools that promise exactly this: open a browser, describe the idea, and in a few clicks you have an app. Lovable, Bubble, Glide, Softr. The ecosystem is huge and keeps growing. The point is that, today, there’s still a pretty clear gap between “I built something that looks like an app” and “I built something that holds up in production.” I’m not saying this out of snobbery, and not as a judgment on those products either. In certain use cases they’re genuinely great. It’s really a matter of substance: robustness, scalability, control over the generated code, the ability to intervene when something breaks, real ownership of the infrastructure. That very concrete feeling of knowing where the pieces are and what happens if one of those pieces stops working. I used tools meant for people who, in some way, already know what they’re building. Tools that assume you have technical context, that you can read an error, that you can make architectural decisions when they put them in front of you. That difference is still enormous today. And that is exactly the point. ## b2b doesn’t scare me, at least for now {: #b2b-doesnt-scare-me-at-least-for-now } While I was finishing my coffee, the question that always hangs in the industry hit me, even when we pretend it doesn’t: *is this taking my job?* In b2b the answer, as I see it right now, is no. Or at least, not in the catastrophic sense that mainstream narratives love. Because good b2b work was never “writing code.” It’s understanding a client’s context, translating often messy needs into precise technical requirements, making sure a system holds up under pressure, navigating compliance and regulations, maintaining relationships of trust over time. In day-to-day work at Oltrematica, I often have on the table at the same time a migration from Python to Laravel 12, compliance frameworks for the Cyber Resilience Act, sbom platforms for clients who have to report their software to public bodies, and solutions tied to the Product Liability Directive that will come into force in 2026. That’s not stuff you solve with a 17-minute conversation. AI has changed *how* I do that work. The speed on certain tasks has increased in an almost embarrassing way. But the value I brought wasn’t in typing the code. It was in knowing *what* to write, *why* , and above all *what to avoid*. That part, for now, hasn’t disappeared. If anything, it may have gotten stronger, because it leaves me more room to think. ## Consumer is a different story {: #consumer-is-a-different-story } On consumer, instead, I feel less calm. Not because apps disappear tomorrow, but because it seems to me the shape of the market is changing. If you take the classic adoption curve—innovators, early adopters, early majority, late majority, laggards—and ask where we are with ai tools for developing software, something weird comes out. For developers, we’re already in the early majority. Many use them every day, integration into workflows is real, productivity is measurable. For a non-technical user, instead, we’re still between innovators and the very first early adopters. The technical threshold is still high. Not as high as ten years ago, but high enough to exclude most people. And that threshold drops every month. Not always linearly. Sometimes there’s a jump, maybe because someone finds an interface that really works, or because a model becomes capable enough to handle the ambiguity of natural language without forcing you to correct it every two minutes. When that threshold drops enough to be crossed by a normal person—someone who doesn’t know what a server is and doesn’t even want to know—the consumer software market will change irreversibly. ## The real “product” of consumer apps {: #the-real-product-of-consumer-apps } Let me try to say it simply. Over the last fifteen years, a consumer app worked like this: someone had an idea, and only those with technical skills, or money to buy them, managed to turn it into a product. Then that product was distributed and used by others. The value was in execution, sure. But underneath there was something else: distance. The distance between having an intention and being able to use it. That gap, between “I’d like to” and “I can,” has been the market. Consumer apps existed because there was a technological barrier between those who knew how to build and those who wanted to use. If that distance collapses—if anyone can describe what they want and receive in return working software calibrated to their needs—what remains of the traditional model? I’m not saying apps disappear tomorrow. I’m saying the mechanism that has supported a huge part of consumer could stop working sooner than we expect. ## Will custom software become normal? {: #will-custom-software-become-normal } For a few months now, an idea has been buzzing in my head that feels radical, but maybe it’s only radical because we’re used to the opposite. In the physical world, mass production makes sense because personalization costs. A custom chair costs much more than an Ikea chair. So you accept a compromise and buy something standard, “good enough.” Software has worked the same way. A note-taking app is designed for millions of people, so it will make choices that work for many and are perfect for very few. You buy it because building it custom, until yesterday, cost years or thousands of euros. But what if the cost of personalization collapses to almost zero? If I can describe how I truly want my notes app—with the categories I use, the flow I prefer, integrated with the tools I already have—does it still make sense to buy the one designed for millions of users? Maybe yes, for convenience. Maybe no, if the difference between “adapting” and “having it the way I want” becomes too obvious. I wonder if mass-market software will end up like commercial music in the streaming era. It remains, sure, but it stops being the center of everything, because alongside it grow more personal, more tailored experiences. ## Who might resist {: #who-might-resist } If this scenario comes true—and I’m putting an “if” not because I doubt the direction, but because the speed and shape of the change are truly uncertain—there are consumer models that seem more solid than others. Network platforms, for example. Twitter, Linkedin, WhatsApp. Their value isn’t in the app itself, but in the fact that everyone else is in there. You can’t have your own customized version of a network, because a network without the network is just an empty interface. Then there are services with proprietary data. Spotify doesn’t sell a music player. It sells access to catalogs, metadata, licenses, algorithms fueled by billions of listens. You don’t generate that stuff with a prompt. And there are products where trust and compliance are part of the package. Finance, healthcare, legal. Even if an AI generated the perfect software for you, the question remains: who takes responsibility? Who certifies? Who answers when something goes wrong? Finally, maybe, ultra-high-end products with exceptional UX. Some experiences are crafted in a way that isn’t just “it works,” it’s perceived quality. Notion, Linear, Figma. Replicating features is one thing. Replicating that coherence, that detail, that aesthetic and operational trust is another. What risks suffering the most, instead, are niche utilities. The apps that “do one thing,” the $9.99-a-month micro-saas that live because they solve a specific problem better than others. If I can build it in an hour, that price starts to shake. ## The barrier that remains, for now {: #the-barrier-that-remains-for-now } There’s a legitimate objection, and I feel it too. People don’t want to build their own things. They want to use them. It’s true. And it probably will be for quite a while. There’s convenience, there’s trust, there’s cognitive savings. Even just clearly formulating what you want is effort—let alone iterating, correcting, choosing. But that barrier isn’t stable. It drops with habit. It drops with better interfaces. It drops with digital education. And it drops above all when the advantage of having something custom becomes obvious enough to justify the effort, while the effort keeps shrinking. I think the inflection point won’t be “the tool has become accessible.” It will be “the first time someone I know shows me what they made in 20 minutes and I think: I could do that too.” That moment is coming. For some people it’s already here. ## What we might see in the next few years {: #what-we-might-see-in-the-next-few-years } I’m not an analyst and I don’t have a crystal ball, so take these as informed feelings, not predictions. I think we’ll see a first wave of consumer products that are no longer bought but built. At first in the most tech-friendly segments—developers, designers, university students—and then in concentric circles. I think we’ll see enormous pressure on micro-saas pricing. Not because they become useless, but because it becomes hard to justify a subscription when the same utility can be generated on demand. Those who survive will offer something that isn’t easily generated: data, network, trust, deep integration with existing ecosystems. And I think new intermediaries will emerge. Not “app builders,” but curators and distributors of software intentions. People who package prompts, configurations, already-tested flows, so others can create without starting from zero. A kind of template marketplace, but deeper, more operational. There will probably also be attempts at regulation, more or less clumsy, around certain specific scenarios. ## Breakfast as a metaphor {: #breakfast-as-a-metaphor } I’ll go back to the starting point, because that’s where the feeling stuck to me. It wasn’t the speed that really struck me. It was the cognitive cost. I was distracted, doing something else, with my head on two things in parallel. It wasn’t a work session. It wasn’t “today I’m building a product.” And yet the result is good enough to be online. For me, this is the signal. The fact that producing software is becoming something you do *in parallel with something else* , like sending an email or searching something on Google. An action that no longer requires a dedicated context, a specific skill, a special mental energy. When something becomes like that, it changes its place in the cognitive and cultural hierarchy. And with it, the market that grew around it changes. Software is becoming an intention. Not yet for everyone, not yet in a stable way, but that’s the direction, and the speed is increasing. And so the question I’m left with, this morning, is this. > If you’re building a consumer product, is the value in the technological distance between you and your user, or in something that exists even when that distance no longer exists? **If you don’t have a clear answer, maybe it’s time to find one.** --- # After the Death of the UI: Does the Idea of the App Die Too? - **URL:** https://margiovanni.it/en/blog/after-the-death-of-the-ui-does-the-idea-of-the-app-die-too/ - **Published:** 2026-03-17 - **Tags:** AI, Design, Product, SaaS - **Reading time:** 9 min > Reading Mircha made me wonder what happens if the UI really dies. Maybe it’s not just the screen that disappears, but the application itself. A few days ago I read a post by Mircha Emanuel D’Angelo about the [death of the user interface](). The kind that sticks with you. I read it, I reread it, and then I started noticing it in real life too: how much mental energy we spend just to remember *where* you do something—on which tab, in which menu, in which product. And while I was trying to fall asleep, the question became more annoying and more interesting: if the UI really stops being the center of software, what happens to the rest? Because maybe it’s not just the screen that dies. Maybe the application as we’ve known it dies. ## If the UI dies, it doesn’t fall alone {: #if-the-ui-dies-it-doesnt-fall-alone } When we say “app”, we usually mean a fairly clear object. It has a name, an icon, a place in the dock, a monthly subscription, a personality. And above all it has a boundary. Inside is Notion’s world. Inside is Jira. Inside is Salesforce. Outside is everything else. I realized that boundary, often, isn’t there because the problem requires it. It’s there because the business model requires it. A lot of modern software is built like a fence. Not out of malice, maybe. It’s just that for years the simplest way to monetize has been this: take a set of features, package them up, build an interface around them that becomes familiar, put the user’s data inside, and then make leaving painful. Mircha draws a parallel that I find illuminating: MCP servers as “new Unix programs”. And if that’s true, then the natural consequence is another one, a bit more uncomfortable. SaaS applications, seen from there, resemble mainframes. Big monoliths born in an era when distributing software was expensive and the only way to get paid for it was to build walls. In a world where an agent can compose small, precise capabilities on the fly, that wall becomes more of a burden than a protection. ## The generative interface: not designed, summoned {: #the-generative-interface-not-designed-summoned } There’s a passage in Mircha’s post that made me stop and think. The idea that the GUI shifts from control panel to display. And it made me ask: what if it were neither? Maybe the interface, in the next round, becomes *ephemeral*. Today a designer, when designing a screen, is making a compromise. They look for a layout that works “well enough” for many people, in many contexts. The result is often an interface that’s solid, consistent, tested, but inevitably generic. It has to serve everyone, so it serves no one perfectly. With an agent in the middle, that compromise could break. I don’t mean “do everything via chat”, which is a convenient caricature. I mean a system that, given your intent, generates the right interface for that moment. A form that isn’t generic, but with *those* fields, in *that* order, with sensible defaults for your case. A dashboard that isn’t standard, but the visualization that answers a specific question, with the necessary data and no noise. These UIs aren’t maintained. They aren’t versioned. They don’t need a roadmap. They’re summoned and then they disappear. And the unsettling thing is that it’s not even sci-fi anymore. Today we already see models that generate components, pages, small artifacts in React in real time. It’s still rough, yes. But the direction is hard to ignore. At that point the designer’s role doesn’t disappear, but it changes skin. From screen designer to designer of generative systems. Design system, constraints, patterns, rules. Work more like building a grammar than drawing sentences. ## The agent as an operating system {: #the-agent-as-an-operating-system } Another consequence that keeps coming back to me is this: maybe the right metaphor for the agent isn’t “assistant”. It’s “operating system”. An OS does things we take for granted: it abstracts hardware, manages resources, offers a unified interface, lets different programs coexist and talk to each other. The agent does something similar, one level up. It abstracts services, manages contexts, offers a unified interface (natural language), orchestrates different capabilities. If this metaphor holds, then something almost inevitable happens: the agent becomes the platform. Not because everything “lives inside” the agent, but because everything passes *through* the agent. Just as today no software runs without an OS, tomorrow no service will be used without an agent. And here comes the political, or economic, part, which is probably the most delicate. Whoever controls the agent controls the access point to software. It’s a position we’ve already seen in history, just with different names. And I wonder whether we’ll manage to avoid the usual trajectory. The one Cory Doctorow calls enshittification. First everything is useful and open, then it becomes rent, then it becomes a toll. ## From app to capability {: #from-app-to-capability } If the application loses meaning, what’s left? What’s left is the capability. A capability is an atomic function exposed via protocol, described in human terms, invocable by an agent. “Create an invoice.” “Search for this contact.” “Summarize these tickets and tell me the risks.” It’s not a product with a brand and a layout. It’s a building block. And as soon as you think in terms of building blocks, the economics change too. Today you pay a subscription for a bundle: a hundred functions, you use twenty, but the price is for all of them. Tomorrow you might pay per use, capability by capability, at the moment you need it. Fractions of a cent for a single action done well. This throws three historical advantages of SaaS into crisis: First, the interface as lock-in. If the interface belongs to the agent, it’s no longer yours. Second, data as a prison. If data lives in personal vaults and access is via granular permissions, the fence loses power. Third, the bundle. If the agent can compose the best for each piece, the monolithic package becomes less attractive. At that point only one thing remains: the quality of the capability. Do one thing, do it better than everyone else. It’s Unix as a technical philosophy, but also as a business model. Elegant, and a bit ruthless. ## The new literacy {: #the-new-literacy } There’s another idea in Mircha’s post that I think is underestimated: “not knowing how to talk to AI” as a new form of illiteracy. For decades we’ve called “digital literacy” something very specific: knowing how to use interfaces. Clicking, dragging, navigating menus, filling out forms. We built courses, certifications, professional roles. If the agent becomes the main interface, all of that deflates. The central skill becomes something else, and maybe it’s more human than technical. Knowing how to express an intention clearly. Knowing how to provide context. Knowing how to break down a problem. Knowing how to judge a result and iterate. And here there’s a paradox that fascinates me. There are people who never really learned Excel, but can explain what they want with surgical precision. And there are power users who, put in front of an agent, don’t know what to ask. The skills map gets redrawn. And yes, the risk of a new digital divide is real. But there’s also a rare opportunity: for the first time, the advantage isn’t “knowing how to speak the machine’s language”. It’s knowing how to think and communicate well. ## The European surprise: compliance as a capability {: #the-european-surprise-compliance-as-a-capability } There’s a piece of this story that, in my opinion, we can’t ignore in Europe. While the American narrative tends to see regulation as a brake, here we’re building a regulatory framework that touches exactly the exposed nerves of a world of composable capabilities: AI Act, Cyber Resilience Act, Product Liability Directive, EAA. In a system where an agent combines three capabilities from three different providers, the question “who’s responsible if something goes wrong?” becomes explosive. **If the law asks you for traceability, security, audit trail, explainability, then compliance stops being just a cost. It becomes a differentiating capability.** SBOM as the component’s passport. The agent’s action log as a requirement. Transparency as a competitive advantage. And here there’s an almost ironic reversal: many historical demands of hacker culture—openness, accountability, verifiability—are becoming law. Maybe Europe, more than slowing things down, is building the trust infrastructure without which the agents world doesn’t hold up in serious companies. ## 2030, an ordinary day (maybe) {: #2030-an-ordinary-day-maybe } I try to imagine a normal day, without wanting to do sci-fi. You no longer have “apps” on your phone. You have an agent. You talk to it, write, maybe make a gesture. It orchestrates different services and you almost never see what’s behind the scenes. A bit like today you don’t think about microservices when a page loads. The interface you see was generated for you, in that moment. In five minutes it no longer exists. Commerce becomes conversation. “I need trail shoes, budget 150 euros, mixed terrain, I prefer a Vibram sole.” The agent knows your size, history, preferences, trusted sources. It proposes three options with a custom-made comparison. You choose, done. At the office something similar happens. The PM doesn’t open Jira, they ask “where are we on Alpha?” and get status, risks, next steps. The sales rep doesn’t navigate the CRM, they ask “which deals are at risk this week?” and receive a briefing. The developer describes a behavior and the system generates, tests, deploys. Data lives in a personal vault, encrypted and portable. Capabilities ask for granular, revocable permissions, and everything is logged. Every action produces an audit trail. In that world, value sits in two things: good capabilities and trust. ## A necessary realism {: #a-necessary-realism } Is it inevitable? I don’t know. Transitions are never linear. There will be enormous economic resistance. Enterprise moves with an almost geological slowness. Habits change more slowly than press releases. And there are real technical problems: reliability on complex tasks, error handling in composition chains, security, costs. But the direction Mircha brings into focus seems hard to ignore to me, because it’s supported by two concrete forces. On one side the cognitive cost of traditional interfaces, which grows with every new SaaS. On the other the ability of agents to reduce that cost, which grows with every iteration of the models. When the distance between the two crosses a threshold, the transition becomes practical, not ideological. And for some use cases, maybe that threshold has already been crossed. Mircha closes by asking who will build this future and with what values. I’m left with another question, a bit more personal and a bit more cynical: who will have the courage to build *for* this future, knowing it means dismantling the model that pays salaries today? Because the dilemma, in the end, isn’t technical. It’s the willingness to cannibalize the present. And the time to decide which side to be on, probably, isn’t infinite. *This post is born from reading["La morte dell’interfaccia utente come la conosciamo"]() by Mircha Emanuel D’Angelo. If you haven’t read it, I think it’s worth starting there.* --- # Compliance Is Your Problem - **URL:** https://margiovanni.it/en/blog/compliance-is-your-problem/ - **Published:** 2026-03-17 - **Tags:** Compliance, EU Regulation, Cybersecurity, Software Development - **Reading time:** 7 min > Between 2026 and 2027, software becomes a product with legal liability. If the client only wants go-live, the risk stays with everyone. There’s a line I find myself hearing more and more often, said almost as an aside while wrapping up a call and getting back to the “real” stuff: *we only care about the go-live. Compliance is your problem*. It’s not always arrogance. Actually, it’s usually the opposite. It’s a line said with the natural ease of someone who thinks compliance is a technical detail, like choosing a framework or deciding whether the button goes on the right or the left. Except that “detail” is changing shape. And it’s becoming—much faster than the market seems ready to admit—a matter of responsibility. ## What the client buys and what the vendor sells {: #what-the-client-buys-and-what-the-vendor-sells } For years, in custom software, we understood each other through a fairly simple implicit pact. The client describes what they want, the vendor builds it, timelines and costs are agreed, and at delivery you test, go to production, close it out. In this model, the “heavy” responsibility almost always ended up inside the project perimeter. If something went wrong, you talked about bugs, outages, maybe a penalty. Annoying, sure, but manageable. The point is that in Europe, between 2025 and 2027, a shift in perspective is coming that makes that pact less stable. It’s not a single regulation you can ignore until the legal email arrives. It’s a set of rules that, taken together, push in a very specific direction: software is increasingly treated like a *product*. And when something is a product, whoever “produces” it no longer answers only in contractual terms. They also answer for defects, a bit like what happens with an appliance that causes damage because it was designed or assembled badly. ## The commercial misalignment that creates friction {: #the-commercial-misalignment-that-creates-friction } This is where the real friction starts—the kind that then blows up in negotiations and quotes. The client thinks in a linear way and, from their point of view, also correctly. They want a working platform, a portal, an app. They want it by a certain date, with a certain budget, with the features the business needs. The vendor, however, finds themselves carrying a growing load of requirements that almost never show up in the brief. You don’t find them in user stories, you don’t see them in mockups, the product owner doesn’t ask you for them. And yet they’re things that, if missing, turn a “delivered” project into a “risky” project. I’m talking about technical documentation done a certain way, component traceability, vulnerability management, transparency around certain algorithmic choices, accessibility. All activities that share one common trait: they cost time, skills, process. And here comes the dilemma that, in my view, is becoming more and more toxic. If you include them in the quote, you risk being more expensive than the competitor who doesn’t. If you don’t include them, you absorb them into margin, work at a loss and, on top of that, take on a risk you never made explicit. Neither path is sustainable for long. ## Why “it’s always been this way” doesn’t hold up anymore {: #why-its-always-been-this-way-doesnt-hold-up-anymore } In Italian b2b we’ve spent years inside a “let’s do it, then we’ll see” culture. Light contracts, vague specs, lots of personal trust. Sometimes it worked pretty well too, I won’t deny it. Maybe because the context allowed it. Now, though, three things are changing at once, and it’s the combination that’s scary. The first is more “objective” liability. In some scenarios it’s no longer enough to say “we weren’t negligent.” The defect matters and the damage matters. And in certain cases the burden of proving there was no defect shifts to whoever produced or placed it on the market. The second is the widening of the perimeter. Software isn’t only what you write. It’s also what you integrate: open source libraries, cloud services, third-party api, ai models. And when these things enter the final product, someone has to answer for how they were chosen, integrated, monitored. The third is time. We’re not talking about a distant future. We’re talking about deadlines between 2026 and 2027. The code you’re writing right now will, in all likelihood, still be there when these rules are fully in force. So I wonder whether it’s naive to keep treating compliance as a footnote. ## The conversation nobody wants to have {: #the-conversation-nobody-wants-to-have } The hardest part isn’t understanding the rule. It’s talking about it without blowing up the commercial table. Try telling a client the quote goes up by 20% because you need to produce compliant technical documentation, implement a vulnerability management process, and keep an up-to-date inventory of components. In the best case, they answer with a long silence. In the worst case, they tell you someone else will do it without. And this is where the market splits. Because that “without” rarely means “more efficient.” Often it means “compliance debt,” i.e., work and risk pushed into the future. A future in which, with the new rules, the bill could land on the vendor, the client, or both. And yet almost nobody is having this conversation, at least not explicitly. It’s uncomfortable. It forces the client to accept that compliance has a real cost. And it forces the vendor to explain that cost without hiding behind words that sound like bureaucracy. ## The cost of invisibility {: #the-cost-of-invisibility } There’s a paradox that makes everything more complicated. Compliance activities, when done well, are invisible. A serious vulnerability management system is noticeable when nothing happens. Technical documentation becomes valuable when something goes wrong. A component inventory (like an up-to-date list of dependencies) is truly worth it on the day a critical vulnerability drops and you need to immediately understand whether you’re exposed. The client sees the feature, sees the go-live, sees the interface. Everything that keeps that result standing over time stays under the floor. So maybe the problem isn’t that the client “doesn’t want to pay.” It’s that they don’t perceive what they’re buying. If you go to an entrepreneur and say “we need to implement a compliant software bill of materials,” you’ll probably lose their attention after a few words. If instead you say “we need to be able, within 24 hours, to know whether a newly disclosed vulnerability puts your product—and therefore your liability—at risk,” you’re speaking the language of risk. Which is a much more universal language. ## What changes, in practice, without turning everything into a nightmare {: #what-changes-in-practice-without-turning-everything-into-a-n } For vendors, the path is narrow but fairly clear. You need to stop treating compliance as a hidden cost and start treating it as an explicit service, with a value you can explain. That means, for example, separating functional development from security and compliance maintenance. Not inside some indistinct “annual retainer,” but with a line item that says what it actually covers. Also because, if one day something ends up in dispute, ambiguity helps no one. It means putting it in black and white, in contracts, who does what. Who updates dependencies? Who monitors vulnerabilities? Who produces and retains technical documentation? Who decides whether a library can be used or not? Who answers if a component turns out to be compromised? Today, in many Italian contracts, these questions simply don’t exist. And when a question doesn’t exist, the answer always arrives at the worst possible moment. It also means learning to sell these activities for what they are: risk reduction. Because the client doesn’t buy “compliance.” They buy the ability not to end up with an outlaw product, with a security incident handled badly, or with a dispute where they have no evidence and documents to defend themselves. For clients, the mindset shift is the mirror image. *Compliance is your problem* is no longer a comfortable position, and maybe it never really was a safe one. If you place a digital product on the market, even if you had it developed by third parties, responsibility doesn’t evaporate. At most you can seek contractual recourse against the vendor. But in the meantime the damage, reputation, incident handling, and commercial consequences are yours to deal with. ## A question of market maturity {: #a-question-of-market-maturity } If you think about it, what’s happening looks like forced growth. The software market—especially custom work—is moving from an artisanal model, based on trust and implicit agreements, to a more industrial model, where responsibilities are defined, processes are documented, and quality isn’t just “it works on my phone.” That’s not necessarily bad news. For serious vendors it can become a way to stand out from those who compete only by cutting corners. For more aware clients it can be a guarantee: knowing the software isn’t built just to go online, but to stay standing, withstand incidents, and not turn into a legal problem at the first jolt. Maybe the right line today isn’t “compliance is your problem.” It’s something more honest and more useful: *compliance is part of the product*. And then yes, it’s a structural cost of making software. The sooner you acknowledge it, the sooner you can manage it. And maybe, with a bit of courage, turn it into a competitive advantage too. --- # Hands and the Machine: Trust in Software - **URL:** https://margiovanni.it/en/blog/hands-and-the-machine-trust-in-software/ - **Published:** 2026-03-17 - **Tags:** Trust, EU Regulation, Open Source, Software - **Reading time:** 11 min > Software runs the world yet stays invisible. Between ai, open source and European rules, trust is built with care, choices, and responsibility. ## Hands and the Machine {: #hands-and-the-machine } My grandfather was (ALSO) a carpenter. When you asked him how he could tell whether a piece of wood was good, he didn’t pull out theories. He’d stop, turn it over in his hands, smell it, and then say: “you can feel it.” Every time I think back to that scene it makes me smile, and then I get this kind of strange nostalgia. Because I’ve been doing software for twenty years, and when a client asks me how I know whether a system is good, I wish I could answer the same way. I wish I could say “you can feel it” and leave it at that. Except the truth is more complicated, and maybe that’s exactly the point. You can’t touch software. You can’t smell it. You can’t hold it up to the light to look for the grain. And yet it’s everywhere. It’s the most powerful and most invisible thing we’ve built. And when something is that invisible, trust becomes everything. ## The world runs on things you can’t see {: #the-world-runs-on-things-you-cant-see } This morning you had breakfast. The milk you bought got to the supermarket by moving through a logistics chain run by software. The payment at the checkout went through more systems than we imagine, often without anyone even noticing. The traffic light you passed on your way out executes an algorithm. The elevator has firmware. Your salary is a number in a database. I’m not saying it for dramatic effect. That’s just what the world is like now. And here comes the paradox that unsettles me a bit. Almost no one, among the people who make decisions about how society works, has a deep understanding of how these systems work. Not out of stupidity or laziness. More because of a structural flaw in our culture: for years we treated technology as something *for technicians* , a department, a corner of the map. In the meantime it’s become the connective tissue of everything. When a board of directors approves an ai-based system to filter job applications, is it making a technological decision? Yes. But it’s also making an ethical, legal, social decision. It’s deciding which biases are acceptable, what margin of error is tolerable, how much opacity is admissible in a process that changes people’s lives. And often it doesn’t know it. ## What happens when no one understands the machine {: #what-happens-when-no-one-understands-the-machine } There’s a story that we know well in our industry, but that we rarely tell outside our rooms. Inside almost every system you use, from your bank’s website to the app you order dinner with, there are small pieces of code written by people you’ll never meet. They’re open source libraries: free, shared components, often maintained by single individuals in their spare time. Some time ago someone tried to slip a backdoor into one of these libraries, a component used by millions of servers around the world. The attempt was discovered almost by chance: an engineer noticed the system took half a second longer to start up. Half a second. From that half second they traced it back to a sophisticated operation, probably state-sponsored, that could have compromised critical infrastructure on a global scale. The thing that should keep you up at night isn’t that someone tried. It’s that the entire security chain depended on one person, a volunteer, who maintained that code in their spare time while fighting burnout. It’s not an isolated anecdote. It’s a model. And I often wonder how long it can hold. ## ai isn’t intelligent (and that’s fine) {: #ai-isnt-intelligent-and-thats-fine } Here we need to be clear, because marketing has done an incredible job muddying the waters. The systems we call “artificial intelligence” don’t think. They don’t understand. They don’t have intentions, desires, goals of their own. They’re statistical machines of unprecedented power, capable of finding patterns in amounts of data no human being could process, and of generating results that *appear* intelligent. This distinction isn’t academic. It’s practical. It’s one of those things that changes how you make decisions. If you think ai understands, you’ll end up treating it like an expert. You’ll trust its judgment. You’ll delegate choices to it. And when it gets things wrong, because it does get things wrong and it also does so in subtle ways, you won’t have the tools to notice. If instead you see it for what it is, a hugely powerful tool, then everything snaps back into a healthier perspective. A tool has to be guided, checked, secured. A scalpel is extraordinary in a surgeon’s hands, and it’s a danger in anyone else’s. The difference isn’t in the scalpel. For those of us who write software, that awareness changes the job. Maybe we don’t write every single line anymore, or at least not in the same way. But we have to understand every single line, because we’re the ones accountable for what the system does. The machine generates. The human guarantees. And that guarantee carries a weight that no statistical model can take on. ## Europe does something brave (and almost no one notices) {: #europe-does-something-brave-and-almost-no-one-notices } While American and Chinese big tech race ahead, Europe does something different. It writes rules. I know, the instinctive reaction is a yawn. Rules, bureaucracy, slowness, yet another brake on innovation. But stop for a moment. Maybe, and I do mean maybe, it’s one of the few truly political moves we’re seeing. Europe is saying that technology is not above the law. That if you produce software that makes decisions about people, you must be able to explain how it works. That if your digital product has a vulnerability, you’re responsible for it, the way a car manufacturer is responsible for a defect in the brakes. AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Dry names, yes. But behind them there’s a very concrete insight: in the twenty-first century, regulating technology means regulating society. For those who run businesses, this means costs and complexity—it would be naive to deny it. But it also means something else that seems underestimated to me: a potentially enormous competitive advantage. When the global market wakes up asking for digital products that are secure, transparent, accessible, those who have already built these qualities into the way they work will be ahead. Compliance can be a burden, sure. But it can also be an investment, if you integrate it into the process and don’t treat it like a sheet to sign at the end. An sbom compiled out of obligation is a file in a folder. An sbom compiled with awareness is a map of your product, a governance tool, almost a declaration of maturity. ## Open source: the greatest and most fragile gift of the digital era {: #open-source-the-greatest-and-most-fragile-gift-of-the-digita } There’s something deeply beautiful about open source. Someone writes a piece of code, publishes it, and tells the world: take it, use it, improve it. It’s generosity, but not in the romantic sense. It’s the construction of a common good. And the global digital economy rests on that common good. That’s not an exaggeration. If that software had to be rewritten from scratch, the estimated value would be on the order of trillions. But the people who maintain it receive a tiny fraction of that value. The problem is systemic. Big platforms build billion-dollar services on libraries maintained by exhausted volunteers. Governments use open source in critical infrastructure without truly contributing to maintenance. Companies integrate open components into their proprietary products without knowing what’s inside, until a vulnerability forces them to find out in the worst possible way. Cory Doctorow talks about *enshittification* , that cycle in which platforms extract value until they degrade the ecosystem. But open source isn’t a platform. It’s more like a garden. And a garden, if everyone harvests and no one waters, dies. The good news is that something is moving. Europe, with the CRA, is starting to distinguish between those who maintain code out of passion and those who commercialize it. Some companies are creating dedicated funds. But the most effective response remains the simplest—and also the most uncomfortable. If you use open source in your product, contribute. With code, with funds, with recognition. Not because you have to. Because it’s smart, and because it’s right. ## Accessibility: the ultimate test of our intentions {: #accessibility-the-ultimate-test-of-our-intentions } There’s an almost foolproof way to tell whether a company takes its values seriously. Don’t look at the “about us” page. Look at whether its site works with a screen reader. Accessibility is where rhetoric meets reality. You can talk about inclusion and diversity all you want, but if your digital product can’t be used by someone with a visual, motor, or cognitive disability, those words become empty. And then, let’s be honest, we’re not talking about a niche. In Europe, tens of millions of people live with some form of disability. Add to that older adults, people with temporary disabilities, anyone who finds themselves in an unfavorable context: sunlight hitting the screen, a slow connection, an old device. Accessibility isn’t a favor. It’s a measure of the quality of our work. Accessible software is almost always better software: cleaner in the code, clearer in the interface, more robust. The European Accessibility Act will make many things mandatory starting in 2025. But whoever waits for the law to do the right thing, in my opinion, has already missed the point. ## ai developers: you’re not in danger, you’re in transformation {: #ai-developers-youre-not-in-danger-youre-in-transformation } Here I’m talking to people who do my same job. Those who live between commit and deploy, between bug and refactor. I know there’s fear. I see it in conversations, in messages, sometimes in jokes. The question is always the same, even when it isn’t said: “in five years, will there still be a need for me?” I breathe. We went from spreadsheets to relational databases. From static sites to frameworks. From manual deploy to ci/cd. And now from hand-written code to ai-assisted code. Every time the ground shook. Every time, those who managed to adapt discovered the new ground was more fertile than the old. The value was never in typing. It was in understanding. In the ability to look at a problem and see the structure beneath the surface. To talk with a user and translate frustrations into a system that works. To choose when to build and when to reuse. To know that a test isn’t bureaucracy, it’s love for the future. These skills aren’t automatable. They’re *amplifiable*. A machine that writes code is a multiplier of your abilities, but only if you have abilities worth multiplying. An ai IDE in the hands of someone who understands what they’re doing is an extraordinary tool. In the hands of someone who doesn’t understand, it’s a high-speed technical debt generator. Study, yes, but not only the new tools, because they’ll change. Study the fundamentals: architecture, system design, security principles, accessibility. Study people: how they communicate, what they fear, what they hope for. And also study the regulatory context, not because it’s fun, but because it defines the playing field. And above all, don’t stop being curious. Curiosity is a strange thing, not always “productive” in the corporate sense of the term. But it’s one of the few competitive advantages a machine can’t truly replicate. ## A matter of trust {: #a-matter-of-trust } In the end, this whole conversation—about ai, about open source, about regulation, about accessibility—revolves around a single word: trust. Do we trust the systems we can’t see? Should we? And under what conditions? Trust isn’t built with statements of intent. It’s built with concrete choices, repeated over time, verifiable. It’s built by documenting dependencies, testing code, making the product accessible, explaining the algorithm’s decisions, being accountable for mistakes. For decision-makers, technology isn’t a department. It’s the language the organization is written in. You don’t have to become programmers, heaven forbid. But you do need to understand enough to ask uncomfortable questions of vendors, tell a real risk from empty reassurance, understand what’s inside the software that runs the processes. For us developers, the job was never only technical. Every architectural choice is a choice of values. Every piece of data we decide not to collect is a right we choose to respect. Every interface we make accessible is a door we open. Code is power, and power comes with responsibility. ## So: wood and code {: #so-wood-and-code } My grandfather wouldn’t have understood my job. He probably would have shaken his head at certain words, and then changed the subject. But I think he would have understood the principle. He knew a well-made piece of furniture is recognized by the joints you can’t see. By stability that lasts over time. By the care put into details the customer will never notice, but that make the difference between an object that lasts twenty years and one that creaks after six months. Good software is the same. You recognize it by what you don’t see: by security that isn’t breached, by accessibility that excludes no one, by privacy that isn’t betrayed, by documentation that allows whoever comes after to understand what you did and why. It’s not a job that ai will take away from us. It’s a job that ai, in a sense, is giving back to us in its purest form: not as a mechanical act of translation, but as a human act of care. And care, as my grandfather knew while looking at wood, you can feel it. *This article is for those who write code and for those who depend on it without knowing it. For those who decide without understanding and for those who understand without being able to decide. Maybe for all of us, because in the end the answer is always the same: it depends on us.* --- # The Smallness Paradox: Long Live European Regulation - **URL:** https://margiovanni.it/en/blog/the-smallness-paradox-long-live-european-regulation/ - **Published:** 2026-03-17 - **Tags:** Compliance, Cybersecurity, AI, SME - **Reading time:** 11 min > Between the AI Act, CRA and NIS2, Europe is rewriting the rules: it’s not who runs fastest that wins, but who builds serious, secure, accessible software. ## The smallness paradox, seen from Pescara {: #the-smallness-paradox-seen-from-pescara } I work at a small-to-medium tech company in Pescara. We’re about a dozen people, not fifty, not two hundred. We build software for different clients, from public administration to SAAS platforms, and the thing that has kept us afloat, forever, is a kind of obsession with solidity. Thought-through architectures, code that holds up, systems that don’t crumble when someone feeds them real data, real money, real decisions. And yet, in recent months, I’ve found myself thinking something a bit bitter: **this is a brutal time to have ideas**. Not because creativity is lacking—quite the opposite. The problem is that creativity often comes with a feeling of powerlessness. ## The “someone already did it” syndrome {: #the-someone-already-did-it-syndrome } It happens like this, with an almost comical regularity. Monday morning, brainstorming. Someone throws out an idea. We get fired up, we start imagining how to do it properly, what the right architecture would be, where the risks are, how we’d sell it without lying to ourselves. Then Wednesday evening arrives. A scroll on LinkedIn, or on Hacker News, and there it is: the announcement. Google, Microsoft, OpenAI, or a startup that just got funded with numbers we only ever see in rounds talked about on podcasts, has just launched *the same thing*. Or something close enough that, in the market’s eyes, our idea becomes a late clone. It’s not even a “they copied us” thing. It’s more banal and more depressing: they have scale. And in this historical phase, scale seems to matter more than anything. I often wonder whether we’re entering an era in which real innovation becomes almost a luxury reserved for those who can afford to fail fast and in public. ## When they don’t beat you because they’re better, but because they’re faster {: #when-they-dont-beat-you-because-theyre-better-but-because-th } Up to here, it would already be frustrating. But there’s another level, harder to swallow. Because they don’t always beat you to market with a better product. Sometimes they beat you with something mediocre, shipped quickly, with minimal tests and an almost arrogant confidence that the brand will hold up anyway. “Vibe coding,” which until recently seemed like a game for indie hackers, has entered enterprises. And I’m not talking about the junior who uses copilot to write a component. I’m talking about entire teams generating huge chunks of an application with prompts, doing a couple quick checks, and then pushing everything to production. In recent months I’ve seen platforms with vulnerabilities that give you chills. Xss you can catch in five minutes, api without rate limiting, payment flows without idempotency, personal data handling that would probably make anyone who’s ever been a serious DPO turn pale. And yet they’re there. On the market. With users. With revenue. The implicit message, that hits you even if you don’t want to hear it, is this: quality doesn’t matter, speed matters. And if quality doesn’t matter, then we small players—who build our reputation and often our survival on quality—what room do we have? ## The Brussels epiphany (that I didn’t expect) {: #the-brussels-epiphany-that-i-didnt-expect } Here comes the part that, until a couple of years ago, I never would have thought I’d write. For a long time I looked at European regulation with annoyance. GDPR in 2018 felt like a boulder: lots of effort for those who were already working well, while the big players kept doing whatever they wanted and, at most, paid fines that were pocket change to them. But then I started looking at the picture that’s forming now. And I had a strange, almost counterintuitive feeling: maybe Brussels is one of the few weapons we have left. Not because “bureaucracy is beautiful,” obviously. But because what’s taking shape isn’t an isolated regulation. It’s an integrated regulatory ecosystem that changes the yardstick by which competition happens. If Europe is 80% SMEs, and if it wants those SMEs to survive in the AI era, then it has to do one simple and extremely hard thing: prevent size from being the only competitive advantage. And, for better or worse, that’s exactly what it’s trying to do. ## Seven laws, one direction {: #seven-laws-one-direction } I’m listing them, yes, but with a specific idea: don’t read them as “seven obligations.” Try to read them as an industrial strategy. ### AI Act, the great leveler upward The AI Act has been in force since 1 August 2024, with progressive application. Bans from February 2025, obligations for high-risk systems from August 2026. The interesting thing is that it doesn’t say “don’t do AI.” It says “do it well.” It classifies systems by risk, and where the risk is high it asks for things that, honestly, should be normal: risk management, data quality, human oversight, documentation, transparency. For an SME that already works in an orderly way, compliance is often a manageable delta. Not free, sure. But manageable. For those who put a critical system into production built in three weeks without really knowing what it does, it becomes an abyss. You have to rethink processes, governance, architecture. You have to slow down. And that’s where the AI Act becomes, paradoxically, pro-SME. Not because it protects small players just because they’re small, but because it rewards those who already have a “let’s do it properly” culture. There’s also a point I care a lot about regarding general-purpose models: transparency and documentation obligations for providers, especially for models with systemic risk. Translated: if I build a product on a foundational model, *I have more right* to know limits, risks, and boundaries. Today you often only figure it out by reading papers and corporate posts. ### Cyber Resilience Act, the end of “it works, don’t touch it” The CRA has been in force since 10 December 2024. Reporting obligations from September 2026, full application from December 2027. Here the music really changes: if you put a product with digital elements on the European market, you’re responsible for security across the lifecycle. Security updates for at least five years, documented vulnerability handling, fast reporting, and above all sbom. Sbom, without any romanticism, is an inventory: knowing what’s inside your software, including dependencies. When a critical CVE comes out, you don’t have to do archaeology. You know. And you know who’s often already set up like this? SMEs with modern stacks, decent pipelines, tracked dependencies. Who suffers instead? Huge organizations with years of technical debt, untouchable legacy applications, components frozen in 2016, and nobody who really has the map of the territory. The CRA makes maintenance no longer a “if there’s time left” thing, but a duty. And suddenly the obsessive attention to updates stops being a personal fixation and becomes a competitive posture. ### Product Liability Directive, software is no longer untouchable The new PLD was adopted in 2024 and member states must transpose it by December 2026. Here I’ll admit I’m a bit scared. Because it extends defective product liability to software as well. And in some cases it introduces mechanisms like the reversal of the burden of proof: if there’s a plausible link between defect and damage, the producer must prove that the product was not defective. Now, imagine a company that shipped a financial app without serious tests, without code review, without documentation. If damage happens, how do they prove it? An SME that works with CI, automated tests, traceable reviews, documented architectural decisions, changelog and release notes, ends up with something valuable it hadn’t called that: a defensive file. The PLD, in practice, turns process quality into a legal shield. ### European Accessibility Act, the web isn’t only for people who see well The EAA already applies from 28 June 2025. Accessibility means WCAG 2.1 AA as a reference: semantics, contrast, keyboard, screen reader, text alternatives. Not the “pretty page,” the page that’s usable even by people with disabilities. Those who have always treated accessibility as a requirement start ahead. Those who built gorgeous interfaces that are unusable with a screen reader have to run. And here there’s a very concrete opportunity: accessibility becomes a service. Audits, remediation, accessible design systems. There’s also the exemption for micro-enterprises, which is an interesting detail: you can be small enough not to be obligated in certain cases, but competent enough to help others. ### NIS2, cybersecurity is no longer optional NIS2 was supposed to be transposed by October 2024, and in Italy the transposition has arrived. Application is progressive. The part that hits SMEs isn’t just “are you in scope or not.” It’s the supply chain effect. If your customer is subject to NIS2, they’ll ask you for guarantees. Procedures. Incident response. Measures. Security becomes a commercial prerequisite. If you can’t demonstrate a serious posture, you don’t work with certain customers. Period. And here too, those who invested earlier, maybe with effort and without glory, find themselves ahead. ### Data Act, the data generated is yours too The Data Act has been in force since 11 January 2024 and applies from 12 September 2025. The concept, put simply, is this: data generated by the use of a connected product must be accessible to the user and, on request, shareable with third parties. For those who live off lock-in, it’s a shock. For SMEs it can be a huge opening: if data must be portable, someone has to build the infrastructures, the API, the connectors, the formats. It’s almost an anti-lock-in law. And many SMEs, plainly, never had the strength to do aggressive lock-in. Now that “lack” can become an advantage. ### DMA and DSA, gatekeepers with different rules The DMA has been fully applicable since March 2024, the DSA since February 2024. Here the point is political but very concrete: gatekeepers can no longer play with the same impunity as before. Interoperability, bans on self-preferencing, more transparency. Is it enough? Probably not. I expect loopholes, creative interpretations, very well-paid lawyers. But it changes a principle: being big doesn’t automatically give you the right to cheat. ## Taken together, it’s not compliance: it’s a change of metric {: #taken-together-its-not-compliance-its-a-change-of-metric } If I look at these laws as a whole, I see a pretty clear message. In the European market, the idea is that the winner is the one who does things well. Well means: transparent and supervised AI, maintained and secure software, real accountability when you cause harm, accessibility as a requirement, cybersecurity as a daily practice, less locked-in data, more controlled dominant platforms. And, almost unintentionally, this direction values some typical traits of serious SMEs: attention to detail, closeness to the customer, more up-to-date stacks, less untouchable legacy, fewer incentives to “ship it and we’ll see.” ## But reality isn’t all sunshine {: #but-reality-isnt-all-sunshine } It would be dishonest to say compliance is free. It costs time, it costs money, it costs focus. And in a medium (or small) company every hour spent on documentation and processes is an hour not spent on product. There’s also a real risk: that compliance becomes, once again, an advantage for big players, the ones who can afford legal departments and governance platforms. But here, maybe, Europe has understood a point: proportionality. Many laws differentiate by risk and size. And then there’s another path, which seems very concrete to me: turning compliance into a service. If you truly understand CRA, AI Act, NIS2, EAA, not just as “checkboxes,” but as technical implications, you can sell it. Sbom, audit, hardening, AI governance, accessibility assessments. Compliance stops being only a cost and becomes a market skill. ## What I’d do Monday morning, for real {: #what-id-do-monday-morning-for-real } I don’t want to close with the moral. I’d rather close with practical things, because maybe that’s where SMEs can help each other. We’re trying to build a single internal framework, not seven separate processes. We have to—we’re small. And this time being small is an advantage, because we can’t afford silos. The documentation needed for the CRA also helps with the PLD. The sbom is needed for CRA, but it also becomes a useful base for NIS2-style requests. The AI Act’s risk-based logic fits well with the GDPR approach. We’re also trying to treat compliance as a product, not just as an obligation. If a customer has to adapt, someone has to guide them. And if you guide them well, you’re not selling “bureaucracy.” You’re selling risk reduction, operational continuity, reputation. Then there’s training. Not the kind made of slides only. Training to understand the *why* behind the rules, because if you understand the why, you need the checklist less. You reason better when the weird case arrives, the one that isn’t written anywhere. And finally the network. Shared templates, processes, lesson learned. Compliance isn’t a zero-sum game. If your ecosystem is more solid, so are you. ## Maybe this is the point: we don’t have to apologize for being small {: #maybe-this-is-the-point-we-dont-have-to-apologize-for-being- } I have no illusions. Big tech will invest in compliance, they’ll find ways to adapt, they’ll lobby, they’ll look for favorable interpretations. But something has changed: Europe is saying that, in its market, speed without responsibility is no longer a superpower. And for those who, like us, have always built with care not out of virtue but out of necessity, that’s a strange and beautiful piece of news. Maybe we don’t have to become bigger. Maybe we just have to keep doing things with attention and responsibility. Only now, finally, there’s someone trying to make that choice count. --- # Hiring in 2026: you don't need to use AI, you need to govern it - **URL:** https://margiovanni.it/en/blog/hiring-in-2026-you-dont-need-to-use-ai-you-need-to-govern-it/ - **Published:** 2026-03-17 - **Tags:** AI, Leadership, SME, Hiring - **Reading time:** 10 min > In SMEs, AI isn’t a tech topic. It’s a cross-functional skill: knowing how to govern it, assess its output, and use it to do new things. ## A question SMEs ask under their breath {: #a-question-smes-ask-under-their-breath } Every now and then I end up talking with entrepreneurs who have ten, thirty, eighty people. They don’t have a Chief AI Officer, they don’t have an eighteen-month roadmap, and often they don’t even want to be told that they “have to transform.” They have another urgency, much more concrete: keeping the company running. And yet the question comes anyway, even if it’s rarely said exactly like this: *so what, concretely, are we supposed to do with AI?* Big companies are already asking it officially, with budgets, dedicated teams, and programs with acronyms that sound important. SMEs, instead, are in different territory—made of confusion and contradictory signals. And it’s not their fault. It’s that the public conversation about AI often feels designed for people who have time, resources, and structures an SME will never have. So I’ll try to put it simply, almost brutally. How many people on your team know how to get a better result from an AI agent than they would produce on their own? Not how many “use it.” Not how many have ChatGPT open in a tab. How many know how to give precise instructions, critically evaluate the output, iterate methodically until something comes out that truly holds up. In sales, marketing, operations, finance, legal, product, HR. **If the honest answer is “few” or “I don’t know,” you probably have a problem.** And in SMEs that problem weighs more, because you don’t have the luxury of postponing. ## The most expensive misunderstanding of 2026 {: #the-most-expensive-misunderstanding-of-2026 } The misunderstanding, in my opinion, is this: thinking AI is a tech issue. It isn’t anymore. Maybe it hasn’t been for at least a year. AI has become a multiplier of individual capability, cross-functional to every role. A salesperson who can build a competitive analysis in ten minutes is playing a different game than someone who takes two days. Whoever handles administration and can generate a sensible cost dashboard in an hour is competing in a different category than someone who assembles everything in a week, fishing data out of old, half-broken excel files. And here we’re not talking about the usual word “efficiency.” Efficiency is doing the same things faster. Here we’re talking about people who start doing things they didn’t do at all before, because the cognitive cost was too high. A truly personalized offer for every prospect, instead of the usual recycled pdf with the name changed on the cover. A cash flow analysis of the last three years that shows you patterns no one ever pointed out. Project progress reports that didn’t exist before because “there’s no time.” It could happen. But only if someone knows how to govern the tool. If they treat it like a collaborator to direct, not like a toy to ignore or an oracle to interrogate at random. ## “Governing” isn’t “using” {: #governing-isnt-using } This distinction is the heart of everything, and it strikes me how often it doesn’t get made. Using AI is asking for something and accepting whatever comes back. It’s prompt-and-pray. You write a request, copy the answer, paste it into an email, and hope it’s fine. It’s understandable—at the beginning everyone does it. But it’s worth nothing, and in some cases it’s even dangerous. Governing AI is something else. It’s knowing what to ask, how to ask it, and above all understanding when the answer is wrong even if it looks perfect. It means giving context, constraints, success criteria. It means iterating for real. Not “rewrite it better,” but “rewrite it considering that our customer is a public entity, with procurement constraints and six-month decision timelines.” Whoever governs AI has a mental model of the tool. They know what it does well, where it tends to invent, where it can become a risk. They know when to trust it and when to verify. They know when the output is a starting point and when it can be considered finished. And no, it’s not an innate talent. It’s a skill you develop. But here comes the slightly uncomfortable part: not everyone develops it. Not because they aren’t smart, but because it takes a specific mindset, and it’s not as widespread as we like to think. ## The mindset you’re ignoring in interviews {: #the-mindset-youre-ignoring-in-interviews } When you hire, you usually look at experience, vertical skills, company culture, maybe leadership. All fair. But you risk overlooking a variable that in the next two years will separate who performs from who struggles. The variable is this: can the person in front of you work at a higher level of abstraction than execution? Those who work at the execution level complete tasks. They write emails, prepare reports, analyze data, produce documents. They do it well, with craft. But they do it one thing at a time, and their time is the only resource. Those who work at the specification-and-governance level define what needs to be done, with what quality, within which constraints, and then direct an agent (AI or human—at that level the distinction starts to blur) to execute it. They supervise, correct, refine. And move on. It doesn’t mean execution doesn’t matter. It means the value of pure execution is compressing rapidly, while the capacity for governance is expanding. If you don’t evaluate this capability during hiring, you’re hiring executors in a world that rewards directors. ## Three questions that change an interview {: #three-questions-that-change-an-interview } It doesn’t matter whether you’re hiring a marketing manager, a controller, an office manager, or a CTO. There are three questions that, in my opinion, work almost every time. ### “Tell me about the last time you used an AI agent for a real deliverable” Not an experiment. Not a game. A finished deliverable in front of a client, a boss, a board. Listen to how they talk about it. Did they give precise instructions or generic prompts? Did they iterate? Did they verify the output? Did they integrate their judgment or take everything as-is? If the answer is “I’ve never done it,” in 2026, that’s a data point. Not necessarily disqualifying, but it’s a data point to weigh seriously. ### “How would you know if the output is wrong?” This is the key question. AI produces convincing results even when they’re completely made up. A plausible but false number. A logical argument that starts from a premise that doesn’t exist. A beautifully written text that says the opposite of what you need. Whoever knows how to govern AI has developed antibodies. They have a method, even a rudimentary one, to distinguish reliable output from toxic output. Whoever doesn’t have it is more dangerous than someone who doesn’t use AI at all, because they produce errors with the confidence of someone who believes they’re right. ### “If you had a dedicated AI assistant for eight hours a day, how would you reorganize your work?” This question separates those who think in terms of tasks from those who think in terms of systems. The mediocre answer is: “I’d do the same things faster.” The interesting answer is: “I’d do different things,” followed by a concrete vision. What would change in priorities? Which outputs would start to exist? Which activities would be eliminated or reduced? Whoever answers well has already understood that AI isn’t just an efficiency tool. It’s a leverage tool. And they know where to place the leverage. ## The elephant in the room: the key people you already have {: #the-elephant-in-the-room-the-key-people-you-already-have } The biggest problem, often, isn’t who you hire. It’s who you already have. In an SME the org chart is short. You don’t have layers of middle management. You have three, five, eight key people holding the company up. The head of sales who knows every customer by heart. The admin who’s kept the machine running for fifteen years. The project manager you dump everything on that you don’t know where to put. If these people don’t touch AI because “it’s not my job” or because “I’ve always done it this way and it worked,” you have a bottleneck no new hire can compensate for. In a big company you can route around the problem with a dedicated team. In an SME you can’t. The key people *are* the company. If they don’t change, nothing changes. And here comes the truly uncomfortable part, the one that usually causes a bit of irritation. In many SMEs, the first person who didn’t get the message sits pretty high up. If it’s you, and you’re reading with a mix of interest and irritation, maybe it’s worth stopping for a second on that irritation. I often wonder if it isn’t one of the most useful signals we have when something concerns us more than we’d like. The choice, in the end, is clear-cut: establish that the ability to govern AI agents is an expected skill for every role, starting with yours. Not optional. Not “nice to have.” Expected, evaluated, measured. ## It’s not a generational issue {: #its-not-a-generational-issue } There’s another mental shortcut that feels convenient, but doesn’t hold up: “young people are digital natives, so they understand AI.” It’s not true. I’ve seen twenty-somethings use AI like a slightly more brilliant search engine. And I’ve seen fifty-somethings integrate it into their workflow in ways that, honestly, I wouldn’t have imagined. The variable isn’t age. It’s the willingness to rethink how you work. To say: “maybe the way I’ve always done this thing isn’t the best anymore.” It takes humility, curiosity, and a pinch of discomfort. Three things that don’t have an age. So no, it’s not enough to hire young people and hope AI enters the company by osmosis. It takes a deliberate choice about which skills you value, which you reward and—let’s say it—which you demand. ## The cost of inertia, in numbers (more or less) {: #the-cost-of-inertia-in-numbers-more-or-less } These aren’t perfect calculations, but the order of magnitude is. A knowledge worker who governs AI well often has output equivalent to 1.5x or 2x compared to someone who doesn’t use it. Not because they work more, but because they eliminate low-value work: manual research, first drafts, exploratory analysis, data structuring, slide prep. In a team of ten people, if five govern AI and five don’t, it’s as if you had twelve or thirteen people. Without hiring anyone. Now flip the reasoning. If your competitor’s team is aligned on this skill and yours isn’t, your team of ten stays a team of ten. Theirs becomes a team of fifteen or twenty, at least for some activities. And the gap widens every month, because the tools improve and those who govern them capture the incremental value. Those who don’t govern them stay still. It’s not futurism. It’s arithmetic. ## What to do Monday morning {: #what-to-do-monday-morning } The good news is you don’t need task forces, consultants, or twelve-month transformation programs that cost six hundred thousand euros. You need three practical choices, and a bit of consistency. The first is to include AI governance capability in the evaluation criteria for every open position. Not as a technical requirement, but as a cross-functional skill, at the same level as the ability to communicate or work in a team. Ask those three questions. Really listen to the answers. The second is to ask your direct reports how they use AI in day-to-day work. Not with an anonymous survey, but in a one-to-one conversation. You’ll discover surprising things in both directions. Those who use it well often do it quietly. Those who use it poorly sometimes don’t realize how fragile their method is. The third is to lead by example. If you’re an entrepreneur who has never used an AI agent to prepare an offer, analyze financial statements, or write an important communication, the message you’re sending is crystal clear: it’s not important. And your organization will believe you. In an SME you can’t delegate change. Either it starts with you, or it doesn’t start. ## It’s not a moral {: #its-not-a-moral } In five years we’ll probably look at the hiring processes of 2025 the way we look at those of 2010 today, with a mix of tenderness and disbelief. “You really hired people without checking whether they knew how to work with AI?” Really. And whoever stops doing it earlier, without waiting for it to become “standard,” will have an advantage the others will take years to close. Maybe the right question, in the end, isn’t whether the next person you hire knows how to use AI. It’s whether they’ll know how to govern it. And whether you’ll be willing to demand it, even when it’s uncomfortable. --- # Things I've Stopped Doing Over the Last Fifteen Years of Work - **URL:** https://margiovanni.it/en/blog/things-ive-stopped-doing-over-the-last-fifteen-years-of-work/ - **Published:** 2026-03-17 - **Tags:** Compliance, Career, Technical Leadership, Software Development - **Reading time:** 9 min > Notes on the things it took me at least 15 years to unlearn—habits about code, stacks, business, compliance, hiring, language, and leadership. I’ve realized that the hardest things to learn are almost never technical. **They’re the things you have to *unlearn*.** And the weird part is that, while you’re unlearning them, it feels like you’re losing something. Status, control, identity. Then, if things go well, you realize you were just letting go of a habit that was keeping you stuck. These are scattered notes on a few things I’ve stopped doing. It took me fifteen years, more or less. And on some of them, if I’m being honest, I’m not done yet. ## I stopped writing code to prove I’m still technical {: #i-stopped-writing-code-to-prove-im-still-technical } There was a period, right after a big career transition, when my way of legitimizing myself in front of the team was always the same: I’d open the IDE and go grab the ugliest bug of the week. I often did it in the evening, alone. The next morning the commit was there, with my name on it. In my head I called it leadership. In reality it was insecurity. Because the implicit message was devastating, even if I never said it out loud. The message was: I don’t trust you. And there was another one, even more toxic: problems get solved at night, solo, without asking for help. Without meaning to, I was teaching that the heroic gesture matters more than the process. That skill is an individual performance. That effort is a medal. Then I took another spin on the carousel. I replaced code with specs. Documents so precise that the team, or an ai agent, could implement them with minimal supervision. For a while it felt like the “adult” solution. But that phase passed too. Today my job, when I do it well, is something else. It’s deciding *what* we build, *for whom* , and *why now*. It’s portfolio architecture, not code architecture. It’s partnerships, hiring, positioning. It’s figuring out where the company needs to aim eighteen months from now, and which choices today make that direction more likely. This distance from code sometimes hurts. Not because I want to go back to programming every day. It’s subtler than that. It’s the feeling that the legitimacy of a technical person who no longer touches code daily is fragile—something you have to rebuild on different foundations. No longer on the quality of what you write, but on the quality of the decisions you make and the people you choose. And then there’s a sentence that comes back to me often, and helps me not fall back into the old reflex: every line I write is a line someone else doesn’t write. Every hour I spend in the IDE is an hour when nobody is looking at where we’re going. ## I stopped chasing the right stack {: #i-stopped-chasing-the-right-stack } For years I had that Pavlovian developer reflex. A new framework comes out, you have to evaluate it. A new language comes out, you at least have to try it. Deep down, I think the subtext was this: there is a “right” technology choice that puts you on the winners’ side. The cool kids. The right conferences. The articles on Hacker News. Then I did something unpopular, at least for how I’d gotten used to thinking: I picked a framework. One. And I stuck with it. Not because it’s the absolute best. But because it lets me deliver value with a small number of people across multiple projects, without losing my mind. Because it has a philosophy that holds up under the real constraints of an Italian company. Convention over configuration, batteries included, obsessive documentation. Not the imaginary constraints of a Bay Area startup that lives on slides and runway. The uncomfortable truth is that a lot of “bold” technology choices, in SMBs, aren’t bold. They’re vanity. Choosing Rust for an internal management system that forty people will use isn’t engineering. It’s narcissism with a compiler. At some point I stopped looking for the right stack and started looking for the honest stack. The one that doesn’t lie about the complexity it introduces. The one you can maintain when the seniors leave, when the budget tightens, when the client changes their mind three times. ## I stopped shielding the team from the business {: #i-stopped-shielding-the-team-from-the-business } This was the hardest transition. For years I acted as a shield. The client asks for a crazy change? I filter it. Sales sells something that doesn’t exist? I handle it. An incomprehensible document arrives? I translate it and pass only the technical part to the team—clean, digestible. I thought I was being a good leader. And instead, I was probably creating invalids. Very strong developers, yes, but disconnected. They didn’t really know why they were building what they were building. They couldn’t read a business requirement. They had never talked to a client. And when they hit ambiguity, instead of picking up the phone, they’d open a ticket and wait for someone else to resolve it. The change, for us, was building an internal path we called “from developer to product owner.” Not to turn everyone into PMs. More than anything, to remove the filter. To say something simple, even if a bit uncomfortable: the mess is yours too. The confused client is yours too. The ambiguous requirement is yours too. And, above all, the satisfaction of delivering something that actually works for someone is yours too. I thought it would be unpopular. I was wrong. They surprised me. Maybe they were just waiting for us to give them permission to step out of the bubble. ## I stopped saying “it’s public anyway” when talking about compliance {: #i-stopped-saying-its-public-anyway-when-talking-about-compli } For years my stance on compliance was the typical one in Italian IT. The bare minimum, done at the last possible moment, treated as a cost and never as an investment. GDPR? A cookie banner and a copied privacy policy. Accessibility? “We’ll think about it later.” Security? “We’re not a target.” Then I started actually reading some European regulations. Not articles *about* those regulations—the texts themselves. And two things became clear. First: the European legislator, for once, is not kidding. The penalties are real, the timelines are tight, and the chain of responsibility goes all the way down to the supplier of the software component. That is, us. Second, more important: in a market where everyone waits until the last moment, whoever moves first has an enormous competitive advantage. Not because they’re better. Because they’re the only one who can tell the client “yes, we’re ready” when the client, in a panic, starts asking. At some point I stopped treating compliance like an obligation. I started treating it like a product. And I often wonder why it took us so long to understand. Maybe because it’s more comfortable to think it’s just paperwork—until it suddenly becomes a problem with a deadline. ## I stopped hiring for technical skills {: #i-stopped-hiring-for-technical-skills } This is recent and, if I’m being honest, still a bit painful. I spent weeks looking for an important role. Candidates with excellent CVs. Years of experience. Solid stacks. Good references. I rejected several—not because they weren’t good, but because they used AI the way they used Stack Overflow ten years ago. Like an oracle. What I was looking for, and what I still struggle to explain to recruiters, is different. I was looking for someone who could write a declarative spec so precise that an AI agent could implement it with minimal supervision. Not a prompt engineer. A *systems thinker* who uses AI as a runtime, not as a crutch. The difference seems subtle, but it isn’t. It’s the difference between someone who says “I asked ChatGPT to write the code for me” and someone who keeps a *claude.md* file in the repository with architectural conventions, patterns, domain constraints. It’s the difference between conversation and specification. Between craftsmanship and engineering. I stopped hiring developers who can code. I started looking for developers who can *specify* and then verify what AI produced with the same rigor they’d use to review a junior’s code. The Italian market doesn’t seem ready for this distinction yet, unfortunately. But I have a feeling it will be soon. And anyone who doesn’t get there in time risks ending up with teams that “produce” a lot, but understand little. ## I stopped speaking Italian at work {: #i-stopped-speaking-italian-at-work } It seems like a small thing. It isn’t. When a new non-Italian junior joined—brilliant—we found ourselves facing a choice. Keep working in Italian among ourselves and use English only with him, effectively creating a two-speed team. Or switch completely. We chose the full switch. Everything in English. Jira in English. Chat in English. Daily in English. Retro in English. For everyone. I didn’t do it only for him. I did it for us. Because a small company in an Italian city that works only in Italian is a company that will probably stay small in that city. There’s nothing wrong with that, truly. It’s just not what we wanted. In the end, English isn’t a language. It’s infrastructure. Like Git, like CI/CD, like documentation. Either you have it, or you’re cut out. It was uncomfortable. Some people struggled. But today, when I read pull request descriptions, messages, emails, I think it was worth it. ## I stopped believing that good code speaks for itself {: #i-stopped-believing-that-good-code-speaks-for-itself } This is perhaps the most dangerous lie in software engineering. The romantic idea that if code is clean, tested, well-structured, then its value is obvious. That technical merit can defend itself. It doesn’t work like that. Good code that nobody understands is indistinguishable from mediocre code. Refactoring that nobody talks about becomes a cost, not an investment. An architectural migration without a written business case looks like a whim from the engineering department. I learned, late, that half of a tech leader’s job is *storytelling*. Explaining to the board why a migration isn’t a luxury but risk reduction. Explaining to the client why the automated tests they paid for are the reason they sleep well. Explaining to the team why CI/CD isn’t bureaucracy but freedom and convenience. If you can’t tell the value of what you build, someone else will tell it for you. And they’ll tell it badly. ## The thing I still haven’t stopped doing {: #the-thing-i-still-havent-stopped-doing } If I want to be completely honest, there’s one thing I should stop doing and I still can’t. Working as if I’m the only one holding the pieces together. Too many things still go through me. Not because the team isn’t capable—quite the opposite—but because I still haven’t built the systems that make me redundant in each of the areas we operate in. And that’s what scares me most. Because every previous step had a clear replacement. Stop writing code? Specs. Stop writing specs? Strategy. Stop doing code review? A team lead. But stopping being the convergence point for everything is different. The replacement is trust in systems. And systems, if I’m honest, I still have to finish building. We’ll talk about it again. --- # The Customer Is Always Wrong (and That Might Be a Good Thing) - **URL:** https://margiovanni.it/en/blog/the-customer-is-always-wrong-and-that-might-be-a-good-thing/ - **Published:** 2026-02-27 - **Tags:** IT Consulting, Work Culture, Project Management, Software - **Reading time:** 7 min > In IT consulting the automatic yes kills projects. Saying no, with respect, is often the better service: less waste, more trust, more truth. There's a sentence that, in consulting—at least where I work—sounds almost like blasphemy. One of those things you think while you watch yet another meeting turn into a catalogue of requests, but then you don't say. Because it's not done, because of "the client relationship", because the salesperson glares at you and someone reminds you that "we're here to satisfy needs". And yet. The customer is wrong. Not always, of course. Not on everything. But much more often than we like to admit. And I wonder whether the real problem isn't the customer themselves, but the polite lie we've been telling them for years. The one about "the customer is always right". A lie that, in Italian software, has done damage you can't even properly count, because failures rarely come with a sign saying "failure". Usually they're quieter. They're projects that go to production and then no one uses. Money burned on things that don't improve anything. Long nights of people who knew it was going wrong but didn't have the space, or the permission, to say so. This is a slightly mean piece. I'm not asking you to agree. I'm only asking you to be honest, at least for the duration of this read. ## The yes that kills projects {: #the-yes-that-kills-projects } I've watched more projects die from a yes than from a no. The mechanism is almost always the same, and that's exactly why it's frightening. The client asks for something. You know it, you feel it, you see it in the details: it's wrong technically, or economically, or just as a direction. But you say yes anyway. You say yes because there's a contract. Because there's a relationship to protect. Because "we'll fix it later". Because the handshake already happened and going back feels like defeat. Because saying no is uncomfortable, requires arguments, requires energy, and above all requires courage. So the project doesn't die in one go. It dies one yes at a time. Every yes adds a feature no one will use. Every yes shifts a piece of the deadline, or compresses a piece of the quality. Every yes makes the architecture a little more fragile and the code a little more contorted, until what you're building no longer looks like a product, but a layered compromise. In the end you ship software that does a hundred and fifty things, none of them well, and the client looks at you and says: "this isn't what I wanted". And here's the part that stings, because in a sense they're right. It isn't what they wanted. It's what they asked for. Two different things. And maybe our craft, the real one, isn't to execute orders. It's to recognise the difference. ## Catalogue of horrors (all real, sadly) {: #catalogue-of-horrors-all-real-sadly } What follows is true. The names are changed, the dynamics aren't. And if you find yourself thinking "I've seen one just like that"—you aren't alone. ### The endless management system A medium-large company asks for a management system. So far, normal. Then, while it's being built, every department adds requirements. HR wants the leave module, marketing wants the dashboard, accounting wants the integration with the bookkeeper, and each one is convinced they're the centre of the world. No one has the power to say enough, because every department is an "internal client" who "is right". Result: eighteen months of development, a product that does everything badly, and after release the company keeps using Excel. Which, in the end, at least doesn't betray you. ### The carbon-copy tender A municipality has to digitalise a service. The tender is written by copying one from another municipality—maybe three times bigger, with completely different needs. Inside it end up requirements that read well on paper but no citizen will ever use. Whoever wins the contract often knows. But the tender is the tender. So you build exactly what's written. You deliver, you test, you tick boxes. The platform goes live. Six months later the service is still being handled by phone. And the saddest part is that, formally, everything went fine. ### The app that was supposed to change everything A local public administration wants a mobile app for citizens. The decision-maker is a council member who saw another municipality's app and wants the same one. No needs analysis, no user research, nothing. Just: "I want the app". The vendor builds it. At launch, four hundred people download it. After three months it's used by twelve, counting council employees. The council member holds the press conference and talks about innovation. The vendor cashes the cheque and moves on to the next. And I can never decide who in this story makes me more uncomfortable. ### The restyle that was a rewrite A client asks to "freshen up" the website. The salesperson sells a restyle. At the first operational meeting it emerges that the site has no CMS, the database is an Excel sheet, content doesn't exist, and "freshen up" means rethinking the entire digital presence. But the quote is for a restyle, the timeline is for a restyle, and the expectations are for a restyle. Everyone knows it isn't a restyle. No one says so. ### The zombie project A project was supposed to last six months and is in its third year. It doesn't work, isn't being used, but no one closes it because closing it would mean admitting it was a mistake. The client keeps paying for change requests. The vendor keeps invoicing. Both know it's dead. Both pretend it's alive. It never officially fails. It just stops being mentioned in meetings, like an awkward uncle no one talks about at lunch. ## Why it actually happens {: #why-it-actually-happens } It happens because our sector has a structural problem with truth. The business model of Italian IT consulting is built on yes. You win projects by saying yes. You retain clients by saying yes. You get promoted by saying yes. The whole system, from sales to project managers to developers, is optimised to minimise conflict and maximise short-term invoicing. The trouble is, short-term and long-term are at war. Saying yes today almost always means paying tomorrow. Every extra feature is technical debt. Every requirement accepted without analysis is a time bomb. Every timeline compressed to please someone is a guarantee of overtime—often unpaid—and of sacrificed quality. Meanwhile the client never learns. Not because they're stupid, but because no one tells them that request was wrong. No one tells them that tender was poorly written. No one tells them that app was useless to anybody. Surrounded by people who nod, the client keeps asking for the same wrong things, and the cycle starts again. And here's the part that hurts, because it shifts the responsibility. It isn't the client's fault. It's ours. It's the fault of a sector that gave up its role—the role of the expert. The one who knows things the client doesn't, and who has the duty, not the right, to say them. ## The no as service {: #the-no-as-service } The best service you can give a client is to say no. No, that feature isn't needed. No, that timeline isn't realistic. No, that tender is poorly written and if we follow it to the letter we'll build something useless. No, you don't need an app. No, you don't need AI. No, you don't need a restyle. You need to stop and figure out what you actually want to do. Every no costs. It costs awkwardness, costs tension, costs a few hard phone calls. Sometimes it costs the project. But every no is also an act of respect for the client, because it treats them as an adult who can hear the truth, not as someone to be placated for a quiet life. The best clients I've had in my career are the ones I've said the most "no" to. At first they tense up, which is normal. Then, if you hold firm and you argue calmly, something happens: they understand that when you say yes, you can be believed. Trust isn't built on continuous agreement. It's built on candour. And candour, in our sector, is rare. Maybe rarer than a good developer. Maybe rarer than a project delivered on time. Maybe rarer than a well-written tender. ## A minimal manifesto, no heroics {: #a-minimal-manifesto-no-heroics } I don't know if this is a manifesto, but if it is, for me it lives in three lines. Don't say yes when you know it's no. Don't build what the client asks for if you know it isn't what they need. And when you're wrong—because you will be wrong, and we all will—at least be wrong by telling the truth, not by nodding. **The customer isn't always right. But they always deserve someone with the courage to tell them.** --- # Don't Add AI to Your Products. Rethink Them from Scratch. - **URL:** https://margiovanni.it/en/blog/dont-add-ai-to-your-products-rethink-them-from-scratch/ - **Published:** 2026-02-24 - **Tags:** API, Compliance, Digital Product, Software Development - **Reading time:** 8 min > Adding a chatbot isn't enough. If half the interactions are going to flow through AI agents, you have to rethink software, APIs, trust, and compliance. I've thought about this several times in the last few months, with a slight uneasiness. I've spent twenty years building digital products, long enough to remember well what it was like when Web 2.0 felt like the answer to everything, and long enough to have lived through the mobile revolution from the inside, with that "OK, something is really shifting here" feeling. With AI the same thing is happening. And yet, looking around, I see many companies reacting as if it were just another update. An add-on. A plugin. Maybe that's the problem. ## The "let's add a bit of AI" trap {: #the-lets-add-a-bit-of-ai-trap } By now it's almost a reflex. A chatbot in customer service. A generated summary in the dashboard. A copilot in a sidebar. A "smarter" search. These are useful things, really. I don't want to play the purist who dismisses everything that works. But I wonder if they aren't also, at the same time, deeply conservative. Like putting an electric motor on a horse-drawn carriage and calling it a revolution. The carriage stays a carriage—only what pulls it changes. I've seen this dynamic before. In 2007 it was called "mobile". When the iPhone exploded, plenty of companies took their desktop sites and "adapted" them. Responsive, smaller buttons, reordered columns, hamburger menu, done. Technically correct. Strategically… **almost irrelevant**. Because the winners weren't those who adapted the old to the new—they were those who rethought everything. **Uber isn't a taxi website made responsive.** It's a product that without GPS, always-on connectivity, and a device in your pocket would have made no sense. Instagram isn't a smaller Flickr. It's a visual language born for mobile, designed to be used with one hand, while you walk. WhatsApp isn't email on a smartphone. It's communication redesigned around an assumption: the device is personal, always with you, always connected. None of these products would have been born from the "let's fix what we have" mindset. They were born from a different question. ## The right question {: #the-right-question } The question isn't: *how do I add AI to my product?* The question is: **if I were designing this product today, knowing half the interactions will flow through AI agents, how would it be different?** It looks like a nuance, but it isn't. For twenty years we designed software starting from an almost invisible assumption: a human sits in front of a screen and interacts with a graphical interface. Click, scroll, fill fields. That assumption won't disappear, but it will stop being the only one. And when it stops being the only one, many choices that looked "natural" suddenly become arbitrary. Think how many daily actions we do inside digital products that, with the right APIs and the right permissions, an agent could do for us. Book a restaurant. Compare quotes. Fill a form. Move an appointment. Analyse a report. Order groceries. Pay a bill. It isn't science fiction. Language models, today, can already manage complex flows. The bottleneck often isn't the AI. It's the way products are built. A lot of software was designed to be *looked at* and *clicked*. Not to be *understood* and *orchestrated*. That difference, I think, is enormous. ## From interfaces to contracts {: #from-interfaces-to-contracts } Here it gets concrete. For years the "product" was the interface. The UI was the product. Everything else—backend, APIs, database—was infrastructure in service of the screens. Designers drawing screens, developers implementing them, product managers measuring conversions on buttons. In the paradigm coming into view, the product becomes the contract. Clear APIs. Structured documentation. Coherent data schemas. Capabilities exposed in semantically rich ways. Errors that explain what happened and what to do. Stable contracts. The graphical interface doesn't disappear, but its role changes. It becomes a *client* of the product, not *the* product. One client among many. And, paradoxically, this is good news. Because an API designed to be consumed by AI agents forces you to write good software. It forces you to be clear. Coherent. Reliable. Composable. **AI isn't lowering the bar. It's raising it.** ## From features to capabilities {: #from-features-to-capabilities } There's a mindset shift that touches the heart of product management. The traditional mindset is feature-driven. Add feature X. Need five screens, three endpoints, two tables. Wireframe, user story, acceptance criteria. And then a flow that's almost always linear: the user lands at A, clicks B, fills in C, gets D. The AI-native mindset, by contrast, tends to be capability-driven. You don't design a path. You design a building block. A capability that can be orchestrated by anyone: a human via GUI, an agent via API, another system via webhook. And often it'll be combined with other blocks in ways you hadn't anticipated. It's more powerful, but also harder. It requires thinking in terms of contracts, invariants, preconditions and postconditions. It requires more mature engineering. And here, I'll admit, I get a little excited. Because it's as if the pressure of AI finally makes inevitable the best practices many engineers have repeated for years, often into the void. ## The paradox of openness {: #the-paradox-of-openness } There's another aspect I find counter-intuitive. For years the dominant model was lock-in. Closed data, hard exports, walled gardens. "That's how we defend the competitive advantage." In a world of AI agents, closure risks becoming a handicap. An agent works better with services that collaborate. That expose structured data. That have documented APIs. That allow interoperability. If a service is opaque and hard to integrate, the agent will tend to bypass it and pick more composable alternatives. **And here there's a beautiful, almost poetic paradox: to keep users, you have to leave them free to leave.** This also shifts the playing field for small companies. Because on openness, on API quality, on documentation, on contract cleanliness, an agile SME can compete. Sometimes it can even do better than a giant full of legacy. ## Compliance as superpower {: #compliance-as-superpower } This part is close to me, because it's the ground I find myself on every day. GDPR, AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. They're often experienced as a cost. A nuisance. A tax on doing business. I, more and more, see them differently. In an ecosystem mediated by AI agents, trust becomes a computational resource. It's not just marketing. It's an input to decisions. If an agent has to choose between two similar services, it'll tend to prefer the verifiable one. The one with a transparent SBOM. Complete audit trail. Documented privacy by design. Compliance declared and demonstrable. In this sense, compliance stops being only a cost to bear and becomes a quality signal readable by machines. A competitive differentiator. I realise it almost sounds odd to put it that way, but I believe it's true: compliance can become a superpower. And maybe Europe, with all its bureaucracy that makes plenty of people sigh, is building a terrain where trust is computable. If you can turn it into architecture, it isn't a brake. It's an advantage. ## Where this becomes concrete {: #where-this-becomes-concrete } I could leave it here, on the level of ideas. But it wouldn't be honest, because for me this transition is concrete, daily. When we migrate a product, we aren't just "modernising the stack". We're preparing a service for a future where agents will interact with these systems as much as humans do. When we build an SBOM platform to manage software dependencies, we aren't just doing compliance. We're creating a layer of verifiable trust. When we move the centre of gravity toward spec-driven development, where the spec is the primary product and the code is a derived artefact, it isn't only a methodology. It's a way of working in which AI can be a real partner, not a gadget. At some point you notice everything holds together. Clean architecture, rigorous documentation, compliance by design, API-first, specs as the primary object. They're faces of the same idea. In the world coming, clarity is power. ## The real risk {: #the-real-risk } The biggest risk today isn't doing "the wrong things" with AI. It's doing the right things, but in the old paradigm. It's adding a chatbot instead of rethinking the architecture of the interaction. Putting AI suggestions in an interface that maybe shouldn't exist in that form. Using AI to write code faster without asking whether we should write clearer specs. I know it's a strong position. And I also know that many companies are getting real results by adding AI to existing products. I'm not saying it's all wrong. I'm saying it's insufficient. That it risks being yesterday's game with today's pieces. ## A love letter to technology that helps {: #a-love-letter-to-technology-that-helps } I'll close on a personal note, because for me this conversation isn't only strategy. I love technology when it helps. When it makes accessible what was exclusive. When it simplifies what was complicated. When it frees time for what really matters. When I think about AI in digital products I don't think—or at least not only—about chatbots answering on someone's behalf. I think about an elderly person who can interact with public administration through an agent that understands and translates bureaucracy. About a small entrepreneur managing compliance without an army of consultants because the software supports them natively. About a doctor who can stay with the patient while the documentation is handled better. About a student with a disability who finds a truly accessible experience, not a tick in an Excel sheet. To get there, though, "adding AI" isn't enough. You have to rethink products around a world where humans and agents coexist. It isn't easy. It requires putting back into question assumptions we took for granted. It requires new skills and a certain humility. It requires the most uncomfortable question of all: *if I were starting from zero today, would I do it like this?* But it's a beautiful challenge. The kind that makes you want to roll up your sleeves. **Because on the other side, perhaps, lies more useful, more accessible, more reliable software. And, in a meaningful sense, more human.** --- # The Luxury of Saying I Don't Know - **URL:** https://margiovanni.it/en/blog/the-luxury-of-saying-i-dont-know/ - **Published:** 2026-02-23 - **Tags:** Communication, Consulting, AI, Work - **Reading time:** 7 min > Saying "I don't know" looks like weakness, but it's often the most competent move. A story about consulting, AI, and the value of pausing before answering. A few months ago, during a call with a potential client, a sharp question landed on me—the kind that looks innocuous only until you have to answer. "In your view, how long does this project take to close?" I had everything I needed to improvise a credible answer. Years of experience, similar projects behind me, a gut estimate that could sound reasonable. Six months, maybe eight, with a prudent margin. Said in the right tone it would have looked the part: competent, reassuring, the voice of someone who knows their business. Instead something else came out. "I don't know. Not yet. Give us two weeks to analyse the context and we'll come back with a number we believe ourselves." The call went strangely silent. Three seconds, which in a sales conversation feels like a long time. Then the CEO on the other end said something that caught me off guard. "Finally someone who isn't pulling a number out of the air." We won that project. Not *despite* that "I don't know". Probably *because* of that "I don't know". ## The age of instant answers {: #the-age-of-instant-answers } I often wonder when we decided that the speed of an answer was a proof of intelligence. Or competence. Or authority. Today an answer is always available. About anything, at any time, in less time than it takes to phrase the question well. You search Google and in a fraction of a second you have endless results. You ask a language model and you get fluent text, well-written, even convincing. And so, without noticing, we've internalised a slightly toxic equation: whoever answers fast knows. Whoever hesitates doesn't. Whoever says "I don't know" is out of the game. You see it in meetings, where whoever speaks first often "takes" the room. You see it in job interviews, where hesitation gets read as unpreparedness, even when it's just caution. You see it in consulting, where "let me think about it" feels like a loss of value, as if the client were paying for ready-made certainty in your pocket. And then you see it in AI, which is maybe the most perfect embodiment of this mechanism. A language model isn't designed to stop and say "I don't know". It's designed to produce an answer. Structured, plausible, maybe brilliant. Even when it doesn't know. Sometimes *especially* when it doesn't know. Hallucinations aren't a folkloric incident, they're the natural consequence of a system trained to always fill the void. We've built a perfect machine for an age that decided silence is a defect. ## The cost of fake certainty {: #the-cost-of-fake-certainty } The interesting question, though, isn't why AI can't say "I don't know". It's why we struggle so hard to say it ourselves. I've spent twenty years between technology and consulting. Meetings, calls, presentations, workshops. If I think back to the times someone openly said "I don't know" without it sounding like a confession of guilt, I can count them on one hand. The unwritten rule is clear: you have to have an answer. Better wrong than absent. The problem is that this norm has an enormous cost, only it's hard to see while it's happening. You see it later, when a project estimated at three months drags on for twelve, and at some point someone says quietly: "we didn't actually have enough information to estimate". You see it when an architecture is chosen because someone spoke with great confidence in a meeting, and the honest version would have been: "let's do a proof of concept before deciding". You see it when a contract is born crooked, because the timeline got promised before anyone understood what was really underneath. I've watched products fail not because competence was missing, but because the courage to admit uncertainty was. And the bitter part is that the people faking knowledge often get rewarded. Certainty, even fake certainty, is reassuring. It gives the illusion of control. And whoever offers it gets perceived as a leader. It's a slightly inverted incentive system: it rewards speed over truth, confidence over honesty, appearance over substance. ## Three dangerous words {: #three-dangerous-words } "I don't know" is dangerous because it breaks a power dynamic. In a meeting with a client, saying "I don't know" means admitting that you, the expert, the one being paid to know, don't know in that moment. It's as if you cracked the implicit pact of consulting, where the client buys certainty and you sell it. Inside a team, if you're the lead, saying "I don't know" is even more counter-intuitive. Because we've been taught that leading means having the direction, having the answer, having the plan. And no one wants to follow someone who admits not knowing the road. Yet if I think back to the best decisions I've made, there's almost always an "I don't know" at the start. Not because ignorance is a virtue. It isn't. It's because "I don't know" is often the only honest starting point for a serious decision. It's the moment you stop performing and start reasoning. It's the move from the prepackaged answer to the real question. When someone says "I don't know", odd things happen. The air lightens, as if it suddenly became permitted not to know. Someone finds the courage to say "I have a doubt too". Information surfaces that had stayed hidden because no one wanted to look like the one slowing things down. Maybe that's the part that interests me most: "I don't know" isn't the opposite of competence. It's often its prerequisite. ## The AI paradox {: #the-ai-paradox } Here comes the paradox. AI makes it even harder to say "I don't know". Because if a machine produces an answer on any topic in two seconds, how do you justify that you, a professional with years of experience, don't have one ready? The benchmark shifts. The machine's speed becomes the standard against which we measure human speed. And in that race, stopping to think becomes a luxury. Except it's the wrong benchmark, founded on a confusion: mistaking *having an answer* for *having the right answer*. AI always has an answer. Often it's good. Sometimes excellent. But it doesn't know when it doesn't know. And that, paradoxically, is one of the most precious capacities we have: recognising that a piece is missing, sensing that something doesn't add up, intuiting that the variable being ignored is precisely the one that changes everything. Socrates built a whole philosophy on it: knowing that you don't know as the basis for actually knowing. Twenty-five hundred years later, we have machines that don't know they don't know, and we use them as a model of cognitive efficiency. The irony is almost perfect. ## A quiet competitive advantage {: #a-quiet-competitive-advantage } My experience is what it is, limited and full of bias, like all experience. But it has left me with a fairly stable conviction: people and companies who can say "I don't know" at the right moment win in the long run. The clients I've worked with longest are often the ones with whom, at the start, I admitted I didn't have all the answers. Not because they appreciated incompetence, but because that gesture created a different kind of relationship. A relationship where it was permitted to explore, ask questions, change one's mind. Where the solution didn't have to be ready by slide three. The best people I've worked with are the ones who, in the middle of a meeting full of acronyms, said "I don't understand" or "can you explain?". The famous "stupid" question everyone has in their head and no one asks. Almost always it's the one that unblocks everything. And the best decisions, the ones that years later turned out to be right, had a moment of suspension before becoming a "yes" or a "no". A small space of legitimate doubt. A refusal to answer just to take the pressure off. It isn't a method. It isn't a framework. It isn't a slide on vulnerability. It's something simpler and harder: accepting that competence includes recognising your own limits, and that those limits aren't a shame. They're the exact border where real thinking begins. ## The last word {: #the-last-word } We live in an era that demands immediate answers about everything. Algorithms that respond in milliseconds, colleagues who expect answers in minutes, clients who want them in hours. In this constant noise of cheap certainties, saying "I don't know" almost becomes a subversive act. A small resistance against a system that mistakes speed for truth and confidence for competence. I'm not making a case for ignorance. I'm making a case for the pause. For that uncomfortable moment between question and answer in which, if you resist the temptation to fill it with the first thing that comes to mind, something rare happens. You actually think. --- # What AI Doesn't Know About My Craft - **URL:** https://margiovanni.it/en/blog/what-ai-doesnt-know-about-my-craft/ - **Published:** 2026-02-22 - **Tags:** IT Consulting, AI, Work, Leadership - **Reading time:** 8 min > I asked a model to write a perfect proposal. I deleted it: it was missing the most important thing—the part written nowhere. Last week I asked Claude to write me a technical proposal for a client. It produced an impeccable document in forty seconds. Clean architecture, three-environment cost estimate, timeline with milestones, risk analysis. Perfect formatting. Professional language. I threw it all away. Not because it was wrong. It was technically correct—probably better than what I would have written off the cuff. I threw it away because that client, three months earlier, had told us in a call that their CTO had been fired after a failed project with an approach similar to the one being proposed. You won't find that in any dataset. It isn't in any prompt. It's an organisational scar that lives in the memory of the people who were on that call, and it changes everything: the tone of the proposal, the choice of solution, even the words to use and the ones to avoid. The AI had produced the right answer to the wrong question. That's something it does brilliantly. ## The invisible work {: #the-invisible-work } I lead in a deliberately small company. My job, on paper, is making decisions: which product to build, for whom, with what priorities, by when. If you looked at my job description, a language model could do ninety percent of what I do. Maybe more. But the job description is a lie. Like all job descriptions. My real work is made of things that don't sit in any backlog or any project document. It's made of silences during calls—that moment when a client says "yes, fine" with a tone that means "no, this isn't fine at all, but I don't feel like arguing right now". It's made of lunches with a colleague who hasn't been delivering for two weeks and who, over a second coffee, tells you they're going through a hard time at home. It's made of the decision, taken at eleven at night, not to reply to a provocative email from a stakeholder and to wait until morning, when the words weigh less. None of this is computable. And I don't think it's only a problem of missing context that gets fixed with a longer prompt or a more sophisticated RAG. **It's a different kind of knowledge. It's situated, relational, almost embodied.** You know a meeting is going badly because you feel the tension in the room. You know an estimate is inflated because you know who made it. You know a requirement should be refused not for technical reasons but because accepting it will push the product in a direction it can't come back from. And you know it because you've been in that direction three projects ago, with another client, and you have the scars to prove it. AI works on what is explicit. My craft lives in what is implicit. ## Four things I can't delegate {: #four-things-i-cant-delegate } I tried an exercise, partly out of curiosity and partly out of fear: identify the parts of my work a language model, however advanced, can't do. Not the parts it can't do *yet*. The parts that, by how it's built, it probably can't do. Or at least not in the same way. I found four. ### The first is reading people I don't mean assigning tasks or doing performance reviews. An Excel sheet can do that, often better. I mean the real part. Understanding that a colleague who suddenly starts producing sloppy work doesn't have a competence problem but a motivation problem. And that the motivation problem comes from the fact that in the last three sprints you put them on activities they considered below their level. And that they didn't tell you because they're afraid of looking arrogant. And that you know it because you've known them for four years and you know how they react when they feel undervalued. This causal chain isn't written anywhere. Half the links have never been verbalised. They exist in the space between two people who have worked together long enough to understand each other without speaking. Managing a team isn't optimising resources. It's navigating the emotional complexities of a group of human beings who spend more time together than with their families. And doing it without manuals, without metrics, often without even noticing. ### The second is understanding what a client actually wants Not what they say they want. What they actually want. Almost always two different things. A client asking for a document management system often doesn't want a document management system. They want their boss to stop asking where files are. A client asking for a mobile app wants to prove to the board that their division innovates. A public-administration client putting out a tender for a digital platform often needs something much simpler—but the tender was written by copying one from another municipality with completely different needs. My job is to dig under the request until I find the need. **And the need is almost always political, organisational, emotional. Rarely technical.** You get there by asking questions that have nothing to do with technology. Who will use this system? Who decided it was needed? What happens if we don't do it? Who gains and who loses? These are questions an AI doesn't ask, because it doesn't know if and when they should be asked. Maybe that's the part that worries me most. It isn't that the machine answers badly. It's that it answers well to a question that maybe no one should have asked that way. ### The third is weighing context that isn't written anywhere Every product has a story. Not the one written in the documentation, which is the official version. The real story is made of compromises accepted because the budget ran out, of features added to please a stakeholder who later changed roles, of choices that were wrong but are now so entangled with the client's processes that removing them would cost more than living with them. When I have to decide whether the next release should rewrite a module or add a feature, I can't ask a model. Because the right answer depends on who uses that module, how they use it, what was happening on the project when it was built, what the current relationship with the client is, and whether that client will still have budget for phase two in three months. An AI can tell you what the ideal roadmap is in the abstract. A product leader knows what the right roadmap is *for that product, with that team, for that client, at this moment*. The difference between the two is the difference between a recipe book and a cook. ### The fourth is saying no It's the most important and the least technical of all. Saying no to a feature that looks reasonable but will lead the product into a dead end. Saying no to a client who wants an impossible timeline, knowing you'll lose the contract. Saying no to a stakeholder pushing for a fascinating pivot that would destroy two years of accumulated value. Saying no to yourself when enthusiasm for a new idea is making you lose sight of the fact that your users need something that works, not something innovative. **No is an act of judgement that requires courage, context, and responsibility.** AI never says no. It can't afford to. Its design is optimised to be helpful, to give answers, to resolve. But sometimes the most useful thing is to stop. Sometimes the best answer is "we don't do it". And no prompt in the world can teach a model when that moment has come, because recognising it requires something no training set contains: *the weight of consequences on your own shoulders*. ## The amplification paradox {: #the-amplification-paradox } To be clear, I'm not saying AI is useless. That would be dishonest as well as stupid. I use it every day. My team uses it to produce, document, analyse. We save hours, days, weeks, months. Deliverable quality has gone up. I wouldn't go back. But there's a paradox I see emerging that worries me. **The more AI handles the "producible" parts of the craft—documents, analyses, specs, code—the more value concentrates in the "imponderable" parts: decisions, relationships, the no's.** And those are exactly the parts you don't learn by reading documentation or taking courses. You learn them by failing, observing, sitting in a room with other people for years. The risk, I wonder, is that a generation of professionals grows up delegating the executable parts without ever passing through the phase where those parts teach you the craft. Writing a wrong proposal, running a demo that falls apart in front of the client, losing a contract because you underestimated a requirement—these aren't only training pain. They're the process through which you develop the intuition that later lets you make the decisions AI can't. Skip that step and you arrive at the negotiation table without ever having felt the weight of a wrong choice. At that table, AI can't help you. ## The craft that remains {: #the-craft-that-remains } My craft is changing. It isn't disappearing, it's changing shape. The time I used to spend producing deliverables I now spend reasoning about what those deliverables should say. The time I used to spend looking for information I now spend deciding what to do with it. The time I used to spend on repetitive work I now spend talking to people—colleagues, clients, users. It's a shift up the value chain, and in some ways it's a liberation. But it carries a new responsibility, which is maybe an old responsibility seen with different eyes: don't confuse speed with competence. The fact that a tool helps me produce more doesn't mean I know more. It means I have more time to apply what I know, or to discover what I don't know, if I'm honest with myself. AI knows what was written. My craft is knowing what wasn't written, and often what can't be written. As long as that's the case—and I suspect it'll be the case for a long time—the craft remains. It changes shape, changes pace, changes tools. But it remains. What AI doesn't know about my craft is, in the end, what makes it a craft and not an algorithm. --- # Europe Says Enough: Your Brain Is Not a KPI - **URL:** https://margiovanni.it/en/blog/europe-says-enough-your-brain-is-not-a-kpi/ - **Published:** 2026-02-21 - **Tags:** Attention, Digital Services Act, Digital Regulation, Social Media - **Reading time:** 9 min > The DSA targets TikTok's infinite scroll and the "autopilot" of attention. Meanwhile in the U.S., Meta goes on trial. Design becomes politics. There's a gesture all of us perform, hundreds of times a day, without thinking. It might be the most repeated gesture of our era—more than walking, more than drinking water "mindfully". The thumb scrolling up on a screen. One scroll. Another. Another. On 6 February 2026, the European Commission did something that, the way I read it, marks a before and after. It didn't say "this content is forbidden". It didn't ask anyone to take down a hashtag or remove a video. It put an *interaction pattern* in question. A design choice. According to preliminary findings under the Digital Services Act, TikTok's infinite scroll pushes users into "autopilot mode", feeding compulsive behaviour. So, Brussels says, the platform has to change the basic design of the service: disable infinite scroll, introduce mandatory pauses, rethink the recommendation system. If it doesn't, the fine can reach 6% of global annual revenue. For ByteDance, that's tens of billions—the kind of number that makes wrists tremble. Two weeks later, on the other side of the ocean, Mark Zuckerberg is sitting in a Los Angeles courtroom. It's the first jury trial on social media addiction in U.S. history. A young woman, identified as K.G.M., describes being pulled into Instagram as a child and developing depression and suicidal ideation. In the background sit more than 1,600 similar lawsuits. The lawyers display Meta's internal emails. One sentence sticks: "IG is a drug. We are pushing users." Another email suggests the company knew that more than 30% of children aged 10 to 12 used Instagram, breaking its own policies. Zuckerberg replies that the goal is to make the service "useful", not to maximise time on platform. Meanwhile the judge warns the audience not to record proceedings with AI glasses—some members of Zuckerberg's entourage, apparently, had shown up wearing Ray-Ban Metas. Two continents. Two approaches. The same problem. ## Design is politics {: #design-is-politics } It's worth pausing on what happened on 6 February, because it's more radical than it looks. Europe didn't regulate content. **It said that the *form itself* of the interaction between a person and an app can constitute a systemic risk.** That a thumb movement, if designed never to end, isn't "your weakness". It's the platform's problem. This is, in fact, the first time a regulator has tried to set a legal standard on the addictive potential of design. It isn't a law "against infinite scroll" in the abstract. It's a larger principle: addictive design is a risk, and infinite scroll is one of its most visible manifestations. The interesting part—and the slightly unsettling one—is that the principle doesn't stop at TikTok. Meta has been under investigation since May 2024 for similar reasons. The famous "rabbit hole", the tunnel you enter watching one piece of content while the algorithm pushes you toward more and more similar—and sometimes more extreme—content, is in the crosshairs. X has already taken a €120 million fine for "deceptive design practices". The EU's approach looks more and more like this: not just "what you can't show", but "how you can't make people feel". For people who build software, the ground really does shift here. **Code has never been neutral, we know that, but now it's officially also a question of legal liability.** The Product Liability Directive coming into force on 9 December 2026 includes software among products. The Cyber Resilience Act demands security by design. The AI Act imposes risk assessments. And now the DSA suggests that even the way you organise a feed can become a violation. A simple image comes to mind: the door handle that won't let you out. It isn't a problem with the person trying to leave. It's a problem with the handle. ## The quarterly vs. the neuron {: #the-quarterly-vs-the-neuron } The question, though, remains. Why did we get this far? Why do we need courts and commissions to say something anyone with a child—or just a thumb—already senses? One answer, maybe, is in the internal documents emerging from the U.S. trials. It doesn't look like negligence. It looks like a deliberate choice, repeated, driven by a metric: engagement. And engagement, in the end, is the antechamber of the quarterly. Those documents show that increasing time spent on platforms and growing among teens wasn't a side effect. It was a goal. Emails from 2015 and 2017 discuss how to prioritise growth among adolescents. Internal studies record some teenagers describing Instagram with words very close to behavioural addiction. And still no one stops. The measuring continues. Adam Mosseri, head of Instagram, testified that in his view it's not "clinical addiction" but "problematic use". Maybe the distinction matters in a courtroom. In real life, I wonder how much it changes. The point, in any case, is that they knew. They knew that certain face filters simulating plastic surgery could affect adolescent girls, and after internal debate they chose a "more targeted ban" rather than a complete one. They knew the parental controls were easy to bypass, and they presented them as a solution. They knew children under 13 were on the platform by the millions, and they kept counting them as users. Here an economic concept comes in that I find useful, even if it's a little frightening how well it fits. It's called externality: a cost the producer offloads onto society without paying for it. Pollution is the classic example: the factory produces, the river pays. With social media we've had a new form of externality for twenty years. We could call it, without exaggeration, **the attention externality**: the cost society pays when a company extracts attention the way a mine extracts coal, without compensating for the damage. Lungs become neurons. Air becomes time. The river becomes someone's childhood. **And the difference from industrial pollution, perhaps, is this: here the harm isn't only a side effect. In many cases it was *designed*. It isn't the production's waste. It's the product.** ## Autopilot and dignity {: #autopilot-and-dignity } In the European findings there's an expression that stuck with me: "autopilot mode". Certain features, the Commission writes, shift users' brains into autopilot, feeding the impulse to keep scrolling. Scientific research, they add, shows that these mechanisms can reduce self-control and contribute to compulsive behaviour. Autopilot is a strange word, because in other contexts it's almost positive. In aviation it makes sense: it frees cognitive resources for more important decisions. In a social media app, on the other hand, it removes the most important cognitive resource we have at that moment: the ability to choose when to stop. Byung-Chul Han described contemporary malaise well by talking about the achievement society and self-exploitation. The idea, simplified, is that today no external master is needed. We squeeze ourselves: we optimise, perform, consume, until burnout. And the smartphone is the perfect instrument for it. But there's another step the TikTok-DSA case makes more visible. Self-exploitation isn't always self-generated. Sometimes it's *designed* by someone else and then sold as freedom. Infinite scroll isn't the user's decision. It's a decision by a product team, validated by an A/B test, approved by a VP of Growth, celebrated in a quarterly business review. The user isn't self-exploiting. They're being exploited inside an architecture that simulates choice. And here, if you want, you could even bring in Kant without going full salon-philosophy. Treat people as ends, never only as means. The user-as-KPI is the user-as-means promoted to a business model. You aren't a person using a service. **You're a unit of attention to extract, an eye to monetise, a thumb to keep moving.** Maybe that's why what Europe is doing feels, underneath, like a defence of dignity. Not just consumer protection. The idea that we have a right not to be manipulated, even when the manipulation is elegant, well-designed, and packaged in a colourful interface with rounded corners. ## Two models of the world {: #two-models-of-the-world } The contrast between Brussels and Los Angeles tells two different philosophies. In the United States the system is adversarial. A family takes a company to court, presents documents, witnesses, expert reports. A jury decides whether Instagram was a "substantial factor" in the harm of one specific person. It's a case-by-case model, where the burden of proof falls mostly on whoever was harmed. And in that context everything becomes ambiguous. YouTube, in the same lawsuit, tries to defend itself by saying it's more like Netflix than a social platform. Meta says the problem isn't the app, it's the content—or maybe it's the girl's personal life. The lines between "platform harm" and "content harm" are hard to draw. People argue over the definition of "addiction". They postpone. They negotiate. **In Europe the approach is more structural. You don't wait for the harm, you regulate the design.** You don't ask the individual to prove that infinite scroll ruined their life. You ask the platform to prove its design isn't intrinsically risky. The DSA treats addictive design as a systemic risk on a par with disinformation or election interference. It's an asymmetry that reflects two ideas of freedom. In the United States, often, freedom is absence of constraint: you're free to use TikTok or not, and if it hurts you that's your problem—or your lawyer's. In Europe, at least in this framing, freedom includes protection from manipulation: you're free only if the conditions you operate in aren't designed to strip you of the ability to choose. Neither model is perfect. But one of them, today, is trying to change the game before millions of people have to walk into a courtroom and recount their childhood in front of a jury. ## The question for builders {: #the-question-for-builders } I build software. Every day decisions get made that look small and aren't. Where to put a button. How to structure a notification. How easy or hard to make leaving a flow. Whether to show a counter, a badge, a red dot. I don't build social media. I work on platforms for public administration, e-learning, B2B services, legal tools. My world is a thousand kilometres from infinite scroll. And yet the principle Europe is trying to fix sounds universal: design isn't neutral. Every interface choice is also an ethical choice. And now, like it or not, also a choice with legal consequences. For years the social platforms enjoyed a kind of de facto impunity, because regulation couldn't keep pace. That time looks over. The DSA, the Product Liability Directive, the Cyber Resilience Act, the AI Act are pieces of a mosaic redrawing the relationship between those who produce technology and those who use it. Those who endure it, you might say, after reading certain internal emails. In the end, a conviction stays with me, and it probably gets stronger every time I see a product "grow" thanks to a cognitive trick: software that respects the people using it is better software. **Not because Europe imposes it on us, but because it's the right thing to do.** **And maybe the most radical thing today is to do something radically obvious. Build technology that doesn't need a court to order it to stop doing harm.** Infinite scroll will end, in one form or another. The real question is what we put in its place. If it's just another trick to keep you glued, with a different name and a slightly subtler mechanism, we won't have solved anything. If instead it's a design that starts from the question "what does this person need?" rather than "how do I keep them here one more minute?", then maybe 6 February 2026 will be a date worth remembering. Not for the scroll it called into question, but for the question it made unavoidable. --- # Signs of a Digitalisation Project Headed for a Stall - **URL:** https://margiovanni.it/en/blog/signs-of-a-digitalisation-project-headed-for-a-stall/ - **Published:** 2026-02-21 - **Tags:** Digitalisation, SME, Product Management, Digital Transformation - **Reading time:** 6 min > Five early signs that often precede failure: an absent sponsor, vague goals, confused decisions, an imposed stack, and useless KPIs. There's a meeting that comes back to me now and then, and not because it was particularly dramatic. The opposite—it had gone perfectly. Polished slides, the right words, that "this time we mean it" tone. We were talking about transformation, operational efficiency, the future. Everyone was nodding. The budget was approved. Three months later, the project was gone. It isn't a rare story. 84% of Italian SMEs run into trouble executing digital projects, and 15.8% report a complete failure. Globally the music is similar: roughly 84% of digital transformation initiatives don't reach their expected results, often for reasons that have little to do with technology. The point, though, isn't only that projects fail. It's that some projects *are born dead*. The signs are there from the start, only they're discreet, almost polite. And if you don't know where to look, you mistake them for ordinary complexity. ## The sponsor who "supports from a distance" {: #the-sponsor-who-supports-from-a-distance } The first sign is the one that looks least serious. On paper, the project has an important sponsor: founder, CEO, someone "putting their face on it". Then you never see that face. The sponsor delegates, sends an endorsement email, maybe opens the kickoff with a five-minute motivational talk. And then disappears from the operational meetings, the ones where the real knots get untied. The result is fairly predictable: the moment the first internal resistance shows up, the resistance wins. Not because it's stronger, but because it's more patient. In many SMEs the resistance isn't even malicious. It's routine, urgency, "let's close the month first", "we'll talk after the trade fair", "we can't stop the warehouse right now". If the sponsor isn't there when choices need to be made, the implicit message is simple: > This project can wait. **And things that can wait, wait forever.** It isn't only a feeling. 56% of digital transformation projects don't get real support from senior leadership. ## Goals written by copy-paste {: #goals-written-by-copy-paste } "Improve efficiency". "Optimise processes". "Increase digital competitiveness". When I read goals like that, I always wonder: are they describing something they actually want to do, or are they just looking for a phrase that sounds right in a document? The problem isn't that they're false. It's that they're not verifiable. They don't help you understand, six months in, whether the project worked. And they especially don't help you decide what to do tomorrow morning. A line like "reduce order fulfilment time by 30% within six months" changes everything. It forces you to pick a scope, find a baseline, understand where to act. "Digitalise the company's processes" is a fog. Everything fits inside it, which means nothing does. Not surprising that 64% of digitalisation projects start without a clear roadmap. The main cause might be exactly this difficulty in turning generic ambition into measurable goals. And there's a slightly toxic side effect: vagueness makes it easy to declare success without having achieved much. You just have to tell the story well. ## No one knows who decides {: #no-one-knows-who-decides } This sign is sneaky, because at the start it looks like collaboration. Lots of people involved, lots of departments invited, lots of opinions gathered. Then, when a real decision arrives, no one knows who has the final word. Who approves the technology choices? Who resolves the conflict between sales and operations? Who decides whether to accept a scope change proposed by the vendor? Who says "OK, we do it this way" when both alternatives are inconvenient? If there's no clear answer, something I've seen recur often happens: decisions don't get denied, they get postponed. They turn into email loops, meetings that end with "we'll sync up", shared documents full of comments. And the project doesn't collapse spectacularly. It dissolves. A little at a time. The literature is less romantic than we'd like: effective governance requires an internal owner who can coordinate technology choices, vendor relationships, and outcome monitoring. Without one, the project drifts. ## The stack picked by the vendor {: #the-stack-picked-by-the-vendor } This is the one that makes me most uncomfortable, maybe because it's the hardest to recognise when you're inside the company. The vendor arrives with a ready-made solution. It might even be a good solution, in its own context. But they propose it as the natural answer to the company's problems, and the company accepts because it hasn't done a real needs analysis. Sometimes it happens out of haste. Sometimes because "they've been doing this for years, they'll know what's needed". Sometimes because no one internally has the skills or the time to question the proposal. The result tends to be the same: an expensive technology gets bought that doesn't fit existing processes, or upends them in ways the organisation isn't ready to absorb. The right sequence would be banal, yet it's extremely rare: first you understand what you want to solve, then you pick the technology. When the stack has already been decided before the first strategic meeting, something is off. ## KPIs that can't be measured {: #kpis-that-cant-be-measured } The last sign often shows up when time, energy, and reputation have already been spent. The KPIs get defined. Everyone is happy because "at least we're measuring". Then no one asks a very simple question: does the data to measure them exist? "Customer satisfaction improvement" is a KPI only if you have a consistent way to measure satisfaction before and after. "Operational cost reduction" works only if you know which costs you're tracking, and you track them cleanly. When KPIs get defined to reassure the budget approver and not to steer the project, they become elastic numbers. And if a number can be interpreted a thousand ways, it will never plainly say the project is failing. There's an interesting point here: sometimes measuring becomes a kind of theatre—a practice that looks serious but doesn't change decisions. ## The PO: the role no one called {: #the-po-the-role-no-one-called } If you think about it, all five of these signs share something. They aren't technical problems. They're problems of clarity, accountability, communication. And there's a role that, in theory, was created precisely to govern that kind of chaos: the product owner. In an SME, often no one has time for the "boring" part of the project. The part made of repeated questions, definitions, boundaries, priorities. And yet that's exactly where it's decided whether a project really starts. A PO doesn't accept "improve efficiency" as an answer. They insist, sometimes too much. Which process? Which metric? From when to when? Who's putting their hands on it? What changes for the people who today do that work a certain way? On the weak-sponsor problem, the PO can't replace leadership—it would be naive to think otherwise. But they can make leadership more effective. They can prepare decisions that force the sponsor to choose between concrete options, instead of nodding along to vague presentations. In practice, they reduce the cognitive friction for the person who's supposed to lead and often doesn't know where to start. On governance, the PO brings structure almost by definition. They manage priorities, make explicit what's in and what's out, keep track of commitments. They don't eliminate internal politics, but they make it visible—and that alone sometimes changes the game. On vendors, perhaps it's the most valuable function. The PO sits in front of the vendor not as a naive customer but as an interlocutor who understands what they're buying. They can tell a proposal built around the company's needs from one built around the vendor's catalogue. I wonder whether the real problem is that in Italian SMEs this role is still seen as a luxury—something for big companies or funded startups. I have the opposite impression. Where resources are limited and mistakes are expensive, having someone who asks the right questions at the start is worth as much as not throwing six months away on a project that, fundamentally, wasn't going to ship anyway. And maybe the most useful question, before picking software at all, is this: who takes responsibility for making the project real, day after day? If there isn't a credible answer, maybe better to stop there. Not out of cynicism, but out of respect for everyone's time. --- # Three Minutes vs. a Year: Universities and AI Out of Sync - **URL:** https://margiovanni.it/en/blog/three-minutes-vs-a-year-universities-and-ai-out-of-sync/ - **Published:** 2026-02-20 - **Tags:** Training, AI, Work, Universities - **Reading time:** 10 min > A three-minute demo replicated a year-long university project. A reflection on time, skills, and the risk that education becomes irrelevant. Three minutes. It isn't a metaphor or a figure of speech. Three real, measurable minutes—the kind that pass while in a classroom someone coughs, someone takes notes, someone checks the time. During a seminar on generative AI in business, at the university, I opened Claude Cowork and gave it three CSV files of e-commerce data and a brief of a few lines. Sales, customers, marketing. Then I asked for something very "course-style": segmentation, KPIs, ROAS by channel, charts, and a strategic report with budget recommendations. In three minutes the AI did the analysis, built an RFM segmentation, calculated return on ad spend, produced interactive visualisations, and wrote a report that, at first glance, looked complete. Not perfect, no. Not ready to be presented to a board without a serious review. But it was exactly the kind of deliverable that often gets requested as a final project. The kind of thing a university course schedules over a year. I'm not writing this to belittle students or teachers. I'm writing it because that scene forced me to look in the face something that, if I'm honest, I'd rather not see: the silent divergence between the speed of technology and the speed of institutions. ## Two clocks ticking different times {: #two-clocks-ticking-different-times } The university is designed to move slowly. And it isn't necessarily a defect, on the contrary. It's how it guarantees quality: committees, accreditations, panels, reviews, consensus. It's almost in the DNA of these institutions not to run. The problem is that outside the classroom, in the meantime, the world isn't just running. It's changing shoes every two kilometres. A university curriculum often takes 12–24 months to be designed, approved, and implemented. Courses get planned far in advance. Textbooks have long editorial cycles, and even when they're excellent, they arrive in a world that has already moved on. Innovation, by contrast, thinks in releases. AI coding tools went from "curiosity" to industrial standard in a few months. AI agents complete work that previously took weeks. Startups founded by recent graduates reach huge valuations in timeframes that no longer resemble old industrial cycles. So we end up with two clocks in the same room. One ticks semesters and study plans. The other ticks deploys, updates, new models, new interfaces. The distance between the two isn't only organisational. It's becoming cultural. ## The half-life of skills: from decades to months {: #the-half-life-of-skills-from-decades-to-months } There's a concept that comes up often when we talk about work and technology: the *half-life* of skills. The time after which half of what you learned becomes obsolete or irrelevant. Forty years ago that could be a decade. Today, for many technical skills, it's around 2.5 years. And yet you don't even need to ask whether 2.5 years are a geological era when we talk about AI and software development. AI assistants for coding went from experiment to widespread presence in a very short time. Anyone who learned to program in 2022 without touching AI coding tools today finds themselves working with a piece of the toolkit missing. Global estimates put even sharper numbers on the picture: by 2030, 39% of key skills required in the labour market will change. And 59% of the global workforce will need reskilling or upskilling. Now take a bachelor's degree: three years. Add a master's: another two. Five years. In the same span a student takes to complete the path, an enormous part of what the market considers "key" will have changed. And here the question stops being theoretical. It becomes almost intimate: what are we promising the young people enrolling at university? ## Entering the workforce is a wall, not a door {: #entering-the-workforce-is-a-wall-not-a-door } If it were just a content misalignment, we could discuss it calmly. The problem is that the entry-level numbers tell a harder story. In recent years, entry-level hiring at many large tech companies has dropped sharply. In several markets we're seeing major reductions, and in Europe in 2024 many tech positions for graduates fell significantly, with prospects that aren't exactly rosy. Then there are layoffs openly framed as "AI-enabled". Companies cutting corporate roles because AI allows leaner structures. Some have publicly said AI now handles a huge share of the work. And while this happens, among young people a feeling grows that you sense even without surveys: the idea that the market has become more closed, more selective, harder to cross. Almost half of young job seekers believe AI has reduced the value of their university education. It isn't science fiction. It's the present. And when the present knocks at your door, you can't keep postponing the conversation. ## The entry-level paradox: when AI eats the first rung {: #the-entry-level-paradox-when-ai-eats-the-first-rung } There's a detail that makes everything more insidious. The implicit entry-level pact, for years, was this: you do repetitive work, you cut your teeth, you learn. In exchange you get mentorship, context, growth. That repetitive work is exactly what AI absorbs best. So the first rung of the ladder disappears. This is the part that worries me most, because it's a "transmission" problem of skills. If you don't hire juniors today, who becomes senior tomorrow? Someone described this choice as "eating the seed corn". You save now, you pay later, and you pay with interest. Meanwhile the university risks a vicious circle: training people for entry-level roles that are shrinking, using curricula that can become old before even reaching cruising speed. The 2026 graduate comes out with 2023 knowledge on average, because that's the year the curriculum was designed, for a market that has since gone through two or three revolutions. ## Three minutes vs. a year, and what I saw in students' eyes {: #three-minutes-vs-a-year-and-what-i-saw-in-students-eyes } Back to that demo, because there—more than in the charts—was the emotional part. The brief was a few lines. Three CSVs attached. Zero configuration. In three minutes the AI produced aggregated metrics, segmentation, ROAS, visualisations, recommendations. Again: it wasn't perfect. But it was good enough to set off a silent question. And the question, in the classroom, showed in the eyes. I didn't see panic. I saw concentration. I saw that form of attention that arrives when you understand the ground under your feet is really moving. I don't know why, but that gave me hope. Maybe because it seemed the students weren't pretending. They were looking. And maybe that's where the move starts: from not pretending. Because the message, in the end, was clear. The "what" you learn is becoming less important than "how" you learn to learn. ## Italy: goodwill, geological timeframes {: #italy-goodwill-geological-timeframes } In Italy we aren't standing still. It would be unfair to say so. In recent years AI training offerings have grown, with new degree courses, master's programs, contamination with other disciplines, advanced training in specific fields. There are national strategies, university-business collaborations, e-learning platforms. These are important steps. But there's a big "but": they move at institutional speed. Tenders, committees, collegial bodies. Meanwhile outside, things move at deployment speed. When a course gets activated after years (or even months) of process, the tools it teaches risk having already changed twice. Not because the course is poorly designed. Because time has become the adversary. And here the divergence hurts most, because it isn't a question of incompetence. It's a question of architecture. Universities guarantee quality through slowness. Technology guarantees relevance through speed. For years these two logics coexisted. Now they're starting to clash. ## What we're teaching, and what maybe we should be teaching {: #what-were-teaching-and-what-maybe-we-should-be-teaching } The skills growing fastest in the coming years are a strange and beautiful mix. On one side AI and big data, cybersecurity, technological literacy. On the other creative thinking, resilience, flexibility, curiosity, lifelong learning, leadership. Technical and deeply human together. So I wonder if the point isn't exactly this. Teaching a tool isn't enough. You have to teach how to think, adapt, communicate, decide under uncertainty. Because tools change. And they change fast. There's also a phenomenon I think we're reading wrong: the widespread dependence of students on AI. We often call it laziness. Sometimes it is, of course. But sometimes it's a signal. Students sense when they're being asked to invest energy in skills that look irrelevant or already obsolete. And they look for shortcuts because, from their point of view, the game isn't worth the candle. Universities (and schools) responding by banning AI are fighting a lost war. Those that integrate it superficially risk doing something else: **normalising the use without really changing the goal.** Maybe what's needed is a more radical rethink of what "competence" means in 2026. ## The end of the static curriculum {: #the-end-of-the-static-curriculum } I don't presume to have definitive solutions. The more I think about it, the more it seems a problem full of real trade-offs. But some directions, at least, are visible. The first is modularity. Abandon the idea of the monolithic multi-year curriculum and shift toward short, updateable, composable modules. Micro-credentials that get refreshed every semester. It isn't a "modern" whim. It's a way to realign education to a world that doesn't wait. The second is bringing real problems inside, not exercises. The difference is simple: an exercise has a known solution; a real problem doesn't. AI is excellent with known solutions, and that's exactly why it makes many traditional projects obsolete. What stays hard is choosing the right question, managing ambiguity, negotiating with stakeholders, understanding when a piece of data is "correct" but out of context. The third is treating AI as environment, not as subject. Not an isolated course, but a transversal presence, the way the calculator didn't kill mathematics but changed what "knowing maths" means. AI probably won't kill education, but it'll change what being competent means. Then there are operational collaborations with companies. Not partnerships that produce a paper in three years, but shared work on real problems, with the same tools, in the same timeframe. It's complex, I know. But it's also one of the few ways to recover time. Finally, teaching how to learn. It sounds like a poster slogan, but today it's almost the only future-proof thing—and maybe the one the university has lost over the last 30 years. Metacognition, critical thinking, the ability to evaluate new tools, to integrate them without becoming dependent on them. ## The real danger isn't AI, it's irrelevance {: #the-real-danger-isnt-ai-its-irrelevance } If the academy is perceived as too slow, too expensive, out of time, the risk is that people start bypassing it. Not out of malice, but out of necessity. And here comes the most uncomfortable question, the one I fear many students are already asking themselves. When you discover you can get in three minutes with an AI assistant what your course taught you to do in a year, you don't think "great, I have solid foundations". You think: why did I invest three years of my life and thousands of euros? The answer exists, and it's a good answer. The value of university shouldn't be the transfer of pointwise skills. It should be a mental framework, critical thinking, the capacity to argue, **the network of relationships**, exposure to different disciplines, personal maturation. But if the curriculum is built as if the main value were "learn how to make a dashboard", that answer sounds hollow. And it hurts to say, because behind many courses there's real dedication. ## The urgency to act, without panic {: #the-urgency-to-act-without-panic } Globally we invest very little, in proportion, in adult lifelong learning. And yet increasing that investment could generate enormous value by 2030. It isn't only an educational problem. It's economic. It's social. Universities have an advantage no AI platform has: they can teach how to think critically, how to collaborate deeply, how to navigate ethical ambiguity. But only if they stop competing on terrain where AI wins—the transmission of information and the execution of structured tasks—and concentrate on what makes them irreplaceable. The time for this transition isn't "the next few years". It's now. Every semester that passes with unchanged curricula is a semester of students coming out less prepared than they could be. The speed of AI won't slow down to wait for educational committees. That three-minute demo wasn't a provocation. It was a mirror. And the thing that struck me most wasn't the speed of AI. It was the slowness of everything else. --- # Software Is a Product. Now What? - **URL:** https://margiovanni.it/en/blog/software-is-a-product-now-what/ - **Published:** 2026-02-18 - **Tags:** Compliance, Cybersecurity, Digital Law, Software Development - **Reading time:** 10 min > From 9 December 2026, the new EU Product Liability Directive treats software as a product. What changes for roadmaps, contracts, releases, and open source. ## A change of word that changes everything {: #a-change-of-word-that-changes-everything } For years I had the feeling software lived inside a bubble. Not in the romantic sense—more like a comfortable, almost protective grey zone. If a physical product hurt someone, the question of liability was immediate and concrete. If it was "just" software, the conversation slid into bugs, patches, workarounds, and that faintly indulgent shrug that said "it's normal, it gets updated". Directive 85/374/EEC on liability for defective products, after all, talked about movable goods, tangible stuff. Software, intangible by definition, didn't fit. And when a rule fits you badly, often it ends up not fitting at all. From 9 December 2026, with Directive (EU) 2024/2853, that ambiguity closes. The new Product Liability Directive (PLD) says explicitly that software *is* a product. Not just software embedded inside an object, but all of it: standalone, embedded, firmware, applications, cloud, SaaS, AI systems. Regardless of where it runs and how you ship it. This isn't a footnote. It's a paradigm shift, and maybe the most interesting thing is that it doesn't only concern the people writing code. It concerns whoever decides what to build, who sells it, who releases it, who maintains it, and who decides when to stop. ## Strict liability: where the perspective shifts {: #strict-liability-where-the-perspective-shifts } The PLD rests on a concept that's easy to underestimate in software until it lands on you: **strict liability**. In practice, anyone harmed by a defective product doesn't have to prove that *you* were negligent. They don't have to reconstruct your decision chain, don't have to show "you could have done better". They have to show three things: that the product was defective, that there was harm, and that there's a causal link. For people used to thinking in terms of "we did our best", "it was an edge case", "it was a third-party dependency", that's a meaningful mental shift. Diligence still matters, of course—but not as an automatic shield. And there's another piece that makes things even more concrete: the directive introduces *presumption* mechanisms. If proving the defect or causal link is "excessively difficult" for the harmed party—which, with complex software or AI systems, is almost the norm—the court can presume defectiveness and causation. It can also order the producer to disclose technical documentation, which has to be presented "accessibly and comprehensibly". Failure to cooperate can itself become a factor against you. Stated plainly: in many cases you'll find yourself having to prove the software *wasn't* defective. And to do that, you need evidence. Traces. Reasoned decisions. Data. ## Product side: liability starts long before the code {: #product-side-liability-starts-long-before-the-code } When liability comes up, the instinct is to look at development. But the PLD also puts product decisions under the lens—the choices that come before any code. Defectiveness is judged against *reasonable safety expectations*. A product is defective if it doesn't offer the level of safety a person is legitimately entitled to expect. That judgement depends on how you present the product, on reasonably foreseeable use, on the moment it was placed in service. But also on very contemporary elements: interconnection with other systems, conformity with cybersecurity requirements, even the capacity to learn. Here I think about how often a roadmap is born from trade-offs that look purely "business": ship faster, cut a security feature, postpone the hardening phase, integrate an AI component because it's cool and competitors already have one. Under the PLD, those aren't just product choices. They're choices that can become relevant in a legal challenge. If you promise a certain reliability or security standard in your commercial specs, you're creating an expectation. If you integrate an AI component that changes behaviour over time, you're taking responsibility for that future behaviour too. AI's unpredictability, the way the directive is written, isn't a defence. The most practical consequence, I think, is this: *risk assessment* enters product management. Not as a document you do once and forget, but as a habit. And documentation of decisions enters with it. Not for bureaucracy's sake, but because in a few years you may need to explain why a certain choice was reasonable *at that moment*. Architecture decision records, which many teams use today just to keep track of themselves, start to look like a piece of your defence. ## Sales side: the contract is no longer a shield {: #sales-side-the-contract-is-no-longer-a-shield } There's a conditioned reflex in software: if risk goes up, add a clause. Limitation of liability, cap, indemnity, disclaimers in the terms. The PLD is fairly brutal here: liability under the directive cannot be excluded or limited contractually when the harm concerns a natural person. That holds in B2C, and in practice it reaches B2B every time the end users are people. This doesn't make contracts useless. It means they have to change function. In B2B in particular, contracts need to clarify responsibility along the supply chain. If you develop for a customer who puts the product on the market under their own brand, who's the "manufacturer" under the PLD? If your software is a component inside a larger system, how is recourse handled between parties? You can't eliminate liability toward the outside world, but you can and should clarify what happens between you. Then there's a piece sales and marketing often underestimate: commercial promises. Demos, brochures, claims like "highest security standards", slides with "zero downtime", pricing pages that imply certain guarantees. All of this contributes to defining what the user was legitimately entitled to expect. So it indirectly enters the assessment of defectiveness. Finally, the insurance and pricing question. Classic professional liability insurance covers negligence, not necessarily strict liability. Many companies will likely have to revisit coverage and limits, including cybersecurity, data loss, and immaterial damages. That cost will end up in the price. With one interesting side effect: those who move well early can turn compliance into a credible competitive argument. ## Releases: every deploy now leaves traces {: #releases-every-deploy-now-leaves-traces } If you work in releases, DevOps, QA, or you're the person who finally says "OK, ship it", this is maybe the most concrete part. In modern software, release isn't the end. It's the beginning. Because almost always the producer keeps control through updates, remote access, feature flags, patches, security updates. The PLD, read alongside the regulatory context, makes a "ship and see" approach very risky. Failing to provide security updates for known vulnerabilities can itself be considered a defect. And an update that introduces a problem can be seen as a substantial modification, with downstream effects on terms. Base liability lasts 10 years, and for latent personal injuries it can reach 25. When I read those numbers I always wonder whether we really have a culture of preserving evidence over that horizon. Because doing things well isn't enough—you have to be able to show it. This is where traceability comes in. Knowing what a given version contained on a given date. Which dependencies. Which known vulnerabilities. Which tests ran. Who approved. What was decided and why. The SBOM (Software Bill of Materials) becomes central. The Cyber Resilience Act makes it mandatory in many cases anyway, and the CI/CD pipeline becomes, in effect, compliance infrastructure: automatic SBOM generation (CycloneDX or SPDX), vulnerability scanning, deploy audit trails, artifact retention. And there's a detail that sounds banal until you live it: the decision *not* to ship a patch is also a decision. If today you choose to postpone a fix for sensible reasons, fine—probably. But in five years you may have to explain why it was sensible. Better to have that explanation written while memory is fresh. ## Development: documentation isn't bureaucracy, it's defensible memory {: #development-documentation-isnt-bureaucracy-its-defensible-memory } For developers, the PLD doesn't ask for magic. It doesn't say "write perfect code", which doesn't exist. It asks, in essence, that the path be reconstructible. Automated tests that prove expected behaviour. Tracked code reviews. Integrated security scans. Commit messages that aren't "fix". Tickets that explain context. Many teams already do these things, perhaps unevenly. The difference is that they shift from "good practice" to a piece of legal protection too. The link with the Cyber Resilience Act is direct: if you're not compliant with requirements like secure-by-design, vulnerability management, and SBOM, that non-compliance can reinforce a defectiveness claim under the PLD. The rules no longer live in separate compartments. ## The myth of B2B as a free zone {: #the-myth-of-b2b-as-a-free-zone } I get the temptation: "we only sell to companies, so it doesn't apply to us". But take a moment to look at the actual users. Public administration software: citizens. HR systems: employees. E-learning: students. Parking systems: drivers. Healthcare: patients. In every case the customer is an organisation, but the impact lands on natural persons. On top of that, the PLD reasons by components. If you supply a module, an API, a microservice that ends up inside someone else's product, you can be considered manufacturer of the component. And then there's the extension of recoverable damages: destruction or corruption of data not used for professional purposes, with no minimum threshold and no cap. That shift hasn't been metabolised yet by many companies. ## Open source: protected, but not a loophole {: #open-source-protected-but-not-a-loophole } The directive excludes open source software developed or supplied outside a commercial activity. But if there's consideration—even in the form of personal data—the picture changes. And above all, if you integrate open source into a commercial product, liability for any defects falls on whoever integrates and places it on the market. That shifts the centre of gravity: it's no longer just a licence-compliance question. It becomes technical and legal risk management. Dependency choice, vetting processes, serious vulnerability management, and again SBOM. ## The PLD doesn't stand alone: an ecosystem that interlocks {: #the-pld-doesnt-stand-alone-an-ecosystem-that-interlocks } Looking at the European picture, the sense is that the EU is building a precise idea of "software as a product" and is supporting it from multiple sides. The PLD interlocks with the Cyber Resilience Act (cybersecurity by design, SBOM, vulnerability management), with the AI Act (which makes AI providers manufacturers for PLD purposes too), with the GDPR (data breaches and damages), with NIS2, with the GPSR, with the Representative Actions Directive for collective redress, and even with the European Accessibility Act. The point isn't to memorise all the acronyms. The point is that a gap in one area can propagate and reinforce litigation in another. Compliance becomes a system. ## Italian implementation: a choice to watch {: #italian-implementation-a-choice-to-watch } Italy has to transpose the PLD by 9 December 2026. Being a maximum-harmonisation directive, there isn't much room for "creative interpretation". But one important margin remains: the *state-of-the-art* defence. In essence, the state can decide whether to keep the principle that a manufacturer doesn't answer if the defect wasn't recognisable with the knowledge available at the time of placing on the market. Or it can drop it. This isn't a detail, and it's worth watching. Because it changes the risk profile, especially for complex software and AI scenarios. ## Not just risks: the part that can become an advantage {: #not-just-risks-the-part-that-can-become-an-advantage } If you read it all in catastrophe mode, the PLD looks like pure cost. More documentation, more processes, more insurance, more internal arguments. But there's another reading, and perhaps the more useful one if you have decisions to make now. The PLD creates a playing field where quality, security, and supply-chain transparency become measurable competitive advantages. No more "trust us"—instead, "we have processes and evidence that hold up to a formal request, and if needed, to a court". For software houses, arriving compliant before the deadline can become a strong argument with enterprise and public-sector buyers. For consulting and system integration, it opens enormous demand for skills that today—at least in the Italian SME landscape—aren't widespread. For product builders, it's an incentive to invest in things that, in the long run, actually make software better. ## A conclusion without triumphalism {: #a-conclusion-without-triumphalism } For forty years we got to think of software as something special. More flexible, more updatable, more forgivable. The PLD says that exceptionalism is over. Software is a product, with liability comparable to a machine, a medical device, a car. This doesn't only concern people who write code. It concerns roadmaps and trade-offs. It concerns contracts and commercial promises. It concerns release and support, and even end-of-life. The most sensible thing today, it seems to me, is to shift the question from "how do we protect ourselves" to "how do we make our way of working demonstrable". Because preparing isn't just legal patchwork. It's doing the job better, with more memory, more traceability, and less blind faith in the idea that "we'll sort it later". The question isn't whether to prepare. It's how fast. *Primary sources: Directive (EU) 2024/2853; Cyber Resilience Act (EU Regulation 2024/2847); analyses by Reed Smith, IBA, Fladgate, Taylor Wessing, Clyde & Co, DLA Piper, Hogan Lovells, ICLG, Covington.* --- # The Site Without a Site: A New Way to Think About the Web - **URL:** https://margiovanni.it/en/blog/the-site-without-a-site-a-new-way-to-think-about-the-web/ - **Published:** 2026-02-15 - **Tags:** Content, SEO, Technology, UX - **Reading time:** 18 min > Discover how to design websites built for bots, improving user experience and ranking. Reflections on SEO and clear content. The other day I was looking for a vendor for a fairly specific service. A trivial thing, in theory: understand what a company does, who it works for, roughly how much it costs, whether it has experience in my sector. I opened the first Google result and ended up in a maze. Full-screen cookie wall, then a banner with a 20% discount if I subscribe to the newsletter, then a live chat opening on its own asking if I need help, then an autoplay video with epic music telling the company's "vision" with words like "innovation", "excellence", "tailored 360-degree solutions". I scrolled for a good three minutes trying to understand concretely what they do. I couldn't. The site was beautiful, mind you. Smooth animations, careful typography, professional photography. But by the end of the visit I knew less than before. Then I did something I do more and more often. I took the URL of the site and fed it to Claude, asking: tell me who they are, what they do, who they work for, what their strengths are. The answer was bleak. Claude pulled out a handful of vague slogans, a few repeated keywords, no concrete cases, no numbers, no information that would let you form a judgement. The site was excellent at making a distracted human click, terrible at letting a machine understand what the hell that company does and whether it's reliable. And there I stopped to think. Because if I, a professional in the field, am doing this operation more and more often—if I use an LLM as a first filter to decide whether to dig further—how many other people are starting to do the same? And above all: how many decisions are already being made by automated systems reading your site instead of a human being? The question that drives all this thinking is one, and I've been carrying it around for weeks: what if the next site shouldn't be designed for the user looking at the screen anymore, but for the visitor who has no eyes? I say "the visitor who has no eyes" and I realise it sounds like a provocation. But it isn't, or at least not only. The first reader of your site today is a Google crawler. The second is an agent composing answers for someone who asked a question. The third is an LLM that has to summarise who you are, what you do, why it should trust you. Only after, maybe, comes the human. And that human, more and more often, arrives already with an opinion formed by what the machine told them. If the machine didn't understand anything about you, the human won't even get to see the site. I'm not talking about SEO. SEO is part of the conversation, sure, but it's a part we know by now and that has become almost a commodity. I'm talking about something different: machines that have to build a mental model of your company. Not a ranking, not a position in a SERP. A mental model. Understand who you are, what you actually do, who you do it for, with what results, with what limits. It's an enormous difference. An SEO crawler looks for keywords and structure. An LLM looks for meaning, coherence, credibility. And if your site is a monument to emotional design but a desert of real content, that mental model will be empty. Or worse, it'll be wrong. I realise that to get here I have to first explain how the web "for humans" broke. Because it isn't that one day someone decided to build incomprehensible sites. It happened gradually, decision after decision, layer after layer, until creating a monster no one consciously designed. It started with cookie banners, and that was fine. Then came the newsletter pop-ups. Then push notifications. Then live chats. Then autoplay videos. Then mobile-app interstitials. Then discount banners. Every single element had its reason, its business case, its A/B test that proved a 3% increase in some metric. But the sum of all those 3% increases produced an experience that became, for many sites, genuinely hostile. Not only for machines. Also for humans, if we're honest. But for machines particularly, because all that visual and interactive noise isn't simply annoying—it's opaque. An LLM can't close a pop-up. It can't scroll past a video. It can't click "No thanks" on the newsletter. It sees the page's source code, and that source code has become a battlefield where real content is buried under layers of JavaScript, tracking, dynamic components, lazily loaded content. Then there's the "conversion design" problem, and here I touch a raw nerve because I know that world well, I've worked in it. Every pixel optimised for micro-conversion. Every sentence designed to generate a click, not to explain something. Every page structured as a funnel pushing you toward an action, not as a document helping you understand. The result is that many corporate sites have become lead-capture machines but stopped being information sources. And when an LLM reads a page that's essentially a long contact form with some slogans around it, what should it understand? That the company makes "innovative solutions"? That it's "industry leader"? That it offers "tailored services"? They're phrases that mean literally nothing. No reasonable human would take them seriously, let alone a model trained on billions of texts. Then there's the technical side, what I see from my vantage point as someone moving between code and strategy. Heavy single-page applications, with all content generated client-side via JavaScript. Texts appearing only after three interactions. Crucial information hidden in accordions no crawler expands. Duplicated landing pages with micro-variations for each campaign, creating insane semantic noise. Menus with twelve items pointing to pages with five paragraphs of pure filler each. As a product owner, as a head of tech, as someone who every day mediates between business vision and technological reality, I see the paradox clearly. We built sites increasingly sophisticated from the perspective of human interaction, and in doing so we made them increasingly incomprehensible to the machines that are becoming our main intermediaries with the public. It's like having built a beautiful shop but walled up the main entrance, forcing customers to go through a side alley full of obstacles. And here I get to the concept that has been turning in my head for a while, and that I call, with some self-irony, the "site without a site". It isn't a provocation for its own sake. It's an alternative model of information architecture that, the more I think about it, the more it seems the only sensible one for what's coming. The idea is simple in formulation: a coherent set of contents exposed to the web as if they were an API for humans and machines, with a minimal or even optional presentation layer. The keyword is "optional". I'm not saying you don't need a website. I'm saying the website should be the last layer, not the first. First comes information, structured, clear, complete. Then, on top, you put graphics, experience, brand. It's a total reversal compared to how sites get built today. Today you start from design, experience, "wow factor". You write the texts after, often in a hurry, often delegated to someone who doesn't know the company, often copied from competitors. Content is filler for a container designed before anyone knew what would go in it. The "site without a site" starts from the other side. First you design the information graph. Who we are, what we do, for whom, with what results, with what processes, at what price, with what limits, with what evidence. You put it all down in simple, readable, textual format. You organise it so it makes sense even without a single line of CSS. Then, possibly, you build on top a presentation layer that makes everything more pleasant for a human to navigate. But that layer is a dress, not the body. The parallel that comes to mind is technical documentation. Well-built open source projects have documentation that's readable in plain text, in a terminal, in a README on GitHub. You can also make it prettier with a dedicated site, sure. But the substance is there before the dress. The "site without a site" is treating the entire corporate site as documentation. Not as a sales pitch, not as an interactive brochure, not as an emotional experience. As documentation. Clear, complete, navigable, comprehensible to anyone, human or machine. I write these words and already feel the objections coming. But I'll get to them in a moment, because first I want to push the metaphor all the way. If the site is documentation, then content is data. Not data in the technical sense of database tables, but in the sense that every piece of information is an object with clear properties. A service has a name, a description, a target audience, a process, a price, limits, success cases. A case study has a client, a problem, a solution, measurable results. A team member has a role, skills, an experience. If you structure content this way, something interesting happens: it becomes reusable. The same content that feeds the website can feed a chatbot, a commercial PDF, a tender response, an LLM prompt, a marketplace listing. It's native multichannel, not multichannel forced after the fact. And the way of writing changes too. When you know your text will be read by a machine trying to build a mental model of your company, you stop writing slogans and start writing answers. Answers to precise questions: who is this service for? How does it work? How much does it cost? What does it include and what doesn't it? What results have you achieved? What are your limits? That last question is the most powerful, and almost no one includes it on their site. Saying what you *don't* do is incredibly precious information, both for a human evaluating whether to contact you and for an LLM deciding whether to recommend you. ## **How I'd actually build it** {: #how-id-actually-build-it } If I had to do it tomorrow for a client, and I've thought about it a lot, I'd start from three layers. The first is a pure knowledge base. Content in markdown, organised by entity. A folder for the company with history, values, team. One for services, with a card for each one always structured the same way. One for case studies. One for processes. One for FAQs—the real ones, not the marketing-invented ones. One for policies. All in plain text, readable without a browser, comprehensible without visual context. The second layer is the semantic structure. Coherent taxonomies, explicit relationships between entities, URL naming that makes sense, microcopy designed to answer questions and not to impress. This is the layer that lets both a human and a machine navigate the information and understand how the pieces connect. The third layer is the exposure. A minimal site, even static, that adds no frills but makes navigable what already exists as a knowledge base. From this same layer you can generate feeds, APIs, structured files for agents. The website becomes one of the possible interfaces, not the only and not even the main one. I know what you're thinking: this works for a tech company, not for a fashion brand, not for a restaurant, not for a company that lives on image. And you're right, in part. But only in part. Because the fashion brand also needs an LLM to know how to describe who it is, what it does, what its positioning is. The restaurant also needs that when someone asks an assistant "where do I eat well in Milan for fish?" the system finds clear and reliable information. The image-driven company also needs its image to be comprehensible beyond the visual. The presentation layer will be different, richer, more curated. But the underlying information layer has the same needs. There's an aspect of all this I find counter-intuitive and therefore particularly interesting: designing for those who have no eyes also improves the experience for those who do. Think about it. If you force yourself to write content an LLM can understand, you're writing clear, concrete, structured content. No empty slogans, no roundabout phrases, no fluff. An LLM doesn't fall in love with your graphics, but rewards coherent text with examples, real cases, numbers, limits. Know who else appreciates that? People who have little time and want to quickly understand if you're the right vendor. That is, basically all your potential clients. If you design clean architecture for machines, you're eliminating useless clicks, redundant pages, contorted paths. You're creating what in SEO is called canonical structure, but applied to the entire site narrative. And you know what? It's the same thing a human user would want: find what they're looking for without getting lost in a labyrinth. If you remove useless decoration to make the site readable to a crawler, you're also making it faster, more accessible, more usable on mobile, more usable for people on slow connections or older devices. Accessibility and machine-readability are almost the same thing, seen from different angles. And yet there's a real tension I don't want to hide, because it would be intellectually dishonest. Every time you add a pop-up, you maybe improve newsletter signup by 2%, but you make the page opaque to every crawling, parsing, sequential-reading system. Every time you write "clever" but empty copy—great for the internal pitch—you make it impossible for a model to understand what you actually do. And if the model doesn't understand, it won't cite you, won't propose you, won't recommend you. Every time you build an "experiential" design that breaks the mould, with content fragmented and scattered across JavaScript components loading at different moments, for the machine that becomes background noise, a puzzle to reconstruct without the box image. I'm not saying any decision made for the human is wrong. I'm saying there's a trade-off almost no one is calculating. And that trade-off, with the passing months, leans more and more toward the machines. Not because machines are more important than humans, but because they're becoming more and more, and better and better, the channel through which humans get to you. At this point I already hear the objections. I hear them because I made them to myself, and because I know the design and marketing world well enough to know where they'd hit. "This kills the brand." No. The brand isn't the gradient, isn't the micro-animation, isn't the parallax scrolling. The brand is the coherence of the message, the quality of promises kept, the clarity with which you communicate who you are. In fact, I'll say more: a site full of visual fireworks but with empty content *damages* the brand, because it creates expectations the real experience doesn't meet. The strongest brand is the one that says true things, clearly, and keeps them. "It all becomes cold and technical." This makes me smile, because it's exactly the opposite. When you remove slogans and stock phrases, what's left is space for an honest narrative. Real cases with names. Stories of projects with their problems and their solutions. Concrete details showing real competence, not declared. The "warmest" sites I've seen weren't the ones with stock photos of people smiling in offices. They were the ones where you understood exactly with whom you'd work and how. "But the competition has super-cool sites." And that's exactly the point. If everyone has super-cool sites and everyone says the same things with the same words, how do you differentiate? Maybe the best way to stand out is to have a site that doesn't give human visitors a headache and at the same time becomes an ally of the models that have to talk about you. While the competition invests in animations, you invest in content. While they optimise for the wow, you optimise for understanding. It's a bet, sure. But it's a bet that seems less and less risky. If you take this vision on board, and I know it's a big if, here's what changes in practice. UX stops being a manipulative funnel and becomes a clear, predictable path. Every element that doesn't add real information gets eliminated. Not because it's ugly, but because it's noise. Pages don't get duplicated for every campaign, content doesn't get fragmented into ten micro-sections with catchy little headings. You build canonical, linear paths that lead the visitor, human or machine, from question to answer in the most direct way possible. SEO completely changes skin. You move from keyword stuffing to entity and relationship modelling. Content has to make sense even read in plain text, without style, without visual context. It has to answer real questions, not queries invented by a tool. And FAQs stop being that section at the bottom of the page no one reads and become the informational core of the site, because they're exactly the format an LLM processes best. Content follows strict internal guidelines. Every service has to explicitly answer: what it is, who it's for, how it works, what it includes, what it excludes, how much it costs, what evidence there is that it works. If you can't answer all these questions clearly, maybe the problem isn't the site. It's that you haven't thought hard enough about what you offer. Metrics change. Less obsession with pageviews and time on page, which are vanity metrics in most cases. More attention to the quality of incoming requests. Are the leads aligned with what you actually do? Do clients arrive already knowing what to ask for? Is there coherence between what the site promises and what the client expects? Those are the metrics that count. I want to tell a story that, even simplified, is very close to situations I've seen with my own eyes. A B2B services company, fifteen people, with a site redone two years ago by a good agency. Flashy site, huge fonts, corporate storytelling, hero video with drone, "our values" section with hand-drawn icons. All beautiful. But if you asked anyone, including the founder, to explain in three sentences what the company does by reading only the site, they couldn't. The service pages were full of words like "integrated approach", "end-to-end solutions", "strategic partner". Real information: zero. They ran an experiment. They took all the site text, put it in a file, gave it to an LLM asking: who are we? What do we do? Who are we the right choice for? The result shocked them. The model had understood they did "consulting" of some kind, maybe in digital, maybe in communication, it wasn't clear. It hadn't identified any specific sector, any distinctive competence, any concrete case. In practice, the €80,000 site told the same story as ten thousand other identical sites. They redesigned everything starting from content. They rewrote every page answering the questions: what we do exactly, for whom, how, how much it costs, what we don't do. They documented case studies with real numbers: problem, solution, measurable result. They put in a list of sectors where they have experience and, equally important, those where they don't. The design became minimal, almost spartan. The copy became direct, at times brutal in its honesty. The result wasn't only a better ranking and better tool comprehension. Different leads started arriving. More qualified, more informed, who already knew what to ask. Sales calls became shorter because clients arrived with a precise idea of what to expect. The conversion rate rose not because the site was more persuasive, but because it attracted the right people and turned away the wrong ones. Which is exactly what a good site should do. ## **The site as persistent prompt** {: #the-site-as-persistent-prompt } There's an aspect of all this that pushes me to look a little further ahead, and that strikes me as the most strategic of all. Your site is becoming a persistent prompt. It's the text that trains LLMs on how to talk about your company. Every word you publish, every piece of information you make available, every absence you leave, contributes to forming the representation language models have of you. If you don't say it clearly on your site, someone else will make it up. Or worse, the model itself will make it up, filling the gaps with what it finds elsewhere, or with the statistically most probable solution, which is almost never the right one. Think about how many interactions are already happening without the user visiting your site. Someone asks an AI assistant: "which company do you recommend for this kind of service?" The assistant consults its sources, including your site, and formulates an answer. If your site is a monument to emotional storytelling but contains no concrete information, the answer will be vague, generic, or will exclude you entirely in favour of a competitor with a less beautiful but clearer site. More and more often the flow will be: client talks to agent, agent reads the site, agent synthesises an answer, client decides based on that synthesis. Your site won't be the client's destination anymore. It'll be a data source for an intermediary. And like any data source, it'll be judged on the quality, completeness, and reliability of the information, not on the beauty of container and contents. This makes the clarity of raw content even more strategic than any campaign, hero video, polished storytelling. Your raw content is what the world will see of you through the machines. It's your face for those who have no eyes. If you've made it this far, I propose an exercise that's also a slightly merciless call to action. Do it today, it takes ten minutes. Take all the text of your site. Just the text, without graphics, without layout, without colours. Put it in a file and give it to an LLM. Ask it: who are we? What do we do? Who are we the right choice for? Why should a potential client choose us? If you don't recognise yourself in the answer, the problem is serious. It isn't an SEO problem, isn't a design problem, isn't a marketing problem. It's an identity problem. Your site doesn't know how to tell who you are, and in a world where LLMs are increasingly the first point of contact, that means no one will know who you are. The question to ask isn't "how do we make the site more engaging?" anymore. The question is: how do we make sure anyone, human or machine, understands at a glance who we are and why we matter? If your most important visitor has no eyes, maybe it's time to stop designing only for those who look and start designing for those who understand. --- # How GenAI Permanently Changed Our Relationship with Digital Products - **URL:** https://margiovanni.it/en/blog/how-genai-changed-our-relationship-with-digital-products/ - **Published:** 2026-02-14 - **Tags:** AI, Claude Code, Development, Product - **Reading time:** 6 min > Building a custom CMS is now faster than picking an off-the-shelf one: in 25 minutes with AI I turned my Astro blog into a dynamic, secure, intuitive system. Zero friction, full control. Until a few weeks ago, writing an article for this blog meant opening the code editor, creating a markdown file in a specific folder, checking the frontmatter was right, committing, pushing, waiting for the deploy. For one article. Every time. It wasn't terrible: it worked. But it was awkward in that sneaky way that makes you postpone things. "I'll write that piece tomorrow", which becomes next week, which becomes never. ## **The old system: nice in theory, awkward in practice** {: #the-old-system-nice-in-theory-awkward-in-practice } ![](/media/images/1771136010757-1760ic.png)The site ran on Astro with static pages. Articles were `.md` files in a project folder. Every post had its YAML frontmatter at the top (title, date, tags, description, image) and then the content in markdown. To publish I had to: 1. Open VS Code 2. Create the file in the right folder, with the right name 3. Write the frontmatter without errors (one comma out of place and the build blew up) 4. Write the content in markdown 5. Test locally that everything was fine 6. Commit, push, wait for the Cloudflare Pages deploy Six steps. To publish a thought. And we won't talk about editing an existing article: find the file, open it, edit, re-commit, re-push. Or uploading an image: save it in the `public` folder, reference it with the relative path in the markdown, hope you didn't get the path wrong. It worked, yes. But every time there was that friction that turned a five-minute task into a twenty-minute ritual. And friction, over time, kills consistency. ## **The idea: what if I built myself an admin panel?** {: #the-idea-what-if-i-built-myself-an-admin-panel } At a certain point I asked myself: how long would it take to build a decent admin panel? Not WordPress, not Ghost, not a headless CMS with a monthly subscription. Something of mine, that does exactly what's needed, nothing more. The traditional answer would have been: a lot. Days of work to build it, or weeks to adapt an existing CMS, with its opinions about how things should work, its dependencies, its updates to manage. But the answer in 2026 is different. ## **Building has become faster than choosing** {: #building-has-become-faster-than-choosing } ![](/media/images/1771136166224-zkgig5.png)![](/media/images/1771136082006-ku1059.png)![](/media/images/1771136096156-irdb3s.png)What I did was sit down with Claude Code (an AI generative tool applied to code) and build the system piece by piece. Not generating random code to copy and paste, but working with it the way you would with a very competent and very fast colleague. The result is a complete admin panel that lets me: * **Write articles with a WYSIWYG editor**: no more hand-written markdown, I write as in a normal text editor, with a toolbar for bold, italic, headings, lists, quotes, code, links, and images * **Drag images directly into the editor**: it uploads them automatically to Cloudflare R2 and inserts them at the right point * **Manage metadata in a clear sidebar**: publication state, date, tags, cover image, all within reach * **Save with one click**: like in any normal application * **See the article list** in a dashboard with immediate stats And all this saves the content as markdown in the database, so the blog's frontend renders them exactly as before. ## **What's under the hood** {: #whats-under-the-hood } ![](/media/images/1771136209509-msxruw.png)For anyone curious about the technical part: the site still runs on Astro, but it has moved from static generation to server-side rendering on Cloudflare Workers. That means pages are generated on the fly when someone visits them (for the first time), which lets me have dynamic content without giving up speed. The data lives on **Cloudflare D1**, a SQLite database distributed across Cloudflare's edge network. Images on **Cloudflare R2**, an S3-compatible object store. Authentication uses **JWT** with tokens signed via the Web Crypto API. The WYSIWYG editor is based on **Tiptap**, an editing framework built on ProseMirror (the same engine underneath editors like Notion). The interesting part is that under the WYSIWYG, content is converted to clean markdown via a dedicated extension. I write visually, I save in a portable format. For security—because an admin panel exposed on the internet has to be secure—there's: * **Cloudflare Turnstile** on the login page (the invisible successor to CAPTCHA) * **Rate limiting** to prevent brute-force attacks * **Strict validation** on every input, every upload, every file path * **Constant-time comparison** of credentials, to prevent timing attacks * **Magic-bytes verification** on uploaded files, not just extension checking No admin framework, no plugin, no heavy dependency. Just the code that's needed, where it's needed. ## **The real change isn't technical** {: #the-real-change-isnt-technical } The interesting part of this story isn't the technology. It's the change in the cost-benefit calculation. Until recently, faced with a need like this, the options were: 1. **Adapt something existing**: WordPress, Ghost, Strapi, dozens of CMSes with their opinions, their learning curves, their recurring costs, their vulnerabilities to update 2. **Have it built**: a quote, waiting times, feedback iterations, compromises on how "the framework wants it to work" 3. **Build it yourself**: weeks of work, testing, debugging, with the real risk of giving up halfway Today there's a fourth option: **build it yourself, with AI as accelerator**. Not as a substitute for thinking, but as an amplifier of execution capacity. I knew what I wanted. I knew how it should work, what user experience I was looking for, what compromises I was willing to make. AI turned that vision into working code at a speed that was previously simply impossible for a single person. And it isn't "generated" code: it's code I guided, reviewed, tested, and understand line by line. Because the point isn't to delegate the thinking—it's to delegate the typing. ## **Faster to build it than to ask for a quote** {: #faster-to-build-it-than-to-ask-for-a-quote } This sentence sounds provocative, but for a certain category of projects it's becoming literally true. **I'm not talking about enterprise systems, platforms with thousands of users, or mission-critical software.** I'm talking about all those "medium" projects that used to fall into a no-man's land: too specific for an off-the-shelf solution, too small to justify a serious investment, too tedious to do by hand. My admin panel is exactly in that category. No existing CMS would have done exactly what I wanted the way I wanted it. Having someone else build it would have required briefs, quotes, reviews, deploys. Doing it myself by hand would have required weeks stolen from evenings and weekends. Instead I built it in 25 minutes. It works. It's mine. It does exactly what's needed. And if tomorrow I want to change something, I can do it in minutes. ## **The future is custom-made** {: #the-future-is-custom-made } I think we're entering an era where custom software becomes accessible to anyone with a clear vision of what they want and decent technical skills. You don't need to be a team of developers anymore. You don't need a serious budget. You need to know what you want and to be able to guide the tool. It's like the move from artisan tailoring to ready-to-wear, **but in reverse**: we're going back to bespoke, only now the tailor is extremely fast and costs a fraction of before. For people working in digital (developers, designers, marketers, founders), this obviously changes the calculations. --- # Who Controls What AI Agents Produce? - **URL:** https://margiovanni.it/en/blog/who-controls-what-ai-agents-produce/ - **Published:** 2026-02-04 - **Tags:** AI Agents, Ethics, AI - **Reading time:** 8 min > There's a question that has been turning in my head for weeks—the kind that arrives at eleven at night when you're going back over everything that was produced during the day. The question is simple, almost banal: how do we govern what we can no longer read? ![](https://substackcdn.com/image/fetch/$s_!XK6c!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fae1632b6-af0b-4412-b8a0-ba1d3d95b186_5352x3648.jpeg) *Photo by Frans van Heerden: * There's a question that has been turning in my head for weeks—the kind that arrives at eleven at night when you're going back over everything that was produced during the day. The question is simple, almost banal in its phrasing: how do we govern what we can no longer read? I'm not speaking abstractly. I'm speaking about what happens every day in organisations using AI agents. About pull requests containing changes generated automatically, about specification documents co-written with Claude, about configurations suggested by systems that understand the infrastructure better than the people approving them understand it. About that subtle, almost imperceptible feeling of approving things you only partly understand. The fact that there isn't a clean answer to this question is, by itself, significant. And the fact that the same question gets asked more and more often—in boardrooms, legal offices, compliance teams—suggests we're crossing a point of no return. Not a gradual evolution. A point of no return. ## The Assumption That Collapses {: #presupposto-che-crolla } Traditional governance rests on an assumption so embedded it has become invisible: that there's enough time to understand what was produced before it goes to production. Code review. Document audit. Contract approval. Analysis validation. Sign-off on deliverables. All of this worked for decades because the bottleneck was production. The time needed to create something was long enough to let the validation process keep up. But when an AI system generates in minutes what used to take weeks, that assumption collapses. It doesn't bend, doesn't adapt: it collapses. And this isn't only about code. It's about everything. ## Where It Collapses, in Practice {: #dove-crolla } I think about contractual documents. An AI agent today can draft contracts, specific clauses, responses to disputes, preliminary opinions. The quality is often plausible enough to survive a quick read. But "plausible enough" in legal work can mean clauses that look protective and aren't, obsolete legal references presented with confidence, omissions that surface only in litigation. The risk isn't the obvious error. It's the subtlety of the error in a context where subtlety is everything. I think about financial analysis. Dashboards, projections, scenario analyses, business cases. A CFO who receives an analysis generated or co-generated by AI is approving something they understand? Or are they validating the surface plausibility of numbers that follow a logic no one has actually verified? The problem isn't whether the numbers add up. The problem is whether the underlying assumptions are correct, whether the models applied are appropriate, whether the data sources are reliable. All things that require domain competence to evaluate, competence the review process presupposes but the production speed makes harder and harder to apply. I think about external communications. Customer emails, tender responses, product documentation, user manuals, internal policies. Every organisation produces thousands of textual artefacts daily. When a significant share of them gets generated or assisted by AI, who guarantees consistency with the company's positioning? Who verifies that a customer reply doesn't create expectations the organisation can't then meet? And then there's compliance. Here the paradox peaks. We're in the middle of the European regulatory wave: AI Act, Cyber Resilience Act, Product Liability Directive, EAA, GDPR continuing to evolve. Organisations have to produce compliance documentation, risk assessments, registers, policies. The temptation to use AI to accelerate this production is enormous. But we're talking about documents that attest conformity to rules that, in some cases, are exactly about the use of AI. There's something circular and unsettling about using an AI system to declare that your AI systems comply with the rules on AI. ## An Organisational Epistemology Problem {: #problema-epistemologico } The problem isn't only speed. It's volume combined with opacity. A team using AI to generate code, configurations, documents, analyses, communications, architectural decisions, produces a quantity of artefacts no human review process can realistically cover at 100%. Maybe not even 50%. Maybe not even 20%, if we're honest with ourselves. But the worse problem is another: many of those artefacts are plausible enough to survive a superficial check. Which is almost worse than if they were obviously wrong. An obvious error gets caught. A plausible error gets approved, deployed, published, signed, and discovered only when it produces consequences. I realise we're facing what could be called **an organisational epistemology problem**: the organisation knows less than what it produces. And the gap widens every day. ## Three Directions, None Decisive {: #tre-direzioni } I don't have definitive solutions. No one does, and anyone who claims to is probably underestimating the problem. But there are a few directions that look sensible, even if none is decisive. The first is what could be called **the move from point-by-point control to structural control**. If you can't check every output, you have to check the system that produces the outputs. That means investing far more in defining upstream constraints, rigorous specifications, automated guardrails, policy-as-code, rather than in downstream review. It's the point of spec-driven development: if the spec is solid, the range of error in the output narrows. It doesn't disappear, but it contains. For legal documents, that means verified templates with clear placeholders, not free-form generation. For financial analyses, validated models with controlled inputs, not blank slates. For configurations, certified baselines with explicit and justified deviations. The underlying principle is simple: shift the intelligence—and therefore the responsibility—into defining the problem, not into generating the solution. The second direction concerns *what* we verify. You can't read all the generated code. You can't reread every document. You can't recheck every analysis. But you can define invariants that must be respected and test them automatically. For code: automated tests, type checking, static analysis, security checks. For documents: automated checklists, structure validation, terminological consistency checks. For configurations: compliance policy as code, drift detection, pre-deploy validation. **It's a paradigm shift: you go from "I read and approved this artefact" to "this artefact respects these verifiable properties".** Which is what we already do with automated tests in software. Only now it becomes the only realistic line of defence for everything. The limit is obvious: verifiable properties are a subset of desirable properties. You can verify that a contract contains certain clauses, not that it's strategically appropriate. You can verify that an analysis is internally consistent, not that the assumptions are correct. But it's still much better than nothing. The third direction is maybe the most uncomfortable to accept: AI checking AI. Automated reviewers. Specialised validators. Systems that verify the output of other systems. The recursive problem is obvious: who watches the watchers? If I don't trust the output of the AI that produces, why should I trust the output of the AI that verifies? But it's probably inevitable. And the question becomes: how do we keep human intervention points at the moments that actually matter? My hypothesis, still to be tested in the field, is that the human role will shift toward architectural decisions, ethical choices, exception handling, calibration of the control systems. It's a different role. Less operational, more strategic. Less doing, more deciding the rules of doing. ## The Organisational Risk {: #rischio-organizzativo } What worries me most in all this? Not so much the technical risk. Bugs get found. Errors in documents surface. Bad configurations show up. What worries me is the organisational risk: teams that get used to trusting outputs without understanding them, that gradually lose the ability to assess what they're approving. I see it already. Developers accepting generated code without reading it. Managers approving analyses without verifying assumptions. Compliance leads signing documents they only skimmed. It's understandable—we're all under pressure, all with more to do than we can manage. But it's also dangerous. The most important governance maybe isn't on systems, but on the competence of the people who should be governing them. **If we lose the ability to understand what we're producing, we lose the ability to govern it.** Regardless of how many layers of automated control we put in between. ## Who Answers, and Navigating the Uncertainty {: #chi-risponde } There's also a question that in Italy, and in Europe with the AI Act, becomes particularly pressing: who is responsible? When a contract generated by AI contains an error that causes harm, who answers? The operator who used it? The provider of the AI system? The manager who approved? The organisation as a whole? When a configuration suggested by AI creates a security vulnerability, the chain of responsibility suddenly becomes very important. The European regulatory framework is trying to give answers. The AI Act defines obligations for providers and deployers. The Product Liability Directive extends liability for defective products. The Cyber Resilience Act introduces security-by-design requirements. But the truth is that regulation runs behind technology, and meanwhile organisations have to make decisions. Decisions that will have legal consequences based on rules that aren't fully clear yet. What you can do is build traceability. Know which artefacts were generated or influenced by AI, with which prompts, under which conditions. It doesn't solve the responsibility problem, but at least it lets you reconstruct what happened. I write all of this and realise how uncertain the ground is that we're all moving on. There are operating principles that look sensible: presumption of structural control, explicit invariants, mandatory traceability, strategic human intervention, competence as prerequisite, acceptance of uncertainty. But they're principles under construction, imperfect, evolving, probably destined to be overtaken quickly by the speed of change. And there's something deeply frustrating about this situation. For years anyone working in this field had the job of finding solutions, giving answers, having a clear plan. Now we find ourselves navigating a territory where the questions are clearer than the answers, where every solution opens new problems, where the most honest thing one can say is "I don't know, but I'm trying to understand". Maybe this is the new role of those who govern complex systems: not having all the answers, but asking the right questions and building structures that allow adaptation when the answers change. It's less reassuring than a framework defined with five best practices and three strategic pillars. But it's the only honest governance possible when the world produces faster than we can understand. I often wonder where others in the middle of this transformation feel the tension most. On the speed of production, on the capacity to evaluate, or on something completely different I'm not yet seeing. Because maybe the thing that worries me most is exactly that: not knowing what I'm not seeing. --- # From Developer to Product Owner: The Necessary Shift in the AI Era - **URL:** https://margiovanni.it/en/blog/from-developer-to-product-owner-the-necessary-shift/ - **Published:** 2026-01-24 - **Tags:** AI, Software Development, Digital Transformation - **Reading time:** 6 min > A few days ago a colleague on my team using Claude Code shipped a feature that, when I did his job, would have taken me half a day. He finished it in forty minutes. ![](https://substackcdn.com/image/fetch/$s_!QSPr!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc3e8b7de-a798-4557-854f-24901d5c21d9_6124x4083.jpeg) *Photo by Tara Winstead: * A few days ago a colleague on my team who uses Claude Code shipped a feature that, back when I did his job, would have taken me more than half a day. He finished it in forty minutes, with quality and confidence. While I was thinking about it, I wasn't thinking about how powerful the tool was. I was thinking about how my own career path—that transition from developer toward product ownership and broader leadership over the last few years—is turning out to be more prescient than I'd imagined. I didn't do it out of foresight, to be clear. I did it because at some point writing code all day stopped giving me what I was looking for. I wanted to understand the *why* of things, not just the *how*. I wanted to be in the room when the decisions about what to build were made, not just receive tickets to implement. It was an instinctive choice, partly self-interested. But in hindsight, it has put me in an interesting spot to watch what's happening right now. ## Value Migrates From the How to the What {: #il-valore-migra } The inflection point we're at isn't about AI "stealing programmers' jobs", the way the sensational headlines put it. **It's about something subtler: value is shifting. It's migrating from the *how* to the *what* and *why*.** And I see it every day, in conversations with the other professionals and managers I know, in hiring decisions that have already changed, in the way it's now necessary to structure teams. Companies don't ask "how many developers can I hire" anymore. They ask "how do we maximise productivity with smaller teams and better tools". It's a radical change of perspective. In my role I increasingly find myself reasoning about how to integrate AI agents into existing workflows rather than how to scale the team. And that has enormous implications for anyone who today writes code as their main activity. The autonomous AI agents we use daily aren't glorified autocomplete. They do things that two years ago would have looked like science fiction: they take a poorly defined problem, decompose it, search the codebase for context, implement, test, iterate. We supervise them, of course. We correct them, often. But the volume of work they can produce, with the right guidance, is impressive. And that changes everything. ## What I Look For in Teams Today {: #cosa-cerco-nei-team } When selecting candidates or reviewing team performance, the questions have to change radically. I no longer care that much how fast someone writes code. I care how well they understand the problem we're solving. I care whether they ask the right questions before starting, whether they anticipate edge cases, whether they can explain their choices in terms that make sense to the business. These are the things AI still can't do well. I know professionals who refuse to use Copilot or Claude Code because they "prefer to write everything themselves". I get it, I really do. I come from there, I know that feeling of total control, that satisfaction of seeing the code emerge from your fingers. But from where I am now, I also see the risk. It's a bit like the typesetters who refused desktop publishing because they loved lead. Romantic, sure. Economically sustainable, much less. The transition from developer to product owner, or to any role where you define the *what* instead of implementing the *how*, doesn't mean ceasing to be technical. On the contrary, in my experience it requires *more* technical competence, not less. But a different competence: I need to know what's possible, what's expensive, what's risky, without necessarily being the one to implement it. You have to lead AI and agents the way a conductor leads musicians—you don't play every instrument, but you have to know how every instrument should sound. The developers I see making this transition well share traits I recognise in myself. They aren't necessarily the most technically brilliant. They're the ones who always asked a lot of questions, the ones who wanted to understand the *why* behind every feature, the ones who got irritated when they received vague specs. They're the ones who always thought about the product, even when their official role was just to write code. If you recognise yourself in that description, you probably have half the work done. Then there's the matter of relational skills, and here I have to admit the shift was hard for me too. For years I avoided meetings with business stakeholders, treated them as interruptions of "real work". Now they *are* my work. Translating technical language into terms a CFO can understand, negotiating priorities with a marketing team that wants everything yesterday, explaining to a board member why that "simple" feature takes three months: these are skills no AI can do yet, and maybe never will. They're what makes me valuable today. ## Specifying Is the New Craft {: #specificare-e-il-mestiere } One thing I've learned in practice: the quality of the requirements you give the AI determines the quality of the output you get. It sounds obvious, but the implications run deep. When I write precise specs, contextualised, with the right constraints and the right freedoms, I get code that works. When I'm vague, incomplete, contradictory, I get garbage. That means the critical skill is no longer "can you code"—it's "can you specify". And specifying well requires deep understanding both of the technical domain and of the business one. I've already seen small teams—five people max—produce output equivalent to teams of twelve, simply because they had someone who could define tasks the right way. I'm not talking about formal documentation, UML diagrams, or hundred-page technical specs. I'm talking about that ability to articulate what's actually needed, to ask the right questions before starting, to anticipate problems. It's a skill you can learn, but it requires a mindset shift. ## The Leap Takes Humility and Courage {: #il-salto } That said, I don't want to paint too rosy a picture. The transition I went through wasn't linear, and I see colleagues struggling enormously. It requires humility: accepting that something you knew how to do well is losing relative value, and that you have to invest in different skills. It also requires courage: stepping out of the comfort zone of code, where things are deterministic and controllable, to enter the ambiguous world of product decisions, where you always have incomplete information and stakeholders with conflicting agendas. There's also an ethical dimension here that worries and fascinates me. Using AI to accelerate development isn't neutral. There's bias in the models, there are implications for code quality, security, maintainability. You also have to be a little paranoid, you have to know when AI is doing something wrong even if it technically works. It's a new responsibility, and it requires awareness and intention. You can't delegate everything and hope it goes well. ## The Bet to Make Now {: #la-scommessa } **What I see from where I sit is that technical leadership, product management, and tech strategy roles will be increasingly in demand and increasingly hard to fill.** **People coming from coding have an enormous competitive advantage over people arriving from pure business: they understand what's possible, what's expensive, what's risky. But they have to make the jump. They have to stop identifying with the lines of code they write and start identifying with the problems they solve.** The false myth I hear most often from developers I talk to is "I don't have time to learn this stuff". But the time you save by using AI to write code—where does it go? If you reinvest it in further perfecting your coding skills, you're optimising something that's becoming a commodity. If you reinvest it in learning to think like a product owner, you're building your future relevance. The question I asked myself years ago, when I started this transition, was "what do I want to be doing in five years?". The answer wasn't "writing code even faster". It was "having more impact, understanding the business better, being in the room where decisions get made". That question is even more urgent today for anyone at the start of their path. The future belongs to those who can define what to build, not only to those who know how to build it. I made that bet a few years ago, without knowing how relevant it would become. **For anyone reading today, the advantage is that they can make it with more awareness. But they have to make it.** --- # From Software to Data, Transformed - **URL:** https://margiovanni.it/en/blog/from-software-to-data-transformed/ - **Published:** 2026-01-21 - **Tags:** AI, Software Development, Digital Transformation - **Reading time:** 9 min > A few nights ago I read an article. It's called The Death of Software 2.0 and uses a metaphor that stuck with me. ![](https://substackcdn.com/image/fetch/$s_!ZQ2c!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb9d40b58-982c-404f-b18f-f49a58a3ef11_5472x3648.jpeg) *Photo by Karola G: * A few nights ago I read an article. It's called [The Death of Software 2.0](https://www.fabricatedknowledge.com/p/the-death-of-software-20-a-better) and uses a metaphor that stuck with me: it compares the software of the future to a computer's memory hierarchy. Fast, ephemeral memory—what we call DRAM—would be artificial intelligence processing non-deterministically. Persistent memory—NAND—would be structured data, APIs, what we call the single source of truth. The author's conclusion is brutal: **interface-oriented software is becoming obsolete**. What will have value is the data and the APIs through which AI agents access systems. Reading that piece, something clicked in my head. Not because it was a fascinating theory. Because it described exactly what I'm starting to do in my work, what I feel necessary to do, even if a part of me still resists. I've spent fifteen years building software with a simple value logic: interface first, API second. From the client's point of view the UI was the product, the API was an add-on, a complement for integrators, something to document when there was time left over. That model worked because software had to be used by people. **Now it isn't, or at least it isn't only that.** ## Agents Don't Click {: #agents-dont-click } Claude, ChatGPT, Gemini, AI agents, agentic tools in general—they don't use software the way a human does. They don't click buttons. They don't follow UX flows. They don't get confused by the seventeen edge cases in the checkout form I spent weeks handling. They need three things: structured data accessible via well-designed APIs, persistent context they can grasp in a conversation, deterministic and repeatable actions they can orchestrate without errors. **If the product you're building isn't designed around those three pillars, you're building it for 2015.** And here I have to be honest with myself. For years I poured my soul into interfaces. I argued for hours about the right colour for a button, about how to organise a menu, about which microinteraction would make the experience smoother. It wasn't wasted time, far from me to say that. But I wonder whether I wasn't building cathedrals on foundations that were already starting to tremble. ## MCP as the Bridge {: #mcp-as-bridge } The Model Context Protocol is the standard Anthropic released in November 2024. OpenAI and Google adopted it immediately. It's the standardised bridge between an artificial intelligence and enterprise systems. Until now, every AI integration was a custom project: raw API calls inside the app, fragile RAG pipelines, bespoke tool calling, no reusability, no governance. With MCP the paradigm changes. You expose your system as an MCP server. The AI consumes it as a standardised client. You authenticate once. You govern once. You monitor once. That isn't a small thing. It's the equivalent of how HTTP standardised communication on the web in the 1990s. And like HTTP, it will change everything without most people noticing. ## The Flow Rewritten {: #flow-rewritten } **Let me try to imagine what it would actually mean for the clients I work with.** Today the flow is this: the client opens the UI, clicks for eight or ten different actions, exports data to CSV, pastes it into another app, gets the result. It's a process that works, that we've optimised over years, that clients know. But it's also a process that takes time, attention, specific competence on how that particular software works. The future flow could be this: the client talks to Claude/ChatGPT/Gemini/whatever and says "process this data and give me the report". Claude connects directly to the system via MCP, reads the data, processes it, writes the result into the right table. All in ten seconds, no clicks. It isn't AI that knows the software. It's the software that becomes consumable by AI. And via tools everyone already uses daily. Writing these words, I feel an internal resistance. Building interfaces was my work for years. There's something human about designing an experience, about thinking how a person will interact with something you've created. There's also, I have to admit, a form of control. When you design an interface, you decide the flow. You guide the user. You choose what they can and can't do, in what order, with what constraints. Opening all of this to an AI agent means giving up that control. It means trusting the system will do the right thing even when you can't predict exactly what the user will ask. But maybe that's the point. Maybe that control was always an illusion, a way to manage complexity by reducing options instead of really facing it. ## The Governance Gap {: #governance-gap } The market data is clear. [More than 80% of development teams](https://www.kasunsameera.com/state-of-api-first-development-in-2026-trends-and-insights) already follow an API-first methodology. Estimates put [active APIs at 1.7 billion in 2030](https://mondaysys.com/api-first-saas/), a 300% increase over the current baseline. API-first adopters see a 37% reduction in integration costs compared to traditional approaches. But the data point that struck me most: [Gartner estimates](https://www.accelirate.com/agentic-ai-governance-crisis/) that more than 40% of agentic AI projects will be cancelled by 2027 if they don't have solid governance. Here's where everything gets complicated, where the technological vision collides with operational reality. MCP today has important gaps. There's no authentication standard: every implementation is different. Sandboxing is weak: if an agent takes control, where do you stop it? There are prompt-injection risks: how do you guarantee the AI isn't manipulated into doing unwanted actions? And there are auditing gaps: how do you trace who did what and when? The European Commission and European central banks are already pushing toward APIs that are transparent, controllable, auditable. It isn't only a technical choice. It's a regulatory survival choice. And here a territory opens up that I know well, the balancing act between innovation and compliance, between what you could do and what you should do. I often find myself reflecting on this balance. On one side there's the push to move fast, to adopt new technologies before competitors, to be the first to offer clients something they didn't even know they wanted. On the other there's responsibility to those clients, to their data, to long-term sustainability. They aren't always in conflict, but sometimes they are. And when they are, the choice is never obvious. I've watched companies move too fast and burn client trust with AI implementations that weren't ready. I've watched companies move too slowly and become irrelevant as the market shifted around them. The perfect trade-off doesn't exist. What exists is the capacity to choose consciously, knowing what you're sacrificing and why. ## Value Doesn't Live in the Work {: #value-not-work } What I'm exploring concretely is a backend layer that exposes client data as an MCP server. A set of instructions and configurations for AI that knows how to query that server. A governance interface where the client can decide what the AI can read and what it can't, which actions it can perform and which it can't. A complete audit trail that tracks every interaction, every decision, every error. The result, if it works, is that the client won't need us for three-quarters of repetitive tasks. They'll need us to keep the system clean, to add new data sources, for governance and compliance, for problems that require human judgement. It's a relationship shift: from doing the work to making the work automatable. I write this sentence and realise how radical it is. I'm thinking about something that will reduce the amount of work clients ask me to do. From a short-term revenue point of view, it's madness. From a long-term value point of view, I think it's the only sensible road. Clients pay because of the love of paying? They pay because you have something they need. If we can give them the same value, or more, with less friction, why wouldn't we? And if you don't, someone else will. There's a phrase I keep saying to myself: value doesn't sit in the work you do, it sits in the problem you solve. **For years I measured my value in hours, deliverables, features released. Now I wonder if I shouldn't measure it in problems eliminated, friction reduced, capacity returned to clients to do what they do best.** The window for this change is now, in 2026. MCP is standard, supported by the three main AI providers. Security gaps are being closed progressively. Clients are starting to understand they want something like "talk to ChatGPT and done". Anyone who doesn't move in this direction will be cut out. Not tomorrow. Now. But "now" doesn't mean "at any cost". It doesn't mean sacrificing data security for implementation speed. It doesn't mean promising clients functionality that isn't yet mature. It doesn't mean ignoring regulation because it's inconvenient. It means **finding the way to move fast in the right direction, with eyes open about where you're going**. ## The Builder's Responsibility {: #builders-responsibility } There's something that particularly stirs me when I think about all this. It isn't the fear of getting things wrong technically. That's there, but it's manageable. It's something deeper. It's the awareness that **the decisions we make today as software builders are defining the relationship people will have with technology tomorrow**. Every API we expose, every piece of data we make accessible, every action we automate sets a precedent. Establishes what's normal, what's acceptable, what's expected. I think about our clients, people running companies, with employees, who in turn serve other clients. When I open their systems to AI, I'm changing how they work. Redefining which skills will be needed, which roles will make sense, how their day will be structured. It isn't a responsibility to take lightly, and we have to expect a lot more resistance because what we offer isn't software but a change—sometimes substantial—of internal roles and processes, and even of hierarchies. But it's also an extraordinary opportunity. The chance to free human time and energy for activities that really require intelligence, creativity, judgement. To reduce repetitive work that consumes people without adding value. To make small companies competitive with large ones, because access to automation will no longer be a question of budgeting for dedicated teams. Maybe this is the fundamental trade-off. On one side the risk of building systems that escape control, create dependencies, concentrate power in the wrong hands. On the other the possibility of building something that genuinely helps people work better, live better, spend their time on what matters. And I have the conviction that staying still isn't an option, and the determination to move in the direction that seems right, one step at a time, with eyes open. So this is what I'm doing. If you recognise this trajectory and want to talk about where it could lead, let's talk. --- # The Invisible Architecture of Music Streaming - **URL:** https://margiovanni.it/en/blog/the-invisible-architecture-of-music/ - **Published:** 2026-01-15 - **Tags:** Music, Streaming, Technology - **Reading time:** 12 min > How business and tech have perhaps killed songwriting, originality, and art There's a moment that often comes back to... *How business and tech have perhaps killed songwriting, originality, and art* ![](https://substackcdn.com/image/fetch/$s_!OWVJ!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9cf6e9cf-8c28-406c-91ef-0f9752f9c47a_1456x971.jpeg) There's a moment that often comes back to me. A few years ago, I was at a concert in a small club in Pescara, one of those places where the stage is as high as a single step and you can smell the bass player's sweat. The band was unknown (3 completely crazy kids with an unmistakable smell), the audience maybe thirty people, the sound raw and imperfect. But there was something alive in that room, a direct connection between those playing and those listening that didn't need algorithms to exist. Going home, I opened Spotify to search for that band. They weren't there. Or rather, they were, but buried under thousands of other results, invisible unless you knew exactly what to look for. And I wondered: how many bands like that exist in the digital shadow, technically present but practically nonexistent? I spent some time studying how music streaming platforms really work. Not the surface—we all know that. I was interested in understanding what happens underneath, in the technical guts of these systems that mediate our relationship with music. What I found made me rethink everything I thought I knew about how we discover music today. ## A Logistics Machine {: #logistics-machine } Let's start with a truth that's rarely told: **when you click play on Spotify, you 're activating one of the most sophisticated logistical machines ever built**. That's not an exaggeration. Spotify manages over one hundred petabytes of data and more than two thousand distributed microservices. Every song you listen to doesn't come from nowhere—it comes from a chain of servers, caches, geographically distributed nodes working together to make you believe the music is simply there, ready for you. It's an extraordinary illusion, and like all successful illusions, it hides something important. The first thing to understand is that not all songs are equal to the system. I'm not talking about artistic quality—I'm talking about something much more prosaic: distribution cost. When you listen to a song, that song has to travel from somewhere to your device. If it's already stored on a server near you, the cost is minimal. If it has to be retrieved from a datacenter on the other side of the world, the cost rises. Multiply this by billions of plays per day and you understand why optimization becomes an obsession. ## Predictability Is Decided {: #predictability-decided } **This is where the concept of predictability comes in, and this is where things get interesting**. The system works better when it knows in advance what you'll listen to. If it can predict that tomorrow millions of people will listen to a certain song, it can distribute that song in advance to hundreds of servers around the world. When the request comes, the song is already there, ready. No delay, no extra transfer cost. It's elegant, efficient, economical. The problem is this: how do you predict what millions of people will listen to? **The answer is as simple as it is unsettling. You don 't predict it. You decide it yourself.** **Editorial playlists are not a service offered to users. They are a consumption control tool.** When Spotify creates a playlist like "Today's Top Hits" and presents it to fifty million followers, it's not simply suggesting music. It's creating a predictable flow of plays that can be optimized at the infrastructure level. The system knows that playlist will be listened to by hundreds of thousands of people, knows they'll follow the proposed order, knows the first fifteen songs will receive most of the plays. With this certainty, it can pre-distribute those songs to all necessary servers, ensuring that every play is served from local cache instead of the central datacenter. ## Albums Versus Playlists {: #albums-vs-playlists } I made a rough calculation. Let's assume one and a half billion streams per day, an average bitrate of 128 kbps, an average song of three minutes. Without optimization, the daily bandwidth cost would be in the order of tens of millions of dollars. With the predictive prefetching made possible by playlists, that cost can be reduced by sixty, seventy percent. On an annual scale, we're talking billions of dollars in savings. This isn't speculation: **Spotify has invested hundreds of millions with Google Cloud precisely to optimize this type of flow.** Albums, on the other hand, remain a problem. Not because they're technically different, but because they're *unpredictable*. When a user saves a twelve-track album, the system doesn't know which tracks they'll listen to, in what order, when. They might only listen to the singles. They might start from track seven. They might never listen to it. This uncertainty means the system must allocate resources conservatively, preparing for every eventuality without knowing which will occur. It's inefficient, expensive, and creates what technicians call *cache waste* —pre-stored songs that nobody touches. The consequence is subtle but profound: **the system has a structural incentive to promote playlists over albums**. Not because someone decided albums are bad, but because the very architecture of the system rewards predictability. And playlists, by definition, are predictable. Albums are not. I've often wondered if those who designed these systems were aware of the cultural implications. Probably not, at least initially. The engineers were solving a distribution problem, not thinking about redefining how music is discovered and consumed. But the effect is the same, intentional or not. There's a study from the National Bureau of Economic Research that particularly struck me. It measured the impact of Spotify's editorial playlists on streams. The results are staggering. Appearing on "Today's Top Hits" increases streams by twenty to forty times in the following week. Appearing on "New Music Friday" by five to fifteen times. **This isn 't simply promotion. It's success creation.** By deciding which songs to put in those playlists, Spotify literally decides who will succeed and who won't. The feedback loop that results is even more insidious. A song enters an editorial playlist. It receives millions of plays. The algorithm perceives it as popular and starts suggesting it organically to other users. The song receives even more plays. The infrastructure pre-caches it even more aggressively, further reducing distribution costs. And meanwhile, somewhere, an unknown band plays in a small club in Pescara, technically present on the platform but practically invisible. I don't want to paint all this as an evil conspiracy. It's something more complex and, in some ways, more disturbing. It's the natural emergence of a network of incentives: technical, economic, market-driven. No one decided that experimental music should be penalized. **It 's simply that experimental music is unpredictable, and unpredictability costs.** No one decided that organic discovery should be stifled. It's simply that **controlled discovery is more optimizable**. The result is the same, but the cause isn't a villain in a room pulling strings. It's a system doing what it was designed to do. ## Discovery Mode and the Pool {: #discovery-mode-pool } **Discovery Mode is perhaps the clearest example of this dynamic.** Introduced in 2023, it allows artists to accept a reduction in royalties—up to half—in exchange for priority in recommendation algorithms. It's brilliant, in a way that makes me uncomfortable. Spotify isn't directly manipulating the algorithm—it's incentivizing artists to voluntarily give up part of their earnings to gain visibility. The result is that those who can afford to earn less get more exposure, while those who need every cent remain in the shadows. And from an infrastructure perspective, the system wins twice: it pays fewer royalties and gets predictable traffic, perfectly optimizable. The underlying economic model amplifies all of this. Spotify doesn't pay artists per stream linearly. It uses a pool system: all subscriptions go into a pot, and that pot is divided proportionally among artists based on their streams. This means that when an artist gains streams, they're not adding to the pie—they're taking a bigger slice of a pie that stays the same size. And who are the artists gaining more streams? Those in editorial playlists. The system rewards those already rewarded, penalizes those already penalized. An independent artist would need two hundred fifty thousand streams to earn one thousand dollars gross. If half goes to distributors and rights, that leaves five hundred dollars net for the work of composing, recording, promoting. For an entire album. Meanwhile, an artist who gets an editorial playlist can receive millions of streams in a week, generating tens of thousands of dollars. It's a lottery, and the house controls who wins. What strikes me is how all this is invisible to the average user. You open Spotify, you see an apparently infinite selection of music, you feel like you have the world at your fingertips. But that selection is filtered, sorted, prioritized by systems that have their own incentives, their own technical necessities, their own business models. You're not exploring a neutral archive. You're navigating a territory shaped by forces you don't see. ## Filter Bubbles and Homogenization {: #filter-bubbles } Researchers talk about filter bubbles and echo chambers. Recommendation algorithms tend to suggest music similar to what you've already listened to, creating self-reinforcing cycles. You listen to indie pop, the algorithm suggests more indie pop, you listen to even more indie pop, and before you realize it you're trapped in a genre you might never have consciously chosen as your musical identity. **The diversity of the offering doesn 't translate to diversity of experience.** There's something deeply ironic in all this. Music streaming was born with the promise of democratizing access to music. Any artist can upload their music, any listener can access millions of songs. In theory, the barriers to entry have disappeared. In practice, they've been replaced by different barriers—more subtle, harder to see and therefore harder to contest. It's not that you can't get in. It's that once inside, you're invisible unless the system decides to show you. I often think about what all this means for music as an art form. Experimental, niche, innovative music—the kind that by definition doesn't fit predictable patterns, the kind you can't pre-cache because you don't know who'll listen to it—is structurally penalized. Not because someone hates it, but because the system's architecture doesn't favor it. **The economic incentive goes toward homogenization, toward repeating formulas that work, toward predictability that reduces costs.** ## Conscious Resistance {: #conscious-resistance } I obviously don't have solutions. I don't believe Spotify is evil, nor that we should go back to vinyl or CDs. Technological progress has brought real benefits: universal access, reduced costs for listeners, the possibility for independent artists to reach a global audience without going through major labels. But it seems important to understand what we're losing while gaining all this. To understand that when we open an editorial playlist we're not simply listening to curated music—we're participating in an economic and technological system that has its interests, its logics, **its consequences**. Perhaps the most important thing is to keep alive a form of conscious resistance. Actively seek music outside algorithmic recommendations. **Go to concerts, discover local bands, follow independent blogs and magazines, talk to friends who have different tastes than ours.** Use streaming for what it is—an extraordinarily convenient tool—without forgetting that every tool shapes the use we make of it. That evening in the club in Pescara, going home after the concert, I realized the experience I had lived wasn't replicable on Spotify. Not because the music was different, but because the context was different. The discovery had happened through chance, physical presence, word of mouth from a friend (thanks Kris!) who had dragged me there. No algorithm had mediated it, no system had optimized it. It was inefficient, unpredictable, impossible to scale. And perhaps precisely because of that, it was alive in a way no editorial playlist can ever be. What leaves the most bitter taste in my mouth is the awareness that all this isn't an accident. It's the predictable result of a system that put business in command and used technology as a control tool. **Songwriting, art, musical exploration—everything that by its nature is unpredictable, personal, irreducible to formula—has been systematically marginalized.** No conspiracy was needed. It was enough to build an infrastructure that rewards the homogeneous and penalizes the different, and then let the market do its work. We hear the result every day. Songs that seem to come from the same factory, identical structures, predictable drops, interchangeable lyrics. Not because musicians are less talented than before, but because **talent that doesn 't fit the format gets filtered out before it even reaches our ears**. The algorithm selects, the playlist amplifies, the loop closes. And whoever doesn't enter the loop simply doesn't exist. ## The Reckoning With Suno {: #suno-reckoning } What I find almost comical, in a tragic way, is that the same music industry is now trembling before Suno and other AI-based music generators. **Suddenly everyone realizes that maybe, just maybe, they should have valued what makes an artist irreplaceable instead of treating them as a provider of fungible content. They spent twenty years compressing royalties, pushing toward homogenization, building systems where music is a commodity to be optimized. And now they 're surprised that someone built a machine capable of producing musical commodities at zero cost?** The irony is perfect. They trained the public to accept generic, predictable, interchangeable music. They built playlists where one song is as good as another, where the artist's identity is irrelevant, where all that matters is that the sound fills the background without disturbing. And now that same music can be generated by an AI in thirty seconds, without paying anyone. What did they think would happen? I have no compassion for an industry that chose to kill what made it necessary. If you spent decades convincing the world that music is just background entertainment, you can't complain when someone finds a cheaper way to produce background entertainment. The value of art lies in its uniqueness, in personal vision, in human imperfection. Everything you systematically eliminated in the name of optimization. That evening in the club in Pescara, and then going home after the concert, I understood something I couldn't articulate at the time. The music I had heard wasn't optimizable. It didn't fit any playlist, didn't adapt to any algorithm, didn't generate predictable patterns. It was inefficient, uncomfortable, impossible to scale. And it was alive in a way that no system based on predictability will ever be able to replicate, neither human nor artificial. Songwriting might survive. Art might survive. But not thanks to the streaming industry or the music industry at large. It will survive despite it, in small clubs, in independent productions, in niches that algorithms can't see. And when the current business model collapses under the weight of its own contradictions, crushed by music generators that do exactly what the system has always asked for, perhaps someone will remember there was an alternative. That it was possible to choose to value art instead of optimizing it. **And perhaps it will be too late.** --- # From Code Writers to Spec Architects - **URL:** https://margiovanni.it/en/blog/from-code-writers-to-spec-architects/ - **Published:** 2026-01-10 - **Tags:** Training, AI, Software Development - **Reading time:** 7 min > I spent the morning reviewing materials for an internal training course. Twenty-six dense pages, full of workflows, commands, checklists. At one point I stopped and looked out the window and asked: when did all of this happen? ![](https://substackcdn.com/image/fetch/$s_!nPnQ!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F59a15f1a-bc2b-47bb-9899-6ad8d9f873d9_1024x1024.png) I spent the morning reviewing materials for an internal training course. Twenty-six dense pages, full of workflows, commands, checklists. At one point I stopped and looked out the window. I asked myself: when did all of this happen? A year ago we were still debating whether or not to use Copilot for autocomplete. Today we write documents called "Constitutions" that govern the behaviour of AI agents that generate entire features. The jump wasn't gradual. It was like waking up one morning and discovering the floor had shifted a few centimetres during the night. ## Vibe coding and its seduction {: #vibe-coding-and-its-seduction } There's a term that struck me while I was preparing the material: *vibe coding*. Vaguely describe what you want and let the AI produce something. We all did it, in the first months. There was something almost magical about seeing code appear out of nothing from a rough description. Did it work? Sometimes yes, often no. But the sense of speed was intoxicating. The problem is that the speed was an illusion. Code generated that way, without precise specs, without thought-through architecture, was accumulating technical debt at an impressive rate. Every feature added was a bet. Maybe it works today; maybe tomorrow everything breaks when someone touches something else. I've watched POCs launch like rockets and crash within a few weeks. Not because the AI got it wrong, but because no one had thought about what we were building. We were improvising with an extremely powerful instrument without a score. ## The spec as a new form of expression {: #the-spec-as-a-new-form-of-expression } The answer we're exploring, and trying to teach in the course, completely flips the approach. It's called spec-driven development and the underlying idea is simple, almost banal: first you write what you want with maniacal precision, then you let someone else (in this case, an AI agent) implement it. But there's an aspect that fascinates and disturbs me at once. Writing precise specs is tremendously hard. It requires thinking through every edge case, every error scenario, every possible ambiguity. It requires knowing exactly what you want before you've seen it work. In a sense, it's the opposite of how many of us learned to program. I learned by experimenting, trying, failing, correcting. A continuous loop of trial and error that eventually produced something that worked. Now we're being asked to think everything through up front, to be precise before writing a single line of code. I'm not sure it's a purely positive change. We probably lose something in the experimentation, in the accidental discovery of elegant solutions that emerge while you write. But we maybe gain something else: the chance to build systems bigger and more complex than we could have built alone. ## The skills paradox {: #the-skills-paradox } One thing that has made me think a lot is the skills paradox emerging from this new way of working. In the document I prepared there's a sentence I underlined more than once: > This doesn't mean technical skills become obsolete. The opposite—even more solid skills are required. It sounds counter-intuitive. If AI writes the code, why should I know how to program? The answer is that you have to know how to program *better* than before to tell whether what the AI produced makes sense. To validate the architecture. To spot security issues. To know when something is a fragile workaround masquerading as an elegant solution. I've watched juniors get excited about AI-generated code without realising it contained serious vulnerabilities. Unparameterised queries, missing validations, hardcoded secrets. The AI had copied insecure patterns it saw in training data. Someone with experience was needed to notice. In a way, we're becoming full-time reviewers. Our work is shifting from production to supervision, from writing to critical reading. I don't know whether that's a loss or a gain. Maybe both. ## The Constitution and the illusion of control {: #the-constitution-and-the-illusion-of-control } In the framework we're adopting there's a central concept: the Constitution. It's a document that defines the project's immutable principles. Things like "no `any` types allowed" or "minimum 80% coverage" or "every PR requires a human code review". The idea is that the AI must respect these principles in every decision. Does it work? **Largely yes**. The AI follows the rules when you give them clearly. But there's something slightly ironic about all this. We're writing constitutions for machines. Defining laws that algorithms must follow. It's an interesting inversion of the relationship between humans and tools. What I wonder, and don't yet have an answer to, is **how far written rules can capture what we actually mean**. I can write "no workarounds or hacks in the code" but how do I define exactly what a hack is? Sometimes the line between a pragmatic solution and a hack is blurry, contextual, requires judgement. **That judgement, for now, stays human.** ## The time that isn't there anymore {: #the-time-that-isnt-there-anymore } One thing that has changed subtly but deeply is the relationship with time. Before, when I estimated how long a feature would take to implement, I thought in hours or days of work. Now I think in terms of how much time I need to write a precise enough spec and to validate the output. Paradoxically, sometimes it takes longer. Writing a complete spec, clarifying every ambiguity, defining every edge case can take as long as I would have spent writing the code. But the kind of work is different. It's more mental, more abstract. Fewer hours staring at a debugger, more hours thinking. Not everyone on the team is comfortable with this shift. Some colleagues loved exactly that flow feeling, when code streams from your fingers, when you're immersed in the problem and solutions emerge almost by themselves. That mental state is rarer now. The work has become more fragmented, more about review and validation than continuous creation. ## Security as necessary obsession {: #security-as-necessary-obsession } There's an aspect of AI-generated code that obviously makes me restless: security. In the course materials I dedicated a whole section to specific risks. Insecure patterns, vulnerable dependencies, unparameterised queries. AI doesn't have malice, but it doesn't have prudence either. It reproduces what it has seen, mistakes included. What worries me is that many of these problems aren't obvious at first sight. The code compiles, the tests pass, the application works. The vulnerability is hidden, silent, waiting for someone to find and exploit it. You need an experienced eye to spot it. You need time for meticulous reviews. We've added automated tools to the pipeline: dependency audits, secret scanning, static analysis. They help, but they aren't enough. In the end, someone has to sit down and read the code line by line asking: what could go wrong here? And I've learned (again) the importance of E2E tests. ## What's left of us {: #whats-left-of-us } Sometimes I wonder what will be left of our craft in five years. Not in the apocalyptic sense of "programmers will be replaced", which strikes me as a simplification. But in the sense of what we'll actually do, day by day. We'll probably write less code and more specs. We'll read more code than we write. **We'll spend more time thinking about architecture, security, the implications of every choice. We'll be less craftspeople and more architects, less builders and more supervisors.** I don't know whether anyone will like it. Many people liked writing code. Many liked the feeling of building something with their own hands, even if the hands were only metaphorical. Maybe that feeling will turn into something else. Or maybe people will look for it elsewhere, in personal projects where no one forces you to be efficient. ## A craft in transition {: #a-craft-in-transition } What I'm trying to convey in the course, beyond the commands and checklists, is the awareness that we're in a moment of transition. We don't yet know where we're going, but **we know we won't go back**. Vibe coding was an experiment, an adolescent phase in the use of these tools. Now we're trying to grow up, to build processes and disciplines that let us use this power without hurting ourselves. It's a work in progress, obviously. A few months from now I'll probably revisit this material and find it already obsolete. Something will have shifted again. The tools will be different, the workflows will have evolved. It's the beauty and the curse of working in a field that moves this fast. For now, what I can do is document what we learn, share it with the team, try to build skills that go beyond the specific tool. The capacity to think in a structured way, to write precise specs, to critically validate someone else's output: these strike me as skills that will stay useful whatever happens, and that will give value to the people who hold them. Or, at least, that's what I keep telling myself lately. --- # AI and the Vicious Cycle That Risks Killing Open Source - **URL:** https://margiovanni.it/en/blog/ai-and-the-vicious-cycle-that-risks-killing-open-source/ - **Published:** 2026-01-09 - **Tags:** Ethics, AI, Open Source - **Reading time:** 11 min > There's a sentence from Adam Wathan that struck me, that I've been thinking about for two days since he posted it. ![](https://substackcdn.com/image/fetch/$s_!7Gjm!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3262bd77-2b59-4412-911e-24d37ba3379b_1934x1378.png) There's a sentence from Adam Wathan that struck me, that I've been thinking about for two days since he posted it. He wrote it the day after laying off three quarters of his engineering team. It was [a reply to a pull request on GitHub](https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957), one of those apparently innocuous technical requests that normally pass unnoticed. But Wathan's reply wasn't technical. It was a cry of pain disguised as a rational explanation. For those who don't know him, Wathan is the creator of Tailwind CSS, one of the most-used frameworks in the world for web development. If you've worked on the front-end in recent years, you've probably crossed paths with Tailwind. It's everywhere, with 75 million downloads a month. It's the dream of open source realised: a free project, loved by the community, that had found a sustainable model to exist. *Had*. Because now that model is in pieces, and the reason should alarm us and make us ask questions. Tailwind Labs' revenue collapsed by 80%. In one year. Not because the project is in decline—on the contrary, it has never been more popular. It collapsed because AI changed how developers use software. And that, when I think about it, frightens me much more than any other consequence of AI we usually talk about. To understand what happened you have to go back a few years and look at how Tailwind's business model worked. The framework is open source, free, accessible to all. But the team also built Tailwind UI, a premium component library they sell. It's one of the classic open source models: offer something free and valuable, build a community, and a percentage of that community ends up buying the paid products. In 2020, Tailwind UI made $500,000 in the first three days after launch. Within five months it had passed two million. In 2024 the team had grown to eight people, with engineer salaries of $250,000–$300,000. It was the living example that sustainable open source is possible. ## Wathan's Cry of Pain {: #wathan-cry-of-pain } Then AI arrived. Since 2023, traffic to Tailwind's documentation has dropped 40%. Not because developers stopped using Tailwind. On the contrary, usage is at all-time highs. But because when you need a Tailwind component, you no longer go to tailwindcss.com. You open Copilot, or Claude, or Cursor, and you say "make me a button with Tailwind". And the AI generates it for you. Instantly. Without ever touching the official site. Here's the point that obsesses me: the documentation was the funnel. It was the moment developers discovered that Tailwind UI, the premium version, also existed. But if developers never visit the documentation, they never discover the paid products. The funnel has been completely short-circuited. AIs have removed the intermediation, that productive friction that allowed open source projects to monetise. Wathan says it with a clarity that almost hurts: > Tailwind is growing faster than ever and is bigger than ever, and our revenue has dropped almost 80%. At the moment there's no correlation between making Tailwind easier to use and making the development of the framework sustainable. I've reread that sentence several times. There's no correlation between improving your product and making it sustainable. It's the death of the model. It's the end of an era. ## The Funnel Short-Circuited {: #funnel-short-circuited } The pull request that triggered all this was a request to add an `llms.txt` file to the Tailwind repository. It's an emerging standard, a way to make documentation more easily readable for Large Language Models. Other projects have already adopted it. It looks innocuous, almost obvious. But Wathan closed it with an explanation that became an involuntary manifesto of the open source crisis. > We have more important problems to face, like raising funds to keep the business afloat. Making our documentation more readable for LLMs will only further reduce visits to the documentation, and fewer users will discover our paid products, further reducing the sustainability of our business. Some criticised him. They told him the message he was sending is selfish, that he puts money before service to the community. But this is where the situation becomes really tragic, because Wathan is right. Completely right. And there is no winning choice. ## No Winning Choice {: #no-winning-choice } I tried to think about the options he has, and none of them works. If you block the LLMs, add aggressive rules in robots.txt, prevent OpenAI and Anthropic and Google crawlers from scraping the documentation, what happens? The LLMs stop knowing your project. Developers using AI assistants no longer get suggestions based on your documentation. Your project becomes invisible in an era when 84% of developers use AI tools. You lose userbase. You lose relevance. You lose everything. If you don't block LLMs, you let bots scrape freely. The LLMs train on your content. They get great at generating code that uses your framework. Developers love it. But they never visit your site. They never discover your paid products. Revenue collapses. You have to fire the team. The project becomes unsustainable. If you add `llms.txt` to "help" the LLMs, you make the documentation even easier for AIs to digest. The LLMs get even better at answering without sending users to your site. You accelerate your own economic obsolescence. It's like sharpening the knife for whoever is stabbing you. There's no winning choice. It's literally a deadly vicious cycle. And what makes me shudder is that it isn't only Tailwind. ## It Isn't Only Tailwind {: #beyond-tailwind } Stack Overflow, the Mecca of programming questions for twenty years, has seen submissions collapse from peaks of 200,000 a month in 2014 to less than 50,000 at the end of 2025. 47% of daily active users have simply disappeared. Now 81% of developers use ChatGPT (or alternatives) for the questions they once asked on Stack Overflow. Traffic kept dropping even after Stack Overflow blocked GPTBot and then lifted the block for a partnership with OpenAI. Nothing changed: users had already changed behaviour and habits. Business Insider has recorded traffic drops between 40% and 48%. "Zero-click searches"—queries where the user gets the answer directly on the results page without clicking any site—now make up 62% of all searches. 2025 has been called "the organic traffic crisis". Read the Docs, GNOME, SourceHut, LWN, Fedora—all open source projects, all under siege from AI crawlers. GNOME GitLab had significant downtime. They had to implement reverse proxies with proof-of-work challenges to block the most aggressive bots. But it's a battle lost from the start, because bots become more sophisticated, pay for accounts to look human, falsify TLS fingerprints. Some are trying to find ways out. Cloudflare launched "Pay Per Crawl" in June 2025. The idea is elegant: instead of blocking or allowing for free, you can charge AI crawlers per request. You use response code 402, "Payment Required", dormant for decades. Cloudflare acts as intermediary and you set a price per request. On paper it could shift more than two billion dollars from AI companies to publishers by 2027. But there's a problem: it works only if a critical mass of publishers adopts it. If you're alone in setting up the paywall, AI companies ignore you and go elsewhere. It's a classic coordination problem, and historically the open source ecosystem has never been good at coordinating on this kind of thing. ## The Next Chapter: Model Collapse {: #model-collapse } There's an aspect of this story I find particularly disturbing, and few are noticing. If developers stop posting questions on Stack Overflow, if they stop writing detailed technical documentation because "the AI will generate it anyway", what will future AI models train on? It's a circularity problem. **Current LLMs trained on decades of high-quality human-generated content: carefully written tutorials, questions and answers on forums, detailed technical documentation.** But if that source dries up because it's economically unsustainable, what happens? AIs start training on output generated by other AIs. **It's the "model collapse" phenomenon, and it leads to progressive degradation of quality.** Wathan himself experienced something like this. He tried to use Claude to add dark mode to over 600 Tailwind UI components. He said the results were so inconsistent that reviewing and fixing the agent's work took longer than doing everything by hand from the start. Even for apparently simple tasks, current LLMs have obvious limits in the absence of quality documentation. The more I think about it, the more I'm convinced there's no win-win solution here. Or at least, none that preserves the current model of sustainable open source. Traditional monetisation models—open core, SaaS hosting, premium add-ons, professional services—were all based on an assumption: that there was a moment of contact with the user. A moment when the user came to know your project, visited your documentation, saw your brand, discovered your commercial products. That moment was the funnel. It was where you could convert free users into paying customers. AI tools have completely short-circuited that funnel. Developers don't "visit" anything anymore. They ask Copilot and Copilot generates the code. AI has become a total intermediary between users and open source projects. And that intermediary doesn't pay commissions. If improving your product no longer leads to greater economic sustainability, the project is destined to die or be absorbed by a big tech that can afford to maintain it without monetising. ## The End of an Era {: #end-of-an-era } While I was reflecting on this, I found myself with more questions than answers. And they're heavy questions, the kind that keep me awake. Can open source survive without big tech backing? If projects can no longer monetise, only those sponsored by Google, Meta, Microsoft will survive. But is it really open source if it's controlled by corporations? Or is it just "source-available" with an aura of community? **Do we need a new social contract?** Some talk about treating open source as "digital public infrastructure" and funding it with public money. But which government wants to fund thousands of software projects? **And who decides what deserves the funding?** Should AI providers pay for training data? Intuitively it seems right. But how do you implement it? With what legal mechanism? And if data is released under an open source licence, how do you impose payment without violating the principles of open source itself? Is this a temporary or permanent transition? Maybe in a few years new business models will emerge that we can't even imagine today. Or maybe not. Maybe we're watching the end of an era, and what comes after will be radically different from everything we knew. There's an almost comic irony in this tragedy. Tailwind is a victim of its own success. LLMs are so good at generating Tailwind code precisely because Tailwind did an exceptional job of creating clear documentation, practical examples, an active community. All that high-quality data trained the AIs perfectly. But that quality is now the weapon killing it. It's as if you'd spent years creating the best programming course in the world, free, accessible to everyone. And then someone builds a robot that watches all your videos, memorises everything, and starts answering students' questions in your place. The better your course, the more effective the robot. And you stay there, watching while students stop visiting your site, because they have the robot. I don't know if there's a way out of this vicious cycle. I don't know if Wathan will manage to save Tailwind Labs. I don't know what will happen to all the other open source projects in the same situation. What I know is that we're at a turning point. AI promised to democratise software development, to make programming accessible to everyone. And probably in some way it's doing that. But the cost may be the entire infrastructure of open source projects, quality documentation, communities of experts that for decades made that democratisation possible. When the last sustainable open source project closes, what will future AIs train on? It's a question I have no answer to. And maybe the very fact that there's no obvious answer is the most worrying thing of all. **Maybe what we're living through is the moment when the open source ecosystem discovers it was too generous, too open, too trusting. Our sector was the only one that decided knowledge and innovation should be distributed publicly.** It gave knowledge to the world for decades, building the foundations on which almost all modern software rests. And now that knowledge has been extracted, processed, and turned into commercial products that are its direct competitors. It isn't anyone's fault in particular, perhaps. It's the inevitable result of misaligned incentives, of an economic model that rewarded openness without considering long-term consequences. But the result is the same: **an entire generation of developers who built incredible things may end up without the means to keep doing it.** And that, for someone like me who has always believed in the power of open source, is simply devastating. --- # When Truth Becomes a Process - **URL:** https://margiovanni.it/en/blog/when-truth-becomes-a-process/ - **Published:** 2026-01-08 - **Tags:** Ethics, Information, Society - **Reading time:** 13 min > There's a precise moment I realised something had broken in my relationship with knowledge. ![](https://substackcdn.com/image/fetch/$s_!tv-8!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3a6d6885-c45c-4794-927c-074eddd5527f_1013x745.png) There's a precise moment I realised something had broken in my relationship with knowledge. I was watching a video on YouTube, an interview with a politician saying things that struck me as absurd. I thought: must be a deepfake. Then I stopped. I had no real reason to think it, no visual glitch, no anomaly in the lip-sync. The doubt had simply become my default reaction. And that, I realised, changes everything. I studied philosophy for years before turning to computer science, and that combination has always made me feel astride two worlds that struggle to talk to each other. On one side the Western epistemological tradition, with its obsession for the correspondence between thought and reality, that *adaequatio rei et intellectus* of Thomas Aquinas that still echoes in our most basic intuitions about what it means for something to be true. On the other side the world of algorithms, statistical patterns, neural networks producing texts and images indistinguishable from human ones without the slightest idea of what they're doing. Two different languages, two different ontologies, and maybe two different eras that have ended up cohabiting in the same historical moment. ## The Liar's Dividend {: #dividendo-del-bugiardo } What worries me most isn't that deepfakes exist. It's that their mere existence has changed how I look at everything else. Scholars call it the "liar's dividend": even without creating a single fake video, deepfake technology lets anyone discredit any authentic evidence simply by saying "it must have been AI-generated". It's brilliant, in a perverse way. You don't need to substitute one truth for another. You just need to create enough noise to make every certainty impossible. I often wonder whether postmodernism prepared us for this or only made us more vulnerable. Lyotard proclaimed the end of grand narratives in 1979; Nietzsche, a century earlier, talked about truths as "illusions whose illusory nature has been forgotten". There was something liberating in that critique, a way to unmask the power hiding behind claims to objectivity. But now I wonder whether we haven't demolished the tools we'd need to distinguish deliberate disinformation from legitimate plurality of interpretation. It's a thought that makes me uncomfortable, because it sounds reactionary, and I don't think I am. But the discomfort is maybe the signal that there's something to understand. When I read that in 2023 nearly a hundred thousand deepfake videos were detected, with a 550% increase since 2019, when I find out that today you can manipulate a video call in real time at a cost below two euros, I realise we've entered a territory where our epistemological intuitions no longer work. For millennia we took for granted that seeing was believing, that a photograph was evidence, that a video showed reality. All this is over, and I'm not sure we're truly aware of it. ## Algorithms and Filter Bubbles {: #algoritmi-bolle-filtro } There's a phrase by Walter Quattrociocchi that stuck with me: "in the era of platforms and artificial intelligence, truth is no longer objective but shaped by the algorithm". The first time I read it, it sounded exaggerated, almost a rhetorical provocation. But the more I think about it, the more it sounds like an accurate description of what we're living. Recommendation algorithms aren't neutral instruments showing us relevant information. They're active agents in constructing our perceived reality. They decide what we see, in which order, with what frequency. And they do so optimising engagement metrics, not truth. The result is what Eli Pariser called filter bubbles, places where we see only content consistent with our pre-existing beliefs. And echo chambers, places where our opinions get amplified and reinforced by people who think like us. Research on Twitter during the pandemic showed that users with right-wing political orientations formed particularly dense echo chambers, with 80% of their audience composed of similar people. But it isn't only a problem of the political right. It's a structural problem, inherent in the very architecture of platforms. What strikes me is how invisible this process is to those it affects. No one tells you "you're entering a bubble". Your feed simply populates with content you like, opinions you share, people who think like you. And you think you're seeing the world, when actually you're seeing an increasingly distorted reflection of yourself. ## Post-Truth and Common Ground {: #post-verita } I've spent a lot of time thinking about the concept of "post-truth", that word the Oxford Dictionary chose as word of the year in 2016. The official definition speaks of a condition where "objective facts are less influential in shaping public opinion than appeals to emotion and personal beliefs". But it feels like something is missing. It isn't only that emotions count more than facts. It's that the very concept of "fact" has become contestable, that the possibility of a common ground on which to build **disagreement** has eroded. Maybe this is what frightens me most. A democracy can survive disagreement—in fact, it needs it. But can it survive when there's no longer agreement even on what counts as a fact? When every claim can be dismissed as fake news, every piece of evidence as manipulation, every expert as part of a conspiracy? I often think about the COVID-19 pandemic as a large-scale natural experiment. We had a real virus, with real consequences, and a scientific system trying to understand it in real time, with all the limits and uncertainties that implies. And we saw how the digital information ecosystem amplified the confusion, turning legitimate scientific uncertainty into material for conspiracy theories, creating polarisation even on questions that should have united us. The World Health Organization coined the term "infodemic" to describe that overabundance of information, some accurate and some not, that made it hard for people to find their bearings. But maybe the term understates the problem. It wasn't just too much information. It was an ecosystem designed to reward engagement over truth, polarisation over understanding. Confirmation bias is as old as humanity. We tend to look for, interpret, and remember information that confirms what we already believe. But algorithms have transformed a psychological tendency into a technological architecture. They've automated confirmation bias, industrialised it. And so what used to be a cognitive defect to correct has become a business model to optimise. The speed at which fake news spreads compared to verified information strikes me. An MIT study showed false news on X propagates six times faster than true news. It's no accident. Fake news is designed to be emotionally engaging, sensational, polarising. It leverages our instinctive reactions, the brain centres that respond before the prefrontal cortex has time to analyse critically. It's a form of cognitive hacking, and it works because it exploits the same vulnerabilities that let us survive as a species. ## LLMs and the End of Truth as State {: #llm-verita-stato } What fascinates me, in a disturbing way, is how AI is changing not only the quantity but the quality of possible disinformation. Large language models like GPT don't know what's true. They have no access to an external reality to verify. They're statistical machines predicting which word comes after another, based on patterns learned from billions of human texts. But the result is so convincing, so fluid, so apparently reasoned, that it's incredibly easy to forget what's actually happening under the hood. A philosopher I read recently asked a question that made me think for a long time: "what does it mean for a system to 'know' something if it has no awareness or intentionality?" It's a question that touches the heart of what we've always thought knowledge was. For Plato, knowledge was justified true belief. But can there be belief without a subject who believes? Can there be justification without understanding? Are we maybe witnessing the emergence of a purely inferential, functional, statistical "knowledge"—without that link to the world that Western philosophy has always considered essential? I have no answers, only questions. But maybe that's right. Maybe at this moment questions are more important than answers. ## Onlife and Cognitive Hybridisation {: #onlife-ibridazione } There's a concept Luciano Floridi introduced that helps me think about our condition: "onlife". The idea is that the boundaries between online and offline, digital and physical, real and virtual are dissolving. We no longer live in the physical world with occasional excursions into the digital. We live in a hybrid space where the two dimensions interpenetrate. And this changes not only how we know but who we are. I recognise myself in this description. My digital self isn't a mask I wear when I go online. It's part of me, a part that interacts with algorithms, expresses itself through avatars, delegates portions of its identity to profiles on platforms I don't control. It's a form of hybridisation my grandparents would probably have struggled to understand, but for me it's simply normal. And that makes me think how quickly we adapt to changes that, viewed from a certain distance, are radical. Hybridisation isn't only digital. Millions of people live with pacemakers, prostheses, implants. Our evolution toward the cyborg is already under way, and is much less science-fictional than we imagine. But while physical hybridisation has generally been welcomed as medical progress, cognitive hybridisation produces more ambivalence. Maybe because it touches something more intimate, something we consider the core of our being: thought, reason, the capacity to know. What worries me isn't hybridisation itself. It's the possibility that we're delegating too much to machines without understanding what we're losing. There's a quote from Hannah Arendt that has haunted me since I read it: > If knowledge were irrevocably separated from thought, then we would become hopeless beings, slaves not so much of our machines as of our competence, thoughtless creatures at the mercy of every technically possible device. Arendt was writing in the 1960s, long before the internet, before social media, before generative AI. But her words seem to describe a risk much more concrete today than it was then. Studies on digital natives show worrying tendencies: superficial information processing, rapid attention shifting, reduced capacities for prolonged reflection. It isn't a moral condemnation, it's a description of how our brains are adapting to an information environment designed to capture attention rather than feed understanding. And I wonder if we're creating the conditions for that separation between knowledge and thought Arendt talked about. But maybe I'm too pessimistic. Maybe every generation has thought the next was losing something essential, and every time history has refuted that pessimism. Or maybe this time it's different. I don't know. Intellectual honesty makes me admit I don't know. ## Trust and the Limits of Media Literacy {: #fiducia-alfabetizzazione } What I do know is that one result of all this is that the data on trust in institutions is alarming. In Italy trust in the institutional system is below the European average. Only one citizen in five says they trust political parties. Trust in Parliament sits at 37%, in parties at 24%. Even the Presidency of the Republic, traditionally the most respected institution, recorded a significant drop. They aren't abstract numbers. They're the sign of a fracture between society and institutions that makes any collective challenge harder, from ecological transition to digital transition. Trust in traditional media has followed a similar trajectory. And this creates a vicious circle: less trust in media means more vulnerability to disinformation, which in turn further erodes trust. It's a self-reinforcing system, and I don't see how it can stabilise without structural intervention. The European Union tried to respond with the AI Act, a regulation introducing transparency obligations for AI-generated content, including deepfakes. The idea is simple: if you can't prevent the creation of synthetic content, at least you can require those who produce it to label it as such. But I wonder how much it can work in practice. Anyone deliberately creating disinformation won't be stopped by a labelling requirement. **And those consuming it often don't want to be undeceived.** Media literacy gets often cited as the educational answer to the problem. Teach people to verify sources, recognise the signs of disinformation, resist confirmation bias. It's a noble goal, and certainly necessary. But I wonder if it's enough. **Cognitive biases aren't errors that get corrected by education. They're mental shortcuts deeply rooted in our cognitive architecture.** And algorithms are designed by some of the brightest minds on the planet precisely to exploit them. It's an asymmetric arms race, and I'm not sure education can win it alone. Maybe the most important thing is to recognise we aren't facing a technical problem requiring a technical solution. **We're facing an anthropological transformation requiring a deep rethink of what knowing, communicating, trusting mean.** It isn't something solved by an app or a training course. It's something that requires long-term cultural work, a collective renegotiation of what we consider true and how we come to consider it so. ## Truth as a Process {: #verita-come-processo } There's a proposal that strikes me as promising, even if I don't know how realistic: shifting from a conception of truth as state to a conception of truth as process. No longer something one possesses or discovers once and for all, but something built continuously through validation, verification, comparison, revision. Not a relativism where everything counts equally, but a critical realism that recognises both the existence of an independent reality and the mediated, partial, contextual nature of our knowledge of it. It's a hard balance to maintain. On one side there's the risk of a naive objectivism that ignores how much our conceptual categories influence what we see. On the other there's the risk of a relativism that dissolves any criterion of distinction between reliable information and disinformation. Finding the middle path requires a form of epistemological wisdom we may still need to learn how to cultivate. Quattrociocchi wrote something that captures this idea well: > The truth of the future won't be a fixed point, but a process of continuous validation, in which data and knowledge are built more transparently and verifiably. I like this formulation, even if I don't know how realistic it is. But maybe that's exactly the point: we don't know what's realistic because we're in the middle of a transformation whose outcomes aren't yet determined. We can still influence them, if we choose to. When I think back to that video that made me suspect a deepfake, I realise the problem wasn't the video itself. The problem was that doubt had become my default state. I lost something I didn't even know I had: a basic trust in the possibility of distinguishing the real from the fake, the actual from the artefact. And I wonder how many other people are living the same thing, maybe without even realising. I don't know what the road out of this condition is. I don't think there's a simple solution, an intervention that fixes everything. But I think the first step is becoming aware of where we are, of the depth of the transformation under way, of what's at stake. And then, maybe, trying to build something different together. Not return to a past that can't return, but imagine a future where truth is neither an untouchable idol nor an illusion to abandon, but a collective project to take part in. The alternative—what someone has called "hypnocracy", a regime of cognitive control through algorithmic manipulation—seems to me much worse. And we should try and fail rather than not try at all. And maybe this, in the end, is the only way to stay human in an era when humanity itself is being put into question. Don't surrender to cynicism, don't yield to despair, but keep searching, doubting, asking. Even when the answers don't come. **Especially when the answers don't come.** --- # The End of Twitter's Trust and Safety Council: When the Controls Disappear - **URL:** https://margiovanni.it/en/blog/the-end-of-twitters-trust-and-safety-council/ - **Published:** 2026-01-03 - **Tags:** Ethics, Moderation, Social Media - **Reading time:** 12 min > I've noticed that lately, when I think about Twitter—or X, as I should call it now—I get the feeling you get when you go back to a place you loved and don't recognise it anymore. ![](https://substackcdn.com/image/fetch/$s_!y-qZ!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fccae1fdd-81d9-42ae-b6f4-432c8e9e87bc_1024x1024.png) I've noticed that lately, when I think about Twitter—or X, as I should call it now—I get the feeling you get when you go back to a place you loved and don't recognise it anymore. The walls are the same, but the atmosphere is completely different. That's what happens to me every time I open the app, scroll for a bit, and then close it with a vague sense of unease. Maybe it's the general tone that has changed, or maybe it's the things I see surfacing more easily, without filters. I don't know. But I do know there was a precise moment when something broke, and that moment goes back to December 2022, when Elon Musk dissolved Twitter's Trust and Safety Council. I've spent a lot of time rethinking that story, trying to understand what that council actually was and why its elimination feels so significant to me. The answer I've arrived at isn't simple, and maybe that's exactly why I've grown attached to it. ## What the Trust and Safety Council Was {: #cos-era-il-council } The Trust and Safety Council was created in February 2016 as a response to the criticism Twitter received for its handling of harmful content. About a hundred independent organisations, civil rights experts, academics, activists came together to advise Twitter on how to handle delicate questions. Hate speech, child exploitation, suicide prevention, mental health. They had no decision-making power, let me be clear on this point. They didn't decide which accounts to ban or which posts to remove. They were consultants, people Twitter listened to when it had to make complex decisions. Patricia Cartes, the Twitter employee who created this council, had imagined it as a way to bring a global perspective, to keep the platform from staying too anchored to an American view. And for six years, with all its limits, it had worked. ## Musk's Broken Promise {: #promessa-tradita } When Elon Musk completed his $44 billion acquisition of Twitter on 27 October 2022, he had made a promise that sounded reasonable. He would form a "content moderation council" with "widely diverse viewpoints", and no major decisions would be made before this council met. At that moment, I told myself maybe the worries were overblown. It looked like a prudent, almost reassuring approach. But that promise was never kept. There was never a new council. And the old one, the one that had existed for six years, was progressively marginalised until it disappeared completely. In November 2022 Twitter laid off about half its employees, around 3,700 people. The Trust and Safety team was cut by 15%. Yoel Roth, who led that team, initially tried to reassure everyone, saying the content moderation policies wouldn't change. But it was a fragile defence, built on foundations already giving way. **A few weeks later, Roth resigned.** ## The Yoel Roth Case {: #caso-roth } Yoel Roth's story is the one that struck me most in this whole affair, and I think it deserves to be told in full. He had been at Twitter since 2014, had built the Site Integrity team from scratch up to 220 people. He had worked on important things: the fight against disinformation during U.S. elections, countering information warfare operations. He was, in essence, one of the people who actually knew how the platform's whole moderation system worked. After his resignation, Musk started attacking him publicly. He took a paragraph from Roth's 2016 PhD dissertation, an academic study on Grindr and the dynamics of the LGBTQ community, quoted it out of context, and insinuated that Roth was a defender of paedophilia. It was a total distortion, a deliberately crafted falsehood to stoke online rage. **The consequences were immediate and terrible. Roth received thousands of threats. He had to leave his home with his husband. He sold the house and went into hiding for months. He needed armed protection.** In an MSNBC interview in 2023, Roth said clearly what he thought had happened: > I believe he was trying to ensure I would not speak up about him or the company in the future. And the way he tried to secure that was intimidating me by violence. Every time I reread that sentence I pause. It isn't just a firing, it isn't even just public criticism. It's a deliberate attempt to silence someone through fear and intimidation. And the fact that it comes from the world's richest man, with access to millions of followers, makes it even more disturbing. In December 2022, three key members of the Trust and Safety Council resigned: Eirliani Abdul Rahman, Anne Collier, and Lesley Podesta. In their resignation letter they wrote something that, in hindsight, sounds prophetic: > Contrary to claims by Elon Musk, the safety and wellbeing of Twitter's users are on the decline. Anne Collier, who had been a founding member of the council in 2016, had observed: > It is evident from research findings that, contrary to Elon Musk's assertions, the safety and well-being of Twitter's users are deteriorating. These weren't loose words, they were observations based on years of direct experience. Musk's response was brutal and dishonest. He accused the council—and especially the three members who had resigned—of having done nothing for years against child exploitation. Jack Dorsey, Twitter's former CEO, replied simply: "this is false". And he was right. The council had always had a working group dedicated specifically to child exploitation, including organisations like the National Center for Missing & Exploited Children. ## The Dissolution and the Twitter Files {: #scioglimento-e-twitter-files } On 12 December 2022, Twitter completely dissolved the Trust and Safety Council. The notification email arrived about an hour before a meeting that had been scheduled with the council members. The email was simply signed "Twitter", no personal name. The official reason was that the council "is not the best structure" for receiving external advice. Patricia Cartes, who had created the council in 2016 and left Twitter in 2018, commented with a simple but devastating phrase: > means there's no more checks and balances. I sat with that sentence for a long time. Checks and balances are what keep power from concentrating too much in one place. They're what protects us from abuses. And when they disappear, nothing visible happens immediately. A space simply opens where there used to be a limit. Meanwhile, Musk had launched the Twitter Files, a series of internal-document releases entrusted to journalists like Matt Taibbi and Bari Weiss. The stated idea was transparency, showing how content moderation decisions actually worked. But there was a huge problem: the names of Twitter employees, even low-level ones, were not redacted. A Filipino staff member was doxxed and subjected to severe harassment. Others became targets of conspiracy theories. Decisions made by teams of dozens of people according to company policy were presented as the arbitrary whims of single individuals, each named and pointed at. [Mike Masnick](https://bsky.app/profile/mmasnick.bsky.social), tech journalist, commented after the first release that there really was "absolutely nothing of interest" in the documents, and the few details present contained significant factual inaccuracies. Even Musk eventually got tired of the initiative. But the damage was done. ## Hate Speech and the Advertiser Exodus {: #hate-speech-advertiser } The numbers tell a story Musk has always denied, but that research has documented fairly clearly. A study by Montclair State University found that in the first 12 hours after Musk's acquisition there were 4,778 tweets containing hate speech, while before the acquisition the maximum was 84 tweets per hour. It wasn't just a temporary spike. A study from the University of California, Berkeley, published in PLOS ONE in 2025, analysed hate speech on X from January 2022 to June 2023, finding a steady 50% increase for at least eight months after the acquisition. Transphobic slurs went from about 115 posts a week to 418. Engagement with hateful content rose 70%. And no, there was no reduction in bot accounts, contrary to Musk's promises. I often wonder what that 50% increase really means. They aren't just numbers on a chart. They're real people seeing racist, homophobic, transphobic insults when they open the app. They're marginalised communities feeling less safe in a space they used to frequent. It's a climate that changes, slowly but inexorably, and that affects how people express themselves, what they say and what they don't. Advertisers caught on immediately. In November 2022, big brands like General Motors, General Mills, Macy's, and Volkswagen suspended advertising on Twitter. Musk himself spoke of a "massive drop in revenue". Subsequent data showed Twitter lost half its ad revenue, with more than 500 advertisers stopping spending on the platform. It wasn't only an economic question. It was a vote of no confidence. Advertisers didn't want their brands appearing next to hateful content and disinformation. And when Musk changed policies—reinstating Donald Trump after a Twitter poll in November 2022, removing protections for transgender users from the guidelines in April 2023—advertisers understood the direction was clear. Some came back. Apple, Comcast, Disney, IBM resumed advertising on X in 2024 and 2025, though with much smaller budgets than before. But trust hasn't returned. And maybe it never fully will. There's an interesting paradox in the child-safety statistics. Musk had accused the Trust and Safety Council of not doing enough against child exploitation. But the numbers tell a more complex story. In the second half of 2021, Twitter had removed about 600,000 accounts for child exploitation. In 2022, under Musk, 2.3 million accounts were removed. In 2023 the number jumped to 12.4 million, with 850,000 reports sent to the National Center for Missing & Exploited Children, eight times more than 2022. These are impressive numbers, and they seem to suggest improvement. But I spent some time thinking about it, and realised they could mean the opposite as well. More accounts to remove could mean more abuse material on the platform. And with a Trust and Safety team cut by 15% and an approach favouring automation over human moderation, it's hard to say whether these numbers represent a success or a badly managed crisis. I lack the expertise to give a definitive answer, but the doubt remains. Of the content moderation council Musk promised, there's never been any sign. It was never created, there was never a meeting, there was never an official announcement saying "we changed our minds". It simply vanished, as if it had never been promised. In its place, Musk introduced Community Notes, previously called Birdwatch, a crowdsourced fact-checking system where users can add context to posts. The idea, in theory, is interesting: democratise moderation, give voice to the community. But research shows it's problematic. One study found that in 91% of posts where at least one note was proposed, none reached "helpful" status. The average delay to get a helpful note is 26 hours, well past a post's peak visibility. And 74% of accurate notes related to the 2024 U.S. presidential elections were never shown to users. Community Notes can work, but only if context arrives in time. And in most cases, it doesn't. ## What We Really Lost {: #cosa-abbiamo-perso } Looking back over all this, I realise we didn't only lose an advisory body. We lost a model of governance that, however imperfect, tried to balance different interests: freedom of expression, user safety, the rights of marginalised communities. The Trust and Safety Council wasn't perfect. Some members had complained even before Musk's acquisition that Twitter ignored them. But it was an attempt to do something social platforms still struggle to do: listen to different voices, incorporate external expertise, admit that moderation decisions are complex and require nuance. In its place we have a different model: decisions made "by edict", as Yoel Roth wrote in his New York Times op-ed. One man, with his convictions and prejudices, deciding what's acceptable and what isn't. And when someone criticises or resigns, they're publicly attacked, threatened, forced into hiding. One thing that struck me particularly was the joint letter from 16 members of the Trust and Safety Council after the dissolution. They condemned "the dramatic changes to, and arbitrary enforcement of, content moderation policies and practices at Twitter". They emphasised that the council didn't decide on specific posts or accounts, had no say on investments or the approach to illegal content. And then they said something worth remembering: > We condemn the irresponsible actions of Twitter leadership in jeopardizing the safety of Council members, including those who resigned before Twitter disbanded the Council, by amplifying disinformation about us and the Council's purely advisory role, sparking huge levels of abuse targeted at the resigning members. These were people who had given years, for free, as volunteers, to try to make Twitter a safer place. And they were repaid with disinformation, false accusations, and threats. What happened to the Trust and Safety Council isn't only about Twitter. It's a precedent. It shows what can happen when a platform with enormous impact on public life is controlled by a single person unwilling to accept limits or external counsel. The consequences we're seeing now. X has become a different place. Hate speech has measurably risen. Advertisers fled and only some are returning, very cautiously. Users are migrating to other platforms—Bluesky saw enormous growth precisely as some companies tentatively returned to X. And above all, we lost that small illusion that social platforms could be governed through dialogue with civil society, with independent experts, with people fighting for human rights. Patricia Cartes's phrase keeps coming back to me—"there's no more checks and balances". It sounds exaggerated, but it isn't. When Musk dissolved the Trust and Safety Council, he didn't only eliminate a group of advisors. He sent a message: I don't need external counsel, I don't need experts, I don't need to balance different interests. I decide. And this, in the end, is the part that worries me most. It isn't only Twitter. It's a model that's being replicated elsewhere. Other platforms look at what happened and think they can do the same—free themselves of the inconvenient voices, of those advisors who slow decisions. But those inconvenient voices served a purpose. They reminded us that behind every moderation decision there are real people, real communities, real lives. And that maybe, just maybe, the hardest decisions are the ones that require more time, more listening, more humility. December 2022 feels far away, but its consequences are still here, every time we open X and see what it has become. The question I ask myself isn't so much "how did we get here", because I know that answer by now. It's rather "where are we going". Because if we don't find a way to build those checks and balances into every public-utility service—social platforms as elsewhere—I'm afraid the answer won't please us. --- # Airbus and European Sovereign Cloud: The First Credible Signal of an Awakening? - **URL:** https://margiovanni.it/en/blog/airbus-and-european-sovereign-cloud-first-credible-signal/ - **Published:** 2025-12-29 - **Tags:** Cloud, Europe, Digital Sovereignty - **Reading time:** 9 min > A few days ago I read a piece of news that probably went unnoticed by many, hidden among the geopolitical and tech headlines. A few days ago I read a piece of news that probably went unnoticed by many, hidden among the headlines on geopolitics and technology. Airbus, the European aerospace and defence giant, is preparing a tender worth more than €50 million to move its most critical applications to a "truly sovereign" European cloud. I read it almost by accident, scrolling sector news the way I often do early in the morning, when my head is still clear enough to catch the details that otherwise slip past. ![](https://substackcdn.com/image/fetch/$s_!aCm9!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fda3be29f-fd2c-4cad-9bb2-faddb367486d_1110x624.jpeg) It isn't a technical story, let me say that up front. It's a story of industrial strategy, of geopolitics, of how Europe is starting to look around and ask whether it's really forced to depend on American Big Tech. And I'll admit that as I read the details, the question came naturally: is this the first credible signal of a possible European awakening, or are we watching another big promise on its way to a drawer full of good intentions? The answer, unfortunately, isn't obvious. And maybe that uncertainty is exactly what makes the story interesting. ## What Airbus Is Putting on the Table {: #cosa-mette-in-gioco-airbus } To understand why Airbus made this move, you have to know what it's putting on the table. We're not talking about ordinary data, emails or spreadsheets. We're talking about mission-critical systems that touch the foundations of the company: resource management, manufacturing execution systems, customer relationship management, and especially PLM, the product lifecycle management software that contains all the design data for the aircraft. These aren't details. They're the industrial secrets, the blueprints, the innovations that make Airbus what it is. Catherine Jestin, executive vice president for digital affairs, said it plainly: > we're talking about information that is extremely sensitive from a national and European point of view. We want to ensure it remains under European control. There's a detail that struck me, and it reveals more than it seems at first glance. Airbus itself estimates only an "80% probability" of finding a fully European provider that meets the technical and security requirements. A company that wants to entrust itself to Europe candidly admits it might not find anyone able to do it. I don't know about you, but that gives me a lot to think about. On one side there's the courage to look for an alternative, on the other the bitter awareness that the alternative might not exist. ## The CLOUD Act and Non-Negotiable Sovereignty {: #cloud-act-sovranita } If I asked you why Airbus doesn't simply use Amazon Web Services, Microsoft Azure, or Google Cloud, many would probably answer that they're the best, the most reliable, the ones with the most advanced technology. And you'd be right. They are all of those things. But there's a bigger problem, called the CLOUD Act. It's a 2018 American law that essentially allows U.S. authorities to request data directly from American cloud providers, regardless of where the servers are. Even if your data is hosted in a Frankfurt data centre, Microsoft could be legally compelled to hand it over to the U.S. government if there's a legal order. No international treaty needed. No diplomatic procedure. American law simply prevails. I've spent a lot of time studying this. At first it sounded almost like an exaggeration, one of those concerns of the privacy paranoid. Then I started to see the practical implications, to understand what it means for a European company working in defence, aerospace, sensitive technology. It's a thorn you can't ignore. And Trump's return to the White House has amplified that concern. I'm not saying Trump will do something strange tomorrow, but the uncertainty around transatlantic relations, tariffs, possible federal shutdowns that could halt services, has set off alarm bells across Europe. Digital sovereignty is no longer an elegant phrase to drop into strategic documents. It has become a question of control over data, over what stays in your hands and what doesn't. ## The European Provider Desert {: #deserto-provider-europei } Here, though, the frustrating part of the story begins. If you ask Airbus who the European candidates are to handle this infrastructure, the list isn't long or comforting. There's OVHcloud, the French provider trying to position itself as a serious European alternative. Deutsche Telekom, through its T-Systems division. Scaleway, another French option. SAP, which is developing sovereign cloud platforms. And then Orange, Telecom Italia, and a handful of smaller national players. And the numbers hurt. According to recent data, European providers control only 15% of the overall cloud market in Europe. Just 15%. While Amazon, Microsoft, and Google together control 70%. SAP and Deutsche Telekom, the two European leaders, each have a 2% market share. OVHcloud, with all its ambition, operates in 12 regions worldwide. AWS operates in 105 availability zones across 33 regions. The technological and scale gap is simply enormous, and it's unclear to me how it can be closed in any reasonable timeframe. And then there's the GAIA-X precedent, which still stings when I think about it. If you remember, GAIA-X was the project launched with great fanfare in 2019 by France and Germany to create a sovereign European cloud infrastructure. It was Europe's answer to the American giants. It was supposed to be the Airbus of data, the project that would finally pull Europe out of digital subordination. You know how it ended? Done. Dead. Not for technical reasons but for political ones. France dreamed of a national champion protected by the state, an upgraded OVHcloud. Germany wanted something more open, more federal, more standards-driven. In the squabble between the two, they left openings where Microsoft, Google, Amazon, and even Palantir slipped in. What was supposed to be a European alternative to the American giants became a bureaucratic standardisation lab, completely disconnected from the real market. While GAIA-X committees discussed norms, European companies kept signing billion-euro contracts with American providers. That precedent weighs like a stone on any conversation about European digital sovereignty. And it's a warning Airbus knows well. ## The Palantir Paradox {: #paradosso-palantir } There's something else worth raising, something that emerges between the lines of this whole story. Something no one wants to name explicitly, but which is the real knot. Yes, you can move the infrastructure to Europe. You can have European data centres, European governance, everything you want. But once the data is there, where does it go to be analysed, understood, turned into intelligent decisions? Because Airbus, since 2015, has worked with Palantir to analyse aircraft data. They have a partnership called Skywise that uses Palantir's technology to do extraordinary things: identify factory defects on the A350, predict maintenance, optimise workflows. They've cut delivery times by 33%. It's an impressive result. But Palantir is American. And there's no European equivalent of Palantir. Here's the paradox that gives me pause: you can move the infrastructure, you can have sovereign cloud, but many of the advanced services—AI, next-level analytics—still sit in American hands. It's like building a European fortress and then discovering the key to the most important room is still held by Americans. I often wonder whether this isn't the real dependency Europe struggles to free itself from. Not so much the servers, but the brains. Not so much where the data sits, but who knows how to read it. ## Credible Signal or Rhetorical Exercise {: #segnale-o-retorica } Let me try to look at it from both sides, because it would be intellectually dishonest to do otherwise. On one hand, when Airbus—a company of Airbus's stature—sends such a clear signal to the market, it starts to create demand that wasn't there. Companies move when they see money and commitment from large players. Airbus's choice arrives in a context where other movements are happening: the European Data Act aimed at reducing American lock-in, EU military projects on combat cloud, the investments SAP and Deutsche Telekom are making on sovereign cloud. Other stories are emerging. Public administrations, German agencies, governments starting to migrate off Microsoft services. It isn't a tsunami, but it's a movement. There's awareness that depending entirely on three American companies is a risk. On the other hand, €50 million over ten years is more a political signal than a transformative tipping point for a sector worth tens of billions. The European cloud market reached around €61 billion in 2024 and grew even faster in 2025. €50 million is 0.08% of that market. A drop in the ocean. The gap between European providers and the American giants is enormous and doesn't close fast: > American hyperscalers invest around €10 billion every quarter in capex in Europe. That's a threshold that looks impossible to cross for any European company. Without drastic change, real alliances, perhaps strategic consolidation, and genuine European industrial integration, the risk is another GAIA-X case: big promises, limited impact. And that's certainly worrying. ## What I'll Watch in the Coming Years {: #cosa-guardare } If I want to know whether the Airbus case really is the start of an awakening, I already know what I have to watch in the coming years. First: will other large European groups make similar choices? Defence, energy, utilities, banking. Will they start shifting critical workloads to European cloud? If only Airbus does it, we're looking at an interesting but irrelevant exception. Second: will real consolidation happen among European providers? Or will we keep seeing fragmentation of national solutions, each serving its local market? Because size matters, and 15 small European players will never compete with three global giants. Third: how do European regulators react? And how do American hyperscalers' sovereign cloud offerings evolve? Because AWS, Microsoft, and Google have already worked out which way the wind is blowing. They're offering sovereign cloud services, guaranteeing data residency in Europe, creating local partnerships. If they can offer *enough European to be enough* while keeping their technological superiority, Airbus may stay an elegant but solitary exception. When I look at this story, I don't see either the all-black "Europe is lost" or the all-pink "the awakening is here". I see the first credible signal that something is moving, but also the memory of GAIA-X whispering: careful, this could end badly too. Airbus has the courage to say out loud "we want European sovereign cloud". That matters. It's a signal. But to turn it into real structural change of the market would take a combination of things: serious public investment, consolidation among European players, political courage to protect emerging champions, and a shared vision among European governments of what digital sovereignty really means. And maybe, more than anything, it would take stopping the bickering between France and Germany every time something has to be built together. Because in the end that's where everything always gets stuck. It's always that old European habit of preferring our own national reasons to a common project. **And as long as that's the case, the Americans will always have an advantage that doesn't depend on technology, but on our incapacity to act as a team.** In the meantime, I'll read the next few months with great curiosity. Because it doesn't depend only on Airbus, but on what the others do. And above all on what we Europeans, finally together, will be capable of doing. --- # Quality, Speed, and the Ghost of the Perfect Craftsman - **URL:** https://margiovanni.it/en/blog/quality-speed-and-the-ghost-of-the-perfect-craftsman/ - **Published:** 2025-12-26 - **Tags:** AI, Quality, Software Development - **Reading time:** 9 min > There's a thought that has been with me for months, maybe since AI stopped being a distant promise and became a tool we use every day. ![](https://substackcdn.com/image/fetch/$s_!uwAS!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe044beb3-3b8b-4f65-89ca-5226f62d9477_1800x1200.png) There's a thought that has been with me for months, maybe since AI stopped being a distant promise and became a tool we use every day. It's an uncomfortable thought, because it puts in question some convictions that guided me for years, and that maybe were more fragile than I wanted to admit. It came back to me today when [Prof. Zanero](https://bsky.app/profile/raistolo.bsky.social) reposted this skeet: ![](https://substackcdn.com/image/fetch/$s_!nnqC!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff20904a6-4763-41c8-b80d-65e4aa5ce8e2_1190x1598.png) ## An Uncomfortable Thought {: #un-pensiero-scomodo } The thought is this: absolute quality, the kind sought as a value in itself, may be a luxury we can no longer afford. Not always, not everywhere, not as a universal principle. I write that and already hear the objections, the same ones I made to myself for a long time. "But quality always pays", "Technical debt accumulates", "Anyone who cuts corners fails in the long run". All true, in a sense. And all things that deserve to be re-examined in light of a world that has changed faster than we were ready to accept. I've spent years building teams, defining standards, fighting to have time to do things "properly". I argued with sales people who wanted everything yesterday, with clients who didn't understand why more time was needed, with developers who wanted to ship something imperfect. And in most cases I think I was right. But the right of then isn't necessarily the right of now, and part of my work is to distinguish immutable principles from habits dressed up as principles. The point was never speed versus quality, as if they were two opposite poles to choose between. The point was always: which quality, for whom, when, and how much does it cost me to maintain over time? Only today this question has different answers from the ones I was giving five years ago, because AI has changed the rules of the game in ways we're still trying to understand. When a generative model can write working code in a few seconds—code that once would have taken hours—the perception of value changes. I'm not talking about real value, I'm talking about perception. And in business perception counts, sometimes more than reality. A client who watches a competitor shipping features at a fast pace starts wondering why we're so slow. And it isn't enough to explain that our code is cleaner, more tested, more maintainable. Those are things they'll only understand when they have a problem, and at that point it might be too late for everyone. ## When Craftsmanship Works {: #quando-artigianato-funziona } The pure artisan model, the "we do everything by hand, calmly, with care" model, still works. But it works only in specific conditions that don't always hold. You need a truly critical problem, where an error costs dearly. You need few credible competitors, because if there are many, the client has alternatives. And you need a client willing to pay a lot to sleep at night, which means a client who understands the risk and has the resources to mitigate it. When those three conditions align, craft wins. When even one is missing, the promise "we do everything by hand, very well" risks being perceived as slowness and cost rather than value. And it isn't the client's fault if they don't understand—it's our responsibility to find a way to communicate that value or, if we can't, to adapt to the market that actually exists. ## Quality as Progressive Investment {: #qualita-investimento-progressivo } Maybe the trick is to stop thinking of quality as an absolute and start treating it as a progressive investment, tied to the product's stage and the actual needs of the moment. It's a perspective that took me time to accept, because it goes against the instinct of someone who grew up professionally believing things should be done well or not done at all. At the start of a product, when you're still trying to figure out if there's a market, you need something reliable enough on a very small perimeter. You don't need perfection. You need something that works, doesn't crash on first use, and is designed cleanly enough to grow without imploding. It's the idea some people call "simple, lovable, complete": little, but well done on what really counts. Not everything polished to perfection, but the right things done with care. As the product finds market, as customers start paying, as revenue grows, you raise the level of robustness, security, and finish on the pieces that generate more value or more risk. You don't polish everywhere uniformly, because you don't have infinite resources and not everything deserves the same investment. You concentrate the craft where it matters, where a bug translates into direct damage, where quality makes the difference between a customer who stays and one who leaves. And speed? Real speed isn't obtained by writing mediocre code. I know because I've watched enough projects drown in their own technical debt to understand that cut corners always come back to bite you. Speed is obtained by cutting scope, deciding what not to do, automating tests, moving quality controls as close as possible to the moment the code is written. Especially when AI is in the picture, which can produce mountains of code in little time but doesn't have the judgement to know which of that code deserves to exist. This way you aren't choosing between perfection and fast shipping. You're choosing among various combinations on a front of possibilities that you can shift based on context. It's a more honest way to think about the craft, I believe. Less romantic, perhaps, but more useful. ## Real Quality and Perceived Quality {: #qualita-percepita } There's also an uncomfortable thing that gets discussed too little, and it's the gap between real quality and perceived quality. For the client, quality is mostly experience, not internal implementation. A clear interface, good response times, present and honest support cover plenty of technical defects that don't break the flow. And paradoxically you can have technically very refined software perceived as mediocre because it's slow to evolve, poorly aligned with the need, or badly communicated. I've watched it happen. Projects we worked on for months to reach very high standards, that the client found frustrating because they didn't answer their actual needs. And less technically polished projects that clients loved because they solved a specific problem in a simple way and got updated often without drama. This doesn't mean technical quality doesn't count. It means it counts in relation to everything else, not as an absolute value disconnected from context. And it means part of our work is understanding what the client perceives as quality, not only what we know to be quality. ## Where to Spend Craft Time {: #dove-mettere-tempo-artigianale } The question I ask myself most often lately is: where do I put my craft time in a world where AI can do a large part of the standard work? Not 60%, maybe not even 80% as some claim, but still a meaningful share of what once required hours of human labour. At equal cost, the client willingly pays for the part where your judgement reduces a big risk or significantly increases the result. They don't pay for the part where you handwrite something a generative model can churn out in seconds. And if you insist on billing time as if AI didn't exist, sooner or later you'll find someone offering the same result at half price, because they figured out how to use it. I've started to think in different terms. I do by hand, to very high standards, everything close to money, to legal or reputational risk, to security. The pieces where a bug translates into direct damage, where judgement is needed and not just execution. And I let AI do, under careful supervision, everything that's commodity, repetitive, easily testable, substitutable. Not because I trust it blindly, but because I know where to check and what to verify. Pricing, then, should reflect the risk you take and the value you enable, more than the number of hours you spent on it. It's a change that takes time to be accepted, both by us and by clients. But it's the direction we're going, whether we like it or not. ## Who Really Risks Failing {: #chi-rischia-fallire } And who really risks failing in this new world? I've asked myself that question many times, trying to understand where the real dangers lie. I don't think the people who love quality are at risk. I think the people who confuse perfectionism with professionalism are at risk—those who always slow down, who can't say "this isn't needed today". Those who polish endlessly while the market overtakes them, convinced the world will eventually recognise their value. Sometimes it happens. Often it doesn't. And those at the other extreme also risk: those who chase only speed, saturate the system with ungoverned changes, accumulate technical debt without even noticing. Sooner or later the problems surface, customers lose trust, and all the time saved at the start gets paid back with interest. Whoever has a better chance, in my view, is whoever can do three things together. Use AI to move fast, because not doing so means falling behind. Use the head to decide where to stop and polish, because not everything deserves the same care. And use honesty to tell the client what kind of quality they're buying and why. That last part is maybe the hardest. It requires admitting that not everything we do is perfect, that there are compromises, that some choices are made for time or budget reasons and not technical reasons. It requires trusting that the client can understand, or at least trying. And it requires accepting that sometimes they won't, and we'll have to find a way to keep going anyway. These are reflections in progress, not definitive conclusions. The craft is shifting under our feet, and anyone who claims to have all the answers probably hasn't fully understood the questions. What I do know is that the balance between quality and speed isn't what it used to be, that AI has redrawn the boundaries of the possible, and that our task is finding a new way to create value in this different context. It doesn't mean abandoning principles. It means understanding which principles are really principles and which were just habits that made sense in a world that no longer exists. **It's a discernment work that requires humility, intellectual honesty, and the willingness to put one's certainties in question.** And maybe, in the end, this is what separates a good professional from one who's just repeating formulas they learned: **the capacity to adapt without losing yourself, to change without betraying, to evolve while staying faithful to what truly matters.** Which isn't quality in itself, but the value that quality creates for the people who need it. --- # Mozilla, Free from Billionaires (More or Less) - **URL:** https://margiovanni.it/en/blog/mozilla-free-from-billionaires-more-or-less/ - **Published:** 2025-12-17 - **Tags:** Browser, Independence, Open Source - **Reading time:** 5 min > I was browsing the Firefox site to check release notes for an update when I ran into a banner that made me smile—a slightly bitter smile, the kind you give when you find out your favourite vegan restaurant is owned by a fast-food chain. I was browsing the Firefox site a few hours ago, checking the release notes for an update, when I ran into a banner that made me smile. One of those slightly bitter smiles—the kind you give when you find out your favourite vegan restaurant is owned by a fast-food chain. ![](https://substackcdn.com/image/fetch/$s_!Rymv!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb1d24499-1083-4315-bfda-00f8301f76df_2402x1032.png) ## The Banner {: #il-banner } "Free from billionaires for over 20 years," reads the text next to the red panda logo. And below: "We're not owned by any billionaire and we keep working to make the Internet better and respect the time you spend on it." Lovely. Really lovely. Pity the reality is a little more nuanced. Because Mozilla does have a glorious history. Firefox was born as a free, open source alternative back when Internet Explorer dominated the web with its suffocating monopoly. For years it was the browser of purists, of tinkerers, of anyone who believed in a more open and privacy-respecting internet. In some ways, it still is. But let's talk money, because in the end money is what keeps even non-profit foundations running. ## The Numbers {: #i-numeri } In 2023 Mozilla took in around $653 million. A respectable figure. Of that, roughly $495 million (76%) comes from royalties for the default search engine. And who pays those royalties? Google. Yes, *that* Google—the one that belongs to Alphabet, whose market cap is over $2 trillion. Google, founded by Larry Page and Sergey Brin, both well past the billionaire threshold. The fun part is that this isn't a recent anomaly. From 2005 to today, with a brief Yahoo interlude between 2015 and 2017, Google has consistently covered between 80% and 90% of Mozilla's budget. Always. For twenty years. ![](https://substackcdn.com/image/fetch/$s_!y0e1!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5a32f389-7483-4c4c-a980-7a6f65505ba1_2208x1012.png) ## Twenty Years of Dependence {: #venti-anni-di-dipendenza } Look at the historical trend and the dependence is striking. In 2005, when Firefox was in the middle of its explosive growth, Google royalties already represented 95% of revenue. In 2012, after the contract was renewed, the numbers got much higher. In 2020, the deal was renewed with estimates between $400 and $450 million a year. There's an odd data point in 2019: revenue jumped to $826 million. Not because of any particular Mozilla achievement. That year Verizon (which had bought Yahoo) had to pay $338 million in damages for breaking the partnership contract early. So even when Mozilla wasn't depending on Google, its bottom line ended up depending on another tech giant. ## The Antitrust Alibi {: #alibi-antitrust } And the most interesting part? Even though Firefox's market share has been in steady decline for years, revenue has stayed stable or even grown. Why? Because for Google, even a reduced number of Firefox users using its search engine is worth the investment. It's an elegant way to avoid monopoly accusations. Being able to say "look, an alternative exists and we support it financially" comes in handy when antitrust regulators are giving you the side-eye. I'm not saying Mozilla is evil or hypocritical. It isn't that simple. Mozilla does important work: it builds a browser that respects user privacy more than Chrome does, contributes to open web standards, funds interesting projects in security and ethical AI. But that banner. That banner makes me laugh a little. "Free from billionaires" while your salary comes from a multi-million-dollar contract with one of the richest companies on the planet. It's a bit like a tenant paying rent to a real-estate magnate boasting about having nothing to do with rich people. The difference between being owned by a billionaire and being financially dependent on one is subtle, sure. Technically true. But also a little intellectually dishonest. The real problem isn't even the creative marketing. The real problem is the fragility of a business model built on a single customer. What happens if Google decides not to renew the contract? What happens if antitrust authorities crack down on these deals? What happens if Chrome becomes so dominant that supporting Firefox no longer works as an alibi? Mozilla knows this, of course. In recent years it has tried to diversify: VPN, premium services, investments. But the numbers say it plain: the Google dependence has never really been dented. Maybe that's the point. Maybe the banner should say something like: "Free from billionaires, but funded by them. It's complicated." Less catchy, sure. But at least honest. ## Free from Billionaires, Not from Their Money {: #non-dai-loro-soldi } In the end, the Mozilla–Google relationship is one of the longest and most stable in tech. Twenty years of financial marriage, with a brief Yahoo affair that ended with a settlement cheque. There's something almost romantic about it, in a slightly cynical way. Google pays Mozilla to exist. Mozilla exists thanks to Google. And in the meantime, both get to tell different stories: Google the one of the company supporting competition, Mozilla the one of the independent organisation fighting for a better web. Maybe it isn't hypocrisy. Maybe it's just how tech works in 2025. Even the alternatives need sponsors. Even the rebels need funding. And sometimes the funding comes from precisely the people you're supposed to be fighting. I don't know if any of this makes Mozilla less valid as an alternative to Chrome. Probably not, in practical terms. Firefox is still a great browser, with privacy features that outclass Chrome and a development ethic I respect. But every time I see that banner, I can't help but smile. With a little bitterness, yes. But also with the awareness that ideological purity, in tech as elsewhere, is often more complicated than promotional banners would have us believe. At least they're honest about one thing: they really are free from billionaires—they just aren't free from their money. --- # Aaron Swartz, the Boy Who Dreamed of a Free Web - **URL:** https://margiovanni.it/en/blog/aaron-swartz-the-boy-who-dreamed-of-a-free-web/ - **Published:** 2025-12-17 - **Tags:** Activism, Open Source, Free Web - **Reading time:** 6 min > 8 November would have been Aaron Swartz's birthday. He was born in 1986 and left too soon, on 11 January 2013. Every time I think about him I feel that hollow that unjust losses leave behind. ![](https://substackcdn.com/image/fetch/$s_!fuCf!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc373cd8a-93f0-4f57-8f06-13ddab489cd9_3888x2592.jpeg) 8 November would have been Aaron Swartz's birthday. He was born in 1986 and left too soon, on 11 January 2013. Every time I think about him, I feel that hollow that unjust losses leave behind—the kind that arrive when a brilliant mind is crushed by a world that didn't manage to understand it. Aaron was fragile and tenacious at the same time. Maybe it's exactly that combination that makes him so human. ## The teenage genius who changed the web {: #the-teenage-genius-who-changed-the-web } He had only a few years behind him when he started changing the way the web worked. At fourteen he took part in creating the RSS format, the technology that still powers blog and news feeds today. He wasn't just a precocious programmer: he was someone who understood the transformative potential of technology. He contributed to the birth of Creative Commons, the licensing system that lets creators around the world share their work without giving up their rights. He was a co-founder of Reddit, which over the years became one of the most influential communities on the internet. But he didn't stop at technology: he founded Open Library to make books accessible to everyone, digitising thousands of volumes to build a universal, free library. And then he wrote the **Guerrilla Open Access Manifesto**, a text that today reads almost like a love letter to freedom itself. In it, Aaron wrote words that still ring louder today: > "Information is power. But like all power, there are those who want to keep it for themselves. The world's entire scientific and cultural heritage, published over centuries in books and journals, is increasingly being digitized and locked up by a handful of private corporations." ## Knowledge as a political act {: #knowledge-as-a-political-act } Transparency and sharing sat at the centre of his thinking. Aaron believed that knowing was a political act, a right, a form of emancipation. He wasn't naive: he understood that knowledge concentrated in the hands of a few is a tool of power and control. That's why he fought to make it accessible to everyone. He used to say that leaving a mark means breaking the rules, trying to change the system by doing what others don't have the courage to do. A simple sentence, but one that gained immense weight over time. Because Aaron didn't speak in slogans: he acted. And his actions had consequences. In 2008 he uploaded and made freely available about 2.7 million federal court documents from PACER, a system that charged 8 cents a page for access to public documents. His logic was simple: if these are public documents, why do I have to pay to read them? He wasn't prosecuted for that gesture, but he started being watched. ## The persecution {: #the-persecution } Then came the darkest part of his story. In 2011 he was charged with downloading millions of scientific articles from JSTOR, a paywalled academic archive. He did it from MIT, using a connection on the university network. His goal, presumably, was to make publicly funded scientific research—locked behind prohibitive paywalls—available to the public. The federal charges were devastating: **thirteen counts**, with sentences reaching 35 years in prison and a million-dollar fine. Thirteen counts for downloading academic articles. JSTOR itself decided not to pursue him, but the federal government kept going. It was persecution more than prosecution. Federal prosecutor Carmen Ortiz wanted to make an example out of him, turn him into the symbol of the fight against "computer crime". But Aaron wasn't a criminal: he was an activist, an idealist, someone who believed that knowledge should be free. The pressure became unbearable. Aaron suffered from depression, and the weight of the charges, the prospect of years in prison, the public pillorying, were too much. I often wonder whether it was really inevitable—whether the law, the very law that's supposed to protect, can sometimes turn into a weapon against people seeking the truth. On 11 January 2013, Aaron Swartz took his own life. He was 26 years old. ## A legacy that keeps germinating {: #a-legacy-that-keeps-germinating } The other day, on what would have been his birthday, his legacy is more alive than ever. It lives in the open-access movements, in the people fighting to make publicly funded scientific research accessible to all. It lives in projects like Sci-Hub, which Alexandra Elbakyan created precisely as an answer to Aaron's ideals. It lives in digital-transparency projects, in the people working for a web that's actually free, civil, fair. It lives in those who code not just to create but to give something back to the world. It lives in every developer who picks an open-source licence, in every researcher who publishes on open archives, in every activist who believes information has to be a right, not a privilege. It's as if Aaron planted a seed that keeps germinating, every time someone decides to share knowledge instead of hoarding it. Every time someone chooses transparency over secrecy. Every time someone stands against unjust systems that turn knowledge into merchandise. ## The best way to remember him {: #the-best-way-to-remember-him } After his death, the reactions were strong. Tim Berners-Lee, the inventor of the World Wide Web, tweeted: "Aaron is dead. The criminals are those who locked up knowledge and persecuted him. Let us wake up." Lawrence Lessig, co-founder of Creative Commons and Aaron's mentor, wrote: "We've lost a friend. We've lost a fighter. America has lost an extraordinary figure." And Reddit's co-founder Steve Huffman said: "Aaron wasn't just a brilliant hacker and political activist. He was also my friend." But maybe the best way to remember him is exactly this: **do what others don't try to do**. Defy the fear, the bureaucracy, the indifference. Continue his work, each in their own way, with the same courage as those who believe freedom and knowledge are never a privilege but a right. You can do it in your own small way: * **Use and support open source projects.** Contribute when you can, even just with documentation or bug reports. * **Share knowledge.** If you have skills, teach them. If you have access to resources, make them available. * **Choose open licences** for your work, when possible. Creative Commons for content, MIT or GPL for code. * **Support open access.** If you're a researcher, publish on open archives. If you're a student, use and promote free alternatives. * **Fight against unjust paywalls.** Sign petitions, support organisations working for free access to knowledge. ## "Guerrilla Open Access Manifesto" {: #guerrilla-open-access-manifesto } I'd like to close with Aaron's own words, from his 2008 manifesto: > "There is no justice in following unjust laws. It's time to come into the light and, in the grand tradition of civil disobedience, declare our opposition to this private theft of public culture. We need to take information, wherever it is stored, make our copies and share them with the world. We need to take stuff that's out of copyright and add it to the archive. We need to buy secret databases and put them on the web. We need to download scientific journals and upload them to file-sharing networks. We need to fight for Guerrilla Open Access." Strong words, radical, inconvenient. But necessary. Because Aaron taught us that change doesn't arrive by waiting for someone to grant it from above. It arrives when brave people decide to act, despite the risks, despite the consequences. Today Aaron would be 39. Who knows what he would have built, what he would have changed, what battles he would have fought in the era of AI, social media, fake news. But even though he isn't here anymore, his spirit goes on living in every act of sharing, in every quiet rebellion against systems that want to privatise knowledge. Happy birthday, Aaron. Your dream of a free web is still alive. And we'll keep fighting to make it real. --- # The Great Illusion of Work-Life Balance in Tech - **URL:** https://margiovanni.it/en/blog/the-great-illusion-of-work-life-balance-in-tech/ - **Published:** 2025-12-17 - **Tags:** Work, Tech, Work-life balance - **Reading time:** 12 min > I've spent the last few days thinking about a conversation I overheard at a networking aperitivo. I've spent the last few days thinking about a conversation I overheard at a networking aperitivo. Two women, both in their forties, both in tech, were talking about their careers. One had just been promoted; the other was thinking about returning to work after maternity. The first was single, no children. The second had two small children. And while I listened, I noticed how different the tone of their voices was when they spoke about the future. ![](https://substackcdn.com/image/fetch/$s_!WVko!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7bcf136-42af-4566-8314-0aa4323529c9_640x427.jpeg) It isn't a new story, probably. And yet it still strikes me as absurd, almost surreal, in a sector that does nothing but talk about [inclusion and diversity](https://diversity.com/post/dei-in-tech-inclusive-teams), about work-life balance, about family-friendly policies. Every tech company has its diversity page, every CEO delivers inspiring speeches about employee wellbeing, every corporate report celebrates initiatives to support working parents. But then, when you actually look at who reaches the top, who gets the most significant promotions, who's considered leadership material, a pattern emerges that contradicts all that polished storytelling. ## The paradox no one wants to admit {: #the-paradox-no-one-wants-to-admit } The numbers speak for themselves, even if we'd rather not hear them. [50% of women leave the tech sector by age 35](https://www.adriasolutions.co.uk/motherhood-penalty-in-tech-careers/). It's no accident that this age coincides with the years many people decide to have children. Almost 40% of women who leave tech cite caregiving responsibilities as a determining factor. And those who stay? [Two-thirds of working mothers in the sector report their career stalled after parenthood](https://startupsmagazine.co.uk/article-motherhood-penalty-nearly-40-women-leave-tech). I often wonder what HR leaders think when they prepare those splendid presentations on parental leave and flexibility policies. Maybe they really believe in them, maybe they think offering more weeks of parental leave really makes a difference. And in a sense it does, don't get me wrong. But it's like putting a band-aid on an open fracture. The problem isn't only in the benefits, however important. The problem is that [unwritten, invisible yet omnipresent culture](https://www.businessinsider.com/tech-industry-amazon-microsoft-meta-google-companies-intensity-hardcore-2025-3), that keeps rewarding those who can afford to be always available. The culture Google itself embodied until recently, when co-founder Sergey Brin recommended employees working on Gemini do sixty hours a week and show up at the office "at least every weekday". The culture Meta embraced when CEO Mark Zuckerberg talked about a corporate world "culturally castrated" that had moved away from "masculine energy". ## The impossible equation of total availability {: #the-impossible-equation-of-total-availability } In 2025 we still work with an "ideal worker" idea that goes back decades—someone always present, always reachable, ready to sacrifice everything for work. Someone who, frankly, either has no family or has someone else handling it completely. [Research confirms it](https://www.hbs.edu/faculty/Pages/item.aspx?num=51141): in high-intensity environments like tech, people who "accept" this always-available culture often fail to cultivate external interests and are slow to recover from professional setbacks. I've seen with my own eyes what this expectation means. Colleagues replying to emails at 11 p.m., not because there's a real emergency, but because they know someone will notice, someone will compare them with the colleague who shut down the computer at 6 to pick up the kids from daycare. And it isn't paranoia. [A Slack study found](https://fortune.com/2023/12/07/workaholics-working-long-hours-productivity-declines-slack/) that those who feel obligated to work past hours report 20% lower productivity and stress levels more than doubled compared to those who keep normal hours. And yet this culture persists, in fact it intensifies. After the pandemic, [many tech companies reversed course on remote work](https://www.nytimes.com/2024/12/13/technology/tech-perks-culture.html), not for productivity reasons (studies show people work just as well from home) but for control reasons. Amazon imposed a five-day return to office. Meta cut four thousand employees deemed low-performing. Microsoft revised its evaluation system to eliminate underperformers more quickly. It's interesting how [the younger tech bros](https://sfstandard.com/2025/10/02/four-kids-dates-tech-bros-plan-families-re-busy-start/), the ones founding startups and talking about wanting four children, work more than 80 hours a week and candidly admit they don't have time even to go to a bar. "I probably talk to language models ten times more than I talk to people," joked one 21-year-old founder. It isn't funny, it's tragic. And it reveals how deeply rooted the expectation is that success requires sacrificing everything else. A small digression about something I'm proud of. My CEO told me a while ago: > "Anyone who doesn't cultivate a rich parental and social life can only be small at work too." ## The invisible parenthood penalty {: #the-invisible-parenthood-penalty } There's a phrase that recurs in studies on women's careers in STEM: ["spectre of motherhood"](https://theconversation.com/women-face-motherhood-penalty-in-stem-careers-long-before-they-actually-become-mothers-164744). You don't even have to become a mother to suffer the consequences of this hostile culture. It's enough that your colleagues and bosses think you might. PhD candidates and post-doctoral researchers have described being explicitly warned by their mentors that they would have to choose between an academic career and family. Some have hidden serious miscarriages or publicly declared they didn't want children, in a desperate attempt to be taken seriously. And when children actually arrive? [Mothers in STEM produce on average 17 fewer publications than fathers](https://pmc.ncbi.nlm.nih.gov/articles/PMC7904257/) in the ten years after the birth of the first child: a gap that would take about five years of work to close. It isn't a question of capacity or commitment. It's a question of time available for research, time that for mothers gets systematically eroded while fathers manage to protect it. 70% of mothers working in tech believe their career is suffering because of caregiving and family responsibilities. It isn't subjective perception. It's [a reality documented by countless studies](https://vanessaloder.com/fast-company-the-secret-society-of-parents-from-techs-biggest-companies/). Mothers are 79% less likely to be hired, half as likely to be promoted, and earn significantly less than women with comparable CVs but no children. ## The other side of the coin {: #the-other-side-of-the-coin } But maybe the most insidious part of this culture is how it creates tensions among colleagues. During the pandemic, when many tech companies offered additional leave to parents to manage school and daycare closures, [a real revolt erupted among childless employees](https://www.nytimes.com/2020/09/05/technology/parents-time-off-backlash.html). On Facebook, employees repeatedly noted during company meetings that COVID policies "primarily favoured parents". On Twitter an intense debate erupted when a childless employee criticised a colleague on leave to care for a child, arguing they weren't doing their part. And you understand their point. Truly. [63% of childless workers](https://hrdailyadvisor.com/2022/06/06/the-childless-stigma-at-work/) report having been denied time off, 69% having had to do overtime, and 70% having received heavier workloads. Almost half believe employees with children are more likely to be promoted. The problem is this isn't a war between parents and non-parents. It's a war orchestrated by systems that demand too much of everyone, and then pit them against each other to hide the real problem. [Companies offering extraordinary benefits to parents](https://www.bbc.com/worklife/article/20211005-is-modern-office-culture-unfair-to-non-parents) but then expecting childless colleagues to cover their work aren't helping anyone. They're simply moving the problem. ## The myth of tech meritocracy {: #the-myth-of-tech-meritocracy } Maybe the most frustrating part of all this is the hypocrisy. The tech sector loves to present itself as meritocratic, a place where only talent counts and the best ideas win. But how can a system be meritocratic when having a family (or even just intending to have one) automatically becomes a professional handicap? Tobi Lütke, CEO of Shopify, before the pandemic wrote proudly that his job was "incredible, but it's also just a job. Family and personal health come first on my priority list". This year he changed tone drastically: "I'm home for dinner but I work at least ten hours a day and a lot during the weekend". The message is clear: that balance he was talking about was a luxury we can no longer afford. And when leaders change tone, the cascade is immediate. Microsoft employees describe [the cultural shift toward "firmer performance expectations"](https://www.nytimes.com/2025/08/04/technology/tech-jobs-silicon-valley-changes.html). Startup workers report we're in the era of "shut up and grind". [Palantir's CEO told Gen Z explicitly](https://fortune.com/2025/09/23/palantir-ceo-alex-karp-gen-z-age-20-cant-have-social-life-and-be-succesful-work-life-balance-not-possible/) that at twenty you can't have both a social life and professional success. It's not by chance that [smaller tech companies](https://disasteravoidanceexperts.com/the-most-innovative-tech-companies-are-also-the-most-flexible/), under five hundred employees, offer full work-location flexibility 88% of the time, while tech giants over twenty-five thousand employees have nearly all adopted "structured hybrid" models with specific in-office requirements. Innovative startups understood flexibility works. Big companies seem more interested in control. ## Fathers and the presence penalty {: #fathers-and-the-presence-penalty } There's another side rarely discussed with proper attention: what happens to men who decide to be present parents? Those who don't settle for the traditional "breadwinner" role spending twelve hours a day in the office while someone else raises the children, but actually want to be active in family life? The answer is complex and, in some ways, even more insidious than the penalty hitting mothers. Because if for a woman having children is almost automatically perceived as a professional handicap, for a man choosing to take extended parental leave or ask for flexible hours the stigmatisation can be even stronger. [Recent studies show](https://cyep.org/fathers-in-tech-balancing-career-family-and-innovation/) fathers who fully use available parental leave are often perceived as less ambitious, less committed to work, less "leadership material". It's a perverse double standard: while women are blamed for being mothers, men are blamed for actually wanting to be fathers. As if fatherhood should remain confined to evening hours and weekends, never interfering with the total availability tech demands. A father who leaves the office at 6 to pick up the kids from daycare is viewed with the same suspicion as a mother who does the same, but with an added burden of judgement: "He isn't ambitious enough", "He doesn't hunger for success", "He lost his edge". And when a man chooses to reduce work hours or refuse a promotion that would require even more time at the office to dedicate himself to family, the career cost can be devastating. [Research shows](https://crg-stemm.ucsd.edu/research/parenting.html) that while mothers suffer a career penalty regardless of how much time they actually dedicate to children, fathers suffer it only when they become visibly involved in daily care. In other words: a father can have children without professional consequences, as long as someone else handles them full-time. The result is a culture that perpetuates deeply outdated gender dynamics. Tech companies can celebrate gender parity all they want and offer generous parental leave on paper, but if then a man who uses it gets penalised in performance reviews, in promotions, in growth opportunities, the implicit message is clear: childcare remains women's work. This hurts everyone. It hurts women, who keep carrying the disproportionate caregiving load because "his job is more important anyway". It hurts men, deprived of the chance to be present fathers without sacrificing the career. And it hurts children, growing up in a world where parental presence is still considered a luxury incompatible with professional success. ## What's left, in the end {: #whats-left-in-the-end } While I write this, I keep thinking about those two women at the aperitivo. I wonder what the one considering a return to work after maternity will do. Will she go back to an environment that statistically penalises her for making a perfectly normal life choice? Will she accept being considered less ambitious, less available, less "leader material" only because she has responsibilities outside the office? Or maybe she'll find a different company, one of those rare places that have actually internalised the value of diversity and inclusion, not just as a slogan on the website but as daily practice. They exist, these companies. There are leaders who model the balance they want to see in their team, who reward results instead of hours worked, who understand that a person with a rich life outside work is often more creative, more resilient, more capable of seeing different perspectives. But they're still too few. And meanwhile, too much talent gets lost, too much potential innovation wasted, too much suffering accepted as inevitable. Tech keeps talking about disruption, changing the world, building the future. Maybe it should start by changing itself, by building a future where you don't have to choose between having a family and having a career. Where your availability at 11 p.m. doesn't become the measure of your dedication. Where you can be present for your children without being invisible to your bosses. I don't know if we'll get there soon. But I keep hoping that one day, when two people meet at an aperitivo to talk about their careers, having or not having children will be as irrelevant as preferring tea to coffee. A personal characteristic, not a determining factor for professional success. Maybe it's naive to think so. But if there's a sector that should be capable of imagining and building different futures, it should be this one. --- # Upskilling in the AI Era: Necessary, but Not Enough - **URL:** https://margiovanni.it/en/blog/upskilling-in-the-ai-era-necessary-but-not-enough/ - **Published:** 2025-12-17 - **Tags:** Training, AI, Work - **Reading time:** 9 min > I often find myself talking to HR leaders explaining their AI training needs. Courses on ChatGPT, prompt workshops, sessions on generative AI tools. And I always feel a little torn. ![](https://substackcdn.com/image/fetch/$s_!sFrh!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F708762c8-657f-4313-ad9f-45194f7de151_1280x853.jpeg) I often find myself talking to HR leaders explaining their needs around AI training programs. Courses on ChatGPT, prompt workshops, sessions on how to use generative AI tools. And I'm always a bit torn, because on one hand I think it's absolutely right and necessary, and on the other I have the sense they're looking only at a small part of a much bigger picture. Upskilling—targeted updating of skills—is fundamental. That has to be said clearly. [The World Economic Forum estimates that 44% of workers will need to acquire new skills by 2027](https://www.risorseumane-hr.it/upskilling-e-reskilling-strategie-hr-per-trasformare-le-aziende/). It isn't a remote possibility, but a concrete necessity. Anyone who isn't training today risks ending up with obsolete knowledge tomorrow. But what worries me is when we stop there. When we think it's enough to teach people to use AI tools and the job is done. Because in that case we're solving only the surface part of the problem, the most visible and immediate one, while underneath there's a structural earthquake that demands a much deeper rethink. ## The training that actually matters {: #the-training-that-actually-matters } Not all forms of upskilling are equal. There's a huge difference between teaching someone to use a specific tool and helping them develop a deep understanding of how AI is transforming their professional domain. The first kind of training—technical, operational—is important but has an intrinsic problem: it ages quickly. Tools change, interfaces evolve, what's cutting-edge today might be obsolete in six months. It's still necessary, because people need confidence with the tools they'll use daily. But if we stop here, we're building on fragile foundations. The second kind of training—strategic, critical—is far more durable. We're talking about developing the capacity to understand when to use AI and when not to, to interpret the results it produces critically, to identify hidden bias in outputs, to integrate AI into one's workflow creatively. These are [skills that don't go obsolete with the next software update](https://www.zetaservice.com/blog/formazione-e-reskilling-competenze-per-la-trasformazione-tecnologica/). And then there are the soft skills, those cross-cutting capacities that are paradoxically becoming more important precisely as technology advances. Critical thinking, creativity, emotional intelligence, the ability to collaborate, to communicate complex ideas. [McKinsey identified 56 essential soft skills for the future of work](https://www.peoplechange360.it/people-strategy/development-and-learning/hcm-valorizzare-le-persone-in-azienda-i-tre-pilastri-lifelong-learning-reskilling-e-soft-skill/). It's not by chance: they're exactly the areas where humans keep a clear advantage over machines. ## The systemic problem upskilling doesn't solve {: #the-systemic-problem-upskilling-doesnt-solve } But even when training is done well—targeted, strategic, balancing hard and soft skills—a fundamental limit remains: upskilling works on individuals, while the problem is systemic. I've watched several organisations invest meaningful resources in excellent training programs, only to find competent people coming back to work exactly as before. Why? Because the corporate processes haven't changed. **The hierarchies are the same. The evaluation systems still reward the same old metrics.** It's a bit like teaching someone to drive a state-of-the-art electric car and then sending it down dirt roads designed for horse-drawn carriages. The competence is there, but the context doesn't allow it to be expressed. [MIT published data we should all stop and think about: 95% of corporate generative AI projects fail](https://inno3.it/2025/09/05/mit-il-95-dei-progetti-genai-fallisce-ecco-perche/). And **the problem is rarely the technology or the lack of technical skills**. The problem is that we're trying to fit AI into organisational structures designed for another era. ## Pairing upskilling with deeper transformation {: #pairing-upskilling-with-deeper-transformation } What we actually need is a two-level approach. On one hand, yes, continuous and targeted training. On the other—and this is the piece that's almost always missing—a radical redesign of how we work. It isn't enough to teach people to use AI. **You have to completely rethink their roles** by asking: which activities can be delegated to AI? Which require human intuition, creativity, ethical judgement, relational capacity? And above all: how do we free people from the tasks AI does better than them, to focus them on what only humans can do? Take the example of an analyst who attends an excellent upskilling course on AI for data analysis. They go back to the office with new skills. But if their role stays defined exactly as before—same workload, same deadlines, same expectations—what really changes? Imagine instead that [the organisation completely rethinks the role](https://joshbersin.com/2025/03/job-redesign-around-ai-work-intelligence-tools-arrive/): AI handles processing data, identifying patterns, generating preliminary reports; the human analyst focuses on interpreting those patterns in the organisation's specific context, asking questions the machine can't ask, connecting apparently unrelated information, making decisions that require deep understanding of the business. That isn't just training. It's a redefinition of the work itself. ## Creating space for human creativity {: #creating-space-for-human-creativity } And here we get to what for me is the central point. All this transformation—upskilling, process redesign, AI integration—should have a final goal: freeing the creative potential of people. Today most workers spend their days submerged in operational tasks, useless meetings, endless emails, reports no one will read. [Only 29% feel encouraged to think creatively or to find new ways of doing things](https://www.corporate-rebels.com/blog/unlocking-creativity-at-work). The rest? They execute, reply, manage the urgent without ever having time for the important. AI could—and I use the conditional carefully—be the opportunity to change this situation. But only if we accompany the technical training with deep cultural transformation. Only if we consciously decide to use automation not to do the same things with fewer people, but to do different and better things with people freer to think. That means creating spaces—physical, temporal, mental—where creativity can actually emerge. It means changing evaluation systems to reward innovation, not only execution. It means giving people permission to experiment, to fail, to explore without a predetermined destination. ## Redesigning processes, not patching them {: #redesigning-processes-not-patching-them } The truth is that training alone, however excellent, cannot compensate for inefficient processes. It's like putting an electric motor on a horse-drawn carriage and expecting it to become a modern car. **You need the courage to do real Business Process Reengineering.** Not marginal adjustments, but radical redesign. And today we have tools—[AI itself](https://proactivemgmt.com/blog/2025/02/14/how-ai-is-revolutionizing-business-process-improvement-right-sized-for-every-business/)—that can analyse processes, spot inefficiencies, suggest redesigns, adapt in real time. > But this requires putting consolidated hierarchies, traditional roles, ways of working that have existed for decades, into question. It requires accepting that maybe a job that occupied three full-time people can be handled by an intelligent system, and those three people can do something much more interesting and valuable for the organisation. Some companies are already on this path. [They've created hybrid teams where humans and AI actually collaborate](https://www.salesforce.com/ap/agentforce/human-ai-collaboration/), not as user and tool but as partners with complementary skills. They've redesigned entire workflows from scratch, asking: if we had to build this process today, knowing what AI can do, how would we do it? ## The risk of surface-level fixes {: #the-risk-of-surface-level-fixes } There's a huge risk that worries me when I talk about these things. The risk is treating upskilling as the total solution, as if it were enough to organise a few courses and the problem is solved. I've watched too many companies launch AI initiatives with great fanfare, organise two-day workshops on digital training, buy expensive tool licences… and then six months later everything is back to before. People keep working exactly as they worked, maybe with an extra tool they don't really use, because no one rethought the processes, no one gave them permission to work differently, no one removed from their desks the useless activities that drown them. That's the difference between running a training project and running a systemic transformation. The first has a beginning and an end, produces a certificate, gets measured in course hours. [The second is continuous, touches the organisational culture](https://www.mhp.com/en/insights/blog/post/ai-strategy-and-culture), changes how decisions are made, requires leadership willing to put itself in question. ## An integrated vision {: #an-integrated-vision } What I'm proposing, and what I see working in more mature organisations, is an integrated approach with three pillars: **Targeted, continuous upskilling**: not one-off courses, but [structured paths that balance technical skills and soft skills](https://radicalhr.it/newsletter/3780/people-transformation-la-learning-agility-come-chiave-della-crescita-di-unorganizzazione/), that evolve with the technology, that are personalised on people's actual needs. Training that doesn't just teach tools but develops critical thinking, judgement, creative use of technology. **Process redesign**: radical analysis of how we work, with the courage to question consolidated assumptions. Use AI not to automate inefficient processes, but to imagine completely new ways of creating value. Involve people in this redesign, because they're the ones who actually know the daily work. **Cultural transformation**: create an environment where continuous learning is valued, where experimentation is encouraged, where success metrics reward innovation and not only execution. Where people have time and space to think, create, imagine new solutions. ## Toward a new balance {: #toward-a-new-balance } Underneath all of this, I think we're facing a fundamental choice. We can use upskilling as a tool to help people adapt to a future that crushes them, chasing technologies that evolve faster than they can learn. Or we can use it as part of a broader transformation, where training people goes hand in hand with redesigning their work and creating spaces where they can really express their human potential. The second road is harder. It requires investment not only in courses but in organisational culture. It requires time, strategic patience, courageous leadership. But it's also the only road that makes sense if we want to actually exploit the potential of this technological revolution without losing what makes us human. Upskilling works when it's done well—targeted, continuous, balanced between hard and soft skills. But it really works only when it's accompanied by deeper transformation: of processes, of culture, of the very way we conceive work in the AI era. Maybe this is what we should teach first in our training programs: not how to use AI, but how to rethink together—people, technology, organisation—the future of work. A future where technology amplifies human ingenuity instead of replacing it, where automation frees time for creativity instead of generating only anxiety, where people can finally focus on what they do best: imagining, creating, innovating, building authentic relationships. Because in the end, success in the AI era won't be determined by how well we know how to use the tools. It'll be determined by our capacity to build organisations where continuous training, process redesign, and the valuing of human creativity work together to create something none of the three could create alone. --- # Ethics as a Compass for AI: When Human Values Become Business Value - **URL:** https://margiovanni.it/en/blog/ethics-as-a-compass-for-ai-when-human-values-become-business-value/ - **Published:** 2025-12-17 - **Tags:** Business, Ethics, AI - **Reading time:** 6 min > AI is becoming part of daily life almost without our noticing. The interesting part isn't that it's a technology question—it's that it's also, increasingly, a business question. ![](https://substackcdn.com/image/fetch/$s_!RmDJ!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F40095c6e-87b3-487a-9056-99e5b790e451_1024x1024.jpeg) I find myself thinking, often, about how AI is becoming part of daily life almost without our noticing. An algorithm suggesting what to watch on Netflix, a chatbot answering our questions, a system filtering CVs for a company. They're all examples of AI quietly slipping into the folds of our digital lives, influencing decisions that until a few years ago were exclusively human. But something stands out in this transformation: it isn't only a technology question. It's a deeply ethical one. And maybe, more than we imagine, it's also a business question. ## When ethics becomes corporate strategy {: #when-ethics-becomes-corporate-strategy } The idea that AI ethics is just a moral question to handle "when there's time" is becoming obsolete fast. [Recent research](https://ethicai.net/the-business-case-for-ethical-ai) tells us something interesting: companies investing in ethical practices for AI aren't only doing the right thing—they're also generating concrete value. The data is clear. Organisations that adopt ethical principles in AI development see better product quality, increased customer trust, and [profit margins 10% higher than competitors](https://www.aigl.blog/the-roi-of-ai-ethics-profiting-with-principles-for-the-future/). It's no longer a question of *whether* to implement ethics in AI, but *how* to do it most effectively. What emerges from the research is a fascinating picture: ethics isn't a cost—it's a sophisticated tool for managing financial risk and generating revenue, with [measurable, substantial economic returns](https://www.linkedin.com/posts/sam-burrett_the-roi-of-responsible-ai-activity-7341011798969458689-Df36). ## Trust as the currency of the future {: #trust-as-the-currency-of-the-future } Maybe the most interesting part of this shift is about trust. [Only 42% of customers trust companies in their ethical use of AI](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/research/State-of-the-Connected-Customer.pdf), down from 58% in 2023. That isn't just a statistic—it's an alarm bell that should make us pause. Trust, in the end, has become a real currency in the digital market. And companies that can demonstrate it through concrete ethical practices are gaining a meaningful competitive edge. 62% of consumers trust brands more when they perceive their AI as ethical, and [61% share positive experiences with friends and family](https://bronson.ai/resources/the-roi-of-responsible-ai/). But what does it mean, in practice, to build that trust? It isn't statements of principle or policies on paper. It's transparency, explainability, giving people control over the systems that affect them. ## The hidden risks behind apparent neutrality {: #the-hidden-risks-behind-apparent-neutrality } One of the most dangerous illusions of AI is neutrality. "It's just an algorithm", we hear often. But the reality is much more complicated. Every AI system reflects the data it was trained on, and that data often contains [biases, discrimination, and distortions](https://www.econopoly.ilsole24ore.com/2025/01/13/etica-dati-algoritmi-e-persone-le-sfide-e-i-limiti-dellai/) that get amplified in automated decisions. The examples aren't hard to find. The COMPAS system, used in U.S. courts to predict recidivism risk, showed twice the false-positive rate for Black defendants compared to white ones. A healthcare algorithm used on more than 200 million American citizens systematically favoured white patients over Black patients for access to extra care. [Amazon had to abandon a recruiting system](https://datatron.com/real-life-examples-of-discriminating-artificial-intelligence/) because it penalised CVs containing the word "women". These aren't technical defects. They're direct consequences of design choices that didn't account for ethical implications. And the cost of these mistakes isn't only social—it's also economic: [reputational damage, lawsuits, customer loss](https://www.rapidinnovation.io/post/ethics-and-privacy-in-ai-app-development). ## Transparency: beyond the black box {: #transparency-beyond-the-black-box } Probably one of the hardest challenges in AI ethics is transparency. Many algorithms, especially those based on deep neural networks, work as "black boxes": even those who built them struggle to explain how they arrive at certain decisions. But transparency isn't only a technical question. It's a question of design, of user experience, of communication. It isn't about explaining every mathematical detail—it's about giving users [enough information to understand and trust the system](https://www.eleken.co/blog-posts/ai-transparency). Take a recommendation system. You don't need to explain the machine-learning algorithms behind it. You need to say: "We're suggesting this product because you recently viewed similar items" or ["This recommendation is based on your previous purchases"](https://www.zendesk.com/blog/ai-transparency/). It's human transparency, not technical. ## The concrete value of applied ethics {: #the-concrete-value-of-applied-ethics } But back to the original question: how much can ethics actually guide us in building AI solutions that bring more value? The answer, based on the data we've gathered, is "much more than we imagine". Ethics in AI generates value in different and often complementary ways. There's direct value, tied to operational and legal risk reduction. There's indirect value, tied to brand reputation and trust. And there's strategic value, tied to innovation and market leadership. Companies adopting ethical practices see concrete improvements: better product quality, higher customer retention, better talent attraction and retention. And, perhaps more important, they're better positioned to face the regulatory challenges that are coming. ## The practical approach: from principles to actions {: #the-practical-approach-from-principles-to-actions } Talking about AI ethics is easy. Putting it into practice is harder. But there are principles that can guide us. **Transparency**: making decision processes understandable. **Fairness**: ensuring impartial treatment, avoiding discrimination. **Accountability**: clearly defining who is responsible for AI decisions. **Privacy**: [protecting personal data with robust measures](https://www.sap.com/resources/what-is-ai-ethics). These principles have to translate into concrete processes. Diversifying datasets to reduce bias. Implementing human controls on critical decisions. Designing interfaces that make AI understandable to users. [Continuously monitoring the ethical performance of systems](https://diecipoints.com/digital-transformation/letica-nellia-come-sviluppare-software-responsabili-nel-2025/). It isn't about adding a layer of complexity to development. It's about integrating ethical considerations from the very start of the process—from ideation to deployment to continuous monitoring. ## Toward a more human future for AI {: #toward-a-more-human-future-for-ai } What strikes me most in this reflection is how AI ethics isn't in conflict with innovation—it's a more evolved form of it. We aren't slowing technological progress, we're steering it toward more sustainable, more useful directions for people. [The Italian AI market hit €1.2 billion in 2024](https://www.osservatori.net/comunicato/artificial-intelligence/intelligenza-artificiale-italia/), growing 58%. That's an impressive figure, and it shows how rapidly we're adopting these technologies. But the question is: are we building AI that actually serves people, or are we just chasing efficiency at any cost? Ethics in AI isn't a luxury we can afford when everything else is working. It's the foundation on which to build technologies that are not only powerful but beneficial. It's the difference between developing systems people endure and systems people choose to use because they get real value from them. Maybe it's time to stop thinking of ethics as a constraint and start seeing it as an opportunity. The opportunity to create technology that doesn't only work but works for the better. The opportunity to build trust in an increasingly digital world. The opportunity to show that the most important innovation isn't the one that goes fastest, but the one that goes in the right direction. In the end, this isn't only about artificial intelligence. It's about human intelligence applied to technology. And that, perhaps, is the most powerful combination we can imagine. --- # When Security Meets Industrial Reality - **URL:** https://margiovanni.it/en/blog/when-security-meets-industrial-reality/ - **Published:** 2025-12-17 - **Tags:** Cybersecurity, Industry, Security - **Reading time:** 1 min > On 18 October I was in Bergamo for NoHat 2025, and I found myself thinking about how easy it is to live in a bubble when you work with technology. ![two bullet surveillance cameras attached on wall](https://images.unsplash.com/photo-1496368077930-c1e31b4e5b44?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wzMDAzMzh8MHwxfHNlYXJjaHwxfHxzZWN1cml0eXxlbnwwfHx8fDE3NjU5MDE4MTJ8MA&ixlib=rb-4.1.0&q=80&w=1080) *Photo by Scott Webb on Unsplash* On 18 October I was in Bergamo for NoHat 2025, and I found myself thinking about how easy it is to live in a bubble when you work with technology. We think we understand cybersecurity because we know how firewalls work, how to configure an authentication system, how to handle vulnerabilities in a web app. Then you hear from someone who works with critical infrastructure or with AI systems, and you realise your mental model maybe covers 20% of the picture. It isn't that what we know is wrong. It's that the world is wider and more complicated than we tend to admit when we're immersed in our own specific patch.