EU AI Act: Technical Controls for AI Agents

The EU AI Act introduces obligations around transparency, human oversight, risk management, and documentation for AI systems. For engineering teams, the practical question is: which technical controls can we implement today to support those obligations?

This page is a technical page, not a legal one. It describes what TramAI can implement and evidence — and draws a hard line between technical controls and legal compliance.

TramAI does not provide legal advice, automatic legal classification, certification, conformity assessment, or guaranteed compliance. Whether your system falls within the AI Act's scope, and what it must do to comply, is a legal determination for your organization. This page only describes technical controls.

Technical Controls vs Legal Compliance

Compliance has a legal component (scope, classification, obligations) and a technical component (what the system can prove about itself). The two are different jobs:

	Legal compliance	Technical controls
Determined by	Legal analysis of the specific system	Engineering implementation
Example questions	Is this a high-risk system under Annex III?	Does the runtime log every model call and approval decision?
Produces	Classification, conformity assessment, documentation per the Act	Logs, audit trails, registries, evidence artifacts
TramAI's role	None — not legal advice	Implements and evidences the controls

TramAI's position: it can help implement and evidence technical controls. It cannot and does not determine legal compliance.

Controls TramAI Can Implement and Evidence

These controls map to the technical obligations that typically surface for agentic AI systems — human oversight, logging, transparency, and documentation:

Human Oversight

Approval gates — high-risk tool executions suspend until a human authorizes them. The decision is a runtime state transition (PENDING → APPROVED / DENIED / TIMED_OUT), not a prompt instruction. See human approval.
Oversight evidence — every approval lifecycle step (suspended, resumed, completed, uncertain outcome) is emitted as an audit event with actor, timestamp, and decision.

Logging and Traceability

Hash-chained audit trail — every policy decision is recorded in a SHA-256 hash-chained event stream. Each event carries a sequence number, previous-event hash, enforcement point, decision, actor, reason code, and self-hash. Retrospective tampering breaks the chain.
Runtime evidence — dedicated policy.decision and tool.permission evidence families reconstruct what was allowed, denied, or queued per execution.
Incident history — audit events preserve the full history of decisions and failures for a stream, supporting reconstruction after incidents.

Model and Provider Registry

Explicit model registry — every allowed model is registered with an approved entry and a primary route. No model runs without an entry.
Provider trust zones — every provider is classified (LOCAL, EU_CLOUD, GLOBAL_CLOUD), and data classification constrains which zones may handle which data.
Deployment posture evidence — evidence packs summarize the registry, trust-zone mappings, verification receipts, and deployment mode (STANDARD / OFFLINE) as a deterministic, safe-for-auditors JSON artifact.

Risk Controls

Runtime policy — Allow, Deny, and RequireApproval decisions at six enforcement points, with deny-by-default sovereign configuration.
Data classification routing — RESTRICTED data is limited to local providers with no fallback; CONFIDENTIAL data may use local or EU-cloud zones.
DLP — sensitive data (PII, secrets) is redacted from model outputs and tool results, with redaction audit events.
Artifact verification — local model artifacts can be verified at build time with digest receipts.

What Is Roadmap, Not Shipped

Be explicit about the boundary:

Control plane — full inventory, intervention, and explainability surfaces for viewing workflows, policies, approvals, and evidence across a deployment are roadmap direction (TramAI 0.7.0). Preview REST approval surfaces and a reviewer UI exist today but are disabled by default.
Compliance mapping — automated mapping of runtime evidence to specific regulatory obligations is a deferred optional track, not a shipped feature.
Certification / attestation tooling — signing and attestation v2 is a deferred optional track.

None of these are presented as shipped functionality.

What a Technical Evidence File Could Look Like

A governed TramAI deployment can produce, per execution stream:

Policy decisions (policy.decision) — every ALLOW / DENY / REQUIRE_APPROVAL with enforcement point and reason code.
Tool permissions (tool.permission) — tool-level decisions at exposure, execution, and result-reinjection.
Approval lifecycle events — who was asked, who decided, when, and the outcome.
Audit chain hashes — proving the event stream was not altered.
An evidence pack — deployment identity, registry, trust zones, verification receipts, and (for offline deployments) zero-egress probe results.

That file supports a human oversight and transparency narrative. It does not, by itself, constitute legal compliance.

When Not to Use This

If your workload has no human-oversight obligation, approval gates add unnecessary latency — use policy decisions instead.
If the system is fully read-only on public data, the registry and audit trail may be the only controls you need.
If you need a legal conclusion, ask a lawyer, not a library.

Human approval — human oversight mechanics
AI agent governance — governance vs compliance boundary
Runtime governance — the enforcement chain
Tool governance — tool-level controls
Evidence Packs — deployment attestation
Sovereign Mode — registry, trust zones, audit
DLP — data loss prevention
TramAI on GitHub