Deployer Instructions-for-Use Compliance Record (EU AI Act, Article 26)

If you deploy a high-risk AI system someone else built, your compliance does not start with paperwork you invent — it starts with the instructions for use the provider hands you under Article 13. Article 26 of the EU AI Act, Regulation (EU) 2024/1689, then requires you to use the system in accordance with those instructions and to discharge a specific list of operational duties. This page gives you a fillable record that ties the two together: it documents that you read the provider's instructions, configured the system as told, and met each Article 26 obligation.

Use it as the deployer's standing evidence file. It is not the provider's technical documentation (that is Article 11 / Annex IV, the provider's job) and it is not a fundamental-rights assessment (that is the separate Article 27 FRIA). It is the deployer's own proof that the system is being operated the way the law and the provider's manual require.

---

Why a deployer needs this record

Most companies are deployers, not providers — you bought or licensed the AI rather than developing it and putting it on the market under your own name. The deployer's duties are lighter than founders fear, but they are real and they are audited. Article 26(1) is explicit: deployers must take appropriate technical and organisational measures to ensure they use high-risk systems in accordance with the Article 13 instructions for use. If you cannot show you read those instructions and acted on them, you cannot show Article 26 compliance.

The record below is structured so that each section maps to one duty. Keep it current — Article 26 is an ongoing obligation, not a launch-day formality.

---

What the provider owes you first (Article 13)

Before you can comply, the provider must give you the instructions for use. Article 13 requires those instructions to state, at minimum: the system's intended purpose; its level of accuracy, robustness and cybersecurity (the Article 15 metrics it was tested against); known limitations and foreseeable misuse; the human-oversight measures the provider built in (the Article 14 interface); the expected lifetime; and the computational and hardware needs. If the instructions are missing any of this, raise it with the provider — you cannot meet Article 26 against a manual that does not exist.

---

The deployer's Article 26 duties, mapped

Note the log-retention point: Article 26(6) requires deployers to keep the logs they control for a period appropriate to the intended purpose, at least six months unless other EU or national law says otherwise. The provider's own log-keeping duty sits under Article 19 — two separate obligations on two separate parties.

---

The template — fields to capture

1. System and provider identification

• System name, version, provider name and contact; whether the system is stand-alone (Annex III) or embedded in an Annex I product; EU database registration reference where applicable (the provider registers under Article 49); CE marking confirmed.

2. Instructions-for-use receipt (Article 13)

• Date instructions received; version; confirmation they cover intended purpose, Article 15 accuracy/robustness/cybersecurity levels, known limitations, foreseeable misuse, human-oversight measures, expected lifetime. Note any gaps raised with the provider.

3. Intended-purpose match

• Statement that your actual use falls within the provider's stated intended purpose. If it does not, stop: using a system outside its intended purpose can flip you into the provider role under Article 25.

4. Human oversight (Article 14 / Article 26(2))

• Named overseers; their competence and training; their authority and mechanism to intervene, override, or stop the system; how automation bias is countered.

5. Input data (Article 26(4))

• The input data you feed the system; your check that it is relevant and sufficiently representative for the intended purpose, to the extent the data is under your control.

6. Monitoring and escalation (Article 26(5))

• How you monitor operation against the instructions; the trigger and route to suspend use and notify the provider; link to your incident-response plan and to the serious-incident report the provider files under Article 73.

7. Log retention (Article 26(6))

• Where the system's automatically generated logs are stored; who controls them; retention period (at least six months); access controls.

8. Worker notification (Article 26(7))

• For workplace deployment: confirmation that workers' representatives and affected workers were informed before the system went live, and the date.

9. FRIA cross-reference (Article 27)

• If you are a public-body deployer, or you deploy a creditworthiness (Annex III point 5(b)) or life-and-health-insurance (5(c)) system, the reference to your completed FRIA. Most private employers do not trigger Article 27 — record that determination too.

---

Worked example: a deployer of a CV-screening system

Nordwind Personal GmbH, a recruitment agency with about 120 employees and roughly €19M turnover, licenses a high-risk CV-screening system (Annex III point 4, employment) from a vendor. Nordwind is a deployer, not the provider. It opens this record on day one: it logs receipt of the vendor's Article 13 instructions and confirms they state the system's accuracy levels and known limitations (the tool underperforms on non-standard CV formats). It names two recruiters as overseers with authority to override any automated reject (Article 14 / 26(2)), and — because this is a workplace system — it documents that the works council was informed before go-live (26(7)). It checks that the CV data it feeds in is representative of its actual applicant pool (26(4)), stores the system's decision logs for the full retention period (26(6), at least six months), and links its monitoring procedure to the provider so a malfunction can be flagged for an Article 73 report. Nordwind does not need an Article 27 FRIA — it is a private employer, not a public body and not deploying creditworthiness or insurance systems — and it records that conclusion.

---

How Confir helps

Confir holds each AI system's role determination, Annex III classification, the provider's Article 13 instructions reference, the named overseers, and the log-retention clock in one record, so the deployer's Article 26 evidence assembles from data you already entered rather than from a blank document at audit time. It separates the deployer's duties (Article 26) from the provider's (Articles 13, 19, 73) so you only see the obligations that are actually yours. The engine is deterministic and rule-based — the same intake produces the same finding every time.

---

Related guides

• Article 26 deployer obligations
• Deployer obligations under the EU AI Act
• Article 13 transparency and instructions for use
• Human oversight protocol template
• Provider versus deployer roles
• Article 12 record-keeping and logging