Article 26 Deployer Obligations, and where ComplyEdge records help
A line-by-line map, written as legal analysis rather than marketing. For each deployer obligation under Article 26 of Regulation (EU) 2024/1689, the specific ComplyEdge check or record that supports it, and an honest note where a duty is organisational and remains yours. Article 26 now applies from 2 December 2027 (status note below). What binds deployers from 2 August 2026 is Article 50 transparency, mapped in its own section.
From obligation to mechanism
| Art 26 | Deployer obligation (in substance) | ComplyEdge mechanism / evidence |
|---|---|---|
| 26(1) | Take appropriate technical and organisational measures to use the system per the provider's instructions for use. | Every decision records the versioned rule bundle (bundle_id), the digest of the rules that decided (bundle_digest) and the jurisdiction in force: configuration-in-force evidence. The rules themselves are open: the rule set shows which rule says what, under which article. Following the provider's instructions for use remains yours; the log does not prove instruction adherence. |
| 26(2) | Assign human oversight to competent, trained, resourced natural persons. | Async flags can be shown to a person. They do not block the call. On a paid plan the injection meaning check runs after a clean phrase pass when the month's model budget covers it, and can block. The wider legal review can also block when the month's model budget covers it, and it runs only when you turn it on. If that budget is used up, it does not run. None of these is Art. 26(2) assignment of oversight over your high-risk system. Appointing, training, and resourcing that person remains yours. |
| 26(3) | Paragraphs 1-2 are without prejudice to other obligations under Union or national law, and to your freedom to organise your own resources. | Interpretive provision: no technical mechanism. Listed for completeness. |
| 26(4) | Ensure input data is relevant and sufficiently representative, to the extent under deployer control. | Each input is recorded as a keyed hash (text_hash, HMAC-SHA-256 with a key per account) with agent identity and jurisdiction: an input-provenance trail without retaining raw content. The representativeness judgement remains yours. |
| 26(5) | Monitor operation per the instructions; inform the provider (Art 72) and market surveillance authority of risks; suspend use; report serious incidents (Art 73). | Runtime checks and optional drift monitoring produce a continuous decision log (with an article citation when a phrase rule or the injection check fires) that can support operational monitoring. ComplyEdge does not itself notify providers or market surveillance authorities under Art. 72/73, or suspend your system for you. |
| 26(6) | Keep the automatically generated logs, where under your control, for an appropriate period, at least six months unless other Union/national law applies. | Automatic logging of each ComplyEdge check: timestamp, agent identity, action, text_hash, and a legal citation when a phrase rule or the injection check fires; each record carries its write-time hash chain fields on every plan, and the Enterprise export adds the export-time chain (chain_link). Records are kept 184 days, then expire (a ComplyEdge guarantee, not a statutory term; longer retention is an Enterprise setting). This is the check/audit trail, not a substitute for every native log the high-risk system itself generates. |
| 26(7) | Employers: inform workers' representatives and affected workers before putting a high-risk system into use at the workplace. | Organisational duty (worker notice). Outside ComplyEdge's technical scope; listed for completeness. |
| 26(8) | Public-authority deployers: register the system in the EU database (Art 49); do not use it if unregistered. | Organisational / registration duty: outside ComplyEdge's technical scope; listed for completeness. |
| 26(9) | Where applicable, use the provider's Art 13 information to carry out the data protection impact assessment (DPIA) under GDPR Article 35. | ComplyEdge supplies the decision record, input provenance and article-cited rule basis the DPIA can draw on. The DPIA itself remains yours. Note: this paragraph concerns the DPIA: not the Article 27 fundamental-rights assessment (below). |
| 26(10) | For post-remote biometric identification in a criminal investigation, obtain prior judicial or administrative authorisation. | Organisational / judicial-authorisation duty: outside ComplyEdge's scope. (ComplyEdge's Art 5 rules separately block requests whose wording matches them; they match wording, not meaning, so a prohibited biometric practice described in other words can pass.) |
| 26(11) | Where an Annex III system makes, or assists in making, decisions about natural persons, inform those persons they are subject to it. | Organisational disclosure duty specific to Annex III high-risk use: without prejudice to Article 50. Art. 50 chatbot / marking / deepfake rules are a separate transparency regime; they do not discharge 26(11). Informing persons they are subject to the high-risk system remains yours. |
| 26(12) | Cooperate with competent authorities on any action regarding the system. | The audit export is an artifact you can hand to an authority: every check, with the legal citation when a phrase rule or the injection check fires; each record carries the hash chain it joined when it was written, so an edit, a gap or a reordering shows when the export is checked offline; on Enterprise the export also carries a completeness attestation. It records ComplyEdge's checks; it is not the high-risk system's own Art 12 log. |
text_hash, citation when a phrase rule or the injection check 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).Why this is different from a policy PDF
For the evidenceable substrate: configuration and jurisdiction on the record (26(1) support), async flags a person can read (they do not assign a human overseer under 26(2)), input provenance (26(4)), monitoring logs (26(5) support), check/audit log-keeping (26(6)), authority-facing export (26(12)), plus the Art 27 FRIA-gap rule: you get a continuous record generated at runtime (legal citation when a phrase rule or the injection check fires; each record hash-chained as it is written, checkable offline), not a periodic attestation. Organisational duties listed above stay yours. Confirm mappings with counsel before relying on them operationally.
Terms of Service · Refund Policy · Privacy Policy · DPA · SaaS Agreement
Primary sources: Reg (EU) 2024/1689 · Reg (EU) 2026/1744 · Art. 50 Code of Practice · Guidelines C(2026) 5054
ComplyEdge · EU AI Act Article 26 deployer one-pager · Article references follow Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 (application dates). Timeline verified 5 August 2026 against primary sources. Article 26 contains twelve paragraphs; sub-paragraph numbering above was verified against the consolidated text (log-keeping 26(6); worker notice 26(7); registration 26(8); DPIA 26(9); person-notice 26(11); cooperation 26(12)). Confirm with your counsel before relying on it operationally. Evidence artifact: the audit export (Art 12 record-keeping: high-risk duties from Dec 2027). How a reviewer checks them without a call: the page for auditors and certifiers.