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
Accountability	Named people in typed roles: accountable owner, deputy, oversight persons, and contacts such as the provider or a data protection contact.	Governance record
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
Readiness	Which obligations apply at the system’s tier and whether each is satisfied, unmet or unknown.	Governance record
Lifecycle	Draft → Assessed → In service → Suspended → Retiring → Retired, with a reason and an approver on every step.	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
Incidents	Serious incidents with their Art. 73 reporting clock, opened by hand or from a monitor alert.	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:

curl -H "Authorization: Bearer $TOKEN" \
  "https://<your-gateway>/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

Give people the right permissions

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 below.

Confirm or assign owners

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.

Classify, person-facing and decision-making systems first

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.

Review the governance policy

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.

Set up a regular check

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.

Turn on disclosure for person-facing agents

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.

Check that notices reach people

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.

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.

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.

Classification

Risk tiers, the wizard, second signatures and inherited tiers.

Governance record

Owners, oversight, documents, readiness and Art. 50 transparency.

Lifecycle and policy

States, suspension, retirement and the tenant governance policy.

Incidents and evidence

Serious incidents, the register, exports and the evidence pack.

Get Started