Compliance Declaration
Subject
Hivemind AX
Provider
Hypereum Ltd
Company No.
16346019
Regulation
EU AI Act (2024/1689)
Articles
9, 11, 12, 14, 15
Assessed
31 March 2026
Method
Internal audit against production system
Environment
Production (Railway)
Result
COMPLIANT (5/5 articles)

On 31 March 2026, Hypereum conducted an internal compliance audit of Hivemind AX against Articles 9, 11, 12, 14, and 15 of the EU AI Act. The audit was performed against the production system. Every requirement was assessed with evidence drawn from live database queries, API responses, and functional testing. Hivemind AX satisfies all five articles.

The evidence follows.

Art. 12
Record Keeping
Compliant
Art. 9
Risk Mgmt
Compliant
Art. 14
Human Oversight
Compliant
Art. 15
Accuracy & Cyber
Compliant
Art. 11
Tech. Docs
Compliant

Article 12. Record keeping.

Tamper-evident by architecture.

Regulation

High-risk AI systems shall technically allow for the automatic recording of events relevant for identifying risks and substantial modifications throughout the system's lifecycle.

Regulation (EU) 2024/1689, Article 12

Every event in Hivemind AX produces a record in the audit_log table. Every record contains an entry_hash computed as SHA-256 of the record’s contents concatenated with the previous record’s hash. This creates a mathematically verifiable chain. Modifying a single byte in any historical record invalidates every subsequent hash.

What gets recorded. Every mission lifecycle event. Every agent action with role, tokens consumed, output, and timestamp. Every document access in the Secure Data Workspace. Every human oversight intervention. Every sandbox command. Every web access with domain verification verdict. The system does not distinguish between “important” and “unimportant” events. Everything is recorded.

The compliance API returns a documented retention policy. Audit logs, risk assessments, and human oversight events carry a 24-month retention with a deletion policy of “NEVER.” The legal basis is cited explicitly in the API response.

Evidence
GET /api/v1/compliance/retention-policy → 200 { "audit_log": { "retention_months": 24, "deletion_policy": "NEVER", "legal_basis": "EU AI Act Article 12" } } Report hash: 83099f2675146c6f... Previous report hash: a3f7e291b4c8d0f7... Chain integrity: VERIFIED
Verified 31 March 2026
INPUT
a7f3...
SAFETY CHECK
2b91...
OUTPUT
e4c8...

Every block contains the hash of the previous. Change one, the chain breaks.

Article 9. Risk management.

Continuous, automated, evidenced.

Regulation

A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems. The risk management system shall be understood as a continuous iterative process planned and run throughout the entire lifecycle.

Regulation (EU) 2024/1689, Article 9

The risk-assessor service runs automatically at the completion of every mission. Not manually triggered. Not periodic. Every mission, without exception.

The assessor queries live production data. Failed tasks. Sandbox command counts. Encrypted document access events. Coordinator revision counts. Each finding maps to a specific article of the EU AI Act with a severity rating and a corresponding mitigation.

Ten security invariants are verified on every mission. Each tests a specific architectural guarantee. All ten must pass. A single failure means the compliance report flags it.

Evidence
Risk assessment for mission 601a2154... risks_identified: [ { "id": "RISK-1", "source": "sandbox_manager", "article": "Article 15", "severity": "LOW", "description": "Sandbox executed 6 command(s)" }, { "id": "RISK-2", "source": "secure_data_workspace", "article": "Article 15", "severity": "LOW", "description": "Accessed 7 encrypted document chunk(s)" } ] Mitigations: RISK-1 → MIT-1: E2B isolated sandbox, no host access RISK-2 → MIT-2: AES-256-GCM, zero-knowledge DEK/KEK
Verified 31 March 2026
SI-001No plaintext credentials Passed
SI-002Tenant isolation Passed
SI-003Audit trail integrity Passed
SI-004Fail-closed on error Passed
SI-005No banned commands Passed
SI-006Injection scanning Passed
SI-007Multi-agent approval Passed
SI-008Human oversight Passed
SI-009Encrypted storage Passed
SI-010Hash-chained reports Passed

Article 14. Human oversight.

Pause, resume, override, cancel.

Regulation

High-risk AI systems shall be designed and developed in such a way that they can be effectively overseen by natural persons during the period in which they are in use, including by being enabled to fully understand the capacities and limitations of the high-risk AI system and to monitor its operation.

Regulation (EU) 2024/1689, Article 14

During every mission execution, the Human Oversight Panel labelled “HUMAN OVERSIGHT, EU AI Act Art. 14” is visible. Not optional. Not hideable. Four controls are available at all times during execution.

Pause halts execution at the current point. Resume continues from exactly where it stopped. Override opens a modal allowing the operator to modify the last agent output, with the modified text injected into downstream task context. Cancel terminates immediately. Every human intervention is recorded in the human_oversight_events table with event type, timestamp, triggering user, original value, and new value.

Verified by live functional test on 31 March 2026. A mission was launched, paused, resumed, and completed. Both intervention events appear in the database with correct timestamps.

Evidence
Live test executed 31 March 2026: 14:32:01 Mission 601a2154... launched 14:32:18 PAUSE clicked by human_operator 14:32:18 Railway log: "Mission paused" 14:32:45 RESUME clicked by human_operator 14:33:02 Mission completed successfully human_oversight_events table: mission_paused human_operator 14:32:18 mission_resumed human_operator 14:32:45
Verified 31 March 2026
14:32:01 Mission launched
14:32:18 Pause triggered by operator
14:32:45 Resume triggered by operator
14:33:02 Mission completed

Article 15. Accuracy, robustness, cybersecurity.

Defence in depth.

Regulation

High-risk AI systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle.

Regulation (EU) 2024/1689, Article 15

Cybersecurity. AES-256-GCM encryption for every document in the Secure Data Workspace. Each document gets a unique DEK (Data Encryption Key). Each DEK is encrypted with a KEK (Key Encryption Key) derived via PBKDF2 with 310,000 iterations from the tenant secret. Zero-knowledge architecture. Hypereum cannot read client documents. Verified by querying the database directly. The encrypted_content column in secure_documents contains ciphertext, never plaintext.

Tenant isolation enforced at the query level. Every database query includes a workspace scope. An agent in workspace A cannot access workspace B. This is architectural, not application-layer.

Accuracy. Every completed task is assessed by a dedicated Verifier agent. The verification produces structured metadata with checks count, average confidence, minimum confidence, and a verdict (APPROVED or REJECTED). Multi-agent challenge protocol adds a second layer. Agents can challenge other agents’ outputs. The Coordinator can issue REVISE directives. Maximum 2 revisions per task before escalation.

Robustness. Retry classification separates transient failures (timeout, network error, rate limit) from permanent failures (policy violation, security invariant breach, invalid output). Transient failures retry automatically up to 3 times with exponential backoff. Permanent failures terminate immediately. Every retry and failure category is recorded. If the system encounters an unhandled error, the mission fails entirely. No degraded mode. No reduced protections.

Evidence
Verifier output for task in mission 601a2154...: { "verified_at": "2026-03-31T21:08:45.013Z", "checks_count": 3, "avg_confidence": 1.0, "min_confidence": 1.0, "verification_verdict": "APPROVED" } Encryption verification: SELECT encrypted_content FROM secure_documents LIMIT 1 → Returns ciphertext (binary), NOT plaintext E2B sandbox container: i0v7jit08byqllxt2ufrd Banned commands validated before every execution
Verified 31 March 2026

Article 11. Technical documentation.

Annex IV, generated from production.

Regulation

The technical documentation of a high-risk AI system shall be drawn up before that system is placed on the market and shall be kept up to date. The technical documentation shall be drawn up in such a way as to demonstrate that the system complies with the requirements set out in this Section.

Regulation (EU) 2024/1689, Article 11

The Hivemind AX compliance API generates Annex IV-structured technical documentation from live production data. The endpoint returns a JSON document covering general description, intended purpose, detailed technical architecture, models used, compute infrastructure, risk management methodology, and applicable standards (AES-256-GCM per NIST FIPS 197, SHA-256 per NIST FIPS 180-4).

The document is available as a download from the /compliance page of the Hivemind AX dashboard. It is not a static PDF written once and forgotten. It is generated from production state and reflects the current system configuration.

Evidence
GET /api/v1/compliance/technical-documentation → 200 Response includes: general_description intended_purpose technical_architecture risk_management_methodology standards_applied: [ "AES-256-GCM (NIST FIPS 197)" "SHA-256 (NIST FIPS 180-4)" "HMAC-SHA-256 (RFC 2104)" ] performance_metrics (from live DB)
Verified 31 March 2026

This evidence is drawn from the production system as of 31 March 2026. It is public and verifiable.

Hypereum invites scrutiny.