Private AI for business: what it is and what it is not

A term that means everything and nothing

Private AI is one of those phrases that appears in every proposal and means something different in each. For one vendor it is an open model on their own server. For another it is a cloud service with a data processing agreement. For a third it is simply a reassuring heading above a standard product.

That is unhelpful, because the question behind it is legitimate. If an AI coworker processes your orders, invoices and customer data, you want to know where that data goes, who can see it and what happens to it. That is a good question to ask before you start.

It helps to break the term into three separate questions you can answer independently.

Question one: where is your data processed?

This is the most concretely answerable question and in practice the heaviest one. Does your data leave the EU, and if so, where to? For many European companies, and certainly in the public sector and healthcare, this is where the conversation stands or falls.

There is a difference between where a model was made and where it runs. The large model providers now offer processing within European regions, with contractual and technical safeguards. That is not the same as a model developed in Europe, and sales pitches sometimes blur the two.

With us, data is processed within the EU. That is not an option you tick but how the platform is built, and it is one of the things our ISO 27001 certification was audited against.

Question two: is anything trained on your data?

This is the fear most often voiced: will my price agreements end up at a competitor because the model learned from them? It is a fair concern, and the answer is both contractual and technical.

Under business agreements with the major model providers, nothing you send through the API is used for training. That is an explicit condition, not an implicit promise. Important detail: that applies to business access through the API, not automatically to the free consumer version of the same tool. Pasting a customer order into a free chat window falls under different terms.

• Ask for the data processing agreement and read what it says about training.
• Ask how long data is retained for logging and troubleshooting, and how you can shorten that window.
• Ask who can access those logs, and whether that is set up role-based.
• Ask what happens to your data when the engagement ends.

Question three: own model or own environment?

This is where most of the confusion sits. Some companies want an open model on their own infrastructure, so that by definition nothing leaves the building. That is possible, but it is a heavier choice than most people assume.

An own model means own hardware or rented GPU capacity, someone to run it, and responsibility for updating and securing it. On the other hand, open models are now good enough for a lot of administrative work, so it is no longer a quality sacrifice.

The question is whether your risk profile justifies it. For processing a wholesaler's purchase invoices it is usually overkill. For an organisation handling medical or judicial data it can be exactly right. The answer depends on your data, not on fashion.

What happens outside the model counts just as much

Discussions about private AI are almost always about the model, while most of the risk sits elsewhere. An agent working in your ERP has permissions in that ERP. That is a bigger security question than which model reads the text.

• Permissions: what may the agent create, change and read, and what explicitly not?
• Separation: can the agent reach administrations or customers it has no business in?
• Logging: can you see per action what was done and on what grounds?
• Human oversight: which decisions never proceed without approval?
• Certification: is all of this independently audited or only internally described?

These five points are duller than the question of which model you use, but in practice they decide whether an incident stays small or becomes large.

The model as a replaceable component

There is another practical reason not to put too much weight on the model choice: models change faster than your business process. Building your solution around one specific model builds in a dependency that can get expensive within a year.

So we treat the model as a component you swap. If a model arrives that is better, faster or cheaper, or that fits a specific data processing requirement better, we switch it out without your process changing. The connection, the rules, the memory and the logging all stay.

That also makes the private AI question easier to answer. You do not have to choose for all time up front. You choose an architecture in which that choice stays reversible.

Getting started

Do not start with which model you want, but with what data flows through the process and how sensitive it is. It often turns out the most sensitive part of the process needs no model at all, and that the requirements on one specific flow are far heavier than on the rest.

In a Quick Scan we look together at your process, your data and your requirements, and show what a fitting setup looks like. Our security page explains how the platform is built, and we share the ISO 27001 certificate on request.