L’annuncio confuso
Il job posting era apparso a febbraio su una di quelle bacheche dove le aziende italiane di medie dimensioni cercano figure tecniche senza essere troppo sicure di cosa stanno cercando. Il titolo della posizione era “Senior Software Engineer with Regulatory Background”, e già lì c’era qualcosa di strano, perché in italiano una formula del genere non significa niente di preciso. Il corpo dell’annuncio chiariva poco. Si chiedeva esperienza di almeno cinque anni in sviluppo backend, preferibilmente Java o Python, conoscenza di Kubernetes, esperienza in pipeline CI/CD. Fin qui un profilo da senior developer normale. Poi il testo cambiava registro e cominciava a chiedere conoscenza approfondita del GDPR, padronanza dell’AI Act per quanto riguarda i sistemi ad alto rischio, capacità di redigere DPIA e valutazioni di rischio, esperienza con framework di compliance come ISO 27001 e SOC 2, capacità di interfacciarsi con auditor esterni. La RAL indicata era da senior developer di mercato, con un piccolo extra non quantificato per le competenze regolatorie.
Ho letto quell’annuncio una decina di volte cercando di capire chi lo stesse cercando davvero. Una persona così, con quella combinazione di competenze, in Italia oggi non esiste in numeri rilevanti, e quando esiste costa il doppio di quello che l’azienda offriva. L’azienda lo sapeva o non lo sapeva, è difficile dirlo. Quello che è certo è che aveva un bisogno reale, perché stava per consegnare un sistema a un cliente regolato, e non aveva la persona giusta in casa. Aveva sviluppatori senior che non sapevano leggere un Regolamento europeo, aveva un legale interno che non sapeva leggere il codice, e aveva un consulente di compliance esterno che riusciva a parlare con uno dei due ma non con l’altro. La persona che cercava esisteva nella sua testa come traduttore fra mondi che non si parlavano, ma quella persona non aveva ancora un nome di mestiere stabile.
L’annuncio è stato ripubblicato a marzo con un titolo diverso, “Compliance Engineer”, senza altre modifiche al corpo. Poi è scomparso. Non so se l’azienda abbia trovato qualcuno o abbia rinunciato. So che annunci come quello, con varianti minime, ne sto vedendo passare uno o due alla settimana sulle bacheche italiane, e molti di più su quelle europee. Sto vedendo un mestiere che si sta cercando un nome, e che lo troverà nei prossimi due o tre anni perché non ha alternative.
L’obiezione tecnologica
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.
Cosa ti porti a casa
Il compliance engineer è la figura che assorbe in una persona sola lavoro oggi distribuito male fra il dev senior che spiega il sistema agli auditor, l’architect che traduce i regolamenti in scelte di design, e il legale interno che prova a leggere il codice senza saperlo leggere.
L’AI non sostituirà il compliance engineer: lo sta rendendo economicamente accessibile alle PMI. Senza assistenza generativa il volume documentale richiesto dal nuovo regime sarebbe ingestibile sotto le trenta persone dedicate. Con AI ben configurata, una sola figura ben formata presidia tutto.
Due degenerazioni patologiche già osservabili: il gate-keeper burocratico che blocca i rilasci e il decoratore di policy che firma documenti senza leggere il codice. Entrambe hanno la stessa radice, la mancanza di formazione strutturata della figura, e producono debito di specifica anziché contrastarlo.
L’università italiana è strutturalmente in ritardo: ingegneria informatica dedica al diritto un ammontare di ore irrisorio, giurisprudenza dedica al software un ammontare di ore irrisorio. Esistono master che provano a colmare il gap, ma sono sovrapposizioni a sei o dodici mesi, non costruzione bicipite dalle fondamenta.
La finestra competitiva per le software house italiane di dimensione media è di due-tre anni. Hanno la prossimità tecnica al codice che le grandi 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 esternalizzarla.
Domande e risposte
Chi è il «compliance engineer» e perché ne stiamo parlando solo adesso?
È la figura che presidia in continuo l’allineamento fra ciò che il codice fa e ciò che la documentazione tecnica e regolatoria dichiara. Ne stiamo parlando solo adesso perché la pressione che la rende necessaria è recente: l’accumularsi degli atti regolatori europei sul digitale fra il 2024 e il 2027 (AI Act, CRA, PLD revisionata, NIS2, DORA, Data Act, EAA) ha creato un volume di obblighi documentali che il consulente esterno occasionale e il legale interno disabituato al codice non sono più in grado di gestire da soli. La figura esisteva in nuce nelle grandi aziende; il pacchetto regolatorio la sta promuovendo a ruolo strutturale anche nelle organizzazioni medie.
Non è un mestiere che farà l'AI fra tre anni?
No, e l’osservazione è capovolta rispetto a come la propongono di solito. L’AI farà il novanta per cento del lavoro meccanico — generazione di prima stesura della DPIA, mappatura dei flussi, redazione di SBOM, controllo di conformità sui considerando — e questo è già osservabile nei contesti in cui viene applicata seriamente. Il dieci per cento residuo non è il dieci per cento che sparirà, è il dieci per cento interpretativo e politico che richiede una persona che capisca contemporaneamente l’architettura del sistema e la struttura del Regolamento. È proprio l’AI a rendere economicamente sostenibile la figura: senza, il compliance engineer esisterebbe solo come reparto di trenta persone in multinazionale; con, una sola persona ben formata in una software house di quindici può presidiare l’intera funzione.
Come si distingue il compliance engineer da un DPO, un security architect o un consulente compliance esterno?
Il DPO ha responsabilità formali specifiche legate alla protezione dei dati, definite dal GDPR, ed è una figura giuridicamente individuata. Il security architect presidia la sicurezza architetturale del sistema. Il consulente esterno produce documenti adeguati ma raramente entra nel codice. Il compliance engineer non sostituisce queste tre figure, le integra: è la persona dedicata che legge le pull request con l’occhio del regolamento, che presidia il debito di specifica, che traduce dal linguaggio del codice a quello del Regolamento e viceversa, e che lo fa tutti i giorni dentro l’organizzazione, non per progetti.
Quali sono le due degenerazioni patologiche da evitare nella costruzione del ruolo?
La prima è il gate-keeper burocratico, che mette il presidio compliance contro il delivery e produce checklist sempre più lunghe, ritardando i rilasci con motivazioni che agli sviluppatori sembrano formalismi. La seconda è il decoratore di policy, che firma documenti formalmente perfetti senza leggere il codice e nel frattempo il sistema reale evolve in direzioni che il documento non descrive più. Entrambe hanno la stessa radice — la mancanza di formazione bicipite — e producono il debito di specifica anziché contrastarlo. La via stretta del compliance engineer vero passa fra queste due derive.
Concretamente, come una software house italiana di dimensione media costruisce questa figura?
Investendo fra i ventiquattro e i trentasei mesi su una persona che ha già metà delle competenze: tipicamente uno sviluppatore senior con curiosità per la dimensione regolatoria, un architect con sensibilità a sicurezza e privacy, o una persona di product management con gusto per la formalizzazione. Traiettoria di crescita: affiancamento a casi reali, lettura sistematica dei Regolamenti europei nelle versioni a confronto, partecipazione ad audit con clienti, redazione di DPIA sotto supervisione, esposizione progressiva al legale interno per assorbire il vocabolario per osmosi. È un investimento significativo — è anche un asset competitivo difficilmente replicabile.
C'è una connessione fra il compliance engineer e i due saggi precedenti («Cruft, non patina», «Il debito di specifica»)?
Sì, ed è il motivo per cui ho scritto i tre pezzi in sequenza. «Cruft, non patina» argomenta che il software non sa invecchiare, perché il drift fra codice e ambiente lo erode. «Il debito di specifica» argomenta che la specifica invecchia ancora peggio, 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.
L'autore
