Short answer
What matters most
Send the smallest version of a record that still supports the workflow's decision. Remove fields that do not change the answer; replace identifiers with scoped tokens when relationships matter but identity does not; send exact values only when the decision truly needs them and the model route, storage, access, and logging are approved. A built-in PII detector can help find known patterns, but test it on the actual formats, languages, and identifiers you process.
Start with the field the task actually needs
An operations team wants AI to sort incoming invoices. A PDF also includes names, addresses, bank details, and remittance notes. If the model only routes each invoice to the right review queue, sending every value creates a larger data path without necessarily improving that decision.
Decide per field, not by file label: does the exact value change the task? The diagram shows three ways to reduce an input and one case for keeping an exact value. It is a design rule, not a promise that an automated detector will find every sensitive field.
Privacy is a system risk, not an accuracy score
NIST's generative-AI profile includes leakage and unauthorized disclosure among data-privacy impacts. A correct extraction can still move more sensitive information than the operation needs; the profile identifies a risk, not a redaction mandate.
NIST: Generative Artificial Intelligence Profile (July 2024)Choose a transformation by the task
Removing a field gives the model no value to use. Replacing it with a label such as [ACCOUNT_ID] preserves the kind of information but loses the exact identity. A token can preserve that two documents refer to the same supplier without exposing the supplier's original identifier to the model. A stable or reversible token still creates a link between records, so keep its mapping or key in a separately controlled store.
Retain an exact value only when it changes the decision the model must support. If a conventional rule or the business system can check that value directly, keep the check there rather than putting it in a prompt for convenience.
Redaction is one of several transformations
Google Sensitive Data Protection documents deletion, replacement, masking, and cryptographic tokenization. Its guidance says the choice depends on the data and purpose; its API applies the configured transformation to values matched by the configured inspection criteria.
Google Cloud: Sensitive Data Protection transformation reference (updated October 20, 2026)On a small screen, scroll the table to read every column.
| Treatment | Use it when | Trade-off to test |
|---|---|---|
| Remove | The field does not change the answer or action. | Confirm that removing it does not remove a required clue from the document. |
| Replace with a label | The task needs to know the field type, not its value. | Check that the model can still distinguish the cases it must route. |
| Tokenize | A relationship across records matters, but the original identity does not. | Keep the mapping or key out of the model request and restrict who can restore it. |
| Retain under approved controls | The exact value changes the decision and the chosen route permits it. | Check the model endpoint, stateful features, logs, access, and review step. |
Check the native detector against real inputs
A PII detector can find known categories before a model call, but your organization still chooses what categories matter and what each match should become. Company-specific codes, contract terms, or a business rule may need a separate detector or an ordinary deterministic check. A detector service also receives the original text before it can transform it, so include that request in the approved data path.
Start with a feature already available in the platform your team uses. Microsoft documents separate text, conversation, and native-document PII features with different input and processing models. Google documents configurable built-in detectors as well as custom dictionaries and regular expressions. Test the exact document shape and languages you receive, then inspect missed matches and unnecessary redactions before enabling a live workflow.
PII features have different input contracts
Azure Language returns confidence-scored detections, but its text, conversation, and document features process different input shapes. That makes a representative sample test more useful than assuming one detector configuration covers every file or transcript.
Microsoft Learn: Azure Language PII detection overview (updated July 22, 2026)Redaction does not settle retention
Removing identifiers can reduce what reaches a model, but it does not answer what the selected endpoint, stateful feature, gateway, or your own application logs retain. Check the exact model route and feature settings as part of the same data-flow review.
For example, OpenAI's API documentation says API data is not used to train or improve its models unless a customer opts in. It separately says abuse-monitoring logs may contain customer content and are retained for up to 30 days by default, while application-state behavior depends on the endpoint and feature. That is a product-specific example: do not read a no-training statement as a complete retention description.
Training and retention are separate controls
OpenAI documents no training by default for API data, alongside separate abuse-monitoring retention and endpoint-specific application state. Verify the account's actual route and feature configuration; this example does not describe other providers.
OpenAI: Data controls in the API platform (checked October 21, 2026)Worked example: a hypothetical invoice queue
Imagine a team uses a model to extract invoice details and recommend which review queue should receive each submission. This scenario is hypothetical; I have not built or measured this workflow. The process owner decides that invoice date, amount, purchase-order match, and a supplier reference affect the queue. Bank details printed for remittance do not.
The workflow can remove bank details before the model call. If the same supplier appears across several submissions, it can pass a scoped supplier token and keep the token map in the business system. If a separate task must verify a changed payment account, send that value only through a route approved for that task and have a deterministic check or authorized person confirm the change. The model does not need every field just because it appears on the page.
Write a data-boundary brief before release
Use the matrix above as a field-by-field policy. For each field, record the task that needs it, its treatment, where the original and any token map remain, which services see the raw value, and who approves exceptions. Then test the boundary with representative normal, missing, unusual, and unsupported inputs.
- Confirm the output still supports the business decision after each transformation.
- Check for missed sensitive values and fields that were removed unnecessarily.
- Inspect the detector request, model request, application logs, and stored outputs for raw values.
- Define who reviews an uncertain match and what manual path keeps the process moving.
Use the smallest system that meets the policy
A native PII or data-protection feature is sufficient when it covers the real input format, required categories, chosen transformations, and review path. Add custom engineering only for a specific gap, such as a business identifier the native detector cannot recognize, a token relationship it cannot preserve, or a workflow that needs a control the existing platform cannot represent.
The document-automation case study shows an existing extraction-to-record workflow; it does not claim that this redaction policy was part of that engagement. If you are mapping a similar system, I can help identify which fields the decision actually needs and test the smallest safe transformation. Start with the document flow and its current model route, not a blanket rule to redact everything.