TL;DR:
Almost every AI governance article you will read describes the same thing: appoint an owner, write an acceptable-use policy, inventory your AI systems, assess risk, map to a framework, review periodically. That advice is correct and it is where every program should start.
It is also where most programs stop, and the gap that leaves is specific. You end up with an approved-tools list nobody can verify, a data-handling policy nobody can enforce at the moment data is typed into a prompt, and an agent strategy with no record of what the agents retrieved. This guide covers the structural part first and then the operational part that usually goes missing.
AI governance is the operating model for how AI gets adopted and used inside an organization: which systems are approved, what data they may process, who is accountable for outcomes, and how all of that is monitored and evidenced over time.
It splits into two halves that get conflated constantly, and the distinction is the single most useful thing to hold onto.
A program with only the first half passes a document review and fails the first real question. A program with only the second half has telemetry nobody has mapped to an obligation. You need both, and most companies are over-invested in one and have nothing in the other.
Strip away the frameworks for a moment and AI governance reduces to three questions a board, an auditor or a customer's security team will actually ask. Who is using AI here. What data is going into it. And what are the agents doing on our behalf.
Notice what these have in common. None of them can be answered by reading a policy, filling in a questionnaire, or pulling configuration from a cloud account. Each one requires seeing inside something: a browser session, a prompt, a tool response. That is a data-layer capability, and it is the part of AI governance that compliance platforms structurally cannot reach.
Every AI governance framework opens with an inventory of AI systems. The assumption behind that requirement is that you can produce one. In practice most organizations cannot, because AI adoption does not come through procurement. It arrives as a browser tab, a free tier, a desktop app, a VS Code extension, or a coding agent somebody installed on a Tuesday.
This is the shadow AI problem, and it is why network-level inventories miss most of it. Discovery has to happen where the usage happens, which means the browser and the endpoint. Strac covers both, and the output is the thing every framework asks for first: a list of the AI tools and agents actually in use, by person and by team, sanctioned or not.
The gap between that list and your approved-tools policy is usually the most useful single artifact a new AI governance program produces. It reframes the conversation from writing rules to enforcing the ones you already wrote.
Once you know which tools are in use, the next question is what is going into them. This is where governance becomes a data-security problem rather than a policy problem, because the risk is not that someone used an AI tool. It is that they pasted a customer record into it.
Strac's classifier covers 255 data element types across PII, PHI, PCI and secrets, including 160 national ID formats, and it inspects more than prompt text: uploaded files, query results, command output, images via OCR and PDFs. That breadth matters because the typed prompt is rarely where the worst exposure happens. It is the screenshot, the CSV export, the scanned onboarding form.
The governance output is a record of which sensitive data types were detected on the way into which AI tools, and what the policy did about it. See AI DLP for how the enforcement works.
This layer did not exist two years ago and it is now the fastest-moving risk in the category. An employee using a chat assistant leaks whatever they paste. An agent leaks whatever it decides to read, which is a far larger and less predictable surface.
Agent governance has two directions and both need controls.
Inbound is what an agent is allowed to pull from your systems, governed through MCP DLP and an MCP gateway. Access control alone is not enough here: an agent calling an approved tool can still return ten thousand customer records in a single response.
Outbound is what reaches the model provider once the agent has that data, governed through the AI Gateway, which substitutes sensitive values for tokens before the request leaves and restores them afterwards so the agent still completes its work.
Together these produce the record an auditor will eventually ask for: which agent called which tool, what came back, what was redacted, and what the provider actually received.
The output is telemetry your compliance program can draw on, so the control you mapped has an operating record behind it rather than only an assertion that it exists. Stated plainly, because the category oversells this: none of these artifacts are a compliance program on their own. They are inputs. The compliance platform states the control; the data layer shows it operated.
The practices that separate programs that hold up from programs that produce a binder nobody reads.
The ownership question derails more programs than the technical one. AI governance lands across security, legal, privacy, data and the engineering teams actually shipping AI features, and when it is assigned to all of them it belongs to none.
What works in practice is a single accountable owner with a cross-functional working group, rather than a committee. In most companies under a thousand people that owner is the security leader, because the enforcement surfaces (endpoint, browser, data) already report there and the alternative is a policy function with no levers. Legal owns the obligations, privacy owns the data-subject angle, engineering owns the systems. One person owns whether the program is real.
The second structural decision is where AI governance sits relative to your existing security program. Running it as a separate parallel track duplicates vendor review, evidence collection and control mapping. Folding it into the program you already have is faster and gives you the reuse that makes it sustainable.
If you handle PHI, cardholder data or financial records, two things change. The first is that the data-handling layer stops being a best practice and becomes the thing a regulator or auditor will examine directly. The second is that your customers start asking, which turns governance into a revenue question rather than a risk one.
Healthcare organizations face the sharpest version: a clinician pasting notes into a general AI tool is a disclosure, and no policy document prevents it at the moment it happens. Financial services teams tend to hit the agent problem first, because analysts adopt coding agents against production data faster than governance catches up.
The practical consequence is that discovery and ingress controls move to the front of the roadmap. You need to be able to say which AI tools touched regulated data, and prove it, before you need a certificate.
Three reference points matter for most organizations, and they do different jobs.
Whichever you adopt, the Measure and Manage functions are where programs stall, because those are the parts that need live data rather than documents. Our AI governance framework guide goes deeper on structure.
Vanta, Drata and the rest of the compliance-automation category are good at what they do: control mapping, policy management, evidence collection from infrastructure, and auditor workflow. If you need SOC 2 or ISO 27001 run efficiently, they earn their place.
The limit is architectural, and it is narrowing at one edge. Both vendors have started shipping agent-scoped telemetry: Vanta inventories agents across laptops, code and vendor platforms, and Drata's AI Agent Governance, in limited availability for Anthropic agents, runs a device sensor and a policy proxy in front of agent tool calls. What neither does is inspect content. They can tell you an agent exists, who owns it and what it is permitted to reach. They cannot tell you that the file one of your analysts pasted into a browser tab carried 400 cardholder records, because they do not sit in the path of a browser session, a prompt or a file upload. Layer one and layer two are still unanswered, and layer three is answered for agent identity rather than agent payload.
In practice the mature pattern is both: a compliance platform for the framework and the auditor, and a data layer underneath producing the telemetry the AI-specific controls actually need. Strac Comply runs the first on top of the second, which is the part worth comparing.
See your own three layers. Strac Comply starts at $4,995 all in, with no sales call and a 14-day trial, and it sits alongside the same DSPM and DLP that generate the telemetry above. Book a demo or read how the compliance automation side fits together.
Strac discovering and protecting sensitive data across SaaS, cloud, GenAI, browser and endpoint. This is the telemetry the three AI governance layers run on.
A sequence that works, in the order that produces useful answers fastest.
Related reading: AI agent security, agentic AI security, AI governance tools, writing an AI governance policy, a 90-day implementation playbook, and usage governance versus model governance.
AI governance is the set of policies, controls and evidence an organization uses to manage how AI is adopted and used: which systems are approved, what data they may process, who is accountable, and how all of that is monitored and proven over time. In practice it has two halves that are often confused. The documentation half covers policies, risk assessments and framework controls. The operational half covers what is actually happening right now, meaning which tools are in use, what data is entering them, and what agents are doing. Most programs are strong on the first half and blind on the second.
Compliance is conformance to a specific standard, so ISO 42001, the EU AI Act or SOC 2 as it touches AI systems. Governance is the broader operating model that compliance draws on: accountability, approved use, data handling and monitoring. You can be compliant on paper and ungoverned in practice, which is the usual failure. It shows up the first time someone asks which AI tools the company is using and nobody can produce a list.
For most companies the practical answer is NIST AI RMF to structure the program and ISO 42001 if you need a certifiable AI management system for customers or procurement. The EU AI Act matters if you place systems on the EU market or your users are there, and it is obligation-based rather than something you certify against. Pick the one your buyers ask for, then make sure whichever you choose is backed by real telemetry rather than a document set.
Discovery has to happen where the usage happens, which is the browser and the endpoint. People reach AI tools through a browser tab, a desktop app or a coding agent on a laptop, so network-level inventories miss most of it. Strac discovers AI usage across browser and endpoint, which is what turns an approved-tools policy into an enforceable one and gives you the inventory that every AI governance framework starts by asking for.
They do the documentation half well: policies, control mapping, evidence collection from infrastructure and questionnaire workflow, and both now ship an AI agent registry. What they cannot do is see inside the usage. Neither inspects the contents of a prompt, a file upload or an agent's response for regulated data, which is the part the AI-specific controls actually depend on. Those answers come from DLP and discovery, which is why most mature programs end up running both.
Yes, and that is the most common starting point. Two sanctioned tools is a governance scope, not an absence of one: you still need to know who is using them, what data is going in, whether any of it is regulated, and what your contractual retention position is. It is also rarely only two. Once you run discovery, most companies find a long tail of AI tools nobody registered, which is the gap between the policy and the reality.
An auditor wants to see that the control exists, operates, and has operated consistently. For AI that usually means an inventory of AI systems in use, a record of what data classes they process, proof that sensitive data is controlled on the way in, approval records for high-risk uses, and logs showing the controls fired. The inventory and the data-handling records are where most programs come up short, because those require inspecting real traffic rather than describing intent.
“Don’t just alert on problems, fix them.”
Scott Roberts, Chief Information Security Officer, UiPath
.webp)
.avif){kind=icon}
.gif)
.webp)
