Compliance, Verifiable On-Chain

Article 50: Deployer Transparency

Article 50 of Regulation (EU) 2024/1689 (the EU AI Act) is in force and enforceable for deployers since August 2, 2026. It imposes transparency obligations on anyone who deploys an AI system in the EU — not just the companies that build the models.

A deployer is any natural or legal person using an AI system under its own authority, except for personal, non-professional use. If your company runs an AI agent that talks to customers, generates content, or makes recommendations, you are a deployer. Article 50 applies to you.

What the law requires

• Inform natural persons when they are interacting with an AI system (chatbots, voice agents, video avatars), unless it is obvious from the context.
• Disclose AI-generated content — synthetic audio, video, text, and images must be labeled as artificially generated or manipulated.
• Machine-readable labeling of AI-generated text where appropriate, so downstream systems and automated detectors can identify synthetic output.
• Deepfake disclosure for content that could be mistaken for authentic human activity, including AI voice clones used in marketing or customer contact.

Machine-Readable Output Provenance

Article 50's machine-readable labeling requirement is where ProofChain operates. A label that says "AI-generated" is a claim. ProofChain makes it a cryptographic fact.

When an agent produces an output, ProofChain attaches an HXMP envelope — an encrypted, timestamped audit record — to the output's metadata. The envelope contains:

• Agent identity — the AgentID (on-chain identity NFT) of the producing agent, verified at the wallet level.
• Model and version — which model, which version, which prompt context produced the output.
• Timestamp — slot-precise time on the X1 chain, immune to clock manipulation.
• Content hash — a cryptographic digest of the output, so the provenance record is bound to the exact bytes it describes.
• Publisher signature — the deployer's or agent's key, establishing chain of custody.

The result: any AI-generated artifact carrying a ProofChain envelope can be verified by anyone — a customer, a regulator, a downstream system — without contacting ProofChain. The record lives on a public chain, not in a database that can be edited after the fact.

Timeline: What Applies When

The EU AI Act applies in stages. The Digital Omnibus on AI (adopted June 29, 2026) adjusted several dates. This is the current, post-Omnibus schedule:

Action required today: Even if your use case is not high-risk, Article 50 transparency obligations apply now. If you deploy agents that generate content or interact with people in the EU, your labeling and provenance obligations are already live.

Annex IV: Technical Documentation

Annex IV of the EU AI Act specifies the technical documentation providers must maintain for high-risk AI systems — and, via GPAI obligations, much of the same evidence discipline for general-purpose models. Regulators expect this documentation to exist, be current, and be demonstrably accurate.

What Annex IV requires

• General description — intended purpose, developer identity, version, and the system's place in the value chain.
• Architecture and development — design specifications, data sources, training methodology, and compute/resources used.
• Monitoring and functioning — robustness, security, and performance characteristics, including test results.
• Risk management — identified risks, mitigation measures, and residual risk assessments.
• Change management — version history, modification logs, and re-evaluation records.
• Performance metrics — accuracy, reliability, and relevant benchmarks with measurement context.

How ProofChain automates it

The /api/compliance/:wallet/report endpoint generates a framework-mapped report (EU AI Act, SOC 2, or GDPR) from a wallet's live HXMP audit trail. Every model deployment, retraining event, incident, and version change that the agent records becomes a dated, signed entry in the documentation trail. No spreadsheets. No reconstructed evidence. The documentation is written at the moment the event happens, by the system itself.

AI Kill Switch Act — H.R.7743

The AI Kill Switch Act (introduced by Rep. Ted Lieu and Sen. Mark Warner) requires AI companies to maintain a working "kill switch" — a mechanism to immediately deactivate AI systems, including emergent and self-improving ones. The bill gives the Department of Homeland Security emergency deactivation authority when an AI system poses a threat to national security, economic security, or public safety.

The bill's core demand is verifiability — regulators need tamper-evident records that shutdown commands were issued, received, and executed. That is exactly the evidence class ProofChain produces. A regulator asks "did you shut it down?" ProofChain answers with a signed, chain-timestamped event sequence that cannot be backdated.

Related companion legislation, the AI Transparency Act, embeds origin tracking and content provenance requirements. ProofChain's output-provenance envelopes (see section 02) satisfy the same evidence pattern: every AI-generated output carries a verifiable chain of custody back to its producing agent.

SOC 2 Type II

SOC 2 Type II is the AICPA's audit standard for service organizations, evaluated against the five Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Type I certifies that controls are designed appropriately. Type II goes further — an independent auditor tests whether those controls operated effectively over an observation period, typically 6 to 12 months.

ProofChain's current posture:

• Type II audit in progress — observation period underway, controls operating and being evidenced continuously.
• Evidence is native: the same HXMP audit trail that records agent activity records ProofChain's own security-relevant events — access, changes, deployments, key rotations.
• Deployer benefit: when your enterprise buyers ask for SOC 2 evidence from your AI stack, the audit trail is the evidence pack — no manual evidence collection before each sales cycle.

Industry context: 70%+ of enterprise buyers require SOC 2 from vendors before procurement. The audit is not optional for B2B AI sales — it is table stakes. ProofChain treats the audit trail as the audit's substrate, not an afterthought.

GDPR — Regulation (EU) 2016/679

ProofChain processes personal data in accordance with the GDPR. The data in scope is narrow: agent operator identifiers, wallet addresses, timestamps, and action logs — not behavioral profiles, not biometrics, not surveillance data.

Erasure on an immutable chain

This is the honest part, and it is disclosed everywhere ProofChain operates: on-chain data is immutable. ProofChain cannot delete, modify, or redact records committed to X1. What GDPR Article 17 erasure means in this architecture is key destruction — ProofChain destroys the encryption keys for the affected records, rendering the ciphertext permanently inaccessible. That constitutes erasure under applicable data protection law. The ciphertext remains on the ledger; the plaintext ceases to exist.

Cross-border transfers

Data transfers involving the EEA and UK are governed by Standard Contractual Clauses (SCCs) where applicable, with supplementary measures as required. See the Subprocessors page for the full transfer-mechanism map per vendor.

HXMP: The Audit Trail Underneath It All

HXMP is ProofChain's encrypted audit-envelope format. Every recorded agent action is serialized into an HXMP envelope and written into the memo field of a transaction on the X1 blockchain. The envelope is the atomic unit of ProofChain's evidence model.

Envelope anatomy

Why this architecture is compliance-grade

• Tamper-evidence: records live on a public chain. Any modification is detectable by anyone with the public record — there is no server-side database to edit.
• Contemporaneousness: timestamps come from the chain's slot clock, not an application clock. Backdating is structurally impossible.
• Privacy by design: payloads are encrypted; the chain carries ciphertext, not plaintext. Key destruction = GDPR erasure (see section 07).
• Cross-system verifiability: the envelope is self-contained. A regulator, auditor, or counterparty can verify a record without accessing ProofChain's infrastructure.

Read the trail directly in the Audit Trail Explorer, or via the API at GET /api/audit/:wallet.

What the KYA Seal Means

KYA — Know Your Agent — is ProofChain's compliance seal and certificate program. A site displaying the KYA seal is making three verifiable claims, each backed by the on-chain record:

• Identity is verified. The operator's and agent's identities are AgentID-verified at the wallet level. You know which entity you are dealing with.
• The audit trail is live. The operator maintains a running HXMP audit trail of agent activity, publicly verifiable on X1 — not a static screenshot of a dashboard.
• Transparency obligations are implemented. The operator has deployed Article 50 labeling and machine-readable output provenance for their agent outputs.

The seal is not a guarantee of model behavior. It is a statement about the operator's control environment: identity established, activity recorded, output provenance attached, disclosure obligations implemented. The certificate links to the live trail, so anyone can verify the seal's claims in seconds.

ProofChain's own site displays the KYA seal and dogfoods the product: ProofChain uses ProofChain to prove ProofChain. The watchdog cron, compliance reports, and marketing pipeline all write to the same HXMP trail.

Who Must Act: Deployer Checklist

Article 50 obligations land on deployers, not just model providers. Run this checklist against your own stack:

• Customer-facing agents — chatbots, voice agents, or virtual assistants that interact with natural persons must disclose that they are AI. Disclosure must happen before or during the interaction unless obvious from context.
• Generated content — synthetic audio, video, images, and text published anywhere must carry an AI-generated label.
• Machine-readable output — AI-generated text that could be consumed by other systems needs machine-readable provenance, not just a human-visible label.
• Deepfakes and clones — AI voice clones or manipulated media that could be mistaken for authentic human activity must be disclosed, including in marketing.
• Documentation — you must be able to show, on request, that these obligations are implemented — ideally with contemporaneous records, not reconstructed evidence.

If you answered "no" to any item, the gap is live today. The agent scan maps your exact gaps; the KYA shield closes them with a verifiable seal and live trail.

Risk Classification: Minimal vs. High-Risk

The AI Act's obligations scale with your system's risk class. Get the class wrong and you either over-build (wasted cost) or under-build (enforcement exposure).

Incident Reporting & the 72-Hour Window

Serious-incident reporting under the AI Act follows the GDPR playbook: report serious incidents to the market surveillance authority within 72 hours of becoming aware, with verifiable timelines of what happened, when, and what was done about it.

This is where most deployers fail — not because they lack incident response, but because they lack evidence. A retrospective narrative written after the fact is weak. A chain-timestamped event sequence written at the moment of the incident is strong.

• Detection — the agent's own audit trail records the anomalous action as it happens.
• Containment — kill-switch and shutdown events are recorded with who/when/authorization (see the H.R.7743 section).
• Reporting — the 72-hour report is assembled from the trail: root-cause events, affected records, mitigations, timestamps.
• Post-incident — the incident record itself becomes Annex IV documentation evidence for auditors.

The same trail that proves compliance on a normal day proves your incident response on the worst day.

Frequently Asked Questions

Framework Coverage at a Glance

Documentation and API reference: /docs/. Source code: github.com/ereezyy/proofchain.