EU AI Act templates: Annex IV outline, FRIA outline, protocol skeleton and evidence pack index
Four outlines are published on this page: an Annex IV technical documentation outline under Art. 11, a fundamental rights impact assessment outline under Art. 27 with its sections ordered by the impact assessment process of ISO/IEC 42005:2025Published, the test protocol skeleton that every protocol on the methodology pages follows, and an evidence pack index. Each outline renders in full below with its version badge and a verified-on stamp for the regulation entry In force the structure was checked against, and each outline downloads as Markdown built in the browser.
How to use an outline
An outline supplies the structure of a file and none of its content. Every item under a heading is a prompt for the provider's or the deployer's own material: the Annex IV outline lists the items of each Annex IV section with the paragraph reference, and the FRIA outline lists the six elements of Art. 27(1) with the paragraph reference. The obligation page linked on each outline, Art. 11 with Annex IV for the technical documentation outline and Art. 27 for the impact assessment outline, states for every element whether a test, a document or a process answers it, and names the protocol that produces the record, PR-11-DOC v1.0 and PR-27-FRIA v1.0 respectively. The protocol skeleton is the structure of every protocol page under the methodology index, and the evidence pack index takes its row ids from the traceability matrix tool. The verified-on stamp on each outline names the regulation entry the structure was checked against; a change to Annex IV under Art. 11(3) or to the Art. 27(5) template would be recorded against that entry in the regulation changelog.
Annex IV technical documentation outline
The nine sections of Annex IV as headings, each with the items the section lists and the obligation page that maps them to a test, a document or a process. The outline is a structure, not a completed file; every item is a prompt for the provider's own content.
- Obligations
- Art. 11
- Protocols
- PR-11-DOC v1.0
1. General description of the AI system
- Intended purpose, provider name, version and its relation to previous versions (Annex IV 1(a))
- Interaction with hardware or software, including other AI systems, where applicable (1(b))
- Versions of relevant software or firmware and any requirement related to version updates (1(c))
- Forms in which the system is placed on the market or put into service (1(d))
- Description of the hardware on which the system is intended to run (1(e))
- Where the system is a component of a product: photographs or illustrations of the external features, marking and internal layout (1(f))
- Basic description of the user interface provided to the deployer (1(g))
- Instructions for use for the deployer, and a basic description of the user interface where applicable (1(h))
2. Detailed description of the elements and of the development process
- Methods and steps of development, including pre-trained systems or tools from third parties and how they were used, integrated or modified (2(a))
- Design specifications: general logic, algorithms, key design choices with their rationale and assumptions, classification choices, optimisation targets and trade-offs (2(b))
- System architecture: how software components build on or feed into each other; computational resources for development, training, testing and validation (2(c))
- Data requirements: datasheets describing training methodologies and techniques, the training data sets, their provenance, scope and main characteristics, how the data was obtained and selected, labelling procedures and data cleaning (2(d))
- Assessment of the human oversight measures needed under Art. 14, including the technical measures that help deployers interpret the output (2(e))
- Pre-determined changes to the system and its performance, and the technical solutions that keep the system in continuous compliance (2(f))
- Validation and testing procedures: data used, metrics for accuracy, robustness and compliance with the other Section 2 requirements, discriminatory impacts, test logs and dated and signed test reports (2(g))
- Cybersecurity measures put in place (2(h))
3. Monitoring, functioning and control
- Capabilities and limitations in performance, including degrees of accuracy for specific persons or groups and the overall expected level of accuracy in relation to the intended purpose
- Foreseeable unintended outcomes and sources of risk to health, safety and fundamental rights, and to equality and non-discrimination, in the light of the intended purpose
- Human oversight measures under Art. 14, including the technical measures that help deployers interpret the output
- Specifications on input data, as appropriate
4. Appropriateness of the performance metrics
- Description of why the metrics chosen under section 2(g) are appropriate for the specific system
5. Risk management system
- Detailed description of the risk management system in accordance with Art. 9
6. Changes through the lifecycle
- Description of relevant changes made by the provider to the system through its lifecycle
7. Standards and specifications applied
- List of the harmonised standards applied in full or in part, with the references published in the Official Journal; where none is applied, a detailed description of the solutions adopted to meet Chapter III Section 2, including the other relevant standards and technical specifications applied
8. EU declaration of conformity
- Copy of the EU declaration of conformity referred to in Art. 47
9. Post-market monitoring
- Detailed description of the system in place to evaluate performance in the post-market phase in accordance with Art. 72, including the post-market monitoring plan referred to in Art. 72(3)
Fundamental rights impact assessment outline
The six elements of Art. 27(1) as headings, in an order that follows the impact assessment process of ISO/IEC 42005:2025: context and scope, interested parties, impacts, measures, monitoring. The AI Office template that Art. 27(5) provides for takes precedence once the deployer uses it; this outline records the same elements so the content transfers.
- Obligations
- Art. 27
- Protocols
- PR-27-FRIA v1.0
- Standards
ISO/IEC 42005:2025Published
A. Scope and context
- The high-risk AI system, its provider, its version and the provider's Art. 13 information taken as input
- The deployer's processes in which the system will be used, in line with its intended purpose (Art. 27(1)(a))
- The period of time and the frequency of intended use (Art. 27(1)(b))
- The assessment's relation to any data protection impact assessment under Art. 35 of Regulation (EU) 2016/679, which Art. 27(4) allows the deployer to cross-reference or include in part
B. Interested parties
- Categories of natural persons and groups likely to be affected by use in the specific context (Art. 27(1)(c))
- Persons and groups the deployer consulted, and how
C. Potential impacts
- Specific risks of harm likely to affect each category identified under B, taking into account the provider's information under Art. 13 (Art. 27(1)(d))
- For each risk: the right affected, the mechanism of harm, the likelihood and severity as the deployer assesses them, and the evidence behind the assessment
D. Measures
- Human oversight measures implemented, according to the instructions for use (Art. 27(1)(e))
- Measures to be taken if the risks materialise, including internal governance arrangements and complaint mechanisms (Art. 27(1)(f))
E. Monitoring and review
- Trigger for updating the assessment when any element changes or is no longer up to date (Art. 27(2))
- Notification to the market surveillance authority with the completed template (Art. 27(3)), and the exemptions the deployer relies on
- Record of the review, with the version of the system and the version of this assessment
Test protocol skeleton
The structure of every protocol on the methodology pages: scope, articles covered, inputs, numbered steps each with a citation and a record, thresholds and criteria, outputs, limitations, sources, revision history. A step that no provision or standard covers is marked as the organisation's own procedure in its citation field.
- Protocols
- PR-CLS v1.0PR-50-MARK v1.0PR-15-ROB v1.0PR-10-BIAS v1.0PR-12-LOG v1.0PR-14-OVR v1.0PR-11-DOC v1.0PR-43-MOCK v1.0PR-27-FRIA v1.0PR-17-QMS v1.0
Identification
- Protocol id and name
- Version and the regulation entry it was verified against
- Derivation line: the standards and guidelines it is built from, each with its stage
Scope
- What is tested, at which fixed version, in which environment
- Articles and paragraphs covered
- What is out of scope
Inputs
- Model or system access, with the version hash
- Data sets with provenance and hashes
- Documents the provider supplies (declarations, risk management file, instructions for use)
Steps
- Step number
- Action
- Citation: the provision of Regulation (EU) 2024/1689 or the clause of a standard the step derives from, with the standard's stage
- Record: the artifact the step writes
Thresholds and criteria
- For each pass criterion: its source level in the six-level hierarchy, and the step that records the provider's justification where no published threshold exists
Outputs
- The reports and records the protocol produces, each mapped to the Annex IV section or the obligation element it serves
Limitations
- What the protocol does not show, and the re-test triggers that invalidate a result
Sources and revision history
- Every source with its URL
- One row per version with the regulation entry that dates it and the note on what changed
Evidence pack index
A manifest for the evidence pack that answers a market surveillance request under Art. 74 or a notified body's request under Annex VII: one row per artifact with the obligation element it answers, the test or protocol that produced it, its version and hash, and the role that owns it. Names of persons are not recorded; owners are roles.
- Obligations
- Art. 11Art. 9Art. 12Art. 15Art. 17
- Protocols
- PR-11-DOC v1.0PR-43-MOCK v1.0
Pack identification
- System name and version, provider, the classification record (Art. 6) and the conformity assessment route (Art. 43)
- Pack version and the date of the record that closes it
- Index of the traceability matrix rows the pack answers
Artifact rows
- Artifact id (matrix row id), title and file name
- Obligation element answered (article, paragraph, element)
- Producing test or protocol, with version
- Artifact version, hash and storage location
- Owning role (not a person)
- Status: final, superseded, withheld with reason
Cross-references
- Annex IV section each artifact serves
- Risk management file entries and post-market monitoring records that cite the artifact
- Instructions for use passages that state the declared levels the artifact measures
Gaps
- Obligation elements with no artifact, with the reason and the planned record
Nothing you enter is sent anywhere. This tool runs in your browser from data bundled at build.
What a template is not
An outline carries no presumption of conformity: a presumption under Art. 40 attaches only to a harmonised standard cited in the Official Journal of the European Union, and none is cited as of the anchor date. A completed outline is a file the provider or the deployer has written; the completed Annex IV set, the evidence pack and the FRIA record are deliverables of the technical documentation and evidence-pack preparation and FRIA facilitation services, whose limits are stated on what we cannot do, and each deliverable type is specified with a synthetic sample on the deliverables page. The FRIA outline records the same elements as the questionnaire template the AI Office develops under Art. 27(5); once a deployer uses the AI Office template, that template governs the notification under Art. 27(3). No outline on this page is a conformity assessment under Art. 43 or a classification record under Art. 6, and none replaces the consolidated text of Regulation (EU) 2024/1689 or the advice of counsel.
Questions
Is there an AI Act technical documentation template?
The Annex IV technical documentation outline on this page lists the nine sections of Annex IV as headings, each with the items the section names and the paragraph reference. Art. 11(1) requires the provider of a high-risk AI system to draw up the technical documentation before placing the system on the market and to keep it up to date. An SME, including a start-up, or an SMC may use the simplified form the Commission establishes under Art. 11(1). The outline downloads as Markdown built in the browser.
Where is a FRIA template?
The fundamental rights impact assessment outline on this page renders in full with its version badge and downloads as Markdown. The outline holds the six elements of Art. 27(1)(a) to (f) as headings under five sections: scope and context, interested parties, potential impacts, measures, and monitoring and review. Art. 27(5) provides for a questionnaire template developed by the AI Office; once a deployer uses that template, it governs the notification to the market surveillance authority under Art. 27(3), and the content of the outline transfers to it.
What does a fundamental rights impact assessment (FRIA) template contain?
Art. 27(1) names six elements: the deployer's processes in which the system is used, the period and frequency of use, the categories of natural persons and groups likely to be affected, the specific risks of harm to those categories, taking the provider's Art. 13 information into account, the human oversight measures implemented according to the instructions for use, and the measures to be taken if the risks materialise, including internal governance and complaint mechanisms. The outline orders the six elements by the process of ISO/IEC 42005:2025, a published international standard.
Is there an EU AI Act conformity assessment template?
No outline on this page is a conformity assessment. Art. 43 sets the assessment routes: internal control under Annex VI, or a notified body under Annex VII. The evidence pack index is the closest structure here: one row per artifact with the obligation element it answers, the protocol that produced it, its version and hash, and the owning role, built for a market surveillance request under Art. 74 or a notified body's request under Annex VII. AIAssuranceLabs does not perform conformity assessments where a notified body is required.
Is there an EU AI Act risk assessment template?
This page carries no risk management file outline. Art. 9(1) requires the provider of a high-risk AI system to establish, implement, document and maintain a risk management system; the Art. 9 obligation page names the assessor artifacts: a risk management file, a hazard register, a residual risk acceptance record per hazard, and the metrics and thresholds declared under Art. 9(8). Section 5 of the Annex IV outline holds the description of the risk management system, and the evidence pack index cross-references the risk management file entries per artifact.
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.