Which AI setup is
actually compliant?

The vendor's own proprietary, most capable model — GPT-5.x, Claude Opus/Sonnet, Gemini 3 — sold with the vendor's full enterprise governance, support, and (where applicable) BAA behind it. Available only through that vendor's own infrastructure, or through a specific, named hosting partnership.

A separate, smaller model a vendor publishes openly — OpenAI's gpt-oss, Google's Gemma — that anyone can host, including competing clouds. Different capability tier, and a different compliance posture: it generally doesn't carry the same enterprise BAA or support as the flagship product, even when it shares a family name.

Going straight to the vendor's own product surface — claude.ai, ChatGPT Enterprise, Gemini Enterprise. The vendor's own compliance tooling (Compliance API, Compliance Logs Platform, Cloud Audit Logs) covers this automatically, no separate setup required.

AWS, Google Cloud, and Microsoft's respective managed model-hosting platforms. Each hosts a mix of the cloud owner's own models, select flagship models from named partnerships (Claude runs on all three; GPT-5.x now runs on Bedrock), and a broader catalog of open-weight models. This is usually a two-processor arrangement, not a clean handoff: the model vendor typically remains the data processor for prompts and outputs under its own terms, while the cloud host provides infrastructure, identity, and billing under its own. What actually changes is the audit tooling — you get the cloud's native logging (CloudTrail, Cloud Audit Logs, Azure Monitor) instead of the model vendor's own compliance product, and it's rarely on by default — see Methodology above.

The open standard that lets an AI agent connect to external tools and data — a file system, a ticketing system, a codebase — as a client connecting to an MCP server. Most of the agentic routes in this tool (Claude Code, Cowork, Codex, Gemini CLI, Copilot Studio) rely on it, or something like it, under the hood.

A proxy layer placed in front of every model route an organization uses, centralizing logging, policy enforcement, and DLP regardless of what native tooling is or isn't available on the underlying route. Several blocked and conditional results in this tool suggest one for exactly that reason.

Real-time inspection that blocks or redacts sensitive data in prompts and outputs as they happen. Audit logging (what this tool checks for) tells you what already occurred — DLP is the layer that stops it in the moment. The two are complementary, not substitutes.

Classification tags that travel with a document or record and determine what an AI system is even allowed to surface to a given user. This is the deployer's own data governance — no model route can compensate for data that was never labeled correctly in the first place.

The human layer: who's approved to use which tools for what, and whether anyone's routing around sanctioned access entirely — a personal API key, a consumer account, a browser extension. The best-configured enterprise route is meaningless if shadow access exists alongside it.

Where a request is actually processed and stored, geographically. A real, separate configuration choice on every platform in this tool — region selection on Bedrock, Vertex, and Foundry all differ from where a client's data may be required to stay under a given regulation.

Whether prompts and outputs are used to improve the vendor's models, and how long they're retained before deletion. Increasingly a contractual toggle — Zero Data Retention, opt-out flags — rather than a fixed default, and worth confirming per contract, not assumed from a product tier.

Running a flagship model on a hyperscaler means two vendors are now in the data path, not one — Claude on Bedrock is Anthropic and AWS. Every route in this tool names both where that applies; a full vendor risk assessment needs each party's own terms, not just the model owner's.

Every MCP connection grants an agent some ability to read or write external data — a codebase, a ticket queue, an inbox. The governance question isn't the model or the route, it's whether that specific connector was vetted and what it's actually scoped to touch. A perfectly cleared model can still be handed an ungoverned connector.

A fundamentally different risk from data leakage: content an agent reads — a web page, a document, an email — can carry hidden instructions trying to redirect what it does next. The more autonomous the route (coding agents, browser agents, Cowork-style tools), the more this matters, and no compliance rating on this page addresses it.