• DOCS
  • EU AI ACT
EU AI Act · Regulation (EU) 2024/1689

The EU AI Act, article by article — what swarmd does, and does not do, for each one.

A provision-level analysis of what the Act asks of providers and deployers of AI agents, and the specific control, check or record swarmd ships for each one. Every provision says plainly whether swarmd enforces it, tracks it, or leaves it to you, and where the control stops. Checked against the shipped product on 18 October 2026.

Reviewed 18 October 2026As amended by the Digital Omnibus on AI
Enforced by swarmd10of 37 provisionsswarmd does it: in the relay, on the traffic the control covers, or by refusing the action that would break it. The limits say where it stops.Tracked and evidenced22of 37 provisionsswarmd runs the workflow, checks it is in place and keeps the evidence. The substance — a document, an assessment, a filing — is yours.Your responsibility5of 37 provisionsOutside what a runtime platform can do. We name it so nothing falls between the gaps.
40obligations in one matrix, each cited to its article, applied by tier, role and use case
25Annex III use cases classified point by point
20compliance document kinds, each linked with an optional SHA-256
3system types governed: agents, MCP servers, LLM gateways
Where the law stands

Phased in, and already biting.

The Act entered into force in August 2024 and applies in stages. Prohibitions, AI literacy, the general-purpose AI regime and, since 2 August 2026, the Article 50 transparency duties all apply today. The Digital Omnibus on AI moved the high-risk regime back, to 2 December 2027 for Annex III use cases and 2 August 2028 for products under Annex I.

Those dates are closer than the work they require. Classification, named oversight, technical documentation and a year of monitoring evidence take time to build, and an auditor will ask for the history, not just the current state.

  1. In effect1 Aug 2024Entry into forceRegulation (EU) 2024/1689 enters into force. Obligations apply in phases.
  2. In effect2 Feb 2025Prohibitions and AI literacyArt. 5 prohibited practices and the Art. 4 AI literacy duty apply.
  3. In effect2 Aug 2025General-purpose AI and penaltiesChapter V obligations for GPAI model providers, the AI Office and Board, and national penalties apply. Fines on GPAI model providers follow from August 2026.
  4. In effect27 Jul 2026Digital Omnibus in forceRegulation (EU) 2026/1744 amends the Act: high-risk dates move, Art. 4 is softened, bias-detection data moves to Art. 4a.
  5. In effect2 Aug 2026Transparency and general applicationArt. 50 applies: disclosure to people interacting with AI and machine-readable marking of synthetic content. National authorities enforce.
  6. Upcoming2 Dec 2026New prohibitions, marking deadlineThe Omnibus bans on intimate-imagery and CSAM generators apply, and generative systems placed on the market before 2 Aug 2026 must mark outputs.
  7. Upcoming2 Dec 2027High-risk: Annex IIIObligations for Annex III high-risk systems apply. Originally 2 August 2026; moved by the Omnibus.
  8. Upcoming2 Aug 2028High-risk: Annex I productsObligations apply to AI systems that are, or are safety components of, products under Annex I legislation.
Guidance and standards
FinalArt. 50 Code of Practice and guidelinesThe voluntary code on marking and labelling AI-generated content was published on 10 June 2026, and the Art. 50 guidelines on 20 July 2026.
CitedEN 18286, quality managementThe first harmonised standard under the Act, cited in the Official Journal on 14 October 2026. Standards for risk management, logging and cybersecurity are not yet cited.
DraftArt. 6 high-risk classification guidelinesPublished in draft on 19 May 2026; consultation closed in July. The final version is expected by the end of 2026.
DraftArt. 73 serious-incident guidance and templateConsulted on in autumn 2025; not yet final. Post-market monitoring guidance and template are now due by 2 September 2027.
PenaltiesUp to €35 million or 7% of worldwide turnover for prohibited practices; €15 million or 3% for most other obligations, transparency included; €7.5 million or 1% for misleading information to authorities. SMEs pay the lower of the two figures, and since the Omnibus so do small mid-caps outside the prohibitions tier.
Who it reachesProviders placing AI systems on the EU market, wherever they are based; deployers in the EU; and providers and deployers outside it whose systems’ output is used in the Union. Importers and distributors have duties too. Substantially modify a high-risk system and you may become its provider.
Why agents are differentAn agent that calls tools, talks to people and delegates to other agents touches several obligations in one exchange. Compliance has to follow the exchange, not sit in a document beside it.
Classification

The Act classifies by use. So do we.

A risk score invites argument. The Act classifies by use, and swarmd asks its questions in a fixed order: prohibitions first, so nothing banned is waved through as out of scope, then scope, Annex I, Annex III with the Article 6(3) derogation, then Article 50. The tier is derived from the answers a named person signs, with every article it rests on, and the same answers always give the same tier.

  1. 01
    Art. 5Does it perform or enable a prohibited practice?→ Prohibited
  2. 02
    Art. 2, 3(1)Is it outside the Act’s scope?→ Out of scope
  3. 03
    Art. 6(1)Is it, or is it a safety component of, an Annex I product needing third-party assessment?→ High-risk
  4. 04
    Art. 6(2), 6(3)Does it fall under an Annex III use case?→ High-risk, or exempt if a derogation holds and it does not profile people
  5. 05
    Art. 50Does it talk to people, generate content, or recognise emotions or categorise people biometrically?→ Limited
  6. 06
    —None of the above→ Minimal
Out of scope
Art. 2, 3(1)Rationale required
Minimal
—In scope, no trigger
Limited
Art. 50Transparency duties
High-risk (exempt)
Art. 6(3)Assessment required, second signature
High-risk
Art. 6(1), 6(2)Full regime, second signature
Prohibited
Art. 5Immediate; in-service systems suspended
  • Four eyes on high-risk. A second person must approve, and the server refuses the assessor's own signature.
  • Upward-only overrides. You can be stricter than the Act, never more lenient without new reasoning.
  • Tools inherit risk. MCP servers and LLM gateways take the strictest tier of the agents using them, recomputed live.
Provision by provision

Every obligation, and what discharges it.

Each provision that applies to organisations building and running AI agents, grouped as the Act groups them. On the left, what the law requires and who it applies to. On the right, how swarmd covers it, where the evidence lives, and the limits of that coverage. Filter by your role or by coverage level.

Enforced by swarmdswarmd does it: in the relay, on the traffic the control covers, or by refusing the action that would break it. The limits say where it stops.
Tracked and evidencedswarmd runs the workflow, checks it is in place and keeps the evidence. The substance — a document, an assessment, a filing — is yours.
Your responsibilityOutside what a runtime platform can do. We name it so nothing falls between the gaps.
Chapters I–II · Scope, AI literacy and prohibited practicesChapter III · Section 1 · Classifying high-risk systemsChapter III · Section 2 · Requirements for high-risk systemsChapter III · Sections 3–5 · Obligations of providers and deployersChapter IV · Transparency for every AI systemChapter V · General-purpose AI models in your stackChapters IX and XIII · Monitoring, incidents, explanations and withdrawal
Your role
Coverage
Showing 37 of 37 provisions
Chapters I–II

Scope, AI literacy and prohibited practices

Before any obligation applies you have to know what is in scope, who is trained, and that nothing on your estate is banned outright.

1 enforced · 2 tracked
The obligation
Art. 2, Art. 3(1)

Scope and the definition of an AI system

The Act applies to AI systems as defined in Art. 3(1), with exclusions in Art. 2 such as military use and pure research.

Applies to: Provider and Deployer
How swarmd covers itTracked and evidenced
  • Every agent, MCP server and LLM gateway is in the AI register from the day the platform is installed, so nothing is out of scope by omission.
  • The classification wizard asks the scope question straight after role and intended purpose. Out of scope needs a written rationale before it can be signed.
Evidence:
The signed classification with its answers and rationale.
Limits:
Whether a system is in scope is your judgement; swarmd records who made it and why. An out-of-scope decision takes one signature, so review them on the register.
The obligation
Art. 4

AI literacy

Providers and deployers take measures to support the AI literacy of the staff who operate AI systems for them. The Digital Omnibus softened this from ensuring a sufficient level to supporting its development.

Applies to: Provider and Deployer
How swarmd covers itTracked and evidenced
  • Owners, deputies and oversight persons each carry an AI literacy attestation date and a link to the training record. Attestations lapse after twelve months.
  • High-risk systems need at least one oversight person with a current attestation before readiness is met.
Evidence:
Attestation dates per person on each system’s Accountability tab and in its evidence pack; the register export shows the oldest.
Limits:
swarmd records the attestation; it does not run or verify the training.
The obligation
Art. 5

Prohibited practices

Eight practices have been banned since February 2025, from manipulative techniques and social scoring to untargeted facial scraping. From 2 December 2026 the Omnibus adds AI that generates non-consensual intimate imagery and child sexual abuse material.

Applies to: Provider and Deployer
How swarmd covers itEnforced by swarmd
  • The wizard screens for all ten practices, including the two Omnibus additions. Any match derives the Prohibited tier at once, with no second signature.
  • An agent or MCP server in service is suspended on the spot and its kill switch engaged.
  • From then on the platform refuses to put it into service or lift its suspension and, for agents, refuses a new version from the console, reactivation and marketplace publishing, whatever the gate mode.
Evidence:
The classification, the automatic suspension and the kill-switch event.
Limits:
swarmd screens the use you declare; it cannot detect a prohibited practice from traffic. A Draft, Assessed or Retiring system keeps serving until you freeze it. LLM gateways have no kill switch, so a gateway in service must be taken out of service before it can be classified Prohibited. Moving a system off Prohibited takes a new classification and a second signature.
Chapter III · Section 1

Classifying high-risk systems

The Act classifies by use, not by score. swarmd asks the Act’s questions in a fixed order, prohibitions first, and records who answered them.

1 enforced · 1 tracked
The obligation
Art. 6(1)–(2), Annex I, Annex III

Which systems are high-risk

An AI system is high-risk if it is, or is a safety component of, a product under Annex I legislation that needs third-party conformity assessment, or if it is used in one of the Annex III areas such as recruitment, credit scoring, education or essential services.

Applies to: Provider and Deployer
How swarmd covers itEnforced by swarmd
  • The tier is derived from signed answers in a fixed order: Art. 5, scope, Annex I, all 25 Annex III points, the Art. 6(3) derogation, then Art. 50. The legal basis names the exact point, such as Annex III 4(a).
  • A high-risk classification, or a move down from high-risk or Prohibited, needs a second person, and the lower tier does not apply until they approve. The server refuses the assessor’s own approval.
  • Overrides can only raise the tier. To go lower you change the answers, which is a new classification with its own reasoning.
Evidence:
Every classification, never edited, with answers, legal basis, assessor and approver.
Limits:
The tier follows the answers people sign, and the legal judgement behind them is yours. Other results, such as Minimal or Limited for a system that was never high-risk, take effect on one signature.
The obligation
Art. 6(3)–(4)

The derogation for narrow tasks

An Annex III system is not high-risk if it meets one of four conditions and does not profile people. The provider documents the assessment before placing it on the market and still registers the system, in simplified form.

Applies to: Provider
How swarmd covers itTracked and evidenced
  • The four conditions and the profiling bar are asked separately. A derogation for a system that profiles people is refused, citing the bar.
  • The High-risk (exempt) tier requires a linked Art. 6(3) assessment, and still counts for registration.
Evidence:
The derogation answers and the linked assessment.
Limits:
The assessment is yours to write. swarmd will not count the system ready without a linked, approved assessment, and records the SHA-256 you supply; under the default Warn mode a missing one is flagged rather than blocked.
Chapter III · Section 2

Requirements for high-risk systems

Articles 9 to 15. Most of them are documents and processes you own; logging and human oversight are where a runtime can do the work itself.

2 enforced · 5 tracked
The obligation
Art. 9

Risk management system

A continuous risk management process across the lifecycle, with testing against defined metrics during development and before release, and risks re-evaluated using post-market monitoring data.

Applies to: Provider · High-risk
How swarmd covers itTracked and evidenced
  • High-risk providers need a linked, approved risk assessment to be ready, and the classification comes up for review every twelve months by default.
  • Evaluation sets send real test messages through the production policy chain and check every hop. A passed run within 30 days, by default, satisfies the testing obligation.
Evidence:
The risk assessment, and evaluation runs with per-hop verdicts.
Limits:
The risk management process is yours. Evaluation runs start on demand; there is no schedule yet.
The obligation
Art. 10

Data and data governance

Training, validation and testing data follow documented governance practices and are relevant, sufficiently representative and, as far as possible, free of errors and complete. Since the Omnibus, using special-category data to detect bias falls under Art. 4a.

Applies to: Provider · High-risk
How swarmd covers itTracked and evidenced
  • High-risk providers need a linked, approved data governance record to be ready.
  • Detectors (Microsoft Presidio, the piiranha model, Amazon Comprehend, regular expressions) can block personal data in flight, or mask every value they find, before it reaches the next agent, tool or model.
  • Closing a retirement case requires an attestation of what happens to the system’s data.
Evidence:
The document, and masking decisions on the audit trail.
Limits:
Training, validation and test data sit outside the platform. Detectors run only where a policy binds them.
The obligation
Art. 11, Annex IV

Technical documentation

Technical documentation, drawn up before release and kept current, covering the elements of Annex IV.

Applies to: Provider · High-risk
How swarmd covers itTracked and evidenced
  • Linked as a governed document with status, validity and an optional SHA-256. Superseding it reopens the obligation until the new version is approved.
  • A tenant policy can require that a different person approves a document from the one who linked it.
Evidence:
Document history with the hash you supplied, on the governance timeline and the audit trail.
Limits:
swarmd stores the link and the hash you supply; it never fetches the file, so it cannot tell if it changed.
The obligation
Art. 12

Record-keeping

High-risk systems allow automatic recording of events over their lifetime, so their operation can be traced and risks identified.

Applies to: Provider and Deployer
How swarmd covers itEnforced by swarmd
  • Exchanges through the relay are recorded at each stage, with their participants, correlation id and content: agent to agent, channels, people, MCP tools and LLM gateways. A request is refused if its record cannot be queued.
  • Each record is hashed with SHA-256. Every five minutes the hashes are sealed into a Merkle root, chained and signed with Ed25519; an RFC 3161 timestamp can be added. Verification re-hashes a sample of each checkpoint’s records (10% by default) to catch edited content.
  • It cannot be switched off for traffic through the relay.
Evidence:
The audit trail and the trace of any single exchange, with checkpoint verification under Immutable proof.
Limits:
Covers traffic routed through swarmd: a call an agent makes straight to a model or tool is not seen. Records the audit service has not yet accepted wait in a queue and keep retrying, with an alert on the backlog. RFC 3161 timestamping is off until you enable it.
The obligation
Art. 13

Transparency and instructions for use

High-risk systems come with instructions that let deployers interpret the output and use the system properly, including the provider’s contact details.

Applies to: Provider and Deployer · High-risk
How swarmd covers itTracked and evidenced
  • Every high-risk system needs approved instructions for use linked to be ready, and a provider contact can be recorded on the system.
Evidence:
The linked instructions and the contact.
Limits:
Writing the instructions is yours.
The obligation
Art. 14

Human oversight

People can effectively oversee high-risk systems in use: interpret outputs, decide not to use them, override them, and stop the system.

Applies to: Provider and Deployer · High-risk
How swarmd covers itEnforced by swarmd
  • Human-in-the-loop policies hold an agent’s turn until a person approves or rejects it. Readiness checks that a high-risk agent has one bound.
  • Every agent has a kill switch. Freezing an agent stops its conversations, its MCP tool calls and its LLM gateway calls. Suspension engages it with a reason, and it cannot be released by hand while suspended.
  • On high-risk agents with oversight persons assigned, only those people, the owner and the deputy may resolve holds; anyone else is refused.
Evidence:
Each hold with who decided, when and under which policy; the kill-switch log.
Limits:
Holds apply to agent replies, not to individual MCP tool calls or LLM requests; a reply that cannot be held is blocked instead. Until an oversight person is assigned, any approver can resolve a hold, and readiness flags the gap. Holds wait in the approval queue and notify no one.
The obligation
Art. 15

Accuracy, robustness and cybersecurity

High-risk systems reach an appropriate level of accuracy, robustness and cybersecurity, and resist attempts to alter their use or outputs. For systems that are also products under the Cyber Resilience Act, meeting its essential requirements is presumed to meet the cybersecurity part.

Applies to: Provider · High-risk
How swarmd covers itTracked and evidenced
  • Policies can block, mask or warn on content at every hop through the relay, not just at the model, and can hold an agent’s reply for human review.
  • Evaluation sets turn policy and safety promises into repeatable pass/fail tests: the verdict expected at each hop, the fields that must be masked, and what the delivered message must or must not contain.
  • Tenant isolation and rate limits are built in, and self-hosting keeps the control layer inside your perimeter; only the licence check, image pulls and optional services such as Amazon Comprehend call out.
Evidence:
Policy decisions and evaluation history.
Limits:
There is no built-in prompt-injection detector; you write the rules. swarmd does not measure model accuracy; declare it in your documentation.
Chapter III · Sections 3–5

Obligations of providers and deployers

The operational duties: who is accountable, what is kept and for how long, what happens when something goes wrong, and what deployers owe the people affected.

3 enforced · 9 tracked · 2 yours
The obligation
Art. 16(b), (h), (l)

Identification, CE marking and accessibility

Providers put their name and address on the system or its documentation, affix the CE marking, and meet EU accessibility requirements.

Applies to: Provider · High-risk
Who covers itYour responsibility

Marking the product and making it accessible happen in your product, not in the platform.

  • What swarmd gives you: A provider contact recorded on the system, and the declaration of conformity tracked as a document.
The obligation
Art. 17

Quality management system

Providers of high-risk systems run a documented quality management system, with clear accountability.

Applies to: Provider
How swarmd covers itTracked and evidenced
  • A linked QMS is mandatory for high-risk providers.
  • Every system needs a named, confirmed accountable owner. An owner inferred from whoever registered it does not count until someone confirms it.
Evidence:
The QMS document and the accountability assignments.
Limits:
The QMS is yours. Building it to EN 18286, cited on 14 October 2026, gives a presumption of conformity for the requirements it covers.
The obligation
Art. 19, Art. 26(6)

Keeping the logs

Providers and deployers of high-risk systems keep the automatically generated logs under their control for at least six months, unless other Union or national law says otherwise.

Applies to: Provider and Deployer · High-risk
How swarmd covers itEnforced by swarmd
  • The audit record has no expiry and no purge job, and the database rejects ordinary updates and deletes of stored rows.
  • Readiness checks the retention floor is at least 183 days, and retirement records a hold of at least six months.
Evidence:
Retention settings, versioned, and holds on the register.
Limits:
Monitoring rollups are kept for 90 days and agent telemetry for 30; the audit record is the log. Database owners can still truncate tables, so on a self-hosted install restrict those rights.
The obligation
Art. 18

Keeping the documentation

Providers keep technical documentation, QMS records and declarations for ten years after placing the system on the market.

Applies to: Provider · High-risk
How swarmd covers itTracked and evidenced
  • At retirement, the ten-year documentation hold is computed from when the system was put into service through swarmd, or from retirement if it never was, and sealed into the record.
Evidence:
The hold on the register and in the sealed evidence pack.
Limits:
The documents live in your document system; keeping them that long is yours.
The obligation
Art. 20

Corrective actions

A provider that finds a high-risk system non-conforming immediately brings it into line, withdraws, disables or recalls it, and informs those concerned.

Applies to: Provider
How swarmd covers itEnforced by swarmd
  • Suspend freezes a system in service, with a recorded reason: non-conformity, serious incident, Art. 79 risk or pending reassessment. Every lift re-runs the readiness gate, a high-risk lift needs a second person, and a Prohibited system cannot be lifted at all.
  • A corrective retirement requires withdrawal or recall, and e-mails the system’s dependants as soon as it is opened.
Evidence:
The state log with reason, actor, approver and readiness at that moment.
Limits:
LLM gateways cannot be suspended; suspend the agents that use them. Suspension sends no e-mail, and retirement notices need SMTP configured.
The obligation
Art. 21, Art. 22

Authorities and authorised representatives

Providers of high-risk systems give authorities the documentation and logs they ask for. Those established outside the EU appoint an authorised representative in the Union by written mandate.

Applies to: Provider · High-risk
How swarmd covers itTracked and evidenced
  • The evidence pack, AI register, incident and audit exports are what you hand over.
  • An authorised representative can be recorded on the system.
Evidence:
The exports, generated from current data or the sealed snapshot.
Limits:
Responding to the authority is yours.
The obligation
Art. 25

Responsibilities along the value chain

A deployer that substantially modifies a system or changes its purpose can become its provider. Suppliers of components to high-risk systems owe information under a written agreement.

Applies to: Provider and Deployer
How swarmd covers itTracked and evidenced
  • MCP servers and LLM gateways inherit the strictest tier of every agent using them, recomputed on every read. A tool server used by one high-risk agent is treated as high-risk.
  • MCP servers declare the data they reach and the most consequential action their tools can take. A server declared as taking irreversible actions or moving money needs attested oversight persons to be ready, at any tier.
  • High-risk tool servers and gateways need a linked supplier agreement. When a new version or refreshed card changes the name or description of a deployer agent, its review is brought forward.
Evidence:
Own and effective tier with the contributing agents, on the register.
Limits:
Inheritance follows subscriptions through swarmd; a tool an agent calls directly is invisible to it. The impact profile is what you declare, and whether a change makes you the provider is your call.
The obligation
Art. 26(1)–(2)

Deployers: use as instructed, with competent oversight

Deployers use the system according to its instructions and assign human oversight to people with the competence, training and authority to exercise it.

Applies to: Deployer · High-risk
How swarmd covers itEnforced by swarmd
  • Oversight persons are named on the system, each with an AI literacy attestation date. On a high-risk agent with named oversight persons, only they, the owner and the deputy can resolve its holds.
  • Policies enforce the instructions that can be expressed as rules: which tools, which data, which actions need a person.
Evidence:
Assignments, attestations and every decision on a hold.
Limits:
If no oversight person is named, anyone with approval permission can resolve holds, and readiness reports the gap. The check does not look at literacy dates and can take up to 30 seconds to see a change; if the registry cannot be reached it uses the last known list, or refuses.
The obligation
Art. 26(4)

Deployers: relevant input data

Where deployers control the input data, they make sure it is relevant and sufficiently representative for the intended purpose.

Applies to: Deployer · High-risk
Who covers itYour responsibility

Whether input data is relevant and representative is a judgement about your use case.

  • What swarmd gives you: Policies and detectors can keep data that should not be there out of the flow.
The obligation
Art. 26(5)

Deployers: monitoring and reporting

Deployers monitor the system’s operation, inform the provider and authorities of risks and serious incidents, and suspend use where needed.

Applies to: Deployer · High-risk
How swarmd covers itTracked and evidenced
  • Readiness for a high-risk agent requires an enabled monitor scoped to it. Alerts go to e-mail, Slack or Microsoft Teams and can be opened as incidents.
  • Suspension is one action with a recorded reason.
Evidence:
Monitors, alerts, incidents and the state log.
Limits:
Telling the provider and the authority is yours. Monitors run only with the analytics store (ClickHouse) enabled, as in the standard install, and e-mail alerts need SMTP.
The obligation
Art. 26(7), (9), (11)

Deployers: notices and impact assessments

Deployers inform workers before workplace use, use the provider’s information for their DPIA, and tell people when an Annex III high-risk system makes or assists decisions about them.

Applies to: Deployer · High-risk
How swarmd covers itTracked and evidenced
  • A worker notification is mandatory for recruitment and workforce-management use cases, and an affected-person notice for every high-risk deployer. A DPIA can be linked.
Evidence:
The linked notices and DPIA.
Limits:
Giving the notices and writing the DPIA are yours.
The obligation
Art. 27

Fundamental rights impact assessment

Public bodies, private entities providing public services, and deployers assessing creditworthiness or pricing life and health insurance carry out a FRIA before first use. It can build on an existing DPIA.

Applies to: Deployer · High-risk
How swarmd covers itTracked and evidenced
  • A linked FRIA becomes mandatory when a deployer’s classification names an essential-services use case under Annex III point 5.
Evidence:
The FRIA and the classification that required it.
Limits:
Public bodies and private entities providing public services need a FRIA for every Annex III use except critical infrastructure. swarmd does not know which you are and will not require it there, so link it yourself. Notifying the market surveillance authority is yours.
The obligation
Art. 43, Art. 47

Conformity assessment and declaration

Providers complete the conformity assessment and sign an EU declaration of conformity, kept for ten years.

Applies to: Provider · High-risk
How swarmd covers itTracked and evidenced
  • Both are mandatory documents. In Block mode the gate refuses to put the system into service until they are approved.
Evidence:
The documents, and the readiness recorded when the system is put into service.
Limits:
The assessment itself is yours, or a notified body’s. The gate starts in Warn mode; switch high-risk tiers to Block. Putting into service is a governance step the relay does not check, so an agent can carry traffic before it.
The obligation
Art. 49, Annex VIII

Registration in the EU database

Providers register Annex III high-risk systems before release, and Art. 6(3) exempt systems in simplified form; critical-infrastructure systems are registered nationally. Public-authority deployers register their use.

Applies to: Provider and Deployer · High-risk tiers
How swarmd covers itTracked and evidenced
  • The Annex VIII extract fills the sections that apply to the system’s role and tier from the record, says where each value came from, and lists what is missing.
  • The registration reference is a mandatory document, and retiring the system prompts its withdrawal.
Evidence:
The Annex VIII extract per system.
Limits:
You submit the registration. A draft or expired document is reported as missing, with its status. Values the platform does not hold, such as Member States, certificates and the deployer’s contact details, are left for you, as is a public authority’s own registration.
Chapter IV

Transparency for every AI system

Article 50 has applied since 2 August 2026 and reaches far beyond high-risk: any agent that talks to people or generates content. swarmd adds the disclosure and the content marking in the relay, and tracks the rest.

2 enforced · 1 tracked
The obligation
Art. 50(1), (5)

Telling people they are talking to an AI

Systems that interact directly with people tell them so, clearly, at the latest at the first interaction.

Applies to: Provider · Agents that interact with people
How swarmd covers itEnforced by swarmd
  • The relay adds your notice as its own message ahead of the agent’s first reply, or ahead of each reply, on every channel or only the ones you choose.
  • Only on the leg that reaches a person: agent-to-agent calls never carry it.
  • Every notice is an audit event, and readiness flags any agent classified as talking to people that has no disclosure configured.
Evidence:
The disclosure event per conversation.
Limits:
You turn the notice on per agent, and your channel has to show it: the swarmd channel client hands it over separately, and custom integrations must display it. It is added to message:send replies over A2A JSON-RPC and REST; direct LLM gateway calls and replies collected later by polling or push notification get none yet. If the settings cannot be read, a generic notice is added. Say in the text on whose behalf the agent acts, as the Commission’s guidelines expect.
The obligation
Art. 50(2)

Marking synthetic content

Providers of generative systems mark outputs in a machine-readable format, detectable as AI-generated. Generative systems on the market before 2 August 2026 have until 2 December 2026.

Applies to: Provider · Agents that generate content
How swarmd covers itEnforced by swarmd
  • Once marking is on for an agent, each agent-authored message and artifact in its replies carries a machine-readable provenance block (swarmd-provenance/1) naming the generating agent and the time.
  • Those replies also carry X-Swarmd-Synthetic-Content and X-Swarmd-Provenance headers, on agent-to-agent legs as well as person-facing ones.
Evidence:
The provenance manifest on each result.
Limits:
Metadata and headers only, with no watermark in text, images, audio or files. The Code of Practice expects at least two techniques, including watermarking, so add one where you generate content. Not yet applied to replies collected later by polling or push, or to LLM gateway and MCP responses. If the settings cannot be read, replies are marked anyway.
The obligation
Art. 50(3), (4)

Emotion recognition and deepfakes

Deployers inform people exposed to emotion recognition or biometric categorisation, and disclose deepfakes and AI-generated public-interest text.

Applies to: Deployer · When the classification says so
How swarmd covers itTracked and evidenced
  • Both are triggered by the classification and discharged by an attestation recording who made it and when, which lapses after twelve months.
Evidence:
The attestation with signer, date and note.
Limits:
Informing the people exposed and labelling the content are yours; swarmd records that it is done.
Chapter V

General-purpose AI models in your stack

Most agents run on someone else’s foundation model. If you build a system on it, its provider owes you documentation, unless the model is open-source without systemic risk; swarmd keeps it on the gateway that routes to the model.

1 tracked · 1 yours
The obligation
Art. 53(1)(b), Annex XII

Documentation from your model provider

Providers of general-purpose AI models give the providers who build on them the information they need to meet their own obligations.

Applies to: Provider · LLM gateways serving high-risk agents
How swarmd covers itTracked and evidenced
  • LLM gateways have their own governance record and inherit the strictest tier of the agents using them. At high-risk, the model’s Annex XII documentation and a supplier agreement become mandatory.
Evidence:
The gateway’s record, with its inherited tier and documents.
Limits:
Obtaining the documentation is yours, and providers of open-source models without systemic risk need not supply it. A gateway’s inherited tier counts only classified agents with active access to it; direct callers do not raise it.
The obligation
Art. 53–55

Obligations of model providers

Whoever places a general-purpose AI model on the market documents it, publishes a training-data summary and respects copyright; systemic-risk models have further duties.

Applies to: Provider · Only if you train, substantially fine-tune or release a model
Who covers itYour responsibility

swarmd governs systems built on models, not the models themselves. Substantially fine-tuning a model and releasing it can make you its provider.

  • What swarmd gives you: Not applicable to building agents on a model; relevant only if you release a model yourself.
Chapters IX and XIII

Monitoring, incidents, explanations and withdrawal

Compliance continues after go-live: watch systems in use, report serious incidents against a clock, answer the people affected, and withdraw systems in a way you can prove later.

1 enforced · 3 tracked · 2 yours
The obligation
Art. 72

Post-market monitoring

Providers systematically collect and analyse data on how high-risk systems perform throughout their lifetime, under a documented plan.

Applies to: Provider · High-risk
How swarmd covers itTracked and evidenced
  • For a high-risk agent, readiness requires an enabled monitor scoped to it and an evaluation passed within the freshness window. Threshold, change and outlier monitors run over the audit trail.
  • Your post-market monitoring plan can be linked to the record, beside the monitors and evaluations that carry it out.
Evidence:
Monitor definitions, alerts and evaluation runs.
Limits:
The plan is yours. Built-in governance reminders, such as reviews falling due, are not available yet; use the register’s filters on a routine.
The obligation
Art. 73

Reporting serious incidents

Providers of high-risk systems report serious incidents to the market surveillance authority immediately, and at the latest within 15 days of awareness, 10 days for a death, and 2 days for widespread infringement or critical-infrastructure disruption. Deployers who find one tell the provider first.

Applies to: Provider and Deployer · High-risk
How swarmd covers itTracked and evidenced
  • Six categories, each with its legal deadline, counted from the awareness date.
  • An alert about an agent, MCP server or LLM gateway can become an incident in one step, with the alert attached as evidence. The incidents queue puts overdue reports first and records the authority’s reference when filed.
Evidence:
Every incident in the incident export, with each change recorded on the audit trail.
Limits:
swarmd keeps the clock and the record; it does not file the report or send reminders as a deadline nears. A draft has no clock until someone confirms it. The Commission’s reporting template is still a draft.
The obligation
Art. 3(23), Art. 79

Substantial modification and systems presenting a risk

A substantial modification needs a new conformity assessment. Authorities can require corrective action for systems that present a risk.

Applies to: Provider
How swarmd covers itTracked and evidenced
  • Require reassessment moves an in-service system back to Assessed with the reason recorded, and it must pass the readiness gate again. Art. 79 risk is a recorded suspension reason.
Evidence:
The state log.
Limits:
Deciding that a change is substantial is yours. Reassessment does not stop traffic; suspend the system if it must stop.
The obligation
Art. 18, 20, 26(6)

Retiring a system with evidence

Withdrawing a system does not end the duties: documentation and logs outlive it, and a provider withdrawing a non-conforming system informs deployers, distributors and, where relevant, importers and the authorised representative.

Applies to: Provider and Deployer
How swarmd covers itEnforced by swarmd
  • A retirement case cannot complete until every mandatory item on its checklist is met: a decommissioning plan and a data disposition statement, plus, for a high-risk system, notices to affected people and deployers and, where you are the provider, the EU database status. High-risk retirements need a second person.
  • Completion deregisters the system, notifies dependants, sets the retention holds, snapshots the whole record immutably and records the audit checkpoint taken after it.
Evidence:
The sealed evidence pack with its checkpoint id.
Limits:
Notices need SMTP configured. Retired is final: a returning system is registered and classified anew. Only under Block mode must a high-risk agent or MCP server in service go through a retirement case; other systems, and every LLM gateway, can be deregistered directly, without the checklist, snapshot or seal.
The obligation
Art. 86

Explaining individual decisions

People significantly affected by a decision based on an Annex III high-risk system, other than critical infrastructure, can ask the deployer for a clear explanation of the system’s role and the main elements of the decision.

Applies to: Deployer · High-risk, Annex III
Who covers itYour responsibility

Writing and giving the explanation is yours; there is no explanation workflow in the platform.

  • What swarmd gives you: The trace of the exchange — inputs, policies applied, tool calls and outputs — is the raw material for the explanation.
The obligation
Art. 111

Systems already on the market

Transitional rules set different deadlines for systems placed on the market before certain dates, such as the Art. 50(2) grace period to 2 December 2026.

Applies to: Provider and Deployer
Who covers itYour responsibility

It does not change the obligations or deadlines swarmd shows; apply the transitional rules yourself.

  • What swarmd gives you: The date a system was placed on the market can be recorded with its classification and appears in the evidence pack.
From go-live to retirement

A lifecycle the Act can recognise.

Every system carries a governance state beside its operational status. Each transition is an immutable event with a reason, the person who made it, any approver, and the system's readiness at that moment. Under Block mode, a high-risk system with unmet mandatory obligations cannot be put into service, and a high-risk agent or MCP server in service can only be withdrawn through a retirement case.

  1. 01DraftRegistered, not yet assessed. Traffic flows; the register shows the gap.
  2. 02AssessedClassified, and approved by a second person where the tier needs it.
  3. 03In servicePut into service through the readiness gate, which refuses an unready high-risk system in Block mode. Starts the ten-year documentation clock.
  4. 04SuspendedCorrective action. Kill switch engaged until the suspension is lifted; high-risk lifts need a second person.
  5. 05RetiringA retirement case is open with its evidence checklist.
  6. 06RetiredDeregistered, snapshotted and sealed. Retention clocks running.

Serious incidents, on the Article 73 clock

Turn a monitoring alert about an agent, MCP server or LLM gateway into an incident, with the alert attached as evidence. The deadline follows the category and the awareness date, and the incidents queue puts overdue reports first. Filing the report is yours.

2days
Widespread infringement, or serious and irreversible disruption of critical infrastructureArt. 73(3)
10days
Death of a personArt. 73(4)
15days
Serious harm to health, property or the environment, or infringement of fundamental-rights obligationsArt. 73(2)

Evidence an auditor can verify, not just read

Governance decisions are written to the same audit trail as the traffic they govern: each record hashed with SHA-256, sealed every five minutes into a chained, Ed25519-signed Merkle checkpoint, and optionally timestamped under RFC 3161. Retired systems are snapshotted immutably, and the checkpoint taken after retirement is recorded with their evidence pack.

Evidence packOne JSON per system: every classification with its answers and signatures, owners, documents with hashes, attestations, readiness at each state change, the state log, incidents and retirement. Retired systems are read from the sealed snapshot.
Annex VIII extractThe EU database registration fields for sections A, B and C, filled from the record with the source of each value, and a list of what is still missing.
AI registerYour AI asset inventory as CSV or JSON: every agent, MCP server and LLM gateway with own and effective tier, role, owner, review date, lifecycle state and retention holds.
Serious incidentsEvery incident with category, awareness date, deadline, filing reference and outcome, soonest deadline first.
Why it goes further

Documents, dashboards — or the system itself.

AI Act tooling usually comes from one of two directions. Governance, risk and compliance suites mostly hold questionnaires and policy documents, and rarely see the running system. Observability tools see the traffic, but rarely know about tiers, owners or obligations. swarmd sits in the path of the exchanges routed through it — between people, agents, tools and models — and carries the governance record with them, so it can do both and connect them.

Capabilities of typical governance tools, typical observability tools and swarmd
CapabilityTypical GRC suiteTypical LLM observabilityswarmd
Risk tier derived in the Act’s order, from answers a named person signsPartial—NoYes
Register covers agents, MCP tool servers and LLM gateways, with inherited tiersPartialPartialYes
Obligations switch on from tier, role and Annex III use caseYes—NoYes
Controls checked against live configuration (policy bindings, monitors, evaluations, retention), not a questionnaire—NoPartialYes
Art. 50 disclosure and synthetic-content marking added to agent replies in the relay—No—NoYes
On high-risk agents, human review restricted to the named oversight persons—No—NoYes
Event log sealed by signed, chained checkpoints—NoPartialYes
Art. 73 incident clocks, raised straight from monitoring alertsPartial—NoYes
Gate that can refuse to put an unready high-risk system into service (Block mode)—No—NoYes
Retirement captured in a write-protected evidence pack—No—NoYes
Deploys on your own infrastructure, in the jurisdiction you choosePartialPartialYes

The first two columns describe the typical scope of each category of tool, not any named product. The swarmd column is subject to the limits stated against each provision above.

Shared responsibility

What stays with you.

No platform makes you compliant on its own, and one that claims to is a risk in itself. swarmd enforces controls on the traffic it carries, and records and evidences the rest — who decided what, when, on which answers, with which documents. Beyond the provisions marked Yours, these stay with your organisation everywhere:

  • Legal judgement.swarmd derives a tier from the answers your people sign; it does not decide what the right answers are.
  • Filing with authorities.Incident reports, EU database registration and declarations of conformity are made by you; the record holds your reference to them.
  • Writing the documents.Risk assessments, technical documentation and FRIAs live in your own document system; swarmd links them, tracks their status and records the SHA-256 you supply.
  • Routing traffic through swarmd.Controls apply to what passes through the relay. An agent that calls a model or tool directly is outside them.

This page is a product analysis, not legal advice. Article references are given so your compliance lead can check the reasoning. Dates and provisions reflect Regulation (EU) 2024/1689 as amended by the Digital Omnibus on AI, reviewed on 18 October 2026; guidance and standards continue to develop, and your obligations depend on your role and your systems.

Bring your agents under the Act

Book a walkthrough of the AI register, classification and evidence pack on your own agents, or start a free on-prem trial.
Control the exchange
Integrate once. Govern every agent you route through swarmd. Keep the evidence from day one.
Scale with your team
Pick a plan built for growing teams and regulated environments
Risk. Control. Compliance. On your prem.
resources
DocsPlatform status
contact
Contact usLinkedin
© 2026 swarmd.ai. All rights reserved. swarmd.ai® is a registered trademark.
Privacy policyTerms & conditions