The EU AI Act for development teams

If the system interacts directly with people, they must be told at the latest at first interaction, unless it is obvious from the context. A static declaration at the start of the session is enough; it does not have to repeat on every reply. The duty does not apply to AI running in the background with no user interaction, such as translation, spellcheck, or network optimisation.

If your system generates synthetic audio, image, video, or text, the output has to be marked in a machine-readable format so it can be detected as AI-generated. The Transparency Code of Practice, published by the Commission on 10 June 2026, says it outright: no single marking technique can on its own meet the four requirements in Article 50(2), so signatory providers must apply at least two layers of machine-readable marking to their output. One exception catches a lot of teams: free-form text cannot carry metadata, so there a single layer is enough. The Code names no particular standard. Our assessment, not the Code's, is that C2PA (Content Credentials) is the strongest candidate for the metadata layer. And standardisation is not finished: as of August 2026, ISO 22144 is still a committee draft, so there is no adopted ISO standard to write into a specification yet. Signing up is voluntary, but it is the easiest way to show you meet the requirement, and it commits you to an interoperable detection solution by 2 February 2027.^5,6,11

If you generate or manipulate image, audio, or video content resembling real people, places, or events that would appear authentic, it has to be visibly labelled at first exposure. The labelling has to meet accessibility requirements so it also reaches users on assistive technology.

If you publish AI-generated text to inform the public on matters of public interest, that has to be disclosed. The exemption is real: where a human has exercised substantial editorial control and takes responsibility for the content, the duty falls away.

DeliverableA threat model that runs in CI

The requirement is an iterative risk management system across the whole lifecycle. In practice, that is threat modelling extended to machine learning: automated test suites in the pipeline running against adversarial input, data drift, and edge cases, measuring how the model degrades rather than only when it is right.

DeliverableProvenance for every training data point

Training, validation, and test data must be relevant, representative, and as far as possible free of errors. That requires real data lineage rather than a description of it: dataset versioning, bias scanning in the preparation pipeline, and a snapshot or detailed metadata retained for audit.

DeliverableDocumentation as code, versioned with the system

Architecture, design choices, model selection, validation logic, test metrics, and the system's limits, meaning what it cannot or should not be used for. Keep the documentation in the repository next to the code and it will not drift from production. Keep it on a shared drive and it will.

DeliverableImmutable, structured logs kept at least six months

The system has to record events automatically during operation. Concretely: one structured event per AI decision, with input, output, timestamp, model version, warnings, and the identity of whoever exercised oversight. Deployers must keep them for at least six months. Logs that can be edited afterwards prove nothing, so they have to be written to storage that cannot be overwritten.

DeliverableA stop button that actually stops something

The system must be effectively supervisable by whoever operates it. That rules out opaque solutions: confidence and limitations have to surface in the interface. And the architecture has to support pausing the work, typically asynchronously with a status flag, where the process only continues once a named person releases it.

DeliverableA fallback for when the model fails

Protection against prompt injection, data poisoning, and model evasion, and redundancy for when the model fails. If it returns something unparseable or blows the latency budget, the system has to fall back to a deterministic rule set or degrade in a controlled way. A system that simply waits on the model is not robust.

If you build a product on top of a third-party model such as GPT or Claude and sell it under your own name, you are the provider. If you use a finished tool internally without putting your name on it, you are the deployer. The provider role carries the documentation, the marking, and the liability.

From 2 December 2027 for standalone systems under Annex III, and from 2 August 2028 for AI embedded in products under Annex I. Both dates were deferred by the Digital Omnibus on 27 July 2026. Many Danish sources still state 2 August 2026.

The provider must apply machine-readable marking to synthetic output and disclose AI interaction. The deployer must label deepfakes and AI-written text of public interest. If you build the product on a third-party model, you are the provider and carry both.

Not by itself. RAG supplies context in the prompt without changing the model's weights, which argues the system is unchanged. Fine-tuning or LoRA on your own data changes the parameters and argues strongly for the provider role. The line has not been tested in Danish practice.

Digitaliseringsstyrelsen coordinates nationally. Supervision of prohibited AI practices is shared with Datatilsynet and Domstolsstyrelsen. Supervision of high-risk and of Article 50 has not yet been assigned. General-purpose AI models fall under the European Commission's AI Office.

Up to EUR 35m or 7% of global annual turnover, whichever is higher, for breaching the Article 5 prohibitions. There are proportionate levels for small and medium-sized companies, but the amounts remain substantial.