Tour — Architecting an AI-Act-aware compliance agent

The AI Act doesn’t require an agent. It requires a system that can answer specific questions about what an agent did. This tour walks the corpus for the architectural choices that make those answers cheap to produce.

Pacing

Articles → architecture map

The AI Act’s high-risk-systems requirements map cleanly onto choices you’re already considering:

Decisions to make

Before you start coding, resolve:

• Audit substrate. Postgres event store? An off-the-shelf streaming log (Kafka, Pulsar)? File-based per-tenant? The choice affects query speed, retention, and your operational footprint.
• Scope-injection mechanism. Jinja-rendered system prompt template + DB-sourced bounds is the pattern; what’s your DB schema for “what this tenant’s agent is authorized to touch”?
• Confirmation gate. Synchronous (block until human acks) or asynchronous (queue and proceed when approved)? Different UX, different audit story.
• Multi-tenant isolation. One container per session? Per-tenant? Per-classification-tier? Cost vs cross-tenant-leak risk.
• Prompt caching tier. Regulatory preamble before BP1 (cached across tenants) vs scope+identity between BP1 and BP2 (cached per session).

Output

The architectural backbone you can defend to a privacy officer or external auditor:

1. The four guardrail layers wired up, with one paragraph each on what they catch.
2. An event-sourced agent with the schema for the audit log written down.
3. Scope injection from a privileged source, not user chat.
4. Per-session sandbox with a documented egress allowlist.
5. Thinking blocks persisted to the audit store.

Each item is a discrete piece of work; together they answer most of what an AI-Act audit asks.

Common traps

• Treating compliance as paperwork bolted on later. It is not extra work; it is documentation of work you’d do anyway if you do it deliberately.
• Persisting only the LLM’s final answer. The audit story needs the thinking, the tool calls, the observations — not just the conclusion.
• One audit log per “session” without cross-session correlation. Real audit questions cross sessions (“show me every time agent X was given access to system Y in the last 30 days”). Index for that.

Itinerary

1. Guardrails concept

   Layered defenses are exactly the GRC story. Articles 9, 12, 14 map onto the four layers.

2. Authorized scope injected into system prompt at render time insight

   The cleanest answer to 'how does the agent stay in its authorized scope' that an auditor will accept. Scope from platform DB, not user chat.

3. OpenHands (v1) project

   Event-sourced architecture. The audit log is the source of truth — Article 12 by construction.

4. Agent loop concept

   Pick the event-bus container. The other three make audit harder.

5. Thinking signature preservation across turns (and stripping on model switch) insight

   Persist thinking blocks to the audit store. 'Show your work' is exactly Article 13 transparency.

6. Claude Financial Services project

   Reference for compliant LLM use in a regulated domain. Conservative tool surface, structured outputs, human approval gates.

7. Comp AI (v2) project

   The closest existing data model to a GRC platform. Tenant-scoped RBAC, structured AI integrations, the v1→v2 evolution.

8. AIGovHub CLI project

   How to detect and classify AI usage under the AI Act — the taxonomy is the product.

9. Sandboxing concept

   Per-session container ID, effective allowlist, egress denials all become audit-log events.