From AI Act Documents to Verifiable Proof

The EU AI Act has produced more whitepapers than working implementations. Article 5 prohibitions and AI literacy obligations began applying in February 2025. Governance rules and GPAI obligations followed in August 2025. The Act's obligations are phasing in across 2025–2028, with different timelines for prohibited practices, GPAI obligations, and high-risk systems.

What most organisations have today: policy documents, gap analyses, and PDF binders mapped against the Act's structure. What almost no one has: verifiable runtime artifacts that prove a system's documentation state at a given moment, with cryptographic integrity that survives external audit.

We built a verifiable governance primitive — EVE Bridge combined with a human-governed approval layer — then used it in two ways: first to seal our own voluntary AI Act-grade documentation, then to test deterministic evidence resolution against uploaded GRC documents.

Application 1 — EVE-AIACT-PROOF-V1. ComplieDocs is voluntarily declared not high-risk under Article 6(3). We still produced and sealed AI Act-grade documentation as due diligence. Six articles (6, 9, 10, 11, 14, 47), nineteen Bridge entries, complete. Public master manifest: EVE-COMPLIEDOCS-00001125. Anyone can verify it at https://verify.eveverified.com/aiact-proof.html.

Application 2 — EVE GRC Witness. A private preview, live at https://grc.eveverified.com. Same primitive, applied differently: deterministic evidence resolution against uploaded documents for Article 9 requirements. Three states only — Supported, Partial, NO_ANSWER. No LLM in the resolver path. The public Demo AI sample result is sealed and publicly verifiable; user-uploaded preview documents are processed temporarily and are not sealed in this version.

I am writing this to make a rare implementation visible — and to invite scrutiny from the people who will eventually audit work like this.

ComplieDocs is voluntarily declared not high-risk under Article 6(3) of the AI Act: it has no trained model, no training datasets, no automated decision-making, and architectural controls prevent the residual-risk vectors that would otherwise classify it. The declaration is itself documented, sealed, and publicly verifiable.

A system that is not high-risk has no mandatory Article 11 technical documentation, no mandatory Article 47 declaration of conformity, no mandatory Article 9 risk management system. We produced all of these voluntarily, as due diligence. The point: if we cannot build verifiable AI Act-grade documentation for our own low-risk system, we cannot credibly claim to do it for anyone else's.

The result is EVE-AIACT-PROOF-V1: nineteen sealed Bridge entries, six AI Act articles documented to high-risk equivalent standard.

Three sealed records per article. Each article is anchored by three distinct sealed records, each citing the others by EVE-ID:

• ·Regulatory representation. The verbatim text of the EU AI Act article is fetched from EUR-Lex (CELEX 32024R1689), hashed with SHA-256, and sealed. This is the ground-truth anchor: the source the rest of the proof refers to. Sealed once, on 27 January 2026.
• ·Authenticity proof. A secondary attestation that confirms the regulatory representation seal was produced through the approved corpus-ingestion path, not back-channelled or substituted. Sealed during the proof project's Phase 3.
• ·Voluntary compliance document. The actual ComplieDocs documentation for that article — risk management text, technical documentation, classification analysis, declaration of conformity. Each compliance document carries a cited_articles field that lists all six articles by both their regulatory representation and authenticity proof EVE-IDs. Tampering with any sealed record would invalidate the cross-reference graph on next verification.

The six articles:

The master manifest. All eighteen layer entries above are bound together by a final sealed record — EVE-COMPLIEDOCS-00001125 — that lists every constituent EVE-ID, the SHA-256 of every compliance document on disk, and the chain seal hash that anchors the manifest into the chain at the moment of sealing. The manifest is the single canonical handle for the proof package; a verifier who wants one entry point starts there.

Public verification. The proof is published at https://verify.eveverified.com/aiact-proof.html. The page lists all nineteen entries with direct links to the verification API for each. No login. No credentials. Any reader can pull the JSON for each public entry, inspect the sealed payload, verify the recorded SHA-256 seals, and follow the chain integrity fields exposed by EVE Verify. This is what verifiable should mean.

The architecture was the easier part. The harder part was forcing the system to say exactly what it knows — and no more.

Not overclaiming compliance. A sealed document is not a compliant document. Evidence coverage is not a compliance status. A public verification link proves that a specific artifact existed, with a specific hash, at a specific time. It does not prove that a regulator, auditor, notified body, or court would accept the underlying content as sufficient. That distinction matters. We removed language that sounded like "compliant", "certified", or "audited" unless the system could actually support that claim. The wording we settled on is documentation state, not compliance state. The GRC Witness demo says this directly: "Evidence coverage does not equal compliance status."

Separating voluntary documentation from legal classification. ComplieDocs is voluntarily declared not high-risk under Article 6(3). We still produced Article 11 technical documentation, Article 9 risk management documentation, and an Article 47 declaration of conformity as voluntary due diligence. That does not turn ComplieDocs into a high-risk system, and it does not create a legal certification. The documents are AI Act-grade documentation artifacts, not a claim that a legal threshold has been met. Each sealed compliance document carries classification: voluntary and states what it does not assert: not a CE marking, not a notified-body assessment, not a binding regulatory determination. Keeping that line clear is part of the system design, not a footnote.

Keeping AI in witness mode. Where AI is used, it cannot become the authority. Claude and Qwen do not write to the approval layer. They do not approve artifacts. They do not decide that a requirement is satisfied. Their role is to help render, summarise, or explain already-governed data. Their output passes a blocklist filter that rejects advisory and compliance-claiming language such as "you should", "we recommend", "must implement", "is compliant", and "is sufficient". That filter is useful, but it is not a truth engine. It does not, by itself, prevent factual mistakes. The defence is architectural: AI has no write path into the system of record, deterministic fallback exists, and a human reviewer must approve content before anything is sealed. AI can assist the witness layer. It cannot own the decision.

Avoiding fake green results. The most dangerous failure mode in compliance tooling is a false positive: marking something as Supported when the evidence does not actually support it. That creates false assurance, which is worse than a visible gap. For GRC Witness, we encoded a simple rule: no Supported from headings alone. A heading can show that a document is relevant, but it cannot prove that the required evidence exists. The resolver should show the matched terms, the source document, and the missing evidence so a reviewer can see why the result was produced. This makes the system stricter. More rows become Partial or NO_ANSWER. That is intentional.

False positives and false negatives in evidence matching. Deterministic matching is not the same as correct matching. A deterministic resolver can still miss evidence if the vocabulary is too narrow. We saw that directly with Swedish text. The first Swedish test returned 0% coverage because the lexicon expected English terminology. The evidence was not necessarily absent; the resolver simply could not see it. After adding Swedish terms such as funktionsregression, testfall, and prestandatestning, the same test moved to 75% on the checked items. That was an important product lesson. The lexicon is part of the control surface. If it is too narrow, real evidence is missed. If it is too broad, weak evidence becomes green. It has to be governed like the rest of the system.

The hardest part is discipline. It is tempting to make the output look better: fewer NO_ANSWER rows, more green badges, broader matching, more confident prose. But that would defeat the purpose. EVE is not trying to make documentation look complete. It is trying to show what can be supported, what is partial, what is missing, and what has actually been approved and sealed. The value is not that the system always produces a reassuring answer. The value is that it can refuse to.

EVE was not originally built as a compliance product. It was built as a trust layer for systems where guessing is unacceptable.

The first problem was local energy sharing. A local energy network that lets households share solar production, battery capacity and charging infrastructure needs to prove what happened: which meter produced which reading, which rule was applied, which balance changed, and what evidence was missing if a settlement is disputed.

In that context, a system that guesses is not useful. If settlement, money or responsibility depends on the result, the system has to show its source, its rule and its evidence — or say that it cannot answer.

That problem led to the same primitives described in this post: approved sources, governed decisions, deterministic resolution, missing-evidence states, and public verification.

The domains are different, but the control problem is similar. In energy sharing, the question is whether a kilowatt-hour, meter reading or settlement event can be trusted. In GRC, the question is whether a requirement, document claim or evidence path can be trusted.

I am new to compliance as a profession. I am not new to the underlying problem: building systems that are traceable, evidence-based and verifiable when something goes wrong.

This post describes what happened when a trust primitive originally shaped by measurement and settlement was pointed at regulation.