Artificial Intelligence, on your own infrastructure

It means running AI models on infrastructure you control — your own data centre, or a dedicated private cloud — instead of sending your data to someone else's service.

Sovereignty means three concrete, verifiable things:

• You know which physical machine runs the model and what country it sits in.
• You know where the data you feed it is stored and who can read it.
• Nobody uses your information to train anything, because it never leaves your perimeter.

It is not a different technology. To a large extent these are the same models you already know, deployed differently. The difference is in the architecture and the contract, not in magic.

In who holds the data and what you can verify. To be fair: the enterprise plans of the major providers do contractually commit to not training on your data, and they are legitimate options. The honest argument is not "they steal your data".

The real differences are these:

• Verifiability. With a contractual promise you trust; with your own infrastructure you check.
• Data location. With a global provider data may be processed outside the EEA under safeguards; on-premise it does not leave.
• Predictable cost. Fixed infrastructure instead of metered billing that scales without warning.
• Continuity. No price changes, no models retired, no usage terms rewritten mid-project.

If your use case does not touch sensitive information and the volume is low, a cloud service is probably the better deal. We will say so.

It depends on the task, and here is the honest answer: for most business uses, yes; for the most demanding ones, not yet.

Today's open models handle document data extraction, classification, summarisation, drafting and question answering over internal documentation perfectly well. On complex multi-step reasoning, hard programming or long agentic tasks, frontier commercial models are still ahead.

The useful question is not which is better in the abstract but which is good enough for your specific task — and that is not settled by reading benchmarks. It is measured with your own documents and your own definition of a correct answer. That is exactly what the proof of concept is for.

The variable that matters is GPU memory (VRAM), not raw compute. The model has to fit entirely in memory to run fast.

As an order of magnitude, quantised to 4 bits:

• A 7–8 billion parameter model fits in about 6 GB of VRAM.
• A 30–35 billion one, around 20 GB.
• A 70 billion one, from 40 GB upwards.

On top of that you need memory for each concurrent conversation, which is what usually gets forgotten when sizing: an assistant for five people is not the same as one for five hundred.

And no, you do not always have to buy. You can start with rented dedicated GPU in European infrastructure, measure real usage for a few months, and decide with data in hand rather than a forecast.

They are two different cost structures: an API is variable and grows with usage; your own infrastructure is fixed and does not care how hard you push it.

Hence the rule of thumb: owning infrastructure pays off when the GPU is busy. A GPU idle ninety per cent of the time is expensive however you look at it. An assistant used daily by a hundred people is a different story.

Before buying anything, the right exercise is to measure one real month of volume — how many queries, of what size — and compare that variable cost against the fixed cost of the equivalent hardware. We run that calculation in the initial assessment, and if the answer says the API suits you better, we will tell you.

Two frameworks worth keeping apart.

GDPR. If personal data goes into the prompts, the AI provider acts as a processor and the Article 28 contract is required. If it also processes data outside the European Economic Area, you need safeguards for the transfer. Keeping the model inside your own perimeter simplifies the analysis, because there is neither a transfer nor an external processor.

EU AI Act (Regulation 2024/1689). It imposes obligations according to the risk level of the use, phased in over time. Most internal business uses — document assistants, classification, drafting — fall under minimal or limited risk, where the main requirement is transparency. Uses affecting people, such as recruitment or credit scoring, do fall into stricter categories.

This is general orientation, not legal advice: the specific classification depends on your case.

Yes, and the key is a design principle: the assistant must never have more permissions than the person asking.

The common mistake is wiring the model in with an administrator account "so it can see everything". That turns the assistant into a way for anyone to read what they should not, without breaking any security at all — simply by asking.

The correct architecture inherits the user's identity:

• Every query runs with the permissions of whoever asked.
• The search index records what each profile may access, and filters before answering.
• Every action is logged: who asked what, and which data was used to answer.

On Microsoft Dynamics — AX, NAV or 365 — this is familiar ground for us: we have been operating those platforms for years.

It will, sooner or later. Anyone who tells you otherwise is selling you something. What you can do is make sure that when it happens, it shows.

• Always cite the source. If every answer links the document and paragraph it came from, checking it takes ten seconds.
• Narrow the scope. An assistant that only answers about your documentation is wrong far less often than one with opinions about everything.
• Human review where there are consequences. Not needed to draft a text; needed to decide about a person or sign off a number.
• Measure continuously. A set of questions with known answers, run on every update, catches regressions before your users do.

An assistant that cites its sources is a tool. One that answers without showing where it got it from is a liability.