Anonymization solves a different problem#
Anonymization is the right tool when data will be released and never needs to point back at a person — research datasets, published statistics, long-term archives. Its defining property is that re-identification is no longer reasonably possible, for anyone, including you.
An AI workflow is the opposite situation. A support engineer asking a model to summarize a complaint needs the answer to say which subscriber and which account — inside the perimeter, where that information is legitimate. If the pipeline anonymized the prompt, the answer would come back permanently incomplete, and no vault or key could fix it.
Reversible, but not casually reversible#
"Reversible" describes the architecture, not the ease of access. Restoration requires three things that all live inside the customer-controlled environment: the vault holding the token mapping, the customer-controlled keys that unwrap it, and a policy decision authorizing the restore. Every restoration is an audited event. An external provider — or anyone without those three — holds tokens with no path back.
This is also why the terminology discipline matters. Calling reversible tokenization "anonymization" would claim a property the system deliberately does not have. The accurate frame: Salus tokenization keeps detected sensitive values inside the customer perimeter while external models work with tokens, and supports pseudonymization-style controls — a classification question covered in Tokenization vs. Pseudonymization.
Where irreversibility still appears#
Policy can mark specific classes as block or mask-without-restore — a data class you never want echoed back can simply stay tokenized in the delivered answer. The difference is that this is a policy choice per class and workflow, not a global property of the pipeline.