Vous ne pouvez pas déboguer une application LLM sans journaliser les prompts, et vous ne pouvez pas garder ces prompts s'ils sont pleins de noms, d'emails et de numéros de compte. Les utilisateurs tapent des informations personnelles identifiables directement dans la boîte de saisie, donc le log qui vous aide à comprendre une mauvaise réponse est aussi un stock grandissant de données réglementées assis dans CloudWatch ou S3 avec la mauvaise rétention et les mauvais contrôles d'accès. La solution n'est pas d'arrêter de journaliser. C'est de rédiger avant le stockage et de poser une politique de rétention sur ce qui reste, pour que la valeur de débogage survive et que la responsabilité juridique ne suive pas.

Le recadrage : un log de prompts est une surface de collecte de données, pas une commodité de débogage. Au moment où vous écrivez un prompt brut sur disque, vous avez collecté tout ce que l'utilisateur y a mis, sous quelque réglementation qui couvre cette donnée. Traitez le pipeline de logs comme un endroit où les PII sont retirées à l'entrée, pas un endroit que vous nettoyez plus tard après qu'un audit le demande.

Rédiger à l'entrée, pas à la sortie

Le seul endroit fiable pour retirer les PII, c'est avant qu'elles soient écrites. Rédiger après le stockage signifie que la donnée brute a déjà existé au repos, déjà été répliquée, déjà été dans des sauvegardes, et « on la supprimera plus tard » n'est pas un contrôle qu'un auditeur accepte. Placez l'étape de rédaction entre la requête et le puits de logs, pour que la valeur qui atterrit dans le stockage n'ait jamais été sensible au départ.

Amazon Comprehend vous donne la primitive de détection. DetectPiiEntities inspecte le texte en temps réel et renvoie chaque entité PII trouvée, son type, ses décalages de caractères et un score de confiance. Vous utilisez ces décalages pour remplacer les portions avant de journaliser. Comprehend supporte deux modes de masquage : remplacer chaque entité par son type, si bien que « Jane Doe » devient [NAME], ce qui garde le log lisible, ou masquer les caractères avec un symbole fixe. Remplacer par le type est généralement le bon choix, parce que ça préserve la forme du prompt pour le débogage tout en retirant 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

Découpez de la fin vers le début pour que les décalages antérieurs restent valides pendant que vous réécrivez la chaîne. La détection est un appel en temps réel ; pour les grands lots historiques, Comprehend propose aussi des jobs de rédaction asynchrones, mais c'est le chemin en direct qui protège les nouvelles écritures.

La détection est probabiliste, donc concevez pour les ratés

Comprehend est un détecteur d'apprentissage automatique, ce qui veut dire qu'il a un rappel inférieur à 100 pour cent et un score de confiance sur lequel vous devez fixer un plancher. Un seuil bas rédige agressivement et peut abîmer du texte légitime ; un seuil haut laisse passer des PII en cas limite. Deux habitudes rendent ça sûr :

  • Superposez une passe déterministe. Pour les identifiants structurés à format fixe, numéros de carte bancaire, identifiants nationaux, certains formats de compte, une regex attrape ce qu'un modèle probabiliste peut manquer, et l'attrape de la même façon à chaque fois. Faites tourner les deux.
  • Rédigez vers les faux positifs. Dans un log de débogage, trop rédiger vous coûte un peu de lisibilité. Pas assez rédiger vous coûte un incident de protection des données. Biaisez le seuil vers le retrait excessif.

Amazon Bedrock Guardrails peut aussi filtrer les informations sensibles à la frontière du modèle, ce qui est complémentaire : Guardrails protège le chemin requête-réponse, Comprehend protège ce que vous écrivez dans vos propres logs. Utilisez celui qui se trouve là où se trouve votre risque.

La rétention est l'autre moitié du contrôle

La rédaction réduit ce qu'un log contient ; la rétention limite combien de temps même la forme rédigée vit. Un prompt rédigé est à risque plus faible, pas à risque nul, et un log de débogage a une durée de vie utile naturelle mesurée en semaines, pas en années. Fixez la rétention explicitement au niveau du puits :

  • Expirez sur un calendrier. Un paramètre de rétention de groupe de logs CloudWatch ou une règle de cycle de vie S3 qui supprime après une fenêtre définie permet aux vieux logs de s'éteindre tout seuls sans que personne ait à s'en souvenir.
  • Faites correspondre la rétention à l'usage. Le débogage opérationnel a rarement besoin de plus de 30 à 90 jours. Si une fenêtre plus longue est nécessaire pour une raison précise, nommez la raison et cantonnez cette rétention aux logs qui en ont besoin.
  • Verrouillez l'accès. Même les logs rédigés méritent un IAM restreint. L'ensemble des personnes pouvant lire les logs de prompts bruts devrait être petit et nommé.

À retenir

La journalisation des prompts et la protection des PII ne sont pas en conflit, ce sont deux étapes du même pipeline. Rédigez avant l'écriture avec Comprehend, en superposant une passe déterministe pour les identifiants à format fixe et en biaisant le seuil vers la rédaction excessive. Puis posez une politique de rétention sur ce qui reste pour que les logs rédigés expirent sur un calendrier au lieu de s'accumuler derrière un accès trop lâche. Faites les deux et vous gardez le signal de débogage dont vous avez besoin pendant que les données réglementées n'atterrissent jamais au repos. Le log qui vous aide à réparer l'application ne devrait pas être celui qui apparaît dans un rapport de fuite.

À lire ensuite

Pour le côté plateforme des pipelines de logs, de la rétention et du contrôle d'accès, les notes de terrain cloud vivent sur ercan.cloud, et le hub est sur ercanermis.com.