← auditaisdk.com · All articles
The first question an enterprise compliance officer asks an AI vendor is "is your product high-risk under Annex III?". The classification decision tree and the Article 6(3) exemption deep dive answer that one. But the moment classification lands on "yes, this is high-risk" — or even "we have not decided yet" — the second question follows immediately: "what do we have to do once we deploy it?".
That second question lives in Article 26. It is short on the page (one Article, thirteen paragraphs) but every paragraph creates an obligation that takes weeks to build into a real product. Procurement teams in 2026 know this. They open the contract package, find the AI risk assessment template, and the first column is "deployer obligations under Article 26 — who is performing them, with what evidence". If your sales engineer cannot fill that column on the call, the deal stalls.
A correctly built deployer-obligations file does three things at once: it tells procurement which Article 26 duties the customer keeps (most of them), which duties you cover for them via product features (a few — logging, oversight UI, transparency strings), and which duties never apply to this deployment because of scope (none of the eleven, usually). That memo is what unblocks signature.
Most of the confusion B2B SaaS teams have about Article 26 comes from not separating the two roles cleanly. The Act treats them as two different legal persons with two different files, even when they are the same company.
Develops or places an AI system on the EU market under its own name or trademark.
Owes: Annex IV file, conformity assessment, CE marking, EU database registration, post-market monitoring, providers' instructions for use.
Uses an AI system under its own authority. Excludes natural persons using AI for non-professional purposes.
Owes: Article 26 (eleven duties below). And, if a public authority or specific sector, Article 27 FRIA.
Three SaaS shapes to make this concrete:
The Act numbers them 1 through 13, but two paragraphs (12 and 13) are about authorities and exceptions, not generic duties. The eleven duties that apply to almost every commercial deployer are:
This sounds soft and is the most weaponised duty in the Article. The provider's instructions for use (delivered under Article 13) define intended purpose, known limitations, required input data characteristics, and operational constraints. The moment a deployer uses the system outside that envelope — different population, different data quality threshold, different decision threshold — they have breached Article 26(1) and may have triggered Article 25(1)(c) (substantial modification → deployer becomes provider).
Worked SaaS example. Your model classifies invoices for accounts payable. The instructions for use say "trained on EU invoices in English, French, German; minimum confidence 0.7 for auto-approval". A customer routes Chinese-language invoices through it because volume spiked. They have breached 26(1). If audited, fines flow to the deployer first, and your contract should let you suspend service.
What this means for your product. Ship machine-readable instructions: API responses that include a scope_violations field if the input is outside training distribution. Customers do not read PDFs; they ship code.
The deployer must designate which humans are the oversight humans for the system. Not "any user". Specific named persons with: the technical competence to understand the model, the authority to stop or override it, the time and resources to actually perform oversight, and protection from retaliation if they intervene.
Three failure modes seen in audits.
What this means for your product. Your admin UI should require a named oversight contact per deployment, surface that name in audit reports, and log every override that contact performs.
Interlock with Article 4 literacy. Article 26(2) requires competence and training; Article 4 sets the literacy floor for every staff member operating any AI system. The named oversight personnel under Article 26(2) carry two distinct training entries — the general Article 4 literacy module plus the system-specific oversight training. Full role-band matrix, policy and log in the Article 4 AI literacy programme walkthrough.
Where the deployer controls the input data (almost always the case), Article 26(3) makes them responsible for whether that data fits the model's intended purpose. This is the duty that bites compliance officers because it forces them to define their input quality criteria, not the vendor's.
Worked example. An education AI grades essays. The deployer feeds it scanned handwritten essays from a single school district. The model was trained on typed essays. The deployer has breached 26(3) by using input outside the training distribution. The damage is not theoretical — biased outputs hit specific students.
What this means for your product. Input-quality telemetry. Surface to the customer: distribution drift alarms, OCR confidence scores, language detection mismatches. Customers building their own Article 26 file will copy your telemetry into it.
Continuous monitoring against the provider's instructions, with a duty to inform the provider and the relevant authority if the system shows signs of presenting a risk to health, safety or fundamental rights. The standard for "inform" is "without undue delay" — operationally, days, not weeks.
Common failure mode. The deployer detects a regression, opens a vendor ticket, and stops there. Article 26(4) also requires informing the market surveillance authority for "serious incidents" (see Duty 8). A vendor ticket is not enough.
What this means for your product. A "report serious incident" button in the admin UI that pre-fills the authority notification under Article 73 (serious incident reporting). Most customers will never use it. The ones who do will sign because you made it easy.
If the deployer "has reason to consider" that use of the system poses a risk to health, safety or fundamental rights, they must suspend use and inform the provider and the authority. The trigger threshold is deliberately low — "reason to consider", not "has confirmed". A complaint from an affected person is enough.
Worked example. Three candidates complain that the screening AI returned identical rejection scores. The HR director "has reason to consider" the system may be malfunctioning. Article 26(5) requires immediate suspension and notification — not an investigation followed by a decision.
What this means for your product. A kill switch the customer controls. If your product cannot be turned off by the customer for a single deployment without engineering involvement, you have built a contract risk into it.
The provider must build automatic logging into the system (Article 12). The deployer must keep the logs for "at least six months" — longer if other law requires (GDPR, sectoral law, contract). The six months is a floor, not a ceiling. Banks keep them seven years.
Common failure mode. The provider ships logs as ephemeral cloud storage with a 30-day retention. The deployer assumes that's the file of record. It is not — the deployer is responsible for retention, full stop.
What this means for your product. Default log retention should be six months minimum, configurable up to seven years, with export to the customer's S3 or Azure bucket on a schedule. The export schedule should be documented in the deployer file.
If the deployer is an employer and the AI system is used in the workplace, the deployer must inform employee representatives and the affected workers before putting the system into service. The information is specific: what system, what use, what data, what decisions. Member State law on consultation (works councils, unions) still applies in addition.
Worked example. A retailer deploys an AI scheduling system that ranks shift swaps. They inform the works council before going live, including a one-page description of the model, the input data, and the appeal route. Workers see a notice in the staff portal explaining the AI is involved in shift decisions.
What this means for your product. Ship a "worker notice template" with every workplace-relevant product. Customers ask for it; very few customer legal teams know how to draft one without a starting template.
Article 26(8) refers back to Article 73, which defines "serious incident" (death, serious harm to health, serious damage to property/environment, serious infringement of fundamental rights). The deployer must report to the national market surveillance authority — not the provider's authority, the deployer's national authority — without undue delay and at most 15 days after becoming aware. Article 73 itself splits the threshold further: 2 days for widespread fundamental-rights infringement or serious and irreversible critical infrastructure disruption, 10 days where death is involved, 15 days residual default. The full thresholds matrix and the Annex IX-aligned eight-block report template live in the Article 73 serious incident reporting walkthrough.
Practical note. Most Article 26 incidents are not "serious" under Article 73. A model giving a wrong but recoverable result is not a serious incident. A model causing a job rejection that is later challenged in court might be. The threshold is high; the reporting duty when met is unambiguous.
What this means for your product. Internal escalation flow your customer can plug into. When the customer's compliance team flags a "potential serious incident", your incident response should automatically generate the Article 73 notification draft (system identifier, provider details, incident description, mitigation taken). Article 26(5) is the parallel chain — deployer notifies provider without undue delay, opening the provider's Article 73 awareness clock.
Article 26(11) requires the deployer to inform natural persons subject to decisions taken or assisted by the AI system that the AI is being used, and to inform them of the right to receive an explanation under Article 86. The information must be clear, in accessible form, and before the decision.
Worked SaaS example. An insurer uses AI to decide premium quotes. The deployer must tell each applicant — before the decision — that AI is involved, what role it plays, and that the applicant can request an explanation under Article 86. A footer line on the quote PDF is not enough; it must be visible and pre-decision.
What this means for your product. A copy-paste transparency string in your SDK's response. Three plain-language paragraphs the customer's frontend can render. Localised. Updated when the model or use case changes.
The deployer must provide to authorities, on reasoned request, all information necessary to demonstrate compliance with Article 26. That means having the Article 26 file ready — not assembling it during an investigation. Reasoned requests come with deadlines (typically 14 to 30 days). Missing them creates separate penalty exposure.
What this means for your product. Customer-facing audit-ready exports. A single "compliance bundle" download that pulls logs, oversight assignments, incident reports, FRIA (if any), and training records into one zip. Customers who can hand that to the authority in 24 hours rate you 5 stars.
Where the deployer is also a controller under GDPR, Article 26(9) requires the deployer to use the information from the AI provider (Article 13 instructions for use) when conducting the DPIA under Article 35 GDPR. This is not a new DPIA duty; it is a reminder that DPIA and Article 26 file overlap and must be consistent.
Common failure mode. The legal team writes the DPIA, the AI/ML team writes the Article 26 file, and the two contradict each other on data flows, retention, or model purpose. Auditors love finding this.
What this means for your product. A unified data-flow diagram you ship with every deployment. Both DPIA and Article 26 reviewers point at the same diagram.
Article 27 sits next to Article 26 and applies to a subset of deployers. It requires a Fundamental Rights Impact Assessment (FRIA) before putting into use a high-risk system, when the deployer is:
Full walkthrough: the Article 27 FRIA template deep dive covers the six items in Article 27(1) paragraph by paragraph, the Article 27(3) notification flow to the market surveillance authority, and the Article 27(4) DPIA articulation. Use it when the deployer profile matches; come back here for the Article 26 baseline that applies to every deployer.
The FRIA itself has six required components under Article 27(1)(a)–(f):
The FRIA must be notified to the market surveillance authority via a model template the AI Office is set to publish. Until that template is published, deployers prepare an internal FRIA in the format above and note "to be filed when template is published" in their compliance log.
| Action / Document | Provider | Deployer |
|---|---|---|
| Annex IV technical documentation file | ✔ Owns, builds, updates | Receives summary via Article 13 instructions |
| Conformity assessment + CE marking | ✔ Performs (Articles 43, 47, 48) | Verifies CE mark before deployment |
| EU database registration (Article 49) | ✔ Registers system (49(1)) | Registers use as deployer if public authority (49(3)) |
| Post-market monitoring plan (Article 72) | ✔ Owns plan, collects feedback | Provides feedback / incident data |
| Instructions for use (Article 13) | ✔ Drafts, ships with product | Reads, follows, audits compliance |
| Article 26 obligations (the eleven duties) | — | ✔ Owns all eleven |
| Article 27 FRIA | — | ✔ If public body, public-service operator, credit, or insurance |
| Article 73 serious incident report | ✔ For incidents in operation | ✔ For incidents at point of use |
| Article 86 explanation of individual decision | Provides technical input | ✔ Delivers explanation to affected person |
| DPIA (GDPR Art. 35) using AI info | Provides Article 13 info | ✔ Conducts DPIA if controller |
We ship the full deployer-obligations package — eleven duties checked off, FRIA template included, named oversight assignment, incident response runbook, transparency strings, six-month log retention plan, audit-ready export. Procurement signs. Engineering keeps building.
Get the €199 managed audit →A defensible memo is one page per duty. The standard structure procurement accepts:
DEPLOYER OBLIGATIONS — ARTICLE 26 EU AI ACT
System name: [Acme Hiring Assistant v2.4]
Provider: [Acme AI BV — registered as EU-XXXX in the AI database]
Deployer: [Customer Ltd, Recruitment Operations]
Intended use: [Initial CV ranking, recruiter-supervised, EU candidates only]
Date: [2026-05-11]
DUTY 1 — Use per instructions for use (Art. 26(1))
Provider IFU version: [v2.4 — dated 2026-04-22]
Scope check: [PASS — use within "EU candidates, English/Spanish, recruiter review required"]
Out-of-scope blocks: [Auto-routing of non-EU candidates disabled in admin settings]
Evidence: [link to provider IFU PDF and scope-check API log]
DUTY 2 — Human oversight (Art. 26(2))
Oversight officer: [Name, role, hire date — Senior Recruiter, 3+ years tenure]
Authority: [Can override any AI score; can suspend deployment]
Training: [4-hour onboarding, recorded — see attachment 02]
Backup: [Named substitute, equivalent authority]
DUTY 3 — Input data control (Art. 26(3))
Input scope: [CV PDFs, English/Spanish, post-2020 format]
Drift monitoring: [Daily distribution check, alarm at 2 sigma]
Last drift event: [2026-04-18 — Spanish CVs spike, model retrained by provider]
DUTY 4 — Operational monitoring (Art. 26(4))
Monitoring frequency: [Continuous via provider API + weekly internal review]
Last review date: [2026-05-08 — no anomalies]
DUTY 5 — Suspension procedure (Art. 26(5))
Trigger conditions: [List of three triggers — see attachment 05]
Kill switch owner: [Oversight officer + Head of People]
Last drill: [2026-03-12 — kill switch tested in 4 minutes]
DUTY 6 — Log retention (Art. 26(6))
Retention period: [12 months — exceeds 6-month floor]
Storage: [Customer S3 bucket, KMS-encrypted]
Export schedule: [Daily, automated]
DUTY 7 — Worker notification (Art. 26(7))
Worker notice issued: [2026-04-30 to all hiring managers]
Works council: [Notified 2026-04-22 via formal letter — attachment 07]
Candidate notice: [Visible at start of application flow]
DUTY 8 — Serious incident reporting (Art. 26(8), Art. 73)
Authority: [National market surveillance authority — XYZ]
Reporting flow: [Internal escalation → 24h authority notification draft]
Last filing: [None — no serious incident to date]
DUTY 9 — Transparency to affected persons (Art. 26(11))
Notice location: [First page of application flow]
Notice text: [Attachment 09 — reviewed by legal 2026-04-20]
Article 86 explanation:[Rejected candidates receive explanation within 30 days on request]
DUTY 10 — Cooperation with authorities (Art. 26(10))
Bundle export: [One-click "compliance bundle" via provider admin UI]
Last drill: [2026-04-25 — bundle generated in 90 seconds]
DUTY 11 — DPIA (Art. 26(9))
DPIA reference: [DPIA-2026-014 — completed 2026-04-15]
Data flow diagram: [Shared with Article 26 file — attachment 11]
ARTICLE 27 FRIA — APPLICABLE? [NO — private deployer, not credit / insurance]
[If YES: attach FRIA-2026-XXX, six required sections]
Signed by Compliance Officer: ___________________ Date: ___________
One page per duty, evidence linked from each. Procurement reviews this in 45 minutes. Without it, the same review takes weeks and ends in escalation.
A subtle but common failure: the SaaS team treats itself only as "provider" and forgets that using third-party AI components inside their own product makes them a deployer of someone else's AI. This creates a dual-file situation that procurement does not always spot but that authorities will.
Worked example. A SaaS sells fraud-detection AI to banks. The product internally calls a third-party LLM for natural-language summarisation of transaction patterns. The SaaS is provider to the bank (Article 16 + Annex IV file) and deployer of the LLM (Article 26 file pointing at the LLM vendor). Both files must exist. Skipping the deployer file because "we are the provider" is a clear breach.
If you cannot answer the question "which Article 26 duties do we owe as a deployer of the third-party AI inside our product?" in one minute, you have a hole. Fix it before procurement notices.
Article 99 sets the fine ceilings. Article 26 obligations fall under Article 99(4): up to €15 million or 3% of total worldwide annual turnover of the preceding financial year, whichever is higher. SMEs benefit from a proportionality cap (Article 99(6)) but the headline rate is the same.
In practice, authorities will graduate from formal notice → corrective order → fine, in that order, for first-time deployer violations. Repeat offenders see escalation. The greater risk for B2B SaaS is not the fine — it is the commercial damage from being publicly named as the AI vendor whose customer was sanctioned.
The auditai SDK ships an export tailored for Article 26 deployers:
auditai.transparency_text(use_case="hiring") returns the Article 26(11) plain-language paragraph for the customer's frontend to render before any AI-assisted decision.Three lines of code, one compliance bundle per deployment, ready to hand to your customer's procurement team.
pip install auditai-sdk
from auditai import AuditAI
audit = AuditAI(deployer="Customer Ltd", system_id="acme-hiring-v2.4")
audit.export_article_26_bundle("./bundle.zip")
If you fine-tune, brand, or distribute it under your own name, you become provider for that derived system. You are also deployer of the upstream model. Two files. The cleanest way to avoid this is to use the model unmodified, under the upstream provider's name — but most SaaS teams do at least light fine-tuning, so dual-file is the realistic default.
No. Article 26 only applies to deployers of high-risk AI. For non-high-risk AI, the only generic deployer duty is Article 50 transparency (telling users they are interacting with AI), and only in specific cases. The Article 6(3) exemption is what most B2B SaaS uses to take their product out of high-risk and therefore out of Article 26 entirely — see the 6(3) deep dive.
You cannot transfer the statutory obligation — Article 26 is owed to the authority by the deployer. You can, however, contractually allocate who builds the evidence. Most enterprise contracts have the provider supply the templates, telemetry, and log retention while the deployer signs and dates each item. This is normal and accepted.
You report it to the provider. If they do not remediate, you report to the market surveillance authority. You should not deploy without proper instructions — Article 26(1) implicitly requires them, and Article 26(3) input-control duty cannot be met without them.
Annex III deadline shifted to December 2027 after the May 2026 Omnibus — see the deadlines timeline. But enterprise procurement is asking for the deployer file today, regardless of the legal deadline. The market is faster than the law on this one.
No. They overlap but are separate documents under separate laws. The FRIA is Article 27 of the AI Act; the DPIA is Article 35 of GDPR. They use shared data flow diagrams and shared risk language but live in separate files. If you only do one of them, you have a problem.
If the AI output is used in the EU or affects EU persons, Article 26 applies regardless of where the deployer is incorporated. Extraterritoriality is in Article 2(1)(c). US deployers practical advice: appoint an EU authorised representative under Article 22, run the same Article 26 file, and hold it ready for the relevant national authority.
Article 25 says when a deployer becomes a provider (substantial modification, putting own name on it, changing intended purpose). Article 26 says what duties a deployer has while remaining a deployer. If Article 25 triggers, you exit Article 26 and enter provider duties (Annex IV file, CE marking, the whole package).
Article 26 is procurement's checklist. The deal moves when your customer can fill the eleven boxes; it stalls when they cannot. The fastest path for a B2B SaaS is to ship the boxes pre-filled — telemetry the customer copies into their file, templates for notices, FRIA scaffolding for the two trigger categories, one-click audit bundle.
Most SaaS teams discover Article 26 the day a customer's legal team asks for the file. By that point the deal has weeks of friction baked in. The teams that ship the deployer-obligations package as a default product feature win the procurement reviews their competitors lose.
If you want the file done for you — five business days, signed, defensible, with FRIA when it applies — the €199 managed audit delivers the exact memo above, populated with your real product details.
This article is informational and reflects the EU AI Act as in force after the May 2026 Omnibus delay. It is not legal advice. The managed-audit deliverable is a compliance memo, not a legal opinion; engage qualified counsel for binding interpretation. Article references are to the EU AI Act consolidated text.