Você não consegue debugar uma aplicação de LLM sem fazer log dos prompts, e você não pode manter esses prompts se estiverem cheios de nomes, emails e números de conta. Usuários digitam informações pessoalmente identificáveis direto na caixa, então o log que te ajuda a entender uma resposta ruim também é um repositório crescente de dados regulados sentado no CloudWatch ou no S3 com a retenção errada e os controles de acesso errados. A solução não é parar de fazer log. É redigir antes do armazenamento e colocar uma política de retenção no que sobra, para que o valor de debugging sobreviva e a responsabilidade não.

O reenquadramento: um log de prompt é uma superfície de coleta de dados, não uma conveniência de debug. No momento em que você escreve um prompt cru em disco, você coletou o que quer que o usuário tenha colocado nele, sob qualquer regulação que cubra esse dado. Trate o pipeline de log como um lugar onde PII é removido na entrada, não um lugar que você limpa depois que uma auditoria pergunta.

Redija na entrada, não na saída

O único lugar confiável para remover PII é antes de ele ser escrito. Redigir depois do armazenamento significa que o dado cru já existiu em repouso, já foi replicado, já está em backups, e "a gente deleta depois" não é um controle que um auditor aceita. Coloque o passo de redação entre a requisição e o destino do log, para que o valor que chega ao armazenamento nunca tenha sido sensível em primeiro lugar.

O Amazon Comprehend te dá a primitiva de detecção. O DetectPiiEntities inspeciona texto em tempo real e retorna cada entidade de PII que encontra, seu tipo, seus offsets de caractere e uma pontuação de confiança. Você usa esses offsets para substituir os trechos antes de fazer o log. O Comprehend suporta dois modos de mascaramento: substituir cada entidade pelo seu tipo, então "Jane Doe" vira [NAME], o que mantém o log legível, ou mascarar os caracteres com um símbolo fixo. Substituir pelo tipo costuma ser o certo, porque preserva a forma do prompt para debugging enquanto remove a identidade.

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

Faça a emenda do fim para o começo para que os offsets anteriores continuem válidos conforme você reescreve a string. A detecção é uma chamada em tempo real; para grandes lotes históricos o Comprehend também oferece jobs de redação assíncronos, mas o caminho ao vivo é o que protege as novas escritas.

Detecção é probabilística, então projete para erros

O Comprehend é um detector de machine learning, o que significa que ele tem um recall abaixo de 100 por cento e uma pontuação de confiança na qual você precisa definir um piso. Um limiar baixo redige agressivamente e pode estragar texto legítimo; um alto deixa PII de caso extremo passar. Dois hábitos tornam isso seguro:

  • Camada uma passada determinística. Para identificadores estruturados com formatos fixos, números de cartão de crédito, IDs nacionais, alguns formatos de conta, uma regex captura o que um modelo probabilístico pode deixar passar, e captura da mesma forma toda vez. Rode as duas.
  • Redija em direção aos falsos positivos. Em um log de debug, redigir demais custa um pouco de legibilidade. Redigir de menos custa um incidente de proteção de dados. Enviese o limiar para remover demais.

O Amazon Bedrock Guardrails também pode filtrar informação sensível na fronteira do modelo, o que é complementar: o Guardrails protege o caminho de requisição e resposta, o Comprehend protege o que você escreve nos seus próprios logs. Use o que fica onde está seu risco.

Retenção é a outra metade do controle

Redação reduz o que um log contém; retenção limita por quanto tempo até a forma redigida sobrevive. Um prompt redigido é risco menor, não risco zero, e um log de debug tem uma vida útil natural medida em semanas, não anos. Defina retenção explicitamente no destino:

  • Expire em um cronograma. Uma configuração de retenção de log group do CloudWatch ou uma regra de lifecycle do S3 que deleta depois de uma janela definida significa que logs antigos expiram sem que ninguém precise lembrar de limpar.
  • Case a retenção com o propósito. Debugging operacional raramente precisa de mais que 30 a 90 dias. Se uma janela mais longa é necessária por uma razão específica, nomeie a razão e restrinja essa retenção aos logs que precisam dela.
  • Tranque o acesso. Até logs redigidos merecem IAM restrito. O conjunto de pessoas que pode ler logs de prompt crus deveria ser pequeno e nomeado.

A conclusão

Logging de prompts e proteção de PII não estão em conflito, são dois passos do mesmo pipeline. Redija antes da escrita com o Comprehend, adicionando uma camada determinística para identificadores de formato fixo e enviesando o limiar para redação excessiva. Depois coloque uma política de retenção no que sobra para que os logs redigidos expirem em um cronograma em vez de acumular para sempre atrás de um acesso frouxo. Faça as duas coisas e você mantém o sinal de debugging que precisa enquanto o dado regulado nunca fica em repouso. O log que te ajuda a consertar a app não deveria ser o que aparece em um relatório de vazamento.

Leia isso a seguir

Para o lado de plataforma de pipelines de log, retenção e controle de acesso, as notas de campo de cloud estão em ercan.cloud, e o hub fica em ercanermis.com.