This fourth part continues Part III on EU AI classification and accountability. The earlier parts establish market access, supply-chain responsibility and classification. The question here concerns the documents needed to implement those decisions: their contents, responsible authors, supporting evidence and maintenance. The analysis concerns ordinary commercial development and deployment under Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744. Each requirement depends on the cited duty applying to the identified system, model or use.
Summary
- A high-risk provider's written quality management system, system technical documentation and risk-management records perform different functions. An organisation may connect them through one controlled document system, provided every applicable requirement remains covered. A general AI policy cannot establish that a particular system passed its required tests. (AI Act, Articles 9, 11 and 17; Annex IV.)
- A usable risk assessment connects each relevant hazard to affected people, controls, test results and residual-risk acceptance. Article 9 requires lifecycle review. Annex IV requires dated test reports signed by the responsible persons. (Article 9(2)–(9); Annex IV, points 2(g) and 5.)
- Deployers need evidence of their own operating arrangements. Where Article 27 applies, the fundamental rights impact assessment must address the actual deployment. Relevant data protection impact assessment (DPIA) sections may be reused, but any remaining Article 27 requirements still need an answer. (Articles 26 and 27(1)–(5).)
- Retention depends on the record and the responsible actor. The provider's Article 18 documents have a ten-year period. Controlled operating logs generally have a minimum six-month period, subject to the applicable legal exceptions. Neither period establishes a universal rule for all AI records. (Articles 18(1), 19(1) and 26(6).)
- Simplification permits proportionate documentation and specified forms; it preserves the required protection. An internal AI governance policy can allocate approval, monitoring and escalation responsibilities. Its chosen structure is distinct from the Act's prescribed documents and conditions. (Articles 11(1), 17(1)–(4) and 63(1).)
The document register and the applicable duty
A document register should carry forward the conclusions reached under the earlier parts. Each entry should identify the legal entity, system or model version, intended use, applicable duty and responsible owner. It should also record the due date, approval status, storage location and update trigger. These fields are a recommended way to organise compliance evidence; the Act does not prescribe this universal register. (Articles 11, 17(1)(k)–(m) and 53(1); Annex IV, point 1(a)–(c).)
The schedule must preserve the distinction between an enacted requirement and one already applicable. Article 113(c) postpones Chapter III, Sections 1–3, except Article 6(5). The dates are 2 December 2027 for Annex III systems and 2 August 2028 for Article 6(1) systems. Article 111 contains separate transitional rules. Provisions outside those sections require their own examination; a single future date for the entire document register would be unreliable. (Articles 111 and 113(c).)
An ordinary business should first distinguish mandatory deliverables from voluntary controls. Articles 9, 11 and 17 do not require the full high-risk provider package for every AI use. Article 95(1) permits voluntary application of the specified high-risk requirements to other systems. A policy or training record may support applicable literacy measures without becoming an Annex IV technical file. (Articles 4(1), 9(1), 11(1), 17(1) and 95(1).)
One workable structure connects the organisation's written procedures, each system's technical file and evidence of each deployment. A company performing several statutory roles must cover each applicable duty, but it need not duplicate identical material without purpose. Where sector legislation applies, Articles 8(2), 9(10), 11(2) and 17(3) expressly permit or require specified integration.
The risk assessment and its supporting evidence
The provider needs a documented process capable of explaining risk decisions throughout the system's life. Article 9(2) requires identification, evaluation, treatment and review of the specified risks. A static questionnaire completed before launch cannot, by itself, evidence later reassessment after new operating information arrives. Annex IV, point 5, also requires a detailed description of the risk management system. (Article 9(1)–(2).)
A practical assessment can use a separate entry for each hazard. The entry should state the relevant function, affected people, intended-use conditions and foreseeable misuse. It should identify the potential harm, the evidence used to assess likelihood and severity, and the limits of that evidence. The provider should connect each selected control to a named implementation task and a test result. These are recommended fields for demonstrating the operations required by Article 9(2), (5), (6) and (8).
Residual-risk acceptance requires an explanation of the remaining risk for each hazard and for the system overall. A colour rating alone cannot explain that judgment. The file should record the acceptance criteria, the results against them and the person authorised internally to approve the decision. Article 9(5) requires acceptable residual risk; it does not prescribe one numerical scoring formula or a particular committee. Management responsibilities must be allocated under Article 17(1)(m).
The provider must assess whether warnings are sufficient when design changes can reduce the risk. Article 9(5) requires technically feasible elimination or reduction through design and development, with appropriate controls for remaining risks. Providers must also supply the Article 13 information and, where appropriate, training to deployers. The file should explain why the selected measures address the identified hazard. An instruction telling operators to check outputs needs evidence that the proposed review can detect the relevant error. (Article 9(5)–(8); Annex IV, points 2(e), 2(g) and 3.)
The assessment should explain exclusions by reference to Article 9(3)'s limit concerning risks reducible through design, development or adequate technical information. Where children or other vulnerable groups require consideration under Article 9(9), the provider should preserve the relevant findings. Recording those decisions allows later reviews to examine whether new operating information changes the assessment. (Article 9(2)(c), (3) and (9).)
The technical file and test reports
The technical file must demonstrate the identified system's compliance before market placement or putting into service and remain current. Annex IV specifies its minimum contents as applicable to that system. An index following those headings is therefore a useful starting structure. The provider should connect each entry to the relevant document version and supporting record. (Article 11(1); Annex IV.)
The file needs the system description, intended purpose, version history, interfaces and relevant hardware or software dependencies. Development records must explain design choices, assumptions, architecture and use of third-party systems or tools. Where relevant, they must describe training methods and data provenance, selection and preparation. The provider also needs the required oversight assessment and cybersecurity measures. A product brochure cannot ordinarily supply that development evidence. (Annex IV, points 1 and 2(a)–(e), (h).)
The provider should preserve the records supporting each test result. Annex IV, point 2(g), requires information about validation methods, datasets and their characteristics, relevant metrics and potentially discriminatory effects. It expressly includes test logs and all test reports dated and signed by the responsible persons. Point 4 requires an explanation of why the performance metrics fit the system. Article 9(8) requires the metrics and probabilistic thresholds to be defined before the relevant testing.
Assume a hypothetical provider has already established that its recruitment-ranking system is high-risk. A statement that the model performs accurately leaves the system's own evaluation unanswered. Its evidence should connect the tested version and applicant population to the ranking function, error measures and oversight arrangements. Results from an upstream model can contribute, but the provider must show how they support the complete application's required assessment. (Annex IV, points 2(a), 2(g), 3 and 4.)
The same file must include the risk-management description, relevant lifecycle changes, standards or alternative technical solutions, the declaration of conformity and the monitoring plan. Where the provider relies on predetermined learning-related changes, its record should identify their coverage in the initial assessment. Preserve the relevant version and the later change record together. (Article 43(4); Annex IV, points 2(f) and 5–9.)
The written quality management system
Article 17 requires written policies, procedures and instructions covering how the provider performs and controls its work. The organisation should allocate each required subject to an existing procedure or a new one. The chosen document titles are optional; coverage of Article 17(1) is mandatory when that provision applies.
The required subjects include the compliance strategy and modification process; design control; development and quality assurance; and examination, testing and validation procedures, including their frequency. The provider must also address technical specifications, data management and the Article 9 risk process. A policy that merely commits the company to responsible AI leaves those procedures unspecified. (Article 17(1)(a)–(g).)
Further procedures must cover post-market monitoring, serious-incident reporting, communications, record keeping and resource management. Management and staff responsibilities must extend across all these subjects. A useful procedure names the decision-maker, required evidence, approval criteria and escalation route. Those operational details are an implementation recommendation grounded in the written-procedure and accountability requirements. (Article 17(1)(h)–(m).)
Existing sector procedures can satisfy part of this work under Article 17(3). Article 17(4) concerns financial institutions subject to EU financial-services requirements on internal governance, arrangements or processes. Compliance with the relevant rules is deemed to fulfil the quality-management obligation, except for risk management, post-market monitoring and serious-incident procedures. The institution should record which existing procedure covers each duty and which AI-specific additions remain necessary.
Conformity and release records
The release file should identify the assessment route established under the earlier parts and preserve evidence of its completion. Under Annex VI, the provider verifies its quality management system and examines the technical documentation. It must also check that design, development and post-market monitoring are consistent with that documentation. An internal approval record should identify the reviewed evidence and the resulting decision. This is a recommended record of the work required by Annex VI, points 2–4.
The EU declaration of conformity has prescribed contents. Annex V requires identification of the system and the provider or its authorised representative, as applicable. It also requires the responsibility and conformity statements, and references to relevant harmonised standards used or other common specifications. Further details concern the notified body and certificate where applicable, and the place, date and signatory. For systems involving personal data, point 5 requires the specified data-protection compliance statement. Preparing that declaration therefore requires examination of the applicable data-protection rules. (Article 47(1)–(3); Annex V, points 1–8.)
A provider should connect the signed declaration, any required certificate and registration entry to the assessed system version. The technical file must include a copy of the declaration. Where other Union harmonisation legislation also requires an EU declaration for that system, Article 47(3) requires a single declaration covering the applicable legislation. Consolidation must preserve the information needed under each act. (Article 47(1)–(3); Annex IV, point 8.)
Data records and bias testing
Data documentation must explain the datasets' suitability for the intended function. The relevant records cover collection and origin, preparation, assumptions, availability and suitability, bias examination and correction, and identified gaps or shortcomings. The application of particular requirements depends on whether the system uses model training or only testing datasets. (Article 10(1)–(4), (6); Annex IV, point 2(d), (g).)
The provider should connect a dataset description to the version used in a particular test. A record of the source alone cannot explain later filtering, exclusions or corrections. Documenting those operations helps establish whether the reported results concern the same data and configuration as the approved release. This is an evidentiary recommendation derived from Article 10(2) and Annex IV, point 2(d), (g).
Special-category data used under Article 4a requires additional records. The processing record must explain strict necessity for bias detection and correction and why other data could not achieve the objective. Access must be controlled and documented. The operator should also retain evidence of the required reuse restrictions and security measures. Data must not be transferred or otherwise accessed by other parties. Deletion is required once the bias is corrected or the retention period ends, whichever occurs first. Article 4a does not prescribe a document called a deletion certificate. (Article 4a(1)(a)–(f).)
That permission remains conditional. Article 4a(2) extends it to specified other providers and deployers only under its harm-related conditions and paragraph 1 safeguards. It creates no independent duty to conduct bias detection and correction. A completed necessity form cannot authorise processing that fails those conditions. (Article 4a(2).)
Instructions and deployment records
The provider's instructions must translate the system's capabilities and limitations into usable operating information. Article 13(3) specifies the content, including intended purpose, performance information, relevant risks, input specifications where appropriate, oversight measures and maintenance requirements. Where relevant, the instructions must explain mechanisms for collecting, storing and interpreting logs. The provider should verify consistency between these instructions and its tested configuration. (Article 13(3); Annex IV, points 1(h), 2(g) and 3.)
A deployer should maintain an operating record linked to the received instructions and approved configuration. It can identify the operating owner, authorised users and oversight personnel, including their competence, training, authority and support. Relevant input checks and escalation arrangements should also be recorded. Article 26 imposes the underlying obligations; it does not prescribe a universal deployment-file format. (Article 26(1)–(5).)
The deployer should retain the required logs and evidence of applicable notices, registration and impact assessments. A supplier's test report does not establish that the customer appointed oversight personnel or informed affected workers. The file should identify the action, its date and the supporting record without assuming that every notice or assessment applies to every deployment. (Article 26(2), (6)–(9), (11).)
The fundamental rights impact assessment
Where the Article 27 trigger established in Part III applies, the deployer needs a deployment-specific assessment before first use. Its contents must cover the process using AI, intended period and frequency of use, and affected categories of people. The assessment must also address relevant risks of harm, oversight implementation and measures if those risks materialise. Those measures must include the required internal arrangements and complaint mechanisms. A provider's general risk report may inform the assessment, but it cannot supply deployment facts that it does not address. (Article 27(1)(a)–(f), (2).)
Assume a hypothetical lender deploys a covered creditworthiness system. The assessment should describe the lending process and affected applicants, then connect likely harms to the proposed safeguards. It should identify who can review a disputed result and how the complaint procedure operates. These are applications of the statutory content requirements, not claims about any lender's actual practices. The Article 9 provider assessment and the Article 27 deployment assessment can share evidence while answering their respective questions. (Articles 9 and 27(1).)
Article 27(2) permits reliance in similar cases on previous assessments, including existing provider assessments. The deployer must still address changed or outdated elements. A reuse record should identify the earlier assessment, the circumstances supporting reliance and the differences requiring an update.
Amended Article 27(4) permits cross-references to relevant data protection impact assessment (DPIA) sections or incorporation of those sections. A combined file should map each Article 27 requirement to the section that answers it. Any Article 27 requirement not already met by the DPIA needs additional assessment. The underlying GDPR duty depends on Article 35(1) of Regulation (EU) 2016/679; AI Act classification alone does not settle that separate trigger. (AI Act, Articles 26(9), 27(4)–(5).)
The deployer must notify the market surveillance authority of the results with the completed prescribed template. Under Article 27(3), deployers may be exempt from notification in the case referred to in Article 46(1). Article 27 does not impose a general duty to publish the whole assessment. Separate registration rules require particular public-sector deployers to submit specified summaries where applicable. The recommended register should distinguish notification, database registration and public disclosure. (Articles 27(3), 49(3)–(4) and 71(4); Annex VIII, Section C, points 4–5.)
Monitoring and incident records
The provider's post-market monitoring plan must form part of the technical documentation. It should identify the information to collect, its sources, review responsibilities and criteria for investigating or correcting a problem. Those are recommended implementation fields. Article 72 requires active, systematic collection, documentation and analysis of relevant performance information throughout the system's lifetime. Relevant interactions with other AI systems also require analysis. (Article 72(1)–(3); Annex IV, point 9.)
The plan should connect complaints, operating errors and other relevant findings to the risk assessment and change process. The provider must be able to show how a newly observed problem affected its earlier assumptions or controls. Recording an incident without considering its risk consequences would leave the review required by Article 9(2)(c) unanswered. Relevant sector monitoring systems may incorporate the AI elements under Article 72(4), subject to its conditions.
An incident procedure should preserve awareness times, the known facts, the causal assessment, escalation, reports and corrective actions. The reporting periods depend on the statutory incident category, so the procedure needs a route for urgent cases. Article 73(5) permits an incomplete initial report where necessary for timely reporting. The provider should preserve the basis for that initial report and the information supplied later. (Article 73(2)–(6).)
Incident investigation also affects evidence preservation. Before altering the system during an investigation in a way that may affect later evaluation of the cause, the provider must inform the competent authorities. A practical procedure should record the affected version and proposed changes before remediation obscures that evidence. The notification obligation follows from Article 73(6); the chosen preservation method depends on the system.
Model documentation and its recipients
General-purpose model providers need a document structure suited to Chapter V. The Article 53(1)(a) file contains the Annex XI material for competent authorities. The Article 53(1)(b) information serves downstream system providers and must include Annex XII's specified contents. These recipient groups do not have identical statutory entitlements. The conditional open-source exception in Article 53(2) must be applied before treating either document duty as mandatory.
The model file includes development, training and evaluation information, with the applicable technical and resource details. The downstream information must explain integration requirements and include the specified model, input, output and data information. A provider should track which document version accompanied which model release. That is a practical response to the updating duties and release information required by Article 53(1)(a)–(b), Annex XI and Annex XII.
The document register should separately identify the copyright policy and public training-content summary required by Article 53(1)(c)–(d). Systemic-risk models require additional evaluation and adversarial-testing records, risk controls, and documentation and reporting of serious incidents. These belong to the model provider's obligations under Article 55 and Annex XI, Section 2. They do not establish the conformity of a separately developed downstream application. (Article 11(1); Annex IV.)
Retention and controlled access
The retention schedule should specify the document category, responsible legal entity, retention trigger and permitted access. Article 18(1) covers the provider's technical and quality-management documentation, applicable notified-body records and the declaration of conformity. The period ends ten years after market placement or putting into service. A supplier contract should preserve the practical access needed to meet that duty when another company stores the records. (Articles 18(1) and 25(4).)
Operating logs have a different rule. Articles 19(1) and 26(6) concern automatically generated logs under the respective provider's or deployer's control. The period must fit the intended purpose and generally last at least six months, unless applicable EU or national law provides otherwise. The qualification expressly includes personal-data law. Applying the ten-year technical-file period to every raw log would disregard that distinction.
Other actors have specified retention duties. Article 23(5) requires an importer to preserve the declaration and instructions, plus any applicable notified-body certificate. The period is ten years after the system is placed on the market or put into service. Under Article 54(3)(b), a covered model provider's authorised representative must retain an Annex XI copy for ten years after model market placement. These provisions need separate schedule entries; Article 53 does not itself impose Article 18's period on every model-provider record.
The document system should preserve the evidence supporting earlier releases while keeping current operating instructions identifiable. Article 11 requires updated technical documentation, and Annex IV requires relevant lifecycle changes. The Act does not prescribe one version-control product. The provider must be able to retrieve the records required by Article 18 and respond to competent-authority requests under Article 21.
An AI governance policy example
An organisation can adopt an internal policy that assigns approvals and connects the required records. The following clauses illustrate a possible policy structure. They are proposed internal rules, not an official template or a statement that the Act requires these particular job titles.
1. Each business owner must record a proposed AI use before procurement, development or deployment. The record must identify the intended function, responsible entity, system version and proposed users. The compliance lead must identify the applicable duties and required approvals.
2. The technical owner must supply the evidence required for the approved use. Where high-risk provider duties apply, this includes the applicable risk assessment, technical documentation, test records and operating instructions. Release approval must identify the reviewed versions and the person accepting any residual risk.
3. The deployment owner must assign oversight personnel with the required authority and support. Staff must receive instruction relevant to their tasks. The owner must confirm completion of any required impact assessment, notices and registration before use.
4. Proposed changes to purpose, inputs, models, permissions or operating conditions must be assessed before activation. The responsible owner must identify the required retesting, document updates and approvals. Incident reports must follow the applicable escalation procedure and preserve the information needed for investigation.
5. Each record must have an owner, current version and retention rule. The document owner must maintain access for authorised personnel and preserve required earlier records. Periodic reviews must also address new operating information and changes affecting the approved use.
These clauses organise decisions arising under Articles 9, 11, 17 and 26. Supporting procedures must specify how staff perform the actual work. For literacy evidence, a training record can identify the roles covered, systems discussed, date, materials and follow-up instruction. Those fields connect the measures taken to staff knowledge, experience and use conditions under Article 4(1).
Proportionate documentation and template limits
The provider may scale its quality-management implementation to its size while preserving the required rigour and protection. Micro, small and medium-sized enterprises (SMEs) and small mid-cap enterprises (SMCs) may use Article 11(1)'s simplified technical-documentation route under its conditions. Choosing that route requires the Commission form specified there. (Articles 11(1) and 17(2).)
Article 63(1) permits certain independent SMEs to simplify elements of quality management. Its eligibility condition excludes partner or linked enterprises within the specified definition. Small mid-cap status alone does not establish eligibility for that separate concession. The provider should record the basis for each concession and the requirements that remain applicable. (Articles 3(14a)–(14b), 11(1), 17(2) and 63(1).)
The post-market monitoring plan has a different template rule. Amended Article 72(3) requires Commission guidance, including a template, by 2 September 2027. Recital 41 of Regulation (EU) 2026/1744 describes that template as voluntary. The provider's statutory duty to establish and document the monitoring system remains governed by Article 72; the deadline for guidance does not itself determine that duty's application date.
Missing required documents can have consequences even before a dispute about the system's performance is resolved. Article 83 requires correction of specified formal defects, including unavailable technical documentation and an absent or incorrectly drawn-up declaration of conformity. If the defect persists, the competent authority must take appropriate and proportionate measures to restrict or prohibit supply, or require recall or withdrawal. A document index should therefore expose missing evidence and unresolved approvals before release. (Article 83(1)–(2).)
