Prompt injection: diretta, indiretta e come contenerle entrambe
Perché il modello non può risolverla da solo, che aspetto ha un attacco nascosto in un documento e come contenerlo.
Approfondisci la prompt injectionServizi finanziari · 4 min di lettura
Un registro di audit dell'AI per i servizi finanziari
La domanda che blocca i progetti non è cosa ha fatto il sistema, ma come era configurato quel giorno. Quattro proprietà permettono di rispondere.
La domanda di audit a cui ci si prepara è “cosa ha fatto il sistema”. Quella che blocca davvero i progetti è “come era configurato il sistema nel giorno in questione, e cosa è cambiato da allora”. Senza uno storico della configurazione questa domanda non ha risposta, e un controllo che non puoi ricostruire è un controllo che non puoi garantire. Questa guida passa in rassegna le quattro proprietà che rendono verificabile un sistema di AI, ed è scritta per il tecnico che deve realizzarle, non per il revisore che le chiederà.
Nota sull'ambito: questa è una guida tecnica sui controlli, non una consulenza legale né una descrizione di ciò che una norma richiede. NeuralSeek dispone dei report SOC 1 e SOC 2 Type II ed è conforme a HIPAA. Sono i tuoi consulenti legali, le autorità di vigilanza e il tuo audit interno a decidere cosa si applica alla tua organizzazione.
Perché tutta la conversazione è qui
In un'istituzione regolamentata, un sistema di AI che tocca libri contabili, registri o interazioni con i clienti non viene valutato prima di tutto sulle sue capacità. Viene valutato sulla sua capacità di produrre un resoconto completo e affidabile di ciò che è successo: chi ha fatto cosa, quando, con quale configurazione, e se quel resoconto può essere consegnato in tempi brevi e reggere davanti a qualcuno che non dà nulla per scontato.
È un problema tecnico risolvibile, e si scompone in quattro proprietà. Nessuna è esotica. Ciò che le rende difficili è che devono esserci fin dall'inizio. Un registro di audit non si può aggiungere al passato.
Uno: un registro duraturo di ogni interazione
Due log complementari, più il controllo su dove vengono conservati. Un registro di ogni interazione, a livello di tutta l'organizzazione e a prova di manomissione, ti dà il resoconto. Un registro dei prompt stessi ti dà la ricostruzione: quando una risposta precisa viene messa in discussione più avanti, puoi mostrare esattamente cosa è stato chiesto e su quale materiale stava lavorando il sistema.
La parte che i team pianificano meno è l'archiviazione. Gli obblighi di conservazione per i registri regolamentati sono di solito più lunghi della conservazione predefinita dei log, e spesso richiedono un tipo specifico di durabilità. Poter inviare questi registri al backend che la tua istituzione usa già per i registri regolamentati, invece che a quello predefinito dell'applicazione, è ciò che rende il controllo reale e non solo nominale.
Due: uno storico di ogni modifica alle impostazioni
È la proprietà che manca alla maggior parte dei sistemi di AI, e quella che più spesso trasforma una verifica in un progetto. Se a un certo punto sono cambiate le soglie di recupero, la policy dei guardrail o l'assegnazione dei modelli, e nessuno sa dire quando né in cosa, allora ogni risposta prodotta prima di quella modifica è inspiegabile.
Serve un log con data e ora di ogni modifica alle impostazioni, per vedere cosa è cambiato e quando, e per annullarlo. Così una modifica a un controllo smette di essere un intervento non tracciato e diventa un evento verificabile, che è ciò che chiede un framework di controllo.
Tre: attribuzione, senza rivelare credenziali
Un registro che non si può collegare a un'identità fallisce l'audit da un lato; un registro che contiene segreti lo fallisce dall'altro, e con costi maggiori. Ogni interazione registrata dovrebbe essere legata a un percorso di accesso e a un'identità noti, non a una chiamata anonima: è una scelta di progetto su come si accede al sistema, non qualcosa che si aggiunge dopo.
Allo stesso tempo, chiavi e segreti di connessione vanno tenuti fuori dai prompt, dalle risposte e dai log stessi. Il registro che produci come prova è un documento che verrà copiato, inviato via email e conservato da persone esterne al tuo team. Non deve essere un posto in cui si trovano credenziali.
Quattro: prove che si esportano, non che si ricostruiscono
L'ultima proprietà è se il registro può diventare qualcosa che un revisore accetta senza bisogno di traduzioni. In pratica significa collegare ogni controllo al requisito che soddisfa, nel formato che i tuoi revisori usano già, così la risposta a una richiesta di verifica è un documento e non un'indagine.
Il test è semplice e vale la pena applicarlo a qualsiasi soluzione tu stia valutando: quando arriva la richiesta, produrre le prove è un'esportazione o un'emergenza?
Configuralo una volta, o ricostruiscilo per sempre
La differenza tra un progetto di AI che arriva in produzione in un'istituzione regolamentata e uno che si blocca raramente è il modello. È se il registro di audit nasce dalla configurazione o viene ricostruito sotto pressione ogni volta che qualcuno lo chiede.
Tutte e quattro le proprietà descritte sopra sono impostazioni di NeuralSeek, non componenti da integrare, e valgono per ogni workflow creato sull'istanza, non solo per quelli i cui autori se ne sono ricordati. Le hai per impostazione predefinita invece di ricostruirle per ogni workflow.
Continua a leggere
Altre guide sull'AI con governance
Letture pratiche per creare, governare ed eseguire agenti AI.
Per impostazioni e parametri, consulta la documentazione del prodotto (in inglese).
Trovare i dati personali che il pattern matching non vede
Le espressioni regolari trovano i dati personali che sembrano dati personali. “Maria nella stanza 4B” identifica una paziente e non corrisponde a nessun pattern. Ecco come la trova un secondo passaggio, basato sul contesto.
Approfondisci i dati personali
Inizia oggi a creare con NeuralSeek.
Registrati online e inizia con una prova di due settimane, oppure parla con un nostro esperto per usare NeuralSeek nel tuo cloud.