L'attacco in sé sembra quasi ordinario. Qualcosa ha analizzato file generici alla ricerca di punti deboli, ha trovato un varco ed è riuscito ad accedere. Poi ha proseguito: ha cercato nell'applicazione altre vulnerabilità, le ha sfruttate, ha modificato dati personali e ha aperto fatture. Ciò che distingue questa notifica è chi, o che cosa, ha condotto la ricerca. Secondo l'organizzazione colpita, si trattava di un agente di IA che utilizzava un noto modello linguistico.

L'AEPD ha subito precisato alcune cautele quando ha pubblicato il caso. Le informazioni provengono dalla notifica dell'organizzazione stessa e devono ancora essere analizzate. L'uso di un determinato modello non significa che il modello, o l'infrastruttura del suo fornitore, sia stato compromesso. E una singola notifica non costituisce una tendenza statistica. Rappresenta, secondo l'Agenzia, un segnale del fatto che gli attacchi assistiti dall'IA iniziano a comparire in incidenti che coinvolgono dati personali reali.

Che cosa ha reso diverso questo attacco

L'IA è presente da tempo negli attacchi informatici: nelle email di phishing, nei messaggi truffa tradotti, nell'analisi del codice. Un agente aggiunge qualcosa di diverso. Può assumere un obiettivo, scomporlo in fasi, usare strumenti, osservare i risultati e adattare le azioni successive, con scarso o nessun intervento umano tra una fase e l'altra.

In questo caso, ciò ha significato che un unico sistema ha concatenato l'intera sequenza, dalla scoperta di una vulnerabilità alla modifica dei dati personali. L'AEPD indica un rischio specifico: un agente che entra in possesso di un account, di una chiave API o di un token con permessi più ampi del necessario può spostarsi tra i servizi prima che qualcuno noti attività anomale. Il dettaglio più significativo del caso spagnolo è quanto sia stato banale l'accesso: l'agente ha semplicemente effettuato il login.

Questo sposta l'attenzione dalla difesa perimetrale a una domanda meno appariscente: quali account, chiavi e token esistono nell'organizzazione, a che cosa può accedere ciascuno di essi e con quale rapidità è possibile revocarne uno?

Il termine del GDPR non cambia. Cambia il tempo per capire.

Il GDPR è neutrale dal punto di vista tecnologico e il caso dell'AEPD non modifica alcun obbligo. L'articolo 32 continua a richiedere una sicurezza adeguata al rischio. L'articolo 33 continua a imporre ai titolari del trattamento di notificare la violazione all'autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne sono venuti a conoscenza, a meno che sia improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche.

La differenza sta nello scarto tra il momento in cui si viene a conoscenza della violazione e quello in cui la si comprende. Un team può sapere che qualcuno ha avuto accesso a un'applicazione e, nel frattempo, stabilire quali record siano stati coinvolti, se i dati siano stati copiati e, come in questo caso, se siano stati alterati. I dati modificati trasformano una questione di riservatezza anche in una questione di integrità, il che rende l'indagine più difficile. Se l'agente ha usato credenziali valide, può inoltre essere complicato distinguere le sue azioni dall'attività legittima.

Per chi gestisce gli incidenti ne derivano due conseguenze. La valutazione giuridica deve iniziare mentre l'indagine tecnica è ancora in corso, non dopo l'arrivo del rapporto forense. E il GDPR lo prevede già: quando non è possibile fornire tutte le informazioni contemporaneamente, l'articolo 33 consente di fornirle in fasi successive, senza ulteriore ingiustificato ritardo. Un piano che considera la notifica come un unico documento definitivo farà fatica a reggere un attacco che si sviluppa alla velocità delle macchine.

A seconda dell'organizzazione, lo stesso incidente può far scattare anche obblighi di segnalazione ai sensi di NIS2, DORA o del Cyber Resilience Act, ciascuno con soglie, termini e autorità propri. È nella prima ora che si prendono queste decisioni.

Che cosa c'entra l'AI Act

È facile leggere questo caso come una storia di AI Act. Per l'organizzazione attaccata, in gran parte non lo è. L'AI Act dell'UE regola il modo in cui i sistemi di IA vengono sviluppati, immessi sul mercato e utilizzati. Non disciplina l'autore dell'attacco, e nulla nel caso dell'AEPD suggerisce che la vittima gestisse l'IA coinvolta.

L'AI Act può diventare rilevante sul versante opposto: quando l'organizzazione impiega agenti di IA propri. Gli agenti che leggono i dati dei clienti, aggiornano un CRM, inviano email o avviano pagamenti dispongono esattamente del tipo di accesso di cui l'AEPD mette in guardia. Se uno di essi, o le sue credenziali, venisse compromesso, la stessa catena di eventi potrebbe attraversare i sistemi dell'organizzazione, partendo dall'interno.

È qui che privacy e governance dell'IA si incontrano:

• Ai sensi del GDPR, ciò che gli agenti dell'organizzazione fanno con i dati personali richiede una base giuridica, spesso una valutazione d'impatto sulla protezione dei dati (DPIA) e garanzie nei casi di decisioni automatizzate.

• Ai sensi dell'AI Act, i sistemi di IA ad alto rischio devono raggiungere livelli adeguati di accuratezza, robustezza e cibersicurezza in base all'articolo 15. In seguito al Digital Omnibus sull'IA, tali obblighi si applicano dal 2 dicembre 2027 per i sistemi autonomi e dal 2 agosto 2028 per l'IA integrata in prodotti regolamentati. I fornitori dei modelli di IA per finalità generali più avanzati hanno già oggi obblighi in materia di cibersicurezza e di incidenti gravi.

• In entrambi i casi, le domande pratiche sono le stesse: quali agenti vengono gestiti, chi è responsabile di ciascuno, a quali dati e sistemi può accedere e chi ha approvato tale accesso?

Il nostro punto di vista: le organizzazioni che trattano GDPR e AI Act come progetti separati risponderanno a queste domande due volte, in luoghi diversi e probabilmente in modo diverso. Sono un unico insieme di domande.

Come Formalize supporta tutto questo

Una piattaforma GRC non rileva né blocca un agente di IA. Questo è il compito degli strumenti di sicurezza, dalla gestione delle identità al monitoraggio. Ciò che una piattaforma GRC fa è garantire che la parte organizzativa regga quando si verifica un incidente, e che sia possibile dimostrarlo.

In Formalize, questo significa:

• Valutazioni del rischio con responsabili assegnati, aggiornate man mano che minacce come gli attacchi assistiti dall'IA cambiano il quadro.

• Controlli come attività ricorrenti e supportate da evidenze, per esempio le revisioni degli accessi per account di servizio e chiavi API, anziché buone intenzioni in un documento di policy.

• Flussi di lavoro per gli incidenti che registrano chi ha valutato che cosa, quando e perché, dal primo alert alla decisione di notifica.

• GDPR e AI Act nello stesso sistema, con blueprint per entrambi, così che i registri delle attività di trattamento e i sistemi di IA siano governati fianco a fianco.

Quando, in seguito, un'autorità di controllo chiede che cosa si sapeva, quando lo si sapeva e che cosa è stato fatto, la risposta dovrebbe già esistere. Scopri l'approccio di Formalize alla conformità al GDPR e all'AI Act.