Use leading AI models with reversible tokens instead of detected personal data. Compare document redaction, prompt privacy, OCR and retention.
Sluis tokenization lets a leading model draft or summarise using typed tokens instead of the detected protected originals. Sluis restores the protected values on the return path and never sends the token mapping to the provider. First decide whether you need that protected AI workflow or a shareable redacted document: these are different purchases with different verification steps.
Use leading models with protected personal values
The benefit is a usable answer, not a document full of placeholders for your team to repair manually. The following fictional HR example illustrates tokenization when the name and email are detected and protected. It is not a test result or a promise that every identifier will be found.
Before protection: “Draft a short invitation to a project review for Mira Vermeer at mira@company.example.”
Model provider receives: “Draft a short invitation to a project review for «PERSON_NAME_1» at «EMAIL_1».”
Returned result after restoration: “To: mira@company.example. Hi Mira Vermeer, could we schedule a short project review?”
HR has a personalised draft to review, while the generation provider did not receive those protected original values or their token mapping. The provider still receives the remaining task and context. Detection can miss identifiers, and context can identify someone without an explicit name.
This is a managed Sluis workflow, not a claim that all processing stays on your own infrastructure. Optional hosted inspection receives the remaining eligible text after local protection; missed identifying details may reach that additional recipient. Review its processing location and terms before enabling it.
Distinguish document redaction from pseudonymisation
Document redaction removes selected information from a document output. Prompt pseudonymisation replaces sensitive values with reversible tokens. Neither label alone proves that the remaining content cannot identify someone.
Illustrative scenario: a legal team needs an external disclosure copy and an internal AI summary. Evaluate a redacted document for disclosure and a separate pseudonymised prompt workflow for the summary.
- Specify the intended recipient and output format.
- Decide whether any re-identification must remain possible.
- Have a reviewer assess residual identifying context.
Test the local document pipeline on difficult files
Sluis document anonymization uses a local API for PDF, DOCX, images and text, with OCR. Unreadable areas are destroyed rather than guessed, which can protect against uncertain reconstruction but also remove useful content.
For recurring or batch workflows, test your actual file mix before integration. Check legibility and omissions in outputs, and verify required throughput and API behaviour rather than assuming a one-off utility meets production needs.
- Include scans, images and poor-quality pages in tests.
- Inspect outputs for missed identifiers and lost meaning.
- Validate batch requirements and local deployment boundaries.
Understand each prompt-protection mode and its limits
Default prompt protection uses reversible tokenization for detected values. mask irreversibly replaces detected values, while block refuses a request when it detects protected content. allow_log only records detections and forwards the original text unchanged; it does not protect those values.
Detection is not perfect and coverage depends on content and configuration. Tool definitions are not scanned, and embeddings can be configured to bypass scanning. Existing Workspace web search results and model output are not newly tokenized; generated media cannot restore tokens to original values. Security scanning is a separate optional control. Test the paths you actually use rather than assuming complete prevention.
- Choose the appropriate mode for each information class.
- Test missed identifiers and indirect identifying context.
- Verify scanning settings and unprotected content paths.
Treat retention and audit as separate decisions
Configure Sluis content retention, Workspace original-value and conversation-history windows, and review upstream provider terms separately. Metadata is retained. Tokenization does not mean zero retention, and mappings not being sent to the model provider does not mean originals are never stored within Sluis.
A hash-chained audit trail helps review recorded activity; it does not establish lawful processing or complete detection. Agree deletion, reviewer access and escalation steps before sensitive production use, using the data-protection documentation.
- Configure content retention before submitting sensitive data.
- Verify erasure behaviour and retained metadata.
- Document reviewer approval and escalation for uncertain cases.
Questions before you decide
Is reversible tokenization anonymization under GDPR?
Reversibility is a reason not to assume anonymization. Treat it as pseudonymisation and assess the remaining data, re-identification access and legal context with your privacy reviewer.
Can OCR safely reconstruct unreadable text?
The described document process destroys unreadable areas rather than guessing their content. Review outputs for lost information and obtain a better source if the missing text matters.
Does masking mean no data is stored?
No. Transformation and retention are separate controls. Review Sluis content and Workspace retention settings, retained metadata and the provider's own terms.