The EU AI Act is the world's first comprehensive legal framework specifically targeting artificial intelligence systems. For engineering teams, it translates into concrete obligations around risk classification, documentation, monitoring, and human oversight — most of which need to be designed in, not bolted on. This post walks through what the regulation actually requires, in terms an engineering team can act on, and how to build a readiness path.

What the EU AI Act Is and Is Not

The Act does not ban AI. It creates a risk-tiered framework that applies stricter requirements to systems that can cause more harm. The obligations you face depend almost entirely on how your AI system is classified.

Four risk tiers matter in practice:

  • Unacceptable risk: outright prohibited (social scoring by public authorities, certain biometric surveillance). Almost no commercial product lands here.
  • High risk: heavy obligations — conformity assessments, technical documentation, human oversight, logging, accuracy requirements. This tier covers systems used in employment, credit, education, critical infrastructure, and a defined list of other sensitive domains.
  • Limited risk: transparency obligations only. Chatbots must disclose they are AI; deepfakes must be labelled.
  • Minimal risk: effectively unregulated. Most AI features in enterprise software fall here.

The implication: your first engineering task is to correctly classify each AI system your team ships. Getting that classification wrong is where most teams run into trouble, because the temptation is to assume "minimal risk" without doing the work.

How Risk Classification Works

Classification depends on two questions: what domain does the system operate in, and what decision does it inform?

Annex III of the Act lists the high-risk categories. The ones most relevant to enterprise software are: systems that assess individuals for access to employment or benefits, systems that evaluate creditworthiness, systems used in law enforcement or judicial decisions, and systems that are safety components of regulated products.

A workflow automation tool that drafts marketing copy is minimal risk. The same tool repurposed to score job applicants becomes high risk, even if the underlying model is identical. The system's intended purpose, not its technical architecture, drives the classification. For a broader framework on evaluating governance maturity as you work through this classification exercise, see An AI Governance Maturity Model.

For engineering teams, this means classification should happen at the feature design stage, not as an afterthought before launch. It also means you need a way to track classifications over time — the intended purpose can drift as product scope expands. A structured AI agent compliance checklist for 2026 is a useful starting point for that initial inventory exercise.

What High-Risk Systems Actually Require

If any system crosses into high risk, the Act imposes a specific set of technical and organisational requirements. These map surprisingly well onto practices good engineering teams already apply — but with legal weight behind them.

Technical documentation. You must be able to describe the system's purpose, design decisions, training data characteristics, performance metrics, and known limitations. Think of it as a design doc that has to survive regulatory scrutiny.

Data governance. Training and validation datasets must meet quality standards and be documented. Sensitive attributes used in training require particular justification. This requires traceability back to data pipelines that most teams don't instrument by default.

Logging and audit trails. High-risk systems must automatically log events sufficient to trace decisions after the fact. The Act specifies that logs must allow post-hoc accountability. Append-only, tamper-evident audit logs are not optional for these systems — they are a statutory requirement. The technical approach is covered in tamper-evident audit logs with cryptographic proofs.

Human oversight. The system must be designed so a human can understand, monitor, and intervene in its outputs. This is not just a UI checkbox: it requires that the system surfaces enough context for a human reviewer to make a meaningful decision, and that the override path actually works.

Accuracy, robustness, and cybersecurity. High-risk systems must meet appropriate accuracy thresholds for their use case, be resilient to errors and attempts at manipulation, and be secured against adversarial attacks.

Conformity assessment. Before deployment, certain high-risk systems need a conformity assessment — either self-assessed or via a notified body, depending on the category.

The Provider vs Deployer Split

One of the most practically significant distinctions in the Act is between providers (those who develop and place AI systems on the market) and deployers (those who put a provider's system to use in their own context).

If your team builds and sells an AI system, you are the provider and carry the heavier obligations. If your team takes a third-party model or platform and configures it for a specific use case within your organisation, you may be a deployer — but you are not off the hook. Deployers have obligations too: fundamental rights impact assessments for certain systems, ensuring human oversight is in place, and maintaining usage logs.

Many engineering teams building on foundation models will be deployers. The question to answer is: does the vendor's system cover the provider obligations, and what gaps do you need to fill as deployer?

This is worth working through explicitly with your legal team, because the Act's enforcement is directed at the party responsible for each obligation — and the line between provider and deployer can blur when you fine-tune models or build non-trivial prompt engineering layers on top of a base model.

A Practical Readiness Path

Rather than treating EU AI Act compliance as a one-time project, the teams that tend to handle it well treat it as an ongoing engineering discipline with four recurring activities.

Inventory and classify. Maintain a register of every AI system in use, with its risk classification and the reasoning behind it. Re-evaluate when scope changes. This is the foundation everything else builds on.

Instrument for the Act's logging requirements. For any system that might be or become high risk, instrument it now to capture the events the Act requires. Retrofitting audit instrumentation into a production system is far harder than building it in. The events you need are: who triggered the system, what inputs were provided, what outputs were produced, what human review or override occurred, and when each event happened.

Document as you build. Technical documentation requirements under the Act closely parallel what a good design review produces anyway. The difference is retention and structure: the documentation needs to be findable and coherent years later, not just in a Notion page someone updates twice.

Establish a human oversight path. For any automated decision that could materially affect a person, design the human oversight mechanism before shipping. This means defining who reviews, what they see, and how they can intervene — not just adding a "approve" button at the end of a pipeline. The design considerations for these gates are explored in human-in-the-loop approvals for high-risk agent actions.

How Praesidia Is Designed to Help

Praesidia is designed to address several of the Act's engineering requirements directly. The platform supports per-agent EU AI Act risk classification, letting teams assess and record each agent's risk tier and track compliance status over an agent's lifetime. As the agent's purpose or configuration changes, the classification can be reassessed and the history retained.

Audit logging in Praesidia is append-only and hash-chained, producing a tamper-evident trail that covers the events high-risk system logging requires. Content guardrails provide the in-flow controls — blocking or flagging outputs before they reach users — that support the Act's accuracy and robustness requirements. Access controls and human-in-the-loop approval paths address the oversight requirements directly.

The platform also generates compliance reports that map to recognised frameworks, giving compliance officers a structured view of posture rather than requiring them to reconstruct it from raw logs. See GDPR erasure and EU AI Act readiness for how these controls map specifically to the Act's GDPR-adjacent obligations.

Common questions

Does the EU AI Act apply to my team if we're not based in the EU?

Yes, if the AI system's outputs are used in the EU — either because your users are in the EU or because the system affects people in the EU. The Act applies based on where the system is deployed and whose rights are affected, not where the developer is incorporated. This is consistent with how GDPR territorial scope works.

When do the obligations actually take effect?

The Act came into force in August 2024 and applies in stages. Prohibited practices faced obligations from February 2025. High-risk systems in Annex III have a longer runway, but organisations should not wait until the deadline to start work — the documentation, logging, and oversight requirements take time to build properly.

What is a "conformity assessment" and do we need one?

A conformity assessment is the process by which a high-risk AI system is evaluated against the Act's requirements before deployment. For most high-risk systems, providers can self-assess and document the result. For a narrower set (primarily biometric and law enforcement systems), an independent notified body must assess. If your system is high risk, determine early which path applies — it affects your timeline significantly.

The EU AI Act is a real engineering requirement, not just a legal one. The teams that will handle it best are the ones that treat risk classification and audit instrumentation as engineering disciplines rather than compliance exercises — and that build the infrastructure for human oversight before they need it, not after a regulator asks for it. For a practical readiness review that covers the Act alongside other applicable frameworks, see the AI agent compliance checklist for 2026, and for the data-residency dimension of compliance see data residency and sovereignty for AI agents.