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
| Block | Time |
|---|---|
| Concept · guardrails (layered defenses) | 15 min |
| Omnigent policy-engine drill-down | 15 min |
| Insight · two gates never collapsed | 5 min |
| Insight · scope injected at render time | 5 min |
| OpenHands v1 event-sourcing drill-down | 15 min |
| Insight · agent edits as git commits | 5 min |
| Concept · agent-loop (event-bus tab) | 5 min |
| Insight · thinking-signature preservation | 5 min |
| Drill-down · Claude Financial Services | 10 min |
| Drill-down · Comp AI v2 | 10 min |
| Drill-down · AIGovHub CLI | 5 min |
| Concept · sandboxing | 5 min |
Articles → architecture map
The AI Act’s high-risk-systems requirements map cleanly onto choices you’re already considering:
| Article | Architectural answer |
|---|---|
| 9 · Risk management | The four-layer guardrail stack with written rationale |
| 12 · Record-keeping | Event-sourced agent (append-only event log = audit log) |
| 13 · Transparency | Persisted thinking blocks + skill markdown files |
| 14 · Human oversight | Confirmation gate at controller layer + scope from platform |
Omnigent’s policy engine is a working instance of this whole column: the ASK verdict is the Article 14 confirmation gate, every ASK persists as a durable elicitation row (Article 12), the three tighten-only scopes plus a risk_score policy are the Article 9 stack, and the two-gates-never-collapsed rule guarantees automation can never approve on a human’s behalf. Read it as the reference, then decide what your own substrate looks like below.
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? Or — for artifact-centric work — git itself, where every change is an attributed commit on a per-writer ref (the OpenKnowledge approach, agent-edits-as-git-commits). 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:
- The four guardrail layers wired up, with one paragraph each on what they catch.
- An event-sourced agent with the schema for the audit log written down.
- Scope injection from a privileged source, not user chat.
- Per-session sandbox with a documented egress allowlist.
- 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
-
Guardrails concept
Layered defenses are exactly the GRC story. Articles 9, 12, 14 map onto the four layers.
-
Omnigent project
A working policy engine you can read: ALLOW/DENY/ASK gates declared in YAML, layered in three scopes that can only tighten, enforced by a pre-tool hook. ASK = Article 14, the elicitation rows = Article 12.
-
Keep the policy gate and the human-consent gate orthogonal insight
Keep machine policy and human consent as separate gates — an org can block but never silently approve on a person's behalf. A structural Article 14 oversight primitive.
-
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.
-
OpenHands (v1) project
Event-sourced architecture. The audit log is the source of truth — Article 12 by construction.
-
Make the audit trail the storage format — per-writer git refs insight
A second way to make the audit trail the storage format: per-writer git refs + actor footers (agent_type, session, tool version). Article 12 record-keeping with no separate log to drift. Contrast the event-store substrate above.
-
Agent loop concept
Pick the event-bus container. The other three make audit harder.
-
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.
-
Claude Financial Services project
Reference for compliant LLM use in a regulated domain. Conservative tool surface, structured outputs, human approval gates.
-
Comp AI (v2) project
The closest existing data model to a GRC platform. Tenant-scoped RBAC, structured AI integrations, the v1→v2 evolution.
-
AIGovHub CLI project
How to detect and classify AI usage under the AI Act — the taxonomy is the product.
-
Sandboxing concept
Per-session container ID, effective allowlist, egress denials all become audit-log events.
-
Authenticate from a sandbox without the secret ever entering it insight
A single mandatory egress chokepoint where the secret never crosses into the sandbox — an Article 9 risk control and an Article 12 logging point in one.