The AI they make you use goes outside your perimeter. Ours doesn't.

Imagine the scene. A vendor shows you their new cloud management platform, and then comes the moment needed to close the sale: they open the assistant, type in natural language, "create a test environment for me with three machines and a database," and within seconds the environment appears. Applause. It's truly remarkable.

Then someone at the back of the room, usually the one who will have to sign, asks the right question: where does that model go?

In most cases, the answer, translated from business jargon, is this: the model runs somewhere outside. When you write your request, the description of your environment—how many machines you have, what they're called, how they're configured, sometimes what they contain—leaves your infrastructure, traverses the network, and reaches an AI service that isn't yours, often not even European. It comes back with a plan, and the environment is created.

For many companies, this is fine. For a growing number, however, this is exactly the point where the demo stops being good news.

Because "where the model turns" is not a technical detail

There's a temptation to treat this question as a nitpicking question for insiders. It's not. It's the point where a product choice becomes a risky one, and those who must answer for that risk know it.

When your infrastructure description goes beyond the scope, three things emerge at once, and it's worth separating them because they carry different weight.

A map of your structure emerges. Often, it's not user data, but something that in certain contexts is as important as data itself: the topology, the names of environments, the size of resources, the structure of who accesses what. It's the information someone needs to understand where you're vulnerable.

Control over where that information ends up is lost. An external service has its own terms, jurisdiction, and retention policy. You can read them, you can trust them, but you don't control them. And if they change, you find out later.

And above all, it gives us the ability to know with certainty where your data is located. Which is precisely what a public service operator, a public administration, or a company in a regulated sector is asked to guarantee—not to hope, but to guarantee.

For a private company without any particular constraints, all this is a cost-benefit analysis that often ends in favor of convenience. For anyone who meets data sovereignty requirements, it's not an evaluation. It's a wall.

The crossroads that the market puts before you

The result is that, in Europe, those who want to bring intelligent automation to their infrastructure almost always find themselves faced with two doors, and neither is the right one.

Behind the first door lies renunciation. You keep AI out, you stick to manual processes, you accept that each environment you create requires days of specialized work and that each complex fault diagnosis requires hours of human effort. You are sovereign, but you are slow, and slowness in infrastructure has a silently accumulating cost.

Behind the second door lies surrender. You take the intelligent automation the market offers, you gain speed, and you accept that part of your perimeter is no longer truly yours. You're fast, but you've signed up to a dependency that, the day an auditor asks you to release, you don't know how to untie.

Most commercial cloud management platforms, including some very good ones, make you choose between these two doors—because that's how they're built. AI is an external service they integrate, not a component that lives within your infrastructure. It's a reasonable choice from their perspective: integrating a third-party API costs a fraction of what it costs to bring the models inside the perimeter and keep them there. But the cost they save is paid by you, in the form of that dependency.

We built our automation because we were convinced that a third door existed. And that it was worth the effort to open.

What does "inside the perimeter" actually mean?

The third door is an AI that operates entirely within the organization, on an entirely open-source technology chain. It sounds like a slogan, so it's worth breaking it down into the pieces that make it real, because it's in those pieces that the difference lies.

The model runs on-premise. Processing occurs within the client's infrastructure. The description of the environment, requests, and operational context do not cross the network to an external service, simply because the external service does not exist. It's not "the data is encrypted in transit to a trusted provider": it's just that there is no transit.

The chain is open source and reversible. There's no proprietary, closed component at the heart of the automation, whose functions you don't know and which you can't replace. The entire chain is inspectable and, the day you want to change, replaceable. There's no exit to negotiate, because there's no lock.

The model proposes, the automation engine executes. This is the underlying principle, and it's what makes it defensible in an audit. AI never directly touches the infrastructure. It produces a plan—the sequence of operations it intends to perform—and that plan is presented for review and approval. Only then does a traditional automation engine, based on Ansible and AWX with versioned playbooks in the organization's repository, execute it in a traceable manner. No resource is created without explicit approval.

This last point deserves emphasis, because it's where on-premise AI stops being just a matter of sovereignty and becomes a matter of operational reliability. An automation that suggests and awaits confirmation is an automation you can leave in the hands of non-specialists, without a misunderstanding turning into a production error. And every operation, being executed by the automation engine and not the model, leaves a complete record: who requested what, what was proposed, what was approved, what was done. Not as an afterthought, but as a natural consequence of how it's built.

The legislation is going in this direction, not the other

It's worth looking at where the European picture is headed, because it helps us understand whether this is a purist obsession or a clear direction.

The AI Act, the world's first comprehensive regulation on artificial intelligence, has been in general application since August 2, 2026. The most stringent requirements for high-risk systems have been postponed—most will be implemented by the end of 2027—but the direction is already clear, and it's the same one infrastructure managers know from the GDPR and NIS2 : traceability, explainability, human oversight, and the ability to demonstrate what a system does and why.

Automation where the model proposes and a traced engine executes, within a perimeter that doesn't leave, isn't a way to circumvent those requirements. It's the most direct way to satisfy them—because traceability isn't a layer added on top, it's the very functioning of the system. Those who have chosen the second door, AI-as-an-external-service, will have to chase those requirements. Those who have built within the perimeter already have them in place.

It's not a renunciation of power

There's a genuine objection to all this, and it needs to be addressed rather than sidestepped: won't a model running inside my perimeter be less powerful than the massive one running in a hyperscaler's data centers?

The answer is that it depends on what you ask it to do, and for the work we're discussing, the question is less crucial than it seems. Here, the model doesn't have to write poetry or reason about everything that exists: it must understand a specific operational request—create an environment, add space, open a door, diagnose a discrepancy—and translate it into a plan based on a catalog of known operations. It's a specialized task, and for a specialized task, a model that runs in-house, aware of the context and operating in a defined domain, is more than sufficient. In this scenario, you wouldn't even use the raw power of a huge generalist model.

And there's a flipside that matters: the in-house model learns your environment without your environment ever leaving the house. The anomalies it recognizes are yours; the normal behavior it learns is that of your infrastructure. It's not a generic model to which you constantly explain who you are. It's a model that lives where the data is.

Because for us it is not a selling point

We've discussed elsewhere why infrastructure you can't leave behind isn't a service . On-premise AI is the same idea, brought to the newest and most sensitive component of the stack.

When we design infrastructure for a client, our job isn't to make them dependent on us. It's to enable them to govern what they have, with the people they have, and be able to change their minds when needed. Intelligent automation that exists within their perimeter, on technologies they can inspect and replace, is consistent with that work. Automation that forces them to expose their infrastructure to an external service in order to use it, is not—it would be the same dependency we spend our time dismantling, re-entering through the window in the guise of convenience.

It's the difference between a supplier and a partner, expressed in the most concrete terms possible. A supplier sells you the functionality and doesn't worry about what that functionality forces you to concede. A partner starts with what you can afford to concede and builds the functionality within that boundary.

AI inside the perimeter isn't the version with an extra constraint. It's the version without the constraint that counts.

Shall we talk about it?

If you're considering how to bring automation and intelligent analytics to your infrastructure without having to take it out of your control, we can show you how ours works—in real environments, with the model running inside the perimeter—and openly discuss what's already in place and what's not.

→ Discover Epic Edge Platform → Talk to us about your infrastructure