# Instructions for Use: [High-risk AI system] [version]

> Deployer-facing instructions for use for a high-risk AI system,
> organised on Article 13 of the EU Artificial Intelligence Act
> (Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744,
> the Digital Omnibus on AI). It covers provider identity, intended
> purpose, accuracy and its metrics, robustness and cybersecurity, known
> risks and misuse, performance for specific groups, input data, output
> interpretation, pre-determined changes, human oversight, resources and
> maintenance, and logging. Replace every `[bracketed]` value and every
> row marked *Example*. Under the amended Article 113, Chapter III
> Sections 1 to 3, which include Article 13, apply from 2 December 2027
> for Annex III systems and from 2 August 2028 for Annex I systems; check
> the consolidated text. This is a documentation format, not legal
> advice: check the current official text and a qualified professional.

<!--
Guidance: How to use this template
- Write for the deployer's staff, not for your engineers. Article 13(2)
  asks for information that is concise, complete, correct and clear, and
  that deployers can access and understand. Test the draft with one
  real deployer user before release.
- Section numbers 3 to 8 follow Article 13(3)(a) to (f). Keep them so a
  notified body or market surveillance authority can trace each item.
- Every number must come from the technical documentation (Annex IV)
  and the test reports. Never quote a metric here that the technical
  documentation does not support.
- Deployers rely on this document for their own duties: Article 26(1)
  use in line with the instructions, Article 26(5) monitoring, Article
  26(9) DPIA input and Article 27 FRIA input. Write so they can do that.
- Issue a new version with every release that changes performance,
  oversight measures or logging, and keep old versions available to
  deployers still running older releases.
-->

## Document control

<!-- Guidance: Tie the instructions to one exact system version. A deployer must be able to check that the version running matches the version described. -->

| Field | Value |
|---|---|
| Document ID | [IFU-001] |
| System name and version | [Name, version, build] |
| Provider | [Legal name] |
| Version of these instructions | [1.0] |
| Status | [Draft / Released / Superseded] |
| Owner | [@product-owner] |
| Reviewers | [@ml-lead], [@regulatory], [@technical-writer], [@security] |
| Linked technical documentation | [Annex IV file ID] |
| Linked declaration of conformity | [DoC ID] |
| Release date | YYYY-MM-DD |
| Languages available | [List, per the Member States where the system is made available] |
| Format | [Online help / PDF / in-product] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Product owner | [@name] | [Approve] | YYYY-MM-DD |
| Regulatory lead | [@name] | [Approve] | YYYY-MM-DD |
| Quality manager | [@name] | [Approve] | YYYY-MM-DD |

### Revision history

| Version | Date | System version | Change summary |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | 2.4 | *Example:* First release for CRV Shortlist 2.4 |
| 1.1 | YYYY-MM-DD | 2.4.1 | *Example:* Added age-band performance table after deployer request |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [About these instructions](#1-about-these-instructions)
2. [Quick reference](#2-quick-reference)
3. [Provider identity (Article 13(3)(a))](#3-provider-identity-article-133a)
4. [Characteristics, capabilities and limitations (Article 13(3)(b))](#4-characteristics-capabilities-and-limitations-article-133b)
5. [Pre-determined changes (Article 13(3)(c))](#5-pre-determined-changes-article-133c)
6. [Human oversight measures (Article 13(3)(d))](#6-human-oversight-measures-article-133d)
7. [Resources, lifetime and maintenance (Article 13(3)(e))](#7-resources-lifetime-and-maintenance-article-133e)
8. [Logging (Article 13(3)(f))](#8-logging-article-133f)
9. [Deployer checklist](#9-deployer-checklist)
10. [Glossary and references](#10-glossary-and-references)

## 1. About these instructions

<!-- Guidance: Say who the document is for, what it covers and what it does not. Point to the in-product help if the instructions are also delivered there. -->

These instructions are for organisations that use [System name] under
their own authority (deployers) and for the staff they assign to
operate and oversee it. Read sections 2, 4.7 and 6 before first use.

*Example:* These instructions cover CRV Shortlist 2.4 by Tarnwick
Analytics, a system that ranks job applications against criteria set by
the recruiter. They do not cover the separate CRV Schedule Assist
module, which has its own documentation.

## 2. Quick reference

<!-- Guidance: One table a busy user can read in a minute. Every line must match the detailed sections below. -->

| Item | Summary |
|---|---|
| Intended purpose | *Example:* Rank applications for a vacancy to help a recruiter decide whom to invite to interview |
| Not intended for | *Example:* Automatic rejection, promotion or dismissal decisions, roles outside the supported job families, applicants under 18 |
| Headline accuracy | *Example:* Recall 0.80 and precision 0.67 for the "invite" band on the 2.4 validation set (section 4.2) |
| Main limitation | *Example:* Lower recall for applicants aged 50 and over (0.70) |
| Human oversight | *Example:* A recruiter must review the ranked list and may invite anyone regardless of rank |
| Logs | *Example:* Ranking events and overrides, exportable by the deployer, retained 12 months by default |

## 3. Provider identity (Article 13(3)(a))

<!-- Guidance: Give the legal identity and a working contact, and the authorised representative if the provider is outside the EU. -->

| Item | Value |
|---|---|
| Provider | [Legal name, registered address] *Example:* Tarnwick Analytics |
| Contact for deployers | [Support address, phone, portal] |
| Authorised representative in the EU (if applicable) | [Name, address, contact] |
| Serious incident and risk reports | [Dedicated channel] |

## 4. Characteristics, capabilities and limitations (Article 13(3)(b))

<!-- Guidance: This is the core of the document. Subsections 4.1 to 4.7 follow points (i) to (vii) of Article 13(3)(b). Use plain language next to every metric. -->

### 4.1 Intended purpose (point (i))

[State the intended purpose, the specific context and the conditions of
use, including users, persons affected, settings and geographic scope.]

*Example:* CRV Shortlist ranks applications for warehouse, driver and
customer service roles in the EU. Recruiters set the job criteria and
see a ranked list with three bands: invite, review, and low match. The
system is intended for organisations that review each list with a
trained recruiter.

### 4.2 Accuracy, robustness and cybersecurity (point (ii))

<!-- Guidance: Article 15 requires the levels of accuracy and the relevant metrics to be declared here. State the test set, the date and the metric definitions. -->

*Example:* Validation set of 4,000 historical applications with
recruiter decisions, collected YYYY-MM-DD to YYYY-MM-DD; 800 were
invited to interview by recruiters (the reference label).

| Metric | Definition | Value *(Example)* |
|---|---|---|
| Recall (invite band) | Share of reference invitees the system places in the invite band | 0.80 (640 of 800) |
| Precision (invite band) | Share of invite-band applications that were reference invitees | 0.67 (640 of 960) |
| False positive rate | Share of non-invitees placed in the invite band | 0.10 (320 of 3,200) |
| Accuracy | Share of applications placed correctly in or out of the invite band | 0.88 (3,520 of 4,000) |

What this means: about one in five suitable applicants is not in the
invite band, so recruiters must look beyond it (section 6).

| Robustness and cybersecurity item | Value |
|---|---|
| Robustness tests | *Example:* Recall changes by no more than 0.02 when CVs are reformatted or translated |
| Known factors affecting performance | *Example:* Very short CVs, scanned CVs with OCR errors, job criteria with fewer than three requirements |
| Cybersecurity measures | *Example:* Prompt and file injection filtering on CV upload, tenant isolation, see security annex |

### 4.3 Known and foreseeable risks (point (iii))

| ID | Circumstance | Possible harm | Mitigation |
|---|---|---|---|
| RSK-01 *(Example)* | Recruiter invites only the invite band | Suitable applicants missed, indirect discrimination | Oversight measure OM-01 |
| RSK-02 *(Example)* | Misuse to screen out applicants automatically | Decisions without human review | Not supported; auto-reject is disabled in the product |
| RSK-03 *(Example)* | Criteria that act as proxies for protected characteristics | Discrimination | Criteria checker warns on terms such as graduation year |

### 4.4 Explainability (point (iv))

*Example:* Each ranked application shows the three criteria that
contributed most to its band. These are approximations of the ranking
logic, not a full explanation; deployers can export them to answer
requests under Article 86.

### 4.5 Performance for specific persons or groups (point (v))

<!-- Guidance: Report the groups that matter for the intended purpose and say where data was not available. Never leave this out because results are unflattering. -->

| Group *(Example)* | Reference invitees | Recall | False positive rate | Precision |
|---|---|---|---|---|
| Aged under 50 | 690 | 0.82 (563) | 0.10 (284 of 2,710) | 0.66 |
| Aged 50 and over | 110 | 0.70 (77) | 0.07 (36 of 490) | 0.68 |
| All | 800 | 0.80 (640) | 0.10 (320 of 3,200) | 0.67 |

Data on disability and ethnic origin was not available in the
validation set. [State how deployers should monitor these groups.]

### 4.6 Input data and datasets (point (vi))

| Item | Value |
|---|---|
| Required input | *Example:* CV as PDF or DOCX up to 5 MB, application form fields 1 to 12, job criteria |
| Languages supported | *Example:* English, German, French, Spanish, Polish |
| Training, validation and test data | *Example:* Summary in technical documentation section 2.3; datasheet DS-007 |
| Inputs to avoid | *Example:* Photographs, dates of birth and other data not needed for the criteria |

### 4.7 Interpreting the output (point (vii))

*Example:* Bands are a ranking aid, not a suitability decision. A low
match band means the CV text matched few of the stated criteria; it
does not mean the applicant is unqualified. Never send a rejection based
on the band alone.

## 5. Pre-determined changes (Article 13(3)(c))

<!-- Guidance: List only changes assessed at the initial conformity assessment. Anything else may be a substantial modification. -->

| Change | Limits assessed | How deployers are informed |
|---|---|---|
| *Example:* Quarterly recalibration of band thresholds | Recall in the invite band stays between 0.78 and 0.84 overall and no group falls below 0.68 | Release note and updated section 4.2 |
| [None] | | |

## 6. Human oversight measures (Article 13(3)(d))

<!-- Guidance: Describe the Article 14 measures and the technical features that support them, and what the deployer must do. Deployers use this section to assign oversight under Article 26(2). -->

| ID | Measure | Built into the system | Deployer action |
|---|---|---|---|
| OM-01 *(Example)* | Review beyond the invite band | Review band shown by default; list cannot be closed before the review band is opened | Train recruiters to check the review band for every vacancy |
| OM-02 *(Example)* | Override | Recruiter can move any applicant to invite with one click; overrides are logged | Give recruiters authority to override |
| OM-03 *(Example)* | Stop | Administrator can pause ranking per vacancy or tenant | Name who may pause |
| OM-04 *(Example)* | Automation bias warning | Banner on first use each day | Include in training |

Competence needed by oversight staff: [*Example:* completion of the
provider's 4-hour module, knowledge of the job criteria and of the
limits in section 4.5].

See ai-data/human-oversight-design for the provider's oversight design
record.

## 7. Resources, lifetime and maintenance (Article 13(3)(e))

<!-- Guidance: State compute and hardware needs, the expected lifetime and the maintenance and update cycle. -->

| Item | Value |
|---|---|
| Deployment | *Example:* Provider-hosted SaaS; no deployer hardware |
| Expected lifetime of this version | *Example:* Supported until YYYY-MM-DD |
| Updates | *Example:* Security patches monthly; model recalibration quarterly (section 5) |
| Deployer maintenance | *Example:* Review job criteria every six months; keep user list current |

## 8. Logging (Article 13(3)(f))

<!-- Guidance: Describe what Article 12 logs exist, how deployers collect, store and read them, and the retention default. Deployers must keep logs under their control for at least six months (Article 26(6)). -->

| Item | Value |
|---|---|
| Events logged | *Example:* Ranking request, band per application, criteria used, model version, recruiter overrides, pauses |
| Access | *Example:* Export as CSV or via API by tenant administrators |
| Default retention | *Example:* 12 months, configurable from 6 to 36 months |
| How to read | *Example:* Field dictionary in annex B |

## 9. Deployer checklist

<!-- Guidance: A short list the deployer can copy into its own record (ai-data/ai-act-deployer-obligations). -->

- [ ] Intended purpose matches your use (section 4.1)
- [ ] Oversight staff named, trained and given authority (section 6)
- [ ] Input data relevant and representative for your vacancies (section 4.6)
- [ ] Monitoring set up for the groups in section 4.5 and those without data
- [ ] Log retention set to at least six months (section 8)
- [ ] Workers and applicants informed (Article 26(7) and 26(11))
- [ ] DPIA and, where required, FRIA use this document as input
- [ ] Contact for risk and incident reports saved (section 3)

## 10. Glossary and references

<!-- Guidance: Define every metric and term used above, and list official sources with the date checked. -->

| Term | Meaning |
|---|---|
| Recall | Share of truly relevant cases the system finds |
| Precision | Share of cases the system selects that are truly relevant |
| False positive rate | Share of not relevant cases the system wrongly selects |
| Deployer | The organisation using the system under its authority |
| Substantial modification | A change not foreseen in the initial conformity assessment that affects compliance or the intended purpose |

References (check the current consolidated text):

- Regulation (EU) 2024/1689 (AI Act), Articles 12, 13, 14, 15, 26, 86, 113 and Annex IV: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), OJ L 24 July 2026: http://data.europa.eu/eli/reg/2026/1744/oj
- Related templates: ai-data/ai-act-technical-documentation, ai-data/human-oversight-design, ai-data/model-card, ai-data/ai-act-deployer-obligations, ai-data/ai-act-risk-management-system, ai-data/ai-act-declaration-of-conformity

## Standard and licence note

Based on Regulation (EU) 2024/1689 (the Artificial Intelligence Act) as
amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI), Article
13 on transparency and provision of information to deployers, as
published in the Official Journal of the European Union; EU legislative
texts are free to reuse. The required content is summarised in original
wording and no text of the Regulation is reproduced. Check the
consolidated text on EUR-Lex for the binding wording, harmonised
standards and Commission guidance; under the amended Article 113 the
obligation applies from 2 December 2027 for Annex III systems and from
2 August 2028 for Annex I systems. All organisations, products and
figures in examples are fictional. This is a documentation format, not
legal advice. Template licence: MIT.