← Docs index

Compliance — EU AI Act

ownify implements 8 EU AI Act instruments as live platform mechanisms — not roadmap items. Each has a verifiable audit output. The EU AI Act becomes enforceable on 2 August 2026. Fines for non-compliance reach €35M or 7% of global turnover.

Art. 5 — Prohibited Practices Guard

The platform blocks AI uses explicitly banned by the EU AI Act. When a compliance profile is saved, the intended purpose and use-case category are checked against a blocklist of 6 banned patterns:

  • Social scoring by public authorities (Art 5(1)(c))
  • Untargeted facial image scraping (Art 5(1)(a))
  • Emotion recognition in the workplace (Art 5(1)(f))
  • Subliminal manipulation / exploitation of vulnerabilities (Art 5(1)(a)+(b))
  • Predictive policing based on profiling (Art 5(1)(d))
  • Biometric categorisation inferring sensitive attributes (Art 5(1)(e))

If a match is found, the API returns 403 prohibited_practice with the article reference and description. The blocklist is visible in the portal at Dashboard → Agent → Compliance → Art. 5 Prohibited Practices Guard.

Art. 6 — Risk Classification

Every agent is classified at provisioning time as minimal, limited, or high risk. The classification determines which obligations apply. The portal has a risk tier selector and use-case category dropdown (Annex III categories: general, recruitment, education, credit, critical infrastructure, law enforcement, healthcare).

The classifyRiskFromUseCase() function maps use-case categories to risk tiers automatically. The operator can override with an explicit risk tier.

Art. 11 — Technical Documentation

The platform auto-generates a technical documentation dossier per agent, covering: system name, version, provider, intended purpose, risk category, model provider, capabilities, data storage, security measures, transparency status, human oversight, audit trail, and post-market monitoring.

Access via GET /api/tenant/:slug/compliance/tech-doc (view) or PUT (generate + persist). The portal has View, Generate & persist, and Download JSON buttons in the Compliance tab.

Art. 12 — Audit Trail

Every agent action is logged in a SHA-256 hash-chained event log. Events flow from multiple sources: microclaw (agent_message, agent_error, agent_llm_call, agent_tool_call), router (routing decisions), egress scanner (DLP results), a2a-gateway (inbound/outbound A2A calls), and memgate (memory operations).

The portal audit pane shows events with: timestamp, event type (20 kinds), source, hash, verification status. Broken chains are highlighted. Export to CSV/NDJSON. Paginated at 50 events per page.

Art. 14 — Human Oversight

When a compliance profile has human_oversight_required = true, high-risk actions are queued for operator review. The oversight_reviews table tracks pending, approved, rejected, and expired reviews.

The portal has a review queue at Dashboard → Agent → Compliance → Art. 14 Review Queue with Approve/Reject buttons. Each decision is audit-logged.

API: GET /api/tenant/:slug/compliance/reviews?status=pending and POST /api/tenant/:slug/compliance/reviews/:id with {decision: "approve" | "reject", note: "..."}.

Art. 50 — AI Transparency

Three-layer disclosure on every AI-generated output:

  1. Layer 1 — Zero-width watermark: Invisible Unicode characters (U+200B / U+200C) embedded in AI text. Machine-readable, survives copy-paste.
  2. Layer 2 — Visible footer: — via A2A from did:moltrust:... appended to every A2A response.
  3. Layer 3 — Git trailer: Generated-by: did:moltrust:... + AI-Act-Art50: ... on every AI-generated commit.

Every disclosure is automatic — no operator switch, no opt-in.

Annex V — Declaration of Conformity

The platform generates a signed Verifiable Credential (VC) declaring conformity with the EU AI Act. The VC uses the agent’s MolTrust DID as subject, includes the risk tier, intended purpose, and security measures. It is anchored on Base L2 via MolTrust.

Access via POST /api/tenant/:slug/compliance with {action: "declaration"}. The portal shows the full declaration content in the Credentials tab.

GDPR Art. 32 — Encryption (TOMs)

Technical and organisational measures:

  • TLS 1.3 in transit for all service-to-service communication
  • AES-256-GCM at rest for AAE signing keys (per-tenant Ed25519 private keys)
  • Per-tenant Kubernetes namespace isolation (NetworkPolicy enforced)
  • Per-tenant secrets (K8s Secrets, never shared across tenants)
  • Egress DLP scanner (Pro tier and above) — scans outbound for tokens, keys, internal paths

Sovereign Mode (default): all LLM inference on OVH Frankfurt. BYO Mode: external LLM API allowed (Art 32 GDPR gap flagged in compliance assessment).