Governance that runs in production, not in a slide deck.
Most AI governance programs end at an acceptable-use policy and a model inventory spreadsheet. Data.co Control gives the program a runtime: every AI request is checked against written policy before it executes, and every decision is recorded where your auditors can reach it.
Policy on paper does not stop a request at 2 a.m.
Governance committees write sound rules: no PHI to external models, no autonomous changes to production data, every AI use case has an owner. The problem is enforcement. Rules live in documents, AI usage lives in dozens of tools, and the only control between them is whether people remember the rules.
Data.co Control closes that gap by putting a decision point in the path of every AI request. A governance rule becomes a versioned policy with tests. A model inventory becomes the gateway's list of approved endpoints. A use-case owner becomes the named approver on a policy. The program you already designed becomes something that executes, and produces its own evidence.
Where each governance question is answered.
The questions a governance program has to answer, and the part of Control that answers them with data rather than attestation.
| Governance question | Answered by | Evidence produced |
|---|---|---|
| What data do we have, and what is sensitive? | Catalog and classification at ingest | Inventory of sources, fields, and labels with owners |
| Which models are approved, for what data? | AI gateway endpoint registry + policy | Endpoint list and the policies that reference each one |
| Who and what can access regulated data? | Identities + policy engine | Policy set at any point in time, with test results |
| What did an AI agent actually do? | Enforcement points + audit log | Per-request record: identity, decision, sources, tools, outcome |
| Which high-risk actions had human review? | Approval workflows | Approver, timestamp, context shown, and decision |
| Did anything sensitive leave the boundary? | DLP policies on egress paths | Denied and allowed egress events by classification |
Clear ownership across security, data, and the business.
Security and risk
Own baseline policies, external endpoint approvals, and DLP rules. Review audit exports and denied-request trends.
Data owners
Confirm classification labels on their sources and act as approvers for access that falls outside the baseline.
Platform engineering
Operate the runtime, manage connectors and model endpoints, and run policy changes through Git review and CI.
Legal and compliance
Map internal controls and framework requirements to policies, and pull evidence from the audit log for reviews.
A governance rollout in four stages.
Each stage produces something usable on its own, so the program does not wait on a single cutover.
- 1
Inventory
Connect priority sources, populate the catalog, and identify which AI tools and agents are already in use.
- 2
Classify
Apply PHI, PII, financial, privileged, and custom labels at ingest, and have data owners confirm them.
- 3
Codify
Translate written rules into policies, write tests for them, and run real scenarios through the simulator.
- 4
Enforce + evidence
Route AI traffic through the gateways, turn on enforcement, and schedule audit exports for your review cadence.
How a governance rule changes without breaking production.
A rule change in a governance program usually starts as a committee decision and ends as an email. In Control it follows the same path as any other production change. A policy author opens a pull request that edits the YAML and the tests that describe the intended behavior. Reviewers see the exact diff, and CI runs the full test suite against the whole policy set, not just the edited file, because a new allow can interact with an old deny in ways a reader may miss.
When the change merges, the policy set is delivered to the runtime, either by updating the policy directory and triggering a reload or, across an air gap, as a bundle signed with a key you control. The runtime validates the set and runs its tests before activating it. If anything fails, the previous valid set stays in force and the errors are reported, so a bad change cannot leave production half-governed. Every decision after activation records the new policy set version, which gives the committee a clean before-and-after boundary when it reviews the effect of a change.
Signals a governance committee can review each cycle.
These come from the decision log and catalog in your environment, not from surveys or self-attestation.
Denials by policy
Which rules are actually firing, and whether a spike follows a policy change, a new agent, or a newly connected source.
Approvals and outcomes
How many high-risk actions were held, who approved or rejected them, and how many expired into the default.
Unowned or unlabeled assets
Connected sources without an owner or with labels still awaiting confirmation, which should not be widely available to AI yet.
Endpoint usage by classification
Which model endpoints received requests involving each label, as a check that private-only rules are holding.
Questions to ask any AI governance platform.
- Is a model ever involved in deciding whether a request is allowed?
- What happens to requests when the policy service is unavailable?
- Can policies be tested in CI before they reach production?
- Are agents and models distinct identities, or do they share keys?
- Where do decision logs live, and who besides us can read them?
- Can you prove which policy version applied to a past request?
- Does enforcement keep working with no connection to the vendor?
Designed to support the frameworks you report against.
Control does not certify you against any framework. It provides enforceable controls and exportable records that teams map to the requirements they own.
- Documented, versioned AI access policies
- Inventory of data sources and sensitive fields
- Inventory of approved model endpoints
- Human oversight for designated high-risk actions
- Per-request records of AI data access
- Separation between policy authors and approvers
- Change history for every policy
- Evidence that stays inside your environment
Questions buyers ask
Does Data.co Control make us compliant with HIPAA, SOC 2, or the EU AI Act?
No product can do that on its own. Control is designed to support those programs by enforcing access rules and recording evidence. Your compliance team still maps controls to requirements and owns the attestation.
We already have a model inventory and an AI acceptable-use policy. What changes?
Those documents become inputs. Approved models become the gateway's endpoint registry, and acceptable-use rules become policies that are evaluated on every request instead of relying on users to remember them.
What about AI usage that does not go through the gateway?
Control governs traffic routed through its AI gateway, MCP gateway, and connectors. Usage outside those paths, such as a browser session to a public chatbot, needs network or endpoint controls. The catalog and monitoring help show where sanctioned usage is and is not happening.
How do policy changes get approved?
Policies are YAML in a Git repository you control. Changes go through pull requests with your existing review rules and must pass their tests in CI before they deploy.
Can governance reporting run without sending data to Data.co?
Yes. The audit log, policy history, and catalog all live in your environment, and exports are produced there. The hosted account plane never receives them.
Who should own AI policies day to day?
Usually a security or risk team owns baseline rules, data owners approve exceptions for their sources, and platform engineering operates the pipeline that tests and deploys policies. Git review rules make that separation explicit.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.