Il debito dei dati sta diventando un rischio per la sicurezza dell'AI aziendale
Google News ha portato alla luce un avvertimento di IT Brew che mette in discussione una comune convinzione sull'AI aziendale: i modelli più recenti non possono compensare anni di controlli sui dati trascurati.
Il problema immediato è il debito dei dati, ovvero il costo accumulato di informazioni incomplete, incoerenti, inaccessibili o gestite in modo inadeguato. Questo debito è precedente all'AI generativa. Tuttavia, i sistemi di AI possono farlo emergere più rapidamente e diffonderne le conseguenze più ampiamente.
Il conflitto non si limita più alla questione se dati scadenti producano risposte deboli. Gli agenti AI possono recuperare record, richiamare software e formulare raccomandazioni in tutti i sistemi aziendali. Quando i dati sottostanti non dispongono di chiare regole di proprietà o di accesso, un problema di accuratezza diventa un problema di sicurezza.
Questo pone i dirigenti aziendali in una posizione scomoda. Subiscono pressioni per ampliare l'uso dell'AI mentre i team di sicurezza continuano a non disporre di inventari affidabili, classificazioni, politiche di conservazione e mappe delle autorizzazioni. La velocità di implementazione e una governance dei dati responsabile procedono ora a ritmi diversi.
Uno studio del giugno 2026 di Genpact e HFS Research fornisce a questa tensione una dimensione finanziaria. I suoi autori hanno intervistato 2.002 dirigenti in 16 settori e hanno identificato il debito di dati, tecnologia, processi e talenti come ostacoli al valore dell'AI.
Il rapporto stima che queste passività accumulate lascino bloccati circa 18 trilioni di dollari di valore potenziale nelle aziende Global 2000. La stima merita cautela, ma il problema di fondo è concreto. L'AI non può utilizzare in sicurezza informazioni che un'organizzazione non comprende.
L'avvertimento di Google News riguarda l'infrastruttura, non solo i modelli
Il cambiamento importante è che il debito dei dati ora determina a cosa i sistemi di AI possono accedere, cosa possono esporre e su cosa possono agire.
La copertura di IT Brew si fonda su una più ampia rivalutazione della preparazione delle imprese all'AI. Per anni, le aziende hanno trattato record dispersi, database duplicati, campi non documentati e autorizzazioni estese come un attrito operativo gestibile. L'AI trasforma questi compromessi in input.
Un'applicazione convenzionale raggiunge solitamente le informazioni tramite query predefinite e flussi di lavoro prevedibili. Un assistente di AI generativa può recuperare materiale semanticamente correlato da diversi repository. Un agente può andare oltre, scegliendo strumenti e compiendo azioni.
Questa maggiore portata cambia il calcolo della sicurezza. Un documento dimenticato in una vecchia unità condivisa potrebbe non attirare attenzione durante il lavoro normale. Un sistema di recupero può farlo emergere perché il suo contenuto somiglia alla domanda di un utente, anche quando la sua posizione di archiviazione sembra poco visibile.
Un'autorizzazione obsoleta crea un problema simile. Un dipendente che conserva l'accesso dopo aver cambiato ruolo potrebbe visitare raramente il vecchio sistema. Un assistente AI collegato a quel sistema può portarne i contenuti nelle conversazioni di routine. In pratica, un venditore trasferito in un'altra regione potrebbe chiedere la cronologia di un account e ricevere concessioni sui prezzi o note sui clienti di un territorio che non gestisce più.
Il fallimento originario dell'accesso resta di origine umana. L'AI aumenta la frequenza e la scala con cui tale fallimento può avere conseguenze.
Ecco perché la distinzione tra qualità dei dati e sicurezza dei dati sta diventando meno utile. Una classificazione errata di un cliente può distorcere una raccomandazione dell'AI. Un'etichetta di sensibilità mancante può esporre le informazioni private dello stesso cliente.
Entrambi i fallimenti hanno origine nella gestione dei dati. Le loro conseguenze ricadono in parti diverse dell'azienda.
Lo studio sul debito aziendale definisce il debito dei dati come l'attrito generato da informazioni frammentate, inaccessibili, di scarsa qualità o governate in modo inadeguato. Colloca questo onere accanto al debito di processi, tecnologia e talenti.
Queste categorie interagiscono. Le applicazioni legacy creano dati frammentati. I dati frammentati costringono i dipendenti a creare soluzioni manuali. Le soluzioni manuali dipendono da conoscenze non documentate detenute da poche persone.
Aggiungere l'AI a questo ambiente non elimina le dipendenze. Può nasconderle dietro un'interfaccia conversazionale.
Lo studio ha rilevato che la scarsa qualità delle decisioni e insight inaffidabili erano l'effetto aziendale principale del debito dei dati selezionato più frequentemente, al 18%. Costi più elevati e spreco di risorse seguivano al 15%.
La sicurezza non è esterna a questa catena. Un'azienda non può proteggere costantemente i dati se non riesce a identificare copie autorevoli, proprietari responsabili o utenti legittimi. Non può nemmeno spiegare una decisione dell'AI quando i record di supporto non hanno provenienza.
La provenienza descrive da dove provengono le informazioni e come sono cambiate. Diventa essenziale quando un modello combina risultati di ricerca, documenti interni, istruzioni dell'utente e strumenti esterni. In linee guida congiunte, NSA, CISA, FBI e partner internazionali raccomandano specificamente di tracciare la provenienza dei dati e autenticare le revisioni affidabili durante l'intero ciclo di vita dell'AI.
Senza provenienza, gli investigatori potrebbero osservare un output non sicuro ma avere difficoltà a ricostruirne la causa. La fonte era inaccurata, avvelenata, obsoleta, dotata di autorizzazioni improprie o semplicemente fraintesa dal modello?
Google News è utile qui come segnale di crescente attenzione, non come prova in sé. Le prove sottostanti provengono da indagini aziendali, telemetria di sicurezza, standard ed esperienze organizzative riportate.
La stessa ricerca sull'automazione di IT Brew ha rilevato che solo il 12% dei professionisti IT intervistati si sentiva molto sicuro che i dipendenti comprendessero le pertinenti politiche di sicurezza dei dati. Questa cifra riflette la consapevolezza, non l'applicazione tecnica, ma evidenzia il debole livello umano che circonda l'adozione rapida.
La stessa ricerca ha rilevato che il 29% degli intervistati ha riscontrato un lieve aumento della complessità dopo le implementazioni dell'AI. La complessità conta perché i team di sicurezza devono comprendere un sistema prima di poterlo monitorare in modo affidabile.
Un complesso stack AI può comprendere data warehouse, database vettoriali, provider di modelli, sistemi di identità, plugin e dispositivi dei dipendenti. Ogni connessione crea un ulteriore punto in cui autorizzazioni, registrazione o regole di conservazione possono divergere.
Il titolo, quindi, non è che i dati aziendali necessitino di un'altra campagna di pulizia. L'AI ha cambiato le conseguenze del rinvio di quel lavoro.
Il debito dei dati amplia la superficie di attacco dell'AI
Dati governati in modo inadeguato offrono ai sistemi di AI maggiori opportunità di rivelare informazioni sensibili o seguire un contesto compromesso.
Una superficie di attacco include ogni percorso attraverso cui un sistema può essere manipolato o raggiunto. L'AI amplia questa superficie perché il linguaggio naturale diventa un'interfaccia verso dati e software.
Il rischio inizia prima che un attaccante entri in gioco. I dipendenti possono incollare materiale proprietario in servizi non approvati. I team possono collegare assistenti ai repository senza esaminare le autorizzazioni ereditate. Gli sviluppatori possono raccogliere log operativi contenenti segreti o dati personali.
Queste azioni creano shadow AI, ovvero un uso dell'AI che opera al di fuori dei controlli di sicurezza e governance approvati. Gli strumenti possono essere legittimi, ma l'organizzazione non può osservare in modo affidabile come le informazioni si muovano attraverso di essi.
La ricerca sui rischi dell'AI di Cyberhaven ha analizzato miliardi di movimenti di dati che coinvolgevano servizi di AI generativa, applicazioni endpoint e agenti. L'azienda afferma che il comportamento dell'AI aziendale sta creando rischi che i controlli più datati spesso non riescono a rilevare.
La ricerca dei fornitori va letta tenendo presenti i loro incentivi commerciali. Tuttavia, il divario di visibilità descritto è coerente con un principio basilare della sicurezza: i controlli non possono proteggere informazioni che non riescono a localizzare o classificare.
Il debito dei dati indebolisce questa visibilità in diversi modi.
In primo luogo, i record duplicati rendono difficile identificare la versione autorevole. I team di sicurezza potrebbero proteggere un database corrente mentre un'esportazione più vecchia resta disponibile tramite una cartella condivisa.
In secondo luogo, una classificazione incompleta lascia i modelli senza regole affidabili per gestire contenuti sensibili. Un documento può contenere informazioni riservate anche quando la sua etichetta non indica nulla.
In terzo luogo, identità incoerenti oscurano chi dovrebbe avere accesso. Acquisizioni, account di collaboratori esterni, credenziali condivise e cambi di ruolo possono lasciare autorizzazioni che sopravvivono al loro scopo aziendale.
In quarto luogo, pratiche di conservazione deboli mantengono disponibili informazioni dopo che il loro valore è scaduto. Il recupero AI rende più facile riscoprire queste informazioni inattive.
In quinto luogo, la mancanza di tracciabilità impedisce ai team di risalire dall'output alla sua origine. Ciò complica la risposta agli incidenti e rende più difficili da contenere gli errori dannosi.
Queste debolezze diventano più gravi quando gli agenti AI ricevono accesso permanente. L'accesso permanente resta disponibile in modo continuativo, invece di essere concesso brevemente per un compito specifico.
Un assistente che si limita a redigere testo a partire da documenti approvati ha una portata operativa limitata. Un agente che può leggere fatture, aggiornare record dei clienti e inviare messaggi combina diversi confini di fiducia.
Se un repository collegato contiene istruzioni fuorvianti, l'agente può incontrare un'iniezione indiretta di prompt. In questo attacco, testo dannoso all'interno di contenuti esterni o recuperati tenta di reindirizzare il comportamento del modello.
Il modello potrebbe trattare il testo ostile come un'istruzione anziché come dati ordinari. Difese efficaci richiedono più che filtrare frasi sospette. I sistemi devono separare le istruzioni affidabili dai contenuti non affidabili e limitare ciò che gli strumenti possono fare.
Il debito dei dati complica questa separazione. Quando le organizzazioni non dispongono di inventari affidabili delle fonti, non possono decidere facilmente quali repository meritino fiducia. Quando la proprietà dei documenti non è chiara, nessuno ha un preciso dovere di esaminare contenuti rischiosi.
Anche il controllo degli accessi si comporta diversamente nei sistemi di recupero. Un indice di ricerca può conservare informazioni dopo che il documento originale viene eliminato o limitato. Gli embedding memorizzati nella cache, che sono rappresentazioni numeriche utilizzate per la ricerca semantica, possono creare ulteriori questioni relative al ciclo di vita.
L'embedding potrebbe non riprodurre da solo un documento sorgente. Tuttavia, il testo indicizzato, i metadati, la cache di recupero e i log del modello possono ciascuno conservare dettagli sensibili.
I team di sicurezza devono sapere quali componenti archiviano contenuti grezzi e quali conservano rappresentazioni derivate. Devono anche comprendere il comportamento di eliminazione lungo l'intera pipeline. Ad esempio, quando un collaboratore esterno uscente perde l'accesso a una cartella di progetto, la stessa restrizione dovrebbe raggiungere tempestivamente l'indice di ricerca; altrimenti, gli ex colleghi potrebbero continuare a vedere estratti da documenti che il sistema sorgente non restituisce più.
Cloud Security Alliance ha riferito che le informazioni non strutturate rappresentano una quota stimata dal 70% al 90% dei dati aziendali. Il suo studio sui dati non strutturati sostiene che le pratiche di governance tradizionali faticano a gestire questo volume.
I dati non strutturati includono email, messaggi in chat, documenti, registrazioni e presentazioni. Sono anche il materiale a cui i sistemi di retrieval-augmented generation si rivolgono spesso per primo.
Questo crea un'inversione centrale. Le informazioni che le aziende un tempo consideravano troppo disperse da gestire sono diventate un prezioso contesto per l'AI. La loro utilità attira l'integrazione prima che il lavoro di governance sia completo.
L'implementazione più rapida dell'AI si scontra con una governance responsabile
La principale sfida è tra la velocità di implementazione e la capacità di spiegare ogni accesso importante ai dati o azione dell'AI.
I programmi di AI spesso iniziano con un obiettivo aziendale evidente. Un team di assistenza vuole risposte più rapide. Un gruppo finanziario vuole automatizzare la revisione delle fatture. Un'organizzazione di ingegneria vuole assistenti in grado di cercare nella documentazione tecnica.
La bonifica dei dati offre un ritorno meno immediato. Catalogare i record, rivedere le autorizzazioni, rimuovere i duplicati e definire le regole di conservazione può sembrare scollegato dalla dimostrazione attesa dai dirigenti.
Questa differenza di visibilità incoraggia i team a costruire prima il livello AI. Collegano un modello ai sistemi esistenti, testano un flusso di lavoro promettente e rimandano il lavoro fondamentale finché la scalabilità non diventa necessaria.
L'approccio funziona finché il progetto pilota resta circoscritto. Fallisce quando l'organizzazione aggiunge utenti, repository, strumenti o azioni autonome.
I team di sicurezza ereditano quindi un sistema il cui valore dipende da un accesso esteso. Limitare tale accesso può ridurre la qualità delle risposte. Mantenerlo ampio può violare i principi del privilegio minimo.
Il privilegio minimo significa concedere a ciascun utente o servizio soltanto l'accesso necessario per il compito attuale. Diventa più difficile da applicare quando un agente svolge molti compiti per molti utenti.
I diritti di accesso di un dipendente non dovrebbero trasformarsi automaticamente nelle autorizzazioni permanenti di un agente. L'agente può operare più rapidamente, combinare informazioni tra sistemi e agire quando il dipendente non controlla ogni passaggio.
La telemetria di Teleport illustra la preoccupazione. La sua indagine del 2026 ha coinvolto 205 CISO, architetti della sicurezza e responsabili delle piattaforme. L'azienda ha riferito che le organizzazioni con sistemi AI dotati di privilegi eccessivi hanno subito 4,5 volte più incidenti di sicurezza rispetto a quelle che applicano il privilegio minimo.
I risultati sulla sicurezza delle identità provengono da un fornitore e non stabiliscono un nesso causale. Indicano comunque un meccanismo credibile: accessi non necessari aumentano il numero di azioni dannose che un sistema compromesso può compiere.
Una buona governance deve operare a più livelli.
A livello di dati, i team necessitano di responsabili, classificazioni, regole di qualità, periodi di conservazione e usi approvati. A livello di identità, necessitano di mappature chiare tra utenti, servizi, agenti e risorse.
A livello di modello, necessitano di test per fughe di dati, selezione non sicura degli strumenti, output inaffidabili e manipolazione. A livello operativo, necessitano di log che colleghino un'azione AI al relativo utente, alle fonti di dati, al modello, alle istruzioni e agli strumenti.
Nessuno di questi controlli funziona bene isolatamente.
Un registro degli accessi perfetto non può spiegare se una fonte fosse accurata. Un catalogo dati ordinato non può impedire a un agente di compiere un'azione non necessaria. Test rigorosi sui modelli non possono compensare credenziali che consentono modifiche illimitate in produzione.
Per questo l'acquisto di un prodotto di sicurezza AI non elimina il debito sui dati. I prodotti possono migliorare la scoperta, il monitoraggio, l'applicazione delle policy o i test. Non possono decidere le regole legittime di proprietà e utilizzo di ogni organizzazione.
Tali decisioni richiedono il coinvolgimento dell'azienda. I team legali comprendono gli obblighi contrattuali. I team della privacy comprendono i requisiti relativi ai dati personali. I responsabili dei reparti comprendono quali record restano operativamente necessari.
I team di sicurezza traducono queste responsabilità in controlli, ma non possono inventare il contesto aziendale sottostante. Le linee guida congiunte per un'AI sicura di CISA e del National Cyber Security Centre del Regno Unito, sostenute da 23 organizzazioni di cybersecurity, attribuiscono analogamente la responsabilità a progettazione sicura, trasparenza e titolarità organizzativa lungo tutto lo sviluppo e l'operatività.
La pressione si estende ai knowledge worker. I dipendenti spesso creano archivi locali, duplicano appunti o esportazioni private perché i sistemi ufficiali sono difficili da consultare. Queste copie possono preservare contesto prezioso sfuggendo al contempo alla governance centralizzata.
Un sistema di gestione della conoscenza ben progettato può ridurre la frammentazione non necessaria quando le sue regole di accesso e conservazione restano chiare. Può anche creare nuovi rischi quando i team acquisiscono materiale senza rivederne le autorizzazioni.
L'obiettivo non è la centralizzazione massima. È un controllo prevedibile su dove risiedono le informazioni, chi può accedervi e come l'AI può utilizzarle.
Questo obiettivo è in conflitto con la convinzione che un modello AI debba cercare ovunque. Un recupero ampio può migliorare la praticità, ma aumenta anche l'esposizione e rende più difficile rilevare il contesto errato.
L'alternativa sicura è il recupero selettivo. I sistemi dovrebbero filtrare le fonti in base all'utente, al compito, alla sensibilità e allo stato di autorizzazione corrente prima che il contenuto raggiunga il modello.
Questo filtraggio deve avvenire al momento della richiesta. Copiare documenti in un indice centrale con un solo account di servizio può appiattire le distinzioni esistenti nei sistemi di origine.
I team necessitano anche di confini espliciti per gli strumenti. Un agente che analizza una fattura non necessita automaticamente dell'autorizzazione ad approvare un pagamento. Un assistente che raccomanda una risposta a un cliente non necessita dell'autorità per inviarla. In pratica, il revisore finanziario dovrebbe vedere il pagamento proposto, la fattura di origine e gli indicatori di eccezione, mentre l'agente deve restare incapace di erogare fondi senza un'approvazione autorizzata separata.
Queste distinzioni rallentano l'implementazione iniziale. Rendono anche più difendibile un'implementazione su scala.
Cosa non dimostrano i numeri sul debito dei dati
La ricerca sul debito aziendale identifica un vincolo diffuso, ma non dimostra che ogni fallimento dell'AI inizi con dati scadenti.
La stima di 18.000 miliardi di dollari di Genpact e HFS Research è la cifra più rilevante associata alla recente copertura. Rappresenta un potenziale valore modellato, non denaro registrato nei bilanci aziendali.
La stima combina possibili aumenti dei ricavi e riduzioni dei costi qualora le aziende Global 2000 risolvessero quattro tipi di debito aziendale. Non dovrebbe essere interpretata come un ritorno garantito dalla modernizzazione dei dati.
Solo una delle quattro categorie è il debito dei dati. I vincoli legati a processi, tecnologia e talenti possono bloccare un progetto anche quando le informazioni sono accurate e ben governate.
Un modello può anche fallire per limitazioni non correlate all'igiene dei dati. Può allucinare, fraintendere una richiesta, selezionare lo strumento sbagliato o rispondere in modo incoerente a prompt simili.
I fallimenti di sicurezza hanno molte fonti. Una dipendenza compromessa, una credenziale rubata, un'API vulnerabile, un plugin non sicuro o una progettazione applicativa difettosa possono aggirare una governance dei dati altrimenti valida.
Trattare il debito dei dati come causa unica ripeterebbe la stessa semplificazione che ha creato il problema. I sistemi AI aziendali sono sistemi sociotecnici: il loro comportamento dipende congiuntamente da software, informazioni, processi e persone.
Anche la progettazione dell'indagine del rapporto è importante. Le risposte dei dirigenti rivelano vincoli organizzativi percepiti. Non offrono una verifica indipendente del patrimonio dati di ogni azienda partecipante.
I partecipanti potrebbero usare “debito dei dati” per descrivere condizioni diverse. Un dirigente può intendere record dei clienti duplicati. Un altro può intendere bassa qualità analitica, accesso limitato o governance assente.
La categoria resta utile perché queste condizioni condividono un modello di costi differiti. Le organizzazioni hanno ottenuto velocità nel breve termine rinviando il lavoro, per poi incontrare costi più alti quando l'AI ha richiesto informazioni coerenti.
Tuttavia, l'etichetta può diventare troppo ampia. I fornitori possono associare il “debito” a qualsiasi problema legacy e presentare la modernizzazione come soluzione ovvia.
Questa impostazione rischia di incoraggiare un altro costoso programma di trasformazione senza priorità chiare. Un'azienda potrebbe sostituire le piattaforme mantenendo al contempo proprietà poco chiare e accessi eccessivi.
Il test migliore è operativo. L'organizzazione sa rispondere a domande specifiche su un flusso di lavoro AI ad alto valore?
I team dovrebbero sapere quali fonti utilizza il sistema, chi ne è responsabile e quando sono state riesaminate l'ultima volta. Dovrebbero sapere se le autorizzazioni restano allineate ai ruoli attuali.
Dovrebbero sapere cosa può fare l'agente dopo aver recuperato le informazioni. Dovrebbero inoltre sapere se gli investigatori possono ricostruire una decisione importante senza affidarsi alla narrazione del modello.
Il National Institute of Standards and Technology organizza il lavoro sul rischio AI attorno alla governance, alla mappatura, alla misurazione e alla gestione del rischio. Il suo AI Risk Management Framework and Generative AI Profile richiede finalità di sistema documentate, monitoraggio continuo, responsabilità definite per la risposta agli incidenti e riesami regolari dei sistemi AI di terze parti, anziché fare affidamento su un unico controllo o prodotto.
Questa visione del ciclo di vita si adatta al debito dei dati perché le vecchie debolezze raramente scompaiono con una sola migrazione. I team devono continuare a verificare qualità, autorizzazioni, provenienza e utilizzo mentre i sistemi evolvono.
Un'altra incertezza riguarda gli esiti di sicurezza misurabili. I partecipanti a un'indagine possono segnalare una scarsa preparazione, ma le aziende raramente divulgano incidenti AI dettagliati. I dati pubblici offrono quindi una visione incompleta di frequenza e gravità.
Alcuni incidenti possono essere classificati come normali perdite di dati, abusi di accesso o compromissioni applicative anche quando l'AI ha influenzato il percorso. Altri possono riguardare output non sicuri senza causare una violazione segnalabile.
Questo rende difficile il confronto. Le organizzazioni necessitano di definizioni interne per gli incidenti correlati all'AI prima di poter valutare se i controlli li riducono.
Una definizione utile dovrebbe includere la manipolazione del modello, la divulgazione non autorizzata di dati, azioni non sicure degli agenti e infrastruttura AI compromessa. Dovrebbe anche distinguere il danno confermato dalle violazioni delle policy e dai quasi incidenti.
Senza questa disciplina, i leader possono dichiarare un miglioramento perché gli incidenti segnalati restano bassi. Il numero potrebbe invece riflettere una capacità di rilevamento limitata.
La conclusione scettica è semplice. Il debito dei dati è un credibile moltiplicatore di rischio, non una spiegazione completa dell'insicurezza dell'AI.
Le aziende che ripuliscono i propri record ma ignorano l'identità degli agenti, il comportamento dei modelli e le dipendenze software resteranno esposte. Le aziende che acquistano strumenti di monitoraggio ma lasciano irrisolta la titolarità affronteranno la stessa ambiguità con dashboard migliori.
Tre segnali mostreranno se la sicurezza AI sta recuperando terreno
Il prossimo banco di prova è se le aziende trasformeranno la preoccupazione per il debito dei dati in autorizzazioni più ristrette, recupero tracciabile e riduzione misurabile degli incidenti.
Il primo segnale è l'adozione di controlli di identità specifici per attività per gli agenti AI. Le organizzazioni dovrebbero abbandonare gli account di servizio condivisi e le credenziali permanenti.
Ogni agente dovrebbe avere un'identità distinta, autorizzazioni limitate e un responsabile umano o aziendale. L'accesso dovrebbe restringersi in base al compito e scadere quando non più necessario. Il concept paper del 2026 di NIST su identità e autorità degli agenti software identifica autorizzazione, audit, non ripudio e controlli contro la prompt injection come aree specifiche che richiedono standard e indicazioni di implementazione più solidi.
Se questa diventerà una pratica standard, il divario tra implementazione dell'AI e preparazione alla sicurezza inizierà a ridursi. Se l'accesso permanente resterà comune, il debito dei dati continuerà a tradursi in un raggio d'impatto più ampio.
Il secondo segnale è la prova che i sistemi di recupero preservano le autorizzazioni delle fonti e le regole di eliminazione. I fornitori di AI aziendale promettono sempre più spesso connettori sicuri, ma gli acquirenti necessitano di prove tecniche.
I team di sicurezza dovrebbero verificare se l'accesso revocato scompare tempestivamente dai risultati di ricerca. Dovrebbero verificare come indici, cache, log e backup gestiscono il materiale eliminato.
Dovrebbero anche verificare se le citazioni identificano in modo affidabile la fonte esatta utilizzata per una risposta. Un link generico a un repository è insufficiente quando gli investigatori necessitano di una provenienza a livello di documento.
I progressi in questo ambito rafforzerebbero l’idea che le organizzazioni possano utilizzare informazioni distribuite senza appiattirne i controlli. Una continua deriva delle autorizzazioni dimostrerebbe che la comodità prevale ancora su un recupero delle informazioni responsabile.
Il terzo segnale è una migliore comunicazione degli eventi di sicurezza legati all’AI. Aziende e fornitori hanno bisogno di categorie coerenti che distinguano tra fuga di dati, prompt injection, eccessiva autonomia, abuso dell’identità e compromissione dell’infrastruttura.
Un maggior numero di segnalazioni non significa necessariamente che la sicurezza stia peggiorando. I primi aumenti possono indicare che rilevamento e classificazione stanno migliorando.
La misura importante è se le organizzazioni riducono gli esiti gravi e abbreviano il tempo necessario per contenerli. Ciò richiede metriche comparabili, non affermazioni di marketing isolate.
Questi tre segnali dovrebbero comparire nelle revisioni degli acquisti e nelle dashboard operative. Sono più informativi del numero di progetti pilota avviati o dei dipendenti a cui è stato dato accesso a un assistente.
L’attenzione di Google News continuerà a spostarsi verso agenti AI, nuovi prodotti di sicurezza e incidenti rilevanti. I lettori dovrebbero guardare oltre quei titoli e considerare lo stato del livello dati.
Chiedetevi se un sistema in evidenza sa quali informazioni sono autorevoli. Chiedetevi se il suo accesso segue l’utente e l’attività. Chiedetevi se le sue azioni possono essere ricostruite dopo che qualcosa è andato storto.
I leader aziendali dovrebbero iniziare da un singolo flusso di lavoro di valore, anziché da una promessa di riordino estesa all’intera organizzazione. Mappate le sue fonti, i responsabili, le autorizzazioni, i requisiti di conservazione, gli strumenti degli agenti e le modalità di errore.
Poi testate i controlli con account revocati, documenti avvelenati, record obsoleti e richieste che oltrepassano i confini di autorizzazione. Registrate ciò che il sistema ha recuperato, ignorato e tentato di fare.
Questo esercizio non eliminerà ogni rischio dell’AI. Rivelerà se l’organizzazione comprende il sistema che ha già implementato.
La domanda non è più se il debito dei dati riduca la qualità dei modelli. È se le aziende ritireranno quel debito prima che l’AI trasformi ogni autorizzazione dimenticata e ogni record non gestito in una decisione di sicurezza attiva.
