EU AI Act, for agents

Risk tiers, read from the agent side.

The Act sorts AI systems into four tiers by the risk of their use, not the size or sophistication of the model. From the most onerous down:

• Unacceptable risk — prohibited. Social scoring by public authorities, untargeted scraping of facial images, real-time remote biometric identification by law enforcement in public spaces (with narrow exceptions), exploitation of vulnerabilities, certain emotion-recognition uses in workplaces and education. An agent that touches one of these is simply not legal to deploy in the EU; design that out at requirements time, not at review time.
• High-risk — heaviest duty list. The Act lists categories — biometric identification, critical infrastructure, education and vocational training, employment and worker management, access to essential public and private services (including credit scoring), law enforcement, migration and border control, administration of justice — plus systems that are themselves products or safety components covered by other EU product law. Most agent use cases that act on people fall in one of these categories.
• Limited risk — transparency duties. Systems that interact with people, generate or manipulate content, or perform emotion recognition or biometric categorization carry disclosure obligations: users must know they are dealing with AI, content must be marked machine-readable as AI-generated. A customer-support agent without high-stakes decisions usually lives here.
• Minimal risk — voluntary best practice. The long tail; no specific obligations under the Act, though general law still applies.

The reframe for engineers: the question is not "how powerful is my model" but "what is the agent deciding, about whom, with what consequence." Tier the use; the model question follows.

What "high-risk" actually requires of an agent builder.

The high-risk duty list is concrete and architectural. The themes that recur:

• Risk management system — an explicit, documented, iterative process that identifies, evaluates, and mitigates the risks the system poses across its lifecycle. Not a one-off launch review.
• Data governance — training, validation, and test data subject to quality criteria: representativeness, error rates, gaps, bias mitigation, and documentation of provenance. The discipline from data-governance maps directly here.
• Technical documentation — what the system does, how it was built, what data it was trained and evaluated on, what it can and cannot do, what residual risks remain. Maintained as the system evolves.
• Record-keeping (logs) — automatic logs sufficient to trace operation throughout the lifecycle, with retention. The audit-trails material is the engineering shape of this duty.
• Transparency to deployers — instructions for use detailed enough that the downstream deployer can use the system properly and meet their own obligations.
• Human oversight — designed-in, not bolted-on; a person able to understand, decline, override, and stop the system. For an autonomous agent this is an architectural constraint, not UX polish.
• Accuracy, robustness, and cybersecurity — appropriate levels for the intended purpose, including resilience to errors, faults, inconsistencies, and adversarial attempts to manipulate the system.
• Quality management system — the organizational scaffolding (responsibilities, procedures, post-market monitoring) the provider operates under.

General-purpose AI: provider obligations, and what flows downstream.

The Act treats general-purpose AI (GPAI) models separately. Providers of GPAI models carry obligations independent of how the model is used downstream — at minimum, technical documentation, information to downstream deployers, a policy to respect EU copyright law, and a public summary of training content. Providers of GPAI models judged to have systemic risk (the most capable models, defined against compute and capability thresholds) carry additional duties: model evaluation, systemic-risk assessment and mitigation, serious-incident reporting, and cybersecurity protection.

For an agent team, almost certainly a deployer rather than a GPAI provider, the load-bearing point is the same one from regulatory-landscape: using a third-party GPAI model does not transfer your deployment-level obligations to its provider. You inherit a documentation baseline from upstream; you still own the risk assessment, the oversight design, and the audit logs for how you actually use it. Read the provider's documentation; pin to versions whose documentation you can keep; treat the upstream model as input to your own high-risk obligations, not as an absolution from them.

The dates that matter (without inventing specifics).

The Act applies in phases over the years following its entry into force. The shape of the staging is more reliably useful to plan around than any one date — and the dates have shifted in practice — so the operating instruction is the staging, not the calendar:

• Prohibitions kick in first. Unacceptable-risk uses are off the table earliest in the staging.
• GPAI provider obligations come next. If you build on a third-party general-purpose model, expect your provider's documentation and information-to-deployer obligations to start flowing to you before your own high-risk obligations are fully in force.
• High-risk obligations phase in later. The risk management, data governance, technical documentation, logging, transparency, oversight, robustness, and quality management duties take effect on a longer staging, with extra time for high-risk systems embedded in already-regulated products.
• Penalties bite once the relevant phase is in force. Fines are tiered (the headline ranges escalate with severity); the practical exposure scales with revenue, so a small product can ignore the headline number but a serious one cannot.

For an agent team, the planning posture is: build to the high-risk duty list now if your use case sits in any of the listed categories, even when the calendar date for full applicability is still ahead. Retrofitting a logging duty, an oversight point, or a documented risk management process onto a live system under deadline is the expensive failure mode the regulatory landscape essay warned about.

Where it meets the NIST AI RMF — and what this essay is not.

The Act is binding EU law; the NIST AI RMF (covered in the next essay) is a voluntary US framework. They do not overlap on enforcement, but they do overlap on engineering work: risk management as a continuous process, governance as a named responsibility, oversight designed-in, evidence as a default. A team that runs a serious NIST AI RMF program is most of the way to the high-risk technical and organizational duties — and a team that satisfies the Act's high-risk duties is generally also covering NIST's territory. Pick one as your scaffolding, do it seriously, and the second mostly falls out of the first.

What this essay is not: legal advice. The Act has consolidated text, amendments, secondary acts, and national implementations. Specific category placement, the line between limited and high-risk for any given use, exemptions, and obligation timing in your jurisdiction all need qualified counsel. Use this essay to know what to ask about; use a lawyer to know what to do.