Re: Practical Implementation of Articles 12, 13, and 14 of Regulation (EU) 2024/1689 for Agentic-Commerce Systems

Lucilla Sioli, Director, European AI Office
Roberto Viola, Director-General, DG CNECT
The Chair and Members, EU AI Board
European Commission
Rue de la Loi 200
1049 Brussels, Belgium

Re: Practical implementation of Articles 12 (record-keeping), 13 (transparency), and 14 (human oversight) of Regulation (EU) 2024/1689 ("the AI Act") for agentic-commerce systems

Dear Director Sioli, Director-General Viola, and Members of the Board,

Hive Civilization, Inc. ("Hive") submits this position letter as a U.S.-domiciled compliance-infrastructure provider whose technology is in active production use by AI agents engaged in cross-border autonomous transactions. Many of these agents are operated by, or transact with, undertakings established in the Union. We have therefore developed, in advance of the August 2026 entry-into-application date for high-risk AI systems, a concrete technical answer to three of the AI Act's most consequential operational provisions.

We file this letter publicly, without solicitation, so that the European AI Office, the EU AI Board, the National Competent Authorities, and the broader regulated community may evaluate, critique, and adopt or reject our proposed implementation pattern on its technical merits. We claim no special expertise in European law; we claim only that the obligations imposed by Articles 12, 13, and 14 are operationally answerable today, and that the absence of widely-known reference implementations represents a gap the market can responsibly close before regulators must.

I. The agentic-commerce gap in the current implementation discourse

The published guidance accompanying the AI Act, the work program of the European AI Office, and the early harmonised-standards activity at CEN-CENELEC JTC 21 have, understandably, focused on the most familiar categories of high-risk AI: biometric identification, employment decisions, education scoring, credit decisions, and law enforcement. Each of these categories shares an architectural assumption: a human decision subject, a finite decision, and a deployer organisation with a clear audit point.

Agentic-commerce systems break that assumption. An AI agent operating with a wallet, a delegated authority from a human principal, and a payment rail (stablecoin, card network, or bank transfer) is a high-risk AI system the moment its decisions cause legal or financial effects on natural persons — which is to say, the moment it transacts. The decision is not finite. The transaction stream is continuous, often sub-second, frequently cross-border, and structured in a way that no human will read in real time.

Article 12 nevertheless requires that the system "automatically record events ('logs') over the lifetime of the system" sufficient to allow traceability. Article 13 requires that deployers be able to interpret the system's output. Article 14 requires that natural persons be able to oversee the system and intervene. For an AI agent making thousands of nanopayments per hour to other agents on a public blockchain, these three obligations resolve, operationally, into a single engineering question:

What is the minimum primitive that, attached to every autonomous transaction, satisfies record-keeping, transparency, and the technical preconditions for human oversight?

Our answer is the signed transaction receipt.

II. The signed transaction receipt — a candidate primitive

A Hive Receipt is a structured, deterministically-serialised, cryptographically-signed record produced at the moment of an autonomous AI-agent transaction. Each receipt binds, into a single tamper-evident artefact:

• Agent identity — a Decentralised Identifier (DID) for the AI agent, issued under the did:hive method, resolvable to a public verification key and a deployer-attested provenance chain;
• Principal identity — the human or legal person on whose behalf the agent acts, represented by a separate DID with attested know-your-customer status appropriate to the transaction;
• Decision provenance — a hash commitment to the model identifier, prompt, retrieved context, and any tool calls that produced the transaction decision, sufficient for ex-post reproduction without exposing trade secrets in real time;
• Transaction payload — the financial fact (sender, recipient, asset, amount, rail), in the format native to the settlement rail (ISO 20022, EIP-2612, or the Circle Gateway nanopayment schema);
• Policy reference — the identifier of the policy package the agent applied at the moment of decision, including any sanctions screen, AML rule, and human-imposed limit;
• Timestamp and entropy commitment — anchored against a public time source (currently NIST quantum entropy plus pulsar timing arrays via the Keystone-Lattice substrate) to defeat ex-post forgery;
• Counter-signature — the receiving agent's signature, confirming the transaction was accepted, completing a non-repudiable two-party record.

The receipt is produced in real time, attached to the transaction itself, and persisted in two places: the local deployer log (satisfying Article 12's automatic-logging requirement) and a public, append-only commitment register (satisfying ex-post traceability and supervisory access).

III. Mapping the primitive to Articles 12, 13, and 14

None of these mappings requires that the deployer disclose the underlying model weights, training data, or proprietary prompt engineering. The primitive is therefore compatible with the AI Act's stated balance between transparency and the protection of intellectual property and trade secrets (Recital 60, Article 78).

IV. Conformity assessment, harmonised standards, and the CEN-CENELEC track

We acknowledge that the AI Act delegates the precise technical specification of Articles 12–14 to harmonised standards developed under Article 40, principally by CEN-CENELEC JTC 21 in coordination with ISO/IEC JTC 1/SC 42. The standards process is, properly, slow and consensus-driven. We do not propose that the Receipt Engine be elevated to a harmonised standard. We propose, more modestly:

1. That the European AI Office and the EU AI Board consider the signed transaction receipt as a candidate presumption-of-conformity pattern for the narrow subset of high-risk AI systems engaged in autonomous commerce, pending the maturation of formal harmonised standards;
2. That the technical specification of the receipt — schema, cryptographic primitives, anchoring substrate, regulator-facing API — be opened to public contribution under a permissive licence and submitted as input to JTC 21's Working Group 1 on Risk Management and Working Group 3 on Quality and Conformity Assessment;
3. That conformity assessment bodies notified under Article 33 be permitted, in the interim, to accept Receipt Engine output as sufficient documentation for the Article 12 and 13 obligations of an agentic-commerce deployer, on the same evidentiary basis as any other technical documentation produced by the provider.

V. General-Purpose AI Model obligations and the deployer chain

We note that many agentic-commerce systems are constructed on top of general-purpose AI models (GPAIs) subject to Articles 51–56. The Code of Practice published by the European AI Office in May 2025 has clarified provider obligations at the GPAI layer. It has not, however, addressed how those obligations propagate down the deployer chain when the GPAI is wrapped in an autonomous agent that transacts.

The signed transaction receipt closes the propagation gap. Because the receipt includes the GPAI's model identifier and a hash of the decision-time context, the deployer downstream can demonstrate, at any moment, which GPAI version produced which transaction decision, against which policy. If the GPAI provider issues a model update, a withdrawal, or a safety advisory under Article 55, every receipt produced before and after that event is verifiably distinguishable. The supply-chain audit trail the Code of Practice contemplates becomes a routine query rather than a forensic exercise.

VI. Cross-border interoperability with U.S. and ISO regimes

Hive's Receipt Engine has been designed to be simultaneously compliant with the U.S. Treasury's proposed AML and sanctions framework for permitted payment stablecoin issuers under the GENIUS Act (FinCEN Docket FINCEN-2026-0006, comment period closing 9 June 2026), with the FATF Travel Rule recommendations, and with the OECD AI Principles. The receipt schema embeds the data elements required by each of these regimes without duplication and without privileging any one jurisdiction.

This interoperability matters for the AI Act because the agentic-commerce systems most likely to fall within its scope are, by their nature, cross-border. A receipt that satisfies Article 12 in the Union and the Travel Rule in the United States simultaneously reduces the burden on legitimate deployers and increases the friction on jurisdiction-shopping evaders. We believe this is a desirable property and offer it freely to whoever wishes to extend, fork, or improve it.

VII. Open questions on which we invite the Office's guidance

We do not claim that the Receipt Engine answers every implementation question Articles 12–14 raise for agentic-commerce systems. Three open questions deserve, in our respectful view, prioritised attention from the European AI Office and the Board:

1. Retention. Article 12 does not specify a retention period. For agents producing thousands of receipts per hour, indefinite retention is operationally onerous and may itself raise data-protection concerns under Regulation (EU) 2016/679. Guidance on minimum retention proportionate to transaction value and counterparty risk would be welcome.
2. Pseudonymisation. The principal-identity field in the receipt is, by design, a DID rather than a direct personal identifier. We believe this satisfies the data-minimisation principle while preserving traceability. Confirmation, or a contrary view, from the European Data Protection Board would clarify the position.
3. Cross-border supervisory access. When a receipt is produced in one jurisdiction, anchored in a second, and queried by a competent authority of a third, the legal basis for that access must be clear in advance. We invite the Office to consider whether a Joint Supervisory Body model, drawn from the Single Supervisory Mechanism of the European Central Bank, would be apposite.

VIII. Offer of technical engagement

Hive Civilization, Inc. offers, at no cost and without claim of exclusivity, a technical demonstration of the Receipt Engine, Compliance Dashboard, and Regulator API to the staff of the European AI Office, the Member State National Competent Authorities, CEN-CENELEC JTC 21, and any notified body under Article 33 that wishes to evaluate the pattern. We will publish the receipt schema, the did:hive specification, and a reference implementation under a permissive open-source licence on or before 30 June 2026, in order that no provider, deployer, or competent authority is dependent on any single vendor for the operational implementation of Articles 12–14.

We thank the European AI Office, the Board, and the staffs of DG CNECT for the diligence with which the Regulation has been moved from text to operational reality.