> ## Documentation Index > Fetch the complete documentation index at: https://docs.swarmd.ai/llms.txt > Use this file to discover all available pages before exploring further. # AI governance (EU AI Act) > What the AI register records for every agent, MCP server and LLM gateway, where it lives in the UI, what changes on the day you upgrade, and what the platform does not do for you. # AI governance (EU AI Act) Every agent, MCP server and LLM gateway on the platform now carries a **governance record**: a risk classification under the EU AI Act, the people accountable for it, links to its compliance documents, and a lifecycle state that runs beside its operational status. Together the records form a tenant-wide **AI register**. On top of that sit serious-incident tracking (Art. 73) and the Art. 50 transparency controls that the relay applies to agent replies. The platform's job is to help you **record and evidence** what the Act asks of you: who decided what, when, on which answers, with which documents. It does not make you compliant, it does not take legal decisions for you, and it does not file anything with an authority. The tier it shows is derived from the answers your people give and sign. Nothing on this page or in the product is legal advice. Article references are there so your compliance lead can check the reasoning, not to replace it. *** ## What a governance record holds | Part | What it is | More | | - | - | - | | Risk classification | A signed questionnaire that walks the Act's decision tree and derives a tier: Unclassified, Out of scope, Minimal, Limited, High-risk (exempt), High-risk or Prohibited. High-risk tiers need a second signature. | [Classification](/governance/classification) | | Accountability | Named people in typed roles: accountable owner, deputy, oversight persons, and contacts such as the provider or a data protection contact. | [Governance record](/governance/governance-record#accountability) | | Compliance record | Links to your documents (risk assessment, FRIA, technical documentation, and so on), each with a status and an optional SHA-256. | [Governance record](/governance/governance-record#compliance-documents) | | Readiness | Which obligations apply at the system's tier and whether each is satisfied, unmet or unknown. | [Governance record](/governance/governance-record#readiness) | | Lifecycle | Draft → Assessed → In service → Suspended → Retiring → Retired, with a reason and an approver on every step. | [Lifecycle and policy](/governance/lifecycle-and-policy) | | Transparency (agents) | The Art. 50(1) disclosure notice and Art. 50(2) synthetic content marking the relay applies to replies. | [Governance record](/governance/governance-record#transparency-art-50) | | Incidents | Serious incidents with their Art. 73 reporting clock, opened by hand or from a monitor alert. | [Incidents and evidence](/governance/incidents-and-evidence) | Every change to a record (a classification, a new owner, an approved document, a state change) is written to the governance timeline and to the audit hash chain, so the history can be shown later and shown to be unaltered. *** ## Where things live | Menu | Page | What it is for | | - | - | - | | **Govern › AI register** | `/governance/register` | Every agent, MCP server and LLM gateway with its tier, lifecycle state, owner, review date and open incidents. Your starting point. | | **Govern › Incidents** | `/governance/incidents` | Serious incidents across the tenant, sorted by how soon the Art. 73 report is due. | | **Govern › Approvals**, *Governance* tab | `/gatekeeper-requests?source=governance` | Retirements and suspension lifts of high-risk systems waiting for a second person. | | **Govern › Compliance reports** | `/reports/compliance` | The *EU AI Act evidence* card: register and incident exports, the per-system evidence pack and the Annex VIII extract. | | **Manage › Governance policy** | `/governance/policy` | Tenant-wide rules: gate mode per tier, extra mandatory documents, review intervals, evaluation validity, minimum retention. | | An agent, MCP server or LLM gateway › **Governance** | `…/{id}/governance` | Four pages per system: **Classification** (tier, readiness, and for agents the *Transparency (Art. 50)* settings), **Accountability**, **Compliance record** and **Governance lifecycle** (state, suspension, retirement, incidents). | | **Observe › Alerts** | `/monitor-alerts` | A monitor alert about an agent, MCP server or gateway can be turned into an incident with **Open incident…**. | The second signature on a **high-risk classification** is not in the Approvals queue. It is the **Approve classification** button on the system's Classification page. The register's *Pending approval* tile and the `approvalPending` flag tell you which systems are waiting for one. Everything in the UI is also available through the API. Through the gateway the registry is under `/registry`, so the register is: ```bash theme={null} curl -H "Authorization: Bearer $TOKEN" \ "https:///registry/v1/governance/register?unclassifiedOnly=true" ``` *** ## What you see on day one after upgrading The upgrade creates the governance tables and the register; it does not classify anything or change how traffic flows. Expect this: | | State after the upgrade | | - | - | | Risk tier | **Unclassified** for every existing agent, MCP server and LLM gateway. | | Governance state | **Draft** for all of them. No state events exist yet. | | Accountable owner | For agents and MCP servers, the user who registered them, shown as **Unconfirmed**. LLM gateways have **no owner** until you assign one. | | Readiness | The *accountable owner* obligation is unmet on every system until an owner is assigned or confirmed. Nothing else applies to an unclassified system. | | Transparency | Disclosure **off** and synthetic content marking **off** on every agent. The relay adds nothing to replies. | | Governance policy | Platform defaults: every gate on **Warn**, reviews every 12 months for high-risk tiers and 24 for the rest, evaluations valid 30 days, retention floor 183 days. | | Monitors and incidents | None. | | Register tiles | *Systems* and *Unclassified* equal your whole estate; *Owner unconfirmed* counts every system, gateways included. | **Nothing blocks traffic.** The relay's per-request check (tenant freeze, kill switch, authorisation, subscription, health) does not look at the risk tier, the governance state or readiness. An agent in **Draft** keeps serving exactly as it did before the upgrade. Governance only stops traffic through the kill switch: when someone **suspends** a system that is in service, or when a system in service is classified **Prohibited**. Both show to callers as `Sink agent is frozen`. That makes the first weeks safe to work through at your own pace. It also means the register only describes reality once people have filled it in. *** ## A suggested first week Decide who classifies (agent owners), who gives second signatures (a compliance lead or a second engineer), who edits the governance policy (a tenant administrator), and who exports evidence (anyone with audit read). See [Permissions](#permissions) below. In **Govern › AI register**, the *Accountable owner* column marks every inferred owner as *Unconfirmed*. Open each system's **Governance › Accountability** page and either press **Confirm owner** or name someone else. Assign owners to LLM gateways, which have none. For anything you expect to be high-risk, add a deputy and at least one oversight person with an AI literacy date. Tick **Unclassified only** in the register and work down the list. Each classification takes a few minutes in the wizard on the system's **Classification** page. A high-risk result needs a second person to approve it. MCP servers and gateways inherit the highest tier of the agents using them, so classify agents before their tools. Open **Manage › Governance policy**. Keep the gates on **Warn** while you classify; switch high-risk tiers to **Block** once their records are complete, so a gap stops a new version from being registered instead of only warning about it. Adjust review intervals if your own process is stricter than the defaults. The governance monitor templates (review due, orphaned owner, unclassified agent, stale attestation, incident report due) cannot be enabled in this release, so nothing reminds you of gaps. Put a recurring check in someone's calendar instead: the register tiles and filters (*Review overdue*, *Owner unconfirmed*, *Unclassified only*, *Reassessment pending*) and the Incidents page tiles (*Overdue*, *Due in 7 days*, *Awaiting confirmation*). For high-risk agents, also create a monitor under **Observe › Monitors** whose filter names the agent: that is what the post-market monitoring obligation looks for. See [Governance checks](/governance/incidents-and-evidence#governance-checks). For every agent people talk to, open **Classification › Transparency (Art. 50)**, turn the disclosure on and choose the text. Then check that each of your channel integrations actually shows the notice — see [AI Disclosure Notice](/sdks/typescript/ai-disclosure). Retirement notices to dependants and monitor alerts go through notification-service. Make sure it is enabled in your values file and that SMTP is configured — see [Configuration](/self-hosting/configuration#turning-services-off). *** ## Permissions Governance uses the permissions you already have; there is no separate governance permission. For per-system actions the entity **follows the subject**: agent governance is checked against **Registry**, MCP server governance against **MCP registry**, and LLM gateway governance against **LLM gateway**. | Action | Agents | MCP servers | LLM gateways | | - | - | - | - | | View the governance record, classification history, state log, retirement case | Registry · Read | MCP registry · Read | LLM gateway · Read | | Classify, approve a classification, assign roles, link/approve/supersede documents, attest, change transparency settings, declare an impact profile, suspend/lift/put into service, open/cancel/complete a retirement | Registry · Write | MCP registry · Write | LLM gateway · Write | | Download the evidence pack or Annex VIII extract | Audit · Read | Audit · Read | Audit · Read | Tenant-wide pages: | Action | Permission | | - | - | | View the AI register and its counts | Registry · Read | | Export the register or incidents (CSV, JSON) | Audit · Read | | List governance approvals | Registry · Read | | Approve or reject a retirement or suspension lift | Registry · Write (for any subject type) | | View incidents | Registry · Read | | Open, edit, report or close an incident | Registry · Write | | Open an incident from a monitor alert | Audit · Write | | View the governance policy | Tenant · Read | | Edit the governance policy | Tenant · Admin | There are **no owner-only actions**. Anyone with Write on the entity can classify, approve, assign or retire, whether or not they are the accountable owner. The platform enforces only person-level separation: the second signature on a classification, retirement or suspension lift must come from a **different person** from the one who asked, and the deputy owner must differ from the owner. The one place assignments restrict who can act is human review on high-risk agents in the relay — see [Human oversight in the relay](/governance/governance-record#human-oversight-in-the-relay). The **Approvals** menu item itself is shown to people with access to human review requests; to use its *Governance* tab they also need Registry Read, and Registry Write to decide. *** ## Dates in the Act For context only — your obligations depend on your role and systems, and the timetable has changed once already. | Date | What applies | | - | - | | 1 August 2024 | The AI Act enters into force. | | 2 February 2025 | Prohibited practices (Art. 5) and AI literacy (Art. 4). | | 2 August 2026 | Transparency obligations (Art. 50): disclosure to people interacting with an AI system and marking of synthetic content. | | 2 December 2027 | High-risk obligations for Annex III use cases. These were originally scheduled for 2 August 2026; the Digital Omnibus moved them. | | 2 August 2028 | High-risk obligations for safety components of products under Annex I. | Track the latest guidance and legislative updates yourself. The platform does not change its behaviour by date: obligations show as applicable as soon as a system is classified into a tier that carries them. *** ## What the platform does not do * **Readiness is not enforced at runtime.** Unmet obligations are checked only when someone registers a new agent version, reactivates an agent, publishes to the marketplace or puts a system into service. A system that later loses its owner, lets an attestation lapse or misses its review date keeps relaying. * **Monitors and alerts never suspend anything.** They tell people; a person decides. * **Block mode refuses registry actions, never traffic.** It stops a version being registered or a system being put into service; it does not stop requests to a system that is already running. * **Documents are links, not uploads.** The platform stores the URL, the metadata you enter and the SHA-256 you supply. It never fetches the document, so it cannot verify the hash or notice that the file changed. * **No transitional (Art. 111) logic.** The *placed on the market* date is recorded and exported, but it does not change the tier, the obligations or any deadline. * **Marking is metadata.** Synthetic content marking adds machine-readable metadata and response headers. It does not watermark text, images or audio, and does not embed a C2PA manifest in files. * **Nothing is filed for you.** Incident reports, EU database registration and declarations of conformity are made by you, outside the platform; the record holds your reference to them. * **Suspension does not notify anyone.** Dependants are told when a retirement is opened for a corrective reason and when it completes, not when a system is suspended. * **Retention floors do not delete data.** They are recorded commitments that hold evidence at least that long; they do not schedule deletion. *** ## Next Risk tiers, the wizard, second signatures and inherited tiers. Owners, oversight, documents, readiness and Art. 50 transparency. States, suspension, retirement and the tenant governance policy. Serious incidents, the register, exports and the evidence pack. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.