Imagine two companies with the same policy for their artificial intelligence, word for word: what the system may say, which data it may touch, what it is forbidden to promise. In the first, the policy is a document that was drafted, signed and filed. In the second, the policy runs inside the system: every response passes through a control that applies it before reaching anyone. On paper, both "comply". The difference does not show in this year's audit — it shows on the day the system tries to say what it must not. In the first company, it says it. In the second, it does not get out.

That distance — between the policy that describes and the control that acts — is probably the most useful idea a decision-maker can take away about compliance in artificial intelligence. Because almost the entire conversation about "complying with AI" is about documents: what must be drafted, what must be producible on request. And documents matter. But a system that produces new responses every minute is not governed with a file: it is governed with controls that run at its speed.

A policy in a drawer stops nothing

The pattern is familiar from other domains. No serious company protects its payments with a memo saying "do not transfer without authorisation": it puts the authorisation inside the process, so that the unsigned transfer cannot execute. The policy describes the control; the control is what prevents. With artificial intelligence, however, most organisations are still at the memo stage: a document exists saying what the system must not do, and nothing stands between that document and the system's next response.

The problem is compounded by a particularity of AI: the system does not repeat an approved script; it generates new text every time. A control that reviews "the content" once a quarter reviews content that already went out. For the rule to arrive in time, it has to sit where the response is produced.

A legal boundary built as engineering

What that looks like in practice, we show with our own case, because it operates on one of the most demanding terrains: Strahlkraft40+, an artificial intelligence system in production in German regulated healthcare. In that sector, the boundary of what an AI may say is set by law: there are health claims that health-advertising legislation prohibits, and a system that converses about health is one step away from them in every response.

In Strahlkraft40+, that boundary is not fine print: it is engineering. The instructions governing the system set what it may not claim; a separate filter reviews every response after it is generated — replacing the terms the law does not allow, removing the prohibited formulations — before it reaches the person; and automated tests verify that the filter keeps working after every change. The system also answers the direct question with structural honesty: asked whether it is an artificial intelligence, it confirms it — because it is designed that way, not because a legal note promises it. And the same principle governs its data: protection is not in an annex but in the operation — minimisation in the system's own memory, consent control for sensitive data, cascading deletion. The three layers of the mechanism — instruction, filter, test — are taken apart piece by piece in The rules your AI obeys.

The detail worth retaining: the system does not diagnose, and that limit is deliberate. A governed system is not the one that does everything; it is the one that knows — by design — what is not its place, and observes it every time.

What the European regulation asks, read with these eyes

With that distinction in hand, parts of the European regulation read differently. Article 50 requires AI systems intended to interact with people to be designed and developed so that the person knows they are interacting with an AI (Source: Regulation (EU) 2024/1689, Art. 50, EUR-Lex, 2024). The wording is not accidental: it does not ask for a warning in the terms of use — it asks for the design to guarantee it. It is an engineering requirement with a transparency requirement's name.

The same goes for the quality management system the law requires for high risk (Art. 17): it is documented in writing, yes, but what is documented are procedures that have to be operating — data management, risk treatment, event logging. Whoever manufactures the documents without the controls owns a description of a system that does not exist; the full sequence is walked through in How to comply with the AI Act, step by step. Our reading, which is also how we work: the right order is to build the control inside the system and let the document describe it — never the other way round.

Three questions to know whether your compliance runs or sleeps

No audit is needed to locate yourself. Three questions suffice, and you can ask them this week:

  • If the rule changed tomorrow — a term that can no longer be used, a data point that can no longer be touched — what would have to change: a document the system obeys, or the habit of every person who uses it?
  • Does the control act before or after? Is there anything between what the system generates and what reaches people — or is the first reviewer the recipient?
  • Could anyone prove it today? If you were asked to demonstrate, this afternoon, that the most important prohibition in your policy is being applied, would you show a mechanism working or a PDF dated last year?

Whoever answers the three well does not have a compliance problem, even if paper is missing: they have the controls, and describing them is minor work. Whoever answers badly has the problem even with immaculate paper — because the drawer policy protects exactly until the day it is needed.