Regulation (EU) 2024/1689 (the EU AI Act) sets obligations on high-risk AI systems. Article 14 covers human oversight: how operators of high-risk systems are enabled to monitor, understand, intervene, and override the system. STACK is runtime infrastructure for AI agents; this page documents how STACK's primitives address Article 14 clause-by-clause, and which clauses STACK explicitly does not address (so you and your counsel can scope the rest).

STACK is not legal advice and this page does not replace conformity assessment. The Act will continue to evolve through delegated acts and AI Office guidance; we'll update this page as that happens.

Where STACK fits

Article 14 has technical requirements (oversight mechanisms, detection of anomalies, kill switches, audit) and non-technical requirements (documentation of foreseeable misuse, organisational risk management, conformity assessment). STACK addresses the technical half: detectors, audit trail, kill switch, checkpoint-based review, three accountability modes scaled to risk. Roughly half of a typical Article 14 implementation, shipped. The legal, organisational, and documentation halves stay with you (see “What STACK does not cover” below).

Article 14 — clause-by-clause

STACK addresses the runtime-monitoring clauses below. Article 14(2) (documenting foreseeable misuse) and 14(5) (biometric two-person verification) are non-technical or domain-specific and out of scope; see below.

Clause	Requirement	STACK primitives	Detectors
Art. 14(1)	Effective human oversight “High-risk AI systems shall be designed and developed in such a way that they can be effectively overseen by natural persons during the period in which they are in use.”	Real-time security-event stream Checkpoint-based behavioural monitoring Per-operator dashboards	Credential Burst Scope Drift Checkpoint Silence
Art. 14(3)	Oversight commensurate with risk “The oversight measures shall be commensurate with the risks, level of autonomy and context of use of the high-risk AI system.”	Three accountability modes per agent: enforced (auto-revoke on critical signals), logged (record only), standard (review queued) Operator picks the rigor of oversight per agent, per service, per skill Defaults adjustable by tier — Free agents default to enforced, Studio operators choose	—
Art. 14(4)(a)	Duly monitor operation; detect anomalies “Natural persons shall be enabled to properly understand the relevant capacities and limitations of the high-risk AI system and duly monitor its operation, including in view of detecting and addressing anomalies, dysfunctions and unexpected performance.”	Hash-chained audit log with full action lineage Per-agent statistical baseline (rolling last-20-checkout window) Post-hoc review engine surfacing flag reasons Every observation about an agent — identity attestation, scope decision, detector signal, checkpoint approval, skill invocation — attaches as a signed claim to the agent’s passport. A compliance officer reviewing an agent’s behaviour reads one timeline, not five separate audit feeds.	Scope Escalation Pattern Undeclared Access Behavioral Anomaly
Art. 14(4)(b)	Remain aware of automation bias “Natural persons shall be enabled to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system.”	Human-review queue for flagged checkouts Forced review of anomalies before agent continuation	Action Volume Duration Overrun Behavioral Anomaly
Art. 14(4)(c)	Correctly interpret the system's output “Natural persons shall be enabled to correctly interpret the high-risk AI system's output, taking into account the characteristics of the system and the interpretation tools and methods available.”	Declared intent vs. observed action comparator (LLM-graded) Natural-language summaries per checkpoint	Intent Deviation
Art. 14(4)(d)	Decide not to use the system or override its output “Natural persons shall be enabled to decide, in any particular situation, not to use the high-risk AI system or otherwise disregard, override or reverse the output of the high-risk AI system.”	Sub-60-second global passport revocation One-API-call kill switch Proxy mode: revoking in STACK is sufficient — no agent-side chase-down When a passport is revoked, every observation attached to it (identity attestation, detector approval, checkpoint sign-off) is marked revoked at the same instant. No partial state where parts of the agent’s authority survive the kill switch.	Post-Checkout Access
Art. 14(4)(e)	Intervene or interrupt via a stop button “Natural persons shall be enabled to intervene in the operation of the high-risk AI system or interrupt the system through a stop button or a similar procedure that allows the system to come to a halt in a safe state.”	Revoke-by-agent, revoke-by-session, revoke-all endpoints Automatic block on critical-severity signals (configurable per operator)	Delegation Downgrade Undeclared Delegation

Related obligations STACK addresses

Art. 12 — Record-keeping

“High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system… ensuring a level of traceability of the system's functioning appropriate to the intended purpose.”

STACK's hash-chained audit log is the canonical answer here. Every passport issuance, every credential injection, every checkpoint, every revocation lands in an append-only log where any later modification breaks the chain visibly. Exports to JSON / NDJSON / CSV; chain is verifiable externally without trusting STACK.

Each observation attached to a passport is also signed as a COSE_Sign1 message (RFC 9052), the same signed-statement format used by the IETF SCITT working group, Sigstore for software supply-chain trust, and FIDO2/WebAuthn for passkey signatures. Any tool that speaks the format can verify a STACK claim against the public keys at api.getstack.run/.well-known/jwks.json without going through STACK. Chain head signatures will publish to a public transparency log (Sigstore Rekor) for third-party verification once an operator enables that feature.

Art. 15 — Accuracy, robustness, cybersecurity

“High-risk AI systems shall be designed and developed in such a way that they achieve an appropriate level of… cybersecurity, and that they perform consistently in those respects throughout their lifecycle.”

The proxy keeps raw credentials out of the agent process (nothing for prompt injection to exfiltrate). KMS-envelope encryption keeps stored credentials encrypted at rest; on the Enterprise tier the operator brings their own AWS KMS key (CMEK), so STACK cannot decrypt their data without calling their KMS. STACK’s own dependency graph is gated by a 7-day minimum release age and a build-script allowlist on every install (full policy at /standards). Cybersecurity has many other dimensions Art. 15 covers; STACK addresses these three slices and no more.

What STACK does not cover

Honest scope is a stronger procurement story than claiming full coverage. STACK is the runtime control plane. The rest of an Article 14 (and broader high-risk-system) compliance programme stays with you and your counsel:

Art. 14(2) — documenting foreseeable misuses. Provider obligation; requires written analysis of how the system can be misused. Not a runtime mechanism.
Art. 14(5) — biometric two-person verification. For Annex III point 1(a) systems only. Procedural; STACK does not enforce it.
Art. 9 — risk management system. Organisational programme, not a technical product.
Art. 13 — instructions for use. Pre-deployment documentation: model cards, intended use statements, performance metrics.
Art. 17 — quality management system. ISO-9001-shape obligations on the provider.
Art. 27 — Fundamental Rights Impact Assessment. Required for certain Annex III deployers; legal/policy work, not infrastructure.
Art. 72 — post-market monitoring. Provider obligation to track real-world performance and report serious incidents.
Conformity assessment + CE marking. Notified-body engagement for high-risk systems.

Disclaimer

This page is a technical interpretation of Article 14 of Regulation (EU) 2024/1689 (the EU AI Act) as it applies to agent runtime infrastructure. The Act will continue to evolve through delegated acts and AI Office guidance; this page is updated as that happens. It is not legal advice. For conformity assessment and legal review, engage counsel familiar with the EU AI Act.

Contact

Deploying agents in the EU and want to discuss Article 14 specifics: hello@getstack.run.

EU AI Act compliance