Prevenzione della fuga di dati AI: come impedire la fuga di dati sensibili tramite prompt, RAG, memoria e agenti

Introduzione

I dati sensibili di solito non lasciano un sistema di intelligenza artificiale con un dramma operistico. Non sfonda la porta, non ruba un'auto sportiva e svanisce nella notte mentre gli allarmi urlano. Più spesso esce in silenzio, nascosto in una risposta innocente, in un pezzo di documento recuperato, nel risultato di uno strumento, in una riga di registro dettagliata o in un allegro riepilogo generato da un modello a cui è stato semplicemente concesso troppo accesso e non abbastanza supervisione.

Questa è la prima cosa che vale la pena dire chiaramente. La fuga di dati dall’intelligenza artificiale non è un problema di fantascienza. È un problema di ingegneria e, come la maggior parte dei problemi di ingegneria, cresce nel divario tra ciò che le persone credono che un sistema stia facendo e ciò che gli è effettivamente consentito fare. Un team crea un copilota per la documentazione interna. Funziona magnificamente. Quindi qualcuno lo indirizza a un'origine dati più ampia, mantiene le stesse autorizzazioni utente, aggiunge memoria, aggiunge alcuni strumenti e all'improvviso il sistema non si limita più a riassumere un testo innocuo. È aggirarsi per un magazzino di materiale privato con la disinvoltura di un ladro educato.

Il pericolo non è che il modello sia malvagio. Il modello non è malvagio. Il modello è obbediente nel peggiore dei modi. Mescolerà istruzioni, contesto, testo recuperato, prompt nascosti, memoria obsoleta e output degli strumenti in un unico brodo funzionante, quindi produrrà qualcosa che sembrerà utile. Se l’architettura attorno ad essa è sciatta, la disponibilità diventa condivisione eccessiva. Se i confini dei dati sono deboli, la convenienza diventa esfiltrazione. E se il team si affida più a una formulazione tempestiva che alla progettazione del sistema, la storia finisce come finiscono molte storie evitabili: con sorpresa, imbarazzo e un incontro che nessuno voleva.

Questo articolo riguarda la prevenzione di tale risultato. Esamineremo le reali superfici di perdita nei moderni sistemi di intelligenza artificiale, perché le difese ingenue falliscono, quali controlli funzionano effettivamente e come costruire un gateway piccolo ma utile che un team tecnico possa gestire ed estendere. Il tono qui è volutamente pratico. Il punto non è sembrare saggio. Il punto è aiutarti a realizzare un sistema di intelligenza artificiale che non consegni i tuoi dati alla persona sbagliata solo perché qualcuno ha scritto un messaggio entusiasta.

Perché la perdita di intelligenza artificiale avviene in modi così ordinari

Le applicazioni tradizionali solitamente separano i ruoli abbastanza bene. L'input arriva da un posto, la logica aziendale risiede da qualche altra parte e le autorizzazioni vengono applicate tramite percorsi di codice espliciti. I sistemi di intelligenza artificiale sfumano questi confini. Il linguaggio naturale diventa sia piano di input che di controllo. La conoscenza recuperata diventa sia prova che superficie di attacco. Le chiamate agli strumenti diventano sia capacità che esposizione. Anche la memoria, che sembra innocua nelle diapositive dei prodotti, può diventare una lenta perdita se nessuno è disciplinato su cosa viene archiviato e per quanto tempo.

Questo è il motivo per cui i team di prodotto ordinari sottovalutano il problema. Pensano di integrare un modello in un flusso di lavoro. In realtà stanno introducendo uno strato middleware probabilistico che ricombina felicemente i dati provenienti da più zone di fiducia. Se il messaggio di sistema dice "non rivelare mai segreti", sembra rispettabile. Inoltre, non cambia il fatto di fondo che il modello può ancora vedere quei segreti, ragionare su di essi ed essere manipolato per confezionarli in una forma che i progettisti non avevano previsto.

Le linee guida di Microsoft per la protezione delle applicazioni IA aziendali sottolineano questo punto con un linguaggio aziendale sobrio: perdita di dati, iniezione tempestiva e lacune nella governance sono già tra le principali preoccupazioni che le organizzazioni devono affrontare quando implementano l’intelligenza artificiale. Il documento è educato, ma il messaggio è schietto. Se l’intelligenza artificiale ha un ampio accesso e una supervisione debole, le informazioni sensibili scivolano via. Una volta capito questo, la domanda giusta non è più “Come possiamo rendere la richiesta più rigorosa?” La domanda giusta diventa: “Perché il modello è in grado di vedere questo materiale e quale controllo ha fallito prima ancora che il prompt fosse scritto?”

Questo cambiamento di mentalità è importante. La sicurezza matura dell’IA inizia prima che il modello tocchi il primo token. Inizia con la classificazione dei dati, i limiti di recupero, il controllo degli accessi, la disciplina di registrazione e l'autorizzazione degli strumenti. In altre parole, la prevenzione della fuga di dati basata sull’intelligenza artificiale è per lo più un’ingegneria di sistema che indossa un badge AI.

Le vere superfici di perdita

Aiuta a smettere di parlare del “sistema di intelligenza artificiale” come se fosse una scatola. La perdita di solito avviene attraverso uno dei cinque percorsi e ogni percorso ha la propria modalità di guasto.

Il primo percorso è il confine del prompt. I team spesso si preoccupano dei prompt degli utenti e dimenticano che i prompt sono semplicemente una fonte di istruzioni tra le tante. Un modello può anche importare istruzioni di sistema nascoste, documenti recuperati, cronologia chat riepilogativa e dati da strumenti esterni. Se una qualsiasi di queste fonti contiene contenuti contraddittori o troppo ampi, il confine del prompt è già compromesso. Il lavoro di OWASP sui rischi delle applicazioni LLM è stato utile proprio perché costringe i team a smettere di considerare l’iniezione tempestiva come un trucco da festa e iniziare a trattarla come un problema del piano di controllo.

La seconda strada è il recupero. La generazione aumentata di recupero appare ordinata nei diagrammi dell'architettura. C'è un indice vettoriale, una query, un passaggio di classificazione e alcuni blocchi finiscono nella finestra di contesto. Ciò sembra controllato finché non ti ricordi che quei blocchi potrebbero contenere informazioni dal tenant sbagliato, autorizzazioni obsolete, documenti avvelenati, esportazioni non revisionate o testo che contiene istruzioni nascoste per il modello. Il recupero è spesso la superficie di perdita più sottovalutata perché non è drammatica. Sembra una ricerca. Ma la ricerca con un livello generativo in alto può trasformare molto rapidamente un errore di indicizzazione in un evento di divulgazione.

La terza via è la memoria. I team di prodotto adorano la memoria perché fa sentire l'assistente meno legnoso. I team di sicurezza tendono ad amarlo di meno, perché la memoria spesso cresce per caso. Forse una cache di sessione diventa memoria a lungo termine. Forse un archivio di riepilogo interno inizia a conservare i dettagli più a lungo del previsto. Forse le informazioni di identificazione personale vengono conservate in una funzionalità comoda che non è mai stata progettata per carichi di lavoro sensibili. La memoria è il luogo in cui le idee UX amichevoli diventano silenziosamente problemi di politica di conservazione.

Il quarto percorso è l’uso degli strumenti. Un modello in grado di richiamare un sistema di ticketing, un CRM, un repository di codice, un calendario, un gateway SQL o un'API interna non è più solo un motore di testo. È un sistema d'azione. Può essere produttivo. Significa anche che un eccesso di permessi diventa molto più costoso. Il recente lavoro del NIST sull’identità e l’autorizzazione degli agenti di software e intelligenza artificiale è prezioso in questo caso perché affronta il punto che molti team cercano di ignorare: quando un sistema di intelligenza artificiale può agire, identità e autorizzazione smettono di essere argomenti di architettura gradevole e diventano punti di controllo centrali.

Il quinto percorso è l'output e la telemetria. Anche se il recupero, la memoria e gli strumenti sono ragionevolmente ben controllati, il sistema può comunque filtrare attraverso risposte, tracce, registri di debug, set di dati del valutatore, dashboard di analisi e trascrizioni di chat copiate. I team spesso dicono "non esponiamo segreti nell'interfaccia utente", dimenticando che lo stesso contenuto viene archiviato in log, tracce, esportazioni di supporto o set di replay del team rosso. Una fuga di notizie è ancora una fuga di notizie se si verifica nello stack di osservabilità anziché nella bolla del chatbot.

Una volta che queste cinque superfici sono visibili, il problema diventa meno mistico. Non stiamo cercando di rendere un modello linguistico moralmente puro. Stiamo progettando un sistema in cui nessuna singola decisione imprudente apre tutte le porte contemporaneamente.

Perché le difese ingenue falliscono

Esistono diverse difese che sembrano rassicuranti nelle diapositive e deludono gravemente nei sistemi reali.

La prima difesa debole è il sistema di poppa pronto. Dire al modello di non rivelare informazioni riservate è meglio che non dire nulla, così come chiudere una bicicletta con lo spago è meglio che lasciarla per strada con un biglietto che dice "per favore, non farlo". Ma un prompt non è un limite di autorizzazione. Non è una politica di minimizzazione dei dati. Non restringe retroattivamente il recupero. Ciò non impedisce al modello di vedere un segreto nel contesto. Cerca semplicemente di persuadere il modello a comportarsi dopo che le condizioni pericolose si sono già create.

La seconda difesa debole è l’ottimismo dei venditori. Le squadre presumono che il fornitore disponga di guardrail, pertanto il problema è stato esternalizzato. Questa è una fantasia confortante. Le protezioni dei fornitori sono utili, ma non conoscono il modello di inquilino, la tassonomia dei documenti interni, gli obblighi di conservazione, gli endpoint di amministrazione nascosti o la strana scorciatoia middleware di tre quarti fa che inserisce ancora troppo contesto nel modello. Le funzionalità di sicurezza gestite possono ridurre i rischi, ma non possono sostituire la tua architettura.

La terza difesa debole è “ci fidiamo dei nostri dipendenti”. Ovviamente ti fidi dei tuoi dipendenti. Non è questo il punto. Le persone prendono decisioni rapide sotto pressione. La discussione di Microsoft sull’intelligenza artificiale ombra e sull’oversharing è utile perché svela la scomoda verità: i bravi dipendenti possono ancora inserire informazioni sensibili nel modello sbagliato, collegare un modello approvato all’origine dati sbagliata o presumere che una trascrizione di una chat sia effimera quando non lo è. La fiducia nelle persone non sostituisce i confini dei sistemi.

La quarta difesa debole è l'attivazione di alcuni filtri solo al momento dell'uscita. Il filtraggio dell’output è importante, ma è l’ultima rete, non il fondamento. Se il modello vede troppo, recupera troppo, ricorda troppo o può chiamare lo strumento sbagliato, il filtraggio dell'output tenta di pulire il pavimento mentre il tubo è ancora rotto.

Lo schema qui è semplice. Le difese deboli chiedono al modello di comportarsi. Difese forti riducono in primo luogo ciò che il modello può vedere, ricordare, recuperare o chiamare.

Costruisci la pipeline come se il modello fosse curioso e incurante

Il modello mentale più pulito è questo: trattare il modello come curioso, capace, veloce e non del tutto affidabile ai limiti. Ciò non significa che il modello sia dannoso. Ciò significa che non ci si dovrebbe fidare del modello con un ampio giudizio implicito su ciò che è sicuro rivelare.

Da questo punto di vista, una pipeline di intelligenza artificiale più sicura inizia con la classificazione dei dati. Non tutti i documenti dovrebbero essere ugualmente recuperabili. Non tutti gli utenti dovrebbero essere in grado di interrogare la stessa fonte. Non tutte le classi di dati dovrebbero essere disponibili nella stessa modalità assistente. Se il tuo livello di intelligenza artificiale si trova sopra una palude di dati in cui le classificazioni sono vaghe e le autorizzazioni vengono ereditate in modo approssimativo, non hai ancora un problema di intelligenza artificiale. Hai un problema di archiviazione e identità mentre indossi il trucco AI.

Dopo la classificazione arriva la politica di recupero. I sistemi RAG non dovrebbero semplicemente recuperare i “pezzi rilevanti K principali”. Dovrebbero recuperare i principali blocchi K pertinenti, corretti per il tenant, corretti per l'autorizzazione, corretti per l'aggiornamento e sicuri per l'attività corrente. Sembra un lavoro extra perché è un lavoro extra. Ma è più economico che spiegare a un cliente perché la convenzione di denominazione interna di un cliente è apparsa nella risposta apparentemente privata di un altro cliente.

Poi arriva l'autorizzazione dello strumento. Un modello non dovrebbe ricevere un'ampia cintura magica per gli attrezzi. Dovrebbe ricevere un insieme ristretto di strumenti le cui autorizzazioni siano limitate all'attività, all'utente, al tenant e allo stato corrente del flusso di lavoro. Anche le chiamate degli strumenti dovrebbero essere osservabili. Se un modello può cercare record, generare esportazioni, scrivere su sistemi o attivare flussi di lavoro, il percorso delle azioni deve essere ispezionabile da persone che non hanno scritto la demo originale.

La memoria ha bisogno della stessa disciplina. Mantieni il contesto a breve termine breve. Mantieni esplicita la memoria a lungo termine. Assegna etichette, durate e percorsi di eliminazione ai ricordi archiviati. Decidere quali categorie di informazioni non verranno mai archiviate. Se non ti fa piacere vedere una porzione di testo in un'esportazione di supporto, non lasciare che diventi una memoria duratura solo perché qualcuno ha detto "migliora la personalizzazione".

Infine, metti i controlli in uscita. Il rilevamento sensibile dei modelli, i controlli delle policy, le liste consentite strutturate per le classi di output ad alto rischio e l’approvazione umana selettiva non sono segni di sfiducia nel modello. Sono segni di età adulta nel sistema.

Confini RAG che contano davvero

RAG è spesso il luogo in cui i prodotti di intelligenza artificiale passano da giocattolo a sistema aziendale, ed è esattamente il motivo per cui merita più sospetti di quanto normalmente riceva.

Il primo limite è l’isolamento degli inquilini. I negozi di recupero che mescolano gli inquilini e si affidano successivamente al filtraggio morbido sono incidenti pronti a verificarsi. Se i dati hanno un valore davvero elevato, la risposta più chiara è spesso la separazione fisica o logica prima ancora che inizi il recupero. La risposta meno elegante ma comunque rispettabile è il filtraggio aggressivo dei metadati che viene applicato prima che i risultati della classifica vengano consegnati al modello. La risposta peggiore è recuperare in modo ampio, fidarsi del modello per dedurne la rilevanza e sperare che non ricuci i frammenti sbagliati.

Il secondo limite è la fiducia dei documenti. Non tutti i documenti indicizzati meritano la stessa autorità. Alcuni sono stati scritti da team interni fidati. Alcuni sono stati esportati da altri sistemi. Alcuni potrebbero essere forniti dall'utente. Alcuni potrebbero essere obsoleti. Alcuni potrebbero essere avvelenati. La ricerca sugli attacchi di estrazione dei dati nei sistemi di recupero è importante in questo caso perché ci ricorda che il recupero non si limita a recuperare i fatti. Può importare istruzioni dannose e trigger nascosti. Un livello di recupero che non ha il concetto di livello di fiducia chiede a un motore di completamento automatico molto costoso di fungere da revisore della sicurezza.

Il terzo limite è l’igiene dei pezzi. Ai team piace parlare di dimensioni dei blocchi, sovrapposizione e incorporamento di modelli. Parlano meno spesso se il pezzo debba esistere o meno. Contiene segreti che avrebbero dovuto essere oscurati prima dell'indicizzazione? Include commenti interni, credenziali o residui di debug? Conserva gli identificatori non necessari quando andrebbero bene i riepiloghi astratti? Se la pipeline RAG inserisce prima tutto e successivamente pone domande di sicurezza, non è realmente una pipeline RAG sicura. È una speranza.

Il quarto confine è la disciplina delle citazioni. Un modello dovrebbe idealmente sapere quali blocchi hanno contribuito alla risposta e quali politiche hanno consentito a tali blocchi di essere inseriti nel contesto. Non perché le citazioni siano belle, ma perché la spiegabilità aiuta la risposta agli incidenti. Quando succede qualcosa di brutto, “la modella deve averlo visto da qualche parte” non è una frase soddisfacente.

Gli agenti moltiplicano il raggio dell'esplosione

I semplici sistemi di chat possono presentare perdite. Gli agenti possono trapelare e agire.

La differenza conta. Una volta che un modello può decidere quale strumento chiamare, in quale ordine, con quali parametri, su quale contesto recuperato, la superficie di attacco si allarga e con essa la superficie di incidente. Il problema non è più solo “L’assistente dirà qualcosa che non dovrebbe?” Il problema diventa: “L’assistente deciderà di interrogare qualcosa che non dovrebbe, combinarlo con la memoria che non avrebbe dovuto conservare e consegnare il risultato a un flusso di lavoro che non avrebbe mai dovuto essere eseguito su quella base?”

Questo è il motivo per cui la sicurezza degli agenti non può essere ridotta alla tempestiva ingegneria. L’attuale interesse del NIST per l’identità e l’autorizzazione degli agenti non è una decorazione burocratica. Si tratta di un riconoscimento del fatto che i sistemi di intelligenza artificiale che utilizzano strumenti necessitano di identità, ambito di privilegi e logica di approvazione leggibile al di fuori del modello stesso.

In pratica, ciò significa che alcune abitudini rigorose e fuori moda aiutano molto. Separare gli strumenti di lettura da quelli di scrittura. Separare il recupero a basso rischio dalle azioni ad alto rischio. Utilizzare credenziali di breve durata. Fare in modo che le azioni pericolose richiedano un percorso di approvazione esplicito. Registrare il motivo per cui l'agente riteneva necessaria una chiamata allo strumento. E non consentire che lo stesso ampio token di accesso fluttui in ogni fase del flusso di lavoro come un passaporto reale.

Un piccolo controesempio chiarisce il punto. Supponiamo che un assistente AI interno possa eseguire ricerche nella knowledge base, leggere i ticket di problema, redigere una risposta al cliente e infine inviare tale risposta. Una progettazione debole consente allo stesso agente di eseguire ogni passaggio dall'inizio alla fine. Una progettazione più efficace consente all'assistente di recuperare e creare bozze, ma richiede una fase di approvazione separata e controllata prima dell'invio di qualsiasi messaggio in uscita. Entrambi i sistemi possono apparire ugualmente raffinati in una demo. Solo uno si comporta come se si aspettasse che il mondo reale esistesse.

Un'implementazione di riferimento che puoi effettivamente eseguire

La policy migliore è quella che sopravvive al contatto con il codice. Costruiamo quindi un piccolo gateway Python che dimostri le idee fondamentali: oscurare i segreti evidenti dal testo in arrivo, filtrare i blocchi recuperati per tenant e classificazione, limitare le chiamate allo strumento a una lista consentita per richiesta ed eseguire la scansione della risposta in uscita prima che se ne vada.

Questo non è un prodotto di sicurezza aziendale completo e non pretende di esserlo. È uno scheletro compatto che impone le giuste abitudini architettoniche.

__CODICE_0__

from __future__ import annotations

from dataclasses import dataclass
import fnmatch
import json
import re
from typing import Iterable


SECRET_PATTERNS = {
    "aws_access_key": re.compile(r"\bAKIA[0-9A-Z]{16}\b"),
    "jwt": re.compile(r"\beyJ[A-Za-z0-9_-]+\.[A-Za-z0-9._-]+\.[A-Za-z0-9._-]+\b"),
    "private_key": re.compile(r"-----BEGIN (RSA|EC|OPENSSH|DSA)? ?PRIVATE KEY-----"),
    "email": re.compile(r"\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b", re.I),
}


@dataclass(frozen=True)
class UserContext:
    user_id: str
    tenant_id: str
    role: str
    allowed_labels: tuple[str, ...]
    allowed_tools: tuple[str, ...]


@dataclass(frozen=True)
class Chunk:
    chunk_id: str
    tenant_id: str
    label: str
    text: str


def redact_text(text: str) -> str:
    result = text
    for label, pattern in SECRET_PATTERNS.items():
        result = pattern.sub(f"[REDACTED:{label.upper()}]", result)
    return result


def outgoing_text_is_safe(text: str) -> tuple[bool, str]:
    for label, pattern in SECRET_PATTERNS.items():
        if pattern.search(text):
            return False, f"blocked by {label}"
    return True, "ok"


def filter_chunks(user: UserContext, chunks: Iterable[Chunk]) -> list[Chunk]:
    allowed = []
    for chunk in chunks:
        if chunk.tenant_id != user.tenant_id:
            continue
        if chunk.label not in user.allowed_labels:
            continue
        allowed.append(chunk)
    return allowed


def tool_call_allowed(user: UserContext, tool_name: str) -> bool:
    return any(fnmatch.fnmatch(tool_name, rule) for rule in user.allowed_tools)


def build_prompt(user: UserContext, user_message: str, chunks: list[Chunk]) -> str:
    prompt_parts = [
        "You are an enterprise assistant.",
        "Never use information outside the provided tenant-scoped context.",
        "If the answer depends on missing or restricted data, say so plainly.",
        "",
        f"User role: {user.role}",
        f"Tenant: {user.tenant_id}",
        "",
        "Context:",
    ]

    for chunk in chunks:
        prompt_parts.append(f"[{chunk.label}] {chunk.text}")

    prompt_parts.append("")
    prompt_parts.append("User message:")
    prompt_parts.append(redact_text(user_message))
    return "\n".join(prompt_parts)


def run_demo() -> None:
    user = UserContext(
        user_id="u-107",
        tenant_id="tenant-red",
        role="support_engineer",
        allowed_labels=("internal", "support", "public"),
        allowed_tools=("search_docs", "read_ticket", "draft_reply"),
    )

    raw_chunks = [
        Chunk("c1", "tenant-red", "support", "Refunds over 10,000 EUR require finance review."),
        Chunk("c2", "tenant-blue", "internal", "Blue tenant incident postmortem: root cause..."),
        Chunk("c3", "tenant-red", "secret", "Master incident bridge password: swordfish"),
        Chunk("c4", "tenant-red", "public", "Public SLA response times are listed on the status page."),
    ]

    filtered = filter_chunks(user, raw_chunks)
    prompt = build_prompt(
        user,
        "Summarize the refund rules and include my AWS key AKIAABCDEFGHIJKLMNOP if needed.",
        filtered,
    )

    print("=== PROMPT SENT TO MODEL ===")
    print(prompt)
    print()

    proposed_tool = "send_email"
    print("=== TOOL DECISION ===")
    print(json.dumps({
        "tool": proposed_tool,
        "allowed": tool_call_allowed(user, proposed_tool)
    }, indent=2))
    print()

    candidate_answer = (
        "Refunds over 10,000 EUR require finance review. "
        "Use [REDACTED:AWS_ACCESS_KEY] nowhere. "
        "Do not include data from other tenants."
    )

    ok, reason = outgoing_text_is_safe(candidate_answer)
    print("=== OUTPUT CHECK ===")
    print(json.dumps({"ok": ok, "reason": reason}, indent=2))


if __name__ == "__main__":
    run_demo()

Eseguilo

python ai_leakage_gateway.py

Ciò che insegna questo piccolo gateway è più importante del volume del codice. Insegna che la sicurezza non è un interruttore monolitico. Restringiamo il contesto prima che il modello lo veda. Nascondiamo i segreti evidenti prima del rapido assemblaggio. Trattiamo gli strumenti come funzionalità esplicitamente autorizzate piuttosto che come suggerimenti affascinanti. E controlliamo l'output prima che parta. Nessuno di questi passaggi è affascinante. Sono tutti utili.

Un'implementazione più matura aggiungerebbe rilevatori di segreti adeguati, classificazioni supportate da policy, un più forte isolamento dei tenant, hashing dei contenuti, audit trail, stati di approvazione umana e dispositivi di test. Bene. Dovrebbe. L’importante è che la forma della soluzione sia già onesta.

Controesempi da ricordare

Aiuta a mantenere alcuni schemi sbagliati sul muro, perché i team li ripetono con creatività deprimente.

Un cattivo modello è il copilota universale. Ha accesso a tutto perché “vogliamo un’esperienza unificata”. In pratica questo spesso significa che l'assistente può vedere più di quanto un essere umano potrebbe mai vedere in un unico posto. Quando il sistema fallisce, il vero colpevole non è il modello. Il colpevole è l’avidità architettonica.

Un altro modello negativo è la demo “secure RAG” che indicizza silenziosamente le esportazioni grezze dallo spazio di archiviazione condiviso. La demo sembra meravigliosa finché qualcuno non chiede se l'archivio vettoriale applica i limiti del tenant al momento del recupero o solo dopo la stesura della risposta. Se la risposta è vaga, il rischio non è affatto vago.

Un'altra è la caratteristica della memoria che nessuno possiede. Il prodotto ritiene che migliori la continuità. La sicurezza presuppone che sia di breve durata. Il punto legale presuppone che la conservazione sia definita altrove. Il supporto scopre sei mesi dopo che i vecchi snippet possono ancora riemergere. È così che caratteristiche innocenti diventano fallimenti di governance.

Poi c’è la trappola del disboscamento. Gli ingegneri spesso aggiungono ricche tracce durante lo sviluppo, promettono di pulirle in seguito e non lo fanno mai. Il risultato è che l’interfaccia utente del prodotto può essere rispettabile mentre lo stack di osservabilità diventa un museo di materiale sensibile. Questo è uno dei percorsi di perdita più noiosi e uno dei più comuni.

Una buona ingegneria spesso sembra l’opposto di questi errori. Sembra più stretto. Più esplicito. Leggermente meno magico. Questo non è un difetto. È un segno di sistemi che pretendono di sopravvivere al contatto con la realtà.

I controlli organizzativi contano più di quanto le persone vogliano ammettere

C'è una storia d'amore nel risolvere tutto tramite codice, e non è del tutto immeritata. Ma la prevenzione delle fughe di intelligenza artificiale è anche un problema disciplinare.

I team hanno bisogno di una policy basata su strumenti approvati, non perché i documenti politici siano entusiasmanti, ma perché l’intelligenza artificiale ombra è reale. Hanno bisogno di regole di base per la gestione dei dati per richieste e caricamenti. Hanno bisogno di un modo per decidere quali sistemi interni possono alimentare le funzionalità dell’intelligenza artificiale e quali no. Hanno bisogno di percorsi di revisione per i casi d'uso ad alto rischio. Hanno bisogno di qualcuno che possieda la fidelizzazione. Hanno bisogno di qualcuno che possieda l'inventario di modelli e strumenti. E hanno bisogno dell’umiltà di dire: “Questo carico di lavoro non è ancora pronto per un ampio accesso all’intelligenza artificiale”.

I migliori controlli tecnici al mondo continueranno a faticare se l’organizzazione considererà ogni funzionalità dell’intelligenza artificiale come una scorciatoia di emergenza per la produttività. La sicurezza è più semplice quando l’azienda fornisce alternative sicure anziché limitarsi a gridare “non utilizzare strumenti non approvati”. La guida di Microsoft ha ragione. Le persone aggirano l'attrito. Se il percorso sicuro è infelice e il percorso non sicuro è veloce, il percorso non sicuro svilupperà un seguito fedele.

Quindi sì, costruisci i guardrail. Ma rendiamo anche il flusso di lavoro sicuro abbastanza utilizzabile da far sì che ingegneri e lavoratori della conoscenza non si sentano puniti per la cooperazione.

Laboratorio pratico: trasforma la demo in un vero e proprio gateway di policy

Se vuoi passare dalla teoria a qualcosa che il tuo team possa toccare, questo è un buon esercizio per un fine settimana.

Inizia con il gateway Python sopra e forniscigli un vero file di policy.

__CODICE_0__

{
  "tenant_red": {
    "support_engineer": {
      "allowed_labels": ["public", "support", "internal"],
      "allowed_tools": ["search_docs", "read_ticket", "draft_reply"]
    },
    "finance_admin": {
      "allowed_labels": ["public", "support", "internal", "finance"],
      "allowed_tools": ["search_docs", "read_ticket", "draft_reply", "read_finance_record"]
    }
  }
}

Quindi estendere il gateway in modo che:

1. gli utenti e i ruoli vengono caricati dalla policy anziché essere codificati;
2. i blocchi di recupero vengono rifiutati a meno che sia il tenant che l'etichetta non corrispondano;
3. ogni chiamata allo strumento bloccato viene registrata con una motivazione;
4. le risposte in uscita che contengono stringhe a forma di segreto vengono messe in quarantena anziché restituite;
5. la memoria viene scritta solo per i tipi di conversazione consentiti.

Se lo fai onestamente, noterai qualcosa di utile. Il problema smette rapidamente di sembrare una “ingegneria tempestiva” e inizia a sembrare quello che è realmente: un lavoro di sicurezza e integrazione di sistemi con un modello nel mezzo.

Attività di prova per appassionati

Se vuoi approfondire l'articolo e imparare qualcosa di reale invece di limitarti ad annuire, prova questi:

1. Aggiungi un test di mancata corrispondenza tenant_id e dimostra che il pezzo sbagliato non raggiunge mai il prompt.
2. Estendi il filtro di output per contrassegnare ID cliente, riferimenti interni ai ticket e artefatti di pagamento.
3. Aggiungi una seconda fase che richiede l'approvazione umana prima che qualsiasi strumento con funzionalità di scrittura possa essere eseguito.
4. Conserva la memoria a breve termine solo per quindici minuti, quindi aggiungi i registri automatici di scadenza ed eliminazione.
5. Crea due prompt per il team rosso: uno diretto, uno nascosto all'interno del testo recuperato e osserva quale controllo rileva quale errore.

Conclusione

La prevenzione della fuga di dati tramite intelligenza artificiale non è questione di trovare la frase perfetta da inserire in un prompt del sistema. Si tratta di costruire un sistema in cui i dati sensibili siano classificati in anticipo, il recupero abbia un ambito adeguato, la memoria sia limitata, gli strumenti siano autorizzati in modo limitato e gli output vengano controllati prima che lascino l'edificio.

Potrebbe sembrare meno affascinante della versione marketing dell’intelligenza artificiale. Bene. Il glamour è sopravvalutato in termini di sicurezza. I team che hanno successo qui sono solitamente quelli disposti a essere precisi fuori moda. Decidono cosa può vedere il modello, cosa può fare, cosa può ricordare e cosa deve essere rivisto da un essere umano. Non chiedono al modello di sviluppare l’etica attraverso la punteggiatura.

E questo è, in un certo senso, incoraggiante. Perché significa che la soluzione non è mistica. È ingegneria. A volte l'ingegneria è dura, sì. Ingegneria un po' fastidiosa, certamente. Ma pur sempre ingegneria. Ciò significa che può essere ragionato, testato, migliorato e spedito.

Se il tuo sistema di intelligenza artificiale sta già toccando informazioni sensibili, ora è un ottimo momento per smettere di ammirare l’assistente e iniziare a ispezionare i confini attorno ad esso. È lì che è sempre stata la vera storia.

Riferimenti

• NIST, Quadro per la gestione dei rischi dell'intelligenza artificiale: profilo dell'intelligenza artificiale generativa: https://doi.org/10.6028/NIST.AI.600-1
• NIST, Iniziativa sugli standard degli agenti AI: https://www.nist.gov/caisi/ai-agent-standards-initiative
• NIST NCCoE, Identità e autorizzazione dell'agente software e AI: https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
• OWASP, Top 10 per applicazioni LLM: https://owasp.org/www-project-top-10-for-large-lingual-model-applications/
• AWS, GENSEC04-BP02: implementare controlli per proteggersi da iniezioni tempestive e tentativi di jailbreak: https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/gensec04-bp02.html
• AWS, Navigazione nel panorama della sicurezza dell'intelligenza artificiale generativa: https://docs.aws.amazon.com/pdfs/whitepapers/latest/navigating-security-landscape-genai/navigating-security-landscape-genai.pdf
• Microsoft, Guida per la protezione dell'azienda basata sull'intelligenza artificiale: Introduzione alle applicazioni AI: https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/Securing-the-AI-Powered-Enterprise-Getting-Started-with-AI-Applications.pdf
• Yupei Lv et al., PLeak: attacchi tempestivi di perdite contro applicazioni di modelli linguistici di grandi dimensioni: https://arxiv.org/abs/2405.06823
• Yuxin Wen et al., Attacchi di estrazione dati nella generazione aumentata di recupero tramite backdoor: https://arxiv.org/abs/2411.01705