We’ve spent the past few months mapping EU AI Act requirements to what AI agents actually need to do at runtime. We’re sharing our findings because honestly, we think more people should be building agents—but in a way that’s compliant from day one.

The Problem: Agents Are Moving Fast, Rules Are Here Now

AI agents are everywhere suddenly. Customer support agents handling tier-1 inquiries. Code generation agents submitting PRs. Agents booking meetings, updating CRMs, processing invoices. The velocity is remarkable—we went from “interesting demos” to “running in production” in months.

But here’s the thing: we genuinely don’t know where this is heading. Will agents become more “autonomous”? Will they stay as simple automation tools? Will enterprises adopt them widely, or will regulatory uncertainty slow everything down?

What we do know: organizations deploying agents need them to behave. Not just “don’t hallucinate” behave, but “comply with our company values and legal obligations” behave. And with the EU AI Act now in force, that’s not optional anymore.

What the AI Act Actually Requires

The Act isn’t just about high-level principles. It has specific, technical requirements. Three main categories:

1. Workforce Education (Article 4)
Your team needs to understand what AI systems do, their limitations, and their legal obligations. This one’s on you—training delivery isn’t something a tool can automate.

2. Documentation (Article 11, Annex IV)
Before deployment, you must document purpose, risk classification, data governance, and technical specifications. For high-risk systems, this extends to conformity assessments and EU database registration (Article 71).

3. Operational Control (Articles 9-15)
The big one. Risk management, human oversight, logging, incident reporting, post-market monitoring. This is where runtime compliance happens.

The Documentation Challenge

Let’s start with documentation because it’s deceptively hard for agents.

Traditional software? You write docs once, maybe update them when you ship new features. AI agents? They’re non-deterministic. The same prompt can yield different tool call sequences. Agent behavior evolves as you tune models or adjust prompts.

The Act requires technical documentation that proves compliance (Annex IV). For agents, this means capturing:

  • Purpose and intended use: What is this agent supposed to do?
  • Risk classification: Is this minimal, limited, or high risk?
  • Data governance: What data does it access? How is PII handled?
  • Technical specifications: What models? What tools? What decision logic?

Here’s how we handle it in Kyvvu:

from kyvvu import Kyvvu

kv = Kyvvu(api_key="your-key")
kv.register_agent(
    agent_key="customer-support-agent",
    name="Customer Support Agent",
    purpose="Handles tier-1 customer inquiries",
    risk_classification="HIGH",  # Per Article 6
    environment="prod"
)

One function call captures the essentials. From there, every action the agent takes gets logged automatically with full context—inputs, outputs, internal model calls. That becomes your technical documentation, generated continuously as the agent runs.

The Logging Requirement

Article 12 requires automatic logging throughout the system’s lifetime. For high-risk systems, logs must enable:

  • Identifying situations that may present risks
  • Facilitating post-market monitoring
  • Enabling deployer oversight

This isn’t “log to a file somewhere” logging. The Act requires structured, traceable records. For biometric identification systems, it even specifies what to log: timestamps, reference databases, matched inputs, and who verified results.

For agents, we need to log every step:

@kv.log_step("LLM_CALL")
def generate_response(user_query):
    response = llm.invoke(
        prompt=f"User: {user_query}",
        model="gpt-4",
        temperature=0.7
    )
    return response

@kv.log_step("TOOL_CALL", has_write_permission=True)
def update_customer_record(data):
    return database.update(data)

The @kv.log_step() decorator captures everything: function inputs, outputs, internal LLM calls (via context variables), execution time, any errors. Each log entry includes task_id and step number, so you can reconstruct the complete execution trace.

We use hash-chained logging—each log entry includes a hash of the previous entry. Tamper-proof audit trails, required by Article 19.

The Human Oversight Problem

Article 14 requires human oversight for high-risk systems. This isn’t “a human should check things sometimes.” It’s specific:

  • Systems must be designed to enable effective oversight
  • Humans must be able to interpret outputs and intervene
  • For certain biometric systems, decisions require verification by at least two people
  • Deployers must assign qualified personnel with appropriate authority

For agents, this means building in checkpoints:

@kv.log_step("HUMAN_APPROVAL")
def approve_refund(amount, reason):
    # Policy engine evaluates:
    # "All refunds > €500 require human approval"
    return await_human_decision()

Our policy engine evaluates rules in real-time. Define a policy like “All TOOL_CALL nodes with has_write_permission=True require human approval,” and the system enforces it automatically. No hoping developers remember to add approval checks—the runtime guarantees it.

The Incident Reporting Gap

Article 73 requires providers to report serious incidents to market surveillance authorities. But what constitutes a “serious incident” for an agent?

  • Agent exposes PII in a response?
  • Agent approves a transaction it shouldn’t have?
  • Agent bypasses a required human approval checkpoint?

We handle this through policy violations. When an agent violates a policy (say, a PII detection policy on outputs), Kyvvu automatically creates an incident record with full context: task_id, step number, inputs, outputs, which policy was violated, timestamp.

This gives you an audit trail for regulatory reporting and helps you catch problems before they become serious incidents.

Post-Market Monitoring

Article 72 requires continuous monitoring after deployment. For agents, this means:

  • Tracking performance over time
  • Detecting drift (is the agent behaving differently than expected?)
  • Identifying emerging risks

With comprehensive logging, this becomes analytics: “How often does this agent hit the approval workflow? Are those rates changing? Which tools are being called most frequently? Are there patterns in policy violations?”

We’re still building out the analytics dashboard, but the foundation is there—every action logged, every policy evaluation recorded, every incident tracked.

Why We’re Sharing This

Kyvvu is a compliance tool. We built it because we think AI agents are genuinely useful, and we don’t want regulatory uncertainty to slow down the organizations that are doing this responsibly.

But compliance tooling only works if people actually deploy agents. And people will only deploy agents if they trust them to behave.

So we’ve mapped the AI Act requirements to specific technical implementations. We’ve built policy templates aligned with Act articles. We’ve tested this with early pilot partners.

And, we’re sharing it publicly because we want more people building compliant agents. The Act isn’t going away. The enforcement timeline is clear. Organizations that start building compliance in now will move faster than those retrofitting later.

Our Mapping

We’ve documented the complete mapping here. It covers:

  • Every relevant Act article (4, 6, 9-15, 19, 26, 50, 71-73, Annex IV)
  • How each requirement translates to runtime behavior
  • Specific Kyvvu implementations (with code examples)
  • Interactive visualizations of the compliance tree

We’re not lawyers. This isn’t legal advice. But we’ve done the technical work of figuring out what “human oversight” or “automatic logging” or “risk management” actually means for agent systems.

What’s Next

We’re running a co-development pilot program for organizations deploying agents in regulated environments. Six weeks: one week setup, four weeks active monitoring, one week evaluation. You get:

  • Kyvvu deployed on your infrastructure (you keep all data)
  • Monitoring for up to 3 agents
  • Custom policies aligned with your company values and AI Act requirements
  • Full technical report on AI Act readiness

We’re looking for Python-based agents (custom frameworks, LangChain, Copilot Studio) in sectors with real governance requirements—healthcare, banking, insurance, government.

Details here: Kyvvu Pilot Program

We Want Your Input

This mapping is a living document. We’ll update it as:

  • The Commission publishes implementation guidelines
  • Standards organizations release technical specifications
  • We learn from pilot deployments what actually works

If you’re building agents and thinking about compliance, we’d love to hear from you:

  • What requirements are you finding hardest to implement?
  • Where does our mapping miss the mark?
  • What other regulations are you juggling alongside the AI Act?

Email alice@kyvvu.com or comment below.

We’re early in this. The Act is new, enforcement is still ramping up, and best practices are still emerging. But we’re committed to building compliance infrastructure that makes it easier to do the right thing—not harder.

Let’s build agents that behave.