For most SMEs, AI used to be an IT topic. Now it is also a legal one. The moment your business starts answering customer questions, drafting documents, or summarising files with AI, you are processing data — often personal data — and where that processing happens has become a compliance decision. The good news: the rules are knowable, and the choices that make you compliant also make you more in control.
This lesson is orientation, not legal advice. It will help you ask the right questions and understand the trade-offs. For anything binding, involve your data-protection officer or a qualified lawyer.
Sovereignty and residency: who controls the data
Two words get used a lot, and they are not the same thing.
Data residency is simply where your data physically sits — which country, which data centre. Data sovereignty is the bigger idea: who ultimately controls the data and which legal system governs it. You can have data resident in Frankfurt that is still controlled by a company subject to a foreign government's access laws. Residency is geography; sovereignty is jurisdiction plus control.
Think of it like renting a safe-deposit box. Residency is which city the bank vault is in. Sovereignty is who holds a master key and which courts can compel the bank to open your box.
Sovereignty means your data — and the processing of it — stays under your control and within a legal regime you understand. That is the real question behind "where does our AI run?"
This matters for AI because a typical cloud AI service sends your prompt (and whatever you paste into it) to a provider's servers, possibly across borders, possibly subject to laws you have never read. Sometimes that is perfectly fine. Sometimes it is a problem. Knowing the difference is the skill — and for a small or mid-sized business, it is often the difference between adopting AI with confidence and not adopting it at all.
DSGVO and cloud AI: not free, not forbidden
If your AI touches personal data — a customer name, an email, an order history, a support ticket — DSGVO (the German implementation of the GDPR) applies. Sending that data to a foreign-cloud AI service is not automatically illegal, and not automatically fine. It triggers obligations you, as the controller, are responsible for managing:
- A lawful basis. You need a legitimate reason to process the data in the first place.
- A processor agreement (AVV / DPA). The AI provider becomes your processor. You need a contract that binds them to act only on your instructions and to protect the data.
- A transfer mechanism. If the data leaves the EU — say, to a US data centre — you need a recognised safeguard (such as the EU–US Data Privacy Framework or standard contractual clauses) and, often, a transfer-impact assessment.
- Transparency and rights. People whose data you process have rights — to know, to access, to have data deleted — and you must be able to honour them.
None of this is exotic; it is the same diligence you already apply to your CRM or your payroll provider. The catch with AI is volume and surprise: staff paste sensitive material into a chat box without thinking, and suddenly customer data is in a system nobody vetted. The fix is less about banning tools and more about choosing tools where the data path is known and controllable.
The EU AI Act: risk-based, not size-based
The EU AI Act is the world's first broad AI law, and its logic is refreshingly simple: obligations scale with risk, not with company size. Every AI use falls into one of four tiers.
| Risk tier | What it covers | What it means for you | |---|---|---| | Prohibited | Social scoring, certain manipulative or biometric uses | Banned outright — don't go there | | High-risk | Annex III uses: hiring, credit, critical infrastructure, etc. | Heaviest duties — documentation, oversight, testing | | Limited | Chatbots, AI that interacts with people | Transparency: tell people they're dealing with AI | | Minimal | Spam filters, most everyday assistants | Essentially unrestricted |
Most SME uses — an internal assistant, a website agent answering product questions — sit in the limited or minimal tiers. The main duty there is honesty: make it clear when someone is talking to a machine. You are far less likely to be building a "high-risk" system than the headlines suggest, but you should still classify each use deliberately.
The dates that matter
- August 2024 — the Act entered into force.
- August 2025 — obligations for general-purpose AI (GPAI) models are already live. If you build on a foundation model, this part applies now.
- 2 August 2026 — the Act becomes fully applicable. This is the date to plan around.
- Into 2027 — some high-risk duties tied to Annex III have a longer phase-in, so a handful of obligations land later. This is a staggered tail for specific cases, not a blanket deferral of the whole Act.
In short: the AI Act is not a future problem you can park. The GPAI rules are in force today, the bulk of the Act bites on 2 August 2026, and only certain Annex III high-risk duties trail into 2027. For a deeper, SME-focused walkthrough, see the EU AI Act guide. And remember why this is worth getting right: surveys consistently find that legal uncertainty is the most-cited barrier to AI adoption among German SMEs — a majority of firms name it. Clarity is a competitive advantage.
Audit trails and governance
Both DSGVO and the AI Act share a theme: accountability. You should be able to show what your AI did. An audit trail is exactly that — a record of inputs, the system's responses, and the human decisions around them.
A good audit trail lets you answer, after the fact: What was asked? What did the system say? Where did the answer come from? Did a human review it? That record is what turns "we think it's fine" into "we can demonstrate it's fine" — the foundation of any certification or regulator conversation. It is also how you spot and fix a bad answer before it becomes a pattern, which connects directly to the human-review and correction practices from the previous module on responsible AI.
Why on-prem or EU hosting strengthens your position
Here is where architecture meets compliance. When the model and the knowledge base live on your own hardware (an appliance), in your own managed environment, or in an EU region, several hard problems get much smaller:
- The cross-border transfer question often disappears — if nothing leaves the EU, there is no international transfer to justify.
- Sovereignty is real, not contractual — you control the keys, not a clause in someone's terms.
- Audit trails stay in-house — your logs of who-asked-what are yours, kept under your jurisdiction.
Where your model and knowledge live is no longer just an IT choice. It is a compliance posture. Local or EU-region hosting keeps both data and processing under your control.
This is the heart of the sovereign design the platform is built around: one local model serving many knowledge bases, with the internal knowledge base as the trusted superset and the public agent as a governed projection of it. A human correction loop captures answers back into that knowledge base — improving accuracy while every record stays where you can account for it. Compliance stops being a bolt-on and becomes a property of how the system is shaped.
Those guarantees are bundled under one compliance umbrella we call Cloud Shield: the combination of sovereign hosting, governed projection, audit trails, and the correction loop that lets you keep AI inside your jurisdiction and demonstrate it on demand — turning DSGVO and EU AI Act obligations into defaults of the architecture rather than paperwork you chase after the fact.
In the next module we turn all of this into a practical plan — how to actually deploy AI in an SME, choosing the right deployment shape and rolling it out without drama.