How Tavrik works
Your staff already use AI tools. Tavrik sits between them and the model, catches the data that must not leave, applies the policy you set, and writes a record your auditors can verify.
This page is for the person who has to decide whether that is safe. It answers four questions: what happens to a request, what Tavrik sees and stores, what compliance posture it carries, and how it is deployed.
What happens to a request
Two paths, one policy.
A clinician typing into ChatGPT. A signed browser extension sees the
submission before it leaves the page. It recognises the identifiers in the text
— names, MRNs, dates of birth, Medicare numbers — and replaces them with
placeholders. The model receives {NAME_1}, {MRN_1}; the reply comes back and
the placeholders are restored for the clinician, who sees their own words. Only
categories ever leave the browser — never the text that matched.
An application calling an AI API. The same policy runs in the gateway. The request is inspected, redacted, allowed or denied, then routed to the model you permit. Your application changes one base URL.
In both cases the decision is recorded before the model is called, not after.
What Tavrik sees, stores, and never touches
This is the question a security review actually turns on.
| Sees | The content of an AI request, in memory, for as long as it takes to inspect and redact it. |
| Stores | Categorical facts about that request: which tenant, which model, which categories of data were found, what the policy decided, when. |
| Never stores | Prompt or response text. The audit log is categorical by construction — the event schema has nowhere to put a prompt. Request and response bodies are not persisted unless you explicitly turn that on. |
| Never touches | Your clinical systems. Tavrik does not process HL7 messages between your EHR and your lab, does not mediate FHIR clinical APIs, does not read or write anything in the EHR, and is not a general-purpose DLP. That boundary is architectural, not a setting. |
The audit log is append-only and hash-chained: every event carries the hash of the one before it, so a removed or altered record breaks the chain and is detectable. Verification is an API call over a list of events you supply, in chain order, up to a thousand at a time — a whole file is verified slice by slice, and the runbook carries the script that walks it.
What Tavrik is and is not, in full →
Compliance posture
Tavrik maintains control mappings — each framework’s controls traced to the features and evidence that satisfy them — for SOC 2, ISO 27001, HIPAA, APRA CPS 234, GDPR and the EU AI Act. Compliance work happens in the same pull request as the feature it affects, not as an annual scramble.
Two things to be precise about, because evaluators are right to ask:
- A control mapping is not a certification. Where you need a third-party attestation, ask for it directly rather than inferring one from this page.
- Tavrik signs as a Business Associate for healthcare deployments. The BAA and DPA are part of the commercial package, not a technical setting.
The structural commitments behind those mappings are the ones you would test first: multi-tenancy enforced at every layer, TLS 1.3 in transit and AES-256 at rest with customer-managed keys available, data residency as a hard routing constraint rather than a preference, and no policy bypass — there is no configuration that turns inspection off for a request that would otherwise be blocked.
How it is deployed
| Shape | What it means |
|---|---|
| Dedicated VM | A single cloud or on-prem virtual machine running the gateway, admin API and console. One tenant, your data, your keys. This is the pilot shape. |
| On-prem | The same components on your own hardware, air-gappable, with a signed installer that verifies itself before touching the host. |
| Sovereign / regional | Dedicated regional deployments where data residency requires it. |
| SaaS | Multi-region Kubernetes, for organisations that do not need a dedicated deployment. |
The browser extension and any programmatic clients talk to whichever control plane you run. Nothing is shared between tenants at any layer.
What to read next
- The architecture in detail — services, data stores, request lifecycle, failure modes.
- Tavrik for healthcare — who it is for, and the explicit list of what it does not do.
- The healthcare architecture — where PHI is caught and where audit events go.
- Onboarding a department — what a rollout actually involves.