Free checklist · LLM prompts and responses

The PII Redaction Checklist

33 checks to redact PII from LLM prompts and responses, and keep it out of model providers, observability logs, and downstream pipelines, without breaking the workflows that legitimately need the data.

No paywall Mapped to GDPR, HIPAA, PCI Built for security and privacy teams
  • PII is redacted before prompts leave for a model provider
  • Responses are redacted before they reach apps or logs
  • Requests fail closed if the redaction engine errors
  • Every redaction event is logged with the policy that fired

Wat de checklist dekt:

33

Evaluatiecriteria voor het detecteren, anonimiseren en auditen van PII in LLM-verkeer

5

Controlegebieden, van detectiedekking tot audit en compliance

12

Must-have controles, gemarkeerd zodat je weet wat je als eerste moet aanpakken

4

Redactiestrategieën vergeleken: maskeren, tokeniseren, hashen en volledige verwijdering

Inhoud van de checklist

Download de checklist en ontvang:

Een werkbaar kader dat uw security-, privacy- en platformteams kunnen gebruiken om PII-guardrails te evalueren of om de bestaande guardrails aan te scherpen.

Checklist downloaden

✓

Het volledige PII-redactiekader van 33 punten

Elk criterium gegroepeerd per controlegebied, met de vraag die je moet stellen en een prioriteit: must-have, should-have of nice-to-have.

✓

Een uitrolplan in drie stappen

Breng de relevante PII-categorieën in kaart, kies een redactiestrategie per categorie en workflow, en voer vervolgens per kwartaal audits en optimalisaties uit.

✓

Criteria voor redactiestrategie

Wanneer blokkeren, maskeren, tokeniseren, hashen, gedeeltelijk maskeren of doorsturen voor menselijke beoordeling, zodat redactie nooit legitieme workflows verstoort.

✓

Audit- en compliance-eisen

Redactie-eventlogs, controles voor heridentificatie, sampling van false-positives en rapportage voor SOC 2, HIPAA en AVG.

Waarom dit belangrijk is

PII lekt sneller via LLM-prompts dan de meeste teams verwachten

Namen, e-mailadressen, rekeningnummers, adressen, IP-adressen en identificatiegegevens in vrije tekst stromen door hetzelfde kanaal als al het andere in een LLM-verzoek. Een supportmedewerker plakt een klant-e-mail in een prompt. Een RAG-pipeline haalt een document op met een patiëntnummer. Een model herhaalt een rekeningnummer in zijn antwoord, en de hele uitwisseling wordt weggeschreven naar een observability-log.

Elk van deze is een kopie van persoonsgegevens op een plek waar ze niet horen: een externe modelprovider, een trace-store, een SIEM of een downstream analytics-pipeline. Elke kopie vergroot de blootstelling onder AVG, HIPAA en PCI, en maakt het moeilijker om te voldoen aan verzoeken tot gegevenswissing.

Prompt from app Refund Jane Doe, email jane@acme.com AI Gateway · pre-call detect + redact per-route · fail-closed Model provider sees Refund [NAME], email [EMAIL] Model response Refund sent to jane@acme.com AI Gateway · post-call redact response event → request log App + logs receive Refund sent to [EMAIL]

Redigeer bij het uitgaan en bij het terugkomen. De checklist dekt beide richtingen, plus de logs daartussenin.

Teams beginnen meestal met een of twee regex-regels in de applicatiecode. Dat vangt wel wat e-mailadressen en kaartnummers op, maar mist namen en adressen in vrije tekst, PII in JSON-payloads en RAG-chunks, geheimen die in prompts worden geplakt en alles wat in het antwoord terugkomt. Bovendien loopt het vast wanneer een workflow de data legitiem nodig heeft, en het laat zelden een audittrail achter.

Hoe goede PII-redactie eruitziet

Detectie omvat gereguleerde identificatiegegevens, namen en adressen, contactgegevens, PHI, PCI-data en geheimen, zowel in vrije tekst als in gestructureerde payloads, documenten en retrieval-chunks. Elke categorie krijgt de juiste strategie voor de workflow: een getypeerde tag zoals [NAME], een omkeerbaar token voor systemen die opnieuw moeten identificeren, een eenrichtings-hash voor analytics, of volledige verwijdering uit logs en traces.

Redactie vindt inline plaats bij de gateway, voordat verzoeken de aanbieder bereiken en voordat antwoorden de apps bereiken, waarbij dezelfde beleidsregels worden toegepast op agent-tool-aanroepen en MCP-verkeer. Het systeem is 'fail-closed', voegt nauwelijks latentie toe en logt elke gebeurtenis met wat er is gedetecteerd, welk beleid is geactiveerd en welke actie is ondernomen, zodat teams steekproeven kunnen nemen van fout-positieven en detectoren in de loop van de tijd kunnen verfijnen.

Behandel redactie als één guardrail-laag

PII-redactie werkt het best in combinatie met routing, 'least privilege'-toegang en retentiecontroles. De PII-redactiechecklist vertaalt die standaard naar 33 criteria die je kunt gebruiken om een gateway- of guardrail-aanbieder te evalueren, of om de controles die je al hebt draaien te auditen.

Voorbeeld

De vijf controlegebieden in de PII-redactiechecklist

Een greep uit de criteria in elk gebied. De volledige checklist bevat alle 33 punten, inclusief prioriteiten en evaluatievragen.

Gebied 1 · 10 controles

Detectiedekking

BSN's, kaartnummers, bankrekeningen, paspoorten en rijbewijsnummers worden standaard gedetecteerd

PII in ongestructureerde vrije tekst wordt opgevangen, niet alleen in JSON-velden

+8 extra controles

Gebied 2 · 5 controles

Redactiestrategieën

Entiteiten worden inline vervangen door getypeerde tags zoals [NAAM] of [E-MAIL]

Entiteiten worden volledig uit logs en traces verwijderd, niet alleen gemaskeerd tijdens transport

+3 extra controles

Gebied 3 · 6 controles

Inline handhaving en prestaties

PII wordt geredigeerd voordat verzoeken de gateway verlaten

Verzoeken worden geblokkeerd en niet doorgelaten wanneer de engine fouten vertoont

+4 extra controles

Gebied 4 · 6 controles

Aangepaste entiteiten en guardrail-ecosysteem

Aangepaste regex dekt werknemers-ID's, rekeningnummers en projectcodes

Detectiebetrouwbaarheid bepaalt of er wordt geblokkeerd, geredigeerd of gemarkeerd en gecontroleerd

+4 extra controles

Gebied 5 · 6 controles

Audit, omkeerbaarheid en compliance

Redactie-events loggen wat er is gedetecteerd, welk beleid is toegepast en welke actie is ondernomen

Elke heridentificatie van een token is toegangsgecontroleerd en gelogd

+4 extra controles

Hoe te gebruiken · 3 stappen

Uitrol

Entiteiten catalogiseren: gereguleerde identificatoren, bedrijfsgevoelige velden en risico's op lekken in vrije tekst

Kies per categorie en workflow voor maskeren, tokenisatie, hashing of verwijdering

Analyseer redactie-events, beoordeel false positives en negatives, en voer per kwartaal optimalisaties uit

4,7

★★★★★

Gartner Peer Insights

Beoordeeld met een 4,7 op Gartner Peer Insights

Teams gebruiken de AI Gateway van TrueFoundry met inline PII-guardrails, aangepaste entiteitsdefinities, beleidsgestuurd maskeren per route, gebenchmarkte integraties van guardrail-providers en redactie-events die worden vastgelegd in verzoeklogs.

96%

van de beoordelaars beveelt dit waarschijnlijk aan

4,9

gebruiksgemak bij implementatie en beheer

3–4 ms

extra gateway-latentie

Veelgestelde vragen over de PII-redactiechecklist

Wat is PII-redactie voor LLM's?

PII-redactie voor LLM's is het proces van het detecteren van persoonlijk identificeerbare informatie, zoals namen, e-mailadressen, rekeningnummers, adressen en IP-adressen in prompts en antwoorden, en het maskeren, tokeniseren, hashen of verwijderen ervan voordat het modelproviders, observabiliteitslogs of downstream-pipelines bereikt.

Waarom PII redigeren in zowel prompts als antwoorden?

Prompts kunnen PII naar externe modelproviders sturen en antwoorden kunnen PII blootstellen aan applicaties, gebruikers en logs. Redactie vóór het verzoek beschermt wat uw omgeving verlaat, en redactie na het verzoek beschermt wat terugkomt en wordt opgeslagen.

Wat is het verschil tussen maskeren, tokenisatie en hashing?

Maskeren vervangt een entiteit door een getypeerde tag zoals [NAAM] of [E-MAIL]. Tokenisatie vervangt het door een stabiel token dat door geautoriseerde systemen later weer kan worden herleid; dit is pseudonimisering in plaats van anonimisering. Hashing is eenrichtingsverkeer, waardoor analyses kunnen groeperen op identiteit zonder de waarde bloot te leggen. Volledige verwijdering wist de entiteit volledig, wat vaak de juiste keuze is voor logs en traces.

Zorgt PII-redactie voor extra latentie bij LLM-verzoeken?

Inline redactie voegt verwerkingstijd voor guardrails toe bovenop de standaard gateway-overhead. De checklist vraagt leveranciers om aan te tonen dat de totale overhead laag blijft; de gateway-baseline van TrueFoundry is ongeveer 3 tot 4 ms, exclusief de tijd voor guardrails.

Wat moet er gebeuren als de PII-redactie-engine faalt?

Verzoeken moeten 'fail-closed' zijn: als de redactie-engine een fout geeft, wordt het verzoek geblokkeerd in plaats van onbewerkt doorgestuurd. De checklist beschouwt 'fail-closed'-gedrag als een vereiste.

Voor wie is de checklist voor PII-redactie bedoeld?

Security-, privacy-, platform engineering- en compliance-teams die klant- of werknemersgegevens versturen via LLM-applicaties, agents of MCP-tools en die PII buiten modelproviders en logs moeten houden voor GDPR, HIPAA, PCI of SOC 2.