Quando un'azienda sa qualcosa?

Venerdì 11 settembre 2026 è andato online un modulo. Sta su portal.cra-srp.enisa.europa.eu, ci si entra con un account EU Login e l’autenticazione a due fattori, e serve a fare una cosa che fino a due giorni fa nessun produttore europeo di software o hardware aveva mai dovuto fare in quella forma: dichiarare a un’autorità che una vulnerabilità dei propri prodotti è attivamente sfruttata da qualcuno.

Tra i campi da compilare ce n’è uno che vale la pena leggere nella lingua in cui è scritto, perché la piattaforma per ora è disponibile solo in inglese: «Date/Time when you became aware of the incident/actively exploited vulnerability». Data e ora in cui sei venuto a conoscenza.

Da quel campo parte un termine di ventiquattro ore.

C’è un dettaglio, nella FAQ che ENISA ha aggiornato il 12 settembre, il giorno dopo l’apertura, che trovo più interessante di tutto il resto. L’agenzia spiega che nella versione attuale della piattaforma il contatore delle 72 ore mostra una scadenza calcolata a 48 ore dall’invio dell’early warning, e che quindi una notifica può risultare in ritardo prima che siano passate 72 ore da quando il produttore ha saputo. Poi aggiunge che la logica sarà corretta in una versione futura, in modo da calcolare la scadenza usando il campo sulla data e l’ora della conoscenza.

Detta così è una nota di rilascio. È anche il punto in cui qualcuno, dentro un ticket, ha dovuto decidere come si misura un tempo che comincia da un fatto mentale collettivo. Per ora la piattaforma conta da quando hai parlato. Ha scritto che conterà da quando hai saputo.

Prendiamo allora una notte qualsiasi.

Alle 02:13 la telemetria di un prodotto registra una sequenza di richieste anomala su un endpoint di autenticazione. Alle 02:14 il SIEM correla quella sequenza con una regola e genera un alert di severità media, uno dei quattrocento della settimana. Alle 07:55 un tecnico del turno di mattina lo apre. Alle 09:20, dopo aver guardato i log applicativi, conclude che probabilmente non è uno scanner ma un exploit funzionante contro una libreria di terze parti. Alle 11:40 il responsabile sicurezza riceve il rapporto. Alle 14:10, finita la riunione commerciale, qualcuno lo dice al management.

Dodici ore. Nessuno ha nascosto niente, nessuno ha violato una procedura, nessuno si è comportato in modo irragionevole. Ogni passaggio, preso da solo, è difendibile.

Quando ha saputo l’azienda?

Non è una domanda retorica e non è una domanda filosofica. Dall’11 settembre è un campo obbligatorio di un modulo, e da quel campo parte un orologio che ha conseguenze sanzionatorie.

Su questa scadenza, sul fatto che la piattaforma sia nata lo stesso giorno dell’obbligo e su cosa significhi arrivarci senza essersi registrati, ho già scritto ad agosto. Quel pezzo finiva con una frase che allora mi sembrava una chiusura e adesso mi sembra l’inizio di un’altra cosa: l’orologio parte dalla conoscenza, e la conoscenza è un fatto organizzativo prima che tecnico. Questo saggio comincia lì, e non parla del CRA.

Il diritto lavora con la conoscenza da molto prima del software

L’obiezione va messa subito, e va messa nella sua versione forte, perché se regge non c’è saggio.

Non c’è assolutamente nulla di nuovo in una norma che fa partire un termine dal momento in cui qualcuno viene a conoscenza di un fatto. È una delle tecniche legislative più antiche che esistano. La prescrizione, la decadenza, l’impugnazione, la denuncia dei vizi: il diritto misura il tempo a partire dalla conoscenza da secoli, e lo fa perché l’alternativa, misurarlo dal fatto oggettivo, punirebbe chi non poteva sapere.

Nel digitale il precedente è persino imbarazzante per quanto è esplicito. L’articolo 33 del GDPR impone dal 2018 la notifica di una violazione dei dati personali all’autorità di controllo «senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza». Il considerando 87 aggiunge che occorre accertare se siano state attuate tutte le misure tecnologiche e organizzative adeguate per stabilire immediatamente se una violazione sia avvenuta. Le linee guida 9/2022 dell’EDPB, adottate nella versione 2.0 il 28 marzo 2023, chiariscono che il titolare deve considerarsi venuto a conoscenza quando ha «un ragionevole grado di certezza» che si sia verificato un incidente di sicurezza che ha compromesso dati personali.

NIS2 fa esattamente la stessa cosa con gli stessi numeri. L’articolo 23, paragrafo 4, della direttiva (UE) 2022/2555 chiede un early warning entro 24 ore dalla conoscenza di un incidente significativo e una notifica entro 72. Il CRA, con l’articolo 14 del regolamento (UE) 2024/2847, ricalca lo schema quasi parola per parola: early warning entro 24 ore da quando il produttore «becomes aware», notifica entro 72, relazione finale entro 14 giorni dalla disponibilità di una misura correttiva per le vulnerabilità e entro un mese dalla notifica per gli incidenti gravi.

Tre norme, lo stesso trigger, gli stessi numeri. Sarebbe facilissimo archiviare la faccenda come l’ennesimo timer normativo e passare oltre, e per la maggior parte dei commenti che ho letto in questi giorni è esattamente quello che è successo.

Voglio costruire il pezzo contro questa lettura, ma non negandola. Negandone la conclusione.

Il legislatore non dice come si sa, e proprio per questo ha cominciato a guardarlo

Il documento che ha cambiato la mia opinione non è il regolamento. Sono le FAQ della Commissione sull’attuazione del CRA, pubblicate la prima volta il 3 dicembre 2025 e aggiornate il 4 settembre 2026, una settimana prima dell’apertura della piattaforma. La sezione 5 riguarda gli obblighi di segnalazione, e la prima domanda della sezione, la 5.1, è questa: come può un produttore venire a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave.

La risposta comincia dicendo che il CRA non lo specifica. «The CRA does not specify how a manufacturer is to become aware», e si limita a imporre l’obbligo di notificare una volta che la conoscenza esiste. Poi la Commissione fa una cosa che non era tenuta a fare: elenca i canali. Un cliente o un partner che segnala un’attività anomala. Un rapporto di threat intelligence. Ricercatori di sicurezza o società di cybersecurity che pubblicano l’analisi di uno zero-day usato in attacchi mirati. Un’agenzia governativa che ha rilevato lo sfruttamento con i propri sistemi di monitoraggio. Un hacker etico. E poi, alla fine dell’elenco, la frase che mi interessa: il produttore può venire a conoscenza anche «via internal monitoring, scanning activities or telemetry». Il sistema di telemetria del produttore, o un suo honeypot, che indica lo sfruttamento di una vulnerabilità prima sconosciuta. Il suo team di sicurezza che monitora forum sul dark web e trova prove che qualcuno ha sfruttato un difetto del prodotto.

Il sensore, in quell’elenco, non è più soltanto uno strumento tecnico. È uno dei modi in cui una persona giuridica viene a conoscenza di qualcosa.

Serve qui una precisazione, perché la tentazione di forzare il testo è forte e sarebbe disonesta. Subito dopo l’elenco la Commissione scrive che tutto questo non implica che il produttore sia tenuto a svolgere quelle attività o a monitorare quei canali per conformarsi agli obblighi di segnalazione. Non esiste, nell’articolo 14, un dovere di vedere. E non sto sostenendo che qualsiasi alert faccia partire automaticamente il cronometro: non lo dice il testo, non lo dice la Commissione, e la nozione concreta di conoscenza richiederà anni di interpretazione prima di stabilizzarsi.

Però quella frase ha una nota a piè di pagina, la decima, e la nota dice il resto. «Nonetheless», ciò nonostante, l’Allegato I, Parte II impone al produttore di avere, fra le altre cose, un punto di contatto unico dove le vulnerabilità possano essere segnalate, di adottare e far rispettare una politica di divulgazione coordinata delle vulnerabilità, e di prendere misure per facilitare la condivisione di informazioni su potenziali vulnerabilità.

Tradotto: l’obbligo di segnalazione non ti impone di guardare, ma il regolamento in cui è contenuto ti impone di essere raggiungibile. Non è un dovere di vedere. È un dovere di avere una porta, tenerla aperta e dire a tutti dove si trova.

C’è un secondo indizio, dentro lo stesso regolamento, che secondo me nessuno ha sottolineato abbastanza. L’articolo 14 usa «becomes aware», conoscenza effettiva. L’articolo 13, paragrafo 21, sullo stesso soggetto e nello stesso testo, usa una formula diversa: i produttori «who know or have reason to believe» che il prodotto non sia conforme devono immediatamente adottare le misure correttive. Sapere, oppure avere motivo di credere. È lo standard della conoscenza imputata, quella che il diritto attribuisce a chi avrebbe dovuto sapere.

Il legislatore europeo conosce benissimo la differenza fra le due formule e le ha usate a poca distanza l’una dall’altra. Non ha esteso la conoscenza imputata all’obbligo di segnalazione, e la scelta è deliberata. Ma ha scritto un regolamento in cui, a poche righe di distanza, convivono lo standard di ciò che sai e lo standard di ciò che avresti motivo di credere. Chi pensa che l’ambiguità sull’awareness sia una svista non ha letto abbastanza vicino.

La tesi, allora, non è che l’Europa abbia imposto alle imprese di sapere. È più sottile e secondo me più importante. Pezzo dopo pezzo, il diritto digitale europeo sta rendendo giuridicamente rilevante l’architettura attraverso cui un’organizzazione arriva a sapere qualcosa. Non impone di monitorare. Crea un incentivo fortissimo a saper descrivere come un segnale diventa conoscenza.

Architettura epistemica

Chiamo architettura epistemica l’insieme dei meccanismi attraverso cui un’organizzazione raccoglie segnali dal mondo, attribuisce loro un significato, decide quando le evidenze sono sufficienti e trasforma quella valutazione in un fatto su cui agire. Non c’è niente di esoterico nel termine e non c’è niente di nuovo nella cosa. Esiste in ogni azienda, anche in quelle che non l’hanno mai nominata.

Un SOC è un’architettura epistemica. Un processo di incident management lo è. Una catena di escalation lo è. La regola non scritta per cui una certa categoria di alert viene silenziata il venerdì pomeriggio lo è. Anche la decisione di non integrare una fonte, di non abbonarsi a un feed, di non leggere una casella, è un’architettura epistemica: negativa, implicita, quasi sempre non deliberata, e perfettamente operante.

Nel software abbiamo costruito un vocabolario estremamente sofisticato per discutere l’osservabilità delle macchine. Log strutturati, metriche, traces distribuite, cardinalità, percentili, alerting basato su SLO. Posso sapere in pochi secondi che la latenza al novantanovesimo percentile di un endpoint è salita del 15% rispetto alla settimana scorsa, e posso dirti da quale servizio a valle arriva.

Siamo molto meno bravi a descrivere l’osservabilità dell’organizzazione che quei sistemi li possiede.

Quando un alert è stato visto, e da chi. Chi aveva, in quel momento, gli elementi per interpretarlo. Quali evidenze mancavano e chi le aveva. In che momento il dubbio è diventato ragionevole certezza. Chi aveva l’autorità per dichiararlo, e se quella persona era raggiungibile.

Sono domande che sembrano amministrative finché una norma non fa partire da una di esse un termine di ventiquattro ore. Da venerdì, in Europa, una di esse è un campo obbligatorio con una data e un’ora dentro.

Il paradosso dell’osservabilità regolata

Qui arriva l’obiezione che considero la più seria di tutto il pezzo, e le do tutto lo spazio che merita perché è vera.

Un’organizzazione che vede meglio si mette, apparentemente, in una posizione normativa peggiore.

Se ho telemetria eccellente sul prodotto in produzione, se compro threat intelligence, se faccio scanning continuo delle dipendenze, se ho persone reperibili alle tre di notte e una catena di escalation che funziona, scoprirò gli incidenti prima. E se li scopro prima, il cronometro parte prima. Il mio collega che non ha niente di tutto questo non sa nulla, e nessun orologio sembra partire.

Detto in una riga: più sei bravo a sapere, prima diventi responsabile di ciò che sai.

È il paradosso dell’osservabilità regolata, e non è un esercizio da seminario. Una regolazione costruita male produce esattamente questo incentivo perverso, e l’incentivo non si manifesta mai nella forma esplicita. Nessun consiglio di amministrazione delibera «non vogliamo sapere». Si manifesta nei rinvii: il progetto di integrazione dei log applicativi nel SIEM che slitta di trimestre in trimestre, il feed di threat intelligence che non si rinnova perché genera troppi falsi positivi, la reperibilità notturna che resta informale, il criterio di apertura di un incidente scritto in modo così esigente da spostare in avanti di ore il momento in cui qualcuno può dire che è successo davvero. Ogni singola decisione ha una giustificazione tecnica o di budget ragionevole. La somma è cecità organizzativa, costruita per accumulo e non per scelta.

Chi lavora nella compliance da abbastanza tempo sa che questo è il vero modo in cui le organizzazioni si difendono. Non mentendo. Strutturandosi per non arrivare mai al punto in cui la verità diventa un fatto dichiarabile.

E allora bisogna chiedersi se la strategia funzioni.

Il GDPR, che su questo ha otto anni di vantaggio, ha già risposto di no, e la risposta è più dura di quanto la si citi di solito. Il considerando 87 non dice che il titolare deve notificare quando sa. Dice che va accertato se siano state attuate le misure tecniche e organizzative adeguate per stabilire immediatamente se una violazione sia avvenuta. Il soggetto della verifica non è la notifica. È la capacità di accorgersi. L’EDPB, al paragrafo 37 delle linee guida, scrive che il titolare deve quindi avere processi interni che gli permettano di rilevare e affrontare una violazione, e aggiunge che quando una violazione viene rilevata è importante che venga riportata verso l’alto, al livello di management appropriato, perché possa essere gestita e, se necessario, notificata. Al paragrafo 126 chiude il cerchio: se la notifica arriva in ritardo, il titolare deve essere in grado di fornire le ragioni del ritardo, e la documentazione relativa serve a dimostrare che il ritardo era giustificato e non eccessivo.

Non si può fornire la ragione di un ritardo senza avere una cronologia. E non si può avere una cronologia di un evento che il proprio sistema non ha mai registrato.

Con il CRA questo principio è destinato ad assumere una forma ancora più strutturale, e la data da guardare non è quella di venerdì scorso. È l’11 dicembre 2027, quando il regolamento diventerà pienamente applicabile e con esso l’Allegato I, Parte II, che elenca i requisiti di gestione delle vulnerabilità. Il produttore dovrà identificare e documentare le vulnerabilità e i componenti dei propri prodotti, redigendo una SBOM in formato leggibile da una macchina che copra almeno le dipendenze di primo livello. Dovrà applicare test e revisioni di sicurezza efficaci e regolari. Dovrà adottare una politica di divulgazione coordinata e fornire un indirizzo per le segnalazioni. E l’articolo 13, paragrafo 7, gli impone di documentare sistematicamente gli aspetti di cibersicurezza rilevanti dei propri prodotti, incluse le vulnerabilità di cui viene a conoscenza e qualsiasi informazione pertinente fornita da terzi.

Messi in fila, questi obblighi non dicono al produttore che deve sapere tutto. Gli dicono che deve avere un inventario aggiornato di ciò che ha costruito, un canale dichiarato attraverso cui gli arrivano le segnalazioni, un processo che le prende in carico e una traccia scritta di ciò che ha saputo e da chi. Ho scritto altrove che la compliance europea fallisce per mancanza di inventario molto più che per mancanza di norme. Qui la cosa si estende: l’inventario non riguarda più soltanto i componenti. Riguarda i percorsi attraverso cui le notizie sui componenti arrivano a qualcuno che può decidere.

Quindi il legislatore non sta offrendo davvero la scelta tra sapere e non sapere. Sta iniziando a regolamentare la capacità di sapere, che è una cosa diversa e molto più invasiva.

Prima del comportamento c’è la conoscenza

È il passaggio per cui questo saggio non riguarda il CRA.

Per decenni la compliance è stata raccontata come un rapporto a due termini, fra comportamento e regola. Una norma stabilisce cosa devi fare, l’organizzazione lo fa, e poi dimostra di averlo fatto. Tutto l’apparato dell’audit, della certificazione, della prova documentale nasce da quello schema.

Nel digitale sta emergendo un terzo termine, che sta prima degli altri due.

Non puoi rimediare a una vulnerabilità che non hai individuato. Non puoi notificare un incidente che nessuno ha classificato come tale. Non puoi valutare un rischio se l’informazione necessaria a valutarlo è rimasta dentro il log di un sistema che nessuno guarda, o dentro la sessione privata di uno strumento che una sola persona usa. La regola dice cosa fare, ma la possibilità stessa di applicarla dipende da un fatto che la regola non descrive: che l’organizzazione sia arrivata a sapere.

La qualità della compliance diventa quindi una funzione della qualità dell’apparato cognitivo dell’organizzazione. Non della sua buona fede, non del suo budget legale, non del numero di policy che ha approvato.

Questo spiega, incidentalmente, perché così tanti programmi di conformità producono carta e non sicurezza. Descrivono con grande precisione i comportamenti dovuti e non descrivono mai i percorsi attraverso cui l’organizzazione scopre di doverli tenere.

Quando sa un agente

Fin qui il problema è vecchio quanto le organizzazioni. Adesso arriva la parte che lo rende urgente.

La Commissione, in quell’elenco, cita monitoring interno, scanning e telemetria come canali attraverso cui un produttore viene a conoscenza di un problema. È scritto pensando a sistemi che generano segnali: un honeypot che si accende, una regola che scatta, un contatore che supera una soglia. Il segnale poi va a una persona, e la persona capisce.

Stiamo entrando rapidamente in un mondo in cui quei sistemi non si limitano più a segnalare.

Un agente può leggere un CVE pubblicato dieci minuti fa, verificare se la dipendenza interessata compare nella SBOM del prodotto, aprire il repository, controllare se la funzione vulnerabile è effettivamente raggiungibile dal codice che spediamo, correlare la cosa con la telemetria di produzione delle ultime settantadue ore e aprire un issue con una conclusione scritta in linguaggio naturale: questa vulnerabilità risulta probabilmente sfruttata su questa versione del prodotto, e queste sono le evidenze.

Non è uno scenario di frontiera. È un pomeriggio di lavoro con gli strumenti che abbiamo adesso.

Quando sa l’organizzazione?

Quando l’agente produce la conclusione? Quando un essere umano la legge? Quando qualcuno la approva? Quando l’issue passa da triage a confirmed? Quando raggiunge la casella che l’azienda ha dichiarato pubblicamente essere il proprio canale di sicurezza, cioè quel punto di contatto unico che l’Allegato I le impone di avere?

Non ho la risposta giuridica e diffido di chi la dà oggi con sicurezza. La lascio aperta perché è aperta davvero, e perché la giurisprudenza su questo non esiste e non esisterà per anni.

Quello che mi sento di dire è che l’AI non crea il problema. Lo rende impossibile da rimandare. Abbiamo sempre trattato i sistemi automatici come strumenti attraverso cui le persone acquisiscono conoscenza: il sensore rileva, l’uomo sa. Con gli agenti cominciamo a costruire sistemi che raccolgono elementi, formulano inferenze, valutano la propria confidenza e decidono autonomamente che qualcosa merita attenzione. Il confine tra «la macchina ha rilevato» e «l’organizzazione sa» diventerà sempre meno evidente, e diventerà meno evidente in fretta.

Da qui discende una conseguenza che riguarda la governance interna dell’AI, e che secondo me è sottovalutata.

Governare un agente non significherà soltanto stabilire cosa può fare. Significherà stabilire quali fatti è autorizzato a far diventare conoscenza organizzativa.

Un agente che trova una vulnerabilità e lascia il risultato dentro la sessione privata di uno sviluppatore è una cosa. Lo stesso agente, con lo stesso modello e lo stesso prompt, integrato nella pipeline aziendale in modo da aprire automaticamente un security incident con un timestamp, è un’altra cosa. Tecnicamente sono lo stesso sistema. Istituzionalmente sono due entità diverse, perché la seconda ha il potere di far partire un termine e la prima no.

Ho scritto tempo fa che l’autorità arriva prima dell’intelligenza, e che un agente è interessante non perché fa cose da solo ma perché qualcuno gli ha concesso il diritto di farle. Questa è la stessa idea applicata al sapere invece che all’agire. Il diritto di dichiarare, dentro un’organizzazione, che una cosa è vera, è una delega come tutte le altre, e fino a ieri non l’avevamo mai scritta da nessuna parte perché ce l’avevano solo le persone.

C’è anche un rovescio positivo, e va detto. Se il costo marginale di investigare un segnale crolla, la quantità di eventi che un’organizzazione può permettersi di capire cresce. Non avremo soltanto più codice scritto dalle macchine. Potremmo avere organizzazioni molto più sensibili al proprio ambiente, capaci di prendere sul serio segnali che oggi vengono chiusi senza guardarli perché guardarli costa quaranta minuti di una persona brava.

Questo è un bene. E produce un cambiamento quasi controintuitivo per chi fa il mio mestiere: il problema non sarà più costruire strumenti abbastanza intelligenti da vedere i rischi. Sarà progettare il processo attraverso cui quello che vedono acquisisce uno status organizzativo.

Il sistema nervoso di un’istituzione

La metafora che uso quando devo spiegare questa cosa a un cliente è anatomica, e ha il pregio di rompere subito la retorica del «serve più monitoring».

Una società non è un cervello. È un organismo distribuito. Ha recettori periferici, vie di trasmissione con latenze diverse, centri in cui i segnali vengono integrati, e meccanismi attraverso cui uno stimolo diventa un riflesso, un dolore, o una decisione cosciente.

La cattiva governance, in questo schema, non consiste soltanto nell’avere pochi recettori. Può consistere in un sistema nervoso che sente perfettamente ma trasmette lentamente, e arriva al centro quando il danno è fatto. Oppure in uno che genera così tanti segnali da non riuscire più a distinguere il dolore dal rumore, che è la condizione clinica di parecchi SOC che ho visto.

Se un SOC riceve diecimila alert irrilevanti alla settimana, l’organizzazione non è più informata. Ha soltanto più rumore, e in più ha costruito una ragione perfettamente difendibile per non guardare il decimillesimo.

La qualità epistemica non coincide con la quantità di dati disponibili. È la capacità di trasformare evidenze in credenze abbastanza affidabili da giustificare un’azione. Sono due cose diverse e la seconda non si compra.

Sapere abbastanza per agire

Il riferimento dell’EDPB al ragionevole grado di certezza è utile proprio perché riconosce questo punto e lo dice in una riga. La conoscenza giuridicamente rilevante non coincide con la certezza assoluta. Le stesse linee guida precisano che un breve periodo di indagine iniziale è legittimo e che durante quel periodo il titolare non può considerarsi ancora venuto a conoscenza, ma aggiungono che l’indagine deve cominciare il prima possibile e stabilire, con un ragionevole grado di certezza, se una violazione ci sia stata. Il dettaglio arriva dopo.

Questo mette il dito su una cosa culturale che secondo me pesa più della norma.

Molte organizzazioni hanno costruito i propri processi decisionali su una premessa implicita di certezza. Prima di portare un problema verso l’alto bisogna essere sicuri. Prima di aprire un incidente bisogna avere conferme. Prima di coinvolgere il legale o il management bisogna sapere esattamente cosa è successo, perché presentarsi con un’ipotesi sbagliata costa credibilità e la credibilità è la valuta in cui le carriere vengono pagate.

I regimi di reporting che l’Europa ha costruito negli ultimi otto anni sono progettati esattamente per funzionare prima che quella certezza esista. È il motivo per cui CRA e NIS2 separano l’early warning dalla notifica successiva: le prime ventiquattro ore sono, per costruzione, ore di informazione incompleta, e il contenuto richiesto nell’early warning lo riflette. Per un incidente grave il CRA chiede, entro 24 ore, almeno se si sospetti che sia stato causato da atti illeciti o dolosi. Almeno se si sospetti. Non cosa è successo.

Il diritto sta chiedendo una cosa che culturalmente molte aziende trovano difficilissima: essere capaci di dire, e di dirlo per iscritto a un’autorità, che si sa abbastanza per agire ma non abbastanza per sapere tutto.

È una forma di maturità epistemica, ed è rarissima.

Nella mia esperienza il punto di rottura non è quasi mai tecnico. In un progetto complesso a cui ho lavorato, con una catena di responsabilità distribuita su più fornitori, il problema non è mai stato l’assenza dei dati: i dati c’erano tutti, con i loro timestamp, da mesi. Il problema era che la stessa anomalia cambiava natura a seconda di chi la guardava. Per lo sviluppatore era un bug da mettere in backlog. Per chi teneva le operations era un alert ricorrente con un runbook. Per il responsabile sicurezza era un possibile incidente, ma «possibile» non bastava ad aprirne uno. Per il management non esisteva finché non arrivava una comunicazione formale, e la comunicazione formale richiedeva che qualcuno, prima, avesse chiamato incidente la cosa.

La realtà non cambiava mentre attraversava quei confini. Cambiava lo status che l’organizzazione le attribuiva, e il tempo che passava fra un confine e l’altro era il vero rischio. Non ho nomi da fare e non servono: chiunque abbia lavorato in una struttura con più di venti persone ha già riconosciuto la scena.

Le obiezioni che meritano una risposta

Due, e la seconda mi preoccupa molto più della prima.

La prima è che sto leggendo troppo dentro una parola. «Awareness» è una tecnica legislativa ordinaria, il legislatore europeo non ha inteso costruire nessuna teoria della conoscenza organizzativa, e attribuirgli intenzioni filosofiche è il tipico vizio di chi commenta le norme senza scriverle.

L’obiezione è fondata e la accetto per intero. Infatti non serve attribuire al legislatore nessuna intenzione. Basta osservare gli effetti organizzativi prodotti da norme diverse che usano sistematicamente lo stesso trigger, si sovrappongono sugli stessi soggetti e chiedono ciascuna una dichiarazione datata. Un’azienda europea che produce software finirà per trovarsi con tre orologi che partono dalla conoscenza e una sola organizzazione che deve farli partire. A quel punto la domanda su come si sa smette di essere filosofica e diventa un problema di progettazione, indipendentemente da cosa avesse in mente Bruxelles.

La seconda obiezione è più seria. Formalizzare eccessivamente la conoscenza può creare organizzazioni difensive, in cui ogni informazione viene classificata, registrata, passata al legale e trattata come materiale probatorio, con il risultato di peggiorare proprio la capacità di reagire. Chi ha visto cosa è diventata la medicina difensiva sa che non è un rischio teorico. E un ingegnere che sa che il suo commento su un ticket potrebbe essere letto da un’autorità fra tre anni scriverà commenti peggiori, non migliori.

Anche questa obiezione è vera, e non ho una risposta che la annulli. Ho solo una distinzione, che uso come criterio quando devo disegnare questi processi.

L’obiettivo non è burocratizzare il sapere. È ridurre l’ambiguità nei pochi passaggi in cui l’ambiguità impedisce una decisione tempestiva. Sono pochi e si contano: chi ha l’autorità di dichiarare aperto un incidente, entro quanto tempo un segnale non ancora valutato deve comunque essere guardato da qualcuno, quale casella è il canale ufficiale e chi la legge di notte, cosa succede quando la persona che deve decidere non risponde. Quattro o cinque punti di snodo. Tutto il resto può e deve restare informale, perché un’organizzazione in cui ogni conversazione è un atto non pensa più.

La differenza fra le due cose è la stessa che passa fra un sistema nervoso e un’ingessatura.

Chi trasforma una possibilità in un fatto

Venerdì l’Europa non ha semplicemente aperto un portale di reporting.

Ha reso visibile un fatto che accompagnerà sempre di più la regolazione tecnologica. Una società che costruisce prodotti digitali deve essere in grado di osservare sé stessa. Deve sapere quali occhi possiede, quali segnali considera affidabili, dove finisce l’incertezza che può tollerare e chi, in che momento, trasforma una possibilità in un fatto di cui l’organizzazione è pronta a rispondere.

Per anni abbiamo interpretato l’accountability digitale come la capacità di spiegare cosa abbiamo fatto. Il livello successivo è la capacità di spiegare quando abbiamo saputo abbastanza per farlo.

Cambia anche la natura della prova. Non basta più il rapporto finale sull’incidente, quello scritto bene, con la timeline ricostruita a posteriori e le lezioni apprese. Diventano rilevanti i timestamp veri, le escalation, i ticket, i decision log, la provenienza dell’informazione, la classificazione iniziale e i cambi di valutazione. Non perché a Bruxelles piacciano i log. Perché senza quella catena è impossibile ricostruire la storia epistemica di un’organizzazione, e un’organizzazione che non può ricostruirla non può nemmeno difendersi.

Il punto non è dimostrare che hai reagito. È dimostrare che non hai avuto bisogno di fingere di non sapere.

Il contrario della compliance non è soltanto violare una regola. Può essere costruire un’organizzazione incapace di sapere quando la sta violando.

Le istituzioni, come le persone, non sono responsabili soltanto per quello che sanno. In certe condizioni diventano responsabili anche per il modo in cui hanno scelto di conoscere. Un padre che non chiede, un medico che non guarda l’esame, un’azienda che non integra il log: il diritto e la morale comune hanno sempre saputo che l’ignoranza può essere una costruzione, e che costruirla è già una decisione.

La tecnologia sta semplicemente rendendo quella vecchia intuizione molto più concreta, e molto più databile.

L'autore

Andrea MargiovanniCompliance EU

Lavoro a fianco di team che disegnano sistemi sotto AI Act, CRA, NIS2, GDPR. La regola non è una checklist: è un vincolo architetturale, e va portato a bordo prima del design, non dopo.

Vai al percorso →