Il debito di specifica

L’audit clinico

Ci sono documenti che si aprono solo nei momenti sbagliati. La DPIA del sistema di triage clinico è stata firmata nell’aprile del 2024 e archiviata nella cartella della compliance, da dove non è uscita più, come nessuna DPIA esce mai dalla cartella della compliance. Diciotto mesi dopo, qualcuno la apre. Non è un giurista, è un consulente arrivato per un audit di sicurezza, e la apre per ragioni di routine, perché vuole verificare che le misure dichiarate corrispondano a quelle implementate.

Il documento descrive un sistema che usa un modello di scoring deterministico, addestrato su un dataset chiuso, con regole esplicite per la classificazione del livello di urgenza. Le finalità del trattamento sono quattro. Le basi giuridiche sono mappate al considerando corretto del Regolamento. I diritti degli interessati sono elencati uno a uno con le procedure operative per esercitarli. I flussi transfrontalieri non esistono, perché tutto resta nel data center europeo del fornitore. Il consulente legge, prende qualche appunto, poi alza gli occhi e chiede al CIO se può vedere il sistema in esecuzione.

Il sistema in esecuzione è un altro. Tre mesi dopo la firma della DPIA il fornitore ha sostituito il modello deterministico con un classificatore neurale addestrato in continuo sui dati clinici degli ultimi sei mesi. Il dataset non è più chiuso. Le regole di classificazione non sono più esplicite. Le finalità ufficiali sono ancora quattro, ma una quinta funzione è stata aggiunta su richiesta del reparto di emergenza, ed è una funzione che la DPIA non contempla. I flussi transfrontalieri continuano a non esistere finché un giorno non esistono, perché il fornitore ha cambiato hyperscaler e adesso una porzione del traffico passa da un data center irlandese gestito da una controllata americana. Niente di tutto questo è documentato altrove. Il sistema funziona. Gli utenti sono contenti. Gli audit interni passano perché si limitano a verificare che il sistema esista e che produca output coerenti.

Il consulente si volta verso il CIO e chiede chi ha autorizzato la quinta funzione. Il CIO risponde che è stata una richiesta urgente del primario di emergenza, gestita in una settimana, con il fornitore che ha rilasciato in produzione il giovedì successivo dopo un test in ambiente di staging. C’è un ticket in Jira che traccia la modifica, c’è una pull request approvata da due reviewer, c’è un changelog interno. Tutto in ordine sul piano operativo. Il consulente chiede se la DPIA è stata aggiornata. Il CIO lo guarda con l’espressione di chi non ha mai pensato che fosse necessario, perché la DPIA appartiene a un altro circuito, gestito da un’altra persona, in un’altra cartella, con tempi che non hanno niente a che vedere con i tempi del rilascio. Il consulente chiude la DPIA e non la chiama più DPIA. La chiama specifica fantasma, perché descrive un sistema che esiste solo sulla carta firmata.

Una condizione ordinaria

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.

L'autore

Andrea MargiovanniAI

Seguo il rapporto fra AI e regolazione europea come fatto politico, non come spettacolo tecnico. Lavoro con team che devono renderla compatibile con AI Act, CRA, NIS2 senza ridurre la compliance a una checklist.

Vai al percorso →