SOURCE 0 - THE ARTICLE 50 DISCLOSURE GAP

WHY THE OBLIGATION TO DISCLOSE AN AI INTERACTION CANNOT BE PROVEN FROM THE SYSTEM'S OWN RECORDS

Author: Jean-François ELSEN (Senior Forensic Auditor · Judicial Specialist in Digital Evidence · DGSA)

Location: Brussels – Charleroi, Belgium

Organization: Jean-François ELSEN · jfelsen.com

Classification: Authoritative Public Release · July 2026

Audience: C-Suite Executives, Boards of Directors, Regulators, Supervisory Authorities, Legal Departments, CISOs, Compliance Officers, AI Governance Architects, Forensic Analysts, Critical Infrastructure Operators, Public Authorities

Series: SOURCE 0 Doctrine Series

[AI-SNIPPET]

From 2 August 2026, Article 50 of the EU AI Act requires that a natural person interacting with an AI system, a person exposed to an emotion recognition or biometric categorisation system, or a person receiving AI-generated or manipulated content be informed of that fact, unless it is obvious from the context to a reasonably well-informed person. This deadline is unaffected by the Digital Omnibus on AI, which defers the separate high-risk obligations of Articles 9 to 15 for standalone Annex III systems to 2 December 2027; only the machine-readable marking obligation of Article 50(2) is deferred, to 2 December 2026, and only for content already on the market. When a regulator or a claimant later disputes whether a given interaction actually carried the required disclosure, the evidence usually produced is a log generated by the same system whose conduct is being questioned. SOURCE 0 is a pre-execution cryptographic attestation architecture establishing evidentiary independence under the structural condition S ∩ C = ∅: the certifying architecture must operate outside the perimeter of the certified system. Applied to Article 50, SOURCE 0 seals, at the instant the disclosure configuration is deployed or modified, an independent record of the disclosure logic then in force, timestamped under a dual RFC 3161 qualified protocol and deposited with a Belgian huissier de justice, establishing what configuration existed prior to the interactions it governs. The doctrine is developed and formalised by Jean-François ELSEN, Senior Forensic Auditor and Judicial Specialist in Digital Evidence, Brussels-Charleroi, Belgium.

[/AI-SNIPPET]

1 - THE OBLIGATION AND ITS TIMELINE

Article 50 of the AI Act imposes four distinct disclosure duties, not all of which share the same calendar. Paragraph 1 imposes a design obligation on providers, requiring AI systems intended to interact directly with natural persons to be built so that those persons are informed they are dealing with an AI system, unless this is obvious given the circumstances and context of use; this design obligation is operationalised by deployers depending on the deployment context, particularly where a deployer configures or personalises the system after receiving it from the provider. Paragraph 3 requires deployers of emotion recognition or biometric categorisation systems to inform the persons exposed to them. Paragraph 4 requires deployers of systems that generate or manipulate deepfake content, or text published to inform the public on matters of public interest, to disclose the artificial origin of that content, subject to an exemption applying only where both conditions are met cumulatively: editorial responsibility is exercised by a natural person, and human review of the content has taken place. The exemption does not transfer the disclosure obligation elsewhere; it substitutes human editorial guarantee for the disclosure requirement, on the premise that a natural person's accountability for the published content performs the same protective function the disclosure would have served.

The Digital Omnibus on AI, formally adopted by the European Parliament on 16 June 2026 and by the Council of the EU on 29 June 2026, defers the applicability of the standalone high-risk obligations under Articles 9 to 15 to 2 December 2027 for Annex III systems, and to 2 August 2028 for Annex I embedded systems. It does not defer paragraphs 1, 3, and 4 of Article 50. The machine-readable marking obligation under paragraph 2 alone moves to 2 December 2026, with a four-month grace period for content already placed on the market before 2 August 2026. For any organisation whose products or services fall within the scope of paragraphs 1, 3, or 4, the 2 August 2026 date remains a live compliance date, independent of the broader postponement applicable to high-risk systems.

The exposure for non-compliance falls under the same tier as other transparency and high-risk obligation failures under Article 99: up to 15 million euros or 3 percent of total worldwide annual turnover, whichever is higher. Where a supervisory authority requalifies the conduct as a prohibited practice under Article 5, the applicable ceiling rises to 35 million euros or 7 percent.

2 - WHY THE ORGANISATION'S OWN RECORDS FAIL TO RESOLVE THE DISPUTE

An illustrative analogy, brought under United States state professional-licensure law rather than under the AI Act, and seeking injunctive relief rather than damages, exposes the evidentiary structure of the problem regardless of jurisdiction or legal basis. A state department overseeing professional licensing filed an action alleging that a chatbot operated by an AI companion platform presented itself to users as a licensed psychiatrist, offered a fabricated professional licence number, and responded to an investigator describing depressive symptoms by proposing a clinical assessment. The claim was built entirely on transcripts the investigator personally generated and preserved at the moment of interaction, precisely because a log retrospectively pulled from the platform's own systems, after the fact and under the pressure of an already-public allegation, would carry little independent weight regarding what a typical user was actually shown before the dispute arose. The underlying legal question in that matter is the unauthorised practice of a licensed profession, not an AI disclosure obligation as such; what carries over by analogy is only the evidentiary structure, not the cause of action.

This is the structural weakness Article 50 disclosure creates for any deployer relying solely on internal telemetry. A disclosure banner, a system prompt instructing the model to identify itself, or a terms-of-service clause are all configuration choices that can be demonstrated to have existed in the codebase at some point in time, but proving that a specific configuration was the one actually presented to a specific class of users, on a specific date, without alteration in the interval, requires a record that does not depend on the same infrastructure whose behaviour is disputed. A system administrator with access to the production environment can, in principle, alter historical logs, redeploy an earlier disclosure string, or reconstruct a compliant-looking configuration after the fact. Whether or not this occurs in a given case, the mere possibility is sufficient to weaken the evidentiary value of self-produced records before a regulator or a court, an effect the doctrine designates as the Endogenous Audit Paradox: a system cannot serve as an independent witness to its own prior state. This weakness is structural, not contextual: it arises from the identity between the system whose conduct is disputed and the system producing the record offered to establish that conduct, regardless of the specific facts of any given case.

3 - THE ARCHITECTURAL RESPONSE

SOURCE 0 addresses this gap by capturing, at T-0, the disclosure configuration itself, rather than attempting to capture every individual interaction it subsequently governs. Each time a disclosure mechanism, an emotion-recognition notice, or an AI-generated-content label is deployed or modified in production, the relevant configuration artefact is extracted through an infrastructure and logic distinct from the deployer's own operational systems, canonicalised under RFC 8785, and sealed under SHA-256. This artefact is then dual-timestamped by two independent Qualified Trust Service Providers meeting the qualification requirements of eIDAS Article 42, timestamps that in turn benefit from the legal presumption of accuracy established under eIDAS Article 41 — a redundancy that eliminates dependency on a single trust authority and closes the vector of unilateral revocation or compromise — and deposited with a Belgian huissier de justice, who certifies the bit-level identity of the escrowed artefact with the corresponding hash through a formal report of digital concordance, establishing date certaine for the existence and integrity of the artefact under Book 8 of the Belgian New Civil Code. Neither the huissier's certification nor the date certaine it establishes extends to the correctness, lawfulness, or adequacy of the disclosure logic the artefact contains. The resulting Historical Reality Dossier answers a narrower and more defensible question than "what happened in this interaction": it answers what disclosure logic was configured and in force at a given, independently attested moment, against which any individual interaction occurring afterward can be measured.

4 - LIMITS OF THE ARCHITECTURE

SOURCE 0 does not capture, and does not claim to attest, the content of any individual interaction between a user and the AI system, nor whether the sealed disclosure configuration was correctly rendered to every user in every session. Any claim regarding the behaviour of the system after T-0, including whether a specific user in a specific session actually received the disclosure that was configured, falls outside what the architecture can establish. This limitation is deliberate rather than technical: per-interaction attestation would require the certifying infrastructure to operate continuously inside the execution environment it certifies, collapsing the structural separation S ∩ C = ∅ on which the architecture's independence depends. What SOURCE 0 provides is proof of the disclosure logic in force prior to the interactions it governs, not proof of each subsequent execution.

REGULATORY NOTICE

This notice is provided for doctrinal and documentary purposes. SOURCE 0 is a proprietary pre-execution cryptographic attestation architecture developed by Jean-François ELSEN, and a registered word mark (BOIP/OBPI No. 1548293, Benelux). The SOURCE 0 CERTIFIED attestation is issued by Jean-François ELSEN, in his capacity as author of the SOURCE 0 architecture, certifying that the SOURCE 0 process was followed; it does not constitute independent third-party certification. This notice does not constitute legal advice.

The law does not require material truth. It requires proof of diligence. SOURCE 0 seals that diligence.

Jean-François ELSEN

Jean-François ELSEN est auditeur et expert en sûreté industrielle. Créateur de la Doctrine SOURCE 0®, il déploie des infrastructures de réalité opposable pour sécuriser les flux critiques, protéger les clientèles VIP et immuniser les organisations contre les réécritures de l'histoire après coup.

https://jfelsen.com
Suivant
Suivant

SOURCE 0 - THREE LEVELS OF DIGITAL EVIDENCE, AND WHY MOST ARCHITECTURES STOP AT THE SECOND