The EU AI Act is (partly) in force, with the high-risk obligations landing in August 2026. Translating its legal text into technical requirements for AI agents is not straightforward. Most AI governance tooling takes a top-down approach: policies written in documents, referenced during audits, with no mechanical link to what agents actually do in production.
Kyvvu is the opposite. We are the bottom-up data producer and enforcement layer you need underneath every agent you deploy — the runtime layer that makes AI Act obligations mechanically verifiable instead of aspirational.
This page explains how.
What you’ll find here:
- Why atomic behaviors and policies on paths are the right primitives for AI Act compliance
- Which articles map directly to runtime enforcement
- What Kyvvu produces, at the behavior level, that an auditor can actually check
Important: This is a technical resource, not legal advice. The mapping reflects our current understanding and will evolve. Email maurits@kyvvu.com if you spot gaps or disagree.
The core insight: policies on paths
AI agents built on large language models are non-deterministic. The same prompt, in the same environment, can produce different sequences of actions. This is part of what makes them useful. It is also the central governance problem.
Traditional safety engineering validates a system’s behavior at design time. There is a specified set of things the system does; you verify it, document it, deploy it. AI agents break this model. There is no single expected behavior to validate — there is a space of possible behaviors, and it shifts every time you change the underlying model.
Crucially, governance violations rarely live in individual actions. They live in the paths agents take. An agent reading a customer record is fine. An agent reading a customer record, calling an external tool, then writing data back — that sequence may or may not be fine depending on the state of the system, the upstream context, and the agent’s authorization. Reviewing each step in isolation will not surface the problem. You have to evaluate the full workflow.
This is what Kyvvu calls policies on paths: runtime rules that evaluate each proposed behavior in the context of everything the agent has already done on this task. It is the approach described in our arXiv paper Runtime Governance for AI Agents: Policies on Paths, and it is the architectural pattern that makes the AI Act’s runtime obligations mechanically enforceable.
Why this matters for the AI Act
Three of the most operationally demanding parts of the AI Act require information that only exists at runtime:
- Article 9 (Continuous risk management) — risk must be managed throughout operation, not just at deployment. That requires per-execution evaluation.
- Article 12 (Automatic logging) — a verifiable record of system decisions, not just a list of actions taken. That requires capturing the decision point, not only the effect.
- Article 14 (Human oversight) — humans must be able to intervene meaningfully before consequential actions. That requires the system to know, at runtime, when an action is consequential based on the path that led to it.
- Article 15 (Accuracy and robustness) — continuous monitoring of system behavior, including in degraded states.
A design-time document describing the intended behavior of the system cannot answer any of these. A log file of actions that already happened cannot either. You need a layer that sees every atomic behavior, evaluates it in context, and produces structured evidence of the decision.
That is what Kyvvu does.
Coverage summary
The AI Act imposes three broad categories of obligations on deployers and providers of high-risk AI systems:
- Workforce education (Article 4) — training your team on AI risks, limitations, and legal obligations.
- Documentation and registration (Article 11, Annex IV) — recording purpose, risk classification, data governance, and technical specifications.
- Operational control (Articles 9-15, 72-73) — runtime monitoring, human oversight, incident reporting, and post-market surveillance.
Kyvvu automates operational control and produces the evidence needed for documentation and registration. Workforce education remains your responsibility, though the audit trails Kyvvu generates are useful source material for training programs.
All article references link to artificialintelligenceact.eu, the authoritative AI Act resource.
Documentation and registration
Organizations must document AI systems before deployment (Article 11 + Annex IV). Kyvvu produces documentation from what agents actually do, not what they were supposed to do.
| AI Act requirement | What Kyvvu provides |
|---|---|
| Purpose and intended use (Art. 11) | Captured per agent at registration time, versioned alongside policy state |
| Risk classification (Art. 6) | Set per agent (MINIMAL, LIMITED, HIGH); drives which policy sets apply |
| Data governance (Art. 10) | Automatic: every data flow through an intercepted behavior is recorded |
| Technical specifications (Annex IV) | Auto-generated from agent configuration and observed behavior types |
| Quality management (Art. 17) | Hash-chained, tamper-evident logs of every interaction |
| Change management (Art. 11) | Versioned agent and policy state; every change recorded |
| EU Database export (Art. 71) | Export-ready from agent metadata and runtime logs |
Operational control
This is where runtime enforcement is indispensable. The Act’s operational obligations cannot be satisfied by a document or a post-hoc audit log — they require a live control plane.
All risk levels
| Requirement | How Kyvvu enforces it |
|---|---|
| Automatic logging (Art. 12) | Every atomic behavior an agent attempts is intercepted and logged — including the policy decision, not just the action |
| Transparency to users (Art. 50) | Dashboard shows active policies, enforcement decisions, and incidents in real time |
| Log retention (Art. 26(6)) | Configurable retention; minimum six months for deployers; logs are tamper-evident |
High-risk systems
| Requirement | How Kyvvu enforces it |
|---|---|
| Human oversight (Art. 14) | Policies can require human approval before a behavior executes — agent is paused, not logged-after-the-fact |
| Risk management (Art. 9) | Every behavior evaluated on the path so far; violations generate incidents with full context |
| PII protection (Art. 10) | Policies can inspect inputs and outputs and block execution when PII is detected |
| Accuracy monitoring (Art. 15) | Confidence thresholds, drift detection, and degraded-state policies all expressible as path rules |
| Incident reporting (Art. 73) | Structured incidents generated automatically, with the full execution path as evidence |
| Post-market monitoring (Art. 72) | Continuous observation of agent behavior in production; drift and policy-violation trends surfaced via log analysis |
How policies on paths work, technically
A policy in Kyvvu is a rule that answers one question for each atomic behavior an agent attempts:
Given everything this agent has done on this task so far, is it allowed to do this next thing?
The answer is one of: allow, block, or require human approval (stop).
from kyvvu import Kyvvu, Policy
kv = Kyvvu(api_key="your-key", environment="prod")
# Example: Article 14 — human oversight for consequential actions
Policy(
name="Human approval required for customer-record writes",
scope="agent_group:customer-support",
when=(
"behavior.type == 'TOOL_CALL' "
"and behavior.writes_to_system_of_record "
"and path.contains('LLM_CALL_WITH_EXTERNAL_CONTEXT')"
),
require="human_approval",
otherwise="block"
)
The critical detail is in the when clause. The rule doesn’t just look at the current action — it looks at the path. If the agent previously ingested external context, the next consequential write requires a human. If it did not, the rule doesn’t fire. This is what makes enforcement semantically meaningful rather than a blunt permission check.
Each enforcement decision is logged, hash-chained, and attributable to a specific policy. That is the runtime evidence the AI Act’s operational articles require.
Workforce education
Requirement: Article 4 requires AI literacy across your organization — training on risks, limitations, and legal obligations.
Kyvvu’s role: Our logs and incident reports provide real-world, organization-specific examples for training — what did our agents actually do, what was blocked, what required human approval. Delivery of the training itself is your responsibility.
Learn more
External resources:
- EU AI Act Explorer — complete Act text
- AI Act Service Desk — official EC guidance
- A joint perspective on governing AI in physical systems — co-authored with a leading AI conformity and certification partner
Ready to implement? Kyvvu is delivered through authorized partners who handle integration, policy design, and ongoing support.
Commercial inquiries and partnerships: jeroen@kyvvu.com Technical questions: maurits@kyvvu.com
This mapping references Regulation (EU) 2024/1689. While we strive for accuracy, this is not legal advice. Consult legal counsel for compliance guidance.