"Data protection rules out AI for us." I hear this sentence in almost every first meeting with an SME, and it is not wrong. It is just too sweeping. It is true for exactly one variant of AI — the one where a chat window sends your data to a server in another country that you have no say over. And there is more than this one variant. Anyone who utters that sentence and closes the whole topic with it has not rejected AI. They have rejected a single architecture, and all the others along with it, without ever having looked at them.
The sentence has a real root. In every SME sits someone whose job is to be accountable for the company's data — design drawings, personnel files, contracts, the costing that no competitor is allowed to see. For this person, data sovereignty is not a buzzword but something they put their name to. When the management team comes back from the trade fair wanting "finally something with AI", they are the one who has to hold two things at once: the wish from above and the duty that nothing leaves the building that is not allowed to. These two things only appear to stand in each other's way.
The mix-up: AI is not the same as cloud
The error in reasoning sits in an equation nobody makes on purpose but that runs along in the background everywhere: AI equals cloud equals "data goes out". It comes from the fact that the best-known tools work exactly like that — a field in the browser, a button, and the request travels to someone else's data centre. That is the most visible form of AI, so people take it to be the only one. But the model that gives the answer and the place where it runs are two separate questions. You can run a capable language model on a server that sits in your own basement and has no connection to the outside world.
Two or three years ago this was still different. Back then a usable model needed hardware that an SME did not have in-house, and the openly available models were noticeably weaker. That has shifted. Today there are freely operable models that run on a single good graphics card and are good enough for most internal tasks — asking a question of your own documentation, summarising a contract, drafting an email. Not the top of the range for every task. But for the tasks that actually come up in an SME, often more than sufficient.
If your data is not allowed in the cloud, you still have options.
A project where exactly this sentence came up
In one of our projects, an engineering firm wanted an assistant that answers questions about their own technical documentation — around 12,000 data sheets, standards, old project reports, grown over twenty years. The requirement was clear and sound: a new employee should be able to ask "which standard did we design this to in 2019?" and get a sourced answer instead of interrupting three colleagues. Then, in the first meeting, the sentence came, almost apologetically: "Lovely, but that will not work for us. Our design data is not allowed to leave the building."
He was right — for the variant he had pictured. In his head ran an image in which 12,000 confidential documents travel to someone else's data centre so that a model there can answer questions about them. That variant genuinely would not have worked, and it was right to reject it. It just was not the only one that would have fit the requirement. We did not take the sentence as a refusal but as what it was: a very precise architecture requirement. The data stays in-house. That is not an obstacle, it is a specification — and specifications are something you can build.