The EU AI act is enforceable: what DACH CTOs should do now

Most coverage of the EU AI Act still reads like a legal summary. It lists the risk tiers, quotes the penalty ceilings, and stops. That is not much use to a CTO who has to decide, this quarter, whether the model already sitting in a production workflow needs documentation, a human review step, or to be switched off.

This is written for that decision, from a DACH vantage point — where the rules land slightly differently depending on which side of the border you sit.

Switzerland is not in scope, and that changes less than you think

Switzerland is not an EU member, so the AI Act does not apply to a Swiss company by virtue of being Swiss. That is where most summaries stop, and where the useful part starts.

The Act applies to systems placed on the EU market or whose output is used in the EU. A Swiss company serving German or Austrian customers is in scope for those systems. So is a Swiss provider whose model output reaches an EU user through a customer’s product.

In practice, three questions decide it:

• Do EU users interact with the system, directly or through a customer?
• Does its output influence a decision taken in the EU?
• Is it embedded in a product a customer places on the EU market?

One yes is enough. Most Swiss mid-market companies with DACH customers answer yes somewhere, usually in a system nobody thought of as “AI”.

Where your systems actually sit

The tiers matter less than honest classification. Four categories, in descending order of consequence:

Prohibited. Social scoring, untargeted facial-image scraping, emotion inference in workplaces and schools. If you are here you already know.

High-risk. The tier that catches people. It includes AI used in employment decisions, creditworthiness, essential private services, and safety components of regulated products. A CV-ranking tool is high-risk. So is a model that scores loan applications, and one that triages patients.

Limited risk. Transparency obligations: people must know they are dealing with a machine, and synthetic content must be marked as such. Most chatbots live here.

Minimal risk. Everything else, which is genuinely most things.

GPAI sits across the tiers. If you build on a foundation model, the provider carries obligations you inherit contractually rather than directly — which is why the vendor question below matters more than it looks.

Why regulated industries are calmer about this

Healthcare and financial services organisations tend to be further along, and the reason is not that they saw it coming. It is that they already had the machinery.

An organisation running under FINMA supervision, or shipping a medical device under MDR, already maintains a system inventory, documented risk assessments, change control and audit trails. The AI Act asks for the same artefacts applied to a new class of system. The work is real but it is extension, not construction.

If you have none of that machinery, the AI Act is not the hard part. The hard part is building the first inventory.

Four questions that define your position

Do you have a documented AI inventory?

Not a list of AI projects — a list of systems where a model influences an outcome. These are usually different lists. The second one includes the classifier someone added to a support queue two years ago, the scoring rule inside the CRM, and the forecasting model in the finance spreadsheet.

Most organisations discover they have between two and four times as many in-scope systems as they expected.

Which systems materially affect rights, safety or money?

This is the classification question, and it should be answered per system by someone who understands what the system does, not by legal working from a project name. “Recruitment assistant” tells you nothing; “ranks candidates before a human sees them” tells you it is high-risk.

What governance do you actually need?

For high-risk systems: risk management across the lifecycle, data governance covering training and input data, technical documentation, logging, human oversight, and accuracy and robustness testing. For limited-risk: disclosure. For minimal: nothing mandatory, though the inventory still has to know they exist.

What does your vendor relationship give you?

This is the one that bites. If you build on a third-party model you need documentation you cannot produce yourself — training data characteristics, evaluation results, known limitations. Whether you can get it is a contractual question you may not have asked.

Check three things in every AI vendor contract: what documentation they commit to providing, what happens when the model changes underneath you, and whether they will support an audit. Many standard terms cover none of the three.

A 90-day path

Sequenced so each phase produces something the next one needs.

Weeks 1–3 — Inventory. Every system where a model influences an output. Owner, purpose, data in, decision affected, users, EU exposure. Expect surprises; that is the point.

Weeks 4–6 — Classify. Tier each system. Be conservative where it is close: reclassifying down later is cheap, discovering an unclassified high-risk system during an audit is not.

Weeks 7–10 — Close the gaps. For each high-risk system, document what exists, list what does not, and decide per gap: build it, buy it, or retire the system. Retirement is a legitimate answer for a system nobody can justify.

Weeks 11–13 — Operationalise. Governance that survives contact with delivery: a checkpoint in the change process, a named owner per system, a review cadence. A framework nobody runs is worse than none, because it looks like coverage.

The cost, honestly

Compliance work on a high-risk system typically runs into weeks of engineering and documentation effort, and it recurs — every material model change reopens parts of it.

The competitive argument is simpler than the risk argument. In DACH procurement, a supplier who can produce an AI inventory and a classification rationale during a vendor assessment is in a materially different conversation from one who cannot. We see this in tenders now, and the gap is widening.

What to stop waiting for

Guidance will keep arriving, and the temptation is to wait for it. Do not wait for it to start the inventory — that work is independent of every open question, and every subsequent step depends on it.

Start: the inventory, the vendor contract review, one named owner. Stop: waiting for perfect guidance, treating this as legal’s problem, and assuming your vendor has it covered.

---

If you are working out what applies to your systems, our AI strategy and consulting work usually starts exactly here — with the inventory, not the technology. A conversation is a reasonable first step, and it is non-binding.