Let’s say one of your teams builds an AI agent that actually works. Word gets around, and seemingly overnight, there are twenty more built by people in finance, legal, HR, and support. Most of them are useful, but when someone suddenly gets a chatbot response showing customer data they shouldn’t have access to, reality hits.
The real test of enterprise AI readiness isn’t at all whether your coworkers can confidently work with AI. Instead, it has everything to do with governance and security, global, cross-cutting policy, and privacy. Many enterprises are underprepared to face these issues: a survey from Databricks and the Economist found that “40% of respondents believed their organization’s AI governance program is insufficient.” And Microsoft’s Data Security Index reports that “only 47% of organizations across industries report they are implementing specific GenAI security controls.”
Having worked with many CIOs to develop strategies to govern their AI systems, this piece is a deep dive into the specifics of what works and what doesn’t. Keeping employees, customers and your entire organization safe must be your top priority before you even start rolling agents out.
8 layers of governance every enterprise needs #
It’s no doubt that the enthusiasm for AI is real, but so is the list of questions that bubble up a month later: Who’s allowed to publish an agent to the rest of the company? How do we track versions, and can we roll one back? Can we require SSO on every agent? What data does this have access to, and does it respect the permissions on those documents? Where do the logs live, and how quickly can we see them?
I think of enterprise AI governance as a set of layers, each answering one of the questions above. You can build them incrementally, but ideally all eight are in place before you have more agents than you can list off from memory.
Roles and groups. Whatever platform you choose, ensure that it offers granular role-based access control. At the level of abstraction higher, map groups to real departments (Legal, HR, Capture Team) and assign those groups to their own. Keep the admin count small enough to list out loud. Though this is the coarsest measure, it still bears a big responsibility down the line — according to Fortune Business Insights, “RBAC solutions help reduce unauthorized access incidents by nearly 30%, enhancing data security.” Scope. It’s extremely helpful to build out private folders with explicit allowlists, so a project, agent, or workflow isn’t merely locked to outsiders but invisible to them. Agents with access to sensitive customer data shouldn’t advertise their own existence. Change control. Those who are building AI agents should be able to place locks on so that only the owner can edit it, with admin override. Every change should land in a version history with a diff and a commit message, and rolling back should take one click so that you know exactly what was edited if an agent stops performing. According to Google’s DORA State of DevOps research, teams with strong version control and rollback practices recover from failed changes in under an hour, versus a week or more for teams without them. Publication. When a builder finalizes an agent and wants to release it to the rest of their team, depending on the use case, they should consider adding one-click SSO, a password option for external collaborators, and restrictions on which origins and which users can reach it. OWASP’s 2025 Top 10 keeps broken access control at #1, observing that every application they tested had some form of broken access control. Org-wide policy. This is the layer CIOs underuse. Require SSO on all interfaces rather than hoping. Restrict who can publish, so shipping to the company is an admin action. Create approval workflows, where a builder requests review and an admin does the publishing (similar to traditional SDLC best practices around pull requests). Allow or deny specific tools and connectors across the enterprise, so nobody connects a data source that procurement hasn’t approved yet. Lastly, vary policy by group, so only Legal can reach the legal agents. Data access. Obsidian Security’s 2025 AI Agent Security Landscape report found that 90% of deployed AI agents are over-permissioned relative to the actual scope of their assigned tasks, and separately estimates that agents are typically granted about 10 times more access than their workflows need. That’s why connections and knowledge bases deserve their own permission model. Credentials should be encrypted and owned by whoever created the connection to a given tool, app, or data lake, with sharing as an explicit decision. Here’s where it gets tricky: if a builder connects SharePoint with their own account, the agent sees what that person can see. Connect through a service account and the agent inherits the service account’s entire scope, which is usually far wider than anyone intended. The safer pattern is to check end-user access at runtime, so the person asking has to authenticate before retrieval happens and only gets what they’re already entitled to. Observability. It’s imperative to have exportable records of who ran what, when, against which model, with token counts and latency, plus per-step traces showing inputs, retrieved chunks and outputs. Give builders the ability to mask or disable logging where the data is too sensitive to retain. Then push those records out of the platform on a schedule so security’s pipeline consumes them automatically. Authentication. SSO over passwords, MFA through whatever authenticator your org already runs, and defaulting new users into the lowest-privilege role until an admin promotes them. According to Microsoft, MFA can block more than 99.2% of account compromise attacks. And SSO gives you the email address of everyone using your interfaces, which makes for an additional layer of security.
None of these are new inventions; they’re the same controls you already apply to internal software. But most organizations haven’t extended them to AI that both talks to customers and writes to the CRM.
Don’t forget about deployment #
After governance, the other half of enterprise AI readiness is deployment. Regardless of what platform you choose, there are four realistic postures:
Multi-tenant SaaS, where you share infrastructure with others and rely on tenant isolation at the database layer. Dedicated single-tenant, where the vendor operates a VPC that only you occupy. Bring-your-own-cloud, where the software runs inside your own cloud account and your data never leaves it. On-premise, where you own the infrastructure, the control plane and the data plane outright.
It’s well known that multi-tenant is available as soon as possible and updates itself continuously. Dedicated takes a couple of weeks to stand up and updates on a schedule the vendor applies. Bring-your-own-cloud runs two to four weeks and splits responsibility, with the vendor managing the application through a scoped cross-account role while your team owns networking and IAM. On-premise starts at a month or more, and after that your team applies every release itself.
My honest read? Most organizations are well served by multi-tenant, and choosing it doesn’t compromise on security or privacy. Bring-your-own-cloud and on-premise make sense when you have a data sovereignty requirement and a mature internal platform team, but they result in manual updates and slower time to value. There’s no right or wrong answer here — but it’s helpful for CIOs to understand the trade-offs between each of these common deployment methods so they can choose what fits best for their enterprise.
A readiness test you can run this week #
So, are you ready for enterprise AI? Here’s a quick self-diagnostic that I like to run with CIOs. Pick your three highest-privilege AI agents or workflows in production and try to list these attributes yourself:
Who owns each one by name. What changed in it most recently, and who approved that change. Which connectors and knowledge bases it can reach, and whose permissions those reads run under. Whether accessing it requires SSO. Where its logs are, and how long they’re retained. What happens to it if the model version it depends on is deprecated next quarter.
If most of those answers are “I’d have to ask around,” you’re not ready to scale, and that’s fine. All it means is that you have a week of policy work ahead — but you’ll thank yourself later for figuring the tough stuff out first.