Author: Alexander Ivanyuk, Senior Director, Technology
Generative AI in business is no longer just one chatbot in one browser tab. In many environments, it is already a mix of web-based AI apps, built-in assistants inside larger platforms, internal agents created for specific workflows and model context protocol (MCP)-connected tools that let AI reach documents, services and business systems beyond the model itself. That changes the conversation completely. The issue is no longer only whether people are using AI. The real issue is how to keep that growing AI estate under control.
The market is already showing how wide that gap has become. A 2025 ISACA survey found that 83% of IT and business professionals in Europe believed employees in their organization were already using AI, while only 31% said their organization had a formal, comprehensive AI policy. A 2026 KPMG survey found that 32% of organizations were already deploying and scaling AI agents, and another 27% were coordinating multiple agents across the business. Those numbers tell a simple story: AI is moving into normal work faster than governance is being built around it.
That is exactly why GenAI management matters. In plain language, it means having one place to decide which AI is approved, who can use it, what it can connect to, what it is allowed to do and how all of that is monitored over time. Without that, every new AI app, every internal agent and every new MCP connection becomes another exception to manage manually.
Why this problem is getting more complicated
A lot of organizations still talk about AI as if it were one category of tool. But that is not how it behaves in the real world anymore.
An AI app is one thing. It may help a user draft a reply, summarize a document or search for information more quickly. An agent is already more powerful. It can move through several steps, use tools, follow a workflow and sometimes act with limited independence. The real issue is not one specific protocol or integration method. The issue is the combination of LLMs, tool use, workflows and permissions. Once an AI system can interpret a request, choose a tool, access business data and take the next step in a workflow, the company is not only managing answers anymore. It is managing access and actions.
MCP makes this picture more important because it standardizes how AI systems connect to tools and data. That can be very useful: standardization can make integrations easier, more repeatable and easier to govern. But it also accelerates the need for clear policy. If AI-connected tools become easier to add, the business needs a stronger way to decide which tools are trusted, who can use them, what data they can reach and whether they are limited to read-only tasks or allowed to perform write-capable actions.
That is where many governance models break down. A team may approve an AI app for research, but nobody checks whether it later gets access to shared files. Another team may build an internal support agent, but nobody clearly defines what systems it may call or what actions it may take. A third team may connect AI to business tools through MCP or another integration method, but no one sets clear rules for trusted connections, read-only access, write-capable actions or human review. None of those decisions look dramatic on their own. Together, they create a messy environment where AI keeps expanding while control stays fragmented.
This is why central policy matters so much now. It brings all of those decisions back into one operating model. Instead of handling AI apps, agents, tool connections and MCP servers as separate exceptions, the business needs one layer that answers the same core questions every time: Why should it be approved? Who can use it? What can it see? What can it do? What gets logged? What needs review?
Apps, agents and MCP should not be governed the same way
One of the biggest mistakes companies make is treating these three things as if they were basically the same.
AI apps are usually the easiest layer to govern. The questions are familiar: which apps are allowed, which users or roles may access them, do they use managed identity, are file uploads allowed, and is there is enough visibility into usage?
Agents raise the stakes because they introduce more workflow logic and more operational reach. An agent may search knowledge, chain together several tasks, use connectors or take the next step in a process instead of only suggesting one. That means governance has to go beyond simple app approval. It has to cover publishing, ownership, tool use, action scope and the level of autonomy the system is allowed to have.
MCP servers make governance more technical again. Once AI can connect to external tools through MCP, the main question is not only whether the AI assistant itself is allowed. The bigger question is whether the tools behind it are trusted, what data they expose and whether they are limited to reading information or allowed to change it. That is where weak governance can quietly turn into real business risk.
A simple way to explain this to customers is that approval is no longer one decision. Approving an AI app is one decision. Approving the actions behind that app is another. Approving the data it can reach is another. Approving tool access through MCP is another again. If all of that is handled loosely, AI use may look controlled on the surface while still expanding in ways the organization did not really mean to allow.
What central policy should actually do
Good GenAI management does not need to sound complicated. It just needs to be consistent. A central policy layer should define which AI apps, agents, and MCP servers are approved, restricted or not allowed. It should define who may use them and through which roles or identities. It should define what they are allowed to access, including connected data sources and tools. It should define what they are allowed to do, especially once the discussion moves from read-only retrieval into write-capable actions. And it should define what gets logged, reported, reviewed and updated over time.
That is the real difference between basic AI adoption and governed AI adoption. In a weak model, people use tools and hope nothing goes wrong. In a strong model, the organization has a clear way to say what is enabled, what is limited, what is blocked, and what is still under review.
That is also why this topic matters so much for MSPs. Without one control layer, every customer request becomes a separate mini project. One customer wants a support assistant, another wants AI tied to internal documentation, another wants an agent connected to ticketing or CRM, and another starts experimenting with MCP-based tools. If each one of those decisions is handled manually, governance quickly becomes slow, inconsistent and difficult to scale across tenants.
For SMD customers, the challenge is similar, just with fewer people and less time. They do not need a huge governance program, but they do need something better than scattered manual decisions and default settings nobody has properly reviewed.
How we approach this at Acronis
At Acronis, we built this into a familiar management model instead of treating it as a separate side process. GenAI Protection can be enabled through a management plan assigned to managed devices, and that same management layer is used to configure usage monitoring, data loss prevention and prompt injection protection. The goal is simple: govern GenAI applications, agents and MCP servers through centralized policies, instead of leaving each new AI capability to be handled separately.
Acronis Data Loss Prevention can be configured either to detect sensitive data being sent to AI applications or to block it, record the event and notify the user. Prompt injection protection can also be configured either to detect harmful prompts or to block them, log the details and notify the end user. So these are not just visibility features. They can move from awareness into enforcement when the customer is ready for that step.
Usage monitoring is another key part of this story. When it is enabled, partners can see additional monitoring dashboard widgets and use a GenAI Protection report available at both partner and customer level. That matters in multitenant environments, where governance needs to work across customer environments rather than inside one isolated deployment.
Our direction is broader than just one control, too. The current scope already covers usage monitoring, DLP, prompt injection protection and centralized GenAI management, while the roadmap extends further into NLP-based prompt analysis, MCP server protection, usage-based denial-of-wallet protection, and control at the network proxy level.
The bigger point
The point of GenAI management is not to slow AI down. It is to stop AI growth from turning into a collection of blind spots.
That is the real change happening in this market. Governance is no longer only about saying yes or no to AI. It is about deciding what is enabled, what is approved, what can connect, what can act, what gets logged and what gets reviewed later. Businesses that get this right will not be the ones that simply enable AI fastest. They will be the ones that can manage it clearly, repeatably and at scale.
For MSPs, that means having one workable model across customers instead of a long list of exceptions. For small and medium deployments (SMDs), it means being able to move forward with AI without losing track of permissions, boundaries and accountability. And for us, that is exactly why central policy sits at the heart of GenAI management.
Written by
About Acronis
Acronis is a leader in AI-native cyber protection, unifying data protection, cybersecurity, IT operations and hybrid infrastructure to deliver business continuity, security and compliance with less cost and complexity. More than 21,000 service providers trust Acronis to protect over 750,000 businesses in 150 countries. Acronis is headquartered in Schaffhausen, Switzerland.
