When you ask enterprises about the important issues of application hosting, one of the top items on their list is always governance. Data security and sovereignty are critical to businesses, and that truth impacts everything about IT and networking from project conception to deployment and use. Of 477 enterprises who offered me spontaneous views on governance, 463 said that they had an audit or compliance department dedicated to the topic. Every one said that some project plans were impacted by governance concerns, and 428 said that they’d had to intervene in a running application to deal with governance concerns.
The relationship between “governance” and “security” is complicated. In theory, governance is about assigning responsibility and setting policy, and security is the processes, tools, mechanisms, that apply governance decisions. Most enterprises say that they use governance to set policies but that these policies are handed off to IT and networking professionals to implement, with governance teams then reviewing/auditing the outcomes. What most of us think of as “security” deals with hacking in some form, and in truth governance policies in this particular area tend to be pretty general (“We tell IT and netops people, ‘don’t get hacked’”). The major parts of governance efforts then tend to be focused on complying with various regulations and requirements set by vertical-specific bodies like TJC for healthcare, and at formulating and enforcing a company’s own data governance and sovereignty rules.
Data governance and sovereignty deals not with hacking but with rights and protections against compromises of confidentiality or jurisdiction that occur not from malware or malefactors, but from inadvertent exposure. This sort of governance has exploded in the last decade, because of cloud computing and because of different regulations applied to data and business practices in different market areas.
From a governance perspective, AI is both identical and very different. It’s identical in the sense that governance policies regarding data are the same regardless of the nature of the way the subject data is used or by what means it’s processed. Different in that AI broadens the pathways to breach governance policies, and it’s this same/different dichotomy that worries enterprises.
Every enterprise has policies on where data can be stored, based on sovereignty issues (political) and based on data security concerns. This is one reason why “everything moves to the cloud” was never realistic. When applications are being built (or bought), part of governance is to establish rules to protect data privacy, and enterprises tell me that the same thing is true when application hosting strategies favor some use of the cloud. The question of how a cloud component accesses data is almost always a specific policy these days, though in the early stages of cloud adoption that was not true.
The problem with AI, enterprises say, is that it’s not always easy to review how data exposure is managed. This is due in part to how AI uses data, and in part because IT professionals and project procedures aren’t applied to all AI usage.
Where is your AI model running? If it accesses company data via RAG or MCP, what data does it access? In multi-agent workflows, what agents are local and what are cloud-hosted, and what data is passed between them? The great majority of AI consumed these days is consumed as a service, hosted by one of the AI giants, by workers who are not IT professionals. They’d have little or no idea how to answer these questions, and a similar level of awareness as to why the answers are important.
When your model runs off-premises you have two issues, enterprises say. First, anything that your model accesses via RAG or MCP is also pulled off-prem to where it’s hosted. So is anything included in a prompt. That, at the very least, means that there should be a compliance review. Second, your AI provider may use the data for training, which would be potentially much worse, and that surely means that the policies of the provider need to be researched. The review, in either case, has to identify any kinds of data that cannot be used with the AI tool, and set up procedures to educate the users of AI in the policies you’ve set.
The use of AI services by non-IT people is a particular problem, because enterprises say that they’re not aware of all such uses of AI. None of the companies believed that they could identify everyone who used AI, and the largest reason was that most AI use by workers is for free services. Next on the list is the fact that people can always buy AI on their own, and organizations can expense AI services without CFO approval, up to a specified limit. While about a third of enterprises say that they have policies on reporting these expensed AI services, so they can be reviewed for policy compliance, most say this is probably not effective. Seven enterprises noted horror stories on public AI usage by line organizations, including ones where sales data and pricing data were exported to a public model suspected of using the data for training.
Another problem with data governance lies indirectly with IT/AI professionals. End user organizations are not normally able to use things like RAG or MCP, so the problems they create are most often with prompts. However, some enterprises say that when an AI agent is augmented with RAG/MCP, the controls on changes made to the data interface aren’t always monitored, nor is the data dependency of an agent reviewed if the agent is moved from private hosting to public. That means that governance fails. This problem was noted by almost a fifth of enterprises, but the higher incidence is more likely to be due to the fact that the IT involvement makes it easier to catch this problem than situations where data governance fails for reasons tied purely to line organizations’ use of AI.
What recommendations does this group have? First, they say that it’s important to manage MCP use, and not just by policy. They point out that an MCP server is a link between the model and “tools” that provide data access, so they say you should control the scope of data a given tool can access to control data delivery, and also control the way tools are assigned to an MCP server. Put tools that could compromise governance if misused in a server by themselves. Second, they say that you should never let an MCP tool run so as to cross the cloud/data-center boundary unless the tool is identified as suitable.
Problems with AI governance aren’t really all that different from problems with data governance overall, and cloud governance in particular. If you take care, enterprise experts say, you can keep things under control for formal exposure via things like RAG, MCP, or A2A, but having critical data exposed via prompts to public models is a risk that can be alleviated only by careful policy attention and worker education. That’s always a good way to start a governance project anyway.
