I sistemi AI hanno bisogno di security ledger

I sistemi AI hanno bisogno di development security ledger, non di checklist di lancio. Questa è la tesi, soprattutto quando la funzione sembra innocua: un assistente per il supporto, un motore di raccomandazione, un classificatore di documenti, un punteggio commerciale, una personalizzazione che impara dal comportamento degli utenti.

La checklist finale non è inutile. Può ricordare al team di verificare cifratura, accessi, revisione legale, valutazione del fornitore, log e piano di incident response. Ma una checklist fotografa un istante. Lo sviluppo di un sistema AI, invece, attraversa molti stati: raccolta dati, costruzione del dataset, annotazione, training, valutazione, integrazione, vincoli di deployment, monitoraggio e talvolta retraining. In ognuno di questi passaggi i dati personali possono entrare, cambiare, essere copiati, esposti, combinati o resi più sensibili dal contesto.

Un ledger serve a conservare la storia operativa del sistema. Non chiede solo se qualcosa è stato approvato. Registra chi possiede l’accesso, quale versione del dataset è stata usata, quale dipendenza è stata verificata, quali prove di audit esistono, se una DPIA è stata attivata, quali vincoli limitano il deployment e chi può fermare il sistema se il rischio cambia.

Le raccomandazioni della CNIL sullo sviluppo dei sistemi AI sono un buon punto di appoggio perché trattano la sicurezza come parte della conformità GDPR durante lo sviluppo, non come rifinitura tecnica prima della produzione. La CNIL richiama analisi del rischio, documentazione della DPIA, controlli sulla confidenzialità e integrità dei dati di training, versioning dei dataset, ambienti riproducibili, verifiche sugli strumenti di sviluppo, audit e misure per limitare o interrompere sistemi non sicuri: raccomandazioni CNIL sullo sviluppo AI.

La sicurezza fa parte del contratto di prodotto

Quando una funzione AI usa dati personali, la sicurezza non è un binario separato che arriva dopo la decisione di prodotto. È parte della promessa fatta a utenti, clienti, regulator e operatori interni. La funzione non coincide solo con l’output del modello. Comprende anche quali dati il modello ha visto, chi poteva modificarli, quale versione ha generato un risultato, quali componenti software sono stati fidati e come il team può dimostrarlo dopo il lancio.

Per questo la governance deve seguire il percorso reale dell’influenza. Nell’articolo Agenti AI: governare per livello di autonomia il punto non è governare il nome del vendor, ma i diritti decisionali del sistema. Qui vale lo stesso principio. La sicurezza deve seguire il passaggio dai dati al modello, dal modello al workflow, dal workflow all’azione.

La checklist tende a nascondere questo percorso. Riduce una storia complessa a una colonna di spunte verdi. Il ledger fa il contrario. Mantiene la catena di custodia. Dice quale data class è coinvolta, quale owner risponde degli accessi, quale dataset è stato usato, quali rischi di dipendenza sono stati accettati, quali evidenze sostengono la decisione e quale limite impedisce al sistema di superare il perimetro deciso.

Sembra burocrazia fino al primo incidente. Poi il team deve sapere se un campo sensibile era nel dataset, se la pseudonimizzazione è avvenuta prima o dopo l’annotazione, se un tool terzo ha avuto accesso ai dati grezzi, se l’output può essere ricondotto a una versione del dataset e chi può sospendere la funzione senza convocare mezzo comitato.

Cosa deve contenere il development security ledger?

Il ledger minimo deve essere abbastanza leggero da essere aggiornato e abbastanza preciso da rispondere alle domande di rischio. Se diventa un archivio legale, nessuno lo userà. Se resta una checklist di release, non guiderà lo sviluppo. Partirei da otto campi.

Il primo campo è purpose e data class. Il team deve sapere a cosa serve il sistema e se tratta dati personali, dati sensibili, dati di persone vulnerabili, informazioni confidenziali del cliente o dati sintetici. Il purpose non è una frase da documento. Serve a limitare quali dati possono entrare nel sistema.

Il secondo è l’access owner. Non una casella condivisa e non un reparto generico. Serve una persona o un ruolo responsabile che possa approvare, rimuovere e riesaminare accessi a dataset, strumenti di annotazione, feature store, log di valutazione e artefatti del modello.

Il terzo è la versione del dataset. Il ledger deve mostrare quale versione è stata usata per esperimenti, training, fine-tuning, valutazioni e candidate release. Se il dataset viene ricostruito, la modifica deve comparire.

Il quarto è il rischio delle dipendenze. Molti rischi AI passano da superfici software ordinarie: notebook, API, pacchetti, storage, backup, interfacce, log, sistemi di autenticazione, pannelli amministrativi. Il ledger deve indicare quali componenti possono toccare dati personali e se sono stati verificati.

Il quinto è l’evidenza di audit. Può essere un threat model, un export degli accessi, un report di validazione del dataset, una sezione della DPIA, un test di sicurezza, una valutazione di leakage, una decisione firmata. Non si tratta di collezionare documenti. Si tratta di rendere le decisioni ricostruibili.

Il sesto è il trigger DPIA. Se il workflow usa dati sensibili, combina dataset, tratta dati personali su larga scala, coinvolge persone vulnerabili, introduce un uso tecnologico innovativo o crea rischi significativi come abuso, breach o discriminazione, il ledger deve mostrarlo. Non deve dipendere dalla memoria di una riunione.

Il settimo è il deployment constraint. Alcuni sistemi possono uscire solo in beta interna, solo con revisione umana, solo senza retention dei prompt, solo in certi mercati, solo con campi mascherati o solo sotto specifiche soglie operative. Il vincolo è parte del comportamento del prodotto.

L’ottavo è lo shutdown path. Se una fonte dati è compromessa, una dipendenza viene revocata, una versione del modello espone dati protetti o l’output comincia a produrre azioni non sicure, chi ferma il sistema e cosa succede dopo?

Quando la DPIA cambia la roadmap?

Una DPIA non dovrebbe comparire quando la roadmap è già stata promessa. Se il sistema AI richiede una Data Protection Impact Assessment, la roadmap ha un nuovo flusso di lavoro sul rischio. Questo può cambiare sequenza, scope, architettura, pubblico di lancio o metriche di successo.

Immagina un team che voglia usare ticket storici di supporto per addestrare un assistente interno. Il ledger costringe a rispondere prima di accelerare sul modello. Quali ticket contengono dati personali? Ci sono informazioni su pagamenti, salute, minori o dispute legali? L’annotazione avviene in un ambiente controllato? Dati sintetici o mascherati bastano per i test di integrazione? Il modello è stato valutato per leakage? Il deployment richiede approvazione umana? Quali prove servono a privacy, security, prodotto e engineering per dire che il rischio è stato ridotto a un livello accettabile?

Questo non rallenta il delivery in modo cieco. Evita di scambiare velocità per controllo. Ed è vicino al tema dell’osservabilità. In L’osservabilità degli agenti AI vuole contratti, le trace sono utili perché rendono ispezionabile il comportamento a runtime. Il development security ledger rende ispezionabile il sistema mentre viene assemblato.

Un buon ledger velocizza anche le decisioni. Quando qualcuno chiede se si può passare da beta a disponibilità generale, il team non deve ripartire da opinioni sparse. Può leggere il ledger: le versioni dei dataset sono congelate? Gli owner degli accessi sono nominati? La DPIA è completa? I rischi delle dipendenze sono mitigati o accettati? Lo shutdown path è stato testato? Se manca qualcosa, il blocco non è governance vaga. È evidenza mancante e nominata.

Il ledger ha bisogno di owner, non solo di campi

L’errore più comune è assegnare tutto a legal, privacy o security. Così nasce il compliance theater. Prodotto definisce purpose e vincoli di deployment. Data possiede lineage, qualità e versioning. Engineering possiede ambienti, dipendenze, accessi implementati, riproducibilità e meccanismi di stop. Legal e privacy interpretano base giuridica, diritti, soglie di rischio e DPIA. Security guida threat modeling, test, review degli accessi e prontezza agli incidenti.

Il ledger è il punto in cui queste responsabilità si incontrano. Va rivisto ai passaggi chiave: ingresso dei dati, primo training, freeze della valutazione, integrazione, lancio limitato, estensione del deployment, retraining. Il ritmo conta più del template. Se viene aggiornato solo alla fine, è già tornato a essere una checklist.

C’è una somiglianza con Consent mode: servono stati fallback, non panico. Il consenso funziona meglio quando il team conosce lo stato fallback prima che il segnale si rompa. La sicurezza AI funziona meglio quando il team conosce lo stato sicuro prima dell’incidente.

Audita un workflow prima di aumentare l’autonomia

Non iniziare costruendo un portale universale di AI governance. Scegli un workflow AI reale, con esposizione a dati personali, e scrivi il suo ledger minimo. Deve essere abbastanza importante da contare e abbastanza stretto da poterlo completare.

In una sessione, elenca purpose, data class, access owner, versione dataset, rischi di dipendenza, evidenze di audit, stato DPIA, vincolo di deployment e shutdown path. Poi guarda i vuoti. Un access owner mancante è un rischio. Una versione dataset assente è un rischio. Uno shutdown path non testato è un rischio. Un trigger DPIA nascosto in una nota è un rischio. Un vincolo di deployment rimasto in chat è un rischio.

L’obiettivo non è rendere pesante ogni sistema AI. L’obiettivo è rendere visibile il rischio quando prodotto, data, engineering, legal, privacy e security possono ancora cambiare il sistema. I sistemi AI hanno bisogno di development security ledger, non di checklist di lancio, perché l’autonomia non si governa con una domanda finale prima della release. Si governa con evidenze vive su cosa è stato costruito, perché è abbastanza sicuro da funzionare e come fermarlo quando la risposta cambia.