For builders shipping AI in or to the EU

The EU AI Act for engineers and architects

The four risk tiers

The Act sorts AI systems into four bands. The obligations that attach to each are very different, so the classification step is where your architecture decisions begin.

Unacceptable risk (banned)

A short list of practices is prohibited outright. These include things like certain manipulative or exploitative systems, untargeted scraping for facial-recognition databases, and some forms of social scoring. If your design lands here, there is no compliance path. You change the design.

High risk (strict obligations)

Systems used in defined sensitive contexts, such as some uses in employment, education, essential services, law enforcement, and safety components of regulated products. High-risk systems carry the bulk of the Act's engineering obligations: risk management, data governance, logging, human oversight, robustness and accuracy targets, and technical documentation.

Limited risk (transparency duties)

Systems that interact with people or generate content carry transparency obligations rather than the full high-risk regime. The headline example is Article 50: disclose that a user is dealing with AI, and label AI-generated or manipulated content. More on that below.

Minimal risk (largely unregulated)

Most everyday AI, such as spam filters or recommendation features, falls here and is largely unregulated by the Act. The risk in practice is misclassifying a system as minimal when one component pushes it higher.

Provider vs deployer

The Act assigns obligations by role, and the same organisation can hold both. A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name. A deployer uses an AI system under its own authority. The two carry different duties.

Providers shoulder most of the heavy obligations for high-risk systems: conformity work, technical documentation, the quality and risk-management processes, and the information that has to flow downstream. Deployers have their own duties, which can include operating the system per the provider's instructions, ensuring meaningful human oversight, and monitoring in use. If you fine-tune, rebrand, or substantially modify a system you did not originally build, you may take on provider obligations. Know which hat you are wearing, because it changes what you are accountable for.

Transparency (Article 50)

Article 50 sets transparency duties that apply broadly, not only to high-risk systems. Two are most relevant to builders. First, when people interact directly with an AI system, they should be made aware they are dealing with AI unless it is obvious from context. Second, providers of systems that generate synthetic audio, image, video, or text should mark outputs as artificially generated or manipulated in a detectable way, and deployers of certain content, such as deepfakes, have disclosure duties of their own.

For engineers this turns into concrete work: an honest AI-disclosure surface in your UI, and a content-provenance or watermarking approach for generated media. Treat these as product requirements, not afterthoughts.

General-purpose AI (GPAI) models

On top of the risk tiers, the Act places obligations on providers of general-purpose AI models, with additional duties where a model is judged to carry systemic risk. These cover things like technical documentation, information to downstream providers who build on the model, and copyright and training-data transparency expectations. If you build on top of a foundation model you are usually a downstream provider relying on the model provider's compliance, but you should know these obligations exist and sit alongside, not instead of, the risk-tier rules.

Mapping obligations to your architecture

The high-risk obligations are not abstract legal text. They map onto system components you, the engineer, already control:

• Logging and record-keeping. Automatic recording of events over the system's lifetime, enough to trace behaviour and support post-incident review. This is observability with a retention and auditability mandate.
• Human oversight. The system has to be designed so a person can understand it, intervene, and override or stop it. That is an architecture and UX decision: surface state, expose a stop control, gate irreversible actions behind a human.
• Data governance. Training, validation, and test data managed for relevance, representativeness, and bias. This reaches into your data pipeline, not just your model.
• Robustness and accuracy. Appropriate levels of accuracy, robustness, and cybersecurity, declared and maintained. This is your eval suite, your adversarial testing, and your security posture.
• Technical documentation. Documentation drawn up before the system is placed on the market and kept current. Architecture decision records and model and dataset documentation feed straight into this.

If you already practise observability, least privilege, testing, and documentation, you are most of the way there. The Act gives those practices a regulatory edge in the EU.

Where GDPR fits

The EU AI Act sits alongside the General Data Protection Regulation (GDPR, Regulation (EU) 2016/679). It does not replace it. Wherever your AI system processes personal data, GDPR still governs that processing in full. The pieces engineers hit most often:

• Lawful basis. You need a valid legal ground to process personal data, before you process it.
• Data minimisation. Collect and retain only what you need for the stated purpose. This pushes back directly on the instinct to hoard training data.
• Purpose limitation. Data collected for one purpose cannot be freely repurposed, which constrains reusing operational data for model training.
• Article 22. Restrictions on decisions based solely on automated processing that produce legal or similarly significant effects on a person. Relevant whenever an agent or model makes consequential decisions without a human in the loop.

In short: the Act tells you what obligations attach to the AI system; GDPR tells you how you may handle the personal data flowing through it. You design for both at once.

A note on timelines

The Act's obligations are phased in over time rather than all at once, and the detail, including guidance and standards, is still evolving. Do not treat any specific enforcement date as fixed. Before you make a compliance decision, check the current official text and the European Commission's guidance for the dates and duties that apply to your situation.