Annex IV §1

Annex IV §1 — General Description of the AI System (EU AI Act)

Annex IV §1 of Regulation (EU) 2024/1689 requires a general description of the AI system: intended purpose, provider, version, interactions, instructions for use, and UI. Structure and what regulators expect.

Source: Regulation (EU) 2024/1689 on EUR-Lex · Last published 2026-04-28 · Hand-edited 2026-04-28

What Annex IV §1 actually requires

Annex IV §1 of Regulation (EU) 2024/1689 lists the elements of the general description of the AI system in the technical documentation. It is the entry point of the Article 11 file — the section a market surveillance officer reads before any other.

The required elements (paraphrased; consult the consolidated text for the normative wording):

  • (a) The intended purpose, the name of the provider, the version of the system reflecting its relation to previous versions.
  • (b) How the AI system interacts with, or can be used to interact with, hardware or software, including with other AI systems, that is not part of the AI system itself, where applicable.
  • (c) The relevant versions of software or firmware and any requirement related to version updates.
  • (d) The description of all the forms in which the AI system is placed on the market or put into service (e.g., embedded software package, downloadable, API).
  • (e) The description of the hardware on which the AI system is intended to run.
  • (f) Where the AI system is a component of products, photographs or illustrations showing the external features, marking and internal layout of those products.
  • (g) A basic description of the user interface provided to the deployer.
  • (h) Instructions for use for the deployer and a basic description of the user interface provided to the deployer, where applicable.

§1 is short on text and long on consequence. Most of what a regulator forms an opinion of — the seriousness of the provider, the precision of the documentation, the credibility of the rest of the file — comes from §1.

Who is covered

Annex IV §1 is a provider obligation under Article 11. Deployers promoted to provider under Article 25 inherit it for the modified variant.

For systems integrating a GPAI model under Article 53, the integrating provider must describe the GPAI integration in §1(b) and reference the GPAI provider's Annex XI documentation.

What to write

Intended purpose — §1(a)

The most important sentence in the file. Regulators read it twice. It must:

  • Name the use case precisely. Not "automated decision support." Specify: "real-time scoring of consumer-loan applications between PLN 5,000 and PLN 80,000 in retail banking, returning approve/decline/human-review."
  • Exclude use cases that are out of scope. Excluded uses are part of the intended purpose definition under Article 3(12).
  • Be consistent across the technical file, the Article 13 instructions for use, and the EU Database registration entry under Article 49.

A good intended-purpose statement:

"DriverScore v2.4 is a supervised-learning classifier that ranks long-haul drivers on a 0–100 safety score using telematics features (harsh braking events per 100 km, speed-variance, fatigue flags from electronic logging device data). Intended purpose: internal shift allocation and voluntary safety coaching within Rondom Logistiek B.V. and its Group entities. Excluded uses: dismissal decisions, contractual penalty calculation, insurance-premium pricing, and any cross-employer benchmarking."

The sentence excluding dismissal, penalty, and insurance pricing is what makes the intended purpose defensible — it limits the scope of foreseeable harm and aligns with the Article 9 risk register.

Versioning — §1(a) + §1(c)

State the version of this file (v0.1, v1.2 …) and the version of the system it documents. Include the relation to previous versions: what changed, when, why. This connects to Annex IV §5 (lifecycle changes).

Interactions — §1(b)

Document upstream and downstream systems. Examples:

  • "Receives input from the Loan Origination System (LOS) v8.2 via REST API; returns score to LOS for routing."
  • "Uses GPAI model GPT-4-class via [provider]'s API for text-explanation generation; the GPAI provider's Annex XI documentation is referenced under file ID GPAI-EXPL-2026-01."
  • "Outputs are not consumed by any other AI system."

Forms — §1(d) and §1(e)

How does the system reach the deployer — embedded software, SaaS API, downloadable package, on-premise installer? What hardware is required, what hardware is optional? Specify versions, OS, RAM, GPU class.

Instructions for use — §1(h)

Annex IV §1(h) mirrors Article 13. The instructions for use must include the system's characteristics, capabilities, limitations of performance, and other content per Article 13(3). Annex IV §1 either includes the instructions verbatim or references them by stable URL or file ID.

A worked example

For a French legal-tech vendor's contract-analysis model:

§1(a) — "ContractScan v3.1, provider: LegalTech FR SAS, version 3.1.0 (released 2026-03-15). Replaces v3.0 of 2026-01-22 (changes: language coverage extended from FR/EN to FR/EN/DE/ES; see Annex IV §5). Intended purpose: clause extraction and risk flagging for B2B commercial contracts in French, English, German and Spanish, deployed by EU law firms. Excluded uses: contract drafting, M&A red-line review, employment-law contracts, and any contract subject to consumer-protection law where Article 22 GDPR Article 22 applies. Output is recommendation-only; final legal opinions are out of scope and require human lawyer review."

>

§1(b) — "ContractScan integrates with iManage, NetDocuments and SharePoint via OAuth2; receives PDF or DOCX inputs; returns a JSON manifest of detected clauses with risk levels. Uses an internal fine-tuned legal-domain language model (not a GPAI model under Article 53; full training pipeline documented in §2 of this file)."

>

§1(c) — "v3.1.0 firmware. Updates released quarterly under release notes RN-3.1.x. Deployers receive version-update notifications under Article 13(3)(b) at least 14 days before deployment."

>

§1(d) — "Placed on the market as a SaaS API. No on-premise variant. EU data residency: Frankfurt and Paris regions only."

>

§1(e) — "Hosted; no deployer hardware requirement beyond a current evergreen browser for the management UI."

>

§1(f) — "Not applicable; the system is not a component of a physical product."

>

§1(g) — "Web management UI for deployer-side overseers; review queue, override controls, audit log; documented in Annex IV §3."

>

§1(h) — "Instructions for use distributed as PDF version 3.1-IFU dated 2026-03-15; included as Appendix A of this file."

The full §1 is two to four pages, dense but specific.

What regulators look at first

  1. Whether the intended purpose excludes high-risk-adjacent uses. A vague intended purpose with no exclusions is the single most common Annex IV §1 weakness.
  2. Whether the version reference matches the EU Database under Article 49. Mismatched versions are an immediate red flag.
  3. Whether interactions are honestly listed. Hidden upstream dependencies are the kind of thing that surfaces during a Article 79 incident investigation.
  4. Whether the instructions-for-use reference is current. A reference to an outdated IFU is a documentation-currency failure.

Inline crosswalk to ISO 42001 and NIST AI RMF

  • ISO/IEC 42001:2023 Clause 7.5 — Documented information.
  • ISO/IEC 42001:2023 Annex A.6.2 — AI system life cycle documentation.
  • NIST AI RMF MAP 4.1 — Documentation includes purpose, intended use, users, and limitations.

What to do

  1. Write the intended purpose first; everything else flows from it.
  2. List excluded uses explicitly. They limit scope of foreseeable harm.
  3. Lock version numbers across §1, §5, the EU Database registration, and the Article 47 declaration of conformity.
  4. Reference the Article 13 IFU by stable identifier; do not duplicate the full IFU in §1 unless it is short.
  5. Cross-reference §5 lifecycle changes for the change history.

Common mistakes

  1. Marketing-prose intended purpose. Regulators don't care that the system "revolutionises" anything.
  2. Version drift. §1 says v3.1, EU Database says v3.0, Article 47 declaration says v3.1.1 — non-conformity.
  3. Missing exclusion list. A high-risk system with no excluded uses signals an unbounded risk surface.
  4. Vague hardware specification. Regulators in safety-relevant Annex III categories will ask.
  5. Stale instructions-for-use reference. Update IFU references with every material system change.

Generate Article 11 documentation with AI

Governancer Pro includes an LLM-assisted Article 11 drafting tool that produces a v0.1 Annex IV §1 from a structured intake — system name, vendor, intended purpose, excluded uses, integrations. You fill in the system-specific details and ship.


Disclaimer. This page is a reference summary of EU AI Act Annex IV §1. It is not legal advice. Verify with qualified counsel before relying on it for compliance decisions. Reg text from Regulation (EU) 2024/1689.

Reference checklist

From the Governancer 30-item EU AI Act checklist. Each item joins to the ISO 42001 + NIST AI RMF crosswalk table below.

  • Article 11 · Starter tier · critical

    Draft technical documentation (system purpose, design, risk)

    Required for all high-risk AI systems before market placement. Our template covers the eight mandatory sections in one .docx.

ISO 42001 + NIST AI RMF crosswalk

Pulled live from the Governancer crosswalk module. Mapping reference; not a substitute for ISO 42001 certification audit or NIST AI RMF self-attestation.

ISO/IEC 42001:2023

Checklist itemISO 42001 controlRationale
art11-tech-docsISO/IEC 42001:2023 Clause 7.5 — Documented informationArticle 11 technical file is the AIMS-required documented information evidencing AI system design, purpose, and risk decisions.
art11-tech-docsISO/IEC 42001:2023 Annex A.6.2 — AI system life cycle documentationAnnex A.6.2 requires lifecycle documentation; the Article 11 technical file is its EU AI Act manifestation.

NIST AI RMF 1.0

Checklist itemNIST AI RMF subcategoryRationale
art11-tech-docsNIST AI RMF MAP 4.1 — Approaches and metrics for measurement of AI risks are followed; documentation includes purpose, intended use, users, and limitationsArticle 11 technical file documents purpose, design and limitations — the system-context output expected by MAP 4.1.
art11-tech-docsNIST AI RMF GOVERN 1.4 — The risk management process is documented and is regularly reviewedMaintaining a living technical file is the documented and regularly reviewed risk-management evidence under GOVERN 1.4.

Pro feature

Generate Article 11 with AI

LLM-assisted draft of all eight Annex IV sections, pre-filled from your system intake. 5 drafts/month on Pro.

Pro template

Download FRIA template

15-page Article 27 FRIA template (.docx) with the six elements pre-structured and a worked example.

Get the 30-item EU AI Act compliance checklist

Free PDF. No spam. Maps every Article and Annex IV section we ship to a ready-to-action checklist row.


Reference; not legal advice. Verify with qualified counsel before relying on it for compliance decisions. Reg text quoted from the Official Journal version of Regulation (EU) 2024/1689. Published by Agonist Development AB.