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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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é

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

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

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

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

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.

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

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

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

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

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

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

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. 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.

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

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

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

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

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

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

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ò.

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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, argomentava che il software non sa invecchiare come gli oggetti materiali. Quello successivo, 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, 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.

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

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

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

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

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

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

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

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

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

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 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, 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.

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

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

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, 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

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

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

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

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

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

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

Qualche mese fa, su questo blog, ho scritto un pezzo che si chiama 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.

È 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

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

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

È 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

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

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

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

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ì.

«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

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

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

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

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

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

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

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

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

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.

È 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

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

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

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

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

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

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

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

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

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

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à

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

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

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

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

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.

Il software non impara, in questo senso. Il software accumula commenti che si scusano.

L’archeologia 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

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

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

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

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

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

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

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

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

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

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

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

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.

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 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

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

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ù

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 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

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

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

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

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

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

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

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

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

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ù.

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

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 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

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

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”

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

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

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

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

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.

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ù

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

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 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

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

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

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à

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

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

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.

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

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)

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

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

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.

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.

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

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

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

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

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

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.

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

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 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à

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

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

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

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

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

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

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.

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

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

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”

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

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

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

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

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.

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

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

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”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

È 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

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

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)

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

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

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

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

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

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

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à

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.

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

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

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

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

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.

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

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

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

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

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.

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

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

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?

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 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à

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

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

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

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.

“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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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.

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, 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”

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

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

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à

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

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)

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

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

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.

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”

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

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)

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

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

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

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

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

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.

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

È 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

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

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

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

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

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

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

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

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

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.

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

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

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ì)

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)

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

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

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

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

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

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.

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

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

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ù

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 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à

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

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

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.

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

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

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

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

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

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

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)

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

È 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ì.

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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?

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

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

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

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

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.

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

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

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à

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

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

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.

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

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)

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

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 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

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 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à

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

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

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

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

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.

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”

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 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

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

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

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

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

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 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

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.