Describe your business, leave with a checklist you can assign

Each processing activity, including training or fine-tuning models on user data, must have a documented Art. 6 lawful basis; processing of Art. 9(1) special categories additionally requires an Art. 9(2) exception. Where consent is relied on, it must meet the Art. 4(11) and Art. 7 requirements of being freely given, specific, informed and unambiguous, withdrawable at any time and as easily as it was given. Where legitimate interests are relied on, a three-part balancing test must be performed and retained. Information to data subjects must cover all Art. 13 and 14 elements, and Art. 14(3) requires notice within a reasonable period and at the latest within one month where data was not obtained from the data subject.

Evidence: Lawful basis register organised by processing activity; Legitimate interests assessment (LIA) documents; Screenshots of consent capture interfaces and consent and withdrawal logs; Version history of the privacy notice and layered notices

GDPR Data Protection Impact Assessment (DPIA) — for AI training and inferenceData Card — datasheet for a training, validation or test dataset

On a personal data breach the controller must notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to natural persons’ rights and freedoms; a notification made later must be accompanied by reasons for the delay. The notification must at least describe the nature of the breach including the categories and approximate numbers of data subjects and records concerned, give the DPO or other contact point, describe the likely consequences, and describe measures taken or proposed. Information may be provided in phases. A processor must notify the controller without undue delay after becoming aware. Where the breach is likely to result in a high risk, the controller must also communicate it to the data subjects without undue delay in clear and plain language. The controller must document all breaches, their effects and the remedial action taken, so the authority can verify compliance.

Evidence: Breach response plan breaking the 72-hour clock into tasks with named owners; Breach register covering all incidents, including the reasoning where notification was not required; Notification filed with the supervisory authority and the acknowledgement; Communication text and delivery records for data subjects where applicable

AI incident and serious incident reporting record (register plus report drafts)Customer security and privacy questionnaire answer bank (grouped by CAIQ / CCM domains)

Transfers of personal data to a third country or international organisation are permitted only under Chapter V: an adequacy decision of the Commission (Art. 45); appropriate safeguards (Art. 46, including Commission-adopted standard data protection clauses, binding corporate rules, approved codes of conduct or certification mechanisms, together with enforceable data subject rights and effective remedies); or the Art. 49 derogations for specific situations. China is not covered by an EU adequacy decision, so the default route for Chinese AI companies is to execute standard contractual clauses and complete a transfer impact assessment identifying how the destination country’s law affects the effectiveness of those clauses, and to adopt supplementary measures.

Evidence: Executed standard contractual clauses, including the module selection and annexes; Transfer impact assessment report and the list of supplementary measures; Data flow maps and a transfer inventory covering remote-access accounts; Policy and transparency records for handling government access requests

GDPR Data Protection Impact Assessment (DPIA) — for AI training and inferenceTransfer Impact Assessment (TIA) — supporting Clause 14 of the EU Standard Contractual ClausesCustomer security and privacy questionnaire answer bank (grouped by CAIQ / CCM domains)

Open tool: Transfer Matrix

A controller or processor that is caught by Art. 3(2) but not established in the EU must designate an EU representative in writing, established in one of the Member States where the relevant data subjects are. The representative must be mandated to be addressed, in addition to or instead of the controller or processor, by supervisory authorities and data subjects on all processing-related issues. The only exemptions are processing that is occasional, does not include large-scale processing of Art. 9(1) special categories or Art. 10 criminal-conviction data, and is unlikely to result in a risk to natural persons; and public authorities.

Evidence: Written mandate appointing the EU representative; Screenshot of the representative’s name, address and contact details published in the privacy notice; Copy of the records of processing activities held by the representative; Log of data subject requests and regulator correspondence forwarded by the representative

Open tool: EU Representative Check

A DPO must be designated in three cases: processing carried out by a public authority or body, except courts acting judicially; where the core activities of the controller or processor consist of processing operations that, by their nature, scope or purposes, require regular and systematic monitoring of data subjects on a large scale; or where the core activities consist of large-scale processing of Art. 9 special categories or Art. 10 criminal-conviction data. The DPO must be designated on the basis of professional qualities, in particular expert knowledge of data protection law and practice, and may be a staff member or fulfil the tasks under a service contract. A group of undertakings may appoint a single DPO provided the DPO is easily accessible from each establishment.

Evidence: DPO designation decision and evidence of professional qualifications; Published DPO contact details and the notification filed with the supervisory authority; Documentation safeguarding independence (no instructions, no dismissal for performing the role, direct reporting to highest management); DPO annual activity report and record of advice given

GDPR Data Protection Impact Assessment (DPIA) — for AI training and inference

Controllers and their representatives must maintain records of processing activities under their responsibility, containing at least the name and contact details of the controller, joint controllers, representative and DPO; the purposes of processing; the categories of data subjects and of personal data; the categories of recipients including recipients in third countries; identification of third countries and the safeguards used for transfers; the envisaged erasure time limits for each category; and a general description of the Art. 32(1) technical and organisational security measures. The Art. 30(5) exemption for organisations with fewer than 250 employees is very narrow: it does not apply where the processing is likely to result in a risk to data subjects’ rights and freedoms, is not occasional, or involves special categories or criminal-conviction data.

Evidence: Controller records covering all Art. 30(1) elements; Processor records covering the Art. 30(2) elements where acting as a processor; Separate record entries for model training, fine-tuning and evaluation activities; Signed periodic review and update records

GDPR Data Protection Impact Assessment (DPIA) — for AI training and inferenceTransfer Impact Assessment (TIA) — supporting Clause 14 of the EU Standard Contractual Clauses

Build a demonstrable process covering access, rectification, erasure, restriction, portability, objection and rights relating to automated decision-making. Under Art. 12(3), the controller must inform the data subject of the action taken without undue delay and in any event within one month of receipt, extendable by two further months for complex or numerous requests provided the data subject is informed of the extension and the reasons within the first month. Responses are free of charge except for manifestly unfounded or excessive requests. For AI companies the hard part is locating and acting on personal data that has entered training sets and vector indexes, and explaining whether it remains reproducible in model outputs.

Evidence: Data subject request SOP and a deadline-tracking dashboard; Complete case files covering intake, identity verification, action and reply; Cross-system data location inventory covering training sets, vector indexes, logs and backups; Sample extension notices and the related statistics

GDPR Data Protection Impact Assessment (DPIA) — for AI training and inference

Where a type of processing, in particular using new technologies and taking account of its nature, scope, context and purposes, is likely to result in a high risk to natural persons’ rights and freedoms, the controller must carry out a DPIA before processing. Art. 35(3) lists three mandatory cases: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based; large-scale processing of Art. 9(1) special categories or Art. 10 criminal-conviction data; and systematic monitoring of a publicly accessible area on a large scale. The DPO’s advice must be sought where one is designated. Where the DPIA indicates a high residual risk absent mitigation, the supervisory authority must be consulted before processing (Art. 36).

Evidence: DPIA report covering the description of processing, necessity and proportionality, risk assessment and mitigation measures; Record of the DPO’s advice; Record of views sought from data subjects or their representatives where applicable; Correspondence on prior consultation with the supervisory authority where Art. 36 is triggered

GDPR Data Protection Impact Assessment (DPIA) — for AI training and inferenceEU AI Act Article 27 Fundamental Rights Impact Assessment (FRIA)

A data subject has the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects or similarly significantly affects them. Only three exceptions apply: the decision is necessary for entering into or performing a contract between the data subject and the controller; it is authorised by Union or Member State law laying down suitable safeguards; or it is based on the data subject’s explicit consent. In the contract-necessity and explicit-consent cases the controller must implement suitable safeguards including, at least, the right to obtain human intervention, to express a point of view and to contest the decision. Such decisions must not be based on Art. 9(1) special categories unless Art. 9(2)(a) or (g) applies with suitable safeguards in place.

Evidence: Inventory of solely automated decision use cases with the legal basis determination; Product description and operational logs of the human-intervention path; Explanation of the decision logic in a form intelligible to data subjects; Statistics on contested decisions and overturn rates

GDPR Data Protection Impact Assessment (DPIA) — for AI training and inference

A controller may only use processors providing sufficient guarantees to implement appropriate technical and organisational measures, and the processing must be governed by a contract or other binding legal act setting out the subject matter, duration, nature and purpose of processing, the types of personal data and categories of data subjects, and the controller’s rights and obligations. A processor must not engage another processor without prior specific or general written authorisation from the controller; under a general authorisation the processor must inform the controller of intended additions or replacements, giving it the opportunity to object.

Evidence: Repository of executed data processing agreements; Sub-processor list and records of change notifications; Due diligence and security assessment records for sub-processors; Operating arrangements by which the processor assists the controller with Arts. 32 to 36

Supplier and subcontractor ESG and security due diligence questionnaire (for use as the buyer)Customer security and privacy questionnaire answer bank (grouped by CAIQ / CCM domains)Transfer Impact Assessment (TIA) — supporting Clause 14 of the EU Standard Contractual Clauses

Controllers and processors must implement appropriate technical and organisational measures ensuring a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risks to natural persons. Measures may include pseudonymisation and encryption; the ability to ensure ongoing confidentiality, integrity, availability and resilience of processing systems and services; the ability to restore availability and access in a timely manner after an incident; and a process for regularly testing, assessing and evaluating effectiveness. Data protection by design and by default must also be implemented at the time of determining the means of processing and during the processing itself (Art. 25).

Evidence: Inventory of security measures with the risk-proportionality rationale; Evidence of encryption and pseudonymisation implementation, including key management and masking rules; Business continuity and restoration drill records; Periodic effectiveness testing and assessment reports such as penetration tests and access reviews

SOC 2 Type II readiness checklist (Trust Services Criteria)Customer security and privacy questionnaire answer bank (grouped by CAIQ / CCM domains)GDPR Data Protection Impact Assessment (DPIA) — for AI training and inference

Classify the software under Rule 11 in Annex VIII section 6.3: software providing information used to take decisions with diagnosis or therapeutic purposes is class IIa, rising to class III where the decisions may cause death or an irreversible deterioration of health, or class IIb where they may cause serious deterioration or a surgical intervention; software monitoring physiological processes is class IIa, or class IIb where it monitors vital physiological parameters whose variations could cause immediate danger; other software is class I. The classification drives the notified body route, the depth of the technical documentation and the clinical evaluation, so it must be fixed in a written classification rationale and re-assessed whenever the intended purpose wording changes.

Evidence: Finalised intended purpose with indications, users and use environment; Rule 11 classification rationale and conclusion; Notified body selection and application dossier; Conformity assessment certificates and technical documentation review records; Re-classification record whenever the intended purpose changes

The manufacturer must establish, document, implement and maintain a quality management system covering the regulatory compliance strategy, risk management, clinical evaluation, product realisation, post-market surveillance and vigilance, and must draw up and keep up to date the technical documentation under Annexes II and III. For AI software the QMS must cover the provenance and management of training, tuning and test data, model versioning and traceability, algorithm change control and revalidation, and the software lifecycle processes; the technical documentation must support the notified body review of algorithm performance, generalisation and clinical evidence.

Evidence: Quality management system documentation (quality manual, procedures, regulatory compliance strategy); Complete Annex II/III technical documentation with version records; Provenance, annotation and quality control records for training, tuning and test data; Model version register and algorithm change control and revalidation records; Risk management file and clinical evaluation report

EU AI Act Annex IV technical documentation for a high-risk AI system

A device from a manufacturer not established in the Union may only be placed on the EU market after a single authorised representative has been designated. The authorised representative accepts its tasks by written mandate: verifying the declaration of conformity and technical documentation, keeping copies, cooperating with competent authorities, forwarding information requests and adverse event information, and in defined circumstances sharing liability for defective devices with the manufacturer. For Chinese AI medical software companies the choice and mandate scope of the authorised representative is the first step of the market route, and its details are registered in EUDAMED with the device.

Evidence: Written mandate of the authorised representative setting out the tasks and termination conditions; Due diligence and capability assessment of the authorised representative; Inventory of technical documentation and declaration of conformity copies held by the representative; Consistency check of the representative details across labelling, instructions for use and registration data

Manufacturers must report serious incidents involving devices made available on the Union market, except expected side-effects that are clearly documented in the product information, quantified in the technical documentation and subject to trend reporting under Article 88. The reporting period must reflect the severity: as a general rule the manufacturer reports immediately after establishing a causal relationship between the incident and the device, or that such a relationship is reasonably possible, and not later than 15 days after becoming aware of the incident; in the event of death or an unanticipated serious deterioration in a person state of health, immediately after establishing or as soon as it suspects a causal relationship and not later than 10 days after becoming aware; and in the event of a serious public health threat, immediately and not later than 2 days after becoming aware.

Evidence: Vigilance procedure with the deadline triage rules; Records of incident intake, causality assessment and the point in time of reporting; Serious incident reports submitted to competent authorities with acknowledgements; Field safety corrective action plan and field safety notice; Quantification basis in the technical documentation for expected side-effects subject to Article 88 trend reporting

AI incident and serious incident reporting record (register plus report drafts)

Manufacturers must implement the Unique Device Identification system under Article 27, and the UDI must be used when reporting serious incidents and field safety corrective actions under Article 87. Device registration under Article 29 and registration of manufacturers, authorised representatives and importers under Article 31 must be completed. For software devices the UDI versioning rules couple most tightly to the release cadence, so the release process must fix which changes trigger a new UDI-DI.

Evidence: UDI assignment rules and the UDI-DI / UDI-PI register; Rules and execution records for which software version changes trigger a new UDI-DI; Confirmation of device registration and economic operator registration; Evidence linking UDIs to serious incident reports and field safety corrective action records

Manufacturers must operate a post-market surveillance system proportionate to the risk class under Article 83, a PMS plan under Article 84 and a PMS report under Article 85. For class IIa, IIb and III devices a periodic safety update report under Article 86 must summarise the results and conclusions of the analyses of PMS data, including the benefit-risk determination conclusions, the main PMCF findings, and the sales volume with an estimate of the size and characteristics of the user population and, where practicable, usage frequency. Class IIb and III manufacturers must update the PSUR at least annually; class IIa manufacturers when necessary and at least every two years. For class III and implantable devices the PSUR is submitted to the notified body through the electronic system; for other devices it is made available to the notified body and, on request, to competent authorities. Where PMS identifies a need for preventive or corrective action, the measures must be implemented and the competent authorities and, where applicable, the notified body informed.

Evidence: Post-market surveillance plan and post-market surveillance report; PSUR updated at the class-specific frequency, with submission or provision records; PMCF plan and evaluation report; Real-world model performance metrics and drift alert records; Records of preventive or corrective actions and of notifications to competent authorities and the notified body

EU AI Act Annex IV technical documentation for a high-risk AI system

ADS type approval is subject to the Annex II technical specifications, assessed by the approval authority or its technical service in accordance with Annex III; as amended by Implementing Regulation (EU) 2026/481, Article 3(2) adds a second subparagraph subjecting the type approval of automated valet parking (AVP) features to the Annex V technical specifications, assessed under Annex V. The overall Annex III compliance assessment consists of five parts: the traffic scenarios to consider; assessment of the ADS safety concept and audit of the manufacturer safety management system; tests for the most relevant traffic scenarios; credibility assessment principles for a virtual toolchain used in ADS validation; and the system established by the manufacturer to ensure in-service reporting. Any Annex II requirement may be checked by tests performed by the approval authority or its technical service. Scenarios and parameters must be used where relevant to the ADS ODD; where the manufacturer deviates from the proposed parameters, the safety performance metrics and inherent assumptions used must be documented in the documentation package and shown to be adequate.

Evidence: Scenario catalogue with ODD relevance justification, including safety performance metrics and assumptions where proposed parameters are not followed; ADS safety concept document and safety management system audit records; Physical test plan and test reports for the most relevant scenarios; Credibility assessment report for the virtual simulation toolchain (model verification, validation and uncertainty analysis); Technical service findings list and closure records

The relevant entries of the information document submitted with the type-approval application under Article 24(1)(a) of Regulation (EU) 2018/858 must consist of the information for the ADS set out in Annex I. In practice this means describing, in a format the authority can check, the ODD boundaries, system architecture, perception and decision chain, degradation strategy, remote assistance interface and dual-mode transition conditions.

Evidence: ADS information document structured to the Annex I entries; ODD boundary definition and exit condition description; System architecture diagram and inventory of safety-relevant interfaces; For dual mode vehicles, design and test evidence that mode transitions occur only at standstill

The Regulation separates two concepts: in-service monitoring means data collected by the manufacturer and data from other sources to obtain evidence on the in-service safety performance of the ADS in the field; in-service reporting means data reported by the manufacturer to demonstrate that safety performance. Part 5 of Annex III makes the system established by the manufacturer to ensure in-service reporting part of the compliance assessment, so it must be auditable at type approval rather than built after launch.

Evidence: Inventory of in-service monitoring data items, their sources and collection methods; Design document for the in-service reporting system (content, frequency, accountable owner); Data quality control and anomaly detection procedures; Data provision and responsibility allocation agreement with the transport service operator; Legal assessment record for cross-border data transfers

AI incident and serious incident reporting record (register plus report drafts)

On an incident having a significant impact on the provision of services, the entity must notify its CSIRT or, where applicable, the competent authority without undue delay, and where appropriate notify the recipients of its services likely to be adversely affected. An incident is significant if it has caused or is capable of causing severe operational disruption or financial loss for the entity, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Reporting is staged: an early warning within 24 hours of becoming aware, indicating where applicable whether the incident is suspected of being caused by unlawful or malicious acts or could have cross-border impact; an incident notification within 72 hours updating the early warning with an initial assessment including severity and impact and, where available, indicators of compromise; an intermediate report on request of the CSIRT or competent authority; and a final report under Art. 23(4). Entities must also, where appropriate, communicate without undue delay to potentially affected service recipients any measures or remedies they can take in response to a significant cyber threat.

Evidence: Incident severity criteria and significance determination records; Submission records and acknowledgements for the 24-hour early warning, 72-hour notification and final report; Notification text and delivery records for service recipients; Playbook sequencing the NIS2 clock alongside the GDPR breach notification clock

SOC 2 Type II readiness checklist (Trust Services Criteria)

Entities listed in Art. 26(1)(b) — including cloud computing service providers, data centre service providers, content delivery network providers, managed service and managed security service providers, and providers of online marketplaces, online search engines and social networking platforms — that are not established in the Union but offer services there must designate a representative in one of the Member States where the services are offered, and are then under that Member State’s jurisdiction. Art. 27(2) requires such entities to submit to the competent authorities their name, sector and entity type, the address of their main establishment or of the representative, contact details, the Member States served and their IP ranges, and Art. 27(3) requires notification of any change without delay and in any event within three months of the change.

Evidence: Representative appointment documents and proof of establishment; Registry information submitted to the competent authority and the acknowledgement; Records of change notifications filed within three months; Inventory of services and Member States served, used to determine jurisdiction

Entities must take appropriate and proportionate technical, operational and organisational measures to manage the risks to the security of the network and information systems they use for their operations or services, and to prevent or minimise the impact of incidents on service recipients and other services. The measures must follow an all-hazards approach and include at least: (a) policies on risk analysis and information system security; (b) incident handling; (c) business continuity such as backup management and disaster recovery, and crisis management; (d) supply chain security, including security aspects of relationships with direct suppliers and service providers; (e) security in network and information system acquisition, development and maintenance, including vulnerability handling and disclosure; (f) policies and procedures to assess the effectiveness of the measures; (g) basic cyber hygiene practices and cybersecurity training; (h) policies and procedures on cryptography and, where appropriate, encryption; (i) human resources security, access control policies and asset management; and (j) the use of multi-factor or continuous authentication, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.

Evidence: Information security management system documentation with an item-by-item mapping to the ten categories; Risk assessment reports and treatment plans; Business continuity and disaster recovery exercise records; Periodic assessment reports on the effectiveness of the measures

SOC 2 Type II readiness checklist (Trust Services Criteria)

When assessing whether the Art. 21(2)(d) supply chain measures are appropriate, entities must take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of those suppliers, including their secure development procedures, and must take into account the results of the coordinated security risk assessments of critical supply chains carried out under Art. 22(1). For an AI supply chain this means model vendors, GPU clouds, annotation outsourcers and open-source components all fall within the assessment.

Evidence: Direct supplier inventory with tiered assessment records; Supplier security questionnaires and collected audits or certificates; Security and incident-notification clauses in contracts; Inventory of open-source and third-party components with vulnerability monitoring records

Customer security and privacy questionnaire answer bank (grouped by CAIQ / CCM domains)Tender / RFP compliance response pack (covering both EU public procurement and enterprise procurement)Supplier and subcontractor ESG and security due diligence questionnaire (for use as the buyer)

Open tool: RFP Model Answers

Member States must ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken to comply with Art. 21, oversee their implementation, and can be held liable for the entity’s infringements of that Article. Members of management bodies must also follow training, and entities are encouraged to offer similar training to employees regularly, so that they gain sufficient knowledge and skills to identify risks and assess cybersecurity risk-management practices and their impact on the services provided.

Evidence: Board resolutions or minutes approving the cybersecurity measures; Periodic oversight reporting packs and records of management’s comments; Training records and certificates for management body members; Employee cybersecurity training plan and completion statistics

A product may only be placed on the market if an economic operator established in the Union is responsible for the tasks in Article 4(3) of Regulation (EU) 2019/1020. In addition, where appropriate to the risks, that responsible person must regularly check that the product conforms to the Article 9(2) technical documentation and meets the Article 9(5), (6) and (7) requirements on identification, manufacturer contact details and instructions/safety information, and must provide documented evidence of those checks on request. Its name, registered trade name or trade mark and postal and electronic contact details must appear on the product, its packaging, the parcel or an accompanying document.

Evidence: Mandate or contract with the responsible person covering the Article 4(3) tasks; Artwork proof of the responsible person details on the product or packaging; Responsible person check-list and per-batch check records; Record of documented evidence provided to market surveillance authorities

Where a manufacturer considers or has reason to believe that a product it placed on the market is dangerous it must immediately take the corrective measures needed to bring it into conformity, including withdrawal or recall as appropriate; inform consumers under Article 35 or 36 or both; and inform, through the Safety Business Gateway, the market surveillance authorities of the Member States where the product was made available, giving details of the risk and of any corrective measure taken and, where available, the quantity per Member State still circulating. Where product registration or loyalty systems allow consumers to be identified they must be contacted directly; where not all affected consumers can be reached, a clear and visible recall notice or safety warning must be disseminated through the widest possible channels including the company website and social media.

Evidence: Dangerousness determination and corrective action decision record with timestamps; Recall notice text and screenshots of the publication channels (website, social media, marketplaces); List of affected consumers and direct contact records, including the basis for collecting safety-only contact details; Safety Business Gateway notifications and correspondence with authorities; Remedy execution ledger (repair, replacement, refund) and recall effectiveness statistics

Before placing a product on the market the manufacturer must carry out an internal risk analysis and draw up technical documentation containing at least a general description of the product and the essential characteristics relevant for assessing its safety. Where appropriate to the risks it must also contain an analysis of possible risks and the solutions adopted, including the outcome of tests conducted by or for the manufacturer, and the list of European standards or other elements applied. Where standards were only partly applied the parts applied must be identified. The documentation must be kept up to date and available to market surveillance authorities for 10 years.

Evidence: Internal risk analysis report; Technical documentation (product description, safety-relevant essential characteristics, risks and mitigations); Third-party or in-house laboratory test reports; List of European standards applied, identifying clauses where only partly applied; Version control and 10-year retention record for the technical documentation

The manufacturer must ensure that an accident caused by a product placed or made available on the market is notified through the Safety Business Gateway to the competent authorities of the Member State where the accident occurred, without undue delay from the moment it knows about it, stating at least the product type and identification number and the circumstances if known, and supplying further relevant information on request. Notifiable events are occurrences associated with use that resulted in death or in serious adverse effects on health and safety, permanent or temporary, including injuries, other bodily damage, illnesses and chronic health effects. Importers and distributors aware of an accident must inform the manufacturer without delay; where the manufacturer is not established in the Union, the Article 16 responsible person must ensure the notification is made.

Evidence: Accident intake and triage procedure with an internal deadline implementing "without undue delay"; Safety Business Gateway submission receipts and copies of the notifications; Accident investigation report and root-cause analysis; Channel and records for importers/distributors reporting accidents to the manufacturer

Manufacturers must make publicly available communication channels such as a telephone number, electronic address or a dedicated section of their website, taking accessibility needs into account, so that consumers can submit complaints and report accidents or safety issues. They must investigate complaints and accident information received and keep an internal register of those complaints, of product recalls and of any corrective measures taken. The register may store only the personal data necessary to investigate the complaint, kept no longer than necessary and in any event no more than five years from entry.

Evidence: Public complaint channel page and accessibility statement; Internal register of complaints and accidents with investigation conclusions and closure status; Register entries for recalls and corrective measures; Data minimisation policy and five-year deletion schedule for the register, with deletion execution logs

Economic operators must have internal processes for product safety allowing them to comply on a continuing basis. Manufacturers must ensure the product bears a type, batch or serial number or another element enabling identification, easily visible and legible for consumers (or on the packaging or an accompanying document where size or nature does not allow it); must indicate their name, registered trade name or trade mark and postal and electronic address, including the single contact point address where different; and must accompany the product with clear instructions and safety information in a language easily understood by consumers as determined by the Member State, unless the product can be used safely and as intended without them.

Evidence: Internal product safety procedure and responsibility matrix; Artwork proof of product identification (type/batch/serial) and contact details; Final instructions and safety information in each language version; Mapping of language versions to target Member States

For ICT services supporting critical or important functions the contract must, in addition to the paragraph 2 elements, contain at least the six items in Article 30(3)(a) to (f): (a) full service level descriptions including updates and revisions with precise quantitative and qualitative performance targets allowing effective monitoring and corrective action without undue delay when agreed levels are not met; (b) notice periods and reporting obligations of the provider, including notification of any development that might have a material impact on its ability to provide the services supporting critical or important functions in line with agreed service levels; (c) requirements for the provider to implement and test business contingency plans and to have ICT security measures, tools and policies providing an appropriate level of security in line with the financial entity regulatory framework; (d) an obligation to participate and fully cooperate in the financial entity threat-led penetration testing under Articles 26 and 27; (e) the right to monitor the provider performance on an ongoing basis, comprising unrestricted rights of access, inspection and audit by the financial entity or an appointed third party and by the competent authority (including taking copies on site of documentation critical to the provider operations, a right that other contractual arrangements or implementation policies must not impede or limit), the right to agree alternative assurance levels where other clients rights are affected, an obligation to cooperate fully during on-site inspections and audits, and an obligation to give details of their scope, procedures and frequency; and (f) exit strategies, in particular a mandatory adequate transition period during which the provider keeps supplying the functions or ICT services and which lets the financial entity migrate to another provider or move in-house. For a financial entity that is a microenterprise the access, inspection and audit rights under (e) may be delegated by agreement to an independent third party appointed by the provider. AI providers should note two things: material model or dependency changes and supplier capacity or licensing changes typically qualify as developments with a material impact under (b); and items (e) and (f) drive audit cooperation cost and the room for negotiating exit terms, so they cannot be ignored at the quotation stage.

Evidence: Definitions of quantitative and qualitative performance targets and monthly attainment reports; List of material-impact events, trigger criteria and the notification records; Business contingency plan and exercise reports; ICT security measures, tools and policies mapped to the customer regulatory framework; Ledger of corrective actions taken when service levels were not met; Audit and on-site inspection cooperation plan stating scope, procedures and frequency, including when alternative assurance levels apply; Records of participation and cooperation in threat-led penetration testing (TLPT); Exit strategy and transition-period service commitments (migration plan, data return, minimum transition duration)

Tender / RFP compliance response pack (covering both EU public procurement and enterprise procurement)Customer security and privacy questionnaire answer bank (grouped by CAIQ / CCM domains)

Open tool: RFP Model Answers

The contract must set out the rights and obligations in one written document including the service level agreements, and must contain at least: a clear and complete description of all functions and ICT services, stating whether subcontracting of an ICT service supporting a critical or important function, or material parts of it, is permitted and on what conditions; the regions or countries where the contracted or subcontracted functions and services are provided and where data is processed and stored, with a requirement to notify the financial entity in advance of envisaged changes; provisions on availability, authenticity, integrity and confidentiality for the protection of data including personal data; provisions on access, recovery and return of personal and non-personal data in an easily accessible format on insolvency, resolution, discontinuation of business or termination; service level descriptions including updates and revisions; an obligation to assist the financial entity at no additional cost or at an ex-ante determined cost when an ICT incident related to the service occurs; an obligation to cooperate fully with the competent and resolution authorities of the financial entity including their appointees; termination rights and minimum notice periods; and the conditions for participating in the financial entity ICT security awareness programmes and digital operational resilience training.

Evidence: Standard contract template mapped clause by clause to Article 30(2); Inventory of functions and services, the subcontractor list and the subcontracting conditions; List of data processing and storage locations and the advance change notification process; Technical approach and drill records for data access, recovery and return; Incident assistance response process and the cost arrangement documentation

Customer security and privacy questionnaire answer bank (grouped by CAIQ / CCM domains)Tender / RFP compliance response pack (covering both EU public procurement and enterprise procurement)

Open tool: RFP Model Answers

Article 31(12) provides that financial entities may only use the services of an ICT third-party service provider established in a third country and designated as critical under Article 31(1)(a) if that provider has established a subsidiary in the Union within the 12 months following designation. The recitals note that the subsidiary requirement does not prevent a critical provider from supplying ICT services and related technical support from facilities and infrastructure located outside the Union, and that the Regulation imposes no data localisation obligation. Chinese providers with the scale and concentration profile that could attract designation should plan the EU entity, staffing and oversight cooperation in advance.

Evidence: Contingency plan for establishing the EU entity (form, location, timetable, cost); Description of the EU entity functions, staffing and mandate; Named liaison, process and document set for cooperating with the oversight framework; Transition and cooperation clauses in customer contracts addressing designation

Financial entities must maintain and update, at entity, sub-consolidated and consolidated level, a register of information on all contractual arrangements on the use of ICT services provided by ICT third-party service providers, and must make the full register or specified sections available to the competent authority on request, together with any information necessary for effective supervision. The practical obligation on the provider is to supply and keep current the fields needed for that filing — legal identification, service description, criticality of the supported function, subcontracting chain, locations, service levels — and to push updates when they change, since stale data directly causes customer reporting failures.

Evidence: Register field list mapped to internal data sources; Records of register information provided to financial customers with update timestamps; Subcontracting chain information and subcontractor change notifications; Legal entity identification information and group structure description

Customer security and privacy questionnaire answer bank (grouped by CAIQ / CCM domains)

Screen every AI capability offered in the EU, or whose output is used in the EU, against the Article 5 prohibition list (manipulation and deception, exploitation of vulnerabilities, social scoring, individual criminal-offence prediction from profiling, untargeted facial-image scraping, emotion recognition at work and in education, biometric categorisation inferring protected characteristics, real-time remote biometric identification for law enforcement, and from 2 Dec 2026 the generation of non-consensual intimate imagery and child sexual abuse material). Remove or technically block any hit before placing the system on the market, and keep the assessment on file.

Evidence: Article 5 prohibition screening matrix mapped to product features, with conclusions; Technical removal or blocking design for any hit, plus pre-release verification records; Signed review minutes from legal and product owners on prohibited practices; Description of misuse safeguards for synthetic-content products (safety filters, prompt blocking, abuse-report handling)

Open tool: AI Act Classifier

Draw up and keep up to date model technical documentation covering the training and testing process and evaluation results, containing at least the Annex XI elements, and provide it to the AI Office and national competent authorities on request. Separately, supply downstream AI system providers with information and documentation containing at least the Annex XII elements so they can understand the model’s capabilities and limitations and meet their own obligations. Models released under a genuinely free and open-source licence with public weights, architecture and usage information are exempt from both, unless the model has systemic risk.

Evidence: Annex XI-compliant model technical documentation (training and testing process, evaluation results, compute accounting); Model card and integration documentation for downstream providers covering the Annex XII elements; Document version-control log mapped one-to-one to model releases; Licence text and public links to weights, architecture and usage information where the open-source exemption is claimed

Model CardPublic Summary of Training Content for a general-purpose AI model (EU official template)ISO/IEC 42001 AI management system implementation and certification readiness checklist

Draw up and publish a sufficiently detailed summary of the content used for training, using the official AI Office template. It must set out the composition of data sources (including large datasets and main domain names) and how data was obtained and processed, so that rightsholders and other parties with legitimate interests can exercise their rights under Union law. The summary must match the model as actually trained and be updated with each release.

Evidence: Public training-content summary completed on the official template, with the published URL archived; Register of data sources and the licence or legal basis for each (proprietary, licensed, web-crawled, third-party datasets); Internal reconciliation record showing the summary matches the data actually used; Change history of the summary across model releases

Public Summary of Training Content for a general-purpose AI model (EU official template)Data Card — datasheet for a training, validation or test dataset

Continuously account for cumulative training compute. Under Art. 51(2), a GPAI model trained with cumulative compute greater than 10^25 floating-point operations is presumed to have high-impact capabilities and is therefore classified as a model with systemic risk. Notify the Commission within two weeks of meeting, or knowing it will meet, that condition, with supporting evidence. A provider may submit substantiated arguments with the notification that, exceptionally, the model does not present systemic risk.

Evidence: Compute accounting methodology and a per-run FLOP ledger; Threshold-crossing determination record with date and accountable owner; Notification submitted to the Commission and the acknowledgement received; Substantiated arguments and supporting evidence where exemption from systemic-risk classification is claimed

In addition to Articles 53 and 54, providers of models with systemic risk must perform model evaluation under standardised state-of-the-art protocols, including documented adversarial testing; assess and mitigate possible Union-level systemic risks; keep track of, document and report serious incidents and corrective measures to the AI Office without undue delay (and to national competent authorities where appropriate); and ensure an adequate level of cybersecurity for the model and its physical infrastructure.

Evidence: Model evaluation protocol and evaluation reports, including adversarial testing and red-teaming records; Systemic-risk identification and mitigation register with residual-risk conclusions; Serious-incident log and records of reports filed with the AI Office; Security controls for model weights and training infrastructure, with audit evidence

AI incident and serious incident reporting record (register plus report drafts)

Before placing a GPAI model on the Union market, a provider established in a third country must appoint, by written mandate, an authorised representative established in the Union. The representative verifies that the Annex XI technical documentation has been drawn up and that the Article 53 (and where applicable Article 55) obligations have been met, keeps a copy of that documentation and the provider’s contact details at the disposal of the AI Office for 10 years after the model is placed on the market, supplies information on reasoned request, and cooperates with regulators on that model. Free and open-source models with public weights, architecture and usage information are exempt unless they present systemic risk.

Evidence: Written mandate covering all tasks listed in Art. 54(3); Proof of the representative’s establishment in the EU and its contact details; Arrangement for holding the technical documentation at the representative, with the 10-year retention period stated; Records of routine liaison with the representative and handling of regulator correspondence

Public Summary of Training Content for a general-purpose AI model (EU official template)

Providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text must ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated, with technical solutions that are effective, interoperable, robust and reliable. Systems performing an assistive function for standard editing, or that do not substantially alter the deployer’s input data or its semantics, are out of scope. Compliance may be demonstrated by adhering to the Code of Practice on Transparency of AI-generated Content, the voluntary code published on 10 June 2026; non-adherents must demonstrate compliance by alternative equivalently adequate means.

Evidence: Technical description of the marking scheme (watermarking, metadata, provenance credentials) and its coverage; Test report on effectiveness, robustness and interoperability of the marking; Monitoring records of marking coverage and missed-marking incidents; Proof of signature of the Code of Practice on Transparency of AI-generated Content, or the equivalently-adequate-means justification if not signed

Open tool: AI Act Transparency Check

Assess each system against Art. 6(1) (a safety component of, or itself, a product covered by the Union harmonisation legislation in Annex I) and Art. 6(2) (the Annex III use cases). The AI Omnibus inserted Art. 6(1a)-(1c): systems used solely for non-safety-related user assistance, performance optimisation, service efficiency, automation, convenience or quality control do not qualify as safety components, but systems whose failure or malfunction would endanger health and safety do. Where a provider concludes under Art. 6(3) that an Annex III system is not high-risk, it must register itself and that system in the EU database before placing it on the market.

Evidence: Per-system high-risk classification matrix comparing against Art. 6(1) and 6(2) with conclusions; Safety-component determination applying Art. 6(1a)-(1c); Documented reasoning where a system is concluded not to be high-risk under Art. 6(3); EU database registration receipt where registration under Art. 49(2) applies

EU AI Act Annex IV technical documentation for a high-risk AI system

Open tool: AI Act Classifier

Establish, implement, document and maintain a continuous iterative risk management process across the system lifecycle: identify and analyse known and reasonably foreseeable risks to health, safety and fundamental rights under intended use; estimate risks that may arise under intended use and reasonably foreseeable misuse; evaluate further risks using post-market monitoring data under Art. 72; and adopt targeted risk management measures so that each residual risk and the overall residual risk are judged acceptable.

Evidence: Risk management plan and risk register including reasonably foreseeable misuse scenarios; Risk assessment and mitigation records with residual-risk acceptability conclusions; Records of periodic systematic review and updating; Evidence that post-market monitoring data feeds back into the risk assessment

EU AI Act Annex IV technical documentation for a high-risk AI systemISO/IEC 42001 AI management system implementation and certification readiness checklist

For high-risk systems using model-training techniques, training, validation and testing datasets must meet the Art. 10(2)-(4) quality criteria: design choices, data origin and collection, preparation, assumptions, assessment of sufficiency, examination for and mitigation of bias, handling of data gaps, and representativeness for the intended persons and the geographic and contextual setting. For systems not using training techniques, these apply only to testing datasets. The AI Omnibus deleted the former Art. 10(5) and inserted Art. 4a, permitting processing of special categories of personal data for bias detection and correction under strict conditions.

Evidence: Dataset card or datasheet covering provenance, collection process, preparation and labelling rules; Representativeness and data-gap assessment report addressing the EU target population; Bias examination and mitigation records; Where Art. 4a is relied on, the necessity justification, safeguards applied and deletion records

EU AI Act Annex IV technical documentation for a high-risk AI systemData Card — datasheet for a training, validation or test datasetISO/IEC 42001 AI management system implementation and certification readiness checklist

Draw up the technical documentation before the system is placed on the market or put into service and keep it up to date. It must contain at least the Annex IV elements in a clear and comprehensive form allowing national competent authorities and notified bodies to assess compliance. As amended by the AI Omnibus, Art. 11(1) allows SMEs including start-ups and small mid-cap companies (SMCs) to use a simplified form published by the Commission, which notified bodies must accept.

Evidence: Complete Annex IV technical documentation, or the simplified SME/SMC form; Document version log and change-tracking table; Post-market monitoring plan, which forms part of the technical documentation; Designation of the person accountable for retaining and producing the documentation

EU AI Act Annex IV technical documentation for a high-risk AI systemData Card — datasheet for a training, validation or test dataset

Systems must be designed, including through appropriate human-machine interface tools, so that natural persons can effectively oversee them while in use, in order to prevent or minimise risks to health, safety and fundamental rights under intended use and reasonably foreseeable misuse. Oversight measures must be commensurate with the risks, level of autonomy and context of use, and may be built into the system by the provider or identified by the provider for the deployer to implement. They must enable the overseeing persons to understand capacities and limitations, remain aware of automation bias, correctly interpret output, and decide not to use the output or to interrupt or stop the system.

Evidence: Human oversight design document covering interfaces, intervention points and stop mechanisms; Job descriptions, authorisations and training records for overseeing staff; Sample operational logs of human intervention and override of outputs; Product description of measures addressing automation bias

EU AI Act Annex IV technical documentation for a high-risk AI systemEU AI Act Article 27 Fundamental Rights Impact Assessment (FRIA)

Systems must achieve an appropriate level of accuracy, robustness and cybersecurity and perform consistently in those respects throughout their lifecycle. Accuracy levels and relevant metrics must be declared in the instructions for use. Systems must be as resilient as possible to errors, faults or inconsistencies within the system or its environment, which may be achieved through technical redundancy, backup or fail-safe plans. Systems that continue to learn after being placed on the market must be developed so as to eliminate or reduce as far as possible the risk of biased outputs influencing future inputs (feedback loops), and must be resilient to unauthorised third-party attempts to alter their use, outputs or performance. The AI Omnibus inserted Art. 42(3): high-risk systems within the scope of the Cyber Resilience Act that satisfy its Art. 12(1) conditions are deemed to comply with Art. 15.

Evidence: Accuracy and robustness test plan and reports with metric definitions; Design description of redundancy and fail-safe arrangements; Controls and test records against adversarial attacks (data poisoning, model poisoning, adversarial examples, model evasion); Feedback-loop monitoring and mitigation records for continuously learning systems

EU AI Act Annex IV technical documentation for a high-risk AI systemModel Card

Determine the conformity assessment route under Art. 43. For Annex III point 1 (biometrics) systems where harmonised standards or common specifications have been applied, the provider may choose Annex VI internal control or Annex VII with notified body involvement; where those standards are absent or only partly applied, Annex VII is mandatory. Annex III points 2 to 8 follow Annex VI internal control. Systems covered by the Annex I Section A harmonisation legislation follow that legislation’s procedure, with the Chapter III Section 2 requirements integrated into it. On completion, draw up a written, machine-readable, physically or electronically signed EU declaration of conformity per system with the Annex V content, keep it at the disposal of national competent authorities for 10 years after placing on the market or putting into service, and affix the CE marking (a digital CE marking for digitally provided systems).

Evidence: Rationale for the chosen conformity assessment route, including the status of harmonised standards and common specifications; Notified body certificate or internal-control assessment report; EU declaration of conformity with the Annex V content and the 10-year retention arrangement; Evidence of where the CE marking is affixed and of accessibility of the digital CE marking

EU AI Act Annex IV technical documentation for a high-risk AI systemTender / RFP compliance response pack (covering both EU public procurement and enterprise procurement)

Before making a high-risk AI system available on the Union market, a provider established in a third country must appoint, by written mandate, an authorised representative established in the Union. The representative verifies that the EU declaration of conformity and technical documentation have been drawn up and that an appropriate conformity assessment has been carried out; keeps the provider’s contact details, a copy of the declaration, the technical documentation and any notified body certificate at the disposal of competent authorities for 10 years after the system is placed on the market or put into service; supplies on reasoned request all information and documentation needed to demonstrate conformity, including access to logs under the provider’s control; and cooperates with competent authorities.

Evidence: Written mandate covering all tasks in Art. 22(3); Index of compliance documents held by the representative and the retention period; Contingency plan for the representative terminating the mandate

EU AI Act Annex IV technical documentation for a high-risk AI system

Providers of high-risk AI systems must report serious incidents to the market surveillance authority of the Member State where the incident occurred: immediately after establishing a causal link, or the reasonable likelihood of one, between the system and the incident, and in any event no later than 15 days after the provider or deployer becomes aware; no later than 2 days for a widespread infringement or a serious incident as defined in Art. 3(49)(b); and no later than 10 days in the event of a person’s death. An incomplete initial report may be filed first and completed later. After reporting, the provider must investigate without delay, including a risk assessment of the incident and corrective action, and must not alter the system in a way that could affect the subsequent assessment of causes before informing the competent authorities.

Evidence: Serious-incident criteria and tiered response playbook mapped to the 2, 10 and 15-day deadlines; Incident register and submission acknowledgements; Incident investigation report with root-cause analysis and corrective actions; Records of evidence preservation and of the notify-before-modifying process

AI incident and serious incident reporting record (register plus report drafts)

Put in place and operate a policy to comply with Union copyright law, in particular identifying and respecting rights reservations expressed under Article 4(3) of Directive (EU) 2019/790 using state-of-the-art technologies (for example robots.txt and machine-readable opt-out signals). The policy must cover crawling, dataset procurement, fine-tuning data and synthetic-data pipelines.

Evidence: Copyright compliance policy text with approval record; Crawler and data-collection configuration (robots.txt compliance, opt-out signal detection rules) and execution logs; Dataset procurement contracts and chain-of-rights evidence; Log of rightsholder complaints and takedown requests and how they were handled

Public Summary of Training Content for a general-purpose AI model (EU official template)Data Card — datasheet for a training, validation or test dataset

AI systems intended to interact directly with natural persons (chatbots, voice assistants, customer-service and sales agents) must be designed so that users are informed they are interacting with an AI system, unless this is obvious to a reasonably well-informed, observant and circumspect person. The information must be given clearly and distinguishably at the latest at the first interaction and must meet accessibility requirements.

Evidence: In-product AI disclosure copy and interface screenshots for each language; Technical description of the first-interaction trigger logic; Accessibility compliance check record

Model CardTender / RFP compliance response pack (covering both EU public procurement and enterprise procurement)

Open tool: AI Act Transparency Check

Deployers of emotion recognition or biometric categorisation systems must inform the natural persons exposed to them and process personal data in line with the GDPR. Deployers generating or manipulating image, audio or video content constituting a deep fake must disclose that it is artificially generated or manipulated; the same applies to AI-generated or manipulated text published to inform the public on matters of public interest, unless the content underwent human review with a natural or legal person holding editorial responsibility. For evidently artistic, creative, satirical or fictional works the disclosure may be limited to an appropriate manner that does not hamper enjoyment of the work.

Evidence: Deepfake disclosure labelling standard and sampled evidence of published content; Notice copy and delivery records for emotion recognition or biometric categorisation contexts; GDPR lawful basis and cross-reference to the processing records for those activities

Open tool: AI Act ClassifierOpen tool: AI Act Transparency Check

High-risk systems must technically allow automatic recording of events over their lifetime, with logging capabilities sufficient to identify situations that may cause the system to present a risk within the meaning of Art. 79(1) or to undergo a substantial modification, to support post-market monitoring under Art. 72, and to enable deployer monitoring under Art. 26(5). Providers must keep the automatically generated logs under their control for at least six months unless other Union or national law provides otherwise; deployers must do the same for logs under their control. For remote biometric identification systems the logs must at minimum record the start and end of each use, the reference database, the input data that produced a match, and the identity of the persons verifying results.

Evidence: Log schema design and retention policy documenting the six-month minimum; Description of log integrity and tamper-resistance controls; Sample log export used in a regulator-request drill; Records of data minimisation and access control for personal data in logs

EU AI Act Annex IV technical documentation for a high-risk AI systemAI incident and serious incident reporting record (register plus report drafts)

High-risk systems must be designed so that their operation is sufficiently transparent for deployers to interpret and properly use the output, and must be accompanied by instructions for use in an appropriate digital or other format giving deployers the information they need to meet their own obligations, including capabilities and limitations, declared accuracy metrics, intended purpose, known reasonably foreseeable misuse, and how human oversight measures are to be implemented.

Evidence: Released instructions for use in each target language; Basis of calculation for the declared accuracy metrics and limitations; Deployer training materials and delivery records

EU AI Act Annex IV technical documentation for a high-risk AI systemEU AI Act Article 27 Fundamental Rights Impact Assessment (FRIA)Model Card

Put in place a quality management system documented systematically in written policies, procedures and instructions, covering at least: a regulatory compliance strategy including conformity assessment and change management; design and design-verification techniques; development and quality-assurance techniques; examination, test and validation procedures before, during and after development and their frequency; technical specifications and standards applied, with alternative means where harmonised standards are not fully applied; and data management systems and procedures. As amended, Art. 17(2) requires implementation proportionate to the provider’s organisational size, in particular for SMEs and SMCs, without lowering the required rigour or level of protection.

Evidence: Quality management system manual and index of procedures; Mapping table from each Art. 17(1) item to existing system documents; Change management and release approval records; Internal audit and management review records

EU AI Act Annex IV technical documentation for a high-risk AI systemISO/IEC 42001 AI management system implementation and certification readiness checklist

Before placing on the market or putting into service a high-risk AI system listed in Annex III (except those under point 2), the provider or its authorised representative must register itself and the system in the EU database referred to in Art. 71; systems concluded not to be high-risk under Art. 6(3) must also be registered. Annex III point 2 systems are registered at national level. Systems under points 1, 6 and 7 in the areas of law enforcement, migration, asylum and border control are registered in a secure non-public section of the database.

Evidence: EU database registration receipt and a screenshot of the entry; Consistency check between the registered information and the technical documentation; Update records for any change to the registered information

EU AI Act Annex IV technical documentation for a high-risk AI system

Establish and document a post-market monitoring system proportionate to the nature of the AI technologies and the system’s risks, actively and systematically collecting, documenting and analysing performance data from deployers or other sources to evaluate continuous compliance with the Chapter III Section 2 requirements and, where relevant, interaction with other AI systems. The system must be based on a post-market monitoring plan that forms part of the Annex IV technical documentation. The AI Omnibus removed the mandatory implementing-act template and instead requires the Commission to publish guidance, including a voluntary template, by 2 Sep 2027.

Evidence: Post-market monitoring plan as part of the technical documentation; Description of data collection channels and metric definitions; Periodic monitoring analysis reports and corrective-action tracking; Contractual clauses with deployers and distributors on performance-data feedback

EU AI Act Annex IV technical documentation for a high-risk AI systemAI incident and serious incident reporting record (register plus report drafts)ISO/IEC 42001 AI management system implementation and certification readiness checklist

Deployers must take appropriate technical and organisational measures to use the system in line with the instructions for use; assign human oversight to natural persons with the necessary competence, training and authority; ensure input data is relevant and sufficiently representative to the extent they control it; monitor operation per the instructions and, where they have reason to believe the system presents a risk within the meaning of Art. 79(1), without undue delay inform the provider or distributor and the market surveillance authority and suspend use; on identifying a serious incident, inform first the provider, then the importer or distributor and the market surveillance authorities; keep logs under their control for at least six months; inform workers’ representatives and affected workers before putting a high-risk system into service at the workplace; and, where applicable, use the Art. 13 information to carry out a GDPR Art. 35 data protection impact assessment.

Evidence: Operating procedures derived from the instructions for use, plus approvals for any deviation; Authorisation and training records for human-oversight roles; Input data quality control records; Notice to workers’ representatives and proof of delivery where deployed at the workplace

EU AI Act Article 27 Fundamental Rights Impact Assessment (FRIA)

The FRIA has a narrow, specific scope: before deploying an Art. 6(2) high-risk system (other than Annex III point 2 critical infrastructure), deployers that are bodies governed by public law or private entities providing public services, and deployers of Annex III points 5(b) and 5(c) systems (creditworthiness assessment and risk assessment and pricing for life and health insurance), must assess the impact on fundamental rights. The assessment covers the deployer’s processes, the period and frequency of use, the categories of persons and groups likely to be affected, the specific risks of harm, the implementation of human oversight measures, and the measures to be taken if risks materialise including internal governance and complaint mechanisms. Results must be notified to the market surveillance authority using the AI Office questionnaire template. It applies to first use and must be updated when elements change. The AI Omnibus allows cross-referencing to, or incorporation of, the GDPR Art. 35 DPIA.

Evidence: FRIA applicability determination explaining why it is or is not triggered; Full FRIA report covering the six elements in Art. 27(1); Notification to the market surveillance authority and the submitted questionnaire acknowledgement; Cross-reference table linking the FRIA to the DPIA

EU AI Act Article 27 Fundamental Rights Impact Assessment (FRIA)Tender / RFP compliance response pack (covering both EU public procurement and enterprise procurement)

Where a third party substantially modifies a system or changes its intended purpose and becomes a new provider, the initial provider ceases to be the provider of that specific system but must cooperate closely with the new provider, making available the necessary information and reasonably expected technical access and assistance, including technical documentation sufficient to assess compliance with Art. 16, information on known limitations and failure modes, and targeted technical access for testing and validation. This does not apply where the initial provider has clearly specified that its system is not to be changed into a high-risk AI system. In addition, third parties supplying AI systems, models, tools, services, components or processes used or integrated in a high-risk system must specify by written agreement the information, capabilities, technical access and assistance the high-risk provider needs; this does not apply to tools, services, processes or components other than GPAI models made publicly available under a free and open-source licence. The AI Omnibus brought breaches of Art. 25(2) and (4) within the Art. 99(4) fine bracket.

Evidence: Template written agreement with downstream integrators covering the Art. 25(4) elements; Technical documentation and statements of known limitations and failure modes delivered downstream; Records of technical access granted for testing and validation; Where the carve-out is relied on, the explicit product-documentation statement that the system is not to be changed into a high-risk AI system

EU AI Act Article 27 Fundamental Rights Impact Assessment (FRIA)Model CardSupplier and subcontractor ESG and security due diligence questionnaire (for use as the buyer)

Providers and deployers must take measures to build the AI literacy of their own staff and of persons operating AI systems on their behalf, taking account of technical knowledge, experience, education and context of use. As amended by the AI Omnibus, the duty does not require guaranteeing any specific literacy level for any individual, but evidence of training is still expected.

Evidence: AI literacy training syllabus and materials; Role-based attendance list and completion records; Assessment or knowledge-check records evidencing effectiveness

ISO/IEC 42001 AI management system implementation and certification readiness checklist

Providers of data processing services must take all adequate technical, organisational and legal measures, including contracts, to prevent international and third-country governmental access to and transfer of non-personal data held in the Union where such access or transfer would conflict with Union law or the national law of the relevant Member State. A third-country court, tribunal or administrative decision requiring transfer or access is recognised or enforceable only if based on an international agreement in force between the requesting third country and the Union or a Member State, such as a mutual legal assistance treaty. Absent such an agreement, transfer or access may occur only where the three cumulative conditions in Art. 32(3) are met: the third-country system requires the reasons and proportionality of the decision to be set out and requires it to be specific in character; the addressee’s reasoned objection is subject to review by a competent third-country court; and that court is empowered to take due account of the relevant legal interests of the data provider protected by Union or Member State law.

Evidence: Government access request policy and escalation process; Description of technical and organisational separation measures such as data residency, key custody and access approval; Contractual arrangements with customers and within the group restricting extraterritorial access; Register of access requests received, how they were handled, and notifications to customers

Transfer Impact Assessment (TIA) — supporting Clause 14 of the EU Standard Contractual Clauses

Where data cannot be accessed directly from the product or related service, the data holder must make readily available data and the necessary metadata accessible to the user without undue delay, of the same quality as is available to the data holder, easily, securely and free of charge, in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, continuously and in real time, on the basis of a simple electronic request where technically feasible. The user may also require the data holder to make that data available to a third party of the user’s choosing on equivalent terms. The data holder may contractually restrict or prohibit sharing only where it could undermine statutory product security requirements with a serious adverse effect on health, safety or security of natural persons, and must notify the competent authority designated under Art. 37 when it refuses. Undertakings designated as gatekeepers under the Digital Markets Act cannot be eligible third parties.

Evidence: SOP for receiving and fulfilling user data requests; Service quality metrics and fulfilment records for the data-provision interface; Verification and execution records for third-party sharing authorisations; Determination documents where sharing is refused on safety grounds, plus the notification to the competent authority

Providers of data processing services must take the measures in Arts. 25, 26, 27, 29 and 30 to enable customers to switch to another provider of the same service type, to on-premises ICT infrastructure, or where relevant to use several providers at once, and must remove commercial, technical, contractual and organisational obstacles to terminating the contract, concluding a new contract with another provider, and porting exportable data and digital assets, including after using a free tier. From 12 Jan 2027 no switching charges may be imposed; between 11 Jan 2024 and 12 Jan 2027 only reduced charges not exceeding the costs directly linked to the switching process are allowed. Before contracting, providers must clearly inform prospective customers of standard service fees, early-termination penalties and any reduced switching charges applicable during the transition, and must publish that information in a dedicated section of their website or another easily accessible way.

Evidence: Description of switching support (export interfaces, data formats, scope of digital assets, migration assistance); Switching-charge policy and implementation records for the withdrawal from 12 Jan 2027; Pre-contractual fee disclosure page and the corresponding contract clauses; Records of customer switching requests received and completed

Connected products must be designed and manufactured, and related services designed and provided, so that product data and related service data, including the metadata necessary to interpret and use them, are by default easily, securely and free of charge available to the user in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, directly accessible. The obligation applies to connected products and related services placed on the EU market after 12 Sep 2026.

Evidence: Product data dictionary and list of exportable data items including metadata definitions; Specification of the data access interface covering format, authentication, rate limits and real-time behaviour; Design review records evidencing access by default; Evidence of the date the product was placed on the EU market, for the transition-period assessment

Before concluding a contract for the purchase, rent or lease of a connected product, the seller, rentor or lessor (which may be the manufacturer) must inform the user clearly and comprehensibly of at least: the type, format and estimated volume of product data the product can generate; whether it can generate data continuously and in real time; whether data is stored on-device or on a remote server, including the intended retention period; and how the user may access, retrieve or where relevant erase the data, including the technical means, terms of use and quality of service. Before concluding a related-service contract the provider must explain the nature, estimated volume and collection frequency of the product data it expects to obtain, the nature and estimated volume of related service data, access and retrieval arrangements, storage arrangements and retention periods.

Evidence: Pre-contractual data information text for each sales channel; Corresponding sections in the product manual and service terms; Consistency check between the disclosure and the product’s actual data capabilities

A contractual term concerning access to and use of data, or liability and remedies for the breach or termination of data-related obligations, that has been unilaterally imposed by one enterprise on another is not binding on the latter if it is unfair. A term is unfair where its use grossly deviates from good commercial practice in data access and use, contrary to good faith and fair dealing. Art. 13(4) lists terms that are unfair in any event, including those excluding or limiting the imposing party’s liability for intentional acts or gross negligence, and those excluding the remedies available to the other party for non-performance or the imposing party’s liability for it. Terms reflecting mandatory Union law provisions, or Union law that would apply absent the term, are not unfair.

Evidence: Unfair-terms self-assessment of EU-facing standard contracts and clause libraries; Item-by-item comparison against the Art. 13(4) list; Revised clause versions and their effective dates

The new AI Act Art. 111(4) requires providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content that were placed on the market before 2 Aug 2026 to take the necessary steps to comply with Art. 50(2) machine-readable marking and detectability by 2 Dec 2026. Legacy products cannot rely on having launched before the application date to avoid marking.

Evidence: Inventory of legacy systems with evidence of the date each was first placed on the EU market; Technical retrofit plan for the marking capability and its release records; Detectability verification report comparing outputs before and after the retrofit

It is prohibited to place on the market, put into service or use an AI system that generates or manipulates realistic images, videos, audio or similar material of an identifiable natural person’s intimate parts, or of such a person engaged in sexually explicit activities, without that person’s freely given, specific, informed, unambiguous and explicit consent, or that generates or manipulates material or a performance within the meaning of Art. 2, points (c) and (e), of Directive 2011/93/EU, except where a "without right" defence applies under national law. Art. 5(1a) narrows the scope: placing on the market or putting into service is prohibited only where such generation or manipulation is the system’s intended purpose, or where its design, training, architecture, capabilities or user-facing functionalities make it a reasonably foreseeable and reproducible outcome without significant technical modification and the system lacks reasonable and adequate technical safety measures and other safeguards to reliably prevent it, taking reasonably foreseeable misuse into account, and to correct observed or reported misuse. Use is prohibited only where the deployer uses the system for that purpose. In practice, the decisive question is whether the "reliably prevent and correct" safeguards can be evidenced.

Evidence: Safeguard design documentation covering input blocking, output filtering, person recognition and consent verification logic; Red-team test report against reasonably foreseeable misuse, with bypass-rate statistics; Standard operating procedure and case log for receiving and handling abuse reports; Version history of the model and safety policies evidencing that the corrective capability remains effective

The new AI Act Art. 4a permits providers of high-risk systems, to the extent strictly necessary for bias detection and correction under Art. 10(2)(f) and (g), to exceptionally process special categories of personal data, provided six cumulative conditions are met in addition to the GDPR and related instruments: (a) the objective cannot be effectively achieved by processing other data, including synthetic or anonymised data; (b) the data is subject to technical limitations on re-use and to state-of-the-art security and privacy-preserving measures including pseudonymisation; (c) security measures with strict access controls and documented access ensure that only authorised persons under confidentiality obligations can access it; (d) the data is not transmitted, transferred or otherwise accessed by other parties; (e) it is deleted once the bias has been corrected or the retention period ends, whichever comes first; and (f) the GDPR records of processing state why the processing was strictly necessary and why other data could not achieve the objective. Art. 4a(2) extends the route conditionally to providers and deployers of other AI systems and models and to deployers of high-risk systems, without creating any obligation to perform bias detection.

Evidence: Strict-necessity justification, including why synthetic or anonymised data would not work; Implementation description and configuration evidence for pseudonymisation and re-use limitations; Access control list, access logs and signed confidentiality undertakings; Deletion execution records with trigger conditions and timestamps; The corresponding entry in the GDPR Art. 30 records of processing activities

GDPR Data Protection Impact Assessment (DPIA) — for AI training and inferenceData Card — datasheet for a training, validation or test dataset

The new AI Act Art. 6(1a)-(1c) provides that AI systems used solely for non-safety-related user assistance, performance optimisation, service efficiency, automation, convenience or quality control do not qualify as safety components; that systems whose failure or malfunction would endanger health and safety do; and that a product required to undergo third-party conformity assessment solely because of risks other than health and safety, in particular radio-spectrum allocation or electromagnetic interference not affecting health and safety, does not satisfy Art. 6(1)(b). Annex I Section A point 1 was deleted and the Machinery Regulation (EU) 2023/1230 moved to Section B point 21. Companies should re-issue their written classification conclusions accordingly.

Evidence: Re-run safety-component determination under Art. 6(1a)-(1c), listing failure consequences function by function; Cross-reference to product safety engineering and FMEA analyses; Approval record for any change of classification conclusion and its impact on the conformity assessment plan

EU AI Act Annex IV technical documentation for a high-risk AI system

Open tool: AI Act Classifier

The amended AI Act Art. 11(1) allows SMEs including start-ups, and small mid-cap companies (SMCs, as defined in point (2) of the Annex to Recommendation (EU) 2025/1099), to provide the Annex IV elements in a simplified manner using the simplified technical documentation form to be established by the Commission, which notified bodies must accept. A company must first determine and evidence its size classification and plan the documentation effort accordingly.

Evidence: Size classification determination (headcount, turnover or balance-sheet total, with linked and partner enterprises aggregated); Completed simplified technical documentation form; Notified body confirmation that the simplified form was accepted

EU AI Act Annex IV technical documentation for a high-risk AI system

Manufacturers must notify actively exploited vulnerabilities contained in their products, simultaneously to the CSIRT designated as coordinator under Art. 14(7) and to ENISA, via the single reporting platform under Art. 16: an early warning within 24 hours of becoming aware, indicating where applicable the Member States where the product is known to have been made available; a vulnerability notification within 72 hours giving general information about the product, the general nature of the exploit and the vulnerability, corrective or mitigating measures taken and those users can take, and indicating how sensitive the manufacturer considers the information to be; and a final report no later than 14 days after a corrective or mitigating measure is available, including a description of the vulnerability with its severity and impact, information on any malicious actor exploiting it, and details of the security update or other corrective measures made available.

Evidence: Vulnerability and incident reporting playbook breaking down the 24-hour, 72-hour and 14-day deadlines into tasks; Single reporting platform account details and submission acknowledgements; Determination records for classifying a vulnerability as actively exploited; User-facing mitigation advisories and their publication records

AI incident and serious incident reporting record (register plus report drafts)

Open tool: CRA Reporting Duty Check

Manufacturers must notify severe incidents having an impact on the security of a product with digital elements, simultaneously to the coordinating CSIRT and ENISA via the Art. 16 single reporting platform: an early warning within 24 hours of becoming aware, stating at least whether the incident is suspected of being caused by unlawful or malicious acts and indicating where applicable the Member States where the product is known to have been made available; an incident notification within 72 hours; and a final report within one month after submission of that notification under Art. 14(4)(c), covering a detailed description of the incident including its severity and impact, the type of threat or root cause likely to have triggered it, and applied and ongoing mitigation measures. The obligation applies from 11 Sep 2026.

Evidence: Severe incident criteria and classification records; Submission records for the 24-hour early warning and 72-hour notification; Cross-regime reporting timeline matrix; Post-incident remediation and user advisory records

AI incident and serious incident reporting record (register plus report drafts)

Open tool: CRA Reporting Duty Check

When placing a product on the market the manufacturer must ensure it has been designed, developed and produced in accordance with the essential cybersecurity requirements in Annex I Part I. To that end the manufacturer must undertake a cybersecurity risk assessment for the product and take its outcome into account during planning, design, development, production, delivery and maintenance so as to minimise cybersecurity risks, prevent incidents and minimise their impact including on user health and safety. The risk assessment must be documented and updated as appropriate during the support period, must comprise at least an analysis of risks based on intended purpose, reasonably foreseeable use and the conditions of use such as the operational environment or the assets to be protected, and must indicate whether and how the Annex I Part I point (2) security requirements apply.

Evidence: Product cybersecurity risk assessment report covering intended purpose and operating environment; Point-by-point conformity statement against Annex I Part I; Security design review and security testing records; Records of risk assessment updates during the support period

Manufacturers must perform a conformity assessment of the product and of their own processes to determine whether the Annex I essential requirements are met, using the Annex VIII internal control procedure (module A), EU-type examination (module B) followed by conformity to type based on internal production control (module C), full quality assurance (module H), or where available and applicable a European cybersecurity certification scheme under Art. 27(9). For important products in Annex III class I, where harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least "substantial" have not been applied or only partly applied, or do not exist, module B+C or module H is mandatory. For important products in Annex III class II, module B+C or module H (or an applicable certification scheme) is mandatory. On completion the manufacturer draws up the Annex VII technical documentation, issues the EU declaration of conformity and affixes the CE marking.

Evidence: Product classification record (default, Annex III class I, class II or critical product); Conformity assessment report or notified body certificate; Complete Annex VII technical documentation; EU declaration of conformity and evidence of CE marking

Tender / RFP compliance response pack (covering both EU public procurement and enterprise procurement)

After becoming aware of an actively exploited vulnerability or of a severe incident having an impact on the security of the product, the manufacturer must inform the impacted users — and where appropriate all users — of that vulnerability or incident and, where necessary, of any risk mitigation and corrective measures they can deploy, where appropriate in a structured, machine-readable format that is easily automatically processable. Where the manufacturer fails to inform users in a timely manner, the notified CSIRTs designated as coordinators may provide that information. This duty is triggered by the same moment of awareness as the Art. 14(1)/(3) notifications and is a separate, outward-facing duty that filing with the CSIRT and ENISA does not discharge.

Evidence: User advisory text and publication timestamps; Records determining the impacted user population (why some users rather than all); User-actionable mitigation and corrective measure instructions; Production and distribution records for the structured machine-readable advisory, where applicable

AI incident and serious incident reporting record (register plus report drafts)

Open tool: CRA Reporting Duty Check

Manufacturers must establish and operate a vulnerability handling process under Annex I Part II, covering identification and documentation of vulnerabilities including a software bill of materials covering at least the top-level dependencies of the product, timely remediation or mitigation, distribution of security updates, a coordinated vulnerability disclosure policy, and communication about vulnerabilities. The process must remain effective throughout the support period and must feed the Art. 14 reporting duties.

Evidence: Vulnerability handling process document with assigned responsibilities; Software bill of materials in a machine-readable format, with generation and update records; Coordinated vulnerability disclosure policy and the external intake channel; Security update release records and sample user notifications

Supplier and subcontractor ESG and security due diligence questionnaire (for use as the buyer)

Manufacturers must determine a support period during which security updates are provided and vulnerability handling is maintained. In determining it, they must take into account users’ reasonable expectations of support duration, the nature and intended purpose of the product, relevant Union law, the support periods of integrated third-party components providing core functions, and relevant guidance from ADCO and the Commission, considering these matters proportionately. Without prejudice to those factors the support period must be at least five years, or the expected time in use where a product is expected to be in use for less than five years. Manufacturers must include the information taken into account in the Annex VII technical documentation.

Evidence: Support period determination rationale covering the factors considered and the proportionality reasoning; Inventory of third-party integrated components with their support periods and expiry tracking; Support period information published for users; The support period entry in the technical documentation

A manufacturer may appoint an EU authorised representative by written mandate; the obligations in Arts. 13(1)-(11), the first subparagraph of Art. 13(12) and Art. 13(14) cannot form part of that mandate. The mandate must at least allow the representative to keep the Art. 28 EU declaration of conformity and the Art. 31 technical documentation at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer; to provide, on a reasoned request from a market surveillance authority, all information and documentation necessary to demonstrate conformity; and to cooperate with market surveillance authorities on any action taken to eliminate risks posed by products covered by the mandate. Importers and distributors have their own verification duties from Art. 19 onwards, so channel contracts must allocate responsibility for delivering documentation and cooperating with investigations.

Evidence: Authorised representative mandate and the scope of the mandate; Documentation retention arrangement for 10 years or the support period, whichever is longer; Compliance responsibility allocation clauses with importers and distributors; Records of channel partner documentation requests and cooperation with investigations

Complete risk assessment and risk reduction at design and construction stage. Beyond conventional mechanical hazards it must cover lifecycle hazards that are foreseeable at the time of placing on the market as an intended evolution of fully or partially self-evolving behaviour or logic, and risks arising from interactions between machines arranged to function as an integral whole. The human-machine interface must be adapted to the foreseeable characteristics of operators and the machine must communicate its planned actions in a comprehensible manner.

Evidence: Risk assessment report with hazard list, risk matrix and residual risk statement; Documented boundaries and limiting measures for the intended evolution of self-evolving or autonomous functions; Definition of machine-to-machine interactions and of the assembly boundary; Human-machine interface design rationale showing adaptation to operator characteristics; Verification and validation test records for the risk reduction measures

EU AI Act Annex IV technical documentation for a high-risk AI system

Items 5 and 6 of Annex I Part A — safety components with fully or partially self-evolving behaviour using machine learning that ensure safety functions, and machinery embedding such systems that have not been placed independently on the market, in respect only of those systems — cannot be self-declared. One of the three Article 25(2) procedures must be used: module B EU type-examination plus module C, module H full quality assurance, or module G unit verification.

Evidence: Inventory of safety functions and the documented determination of whether machine-learning self-evolving behaviour is used; Rationale for the conformity assessment module chosen and record of notified body selection; EU type-examination certificate (module B), approved full quality assurance system (module H) or unit verification certificate (module G); Notified body findings and closure records

Draw up the technical documentation set out in Annex IV Part A before placing on the market. Technical documentation and the EU declaration of conformity must be available to market surveillance authorities for at least 10 years from placing on the market or putting into service. Where the source code or programming logic contained in the technical documentation is necessary to check compliance with the Annex III essential requirements, it must be made available upon a reasoned request.

Evidence: Complete Annex IV Part A technical file (general drawings, control circuit diagrams, calculations and test results); List of harmonised standards applied, with clause-level identification where only partly applied; Configuration management records for software and model versions; Escrow and controlled-disclosure procedure for source code / programming logic, including confidentiality arrangements; Named custodian and storage location for the 10-year retention

EU AI Act Annex IV technical documentation for a high-risk AI system

After conformity assessment, draw up the EU declaration of conformity under Article 21 and Annex V Part A and affix the CE marking under Articles 23 and 24. The machinery must be accompanied by the declaration, or the instructions must give the internet address or machine-readable code where it can be accessed. A digital declaration must stay accessible online for the expected lifetime and in any event for at least 10 years from placing on the market or putting into service.

Evidence: EU declaration of conformity in the Annex V Part A format, citing the Regulation and the notified body number; Check record for CE marking placement and visibility; Hosting page and availability monitoring record for the digital declaration; Authorisation of the signatory of the declaration

Products within the scope are subject to Regulation (EU) 2019/1020, so they may only be placed on the market if an economic operator established in the Union is responsible for the tasks in Article 4(3) of that Regulation. Non-EU manufacturers should appoint an authorised representative by written mandate under Article 12 to keep the declaration of conformity and technical documentation and cooperate with authorities. The manufacturer must state its name and a contactable postal address and digital contact on the product, its packaging or an accompanying document.

Evidence: Written mandate of the authorised representative specifying the tasks covered; Identity and address of the EU responsible economic operator and a proof of its marking on the product or packaging; Arrangement making the technical documentation and declaration retrievable inside the EU; Named contact and response procedure for market surveillance authorities

A natural or legal person carrying out a substantial modification is deemed to be the manufacturer and takes on all Article 10 obligations, must declare conformity on its sole responsibility for the affected machinery and must reapply the relevant conformity assessment procedure under Article 25(2), (3) or (4). Companies need a documented test for which remote updates, added functions or safety-related model replacements amount to a substantial modification. A non-professional user modifying their own machinery for their own use is not deemed the manufacturer.

Evidence: Change classification criteria and the per-change determination of whether a substantial modification occurs; Re-run risk assessment and delta analysis for the affected machinery; Post-modification conformity assessment records and the new EU declaration of conformity; Customer notification and on-site acceptance records

Machinery must be accompanied by the instructions and information set out in Annex III. Digital instructions are allowed only if: the means of access is marked on the product, packaging or an accompanying document; the format lets the user print, download and store them on a device (including where they are embedded in the machine software); and they stay online for the expected lifetime and at least 10 years after placing on the market. On request at the time of purchase the manufacturer must supply paper instructions free of charge within one month, and machinery intended for or foreseeably used by non-professional users must carry essential safety information on paper. The language must be one easily understood by users as determined by the Member State concerned.

Evidence: Final instructions and safety information in each required language; Proof that the access mark (QR code / URL) for digital instructions is applied on the product; Hosting evidence that digital instructions are printable, downloadable and available online for 10 years; Process and ticket records for supplying paper instructions on request within one month

Storing information, or gaining access to information already stored, in the terminal equipment of a subscriber or user is allowed only on condition that the subscriber or user has given consent, having been provided with clear and comprehensive information in accordance with data protection law, in particular about the purposes of the processing. There are only two exceptions: technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, and storage or access strictly necessary to provide an information society service explicitly requested by the subscriber or user. Analytics, advertising attribution, A/B testing and personalised recommendation therefore all require prior consent, with a refusal path as easy as acceptance.

Evidence: Cookie and SDK inventory covering purpose, category, lifetime and third-party recipients; Consent management platform configuration and consent and refusal logs; Technical verification that non-essential scripts do not load before consent; Item-by-item justification for any "strictly necessary" exemption claimed

Member States must ensure, through national legislation, the confidentiality of communications and related traffic data by means of a public communications network and publicly available electronic communications services, in particular prohibiting listening, tapping, storage or other kinds of interception or surveillance of communications and related traffic data by persons other than users without the consent of the users concerned, except when legally authorised under Art. 15(1). That paragraph does not prevent technical storage necessary for the conveyance of a communication, without prejudice to the principle of confidentiality. Art. 5(2) further provides that this does not affect any legally authorised recording of communications and related traffic data carried out in the course of lawful business practice for the purpose of providing evidence of a commercial transaction or other business communication. Note that the scope qualifier — a public communications network and publicly available electronic communications services — is the first filter in any given case: internal corporate systems and features that are not an electronic communications service are not automatically caught, so the characterisation must be settled first.

Evidence: Inventory of purposes for processing communication content with the legal basis determination; Design and implementation evidence for obtaining consent in multi-party communications; Documented boundary between technical storage necessary for conveyance and other processing; Technical controls and audit records excluding communication content from training sets

Automated calling and communication systems without human intervention, fax or electronic mail may be used for direct marketing only in respect of subscribers or users who have given prior consent. The exception is the Art. 13(2) soft opt-in: where a natural or legal person obtains its customers’ electronic contact details for electronic mail in the context of the sale of a product or service in accordance with data protection law, that same person may use those details to market its own similar products or services, provided customers are clearly and distinctly given the opportunity to object, free of charge and in an easy manner, both at the time of collection and in each subsequent message, where the customer did not initially refuse. Art. 13(4) prohibits marketing email that disguises or conceals the sender’s identity or lacks a valid reply address.

Evidence: Marketing consent capture records covering source, timestamp and scope; Assessment justifying reliance on the soft opt-in, including the "similar products" reasoning; Samples showing the objection opportunity and unsubscribe link in each message; Turnaround and execution records for unsubscribe requests

A provider intending to offer the data intermediation services listed in Art. 10 must submit a notification to the competent authority for data intermediation services. After notifying, it may start the activity subject to the conditions of that chapter, and the notification entitles it to provide data intermediation services in all Member States. A provider with establishments in more than one Member State is deemed to fall under the jurisdiction of the Member State of its main establishment. The notification must contain the information listed in Art. 11(6), beginning with the provider’s name.

Evidence: Notification submission and the competent authority acknowledgement; Mapping of the service offering to the three Art. 10 categories; Screenshot of the entry in the public register

Providing the Art. 10 services is subject to the conditions in Art. 12, of which the structural requirements matter most: the provider must not use the data for which it provides intermediation services for purposes other than putting it at the disposal of data users, and must provide the service through a separate legal person; the commercial terms including pricing for providing the service to a data holder or data user must not depend on whether, or to what degree, that party uses other services provided by the same provider or a related entity; and data collected on any activity of a natural or legal person for the purpose of providing the service, including date, time and geolocation data, duration of activity, and connections established with other persons, may be used only to develop that intermediation service, which may entail use for fraud detection or cybersecurity, and must be made available to the data holders on request.

Evidence: Incorporation documents of the separate legal person and a description of business separation; Technical and organisational controls enforcing the data use restriction; Pricing policy and compliance review evidencing no tying; Records of the use restriction on activity data and of responses to data holder requests for it

A provider not established in the Union that offers the Art. 10 services within the Union must designate a legal representative in one of the Member States where those services are offered. To ensure compliance, the representative must be mandated to be addressed, in addition to or instead of the provider, by competent authorities for data intermediation services or by data subjects and data holders on all issues related to the services provided; the representative must cooperate with and comprehensively demonstrate to the competent authorities, on request, the actions taken and arrangements put in place by the provider to ensure compliance. The provider is then deemed to fall under the jurisdiction of the Member State where the representative is located, and the designation is without prejudice to legal actions that could be brought against the provider itself.

Evidence: Legal representative mandate and scope of authority; Rationale for selecting the representative’s Member State; Records of the representative’s cooperation with competent authorities

Providers of intermediary services not established in the Union but offering services there must designate in writing a legal or natural person as their legal representative in one of the Member States where they offer services, mandated to be addressed in addition to or instead of the provider by Member State authorities, the Commission and the Board on all issues necessary for the receipt of, compliance with and enforcement of decisions under the Regulation; the representative can be held liable for non-compliance. Providers must notify the name, postal address, email address and telephone number of the representative to the Digital Services Coordinator of the Member State where the representative resides or is established, and ensure the information is publicly available, easily accessible, accurate and kept up to date. Providers must also designate under Art. 11 a single point of contact for electronic communication with authorities and publish the related information, and under Art. 12 a point of contact for direct communication with recipients of the service.

Evidence: Written mandate appointing the legal representative; Notification filed with the Digital Services Coordinator; Screenshots of the published legal representative and both contact points; Response-time and handling records for the contact points

Providers of very large online platforms and very large online search engines must diligently identify, analyse and assess any systemic risks in the Union stemming from the design or functioning of their service and its related systems, including algorithmic systems, or from the use made of their services. The assessment must be carried out by the date of application referred to in the second subparagraph of Art. 33(6), at least annually thereafter, and in any event before deploying functionalities likely to have a critical impact on the identified risks. It must cover the dissemination of illegal content; actual or foreseeable negative effects on fundamental rights; negative effects on civic discourse, electoral processes and public security; and risks relating to gender-based violence, public health, the protection of minors and serious negative consequences for a person’s physical and mental well-being. It must take particular account of how the design of recommender systems and other algorithmic systems, content moderation systems, terms and conditions and their enforcement, advertising selection and presentation systems, and the provider’s data-related practices influence those risks, and must analyse whether and how the risks are influenced by intentional manipulation, including inauthentic use or automated exploitation, and by amplification and rapid wide dissemination of illegal content and content incompatible with the terms. Supporting documents must be preserved for at least three years after the assessment and communicated on request to the Commission and the Digital Services Coordinator of establishment. Art. 35 then requires reasonable, proportionate and effective mitigation measures, expressly including testing and adapting the provider’s algorithmic systems, including recommender systems.

Evidence: Annual systemic risk assessment report including the analysis of algorithmic systems; Pre-launch risk impact assessments for new functionalities; Inventory of mitigation measures and records of testing and adapting algorithmic systems; Three-year retention arrangement for the assessment supporting documents

Providers of intermediary services must set out in their terms and conditions any restrictions imposed on the use of their service in respect of information provided by recipients, including any policies, procedures, measures and tools used for content moderation, covering algorithmic decision-making and human review, as well as the rules of procedure of their internal complaint handling system. This must be in clear, plain, intelligible, user-friendly and unambiguous language and be publicly available in an easily accessible and machine-readable format. Recipients must be informed of significant changes. Where a service is primarily directed at minors or predominantly used by them, the conditions and restrictions must be explained in a way minors can understand. Providers must act in a diligent, objective and proportionate manner when applying and enforcing those restrictions, with due regard to the rights and legitimate interests of all parties involved, including fundamental rights such as freedom of expression and media freedom and pluralism under the Charter.

Evidence: Terms and conditions text including the content moderation section and the machine-readable version; Description of algorithmic moderation policies and the human review process; Records of notifying recipients of significant changes; Minor-friendly simplified version where applicable

Providers of hosting services must put in place mechanisms allowing any individual or entity to notify them of the presence on their service of specific items of information that the notifier considers to be illegal content. The mechanisms must be easy to access and user-friendly, allow submission exclusively by electronic means, and facilitate the submission of sufficiently precise and adequately substantiated notices, for which the provider must take the measures necessary to enable notices to contain all the elements listed in Art. 16(2).

Evidence: Product implementation and accessibility evidence for the notice-and-action entry point; Notice handling SOP and turnaround statistics; Sample statements of reasons for decisions taken

Providers of online platforms using recommender systems must set out in their terms and conditions, in plain and intelligible language, the main parameters used in those systems and any options available to recipients to modify or influence them. The main parameters must explain why certain information is suggested and must include at least the criteria most significant in determining what is suggested and the reasons for their relative importance. Where several options are available for recommender systems determining the relative order of information, the provider must also make available a functionality allowing the recipient to select and modify their preferred option at any time, directly and easily accessible from the specific section of the online interface where the information is being prioritised.

Evidence: Text describing the main recommender parameters within the terms and conditions; Screenshots of the parameter-adjustment functionality and its access path; Internal reconciliation showing the description matches the actual ranking logic

Providers of online platforms presenting advertisements on their online interfaces must ensure that, for each advertisement presented to each individual recipient, the recipient can identify in a clear, concise, unambiguous manner and in real time: that the information is an advertisement, including through prominent markings; the natural or legal person on whose behalf it is presented; the person who paid for it where different; and meaningful information, directly and easily accessible from the advertisement, about the main parameters used to determine the recipient to whom it is presented and, where applicable, how to change them. Providers must also give recipients a functionality to declare whether the content they provide is or contains commercial communications. In addition, providers of online platforms accessible to minors must put in place appropriate and proportionate measures to ensure a high level of privacy, safety and security of minors on their service, and must not present advertisements based on profiling as defined in GDPR Art. 4(4) to minors.

Evidence: Interface screenshots of ad markings and targeting-parameter disclosure; Process description for collecting and displaying advertiser and payer information; Inventory of minor-protection measures and description of the age assurance mechanism; Technical evidence that profiling-based advertising is disabled for minors

Providers of intermediary services must publish, at least once a year and in a machine-readable and easily accessible format, clear and easily comprehensible reports on their content moderation, covering among other things the number of orders received from Member State authorities categorised by type of illegal content and issuing Member State, as listed in Art. 15. Providers of online platforms must add the Art. 24(1) information: the number of disputes submitted to out-of-court dispute settlement bodies, their outcomes, the median time to complete them and the share of disputes where the platform implemented the body’s decision, and the number of suspensions under Art. 23 distinguishing manifestly illegal content, manifestly unfounded notices and manifestly unfounded complaints. Providers of online platforms and online search engines must also publish, at least every six months, in a publicly available section of their online interface, the average monthly active recipients of the service in the Union calculated over the past six months.

Evidence: Annual content moderation transparency report in machine-readable form, with the published link; Methodology for calculating monthly active recipients and the half-yearly publication records; Auditable retention of the metric definitions and underlying data

Before placing a product on the EU market, identify who will be the EU-based liable operator under Art. 8(1): the importer, the authorised representative, or where neither exists the fulfilment service provider; and agree in supply contracts the allocation of liability, insurance, evidence cooperation and recourse. Note also Art. 8(3): where no Art. 8(1) operator established in the Union can be identified, a distributor becomes liable if the injured person asks it to identify such an operator or its own supplying distributor and it fails to do so within one month of the request; Art. 8(4) extends this to qualifying online platform providers.

Evidence: EU liable-operator mapping by product line and sales channel; Liability and recourse clauses with importers, authorised representatives and fulfilment service providers; Product liability insurance policy and an adequacy assessment of the cover; Process for answering distributor identification requests within the one-month deadline

Because Art. 7(2)(c) requires the effect of any ability to continue to learn or acquire new features after placing on the market to be taken into account when assessing defectiveness, and Art. 11(2) removes the defence where defectiveness is due to software, software updates or upgrades, or the lack of updates necessary to maintain safety within the manufacturer’s control, companies must bring model iteration, online learning and OTA updates into safety lifecycle management: run a safety impact assessment, regression testing and rollback design for every model or firmware change, ship updates promptly for known safety defects, and retain an evidence chain sufficient to show both that the product was not defective when placed on the market and that safety has been maintained since.

Evidence: Model and firmware version ledger including a snapshot of the baseline shipped at placing on the market; Safety impact assessment and regression test report for each change; Release and reach records for safety updates; Design and operating evidence for online-learning boundaries and drift monitoring

Art. 9 requires that, where a claimant has presented facts and evidence sufficient to support the plausibility of a compensation claim, the defendant must disclose relevant evidence at its disposal; conversely, where a defendant has presented facts and evidence sufficient to demonstrate its need for evidence to counter a claim, the claimant must disclose relevant evidence at its disposal in accordance with national law. Disclosure must be limited to what is necessary and proportionate, and in assessing that, national courts must consider the legitimate interests of all parties including third parties, in particular the protection of confidential information and trade secrets; where a defendant is required to disclose a trade secret or alleged trade secret, courts are empowered, on a duly reasoned request of a party or of their own motion, to take protective measures. Companies should plan accordingly for which technical evidence must be retrievable, explainable and producible while protecting trade secrets.

Evidence: Technical evidence retention policy covering scope, period and retrievability; Trade secret classification markings and a template request for protective measures; Verification that operating logs and model version records can be exported; Records of an internal legal and engineering evidence-production drill

Any natural or legal person that substantially modifies a product outside the manufacturer’s control and thereafter makes it available on the market or puts it into service is considered the manufacturer of that product for the purposes of the Directive (Art. 8(2)); correspondingly, Art. 11(1)(g) exempts such a modifier that proves the defectiveness causing the damage relates to a part of the product unaffected by the modification. Companies should define permitted and prohibited alterations clearly in product documentation and channel contracts, and set up an approval and record-keeping mechanism for secondary development by system integrators and distributors so that liability boundaries are determinable.

Evidence: Product documentation clauses defining permitted and prohibited alterations; Alteration approval and notification duties in channel and integrator contracts; Approval records for secondary development and the as-shipped configuration baseline; Written confirmations of liability allocation following alterations