Article 26 of Regulation (EU) 2024/1689 sets out the obligations of deployers of high-risk AI systems. aiegis Eye is the provider of the monitoring system; the customer is the deployer. This page maps each sub-paragraph (1 through 12) to the aiegis code path that supports evidence for it, or explicitly flags it as out of provider scope.
Article 26 binds the deployer — the natural or legal person using the AI system under their own authority. aiegis Eye is not the deployer of the customer's high-risk AI; the customer's organisation is. AIEGIS provides technical controls and records that may support selected Article 26 activities. The deployer remains responsible for satisfying every applicable legal and organisational obligation.
The split below distinguishes obligations the aiegis code path may provide potential technical contribution toward (sub‑paragraphs 1, 2, 5, 6) from obligations that aiegis provides infrastructure or templates for but only the deployer can complete (3, 4, 7, 8, 9, 10, 11, 12).
The authoritative regulation text is at artificialintelligenceact.eu/article/26. Quoted excerpts on this page are reproduced verbatim from that source.
POST /api/protect is evaluated against the org's policy bundle across 15 enforcement layers (L1 Identity through L15 Correlation). Decisions are emitted as {"decision":"ALLOW|WARN|BLOCK|DENY","reason":"…","layer":"L…"} and persisted to agent_logs. The auto-generated checklist at /api/admin/compliance/eu-ai-act-checklist reports the live count of scanned requests as the Art. 26§1 evidence field. Evidence must be combined with the high-risk system's instructions for use, policies, training records and organisational controls./it/violations queues every BLOCK / WARN decision for review by a named human reviewer. Reviewer actions are written to the violation_actions table with action_type='mark_reviewed'; the checklist reports human_reviews_completed as the live evidence field. Deployer must complete: formally assign named personnel to the IT oversight role and document in the risk register./api/admin/compliance/audit-export?days=30&format=json returns the full record set for the period with "framework":"EU AI Act Article 26" in the header. Serious-incident webhook alerting is wired in the dispatcher; the deployer configures the destination (SIEM or incident-response platform) per their own reporting chain.agent_logs with agent_id, action, target, decision, threats, timestamp, decision_ms. Customers configure retention based on applicable law and purpose. Where Article 26(6) applies, the configuration can support retention for at least six months. Signed evidence manifests for any period are produced by GET /api/policy/evidence?org_id=…&from=…&to=…, signed against the public key published at /.well-known/AIEGIS-evidence-pubkey/<org_id>.pem.GET /compliance/worker-notice-template. The template covers what is monitored, why, who sees the data, and the employee's rights of access. Deployer must complete: issue the notice to workers and their representatives before aiegis is enabled./api/policy/evidence to support the registration submission, but does not file on the deployer's behalf./dpia so the deployer's DPO can incorporate the data-flow, retention and lawful-basis sections without re-deriving them./.well-known/AIEGIS-evidence-pubkey/<org_id>.pem. Deployer must complete: respond to authority requests using the manifest as evidence; aiegis does not communicate with authorities on the deployer's behalf.The block below is a real response from production. The L1 Identity layer rejected an unauthenticated request; the response carries the layer name, the human-readable reason, an error code, and the decision latency in milliseconds. The same envelope shape carries higher-layer reasons (L4 Scope, L6 Input Sanitizer, L7 Memory Integrity, L9 Meta Security, L13 MCP Registry, L14 Confidence Scoring, L15 Correlation).
The requires_human_review field on the L14 Confidence Scoring response is the §6 / §2 human-oversight gate signal: when an action's computed confidence falls into the review band, L14 emits a review_id and the decision is queued in the IT Violation Centre for the deployer's named reviewer.
Reproduce locally:
The auto-generated Article 26 checklist (admin-scoped) compiles these signals into a per-sub-paragraph status report sourced entirely from live data — no manual attestation. The signed evidence manifest at /api/policy/evidence packages the same data for authority cooperation under §12.
EU AI Act Article 26 binds the deployer of a high-risk AI system — the natural or legal person, public authority, agency or other body using the system under their own authority — not the provider who placed the AI model on the market. The distinction is structural: a hospital using a high-risk diagnostic AI is the deployer; the vendor that trained the diagnostic model is the provider; aiegis Eye, when deployed by that hospital to govern the agent traffic, is the provider of the governance system, not the deployer of the high-risk AI.
In practice this means the twelve sub-paragraphs of Article 26 sit on the customer of aiegis, not on aiegis itself. aiegis publishes the evidence pack, the signed manifest, the human-review queue, and the configurable retention period; the deployer still owns the legal acts — informing workers (§7), filing with the AI Office (§8), conducting the DPIA under GDPR Article 35 (§9), informing affected natural persons (§11), and responding to competent authorities (§12).
This split is why the page above tags each sub-paragraph as Technical support / evidence contribution, Partial, Deployer-only, or Legal qualifier. The tag is not a marketing distinction — it is the boundary between what aiegis can contribute with technical controls and records and what only the deployer can prove with their own organisational records.
Article 26(5) requires deployers who form a reason to consider that the use of a high-risk AI system may present a risk within the meaning of Article 79(1) to inform, without undue delay, the provider or distributor and the relevant market surveillance authority. The relevant authority is determined by Member State, not by Brussels. Each Member State has designated (or is designating) a national competent authority under Article 70 of Regulation (EU) 2024/1689. The examples below reflect the position as of July 2026 and are subject to change. Customers must verify the competent authority for their sector and use case at the time of notification.
The signed evidence manifest produced by GET /api/policy/evidence is jurisdiction-agnostic in form — the same artefact serves a CNIL request, an AESIA request, or an Irish DPC request. The deployer routes the manifest; aiegis produces it.
The EU AI Act sets a tiered penalty structure under Article 99. Non-compliance with the prohibited-practices regime under Article 5 carries the highest tier: up to EUR 35 million or 7 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. Non-compliance with most other obligations — including deployer obligations under Article 26 — sits in the middle tier: up to EUR 15 million or 3 percent of total worldwide annual turnover, whichever is higher. Supplying incorrect, incomplete or misleading information to notified bodies or competent authorities carries up to EUR 7.5 million or 1 percent of turnover.
For SMEs and start-ups the same ceilings apply but the regulation requires national authorities to apply the lower of the absolute and percentage figures, and to take into account the size and economic context. Public authorities and Union institutions are subject to administrative fines set by the European Data Protection Supervisor under Article 100 with separate but comparable ceilings.
Certain breaches may fall within the Article 99 penalty regime. Maximum ceilings are not automatic and the applicable amount depends on the circumstances and final legal text. The cost of an aiegis deployment is small against that ceiling, which is why the harness is sold as risk-reduction infrastructure rather than as a compliance checkbox.
Article 26 entered into force on 1 August 2024. Relevant Annex III high-risk obligations are expected to apply from 2 December 2027, with product-integrated high-risk rules from 2 August 2028, subject to final legislative publication. As of mid-2026 no Court of Justice ruling has yet interpreted any sub-paragraph; national-authority guidance is the primary supplementary source. Three interpretive gaps are worth tracking:
The boundary of §1 "appropriate technical and organisational measures." The text is structurally similar to GDPR Article 32, where courts have generally treated "appropriate" as a moving baseline tied to the state of the art. What "appropriate" means in practice will be clarified through national guidance and, over time, case law.
Minimum retention under §6. Six months is the explicit minimum, but the regulation says retention must be "appropriate to the intended purpose." Sector-specific retention rules (financial services, medical devices, employment) can require a longer period; Customers configure retention based on applicable law and purpose. Where Article 26(6) applies, the configuration can support retention for at least six months.
The scope of §5 "without undue delay." The GDPR analogue ("72 hours" in Article 33) is explicit; Article 26(5) is not. Organisations should seek advice on the applicable reporting timeline under national guidance once it is issued.
What does EU AI Act Article 26 actually require? Twelve sub-paragraph obligations on the deployer of a high-risk AI system: technical and organisational measures, human oversight, monitoring, input data control where the deployer controls it, automatic log retention as required by paragraph 6 (at least six months), worker notification, public-authority registration where applicable, GDPR DPIA integration, law-enforcement authorisation for post-remote biometric identification (applicable to law-enforcement deployers only), notice to affected natural persons, and cooperation with competent authorities.
What are EU AI Act deployer obligations? The set of obligations binding the natural or legal person using a high-risk AI system under their own authority. The deployer is distinct from the provider (who placed the model on the market) and is bound by Article 26 in particular.
When does Article 26 apply? Relevant Annex III high-risk obligations are expected to apply from 2 December 2027, with product-integrated high-risk rules from 2 August 2028, subject to final legislative publication. Prohibited-practices obligations under Article 5 applied earlier, from 2 February 2025.
What is the deployer's penalty exposure? Up to EUR 15 million or 3 percent of total worldwide annual turnover, whichever is higher, for breach of deployer obligations under Article 26. These are maximum ceilings under Article 99; actual penalties are not automatic and depend on the specific infringement, the enforcement decision and the final legal text.
Article 26(1) — technical and organisational measures. The opening obligation is structurally similar to GDPR Article 32. It requires the deployer to use the high-risk AI system in accordance with the instructions for use and to take appropriate technical and organisational measures to ensure that use. aiegis provides technical controls and records that may support selected Article 26(1) activities by evaluating every action through the 15-layer chain and persisting the decision to the audit ledger.
Article 26(2) — human oversight. The obligation is to assign human oversight to natural persons with the necessary competence, training, authority and support. The named human reviewer is a personnel act, not a technical one. aiegis provides the infrastructure: the IT Violation Centre queue, the named-reviewer column in the violation_actions table, and the L14 Confidence Scoring gate that triggers human-review routing. The deployer assigns the personnel and documents the assignment in the organisational risk register.
Article 26(3) — without prejudice clause. A legal qualifier rather than an operational obligation. It clarifies that paragraphs 1 and 2 do not displace other deployer obligations under Union or national law and do not constrain the deployer's organisational freedom. There is no technical step.
Article 26(4) — input data control. Where the deployer exercises control over input data the deployer must ensure the data is relevant and sufficiently representative in view of the intended purpose. Model training data is the deployer\'s own governance process; aiegis does not see training data. Operational input data flowing through the agent is in scope of the harness: L3 Data Sentinel flags PII, secrets and regulated data classes on the wire, and L6 Input Sanitizer flags prompt injection and tool poisoning patterns.
Article 26(5) — monitoring and incident reporting. Continuous monitoring is the platform\'s primary function. The serious-incident webhook is wired through the dispatcher with sub-hour latency from log to dispatch; the deployer configures the destination (SIEM, incident-response platform, or direct authority feed) per the national reporting chain.
Article 26(6) — log retention. Six months is the explicit floor. Customers configure retention based on applicable law and purpose. Where Article 26(6) applies, the configuration can support retention for at least six months.
Article 26(7) — worker notification. Before putting the system into service at the workplace, deployers who are employers shall inform workers\' representatives and the affected workers. This is a deployer act; aiegis publishes a worker-transparency notice template at the compliance endpoint, but the deployer issues the notice. The notice covers what is monitored, why, who sees the data, and the employee rights of access.
Article 26(8) — public-authority registration. Deployers that are public authorities, or Union institutions, bodies, offices or agencies must comply with the Article 49 registration in the EU AI Office database. The registration is a deployer filing that cannot be delegated to a provider. aiegis supplies the exportable evidence pack to support the submission but does not file on the deployer\'s behalf.
Article 26(9) — GDPR DPIA integration. Where applicable the deployer uses the information provided under AI Act Article 13 to comply with the GDPR Article 35 DPIA obligation (or the Article 27 obligation under the Law Enforcement Directive). DPIA authoring stays the deployer\'s GDPR obligation. aiegis publishes its provider-side DPIA inputs — data flows, retention rules, lawful bases, processor chains — so the deployer DPO can integrate them directly into the organisational DPIA without re-derivation.
Article 26(10) — law-enforcement authorisation for post-remote biometric identification. Law-enforcement deployers of post-remote biometric identification systems must obtain judicial or administrative authorisation before deployment, or within 48 hours for urgent cases. This sub-paragraph applies only to that narrow law-enforcement category and is not applicable to most AIEGIS customers. aiegis does not operate in this category.
Article 26(11) — notice to affected natural persons. For Annex III systems that make or assist in making decisions related to natural persons, the deployer must inform those persons that they are subject to the use of the high-risk AI system. The notice goes in the deployer\'s customer-facing flow; aiegis monitors the internal agent-to-tool boundary, not the deployer\'s customer UI, and so the notice is a deployer-only act.
Article 26(12) — cooperation with competent authorities. The deployer cooperates with the relevant authority on any action taken to implement the regulation. The signed manifest may be included among the materials used by the deployer when responding to a competent authority. It carries an SHA-256 audit digest of the rule set and event stream over the requested period, signed in-process before return, with the verification public key published at a well-known path. The deployer responds to the authority using the manifest as evidence; aiegis does not communicate with authorities directly.
The pattern across all twelve sub-paragraphs: aiegis converts what would otherwise be paper attestation into machine-verifiable evidence wherever the obligation is technical, and provides templates wherever the obligation is organisational. The deployer keeps the legal acts; the harness keeps the receipts.