Article 26 Deployer Obligations, and where ComplyEdge records help

Status: Article 26 applies from 2 December 2027, not 2 August 2026. Regulation (EU) 2026/1744 (Official Journal 24 July 2026, in force 27 July 2026) postponed the Annex III high-risk obligations, which include the Article 26 deployer duties mapped below and the Article 12 record-keeping duty, from 2 August 2026 to 2 December 2027. Annex I embedded systems move to 2 August 2028. Not postponed, and binding from 2 August 2026: Article 50 transparency and the Commission's fining powers over GPAI providers (Art. 101). National market-surveillance penalty powers under Article 99 have applied since 2 August 2025 (Chapter XII early application, except Art. 101). The Article 5 prohibitions have applied since 2 February 2025: with a narrow Omnibus carve-out: Article 5(1) points (ba) and (bb) and Article 5(1a)/(1b) apply only from 2 December 2026 (Reg (EU) 2026/1744 amending Art. 113). This map is published in full regardless, for two reasons: the substance of Article 26 is unchanged, and the mechanisms below are already running in production, so the deferral converts a scramble into a planning horizon. Treat any vendor or adviser still presenting Article 26 as already binding on deployers with appropriate caution.

Article 27 (FRIA) is a separate obligation. The fundamental-rights impact assessment is Article 27, not an Article 26 paragraph, and it is not the same as the GDPR Art 35 DPIA referenced in Art 26(9). ComplyEdge's Art 27 rule blocks prompt text whose wording matches it, such as a claim to skip a FRIA, and the article-cited rule set supplies the legal citation. It matches wording, not meaning, so the same claim in other words can pass. It is not a FRIA workflow, and the assessment itself remains yours to produce.

Article 50 (transparency) binds from 2 August 2026: separate from Article 26. It splits by role: 50(1) direct AI-interaction disclosure and 50(2) machine-readable marking of synthetic content are provider duties (a company building its chatbot or content generator on a general-purpose AI model is the provider of that system); 50(3) emotion-recognition notice and 50(4) deepfake / AI-generated-text disclosure are deployer duties. All bind from 2 August 2026. (Omnibus Art. 111(4) in Regulation (EU) 2026/1744: systems placed on the market before that date have until 2 December 2026 for the 50(2) marking only.) Agents acting for a person. The Commission's final transparency guidelines (20 July 2026, C(2026) 5054) read 50(1) to cover AI agents: where an agent can make bookings, manage correspondence, negotiate or conclude contracts, or execute purchases, it should disclose both its artificial nature and the person on whose behalf it acts, so that delegated authority and accountability for the resulting action are visible. Pure machine-to-machine traffic stays outside 50(1); the duty bites when the agent reaches a person. ComplyEdge's Article 50 rules block a request whose wording matches them, such as text describing a missing disclosure; they match wording, not meaning, and cannot check that your interface or agent actually discloses, and they do not replace Art. 26(11).

The Article 50 Code of Practice asks for compliance documentation of your disclosures: it does not produce the runtime record. The Commission published the Article 50 Code of Practice on 10 June 2026 (covering Art. 50(2), (4) and (5); not Art. 50(3)). It is voluntary implementation support, not a new or binding obligation: Article 50 of Regulation (EU) 2024/1689 remains the legal baseline. For deployer signatories, Section 2 Measure 2.1 commits them to an internal compliance process and documentation of how Art. 50(4)/(5) labelling is implemented (icons or equivalent labels, placement, review). The Code does not supply machinery that writes that documentation when an AI system acts: browser-side checklists and marking validators around it are planning aids, not a compliance determination. ComplyEdge checks each call at runtime and records the decision. Where configured, ComplyEdge's Article 50 rules block a request whose wording matches them, such as text describing a missing 50(3) emotion notice or a missing 50(4) deepfake / public-interest text disclosure. They match wording, not meaning: a missing disclosure described in other words can pass, and a lawful request that names an exception Article 50 allows can still be blocked. They read only the text sent to them; they cannot see whether your interface actually shows the notice. Every check writes a logged event (event ID, timestamp, text_hash, citation when a rule fires), kept for 184 days, then expired (ComplyEdge default; note that the six-month floor in Art 26(6) binds only where the deployment is itself high-risk, and from 2 December 2027, so for an Article 50 deployer this retention is a product guarantee rather than a statutory minimum) and exportable, each record hash-chained as it is written. It is a record of which requests were checked and blocked; it can sit beside the compliance documentation Section 2 Measure 2.1 contemplates, but it does not document how your labels are implemented. The record holds no text: store the event ID each check returns next to your own copy of the prompt or answer, and check the pair with POST /v1/audit/verify when the documentation needs it (how audit reconciliation works).

Honest scope. ComplyEdge does not perform your organisational duties: worker notice (26(7)), registration (26(8)), competent-person assignment (26(2)), Annex III person-notice (26(11)), biometric authorisation (26(10)), or writing the DPIA/FRIA themselves. It blocks the eight original Article 5 practices, blocks requests whose text describes a missing Article 50 disclosure (it cannot confirm your interface discloses), and records every decision, with the legal citation when a rule fires, each record hash-chained as it is written so the export can be checked offline. That record can support the rest: it does not discharge them.