La forma del vincolo

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

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 →