OneTrust AI Guard: what it is and when you need it
What it is
AI Guard is OneTrust's policy and inspection layer for data flowing into and out of AI systems - LLM prompts, model responses, and AI-agent tool calls. It sits in front of your application's calls to a model provider, classifies content against configured sensitivity profiles, and can redact, block, or simply log matches in real time, rather than relying on the model provider's own safety layer to catch a leak after the fact.
When you need it
Your team is connecting internal applications to a third-party LLM API and needs assurance that customer PII, health data, or credentials never leave your infrastructure inside a prompt.
You're scanning AI-generated responses before they reach a customer-facing surface, to catch sensitive content the model itself shouldn't have surfaced.
Privacy or legal has asked for a governance answer to "what stops sensitive data from reaching our AI vendor" that's backed by an inspection layer, not a policy statement.
How to implement it
- 1
Confirm AI Guard is available on your OneTrust tenant
AI Guard is a distinct module from OneTrust's core consent/privacy products - whether it's included in your current license or needs its own provisioning is tenant-specific, so verify against current OneTrust docs or your account team before scoping implementation time.
- 2
Define classification profiles for what actually counts as sensitive in your context
Start from OneTrust's built-in PII categories, then add anything specific to your data model - internal IDs, contract numbers, health record formats - that a generic profile wouldn't catch.
- 3
Initialize the inspection call server-side, in front of your model calls
AI Guard needs to see the prompt before it reaches the model provider and, if you're also scanning output, the response before it reaches the user - this belongs in your backend service layer, not in client-side JavaScript, since the whole point is to inspect data before it leaves your infrastructure.
- 4
Set an explicit action per profile: block, redact, or log-only
A profile you're not confident in yet should log-only while you tune it; a profile covering a real compliance requirement should block or redact outright. Don't ship every profile in block mode by default before you've measured its false-positive rate.
- 5
Decide and implement the fail-safe behavior deliberately
If the AI Guard call itself times out or errors, decide whether the request should fail closed (block the prompt from reaching the model) or fail open (let it through and log the miss) - this is a risk decision your team should make explicitly, not an accident of whatever the default happens to be.
How to verify it worked
Seed a synthetic sensitive value (a fake SSN or a test credential, not a real one) into a test prompt and confirm it gets flagged, redacted, or blocked exactly as the profile's configured action specifies.
Check AI Guard's own logs or metrics for the test request and confirm it was actually counted, so you know the integration point is live and not silently bypassed.
Deliberately break the connection (wrong API key, network block) in a test environment and confirm your fail-safe behavior fires as designed - the failure path is the one that never gets exercised by accident, so it needs its own explicit test.
Related
Want this scoped against your specific OneTrust tenant?
We scope every engagement in discovery, before implementation - no assumptions about your stack.