Sometimes you hear a sentence that sums everything up perfectly. Recently, someone from a large company told us about their new objective for the year: “We need to do something with AI.” Not a concrete problem to solve, no measurable target. Just something involving AI.

Right now, pilot projects are appearing everywhere. New assistants are being tested, teams are experimenting with the latest tools, and at first much of it looks impressive. Then the inevitable question appears: should the AI actually have access to this data?

From that moment on, the discussion is no longer about the model itself. Instead, issues begin to surface that have existed unresolved in many companies for years. Data is spread across different systems. Permissions have evolved over time rather than being designed properly from the start. Some information may be shared internally, some may not. Business units often test new AI tools faster than governance and IT can realistically keep up with, and suddenly questions arise that nobody had properly considered before.

Who is allowed to see what, and who carries the responsibility?

Who should have access to which information? Which data is allowed to leave the company? How do you prevent an agent from combining content that should never appear together in the first place? Once these questions appear, the issue of accountability follows almost automatically.

These are not purely IT questions. They are organisational questions. That is precisely why architecture suddenly becomes more important than the AI itself.

MCP provides access, but it does not solve everything

At the moment, there is a great deal of discussion around MCP, the Model Context Protocol. Put simply, MCP creates a standardised way for AI systems to access company data and applications without building a separate integration for every possible combination of model and system. That is useful, but it still does not address the real problem. An MCP server mainly controls what a model is allowed to access, not what happens to the information afterwards.

Anyone sending sensitive data to external models ultimately has to trust what the provider does with that information. Companies unwilling to hand over that level of trust usually end up with two options: self hosted models running inside their own infrastructure, or private cloud deployments with providers such as Microsoft Azure or Amazon Web Services where the data never leaves the company environment. In both cases, the organisation keeps control of both the data and the models without necessarily having to operate physical servers itself.

Start small, grow in a controlled way

Particularly when companies begin working with locally controlled models, whether self hosted or deployed in a private cloud, one approach has repeatedly proven sensible: small specialised agents with clearly defined responsibilities instead of one large universal agent that tries to do everything.

One agent analyses support tickets, another prepares forecast data, a third supports knowledge access for specific roles. It may sound less spectacular, but in day to day operations it is far easier to control. Permissions remain traceable and the need to know principle can be implemented properly. Later on, these specialised agents may evolve into a larger overarching system, but that usually comes as a second step.

The structure of the MCP server itself also matters enormously. A well designed MCP server should not behave like a simple relay forwarding raw API requests into a model. Instead, it deliberately defines what a model is allowed to do rather than exposing everything the underlying system could technically provide. Inputs are validated, permissions are checked and internal structures remain hidden. That is the difference between AI operating under control inside a company and AI wandering unchecked through internal systems.

At Datalizard, we have spent more than twenty years working at the intersection of data, processes and operational reality. Years ago, the focus was mainly integration and data quality. Today, the same principles shape how we approach MCP architectures. In the end, even the most impressive model becomes useless if a company does not properly control its own data.

​Lizard Learning:

The introduction of agentic AI rarely begins with one large universal agent. Small specialised agents with clearly defined data access are easier to control and far more realistic in day to day operations. MCP governs access, but what an agent does with the data afterwards sits outside the protocol itself. Companies that genuinely want to retain that level of control need locally controlled models, whether self hosted or deployed in a private cloud.