Non puoi debuggare un'applicazione LLM senza loggare i prompt, e non puoi tenere quei prompt se sono pieni di nomi, email e numeri di conto. Gli utenti digitano informazioni personali identificabili direttamente nel campo, quindi il log che ti aiuta a capire una risposta sbagliata è anche un archivio crescente di dati regolamentati seduto in CloudWatch o S3 con la retention sbagliata e i controlli di accesso sbagliati. La soluzione non è smettere di loggare. È redigere prima dello storage e mettere una politica di retention su ciò che resta, così il valore di debug sopravvive e la responsabilità legale no.

Il modo utile di vederla: un log di prompt è una superficie di raccolta dati, non una comodità di debug. Nel momento in cui scrivi un prompt grezzo su disco hai raccolto qualunque cosa l'utente ci abbia messo dentro, sotto qualunque regolamento copra quel dato. Tratta la pipeline di log come un posto dove le PII vengono rimosse in ingresso, non un posto che ripulisci dopo che un audit lo chiede.

Redigi in ingresso, non in uscita

L'unico posto affidabile per rimuovere le PII è prima che vengano scritte. Redigere dopo lo storage significa che il dato grezzo è già esistito a riposo, già replicato, già nei backup, e "lo cancelliamo dopo" non è un controllo che un auditor accetta. Metti il passo di redazione tra la richiesta e il sink di log, così il valore che finisce nello storage non è mai stato sensibile in primo luogo.

Amazon Comprehend ti dà la primitiva di rilevamento. DetectPiiEntities ispeziona il testo in tempo reale e restituisce ogni entità PII che trova, il suo tipo, i suoi offset di carattere, e un punteggio di confidenza. Usi quegli offset per sostituire gli span prima di loggare. Comprehend supporta due modalità di mascheramento: sostituire ogni entità con il suo tipo, così "Jane Doe" diventa [NAME], che mantiene il log leggibile, oppure mascherare i caratteri con un simbolo fisso. Sostituire con il tipo è di solito la scelta giusta, perché preserva la forma del prompt per il debug rimuovendo l'identità.

entities = comprehend.detect_pii_entities(Text=prompt, LanguageCode="en")
redacted = prompt
for e in sorted(entities["Entities"], key=lambda x: x["BeginOffset"], reverse=True):
    redacted = redacted[:e["BeginOffset"]] + f"[{e['Type']}]" + redacted[e["EndOffset"]:]
log.write(redacted)   # only the redacted form is ever persisted

Fai lo splice dalla fine verso l'inizio, così gli offset precedenti restano validi mentre riscrivi la stringa. Il rilevamento è una chiamata in tempo reale, per grandi batch storici Comprehend offre anche job di redazione asincroni, ma il percorso live è quello che protegge le nuove scritture.

Il rilevamento è probabilistico, quindi progetta per le mancate rilevazioni

Comprehend è un rilevatore di machine learning, il che significa che ha un recall sotto il 100 percento e un punteggio di confidenza su cui devi impostare una soglia minima. Una soglia bassa redige in modo aggressivo e può rovinare testo legittimo, una alta lascia passare PII in casi limite. Due abitudini rendono questo sicuro:

  • Sovrapponi un passaggio deterministico. Per identificatori strutturati con formati fissi, numeri di carte di credito, ID nazionali, alcuni formati di conto, una regex cattura ciò che un modello probabilistico può perdere, e lo cattura allo stesso modo ogni volta. Esegui entrambi.
  • Rediggi verso i falsi positivi. In un log di debug, redigere troppo ti costa un po' di leggibilità. Redigere troppo poco ti costa un incidente sulla protezione dei dati. Sbilancia la soglia verso il rimuovere troppo.

Amazon Bedrock Guardrails può anche filtrare informazioni sensibili al confine del modello, il che è complementare: Guardrails protegge il percorso di richiesta e risposta, Comprehend protegge ciò che scrivi nei tuoi log. Usa quello che sta dove si trova il tuo rischio.

La retention è l'altra metà del controllo

La redazione riduce cosa contiene un log, la retention limita per quanto tempo vive anche la forma redatta. Un prompt redatto è a rischio più basso, non a rischio zero, e un log di debug ha una vita utile naturale misurata in settimane, non anni. Imposta la retention esplicitamente al sink:

  • Scadi su un programma. Un'impostazione di retention di un gruppo di log CloudWatch o una regola di lifecycle S3 che elimina dopo una finestra definita fa sì che i vecchi log scadano da soli senza che nessuno debba ricordarsi di ripulirli.
  • Fai combaciare la retention con lo scopo. Il debug operativo raramente ha bisogno di più di 30-90 giorni. Se serve una finestra più lunga per una ragione specifica, nomina la ragione e limita quella retention ai log che ne hanno bisogno.
  • Blocca l'accesso. Anche i log redatti meritano IAM con ambito ristretto. L'insieme di persone che possono leggere i log dei prompt grezzi dovrebbe essere piccolo e nominato.

Il punto chiave

Il logging dei prompt e la protezione delle PII non sono in conflitto, sono due passi della stessa pipeline. Rediggi prima della scrittura con Comprehend, sovrapponendo un passaggio deterministico per gli identificatori a formato fisso e sbilanciando la soglia verso la redazione eccessiva. Poi metti una politica di retention su ciò che resta così i log redatti scadono secondo un programma invece di accumularsi per sempre dietro un accesso troppo largo. Fai entrambe le cose e mantieni il segnale di debug di cui hai bisogno mentre il dato regolamentato non atterra mai a riposo. Il log che ti aiuta a sistemare l'app non dovrebbe essere quello che finisce in un report di data breach.

Leggi questo dopo

Per il lato platform delle pipeline di log, della retention e del controllo accessi, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.