Phase 1 — Validate#
The deployment starts narrow: one team, one workflow, and the containerized engine running in your environment. The validation phase runs Salus detection against an agreed dataset — the documents and records this workflow actually handles — and produces a measured result: what was detected, in which classes, at what quality. Nothing is enforced during this phase, and the exercise runs entirely inside your environment.
What you get out of this phase is evidence, not opinion — detection quality measured on your own data rather than quoted from a datasheet.
Phase 2 — Protect#
With the measured baseline agreed, the workflow is integrated with the Salus API — directly or through your existing AI gateway — and tokenization is switched on for the pilot scope. Users keep the same tools and the same workflow; the difference is that external providers now receive typed tokens for detected governed values, and answers are restored inside your perimeter.
Before Salus goes in path, the protection and failure behavior for the initial workload is agreed and configured per data class — which classes fail closed, which surfaces may degrade visibly, what gets held for human review. The defaults are conservative, and the choices are recorded as configuration, not tribal knowledge.
Expand — when ready#
Expansion is additive rather than disruptive. Each increment reuses what the pilot already proved:
- More applications and agents — each new caller is an API integration or a routing change at your gateway.
- More teams and device groups — where employee AI use is in scope, Salus Desktop rolls out to wider device rings.
- More data classes — additional governed classes and per-class failure behavior.
- Higher-assurance controls — persistent hardened storage and HSM/KMS key custody come in when and where the environment requires them, as described in Deployment Options.
There is no fixed pilot duration — the trigger for each step is that the previous scope is measured and stable, not a date on a slide.