EU AI Act — what OpsChain provides a deployer

Included from Basic tier

This page is the questionnaire-shaped register of how OpsChain supports an organisation's obligations under the EU AI Act (Regulation (EU) 2024/1689). It is written for procurement and AI-governance reviewers, one row per article, and it is generated from the same mapping the release pipeline attests on every release.

Scope, stated plainly. OpsChain is the governance and evidence layer that AI agents act through. It is not itself a high-risk AI system; it brokers calls to model providers and does not train, fine-tune or host a model; and it makes no claims as a provider of a general-purpose AI model. Every row below therefore describes the platform's support for a deployer's obligations — the organisation that puts AI agents to work in its estate. The deployer's own duties (its risk management system, its notices to workers and affected persons, its data-protection assessment) remain the deployer's; this page says what the platform gives them towards each.

Posture. This is tool-assisted attestation of practice, never certification or legal advice. A row is attested-mechanical only when a named check in the release pipeline's security-audit report passes against the source tree on every release; attested-documentary when the evidence is a page of the AI management system record or the served reference; not-attested when neither holds, with the reason. The statuses are pinned against a committed baseline: a row that attested on the last release and attests lower on the next fails the release step, so the register cannot drift upward on its own.

The register

Article	Obligation (deployer-relevant reading)	What OpsChain provides	Evidence	Status
Art. 9	Risk management system	A standing AI risk register (likelihood, impact, treatment, owner, due date) and an impact assessment per AI use case, completed before the use case's AI lane switches on. The deployer's risk management system is its own; the platform supplies the register shape, the assessment record and the evidence loop that keeps both honest.	AI management system record: risk register, impact-assessment template and the completed assessment (available on request)	attested-documentary
Art. 10	Data and data governance	The model-provider catalogue carries a data-handling-approved marker that gates which providers an AI lane may use; what reaches a model is a decided field subset, masked before transmission, recorded in the use case's assessment. No training, validation or test data set exists in scope — the platform sends inference inputs only. The deployer's duty to keep input data relevant (Art. 26(4)) is supported by the assessment's field map, not decided by the platform.	pipeline check data_handling_marker; opschain docs model-providers ("The data-handling-approved marker"); the completed assessment	attested-mechanical
Art. 12	Record-keeping	Every agent request, applied autonomy tier, refusal, model call and halt is an audit event the server emits — an agent cannot omit its own trail. Attestations sit on a hash-chained evidence ledger that is verified end to end and archived as sealed, re-verified segments. Transcripts of every model exchange are kept under a configurable horizon with export before deletion and legal hold on cited exchanges.	pipeline checks ledger_hash_chain, model_call_event, retention_key; opschain docs governance ("The evidence ledger and attestations"), opschain docs events, opschain docs retention, opschain docs ai-agents	attested-mechanical
Art. 13	Transparency and information to deployers	An AI-type agent must disclose its purpose, model provider, model name and version, adapter, tool surface and credential custody in its manifest before it can enrol; a signed release freezes those disclosures and the trust review renders them. Every exchange that transits the adapter is captured and readable, so the deployer can see what the agent is and what it said.	pipeline check manifest_disclosures; opschain docs ai-agents ("Manifest disclosures", "Adapter-transit transcripts")	attested-mechanical
Art. 14	Human oversight	Autonomy is a tier the server resolves on every request under a per-type ceiling — the AI type ships ceilinged at supervised, so unattended AI mutation is an explicit, evidenced raise, never a default. Supervised work waits in the one approval funnel; a human can suspend an agent, a group or the whole platform in one audited verb, with evidence preserved and resumption under a stepped-up session. The stop button is a base control.	pipeline checks tier_ceiling, approval_gate, halt; opschain docs ai-agents, opschain docs change-governance ("The funnel"), opschain docs platform-halt	attested-mechanical
Art. 15(2)–(3)	Accuracy — levels and metrics	Not attested. Accuracy and non-discrimination thresholds need a per-use-case evaluation harness that is designed but not yet built. Until it lands, the supervised observation window and the approval funnel's history are the interim evidence a reviewer uses.	—	not-attested
Art. 15(4)	Robustness	Rate, budget and token caps on every trust grant refuse a runaway loop before it runs and audit the refusal; when a provider is unavailable the lane degrades to its rule-based path; a halt suspends in place without losing a step.	pipeline checks cap_refused_event, halt; opschain docs ai-agents ("Budget, rate and token caps")	attested-mechanical
Art. 15(5)	Cybersecurity	The platform's own secure-development posture — static analysis always on in the lint gate, an OWASP ruleset, dependency vulnerability scanning and secret scanning on every release — is attested in the same report. No model-vendor software sits in the core product, and under brokered custody a model credential never reaches an agent host.	pipeline checks secure_coding_lint, carve_out; the release pipeline's security-audit report (available on request)	attested-mechanical
Art. 26(1)–(2)	Use per the instructions; oversight assigned to competent persons	The manifest's purpose and tool surface are the instructions of use the platform enforces. Every agent is owned by a named human or team, acts only inside its assigned part of the estate, and starts at the advise-only floor until a human grants more.	pipeline checks manifest_disclosures, assignment_floor; opschain docs ai-agents	attested-mechanical
Art. 26(5)	Monitoring the operation; suspension on risk	The trust review aggregates each agent's requests, refusals, spend and approval history on one surface; the deployer suspends an agent, a group or the platform in one audited verb.	pipeline checks cap_refused_event, halt; opschain docs ai-agents, opschain docs platform-halt	attested-mechanical
Art. 26(6)	Keeping the automatically generated logs	Events, transcripts and the evidence ledger are retained under configurable horizons (defaults: events never aged, transcripts 365 days, the ledger's hot window 730 days before sealed archive). A deployer sets them to the six-month floor or its sector's longer period; aged rows are exported before deletion, never silently dropped.	pipeline checks retention_key, ledger_hash_chain; opschain docs retention, opschain docs governance ("Sealed-segment archival")	attested-mechanical
Art. 26(7), (9), (11)	Informing workers, data-protection assessment, informing affected persons	The impact-assessment template's affected-parties section is the record shape the platform supplies for each use case. The deployer's notices and its data-protection impact assessment are the deployer's own acts.	AI management system record: the impact-assessment template and the completed assessment	attested-documentary
Art. 72	Post-market monitoring	Review cadences open review campaigns on a schedule and an overdue review draws a loud event — overdue reviews are themselves evidence. The per-agent trust review is the monitoring surface. Estate-wide token usage telemetry and an agent posture page are planned and will extend this row when they ship.	pipeline checks review_cadence, model_call_event; opschain docs governance ("Review campaigns and cadences"), opschain docs ai-agents	attested-mechanical

Thirteen rows: ten attested-mechanical, two attested-documentary, one not-attested.

How to read the evidence column

• Pipeline check name — a named check in the release pipeline's security-audit report. It reads the product's source tree on every release: the check named is the one whose pass makes the row attested-mechanical, and a reviewer can ask for the report of any release to see the check's result and the file it found the evidence in.
• opschain docs <page> — a page of the embedded reference, served by the product itself, so what the page says and what the product does ship together.
• AI management system record — the policy, scope statement, risk register and impact assessments kept beside the product's source; provided to a reviewer on request.

What this page is not

It is not a conformity assessment, not legal advice, and not a claim that OpsChain or any agent running on it is compliant with the EU AI Act. The Regulation's obligations fall on the provider of an AI system and on its deployer; this page is the honest statement of what the platform gives the second of those towards its duties, with the gaps named. The sister register for the NIST AI Risk Management Framework is opschain docs compliance/nist-ai-rmf.