Every few weeks someone tells me their AI setup is fine because they "use a compliant model," or because "it runs in Europe," or because "the vendor is GDPR-certified." I understand the instinct — you want one box to tick and be done. But it's the wrong shape of answer, and believing it is how SMEs walk into problems they think they've already solved.

Here's the uncomfortable core: there is no such thing as a compliant model. Compliance isn't a property a model has. It's a property of what you do with it — which data, for what purpose, affecting whom, with what oversight. The same model can be perfectly fine for one task and flatly unlawful for another. The model didn't change. The activity did.

Engineer, not lawyer

I build the tooling that enforces these rules; I don't give legal advice, and neither does this post. Everything below is the practitioner's mental model — the shape you need before you talk to counsel, so that conversation is short and productive. For anything going to production with real personal data, get specialist Swiss/EU legal review. That's not a disclaimer reflex; the classification questions here genuinely turn on facts a lawyer needs to see.

Why the model-name question is a trap

Both regimes that matter for a Swiss or German SME — the EU AI Act and GDPR, and Switzerland's revised FADP — are built around use, not product.

The AI Act sorts systems by risk tier according to their intended purpose. The same underlying model, wired into a CV-screening flow that decides who gets an interview, lands in a heavily regulated tier; wired into a tool that drafts your marketing copy, it barely registers. Nothing about the model is different. The obligations are worlds apart, because the activity is. Ask "is this model allowed?" and you've asked a question the law doesn't answer. Ask "is this use allowed, and under what conditions?" and now you're on the actual map.

GDPR and the FADP do the same thing from the data side: they don't care what brand of model touched the personal data, they care whether the processing had a lawful basis, was proportionate, was transparent to the person, and can be accounted for. "It's a European model" answers none of those.

The order the questions actually go in

The setup that survives contact with a regulator or a serious client runs as a pipeline, and the order is not negotiable — each step constrains the next:

  • 1. Activity and purpose. What is this AI actually for? Draft text? Summarise tickets? Rank job applicants? Approve or deny something? This single answer drives everything downstream, because it sets the risk tier and the stakes.
  • 2. People and data. What data goes in, and whose? Anonymous logs and public docs are one world. Personal data — customers, employees, patients — is another, and special categories (health, biometrics, and so on) are a third with its own rules. You classify the data before you choose anything.
  • 3. Legal and contractual overlays. On top of the law sit the promises you've already made: the client contract that says data stays in Switzerland, the NDA, the sector rule. These can be stricter than the statute, and they bind you just as hard.
  • 4. Decision impact. Does the output inform a human, or does it decide? The moment AI materially affects a person — a rejection, a price, an eligibility call — you're in the part of the law with the sharpest teeth, and "a human rubber-stamped it" is not the escape hatch people assume.
  • 5. Allowed routes. Only now do you pick where the inference may go. Given the purpose, the data class, and the contracts, which models and providers are permissible — cloud frontier model, a provider with the right data-processing terms and region, or local-only inference on hardware you control? For step 2's sensitive rows, the answer is often "it never leaves the building."
  • 6. Tools, approval, oversight. What is the agent allowed to do autonomously, and where does a human have to sign? High-impact activities need a human genuinely in the loop, not a checkbox.
  • 7. Retention, memory, evidence. What's kept, for how long, and — the one everyone forgets — can you prove any of the above happened? No trail, no defence.

Notice that the model choice is step five of seven. It's downstream of almost everything. Leading with it is exactly backwards.

The traps that catch good-faith SMEs

The teams that get burned aren't cavalier. They're careful people who trusted one of these:

  • "It's just public data." Public sources are full of personal data — a name in a forum post, a face in an image, a CV on a jobs board. "I found it on the internet" is not a lawful basis for processing it. Scraping public data into an AI workflow is a decision with obligations, not a free pass.
  • "It runs locally, so we're fine." Local inference is a powerful control — it's how you keep the sensitive rows off third-party servers — but it is not automatic compliance. You can process data unlawfully on a laptop in your own office just as easily as in the cloud. Local answers the where; it doesn't answer the whether.
  • "The model is certified." There's no certificate that makes a use lawful. Vendor assurances cover the vendor's product, not your deployment of it. Your CV-screener is your high-risk system regardless of whose model is inside.

Where the tooling actually helps

This is the part I can speak to as the person who builds it, because the framework above is unenforceable if it lives only in a PDF. Policy that isn't wired into the pipe is a wish. Three places it has to become real:

  • The inference route needs one enforcement point. "This class of data may only go to that class of model" is impossible to guarantee when the routing decision is scattered across a dozen apps each with their own API key. Put it behind a single gateway and the policy has one place to live — and, just as importantly, one place that keeps the receipts step 7 demands.
  • Isolation and jurisdiction have to be demonstrable. "It ran in Switzerland and never reached a cloud model" is only worth saying if you can show it. That's the entire reason I build sandboxes you can pin to a jurisdiction — so residency and zero-egress are facts about where the work booted, not claims in a slide.
  • Memory needs a policy, not a default. What an agent remembers across sessions is processing too. If context persists, it has to persist under a rule you set, with a retention you can state — not accumulate silently until a breach turns it into a disclosure.

The one-sentence version

Stop asking which model is compliant. Start with the activity, classify the data, work down to the route, and keep the evidence. The model is a consequence of that pipeline, never the input to it. Do it in that order and compliance stops being a box you hope you ticked — and becomes something you can actually stand behind when someone asks you to prove it.

And then — because I mean the disclaimer up top — take that map to a lawyer who knows Swiss and EU law and let them find the corners I can't see. The framework gets the conversation to the right questions fast. It doesn't replace the person qualified to answer them.