Why regulated institutions need BYO-AI
A regulated institution rarely has the luxury of choosing one AI vendor and forcing everyone onto it. Microsoft Copilot is licensed because the institution is on Microsoft 365. ChatGPT Enterprise is licensed because the strategy team adopted it. Claude is licensed because the legal team prefers it. Internal LLM deployments serve specific workflows. The AI estate is heterogeneous by default.
Regulators care about a different question. What policy governed the AI processing? Was personal data minimised before the model saw it? Is the audit trail verifiable without trusting the AI vendor? The questions are about the institutional control layer, not the AI vendor. Aligning the architecture to the regulatory question means decoupling safety from inference.
The BYO-AI pattern is that decoupling. The safety, policy, and audit layer is adopted once. It applies across whichever AI vendor the staff use today and across whichever AI vendor they switch to tomorrow. The compliance posture is portable; the AI vendor is interchangeable.
The architecture, end to end
The safety layer sits between the user-facing AI surface and the AI inference vendor. Five stages run on every interaction.
Prompt enters the safety layer
When a user submits a prompt to any supported AI surface, the request is intercepted by the safety layer before it reaches the AI inference vendor. The intercept happens at the institutional perimeter (plugin runtime, MCP server, or browser extension), not at the AI vendor.
Classifier and policy run
Field-level classifiers identify PII, PHI, financial sensitivity, Shariah-sensitive content, or institution-specific categories. The disclosure policy (defined once by the DPO) determines what is redacted, what is allowed through, and what is blocked. The policy is the same across all AI surfaces.
Evidence record produced
A signed evidence record captures the pre-redaction state hash, the policy version, the redacted fields, the timestamp, the actor, and the destination AI surface. The record is sequenced and designed to be anchored to a tamper-evident store. The chain is designed to be tamper-evident.
Redacted prompt forwarded to AI
The AI inference vendor receives the redacted prompt. The vendor knows nothing about the safety layer, the policy, or the institutional context. From the AI vendor perspective, this is an ordinary API call.
AI response returns through the layer
The AI response passes back through the safety layer. The audit trail captures the round trip. If the response contains content that violates output policy (for example, an attempted disclosure of redacted context), the safety layer intervenes. The user sees the policy-compliant final response.
Integration points across the AI estate
The same safety layer architecture connects to each AI surface via a surface-specific integration. The user experience is preserved; the institutional control is added.
Microsoft 365 Copilot
In active developmentSurface: Outlook, Teams, SharePoint, Word, Excel
Integration: Enterprise plugin via Microsoft Copilot extensibility
Anthropic Claude
In active developmentSurface: Claude Desktop, Claude API, Claude-based agents
Integration: MCP server (Model Context Protocol)
OpenAI ChatGPT and other browser AI
In active developmentSurface: Web chat, browser sessions, embedded AI in SaaS tools
Integration: Enterprise-managed browser extension
Internal LLM deployments
Pilot deployments availableSurface: Self-hosted models, internal fine-tuned models, custom RAG stacks
Integration: Custom adapter using the ZeroH Disclosure SDK
Distribution is IT-administrator gated
In regulated finance, individual users cannot install arbitrary plugins, MCP servers, or browser extensions. The institutional IT team controls the tenant. The BYO-AI pattern aligns with that constraint. The safety layer is enabled tenant-wide once. Users continue to use the AI tools they had. The policy and audit layer applies invisibly.
This matters for two reasons. First, it means the deployment process matches how regulated institutions actually buy: through procurement, security review, and tenant-level rollout, not viral user adoption. Second, it means the safety guarantee is enforced, not opt-in. A staff member cannot bypass the safety layer by switching to a different AI tool, because the layer is configured at the surface where they use the AI.
For the institution, this is the difference between an aspirational privacy posture (we encourage staff to be careful with AI) and an enforced one (the safety layer applies to every prompt regardless of user behaviour). Regulators ask about the second posture, not the first.
The alternative is not safer; it is just slower
The institution that does not adopt a BYO-AI safety pattern still has staff using AI. The institution has chosen to operate without the policy and audit layer, not to abstain from AI. The exposure is unchanged or worse, and the visibility is zero.
The institution that bans AI tools formally usually finds that staff use them on personal devices or with personal accounts. Shadow AI fills the gap. Shadow AI has no policy enforcement, no audit trail, and no evidence for the regulator. The cost of a ban is not safety; it is the loss of any path to a verifiable safety posture.
BYO-AI is the pattern that lets the institution say yes to AI adoption and yes to verifiable safety in the same architecture. The questions for the IT team and the DPO become operational. Which AI surfaces first. Which policy template first. Which jurisdiction first. The yes-or-no question on AI adoption is no longer the bottleneck.
Frequently asked questions
BYO-AI is the architectural pattern where the AI safety, policy, and audit layer is decoupled from the AI inference vendor. The institution chooses the safety tooling once and applies it across whichever AI the staff use. The opposite pattern is a closed AI stack where safety, policy, and inference all come from the same vendor; switching vendors means switching all three.
Three reasons. First, staff at regulated institutions already use multiple AI tools (Copilot from Microsoft, ChatGPT from OpenAI, Claude from Anthropic, custom deployments). Forcing them onto a single AI vendor for compliance reasons is operationally hostile and politically difficult. Second, AI vendor competition is intense and the leader changes annually; locking compliance to a single inference vendor creates a forced re-platform every time the institution wants to switch. Third, regulators care about the policy and audit layer, not which AI happens to be on the other side of it. The BYO-AI pattern aligns the architecture with what regulators actually scrutinise.
A safety layer (such as ZeroH Disclosure) sits between the user-facing AI surface and the AI inference vendor. When a prompt is sent, the safety layer intercepts it before it reaches the model. Field-level classifiers run. Redaction is applied under policy. A signed evidence record is produced. The redacted prompt is forwarded to the AI vendor. The AI response returns through the same layer, where the audit trail captures the round trip. The user experience is unchanged; the compliance posture is fundamentally different.
The architecture is AI-vendor-agnostic by design. Initial plugin integrations under development cover Microsoft 365 Copilot (enterprise plugin), Anthropic Claude (MCP servers), ChatGPT and browser-based AI tools (managed browser extension), and internal LLM deployments (custom adapters). The institution chooses which AI to plug in. The safety policy and the audit evidence are the same artefacts across all of them.
LLM security tools defend the AI inference call against adversarial inputs. They are concerned with what the model does given a prompt. The BYO-AI safety layer is concerned with what the model is allowed to see given a prompt. The two are complementary. An institution can use an LLM security tool inside the AI vendor stack and a BYO-AI safety layer outside it. The BYO-AI safety layer is what is designed to produce the regulator-verifiable evidence regulators expect.
Deployment is by IT administrator, not by individual user. In regulated institutions, individuals cannot install arbitrary plugins or extensions. The IT team enables the BYO-AI safety layer tenant-wide. Users continue using the AI tools they already had. The policy and audit layer applies invisibly. Compliance demonstrates evidence to the DPO, CISO, and regulator from the runtime data the layer captures.
Talk to us about being in the first deployment cohort for the Microsoft 365 Copilot plugin, the Claude MCP server, or the browser extension.
Schedule a demo