Describe your business, leave with a checklist you can assign

Collect personal information only where reasonably necessary for the entity’s functions or activities. Sensitive information, including health information, biometric information and biometric templates, generally requires the individual’s consent and must be directly related to the entity’s functions or activities. OAIC states that many photographs or recordings of individuals, including artificially generated ones, contain sensitive information and therefore may not be scraped from the web or taken from a third-party dataset without establishing consent.

Evidence: Collection necessity assessment records; Sensitive information identification and consent records; Due diligence on third-party dataset provenance and the consent chain; Sensitive-information screening report for image and audio datasets

Before disclosing personal information to a recipient outside Australia, take reasonable steps to ensure the recipient does not breach the APPs, subject to the statutory exceptions. Section 16C extends accountability so that, in defined circumstances, an act of the overseas recipient is taken to be an act of the disclosing entity. Routing Australian user data to an affiliate or vendor in China requires contractual and supervisory arrangements built on this basis.

Evidence: Overseas disclosure register: recipient, country, data categories, purpose; Evidence of the reasonable steps taken: contract clauses, due diligence, audit rights; Assessment records where an exception is relied on; Disclosure of the countries of overseas recipients in the privacy policy

Open tool: Transfer Matrix

Take reasonable steps to protect personal information held from misuse, interference, loss, and unauthorised access, modification or disclosure, and to destroy or de-identify it once it is no longer needed for any permitted purpose and is not required to be retained by law or court order. In AI contexts this must expressly cover training sets, prompt logs and vector indexes.

Evidence: Inventory of security controls with implementation evidence; Retention schedule covering training sets and logs; Destruction and de-identification execution records; Justification that the steps taken are proportionate to the risk

Where there are reasonable grounds to believe an eligible data breach has occurred, notify the Australian Information Commissioner and affected individuals promptly; where there are only reasonable grounds to suspect one, carry out a reasonable and expeditious assessment to determine whether it is an eligible data breach. The trigger for starting an assessment, the responsible owner and the external notice templates should be settled in advance.

Evidence: Incident response plan including the NDB assessment trigger; Assessment record and conclusion; Statement filed with the Commissioner and its acknowledgement; Notice text to affected individuals and proof of dispatch

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

Under APP 1, maintain a clearly expressed, up-to-date and freely available APP privacy policy stating the kinds of personal information collected and held, how it is collected and held, the purposes of collection, how individuals may access and correct it, how to complain and how complaints are handled, and whether the entity is likely to disclose to overseas recipients and in which countries. Also implement practices, procedures and systems ensuring compliance with the APPs and enabling inquiries and complaints to be dealt with.

Evidence: Full APP privacy policy with version history; Privacy management plan and allocation of compliance responsibility; Register of inquiries and complaints; Annual policy review records

At or before the time of collection, or as soon as practicable after, take reasonable steps to notify the individual of the APP 5.2 matters, including the entity’s identity and contact details, the fact and circumstances of collection (particularly where collected from a third party rather than the individual), the purposes, the consequences of not providing the information, the entities to which it is usually disclosed, how to access, correct and complain, and whether the entity is likely to disclose to overseas recipients and in which countries.

Evidence: Collection notice text covering every APP 5.2 matter; Assessment of the method and reasonable steps used for indirect collection; Proof of delivery of the notice; List of countries of overseas disclosure

New APP 1.7 provides that where (a) an APP entity has arranged for a computer program to make, or do a thing substantially and directly related to making, a decision; (b) the decision could reasonably be expected to significantly affect the rights or interests of an individual; and (c) personal information about that individual is used in the operation of the program to make the decision or do that thing — the entity’s APP privacy policy must contain the information covered by APP 1.8, namely: the kinds of personal information used in the operation of such programs; the kinds of such decisions made solely by the operation of such programs; and the kinds of such decisions for which a thing substantially and directly related to making the decision is done by such programs. APP 1.9 confirms that making a decision includes refusing or failing to make one, and doing a thing includes refusing or failing to do it. APP 1.7 is also added to the s.13K list of provisions for which infringement notices may issue.

Evidence: Inventory of automated decisions with the significant-effect assessment and the human-machine split described; List of personal information fields used for each class of decision; The updated APP privacy policy clauses with an effective-date record; Coverage check for refusals and failures to decide; Mechanism keeping the policy in step with model or rule changes

Build a pre-transfer screening gate covering every form of outward transfer: patent assignment, patent licensing, transfer of know-how, technical cooperation, technical services and contribution of technology as capital. For each technology to be transferred, compare it against the entry descriptions and control points in the Catalogue version MOFCOM currently publishes, record a written conclusion of prohibited, restricted or free, and state in that record which Catalogue version and issue date was relied on — the annex to the 2008 Order No. 12 lapsed on 21 Dec 2023 and can no longer be used. Where the technology is military-civil dual-use, Announcement No. 38 of 2020 brings it under the export-control regime, so the dual-use lists and catch-all provisions of the Export Control Law and the Dual-Use Items Regulations must be applied at the same time.

Evidence: Technology asset inventory: name, type of right, core control points and the form in which it is embodied; Per-technology comparison against the Catalogue entries, recording the conclusion, the entry relied on, the assessor and the date; Parallel dual-use determination recording whether the technology also falls under dual-use control; Catalogue version check recording which published version was relied on and its issue date; Internal approval procedure and approval records for outbound technology transfers

A restricted technology may be contracted for and delivered only after the two-stage permit under the Technology Import and Export Administration Regulations has been completed, and the order of the stages cannot be reversed. Stage one (Arts. 34–36): file a technology export application with MOFCOM, which reviews it together with the science-and-technology authority and decides within 30 working days of receipt; if approved, a letter of intent for a technology export licence is issued, and any required confidentiality review follows national rules. ONLY AFTER OBTAINING THAT LETTER may the applicant enter substantive negotiations and sign the technology export contract — the single line in this regime most often run over by deal tempo. Stage two (Arts. 37–38): after signature, file four documents to apply for the licence itself — the letter of intent, a copy of the technology export contract, an export list of the technical materials, and proof of both parties’ legal status; MOFCOM verifies the contract’s authenticity and decides within 15 working days of receipt; where licensed, the technology export licence is issued and THE CONTRACT TAKES EFFECT ON THE DATE THE LICENCE IS ISSUED. The licence is then used to complete foreign-exchange, banking, tax and customs formalities (Art. 42); a change to the main terms requires the permit to be redone and termination must be filed (Art. 43). Free-export technologies are not a no-op either: the contract must be registered, filing a registration application, a copy of the contract and proof of both parties’ legal status, with the authority registering it and issuing a registration certificate within three working days (Arts. 40–41).

Evidence: Technology export application materials and the letter of intent for a technology export licence; The four licence-application documents: letter of intent, copy of the technology export contract, export list of the technical materials, and proof of both parties’ legal status; MOFCOM’s acceptance, decision and the original licence; Contract clause providing that it takes effect on the date the technology export licence is issued; Timeline comparing the delivery of technical materials against the date the licence was issued; Configuration evidence for the access restrictions applied to offshore entities while the permit was pending; Re-permitting records after a change to the contract’s main terms, and the filing record on termination; Contract registration application and technology export contract registration certificate for free-export technologies

Two things at once. First, treat the prohibited class as an absolute bar: Art. 32 of the Regulations says only that “technologies prohibited from export may not be exported” — no exception, no licensing route, no room to act first and regularise later. The technology asset register therefore needs a prohibited-class flag that no business process can route around: a hit ends the transaction rather than scheduling an approval. Second, widen the trigger surface to the actions that count as technology export even with no customs declaration anywhere, because Art. 2 defines technology export as “transferring technology out of the PRC by way of trade, investment or economic and technical cooperation” — the test is the act and the mode of transfer, not any movement of goods: (1) transferring technology to a wholly owned offshore subsidiary or branch — sitting inside one corporate group is not an exemption; (2) contributing technology as capital or equity into a Sino-foreign or offshore joint venture; (3) patent licensing, know-how licensing, and licensing software or models abroad; and (4) technical services, joint development and technical consulting for offshore parties, including handing domestic R&D output to an offshore affiliate to continue developing. All four sit within the three modes Art. 2 enumerates, so each needs a determination gate in the process and a failed determination must block execution. Two further cases are NOT expressly addressed by the Regulations yet carry real risk; treat them as internal risk-control gates rather than stating them as settled statutory triggers: (5) publishing model weights, training methods or core algorithm implementations as open source — whether a public release with no contract and no consideration amounts to a transfer “by way of trade, investment or economic and technical cooperation” under Art. 2 is not addressed in the text, and no official position on it was obtained in this round; and (6) offshore personnel who access technical materials in China and then use them abroad — the Regulations contain no counterpart to the “deemed export” rule of US export controls. Both should still be assessed in writing before release or licensing, with the determination retained and, where material, a query put to the commerce authority.

Evidence: Prohibited / restricted / free classification field in the technology asset register, with its update history; Decision and approval record terminating a transaction after a prohibited-class hit; Per-item determination records for technology transferred to offshore subsidiaries and branches; Technology-export determination memorandum for technology contributed as capital or equity into a joint venture; Inventory of outbound licensing and technical-service contracts with the determination reached for each; Pre-release determination record for open-source publication: scope of what is published, assessor, date and conclusion; Authorisation and scope records for offshore personnel accessing domestic technical materials

Embed the technology-export determination into outbound deal structuring: how the offshore entity sources its technology, how IP ownership and licensing run between onshore and offshore entities, where R&D output is created and who owns it, and how technology assets move in M&A and restructurings should all be compared against the Catalogue, with permit feasibility assessed, before the transaction documents are finalised. Also monitor the Catalogue and related announcements: it is administered by MOFCOM with MOST and adjusted from time to time, and an adjustment can move an existing arrangement from free to restricted, triggering a fresh determination.

Evidence: Technology flow map for the deal structure and a note on the IP ownership arrangements; Technology-export compliance memorandum prepared before the transaction documents were finalised; Description of the monitoring mechanism for the Catalogue and related announcements, with the monitoring records; Re-determination records and remediation plans following a Catalogue adjustment; Periodic review records for existing cross-border licensing arrangements

Special care-required personal information — such as creed, medical history and criminal record — may only be acquired with the individual’s prior consent, subject to statutory exceptions. For AI companies, scraping public web pages containing health, religious or political content for training is not exempted merely because the content is public; each case must be checked against the exceptions.

Evidence: Detection and filtering rules for special care-required information; Consent records or assessment of the exception relied on; Sampling review report on sensitive content in the dataset

Implement organisational, personnel, physical and technical security control measures over the personal data handled, to prevent leakage, loss or damage; where handling is entrusted abroad, the operator must also understand the relevant foreign regime and take necessary and appropriate measures.

Evidence: Security control measures procedure covering all four categories; Record of the survey of the foreign regime where handling occurs; Access control and log audit records; Employee confidentiality undertakings and training records

Where a leakage, loss or damage event of the kind prescribed by PPC rules occurs — one posing a substantial risk to individuals’ rights and interests — the operator must report to the PPC as prescribed and notify the affected individuals, unless notification is difficult and substitute protective measures are taken. A contractor that notifies the entrusting operator is relieved of reporting itself. Reporting is in two stages, a prompt report and a definitive report.

Evidence: Incident response plan including the Japanese reporting path; Records of the prompt and definitive reports filed; Notice text to individuals and proof of dispatch; Justification and records of any substitute protective measures

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

Providing personal data to a third party in a foreign country in principle requires the individual’s prior consent to that provision, and before obtaining consent the operator must supply information about the personal-information regime of that country, the protective measures taken by the recipient and other reference information, as prescribed by PPC rules. Two exceptions apply: the recipient country is designated by PPC rules as having a regime at an equivalent level to Japan; or the recipient has established a system meeting PPC-prescribed standards for continuously implementing equivalent measures. Where the latter is relied on, the provider must take the measures necessary to ensure those equivalent measures continue and must supply information about them on request.

Evidence: Information supplied to individuals about the foreign regime and the recipient’s protective measures; Consent records including time and scope of consent; Equivalent-measures system documentation: contract, internal rules and a gap-mapping table; Annual confirmation record of continued implementation; Records of responses to individuals’ requests for information

Open tool: Transfer Matrix

Specify the purpose of use as far as possible when acquiring personal information and make it public or notify the individual; any change must stay within a scope reasonably related to the original purpose and be re-notified. Before using Japanese user data for model training, confirm that training falls within the published purpose of use, otherwise extend the purpose or obtain consent first.

Evidence: Japanese-language privacy policy and published purpose-of-use page; Assessment record of the reasonable relatedness of any purpose change; Mapping of model-training uses to the published purposes

Where all or part of the handling of personal data is entrusted to another party, the entrusting operator must exercise necessary and appropriate supervision — in practice, selecting the contractor appropriately, concluding a contract containing security requirements, and keeping track of how the contractor actually handles the data. A Chinese AI company acting as contractor to a Japanese customer must be ready to be supervised and audited.

Evidence: Entrustment agreement with security and sub-contracting clauses; Contractor selection assessment record; Periodic handling-status reports and onsite or remote audit records; Sub-contracting approval records

Article 171 provides that the Act also applies where a personal information handling business operator, pseudonymously processed information handling operator, anonymously processed information handling operator or personally referable information handling operator handles, in a foreign country, the personal information of a person in Japan — or personally referable information to be acquired as such, or pseudonymously or anonymously processed information created from it — in connection with supplying goods or services to persons in Japan. Operators abroad therefore need a working capability to receive individuals’ requests and to respond to PPC enquiries and reporting requirements.

Evidence: Extraterritoriality assessment memo linking business activity to users in Japan; Japanese-language contact channel and internal response-time rules; Register of individuals’ requests; PPC enquiry response plan and designated authorised contact

A private entity in possession of biometric identifiers or biometric information must develop a written policy, made available to the public, establishing a retention schedule and guidelines for permanently destroying the data when the initial purpose for collecting it has been satisfied or within three years of the individual last interaction with the entity, whichever occurs first. Absent a valid warrant or subpoena, the entity must comply with that schedule and those guidelines.

Evidence: Published biometric retention and destruction policy with an archived copy of the page; Biometric data inventory with last-interaction timestamps; Destruction execution logs and technical evidence; Records of handling any warrant or subpoena exception

Before collecting, capturing, purchasing, receiving through trade or otherwise obtaining a biometric identifier or biometric information, a private entity must first inform the subject or the subject legally authorized representative in writing that the data is being collected or stored; inform them in writing of the specific purpose and length of term for which it is being collected, stored and used; and receive a written release executed by the subject or that representative. The definition of written release in section 14/10 was amended by P.A. 103-769 (eff. 2024-08-02) and now reads informed written consent, electronic signature, or, in the context of employment, a release executed by an employee as a condition of employment, so an electronic signature is expressly available.

Evidence: Written notice text including the purpose and term fields; Executed written releases or electronic signature records; Description of the system control that blocks collection before consent; Consent workflows differentiated for employees and third parties such as visitors and contractors

A private entity in possession of a biometric identifier or biometric information may not sell, lease, trade or otherwise profit from it, and may not disclose, redisclose or otherwise disseminate it except in the circumstances the statute allows. This is a hard constraint on product designs that train models on face or voice data or that monetize collected biometric data.

Evidence: Inventory of outbound biometric data flows with the legal basis for each; Compliance review records for training-data provenance; Contract clauses prohibiting profiting and restricting disclosure; Data access audit logs

BIPA provides a private right of action: any person aggrieved by a violation may sue in state circuit court or as a supplemental claim in federal district court. A prevailing party may recover, for each violation, liquidated damages of $1,000 or actual damages, whichever is greater, against a private entity that negligently violates the Act, and $5,000 or actual damages, whichever is greater, against one that intentionally or recklessly violates it, plus reasonable attorney fees and costs including expert witness fees, and the court may grant other relief such as an injunction. The decisive damages limits are in section 14/20(b) and (c), added by P.A. 103-769 (eff. 2024-08-02): collecting the same biometric identifier or information from the same person using the same method of collection in more than one instance is a single violation of section 15(b) with at most one recovery, and disclosing the same data about the same person to the same recipient in more than one instance is a single violation of section 15(d) with at most one recovery. The older per-scan damages theory therefore no longer holds, though the completeness, retrievability and timestamp reliability of notice and consent records still drive class-action exposure directly.

Evidence: Verification report on the completeness and retrievability of consent records; Timestamping and log retention design for biometric processing systems; Allocation-of-liability agreements with vendors such as face recognition SDK and access control suppliers; Insurance and risk reserve assessment records

Obtain valid consent before collecting, using or disclosing personal data (or confirm that deemed consent or a statutory exception applies), and notify the purposes at or before collection; notify any new purpose before that use. Do not make consent to processing beyond what is reasonable for the product a condition of supply, and confine purposes to those a reasonable person would consider appropriate.

Evidence: Privacy notice text with version history; Screenshots and event logs of the consent capture flow; Records of consent given and withdrawn; Purpose inventory and reasonableness assessment memo

Deploy physical, technical, process and contractual controls proportionate to data sensitivity and processing scale, to prevent unauthorised access, collection, use, disclosure, copying, modification or disposal. Data intermediaries are directly subject to this obligation.

Evidence: Inventory of security controls with a responsibility matrix; Access-review records; Penetration test or security assessment report; Encryption and key management policy

Before transferring personal data outside Singapore, take appropriate steps to ascertain and ensure that the recipient is bound by legally enforceable obligations providing a standard of protection at least comparable to the PDPA. Legally enforceable obligations include law, contract, binding corporate rules or any other legally binding instrument; a recipient holding a recognised specified certification is treated as bound. Where consent is relied on instead, the individual must first receive a written reasonable summary of the protection available in that country, and consent must not be a condition of supply unless the transfer is reasonably necessary to provide the product or service.

Evidence: Data-flow map and transfer inventory; Data processing addendum containing legally enforceable obligations; Assessment record of the recipient’s standard of protection; If relying on consent: the written reasonable summary and consent records

Open tool: Transfer Matrix

Conduct a reasonable and expeditious assessment on becoming aware of a possible breach; once assessed as a notifiable data breach, notify PDPC as soon as practicable and in any case no later than 3 calendar days after making that assessment, then notify affected individuals (required for the “significant harm” limb). The prescribed “significant scale” threshold is 500 or more affected individuals. Notification to individuals is excused where remedial action, or a technological measure already in place, makes significant harm unlikely.

Evidence: Incident response plan with escalation path; Breach assessment record with timestamps and conclusion; Acknowledgement of the notification filed with PDPC; Notice text sent to affected individuals and proof of dispatch; Contractual notification-deadline clause with data intermediaries

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

Develop and implement written policies and practices covering every PDPA obligation, designate at least one Data Protection Officer and publish their business contact information, run a complaints-handling process, and make information about those policies available to individuals on request.

Evidence: Data protection policy and internal operating procedures; DPO appointment letter and screenshot of the published contact details; Log of data protection complaints and queries; Staff data protection training records

Stop retaining documents containing personal data, or remove the means by which the data can be associated with particular individuals, once the collection purpose is no longer served and retention is no longer necessary for legal or business purposes. In AI contexts this must expressly cover training sets, prompt and inference logs, vector stores and model checkpoints.

Evidence: Retention schedule covering training sets and logs; Deletion and de-identification execution records; Written justification for any extended retention; Minutes of periodic retention reviews

On request, provide an individual with their personal data and information on how it has been used or disclosed in the past year, and correct errors or omissions within a reasonable time. Data held by a data intermediary but under the organisation’s control must be included. Refusals must fall within a statutory exception and be explained.

Evidence: Register of access and correction requests; Identity verification records; Response letters with any exception relied on; Records of retrieval instructions issued to data intermediaries

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

Establish a classification workflow covering everything within Art. 2, including “technical data and other data relating to the items”. Items on the export control list or subject to temporary controls require a licence from the national export control authority. Where an exporter cannot determine whether goods, technology or a service is a controlled item, it may consult the authority, which must respond promptly — a formal route to reduce uncertainty that should be exercised in writing with the reply archived.

Evidence: Classification register giving, for each product, technology or dataset, the conclusion, the list entry relied on and the assessor; Classification records for technical data and datasets: model weights, source code, datasets and design files; Archived written classification enquiries to the national export control authority and the replies received; Description of the review and refresh mechanism, including re-classification after a list adjustment

Investor ESG due diligence pack (for fundraising and pre-IPO)

For goods, technologies and services outside the control list and outside temporary controls, an exporter must apply for a licence where it knows or should know, or is notified by the national export control authority, that the items may endanger national security and interests, be used to design, develop, produce or use weapons of mass destruction or their delivery systems, or be used for terrorist purposes. “Not on the list” is therefore not a safe conclusion, and exporters must operate a red-flag identification mechanism and keep the resulting determinations.

Evidence: Red-flag checklist and the documented screening procedure; Per-transaction red-flag screening records and conclusions, including records where no flag was raised; Escalation approvals and licence applications where a flag was raised; Archived notifications from the national export control authority and the responses made; Catch-all training records for sales and commercial staff

The national export control authority maintains a control list of importers and end users that have breached end-user or end-use requirements, may endanger national security and interests, or have used controlled items for terrorist purposes, and may prohibit or restrict transactions in the relevant items or order exports suspended. Exporters must not transact with listed importers or end users in breach of the rules; where a transaction is genuinely necessary in exceptional circumstances, an application may be made to the authority. In addition, no organisation or individual may provide agency, freight, delivery, customs-clearance, third-party e-commerce platform or financial services in support of an export-control violation (Art. 20).

Evidence: Control-list screening policy and tooling documentation, naming the list sources and refresh frequency; Per-transaction screening records for counterparties and end users, with retained evidence; Handling and escalation records for hits, and archived applications and approvals for any exceptional transaction; Compliance undertakings and screening arrangements for service providers in freight, customs, payments and platforms

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

Art. 2 §3 expressly brings within export control the act by PRC citizens, legal persons and unincorporated organisations of providing controlled items to foreign organisations and individuals. On that basis, providing an item to a foreign person can be a controlled export even where the item never leaves China. Companies therefore need access-management controls covering foreign nationals and foreign entities across HR, R&D collaboration, investment due diligence, code repositories and model-weight access, applying for a licence where required. Art. 45 separately provides that transit, transhipment, through-transport, re-export and export from customs special supervision areas and bonded facilities are governed by this Law.

Evidence: Inventory of controlled technical data with classification markings; Authorisation workflow, approval records and access logs for foreign nationals and foreign entities; Screenshots of geographic and personnel access controls on code repositories, model weights and technical documentation; Approval and redaction records for technical disclosures in investment and commercial due diligence; Export licence applications and approvals where required

Consolidate into one funded, staffed, decision-empowered entity what is usually scattered across departments. First, the body and its people: set up the dedicated security management body, put its head and key-post personnel through security background vetting (with the public security and state security organs assisting), and fund and staff it; the principal bears overall responsibility for CII security protection and leads the handling of major incidents. Second, its duties: the body must discharge the eight duties in Art. 15 — establish cybersecurity management and appraisal systems and draft the security protection plan; drive protective capability building and run monitoring, testing and risk assessment; produce the organisation’s emergency plan against national and sector plans, run drills regularly and handle incidents; identify key cybersecurity posts, run appraisals and propose rewards and penalties; organise education and training; carry the responsibility for personal information and data security and build the corresponding systems; apply security management to design, construction, operation and maintenance services; and report incidents and significant matters as required. Third, decision participation: personnel of the body must take part in cybersecurity and informatisation decisions — the easiest duty to disprove in an audit, so meeting minutes need to record their attendance and views. Separately, security measures must be planned, built and brought into use simultaneously with the CII (Art. 12), so a new system’s project approval papers must show the security design moving in the same batch as the main works.

Evidence: Establishment document for the dedicated security management body, with its headcount and budget approvals; Security background vetting records for the body’s head and key-post personnel; Cybersecurity protection system and accountability documents signed off by the principal; Cybersecurity management and appraisal systems, and the CII security protection plan; Execution records for monitoring, testing and risk assessment; The organisation’s cybersecurity incident emergency plan and records of regular drills; List of key cybersecurity posts, appraisal records and reward/penalty proposals; Security education and training plan with training and assessment records; Personal information and data security protection system documents; Systems and inspection records for applying security management to design, construction, operation and maintenance services; Minutes of cybersecurity and informatisation decision meetings recording the body’s attendance and views; Project approval and acceptance documents showing security measures planned, built and used simultaneously with the main works

Two things that must leave timestamps. Testing and assessment (Art. 17): the operator must, itself or through a cybersecurity service provider, conduct at least one cybersecurity test and risk assessment of the CII each year, remediate the problems found promptly, and report as the protection department requires — all three steps are mandatory, and testing without remediation, or remediation without reporting, both fall inside the Art. 39(8) penalty. Incident reporting (Art. 18): on a major cybersecurity incident or a major threat, the operator reports to the protection department and the public security organs under the applicable rules; the Regulations separately enumerate the especially serious cases — the CII ceasing to operate as a whole or its main functions failing, leakage of national basic information or other important data, a relatively large-scale personal information leak, significant economic loss, or wide dissemination of unlawful information — which the protection department escalates to the CAC and the MPS after receiving the report. For the company this means that once any of those five appear the reporting chain escalates to ministry level immediately, so internal severity criteria have to be able to recognise them. Cooperate as well with inspections conducted by the protection department and by the public security, state security, secrecy and cryptography authorities (Art. 28).

Evidence: Annual cybersecurity test and risk assessment report, produced in-house or by an engaged provider; Contract with the cybersecurity service provider and its qualification materials; Remediation register: issue, owner, deadline, verification result; Records and acknowledgements of reports on testing, assessment and remediation made as the protection department requires; Incident severity criteria and classification records, including how the five especially serious scenarios are recognised; Reports of major incidents and major threats to the protection department and the public security organs, with timestamps; Cooperation records for authority inspections and the closed-loop remediation materials

This is where most AI companies actually meet these Regulations: the duty does not land on them directly but comes down through the customer’s procurement contract. Prepare three things in parallel. (1) The security and confidentiality agreement (Art. 20): when a CII operator procures network products and services it must sign such an agreement with the provider under the applicable national rules, specifying the provider’s technical support and security-confidentiality obligations and liabilities, and must supervise performance. The supplier should decide in advance what it can commit to: the term and response times for technical support, notification and fix windows for vulnerabilities, personnel confidentiality and vetting requirements, the boundaries of data processing and retention, limits on subcontracting and onward delegation, liability for breach, and cooperation with audits. (2) Cybersecurity review (Art. 19): operators give priority to secure and trustworthy network products and services, and procurement that may affect national security must pass cybersecurity review under national rules. The supplier needs to be able to produce, quickly, an account of its supply chain, the provenance of key components and open-source dependencies, where development and operations staff sit, data flows and storage locations, and remote-access and update mechanisms. (3) Security management of the service itself (Art. 15(7)): the operator applies security management to design, construction, operation and maintenance services, so the supplier’s implementation and operations personnel, accounts, remote access and change operations fall under the customer’s controls and appraisal — the supplier therefore needs account and operation audit capability it can hand over.

Evidence: Executed security and confidentiality agreements with CII operators and the signing records; Technical support commitments: support term, response times, vulnerability notification and fix windows; Cybersecurity review pack: supply chain composition, provenance list for key components and open-source dependencies, locations of development and operations staff, data flows and storage locations, remote-access and update mechanisms; Personnel confidentiality undertakings and records of the vetting requirements applied; Approval records for subcontracting and onward delegation, with the terms binding the subcontractor; Register of implementation and operations accounts, remote-access approvals and operation audit logs; Self-inspection of performance under the security and confidentiality agreement and records of cooperation with the customer’s supervision

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

Open tool: RFP Model Answers

Art. 31 binds every individual and organisation regardless of operator status: without approval from the CAC or the MPS, or authorisation from the protection department or the operator, no one may carry out vulnerability probing, penetration testing or other activities that could affect or endanger the security of critical information infrastructure; such activities against basic telecommunications networks must be reported to the telecommunications authority in advance. For teams building security testing, red-teaming, attack-surface mapping, automated vulnerability scanning, or AI agents capable of network probing, this constrains product design directly: default scan scope needs a hard allowlist and a do-not-scan list; the authorisation document from the operator or protection department should be a precondition checked before a scan starts rather than paperwork produced afterwards; demo and load-test environments must not point at real CII; and probing initiated by third-party users of the product has to be constrained in the service agreement and in the product at the same time. Individuals given a public-security penalty for a breach are barred for five years from cybersecurity management and key network-operation posts, and for life if criminally punished (Art. 43 §3).

Evidence: Scanning and testing authorisation policy: where authorisation comes from, how it is verified, retention requirements; Written authorisation or approval from the operator or the protection department; Configuration evidence for the product’s target allowlist and do-not-scan list; Design note and sample logs for the pre-scan authorisation check; Proof that demo and load-test environments are isolated from real targets; Service-agreement clauses restricting unauthorised probing by users, with the technical controls that enforce them; Records of advance reports for such activities against basic telecommunications networks, where applicable

Do not decide for yourself whether you are CII, and do not treat “no notice received” as a settled answer. Three things: keep a register recording whether a CII identification notice has ever been received from a protection department, which network facilities and information systems it covers, and the date and reference of the notice; write the trigger for a “material change” into change management — major system rebuilds, a change in the business carried, architecture or hosting changes, moving to or off cloud, and large data migrations should all trigger an assessment and a prompt report to the protection department, which completes a re-identification and notifies the operator within three months of receiving the report; and report any merger, division or dissolution promptly and handle the CII as the protection department requires. As a supplier, the same register should run the other way: which customers are CII operators and which part of their systems you carry, because the customer’s identification status determines which duties land in your contract.

Evidence: Original CII identification notice and the register: systems covered, identification date, notice reference; Procedure document establishing the “material change that may affect identification” gate in change management; Assessment records for material changes and the acknowledgement of the report to the protection department; Re-identification result notice and the corresponding register update; Reporting records and the CII handling plan for a merger, division or dissolution; Customer-side CII status register: which customers are operators and what scope you carry for them

No organisation or individual in China may supply data stored in the PRC to a foreign judicial or law-enforcement body without approval from the competent PRC authority. Businesses need a standing intake-freeze-assess-escalate process for foreign authority requests so that legal or business staff do not hand data over directly under discovery or regulatory pressure.

Evidence: Documented handling procedure for foreign authority requests, including freeze and escalation paths; Intake register recording date, requesting body, data scope and disposition; Approval application filed with the PRC authority and the decision received; Negotiation records or reservations logged against extraterritorial disclosure clauses in offshore customer contracts

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

Grade every data category against the national classification-and-grading regime and the specific important-data catalogues published by your sector and regional authorities, and determine whether any of it is important data or national core data. Data that has not been notified or publicly designated as important data by the relevant authority need not be declared as such in an outbound security assessment, but the identification exercise itself must leave a written conclusion available for inspection.

Evidence: Data asset inventory and grading register covering data items, sources, grades and owners; Written important-data determination, citing the sector catalogue relied on or recording that no designation was received; The grading policy document and minutes of the review meeting; Change log for grade reclassifications

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Build whole-lifecycle data security management systems as required by law, run data-security training, and adopt technical and other necessary measures to protect the data. Where processing runs over the internet or other information networks, these duties sit on top of the multi-level protection scheme (MLPS). Important-data processors must in addition designate a data security officer and a data security management body.

Evidence: Data security policy set covering collection, storage, use, processing, transmission, provision, disclosure and deletion; MLPS grading filing certificate and assessment report; Attendance sheets and test records for data security training; Appointment letter for the data security officer and terms of reference for the management body, where important data is processed

Important-data processors must run periodic risk assessments of their processing activities and file the report with the competent authority. The report must cover the categories and volumes of important data handled, the processing activities, the data security risks faced and the countermeasures taken. Art. 33 of the Network Data Security Management Regulations specifies this as an annual exercise filed with a provincial-level or higher authority. From 20 Aug 2026 the Network Data Security Risk Assessment Measures (Order No. 24) make the process concrete: Art. 5 restates the annual cadence for important-data processors and encourages ordinary-data processors to assess at least every three years; Art. 7 allows the assessment to be done in-house or by a third-party assessor; Art. 15 requires the report to be kept for at least three years; Art. 16 requires it to be filed within 20 working days of completing the annual assessment, with the provincial or national cyberspace authority where no competent authority is identified; and Art. 18(4) requires a remediation report within 15 working days where the assessment was mandated through an accredited assessor.

Evidence: Annual important-data risk assessment report covering categories, volumes, risks and countermeasures, archived for at least three years; Filing receipt or submission record from the competent authority, with a timeline comparing the assessment completion date and the filing date to evidence the 20-working-day window; Risk treatment log with closure evidence; Records of the transaction-level risk assessments run before providing, entrusting or jointly processing important data

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Data that constitutes a controlled item and relates to safeguarding national security and interests or performing international obligations is subject to export control. Businesses should fold the question “is this data a controlled item?” into their export-control classification workflow and connect it to the licensing and end-user screening steps under the Export Control Law and the Dual-Use Items Regulations, rather than treating it purely as a personal-information transfer.

Evidence: Export-control classification worksheet giving a per-dataset conclusion on controlled-item status and the reasoning; Note describing how this ties into the internal export-control compliance programme; Approval records for transfers involving controlled data; Correspondence with MOFCOM and any reply received, where a classification enquiry was raised

Pin each processing activity to one of the lawful bases in Art. 13 (consent; necessity for a contract to which the individual is a party; a statutory duty; public-health emergencies; news reporting in the public interest; reasonable handling of lawfully published information, etc.), and before processing give prominent, plain-language notice of the processor’s name and contact details, the purposes and methods, the categories of data and the retention period, and how to exercise rights; re-notify when any of this changes. Where notice is given through a processing rule (privacy policy), that rule must be public and easy to consult and retain.

Evidence: Register of processing activities, each tagged with its Art. 13 lawful basis; Public privacy policy / processing rules with version history and effective dates; Screenshots of the consent interface and consent logs (timestamp, policy version); Records of re-notification when notified items changed

Personal Information Protection Impact Assessment (PIPIA) report

For biometric data (face, voiceprint, fingerprint), medical and health data, financial accounts, location traces and the data of minors under 14, first document a “specific purpose + sufficient necessity + strict protective measures” justification, then obtain separate consent that is not bundled into a blanket consent, and additionally disclose the necessity of the processing and its impact on the individual. Where a law or administrative regulation requires written consent, that requirement prevails.

Evidence: Written necessity justification for sensitive processing, naming the specific purpose and the alternatives considered; Design note and captured screens showing how separate consent is collected; Separate-consent logs kept distinct from general consent records; Guardian consent records and the age-assurance approach for under-14 users; Inventory of strict protective measures (encryption, de-identification, least-privilege access)

Personal Information Protection Impact Assessment (PIPIA) report

Run a prior impact assessment and keep a record of the processing in five situations: processing sensitive personal information; automated decision-making; entrusting processing to, providing data to, or publicly disclosing data to another processor; transferring data abroad; and any other processing with a significant effect on individuals. The assessment must at minimum cover the lawfulness, legitimacy and necessity of the purpose and method, the impact on individuals and the security risks, and whether the protective measures are lawful, effective and proportionate to the risk. The report and processing records must be kept for at least three years.

Evidence: PIPIA report structured around the three elements of Art. 56; Trigger-mapping table showing which limb prompted which assessment; Processing records covering data flows, recipients and retention periods; Remediation log arising from the assessment, with closure evidence; Archive index demonstrating the three-year retention

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)Personal Information Protection Impact Assessment (PIPIA) reportCustomer security and privacy questionnaire answer bank (grouped by CAIQ / CCM domains)

Where personal information is or may have been leaked, tampered with or lost, take remedial action immediately and notify both the competent authority and the affected individuals. The notice must state the categories of data, the cause and the likely harm; the remedial measures taken and the steps individuals can take to mitigate harm; and the processor’s contact details. Individual notice may be omitted where the measures taken effectively avert harm, but the authority may still require it.

Evidence: Personal-data incident response plan and drill records; Severity classification records, including whether the notification threshold was met and why; Text of the notice to the authority and the filing receipt; Text of the notice to individuals, the channels used and delivery statistics; or the justification for withholding individual notice; Post-incident review report and closure evidence for remediation items

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

Automated decision-making must be transparent and fair in outcome, and must not impose unreasonable differential treatment on transaction terms such as price. Where automated decision-making is used to push information or marketing, the processor must at the same time offer an option not based on the individual’s characteristics, or a convenient way to refuse. Where an automated decision has a significant effect on an individual’s rights, the individual may demand an explanation and may refuse a decision made solely by automated means.

Evidence: Inventory of automated decisions (scenario, input features, output impact, whether significant); Self-assessment report on differential treatment, with fairness test results across price, limit and exposure; Product screenshots and release records for the non-profiled option or one-click off switch; Explanation template and human-review workflow for decisions with significant effect

Personal Information Protection Impact Assessment (PIPIA) report

Stand up an intake-and-response mechanism covering access, copies, correction, supplementation, deletion, restriction or refusal of processing, withdrawal of consent and account closure, and satisfy requests promptly. Where a transfer request meets the conditions set by the CAC, provide a channel to move the data to a processor named by the individual. Delete proactively where the purpose has been achieved, the product or service has ceased, the retention period has expired, consent has been withdrawn, or the processing breached the law or the contract; where deletion is technically infeasible, stop all processing other than storage and necessary security measures.

Evidence: Documented intake workflow for rights requests with a response-time SLA; Ticket log for requests, recording identity verification, outcome and completion time; Technical note on deletion and anonymisation, including how vector stores and training sets are traced back; Specification of the portability interface, or a record of the reasons for refusal

Personal Information Protection Impact Assessment (PIPIA) report

A processor handling personal information above the volume set by the CAC must appoint a personal information protection officer, publish the officer’s contact details and report the officer’s name and contact details to the competent authority. The Compliance Audit Measures put numbers on this: processors handling more than 1 million individuals’ data must appoint such an officer, who owns the audit work; processors handling more than 10 million individuals’ data must run a compliance audit at least once every two years. The authority may also require an audit by an accredited external firm, after which the report must be filed and a remediation report submitted within 15 working days of completing the fixes.

Evidence: Appointment letter for the protection officer and a screenshot of the public disclosure page; Filing receipt for reporting the officer’s name and contact details to the authority; Compliance audit report (in-house or by an accredited firm); Remediation log for audit findings and the receipt for the remediation report; Methodology note and monthly counts for the number of individuals whose data is processed

Personal Information Protection Impact Assessment (PIPIA) reportSOC 2 Type II readiness checklist (Trust Services Criteria)Investor ESG due diligence pack (for fundraising and pre-IPO)

A provider with public-opinion attributes or social-mobilisation capability must, within ten working days of starting the service, file through the internet information service algorithm filing system its name, service form, application field, algorithm type, algorithm self-assessment report and the content to be published. Where the materials are complete the authority grants the filing, issues a filing number and publishes it within thirty working days; where incomplete, it notifies the applicant with reasons within thirty working days. Once filed, the provider must display the filing number prominently on the website or application through which the service is offered, with a link to the published information. It must also carry out a security assessment under the applicable national rules.

Evidence: Submission record from the algorithm filing system and the filing number; Algorithm self-assessment report; Text of the content to be published and a reconciliation against the live disclosure page; Screenshots showing the filing number and the link to the published information in a prominent product location; Timeline comparing the service launch date with the filing submission date to evidence the ten-working-day window; Records of amendment and cancellation filings

Filing pack for generative AI services and algorithm filing, including the security assessment report

Establish management systems and technical measures for reviewing algorithm mechanisms, science and technology ethics review, user registration, content-publication review, data security and personal information protection, anti-telecom-fraud, security assessment and monitoring, and incident response; adopt and publish the rules governing the recommendation service; and resource it with specialist staff and technical support proportionate to its scale.

Evidence: The eight management policies with issuance records; Screenshot of the publicly published recommendation-service rules; Org chart and qualification summary for the algorithm security team; Ethics review records, with a note on the joint build with the Science and Technology Ethics Review Measures

Filing pack for generative AI services and algorithm filing, including the security assessment report

Periodically review, evaluate and validate the algorithm’s mechanisms, models, data and application outcomes, and do not deploy models that induce addiction or excessive consumption or otherwise breach the law or ethics. The review should cover both offline metrics and live outcomes, focusing on whether the system induces addiction or excessive spending and whether outcomes discriminate against particular groups.

Evidence: Plan for periodic algorithm review, evaluation and validation, stating cadence, scope, metrics, method and owner; Successive review reports covering the model, the data and live outcomes; Dedicated assessment conclusions on addiction and excessive-consumption risk; Remediation records for findings and the re-validation results

Filing pack for generative AI services and algorithm filing, including the security assessment report

Strengthen user-model and user-tag management, refine the rules for what interests enter the user model and how tags are managed, and do not record unlawful or harmful keywords as user interests or tags, nor push content on that basis. Also strengthen information-security management by building a feature library for identifying unlawful and harmful information with sound inclusion standards, rules and procedures; where algorithmically generated or synthetic information is found without a conspicuous label, apply the label before transmission continues.

Evidence: User-tag taxonomy documentation and the rules governing what enters the interest profile; Blocklist of unlawful and harmful keywords and its enforcement configuration in the tagging system; Inclusion standards, rules and procedures for the feature library, with version history; Technical design and operating statistics for detecting and re-labelling unlabelled generated content

Give users prominent notice that an algorithmic recommendation service is being provided, and publish in an appropriate manner the basic principles, purpose and main operating mechanism of that service. Provide an option that is not targeted at the user’s personal characteristics, or a convenient option to switch the recommendation service off; where the user switches it off, stop providing the service immediately. Both articles are named in Art. 31 as penalty triggers and are frequent inspection items in practice.

Evidence: Screenshots of the notice and published disclosure, covering the basic principles, purpose and main operating mechanism; Product screenshots and navigation path for the non-profiled option or the off switch; Technical verification that switching off takes immediate effect; Reconciliation between the published disclosure and the “content to be published” submitted in the algorithm filing

Filing pack for generative AI services and algorithm filing, including the security assessment report

Where the service reaches minors, perform the statutory duties of online protection for minors and make it easier for them to access information beneficial to their physical and mental health, including through a minors mode and age-appropriate services. Where it reaches the elderly, safeguard their lawful rights, provide age-friendly intelligent services under the applicable national rules, and monitor, identify and handle telecom-fraud content. Where algorithms dispatch work to labourers, protect their rights to remuneration and rest, and build sound algorithms for order allocation, pay composition and payment, working hours and incentives and penalties. Where goods or services are sold to consumers, protect fair-dealing rights and do not use algorithms to impose unreasonable differential treatment on price or other terms based on consumers’ preferences or transaction habits.

Evidence: Design documentation and release evidence for the minors mode; Age-friendly adaptation plan and records of monitoring and handling fraud-related content; Documented and published rules for order allocation, remuneration, working hours and incentives in work-dispatch algorithms; Fairness test report on price differentiation, analysing price distribution for the same item across user profiles

Before applying, run a self-assessment covering six points: the lawfulness, legitimacy and necessity of the purpose, scope and method of the transfer and of the recipient’s processing; the volume, scope, categories and sensitivity of the data and the risks the transfer may create; whether the recipient’s undertakings and its management and technical capability can secure the data; the risk of tampering, destruction, leakage, loss, transfer or unlawful acquisition or use during and after the transfer, and whether individuals have a workable channel to protect their rights; whether the draft legal instrument adequately allocates data-security responsibilities; and any other matter bearing on the security of the transfer.

Evidence: Self-assessment report addressing each of the six points in Art. 5; Field-level inventory of the data to be transferred, tagged with category, volume and sensitivity; Due-diligence pack on the offshore recipient covering its jurisdiction’s legal environment, security capability and incident history; Register of risk-mitigation measures tied to the self-assessment conclusions; Internal approval records signed by legal, security and the business owner

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Open tool: Transfer Matrix

Submit the application form, the self-assessment report, the draft legal instrument with the offshore recipient and any other materials the assessment requires (Art. 6). The provincial authority completes the completeness check within five working days of receipt, forwarding a complete pack to the CAC and returning an incomplete one with a single consolidated list of what is missing (Art. 7). Once the CAC accepts the filing it issues a written acceptance notice, and the assessment must be completed within 45 working days of that notice, extendable with notice where the case is complex or materials need correction (Art. 12). A party disputing the outcome may apply for re-assessment within 15 working days of receiving it, and the re-assessment result is final (Art. 13). The Measures themselves set no “decide on acceptance within N working days” rule; the acceptance-stage timetable sits in the CAC’s Application Guide for the Security Assessment of Outbound Data Transfers, whose text was not retrieved in this round, so no day count is stated here.

Evidence: Archived application form and the complete submission pack; Completeness-check receipt from the provincial authority and the CAC’s written acceptance notice; Correspondence on any supplementary or corrected materials; Written notice of the assessment result and, if re-assessment was sought, the application and final conclusion

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Open tool: Transfer Matrix

The legal instrument must at minimum address: the purpose, method and scope of the transfer and the recipient’s use and method of processing; where and for how long the data is stored abroad, and how it is handled once the retention period ends, the agreed purpose is achieved or the instrument terminates; binding restrictions on onward transfers by the recipient; the security measures to be taken if the recipient’s actual control or business scope materially changes, if the data-security laws or cybersecurity environment of its jurisdiction change, or if another force majeure makes security hard to assure; remedies, liability for breach and dispute resolution; and the emergency-response requirements and the routes by which individuals can protect their rights if the data is tampered with, destroyed, leaked, lost, transferred or unlawfully acquired or used.

Evidence: Executed legal instrument with the offshore recipient, in a bilingual version; Mapping table from the six mandatory matters to the specific clause numbers; Onward-transfer approval process and the list of approved onward recipients; Monitoring and trigger-response records for changes in the recipient’s control or legal environment

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

An approval is valid for three years (Art. 9 of the Cross-border Data Flow Provisions supersedes the original two-year period). To continue transferring after expiry without a re-application trigger, apply through the provincial authority within 60 working days before expiry; once approved the validity extends by a further three years. Re-application is required during the validity period where the purpose, method, scope or categories of the transfer, or the recipient’s use or method, change in a way that affects security, or the offshore retention period is extended; where the data-security laws or cybersecurity environment of the recipient’s jurisdiction change, force majeure occurs, actual control of either party changes, or the legal instrument is amended in a way that affects security; or in any other circumstance affecting the security of the transfer.

Evidence: Register of approvals and validity periods, with expiry reminders configured; Extension application materials and the approval document; Change log for transfer parameters (fields, recipients, regions, purposes); Records of re-application trigger assessments and the conclusions reached

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Art. 16: apply technical measures to add a label that does not impede use to any content generated or edited through the service, and retain log information as required by law and national rules. Art. 17: where the service provides intelligent dialogue or intelligent writing that simulates a natural person generating or editing text; synthetic or imitative voice generation or editing that significantly alters personal identity characteristics; face generation, face swapping, face manipulation or pose manipulation in images and video, or editing that significantly alters personal identity characteristics; immersive realistic scene generation or editing; or any other function that generates or significantly alters content — and the output may cause the public to confuse or mistake it — a conspicuous label must be placed at a reasonable position or area within the content. For deep synthesis services outside that list, the provider must offer a conspicuous-labelling function and remind users that they may use it.

Evidence: Mapping table comparing each service function against the five categories in Art. 17 §1; Implementation note for conspicuous and implicit labels, with samples for each modality; Design justification that the label does not impede use; Log retention policy and screenshots of the retention configuration; Description of the mechanism for detecting and responding to deleted, altered or concealed labels

Filing pack for generative AI services and algorithm filing, including the security assessment report

A deep synthesis service provider with public-opinion attributes or social-mobilisation capability must complete algorithm filing, and amendment and cancellation filings, under the Algorithmic Recommendation Provisions. Where it develops and launches a new product, application or feature with such attributes, it must carry out a security assessment under the applicable national rules. The assessment is therefore not a one-off but recurs with each significant launch.

Evidence: Algorithm filing pack and a screenshot of the published filing number; Records of amendment and cancellation filings; Trigger-determination table and release checklist for new products, applications and features; Successive security assessment reports and submission records

Filing pack for generative AI services and algorithm filing, including the security assessment report

Assume primary responsibility for information security by establishing management systems for user registration, review of algorithm mechanisms, science and technology ethics review, content-publication review, data security, personal information protection, anti-telecom-fraud and emergency response, backed by secure and controllable technical safeguards. Also adopt and publish management rules and a platform convention, refine the service agreement, and prominently remind technical supporters and users of their information-security duties.

Evidence: The eight management policies with their issuance and effective-date records; Establishment documents and review records for the science and technology ethics committee, with a note on the joint build with the Ethics Review Measures; Screenshots of the published management rules and platform convention; Information-security notice clauses in the service agreement and evidence of how they are displayed; Description of the technical safeguards, with a security and controllability justification

Filing pack for generative AI services and algorithm filing, including the security assessment report

Authenticate users’ real identity through their mobile number, identity-document number, unified social credit code or the national network identity authentication public service, and do not provide information-publishing services to users who have not been authenticated. Where an enterprise customer is authenticated by its unified social credit code, the individual operating accounts underneath must still be traceable.

Evidence: Real-identity authentication design: factors used, verification channel and failure handling; Product evidence that publishing is blocked for unauthenticated users; Mapping and audit records linking enterprise customer accounts to the individuals operating them; Note on data minimisation and encrypted storage of authentication data

Strengthen content management by reviewing users’ input data and synthetic outputs, whether by technical means or manually. Maintain a rumour-refutation mechanism: on finding that the service has been used to create, copy, publish or spread false information, take refutation measures promptly, retain the records, and report to the cyberspace authority and other competent departments. Also provide convenient entry points for user appeals and public complaints and reports, publishing the handling process and response times.

Evidence: Input and output review policy covering technical rules and the manual escalation path; Verification workflow for likeness and voice authorisation, with sample authorisations; Description of the rumour-refutation mechanism, refutation records and receipts for reports to the authority; Screenshots of the appeal and complaint entry points and the published process and response times; Retention policy for review records

Filing pack for generative AI services and algorithm filing, including the security assessment report

Deep synthesis service providers and technical supporters must strengthen training-data management and take the necessary measures to keep training data secure; where training data contains personal information, the personal-information rules apply. They must also strengthen technical management by periodically reviewing, evaluating and validating the mechanisms of their generative and synthetic algorithms. Both duties bind technical supporters, that is base-model and SDK vendors.

Evidence: Training-data security policy with grading and access-control records; Lawful basis and processing records for personal information within training data; Plan for periodic algorithm review, evaluation and validation, stating cadence, metrics and method; Successive review reports and the remediation records for findings; Agreement allocating duties between the technical supporter and the provider

Data Card — datasheet for a training, validation or test datasetFiling pack for generative AI services and algorithm filing, including the security assessment report

Before settling on the standard-contract route, confirm in writing that all four conditions in Art. 4 are met: not a CIIO; processing the personal information of fewer than 1 million individuals; cumulative outbound transfers of fewer than 100,000 individuals’ personal information; and cumulative outbound transfers of fewer than 10,000 individuals’ sensitive personal information. Failing any one of them forces the security-assessment route, and retrofitting is expensive. Volumes are counted cumulatively from 1 January of the current year under Arts. 7 and 8 of CAC Order No. 16, which supersede the “since 1 January of the preceding year” wording in Art. 4 of these Measures. Separately confirm that the export contains no important data: important data must go through the security assessment (Art. 37 of the Network Data Security Management Regulations). That is not one of the four Art. 4 conditions, but it must be ruled out before the route is chosen.

Evidence: Route-selection memo setting out the conclusion and basis for each of the four Art. 4 conditions; Statement on CIIO status, recording whether a designation notice was received; Counts of individuals processed and cumulatively transferred, with the counting methodology; Important-data determination showing the export contains no important data

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Open tool: Transfer Matrix

Art. 6 §1 requires the standard contract to be executed strictly in the form annexed to the Measures; §2 allows the parties to add other terms provided they do not conflict with the standard clauses; and §3 provides that the outbound transfer may only begin once the standard contract has taken effect. The CAC may adjust the annex, so confirm you are using the current version before signing. Note the sequencing in §3: sign, let the contract take effect, then transfer, then file within ten working days — the contract cannot be papered over while data is already moving.

Evidence: Executed standard contract including the signature pages and annexes; Note on the provenance of the template version used and the version check performed; Schedule of supplementary terms and a legal opinion that they do not conflict with the standard clauses; Evidence of the offshore recipient’s internal signing authority

Before the transfer, run a personal information protection impact assessment focused on the matters enumerated in Art. 5 of the Measures, produced together with the assessment required by PIPL Arts. 55–56. The report is filed alongside the standard contract and is the principal document examined in any subsequent supervisory check.

Evidence: Outbound transfer impact assessment report including an analysis of the recipient jurisdiction’s legal environment; Field-level inventory of the personal information transferred, with a minimisation and necessity justification; Due-diligence pack on the recipient’s security capability; Risk-mitigation measures arising from the assessment, with evidence of implementation

Personal Information Protection Impact Assessment (PIPIA) report

File with the provincial cyberspace authority within ten working days of the standard contract taking effect, submitting the contract and the impact assessment report among other materials. Where any circumstance listed in Art. 8 arises during the term, re-run the impact assessment, supplement or re-execute the standard contract, and complete the corresponding filing.

Evidence: Filing receipt or system submission record from the provincial authority, with the submission timestamp; Archived filing pack (standard contract plus impact assessment report); Timeline record comparing the contract effective date with the filing date to evidence the ten-working-day window; Trigger determinations and execution records for re-assessment and re-filing

Personal Information Protection Impact Assessment (PIPIA) reportOutbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Conduct pre-training, fine-tuning and other training-data processing lawfully: use data and foundation models from lawful sources; do not infringe others’ intellectual property rights; where personal information is involved, obtain the individual’s consent or rely on another statutory basis; take effective measures to improve training-data quality, strengthening its authenticity, accuracy, objectivity and diversity; and comply with the other requirements of the Cybersecurity Law, the Data Security Law, the Personal Information Protection Law and the supervisory requirements of the competent authorities.

Evidence: Training-data provenance register covering dataset name, source, acquisition method, licence or authorisation, and usage restrictions; Foundation-model licences and a compliance note comparing open-source licence terms against actual use; IP risk screening records (copyright, trade marks, database rights) and the removal list; Statement of the lawful basis for personal information in the corpus, with de-identification and cleaning records; Training-data quality evaluation report across authenticity, accuracy, objectivity and diversity

Filing pack for generative AI services and algorithm filing, including the security assessment reportData Card — datasheet for a training, validation or test dataset

Protect users’ inputs and usage records as required by law: do not collect unnecessary personal information; do not unlawfully retain inputs and usage records capable of identifying the user; and do not unlawfully provide users’ inputs and usage records to others. Promptly handle individuals’ requests to access, copy, correct, supplement or delete their personal information. This directly constrains the practice of feeding user conversations into training sets by default, which needs separate, revocable authorisation and a deletion path that actually works.

Evidence: Field inventory, retention periods and minimisation justification for inputs and usage records; Product evidence of a separate, revocable authorisation for using conversations in training; De-identification design for identity-revealing content and a technical verification report; End-to-end records showing rights requests executed across conversation logs, training sets and vector stores

Personal Information Protection Impact Assessment (PIPIA) report

On discovering unlawful content, promptly stop generation, stop transmission and remove it, remediate through measures such as model optimisation and retraining, and report to the competent authority. On discovering a user engaging in unlawful activity through the service, issue warnings, restrict features, or suspend or terminate the service under law and contract, retain the relevant records, and report to the competent authority. Also maintain a complaints and reporting mechanism with a convenient entry point, publish the handling process and response times, and deal with and respond to reports promptly.

Evidence: Content-safety review policy and the criteria for identifying unlawful content; Ticket log for unlawful content, recording detection time, action taken and completion time; Model remediation records: alignment data, safety fine-tuning, and before-and-after evaluation results; Records of reports to the competent authority and the receipts; Screenshots of the complaints entry point, the published process and response times, and the disposition log

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

A provider of generative AI services with public-opinion attributes or social-mobilisation capability must carry out a security assessment under the applicable national rules and complete algorithm filing, together with amendment and cancellation filings, under the Algorithmic Recommendation Provisions. Art. 24 of those Provisions sets the filing deadline at ten working days from the start of the service, and once filed the provider must display the filing number prominently on its website or application with a link to the published information. From 1 September 2025, filing and assessment submissions must also include the labelling materials required by Art. 12 of the Labelling Measures.

Evidence: Determination record and reasoning on public-opinion attributes or social-mobilisation capability; Security assessment report with submission and feedback records; Algorithm filing pack: provider name, service form, application field, algorithm type, algorithm self-assessment report and the content to be published; Screenshots showing the filing number and the link to published information in a prominent product location; Records of amendment and cancellation filings; The labelling documentation included in the filing and assessment submissions

Filing pack for generative AI services and algorithm filing, including the security assessment reportISO/IEC 42001 AI management system implementation and certification readiness checklistInvestor ESG due diligence pack (for fundraising and pre-IPO)

Providers must label generated images, video and similar content as required by the Deep Synthesis Provisions. From 1 September 2025 the method is set by the AI Content Labelling Measures and mandatory national standard GB 45438-2025: content falling within Art. 17 §1 of the Deep Synthesis Provisions requires an explicit label, and all generated and synthetic content requires an implicit label in the file metadata.

Evidence: Labelling design note covering explicit label placement and style and the implicit metadata fields; API documentation showing metadata carried in outputs, plus captured traffic or sample files; Labelled samples retained for each modality: text, image, audio, video and virtual scenes; Self-assessment records against GB 45438-2025

Filing pack for generative AI services and algorithm filing, including the security assessment report

Where data is annotated during technical development, adopt clear, specific and operable annotation rules that meet these Measures; run annotation quality evaluation with sampling checks on accuracy; and provide the necessary training to annotators to raise their awareness of legal compliance, supervising and guiding them in performing the work properly. Outsourcing annotation does not transfer these duties away from the provider.

Evidence: Annotation rulebook, including criteria for unlawful and harmful information and rules for handling discriminatory content; Sampling plan for annotation quality and successive evaluation reports, showing sampling rate, accuracy and rework records; Annotator training materials, attendance records and test results; Vendor qualification review, contract and oversight records for outsourced annotation

Filing pack for generative AI services and algorithm filing, including the security assessment reportData Card — datasheet for a training, validation or test dataset

Assume the responsibilities of a network information content producer and the duties of network information security, and where personal information is involved, the responsibilities of a personal information processor. Execute a service agreement with registered users that sets out both parties’ rights and obligations; state and publish the intended user groups, settings and uses of the service, guiding users towards an informed and lawful understanding of generative AI; and adopt effective measures to prevent minors from becoming over-reliant on, or addicted to, the service.

Evidence: User service agreement covering rights and obligations, usage limits and notice of labelling duties; Screenshots of the published statement of intended user groups, settings and uses; Design documentation and release evidence for anti-addiction measures (time limits, content grading, guardian controls); Captured screens for usage guidance and risk warnings

Filing pack for generative AI services and algorithm filing, including the security assessment report

Regulation 10.3.1 requires any system used in products, services or use cases that may affect a data subject, positively or negatively, to be designed to be Ethical (unbiased algorithmic decisions and data lineage, with bias mitigated), Fair (treat individuals equally, avoid or mitigate bias leading to unfair outcomes), Transparent (processing explainable to data subjects and stakeholders in non-technical terms with appropriate supporting evidence), Secure (personal data protected and confidential, preventing breaches causing reputational, psychological, financial or professional harm) and Accountable (internal governance and control frameworks or regular external audit enabling assessment of algorithms, data and design processes). Regulation 10.3.2 prohibits commercial use of any system unless it can process personal data only for human-defined or human-approved purposes — or for purposes it defines itself solely on the basis of human-defined principles and strictly within human-defined constraints — and is designed in compliance with 10.3.1 and any further audit and certification requirements the Commissioner establishes. Regulation 10.3.4 deems the Deployer a Controller and the Operator a Processor, so liability follows.

Evidence: Conformity note against the five design requirements and design review records; Bias and fairness test reports including data lineage analysis; Technical evidence of the purpose constraint (system prompts, tool allow-lists, purpose validation and refusal logic, logs); Internal governance framework or external audit report covering algorithms, data and design processes

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

Regulation 10.3.3 provides that no person may use, operate, provide, offer or otherwise make available for commercial use a system to engage in High Risk Processing Activities unless: the Commissioner has established audit and certification requirements for such systems; the system complies with all of them; the system processes personal data solely for human-defined or human-approved purposes; and the Deployer or Operator has appointed an Autonomous Systems Officer with the same or substantially similar competencies, status, role and tasks as a DPO under Articles 17 and 18 of the Law. The Regulation’s guidance note states the regulatory intent that no system may be used for High Risk Processing Activities until the Commissioner has promulgated those requirements. DIFC has published a Regulation 10 certification framework, an accelerator framework and a list of Accredited Certification Bodies, together with an online certification application and a self-assessment tool.

Evidence: High Risk Processing Activity determination and Regulation 10.3.3 applicability analysis; Regulation 10 certification application and the Accredited Certification Body’s conclusion; Autonomous Systems Officer appointment and role description, mapped to Articles 17 and 18; Technical evidence and audit trail that the system processes data only for human-defined or human-approved purposes

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

Article 14(7) requires controllers and processors to register with the Commissioner by filing a notification of processing operations and to keep it current through amended notifications; Article 14(8) puts the notification on a publicly available register and attaches a prescribed fee. Article 14(5) requires a written data protection policy proportionate to the extent and type of processing and consistent with the Law. Article 15 requires controllers and processors each to maintain a written record of processing activities, including categories of recipients, third countries and international organisations, documentation of safeguards for Article 27 transfers, erasure time limits by category, and a general description of technical and organisational security measures.

Evidence: Commissioner registration confirmation and the latest amended notification; Written data protection policy with version history and approval trail; Record of processing activities covering the Article 15(1) fields; Documentation of Article 27 transfer safeguards and its filing index

Article 16(2)(b) requires a DPO where a controller or processor performs High Risk Processing Activities on a systematic or regular basis (DIFC Bodies must also appoint one). An entity that is not required to appoint a DPO must, under Article 16(4), clearly allocate responsibility for data protection oversight and compliance within the organisation and be able to give the Commissioner the details of the responsible persons on request. The DPO may be a member of staff, a group employee, or a third party under a service contract; a group may share one DPO if easily accessible from each entity. Note Article 16(7): the DPO must reside in the UAE unless they are employed within the organisation’s Group and perform a similar function for the Group internationally — check that proviso before assigning the role to a China-based team remotely. Article 16(8) also requires the DPO’s contact details to be published so a third party can reach them without disproportionate effort, and the identity confirmed to the Commissioner in writing on request.

Evidence: High Risk Processing Activity determination memo, per business line, with reasoning; DPO appointment document or the Article 16(4) allocation-of-responsibility document; Note on the DPO’s independence and resourcing; Response template for providing responsible-person details to the Commissioner

Carry out a DPIA for high-risk processing under Article 20; where the assessment indicates that, despite the measures referred to in Article 20(6)(e), risks to data subjects’ rights remain, Article 21 requires the controller to consult the Commissioner before processing, and the Commissioner may notify the controller and processor and use the Article 46 powers if the processing would infringe the Law. Wire the DPIA into model evaluation, red-teaming and launch approval so assessments are never retrofitted after go-live.

Evidence: DPIA report and the list of mitigating measures; Prior consultation submission and the Commissioner’s response, where triggered; Model evaluation and red-team test reports; Launch approval record showing the DPIA conclusion as a gating condition

Article 26 permits transfers to third countries or international organisations that the Commissioner has determined provide an adequate level of protection; the Commissioner publishes and maintains that list by Regulations, and such transfers need no specific authorisation. Otherwise Article 27 applies: rely on the Article 27(2) safeguards (a legally binding instrument between public authorities, Binding Corporate Rules, standard data protection clauses adopted by the Commissioner, or an approved code of conduct or certification mechanism with binding and enforceable commitments), or an Article 27(3) derogation; only where neither is available does the limited Article 27(4) route apply, and Article 27(5) then requires the controller to inform the Commissioner of the transfer. The Commissioner’s site publishes the Article 26 adequacy list and the Article 27(2)(c) model clauses — always use the current version.

Evidence: Export register (recipient, location, data categories, Article 26 or 27 route relied on); Executed DIFC model clauses / standard contractual clauses or BCR approval; Record of the Article 27(5) notification to the Commissioner, where applicable; Review record against the Commissioner’s current adequacy list

Open tool: Transfer Matrix

Article 41 requires the controller to notify the Commissioner “as soon as practicable in the circumstances” of any personal data breach that compromises a data subject’s confidentiality, security or privacy, with at least the nature of the breach (including, where possible, the categories and approximate numbers of data subjects and records), the DPO or other contact point, the likely consequences, and the measures taken or proposed; information may be provided in phases. A processor must notify the relevant controller without undue delay. Article 42 requires communication to affected data subjects as soon as practicable where the breach is likely to result in a high risk to their security or rights, and prompt communication where there is an immediate risk of damage; the communication must be in clear and plain language and contain at least Articles 41(4)(b)–(d), with mitigation recommendations where possible. Article 41(6) requires a written record of all breaches, their effects and remedial action, available to the Commissioner without delay on request.

Evidence: Breach response plan and Commissioner notification template aligned to the four elements of Article 41(4); Written breach register recording facts, effects and remedial action; Data subject communication text and proof of delivery; Timing records for processor-to-controller notifications

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

A data subject has the right to object to any decision based solely on automated processing, including profiling, which produces legal consequences or other seriously impactful consequences, and to require manual review. The Article 38(2) exceptions are: necessity for entering into or performing a contract between the data subject and the controller; authorisation by applicable law that also lays down suitable safeguards; or the data subject’s explicit consent. Where the controller relies on contract necessity or explicit consent, Article 38(5) requires suitable safeguards including, at minimum, the ability for the processing to be reviewed manually. Article 38(4) disapplies all the exceptions where the data subject is a minor by reference to the UAE age of majority. Article 38(6) further bars decisions affecting a data subject based solely on automated processing of special category data unless explicit consent is given or the processing is necessary for reasons of substantial public interest on the basis of applicable law, proportionate, and accompanied by suitable safeguards.

Evidence: Automated decision inventory with legal analysis of the exception relied on; Manual review procedure and sample review records; Age assurance / minor routing mechanism description and test records; Lawfulness reasoning and safeguards list for automated decisions on special category data

Where an application or website service uses autonomous or semi-autonomous systems to process personal data, the Deployer or Operator must, on first use of or access to the system, give notice in clear and explicit terms of the underlying technology and processes that may process personal data in ways that are not human-initiated, controlled or directed (for example whether the system is restricted to specific human-defined purposes or can define further purposes itself), and of the impact of using the system on the exercise of individual rights under Article 29(1)(h)(ix). The notice must also give a comprehensive, true and plain description of: the human-defined purposes for which the system processes personal data; all human-defined principles and limits within which the system may define further purposes; the output produced and how it is used; the principles on which the system was designed to operate, including safeguards built in by design; and the codes, certifications or principles the system was designed or developed to — the Regulation names the Dubai Digital Authority, the OECD, UNESCO, the NIST AI Framework and the Guidelines for Financial Institutions adopting Enabling Technologies issued by the UAE Central Bank, the Securities and Commodities Authority, the DFSA and the FSRA as examples, and lets the Commissioner designate further codes and certifications.

Evidence: Final first-use notice copy and screenshots of where it is shown; System description (human-defined purposes, principles and limits for self-defined purposes, outputs and their use); Inventory of safeguards built in by design and evidence of implementation; List of codes/certifications relied on (for example OECD, NIST AI RMF, UNESCO, Central Bank or DFSA guidelines)

Model Card

Section 12.1 requires an enterprise that uses personal information to render a decision based exclusively on automated processing to inform the person accordingly no later than when it informs them of the decision, and on request to inform them of (i) the personal information used, (ii) the reasons and the principal factors and parameters that led to the decision, and (iii) their right to have the personal information used to render the decision corrected. It must also give the person the opportunity to submit observations to a member of personnel in a position to review the decision. Engineering implications: an explanation layer that maps model output onto principal factors and parameters; retention of the input snapshot at decision time so correction requests can be honoured; and a human ticket path that delivers observations to someone with authority to review.

Evidence: Inventory of solely automated decisions and the notice copy (French and English); Sample explanation output for the reasons, principal factors and parameters, with the method used to generate it; Retention policy for decision-time input snapshots and evidence of retrieval; Observation intake and human review ticket records, evidencing the reviewer’s authority

Section 17 requires a privacy impact assessment before communicating personal information outside Québec, taking into account in particular the sensitivity of the information, the purposes for which it is to be used, the protection measures including contractual ones that would apply, and the legal framework applicable in the destination State including the personal information protection principles applicable there. The information may be communicated only if the assessment establishes it would receive adequate protection, in particular in light of generally recognised principles, and the communication must be the subject of a written agreement that takes into account, in particular, the assessment results and any agreed terms to mitigate the identified risks. The same applies where a person or body outside Québec is entrusted with collecting, using, communicating or keeping the information. “Outside Québec” includes other Canadian provinces. The closing paragraph of section 17 disapplies it only to a communication under subparagraph 7 of the first paragraph of section 18 (one of the consent-free communication cases); there is no other carve-out.

Evidence: Section 17 privacy impact assessment covering the four statutory factors; Analysis of the destination’s legal framework, benchmarked against its personal information protection principles; Executed written agreement reflecting the assessment conclusions and mitigation terms; Transfer register and periodic re-assessment records triggered by changes of recipient or legal environment

Open tool: Transfer Matrix

Section 3.5 requires a person carrying on an enterprise who has cause to believe a confidentiality incident involving personal information they hold has occurred to take reasonable measures to reduce the risk of injury and prevent recurrence; where the incident presents a risk of serious injury, to promptly notify the Commission d’accès à l’information and each person whose personal information is concerned (failing which the Commission may order notification); and permits notifying any person or body that could reduce the risk, communicating only the personal information necessary, in which case the person in charge of the protection of personal information must record that communication. Section 3.7 requires the risk assessment to consider in particular the sensitivity of the information, the anticipated consequences of its use and the likelihood it will be used for injurious purposes, in consultation with the person in charge. Section 3.8 requires a register of confidentiality incidents, whose content may be determined by government regulation.

Evidence: Register of confidentiality incidents with the fields required by regulation; Serious-injury risk assessments, evidencing consultation with the person in charge; Notification texts to the Commission and to individuals, with proof of delivery; Records of communications to third parties able to reduce the risk, documenting the minimisation

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

Section 3.3 requires a privacy impact assessment for any project to acquire, develop or overhaul an information system or electronic service delivery system involving the collection, use, communication, keeping or destruction of personal information — introducing or re-architecting AI capability (model integration, vector retrieval, voice or image processing) normally falls squarely within “overhaul an information system”. Section 3.1 makes the person carrying on an enterprise responsible for protecting the personal information they hold. Section 8.2 requires anyone who collects personal information through technological means to publish a confidentiality policy drafted in clear and simple language on the enterprise’s website, if applicable, and to disseminate it by any appropriate means, and to do the same for notice of any amendment.

Evidence: Privacy impact assessment files and conclusions, organised by project; Project initiation and assessment trigger records for AI introduction or re-architecture; Published French-language confidentiality policy versions and amendment notices; Records of the person in charge’s involvement in and sign-off on the assessments

Section 27 requires an enterprise, on request, to confirm the existence of the personal information it holds about a person, communicate it and allow them to obtain a copy; at the applicant’s request, computerised personal information must be communicated as a written and intelligible transcript. From 22 September 2024, unless doing so raises serious practical difficulties, computerised personal information collected from the applicant and not created or inferred using personal information concerning them must, on request, be communicated in a structured, commonly used technological format and also communicated to any person or body authorised by law to collect it. Where the applicant is handicapped, reasonable accommodation must be provided on request. Section 28 adds the right to require rectification where the information is inaccurate, incomplete or equivocal, or where its collection, communication or keeping is not authorised by law. AI companies should define in advance the boundary of “created or inferred” information — inferred profile labels, embeddings and scores are usually outside the portability scope, but the reasoning must be documented.

Evidence: Access and portability request procedure with turnaround records; Documented classification between information collected from the applicant and information created or inferred; Structured export format specification and sample exports; Reasoning for refusals or partial refusals, including any “serious practical difficulties” analysis

For an activity on the managed list, after clearing the committee’s initial review the entity applies to its local or sector authority to organise an expert re-review; where several entities participate, the lead entity consolidates the application. The submission comprises the Art. 9 materials, the committee’s initial opinion and anything else the organising body requires. The expert panel issues an agree or disagree opinion requiring at least a two-thirds majority of all panel experts; the local or sector authority should normally respond within 30 days of receiving the application; and the entity’s committee then makes its review decision in light of that opinion. The list is published and dynamically adjusted by MOST, and its three AI-relevant items are: research and development of human-machine integrated systems with a strong influence on human subjective behaviour, psychological emotions and life and health; research and development of algorithmic models, applications and systems capable of mobilising public opinion and society and guiding social consciousness; and research and development of highly autonomous automated decision systems for scenarios involving safety or personal-health risks.

Evidence: Determination records mapping each R&D project against the seven annexed items; The committee’s initial review opinion; Re-review application submitted to the local or sector authority and the acceptance record; The expert panel’s written opinion and voting record; The final review decision made in light of that opinion, with records of any required changes; Monitoring records for MOST’s dynamic adjustments to the list

An entity engaged in life sciences, medicine, artificial intelligence or similar activities whose research touches ethically sensitive areas must establish a science and technology ethics (review) committee. The entity must provide the committee with the necessary staff, premises and funding, and take effective measures to secure its independence. The committee’s duties include adopting management systems and working rules; providing ethics advice and guiding risk assessment; conducting reviews and monitoring the activity throughout; determining whether an activity falls within the Art. 25 list; organising training for members and researchers; receiving and assisting in investigating complaints; and completing the registration and reporting required by Arts. 43–45.

Evidence: Resolution establishing the ethics committee, the member roster and terms of appointment; Committee charter, management systems and working rules; Description of the independence safeguards: staffing, premises, funding and recusal rules; Ethics training records and test results for members and researchers; Note recording the joint build with the ethics-review systems required by the Deep Synthesis and Algorithmic Recommendation rules

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

Every science and technology activity requires an ethics risk assessment. Where the assessment places it within Art. 2, the activity lead applies to the ethics committee, submitting: an overview (name, purpose, significance, necessity and prior review history); the implementation plan and supporting materials, including the potential ethical risks with controls and a contingency plan, and how results will be published; the participating institutions’ qualifications, the researchers’ experience and ethics training, the funding source and conflict-of-interest declarations; the informed-consent form and documentation on the provenance of biological samples, data and laboratory animals; an undertaking to observe research ethics and integrity; and any other material the committee requires. The committee reviews against the seven focus areas in Art. 15, and a decision requires the agreement of at least two-thirds of the members present.

Evidence: The entity’s ethics risk assessment methodology and the per-project assessment records; Complete review application pack, including the informed-consent form, provenance documentation for data and samples, conflict-of-interest declarations and the integrity undertaking; Committee meeting minutes and voting records evidencing the two-thirds majority; The review decision (approved, approved subject to modification, re-review after modification, or refused) and evidence that required modifications were made; Assessment conclusions on algorithmic fairness, reliability and controllability corresponding to Art. 15(5)

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

By 31 March each year, the entity must submit to the national science and technology ethics management information platform the previous year’s report of its ethics committee and reports on the implementation of any listed activities. This is a hard annual deadline, and the reports feed into subsequent inspections and eligibility for research funding.

Evidence: The ethics committee’s annual work report for the previous year; Implementation reports for any activities under list management; Submission records and receipts from the national ethics management information platform; Archived annual reports and the internal approval records

Build an inventory of outbound flows and triage each one. Flows within Art. 7 — a CIIO transferring personal information or important data; a non-CIIO transferring important data, or cumulatively transferring since 1 January of the current year the personal information of more than 1 million individuals (excluding sensitive data) or the sensitive personal information of more than 10,000 individuals — must go through the security assessment. Flows within the Art. 8 band — a non-CIIO cumulatively transferring since 1 January of the current year the personal information of at least 100,000 but fewer than 1 million individuals (excluding sensitive data), or the sensitive personal information of fewer than 10,000 individuals — must use the standard contract or certification. Volumes are counted cumulatively from 1 January of the current year, so the count must be tracked on a rolling monthly basis rather than assessed transfer by transfer.

Evidence: Inventory of outbound flows covering scenario, recipient, data categories, and whether sensitive personal information or important data is involved; Rolling monthly counts of cumulative individuals transferred, with the counting methodology; Route determination for each flow (assessment, standard contract, certification or exemption) and the article relied on; Description of the threshold-proximity alerting mechanism and the alerts raised

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Open tool: Transfer Matrix

A processor transferring personal information abroad must perform the statutory duties of notice, obtaining separate consent and running a personal information protection impact assessment. These three duties sit outside the threshold triage: even where a flow is exempt under Arts. 3–6, if personal information leaves the country the separate consent in PIPL Art. 39 and the impact assessment in PIPL Art. 55 still apply, unless another statutory basis displaces consent. The processor must also discharge its data-security duties and, where a data-security incident occurs or may occur, take remedial measures and report promptly to the provincial or higher cyberspace authority and other competent departments.

Evidence: Text of the transfer-specific notice and evidence of how it is displayed; Separate-consent logs for the transfer, kept apart from general consent records; Personal information protection impact assessment report and evidence of three-year archiving; Incident reports for outbound data-security events and the receipts from the provincial or higher cyberspace authority

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)Personal Information Protection Impact Assessment (PIPIA) report

Where you rely on Art. 3 (data collected or generated in international trade, cross-border transport, academic cooperation, transnational manufacturing or marketing that contains no personal information or important data), Art. 4 (personal information collected abroad, transmitted into China for processing and then sent back out without introducing domestic personal information or important data), or any of the four cases in Art. 5 (a contract to which the individual is a party; cross-border HR management; an emergency to protect a natural person’s life, health or property; and a non-CIIO that has cumulatively transferred fewer than 100,000 individuals’ personal information, excluding sensitive data, since 1 January of the current year), produce a written justification at the time of the decision stating the limb relied on, the factual basis and the boundary conditions. Exemptions are self-determined rather than approved, so the burden of proof sits with the business if a regulator challenges them.

Evidence: Written exemption justification per scenario, naming the limb, the factual basis, the boundary conditions and the review cycle; Field-level inventory and technical verification evidence supporting “contains no personal information or important data”; For Art. 4, evidence of the offshore origin of the data and a description of the processing chain showing no domestic personal information or important data was introduced; For Art. 5(2), the lawfully adopted labour rules and the lawfully concluded collective contract; Re-determination records where the basis for the exemption changed

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Open tool: Transfer Matrix

Processors must identify and declare important data under the applicable rules. Where the relevant authority or region has not notified the processor, and has not publicly designated the data as important, the processor need not declare it as important data in an outbound security assessment. The rule leaves the final designation with the authorities, but the processor must still carry out and document the identification exercise; once notified or publicly listed, the outbound transfer of that data goes unconditionally through the security assessment route (Art. 37 of the Network Data Security Management Regulations).

Evidence: Working papers for the important-data identification, recording method, reviewers and conclusion date; Records of monitoring the sector and regional important-data catalogues; Archived copies of any notification from the authority or public designation received; Contingency plan for switching the outbound route if a designation is made

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Within the national data classification and grading framework, a free-trade zone may draw up its own list of data that must go through the security assessment, standard contract or certification (a negative list), approved by the provincial cybersecurity and informatisation commission and filed with the CAC and the national data administration. A processor inside the zone transferring data that is not on the negative list is exempt from the assessment, standard contract and certification. Site selection and entity structuring should take this into account, and the target zone should be checked for whether a list has been published and which sectors it covers.

Evidence: Text of the target zone’s negative list and a note on its approval and filing status; Item-by-item comparison of the company’s data against the negative list; Registration and operating evidence for the in-zone entity, showing processing genuinely occurs inside the zone; Monitoring mechanism and review records for updates to the list

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Open tool: Transfer Matrix

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

Before putting any dataset into pre-training or fine-tuning, determine whether it contains personal information — particularly where the provenance is unclear — and comply with the resulting obligations; public availability or accessibility is not itself a lawful basis. Additional steps such as deleting information may be needed. Collection must also respect the APP 3 necessity limit: collect only personal information reasonably necessary for the entity’s functions or activities, draft appropriate parameters for what is included when compiling a generative AI dataset, and implement mechanisms to filter out unnecessary personal information.

Evidence: Assessment of the personal information content of each dataset; Documented inclusion parameters and filtering rules; Deletion or de-identification execution records; Due diligence conclusions on data of unclear provenance

Data Card — datasheet for a training, validation or test dataset

OAIC states that sensitive information generally requires consent to be collected, and that many photographs or recordings of individuals, including artificially generated ones, contain sensitive information and therefore may not be scraped from the web or collected from a third-party dataset without establishing consent. Companies planning to train face, portrait or voice models must build the consent-chain check into dataset construction rather than remediate before launch.

Evidence: Sensitive-information screening reports for image and audio datasets; Consent-chain verification records, including consent evidence from third-party dataset suppliers; Exclusion or deletion records where consent could not be established; Legal review of the intended use of images of people

Where personal information already held is to be used to train an AI model and that was not a primary purpose of collection, confirm whether consent for that secondary AI-related purpose exists; if not, establish that the secondary use would be reasonably expected by the individual, taking particular account of their expectations at the time of collection, and that it is related — directly related for sensitive information — to the primary purpose, or that another exception applies. Where that cannot be clearly established, seek consent for the use and/or offer a meaningful and informed opt-out to avoid regulatory risk.

Evidence: Secondary-purpose assessment addressing both reasonable expectation and relatedness; The notice given at original collection and evidence of user expectations, including historical privacy policy versions; Implementation and execution records for the consent or opt-out mechanism; A separate record of the direct-relatedness determination for sensitive information

Data Card — datasheet for a training, validation or test dataset

OAIC notes that generative AI models are probabilistic, do not understand the data they handle or generate, and are known to produce inaccurate or false results. Under APP 10, developers must take reasonable steps to ensure the personal information collected, used and disclosed is accurate, commensurate with the likely increased level of risk in an AI context, including using high-quality datasets, undertaking appropriate testing and the appropriate use of disclaimers. Disclaimers should clearly communicate the limitations of accuracy, including whether the dataset only includes information up to a certain date, and should signal where careful consideration and additional safeguards are needed for high privacy risk uses, such as decisions with a legal or similarly significant effect on an individual’s rights.

Evidence: Dataset quality control and provenance assessment records; Accuracy testing plan and results, including factual outputs about individuals; Disclaimer text and screenshots of where it appears, including the data cut-off statement; List of high privacy risk uses and the additional safeguards applied

When using commercially available AI products — third-party model APIs, SaaS and freely available chatbots included — OAIC’s use guidance requires five things. First, privacy obligations apply to any personal information input into an AI system and to output data generated by AI where it contains personal information, so due diligence at selection must consider whether the product has been tested for the intended uses, how human oversight can be embedded, the privacy and security risks, and who will have access to the personal information input or generated. Second, update privacy policies and notifications with clear and transparent information about the entity’s use of AI, ensure public-facing AI tools such as chatbots are clearly identified as AI to external users, and establish policies and procedures for AI use. Third, using AI to generate or infer personal information, including images, is a collection under APP 3 and must be reasonably necessary for the entity’s functions or activities and done by lawful and fair means — inferred, incorrect or artificially generated information produced by AI models, including hallucinations and deepfakes, is personal information where it is about an identified or reasonably identifiable individual. Fourth, where personal information is input into an AI system, APP 6 permits use only for the primary purpose of collection unless there is consent or the secondary use is within the individual’s reasonable expectations and related — directly related for sensitive information — to the primary purpose. Fifth, as best practice OAIC recommends that organisations do not enter personal information, and particularly sensitive information, into publicly available generative AI tools. This dovetails with the APP 1.7 automated-decision disclosure duty applying from 10 December 2026: general AI transparency first, then the statutory disclosure item for automated decisions.

Evidence: Privacy due diligence records for commercial AI vendors; Internal policy and training records on permitted uses and prohibited input data types; The AI-use paragraphs in the updated privacy policy; Approval records and logs for employee use of AI tools; Mapping to the APP 1.7 disclosure requirement and the update plan

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

Exporting a dual-use item requires an individual licence, a general licence or a registration-based export voucher. An individual licence application is made to MOFCOM in writing or by electronic message, with a truthful application form and the prescribed materials; MOFCOM grants or refuses within 45 working days of acceptance. The exporter must export within the scope, conditions and validity stated on the licence and report the actual shipment, arrival, installation and use. The licence must be presented to Customs on export, and without it Customs will not release the goods.

Evidence: Archived dual-use export application form and the complete submission pack; Register of licences with their scope, conditions and validity periods; Reports on actual shipment, arrival, installation and use; Customs presentation records and release documentation; Per-shipment reconciliation between the licence scope and what actually shipped

An application for a dual-use export licence must include an end-user and end-use certificate issued by the end user, and MOFCOM may additionally require a certificate issued or authenticated by a government body in the end user’s jurisdiction. MOFCOM operates a risk-management regime for end users and end uses, assessing and verifying them; where an importer or end user fails to cooperate with verification or provide supporting materials within the prescribed period, so that verification is impossible, MOFCOM may place it on the watch list.

Evidence: Original end-user and end-use certificate from the end user, with translation; Certificate issued or authenticated by a government body in the end user’s jurisdiction, where required; End-user penetration checks covering ownership, ultimate controller, nature of business and compliance history; Distributor contract clauses requiring end-user declaration and restricting onward transfer; Correspondence evidencing cooperation with MOFCOM verification

An exporter or importer that discovers any of the situations listed in Art. 25 must stop the export immediately, report to MOFCOM and cooperate with verification. An exporter that discovers, or is notified by MOFCOM of, a situation under Art. 14 §3, Art. 18 §4 or Art. 25 must report promptly, take the required measures to eliminate or mitigate the harm, and cooperate with the investigation. In addition, operators providing agency, freight, delivery, customs-clearance, third-party e-commerce platform or financial services that discover a suspected export-control violation must report it promptly to MOFCOM (Art. 36).

Evidence: Documented procedure for identifying risk situations and stopping shipments, including a freeze and interception runbook; Execution records for stopping exports, with timestamp, order number and operator; Text of the report to MOFCOM and the receipt; Materials submitted in cooperation with verification and the outcome; Records of notifying and training service providers on their reporting duty

PRC citizens, legal persons and unincorporated organisations that receive a foreign-government request for an export-control-related visit or on-site inspection must report it immediately to MOFCOM, and must not accept or undertake to accept such a visit or inspection without MOFCOM’s consent. Together with the data-blocking rule in Art. 36 of the Data Security Law this forms a pair of blocking duties and should be handled through a single “foreign authority request” procedure.

Evidence: Intake register for foreign-government and offshore-institution requests, recording date, requester, subject and scope; Text of the report to MOFCOM and the receipt; Archived MOFCOM decision granting or refusing consent; The combined foreign-request handling procedure designed jointly with Art. 36 of the Data Security Law; Negotiation records and reservations logged against export-control audit clauses in customer contracts

Properly retain end-user and end-use certificates together with contracts, invoices, ledgers, documents and business correspondence relating to dual-use exports for at least five years, unless another law or administrative regulation provides otherwise. Separately, MOFCOM issues a dual-use export-control compliance guideline and encourages exporters, and the freight, third-party e-commerce and financial service providers serving them, to build sound internal export-control compliance programmes (Art. 6). Such a programme is in practice the precondition for facilitation measures such as general licences and registration-based export vouchers.

Evidence: Internal export-control compliance programme covering governance, classification, list screening, licence management, audit, training and whistleblowing; Appointment of the compliance officer and training records; Archive index for export records and screenshots of the five-year retention configuration; Internal compliance audit reports and remediation records; Compliance-programme evidence submitted when applying for a general licence or registration-based export voucher

Network products and services must meet the mandatory requirements of the relevant national standards; on discovering a security defect, vulnerability or similar risk, the processor must take remedial action immediately, inform users and report to the competent authority as required, and where national security or the public interest is endangered, must additionally report to the competent authority within 24 hours.

Evidence: Severity taxonomy for vulnerabilities and defects, stating which cases trigger the 24-hour report; Template and channel documentation for the 24-hour report; Actual filing records and receipts with timestamps; Text of the user notification and its publication record

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

An outbound transfer of personal information must satisfy one of the eight bases in Art. 35: passing the outbound data security assessment; certification by an accredited body; compliance with the standard-contract rules; genuine necessity to conclude or perform a contract to which the individual is a party; genuine necessity for cross-border HR management under lawfully adopted labour rules and a collective contract; genuine necessity to perform a statutory duty or obligation; genuine necessity in an emergency to protect a natural person’s life, health or property; and any other condition set by law, administrative regulation or the CAC. Important data is governed instead by Art. 37: where it genuinely needs to go abroad, it must pass the outbound data security assessment.

Evidence: Inventory of outbound transfer scenarios, each tagged with the Art. 35 limb relied on; Completion evidence for the route chosen (assessment approval, certification certificate or standard-contract filing receipt), or the documented basis for an exemption; Security assessment application and approval for any important data going abroad; Reconciliation records showing the actual transfer stays within the assessed scope (Art. 38)

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)Personal Information Protection Impact Assessment (PIPIA) report

Open tool: Transfer Matrix

Where personal information or important data is provided to, or entrusted for processing by, another processor, the parties must agree by contract on the purpose, method and scope of processing and the security obligations, and the provider must supervise the recipient’s performance; records of the processing must be kept for at least three years.

Evidence: Data processing agreement template and the register of executed versions; Description of the recipient-oversight mechanism, with questionnaires, audits or spot-check records; Register of provisions and entrustments recording recipient, data scope, date and purpose; Archive and retrieval evidence demonstrating the three-year retention

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

A network data processor providing generative AI services must strengthen the security management of training data and training-data processing, and take effective measures to prevent and handle network data security risks. In practice this covers the lawfulness of corpus sources, the compliance of collection methods (Art. 18 separately requires an impact assessment for automated tools and prohibits interfering with others’ network services), the scrubbing of personal and sensitive information from corpora, access control over training and inference environments, and classification and grading of the corpus store.

Evidence: Training-corpus register recording source, licence or authorisation, collection method and cleaning rules; Impact assessment for automated collection tools and a note on robots-policy compliance; Detection and removal plan for personal and sensitive information in corpora, with sampling results; Access-control matrix and audit logs for training and inference environments

Filing pack for generative AI services and algorithm filing, including the security assessment reportData Card — datasheet for a training, validation or test dataset

An offshore network data processor handling the personal information of natural persons in China that establishes a dedicated PRC entity or appoints a PRC representative under PIPL Art. 53 must report the entity’s name or the representative’s name and contact details to the municipal cyberspace authority where it is located.

Evidence: Incorporation documents for the PRC entity or the letter of appointment for the PRC representative; Filing materials submitted to the municipal cyberspace authority and the receipt; Terms of reference and scope of authority for the PRC representative; Updated filings after any change of entity or contact details

A processor handling more than 10 million individuals’ personal information must also comply with Arts. 30 and 32, which apply to important-data processors: designate a network data security officer and a network data security management body, with the officer drawn from management and empowered to report directly to the authority; the management body owns the policies and incident plans, periodic risk monitoring, assessment, drills and training, and the complaints channel; and where a merger, division, dissolution or bankruptcy may affect data security, the disposal plan and the recipient’s details must be reported to a provincial-level or higher authority.

Evidence: Methodology note and quarterly counts for individuals whose data is processed; Appointment letter for the network data security officer showing management-level status, and the direct-reporting channel; Terms of reference for the network data security management body and minutes of its regular meetings; Records of risk monitoring, assessments, drills and training; Reporting materials and receipts for major corporate changes, where applicable

Where notice is given through a processing rule, that rule must be displayed centrally, be easy to access, sit in a prominent position, and be specific and plain. For qualifying portability requests, the processor must provide a route for another processor named by the individual to access and obtain the data. Where automated collection unavoidably captures unnecessary personal information or data for which consent was not lawfully obtained, and where a user closes an account, the data must be deleted or anonymised; where a statutory retention period has not expired or deletion is technically infeasible, all processing other than storage and necessary security measures must stop.

Evidence: Screenshots of the processing-rules page evidencing centralised, prominent and accessible display; Intake workflow and interface documentation for portability requests; Technical approach and execution records for identifying and deleting or anonymising unnecessary personal information; Verification report on data erasure following account closure

Covered transactions include acquiring an equity or contingent equity interest in a covered foreign person; providing debt financing with equity-like rights; converting a contingent equity interest acquired on or after 2025-01-02; acquiring, leasing or developing operations, land, property or assets in a country of concern that will result in the establishment of a covered foreign person or the engagement of a country-of-concern person in a covered activity; entering a joint venture, wherever located, with a country-of-concern person that will engage in a covered activity; and acquiring a limited partner interest in a non-U.S. fund that the U.S. person knows likely will invest in a country-of-concern person in the semiconductor and microelectronics, quantum information technology or artificial intelligence sectors.

Evidence: Transaction structure chart and covered-transaction determination memo citing the paragraphs of § 850.210; Description of the target activities mapped against the § 850.217 and § 850.224 lists; Investment-scope description and fund undertakings for limited partner interests; Approval record for the determination signed by legal and compliance

Two AI triggers make a transaction prohibited: developing an AI system designed to be exclusively used for, or intended by the covered foreign person to be used for, any military end use or government intelligence or mass-surveillance end use; and developing an AI system trained using more than 10 to the power of 25 computational operations, or more than 10 to the power of 24 computational operations using primarily biological sequence data. Chip-side prohibited activities include EDA software, front-end semiconductor fabrication equipment, volume advanced packaging equipment, EUV-dedicated items, designing integrated circuits meeting or exceeding ECCN 3A090.a, fabricating logic on non-planar transistor architectures or at 16/14 nm or below, NAND with 128 or more layers, DRAM at 18 nm half-pitch or below, gallium-based compound semiconductors, graphene or carbon nanotube circuits, circuits designed to operate at or below 4.5 Kelvin, and specified supercomputer and quantum computing activities.

Evidence: Training compute accounting with a stated methodology distinguishing pre-training, fine-tuning and reinforcement learning; Training data composition statement addressing whether biological sequence data predominates; Product end-use statement and exclusion undertakings for military and intelligence uses; Technical file recording chip design parameters and process nodes

A U.S. person undertaking a notifiable transaction must file with Treasury no later than 30 calendar days after the completion date, following the electronic filing instructions on the Outbound Investment Security Program website, with the content required by § 850.405 and the certification in § 850.203. A U.S. person must also file for notifiable transactions of its controlled foreign entities, and must file within 30 calendar days of acquiring post-closing actual knowledge of facts that would have made the transaction covered. AI-side notifiable triggers include developing an AI system trained using more than 10 to the power of 23 computational operations, and AI systems intended for cybersecurity applications, digital forensics tools, penetration testing tools or the control of robotic systems.

Evidence: Memo establishing the completion date; Notification working papers and the electronic filing receipt; Certification signed by the chief executive officer or a duly authorized designee; Internal log of post-closing knowledge events and evidence of filing within 30 days

In assessing whether a U.S. person knew a fact, Treasury considers what the person had or could have had through a reasonable and diligent inquiry at the time of the transaction, including the questions asked of the target or counterparty, the contractual representations and warranties obtained or attempted, efforts to obtain and consider non-public information, available public information and its consistency with other information, whether the person purposefully avoided learning relevant information, the presence or absence of warning signs such as evasive or non-responses or refusal to provide information or warranties, and the use of public and commercial databases. A person that failed to conduct such an inquiry may be assessed to have had reason to know.

Evidence: Diligence questionnaire and the original responses from the target; Text of the representations and warranties in the transaction documents; Search records from public and commercial databases; Memo identifying warning signs and how they were resolved

A U.S. person must take all reasonable steps to prohibit and prevent transactions by its controlled foreign entities that would be prohibited if undertaken by a U.S. person. Treasury considers compliance agreements with the controlled foreign entity, the existence and exercise of governance or shareholder rights, periodic training and internal reporting, documented internal controls that are periodically reviewed, and a documented testing or auditing process. Separately, a U.S. person may not knowingly direct a transaction by a non-U.S. person that would be prohibited if undertaken by a U.S. person. A U.S. officer or director can avoid being treated as directing by recusing from formal approval and decision-making, from reviewing, editing, commenting on, approving and signing transaction documents, and from negotiations.

Evidence: Compliance agreements executed with controlled foreign entities; Internal control documents, periodic review records and testing or audit reports; Records of training and internal reporting mechanisms; Recusal statements by U.S. directors or officers, corroborated by meeting minutes

Before procuring, deploying or supplying any item, determine its Export Control Classification Number. The most relevant entries for AI companies are advanced computing chips and electronic assemblies (3A090, 4A090 and the .z paragraphs of 3A001, 4A003, 4A004, 4A005, 5A002, 5A004 and 5A992), the associated software and technology (3D001, 3E001, 4D001, 4D090, 4E001 and others), high bandwidth memory (3A090.c), specified semiconductor manufacturing equipment (3B001, 3B002 and others) and AI model weights (4E091). Classification conclusions must be documented and refreshed as items change.

Evidence: Item classification register recording ECCN, rationale, determiner and date; Written ECCN notifications furnished by suppliers; Compute-usage record for model weights and the 4E091 determination memo; Reclassification records triggered by product or model version changes

License requirements sit in section 742.6(a) and license review policy sits in section 742.6(b); the two paragraph numbers run independently and must not be conflated. Requirements: a worldwide license requirement applies to top-tier items such as 3A090.a and 4A090.a (section 742.6(a)(6)(iii)(A)); for second-tier items such as 3A090.b a license is required for the UAE and Country Groups D:1, D:4 and D:5, excluding destinations also in A:5 or A:6 (subparagraph (B)); and separate requirements cover specified semiconductor manufacturing equipment and high bandwidth memory (3A090.c) to or within Macau and Country Group D:5 (section 742.6(a)(6)(i)). Review policy in section 742.6(b)(10) is tiered: for 3A090.c there is a presumption of approval for entities not headquartered in Macau or D:5 and a presumption of denial otherwise; for commodities within section 742.6(a)(6)(iii) exported to end users located in China or Macau there is case-by-case review where total processing performance is below 21,000 and total DRAM bandwidth below 6,500 GB/s and the applicant supplies the additional information in supplement no. 2 to part 748 under paragraph (dd), with a presumption of denial otherwise. Applications for 4E091 model weights are reviewed under section 742.6(b)(14) with a presumption of denial for end users headquartered outside the destinations in paragraph (a) of supplement no. 5 to part 740.

Evidence: Per-transaction licensing memo covering destination, country group, end-user headquarters and ultimate parent; BIS license applications and the approvals or denials received; Working papers computing total processing performance and total DRAM bandwidth; End-user and end-use statements including re-export control undertakings

AI model weights specified in ECCN 4E091 require a license for export, reexport or in-country transfer to any destination worldwide. The requirement does not apply to deemed exports or deemed reexports to permanent regular employees of entities headquartered, or with an ultimate parent headquartered, in a destination listed in paragraph (a) of supplement no. 5 to part 740. License Exception AIA (§ 740.27) can authorize model weights only under strict conditions: the receiving entities must be located outside Macau and Country Group D:5, and the weights must be stored in a facility that complies with paragraphs 14, 15 and 18 of supplement no. 10 to part 748. A foreign-produced 4E091 item includes any item further trained or modified by fine-tuning, quantization or other post-training techniques.

Evidence: Training compute-usage records and the 4E091 determination memo; Inventory of weight storage locations and access controls with facility security compliance evidence; Records of License Exception AIA use, including the written notice to the ultimate consignee; Access audit logs for the weights repository covering onshore and offshore personnel

Even an item manufactured entirely outside the United States falls under the EAR if it meets both the product scope and destination scope of an FDP rule. The advanced computing FDP rule (§ 734.9(h)) covers two situations: foreign-produced items that are the direct product of U.S.-controlled technology or software such as 3D001, 3E001, 4D001, 4D090, 4E001, 5D002 or 5E002; and items produced by a complete plant or major component of a plant that is itself a direct product of U.S. technology or software. In both cases the item must also be specified in 3A090, 4A090 or the corresponding .z entries. The AI model weights FDP rule (§ 734.9(l)) has a worldwide destination scope. The Entity List FDP rules (§ 734.9(e)) add separate footnote 1, footnote 4 and footnote 5 provisions.

Evidence: FDP applicability memo addressing product scope and destination scope item by item; Technology-origin statements from offshore foundries and cloud providers; Supply-chain map annotating each node with item ECCN and the origin of the production tooling; Legal opinions or records of BIS advisory opinion requests where obtained

A license is required, to the extent specified on the Entity List, whenever a listed entity or an entity using an address flagged on the Entity List as presenting a high diversion risk is a party to the transaction. The listing itself states which license exceptions are available and the applicable review policy. Screening must cover the purchaser, end user, ultimate consignee, intermediate consignees and freight forwarders, and must be rerun before each shipment. BIS may also impose license requirements on a specific party by informing the exporter under § 744.11(c).

Evidence: Per-order screening records showing list version, screening timestamp and hit disposition; Entity List entry extracts or citations recording the license requirement and exception scope; Any BIS is-informed letters received and their internal distribution records; Party files for purchaser, end user, intermediate consignees and carriers

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

On 2025-09-30 BIS published an interim final rule (90 FR 47201, effective 2025-09-29) automatically extending Entity List restrictions to entities 50 percent or more owned by one or more listed entities, and applying the same treatment to 50 percent affiliates of listed military end users and certain sanctioned parties. On 2025-11-12 BIS then published a final rule (90 FR 50857) staying that interim final rule, effective 2025-11-10, until 2026-11-09, absent a future extension. Companies should set a calendar trigger for that date and complete ownership look-through mapping in advance so screening logic can be switched over the moment the stay lapses.

Evidence: Group ownership look-through chart annotating each tier and any listed entities; Watch-list register for the stay expiry date with a named owner; Contingency plan for alternative procurement and compliance if the affiliate treatment applies; External legal opinion on the aggregate 50 percent test where obtained

Releasing controlled technology or software to a foreign national inside the United States is a deemed export and must be treated like an actual export. Section 742.6 contains specific provisions keyed to persons whose most recent citizenship or permanent residency is in Country Group D:1 or D:5, including controls on GAAFET technology in ECCN 3E905 and a limited carve-out for employees already employed as of 2024-09-06 who are not prohibited persons under part 744. Companies must therefore segment access to R&D systems by nationality and update entitlements on hire, transfer and departure.

Evidence: Controlled-technology inventory with an access matrix segmented by citizenship and residency status; Export-control review records completed at onboarding and internal transfer for foreign nationals; Access audit logs for code repositories, model repositories and design files; Deemed-export license applications and approvals where required

Institutionalize the above decisions: item classification workflow, counterparty screening workflow, licensing and exception workflow, red-flag escalation, training, internal audit and complete retention of transaction documents. The EAR imposes independent liability for recordkeeping failures and false statements, so export documents such as invoices, packing lists, end-user statements and internal determination memos should be centrally filed to support BIS end-use checks.

Evidence: Export compliance manual and approval workflow chart; Red-flag checklist and escalation disposition records; Export control training records and assessment results; Transaction document archive index covering invoices, end-user statements, determination memos and screening records

Before using License Exception AIA under § 740.27, the exporter must furnish the ECCN of each item to the ultimate consignee and obtain a one-time ultimate-consignee certification, which is submitted to BIS at EARReports@bis.doc.gov with the subject line AIA Certification. Each shipment must be accompanied by written notice to the ultimate consignee that it is made pursuant to License Exception AIA, identifying the covered items or stating that the whole shipment is covered. The reporting requirement is triggered where the ultimate consignee receives items under § 740.27(a)(1) with a cumulative total processing performance of 253,000,000 TPP.

Evidence: Original ultimate-consignee certification and the record of its submission to BIS; Written ECCN notification letters; Copies of the per-shipment AIA notices; Cumulative TPP ledger used to test the reporting threshold

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

Build a data inventory and test each category against the bulk thresholds: human omic data on more than 1,000 U.S. persons (100 for human genomic data), biometric identifiers on more than 1,000, precise geolocation data on more than 1,000 U.S. devices, personal health data and personal financial data on more than 10,000 each, and covered personal identifiers on more than 100,000. Combined data is measured at the lowest applicable threshold. Thresholds aggregate across transactions between the same U.S. person and the same foreign or covered person in the preceding 12 months, and apply regardless of anonymization, pseudonymization, de-identification or encryption.

Evidence: Inventory of sensitive personal data mapped to the six categories in 28 CFR § 202.249 plus government-related data; Working papers showing 12-month aggregation per counterparty; Determination memo for combined data and covered personal identifiers, listing the paired listed identifiers; Screening record against the Government-Related Location Data List in § 202.1401

Open tool: Transfer Matrix

Determine before contracting whether the counterparty is a covered person. Countries of concern are China (including Hong Kong and Macau), Cuba, Iran, North Korea, Russia and Venezuela. Covered persons include foreign entities organized in, or with a principal place of business in, a country of concern, foreign entities 50 percent or more owned directly or indirectly, individually or in the aggregate, by such persons, and persons designated by the Attorney General on the Covered Persons List. Publication in the Federal Register is deemed constructive knowledge.

Evidence: Counterparty due-diligence questionnaire and ownership chain chart including the aggregate 50 percent test; Covered Persons List screening records with screening date and hits; Register of foreign employees and contractors with citizenship and primary residence; Signed screening conclusion approved by the compliance owner

Do not knowingly engage in data brokerage involving government-related data or bulk U.S. sensitive personal data with a country of concern or covered person. Data brokerage means the sale of data, licensing of access to data or similar commercial transactions where the recipient did not collect or process the data directly from the linked individuals. The rule examples expressly cover selling or licensing bulk precise geolocation data from an autonomous-driving fleet to a parent company abroad, embedding tracking pixels or SDKs that pass data to a covered person, and licensing subscription access to a chatbot trained on bulk sensitive data that can be prompted to disclose that training data.

Evidence: Data-flow map annotating each outbound channel with recipient and legal characterization; Inventory of SDKs, tracking pixels and advertising partners with field-level data mapping; List of terminated or restructured data-brokerage contracts with evidence of termination; Training-data provenance statement showing no prohibited transaction was used to obtain or transfer data

Any covered data transaction giving a country of concern or covered person access to bulk human omic data (genomic, epigenomic, proteomic, transcriptomic) or to human biospecimens from which such data could be derived is prohibited outright, including vendor, employment and investment agreements. It cannot be converted into a restricted transaction by implementing the CISA security requirements. The bulk threshold for human genomic data is only 100 U.S. persons.

Evidence: Inventory of omic datasets and biospecimens with source-country tagging; Access matrix showing which onshore and offshore R&D staff can reach omic data systems; Review records for omics collaborations, outsourced sequencing and academic partnerships; Training attendance records on the prohibition for R&D and business development teams

Vendor, employment and investment agreements with a country of concern or covered person that involve access to bulk sensitive personal data are restricted transactions, permitted only if the U.S. person complies with the CISA Security Requirements for Restricted Transactions (EO 14117 Implementation, January 2025) and all other applicable requirements. A rule example is explicit: substituting self-designed controls the company believes are equivalent, instead of the security requirements, makes the transaction prohibited.

Evidence: Implementation statement mapping each CISA security requirement to a control; Evidence of identity and access management configuration, data minimization and encryption or de-identification; Register of restricted transactions split into vendor, employment and investment agreements; Written security-requirements policy certified annually by the officer responsible for compliance

When engaging in data brokerage involving government-related data or bulk sensitive personal data with any foreign person that is not a covered person, the U.S. person must contractually require that the foreign person not engage in onward data brokerage of the same data with a country of concern or covered person, and must report any known or suspected breach to DOJ within 14 days, including the date, a description of the transaction and clause, the parties involved and copies of relevant documents.

Evidence: Template and executed contracts containing the onward-transfer prohibition; Clause-implementation register maintained per counterparty; Internal escalation and investigation records for suspected breaches; Breach report filed with DOJ within 14 days and the filing receipt

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

A U.S. person engaging in any transaction subject to this part must keep a full and accurate record of each transaction, available for examination for at least 10 years. For restricted transactions the following must additionally be maintained in an auditable manner: the annually certified compliance-program and security-requirements policies, annual audit results, due-diligence documentation of the data flow (types and volumes, party identities including direct and indirect ownership or individual citizenship and primary residence, and end use), the transfer method, transaction start and end dates, copies of agreements, copies of any licenses or advisory opinions and their document reference numbers, and an annual certification by the responsible compliance person as to the completeness and accuracy of the due-diligence records.

Evidence: Transaction record archive index with the 10-year retention marker; Due-diligence file covering data types and volumes, party identities, end use and transfer method; Register of agreements, licenses and advisory opinions with document reference numbers; Signed annual certification of completeness and accuracy of the due-diligence records

A U.S. person engaging in any restricted transaction must develop and implement a data compliance program no later than 2025-10-06. At a minimum it must include risk-based procedures to verify and log, in an auditable manner, the types and volumes of data, the identity of the parties (entity ownership and individual citizenship or primary residence) and the end use and transfer method; risk-based vendor identity verification; a written policy describing the compliance program; and a written policy describing implementation of the security requirements. The last two must be certified annually by an officer, executive or employee responsible for compliance.

Evidence: Written data compliance program policy with the annual officer certification page; Written security-requirements implementation policy with the annual officer certification page; Auditable data-flow verification logs; Vendor identity verification records

A U.S. person engaging in restricted transactions on or after 2025-10-06 must conduct an audit once for each calendar year in which it engages in such transactions, covering the preceding 12 months. The auditor must be qualified, independent and not a covered person or country of concern. The audit must examine the restricted transactions, the data compliance program and its implementation, the records required by § 202.1101 and the security requirements. The auditor must deliver a written report within 60 days of completing the audit, describing any failures or deficiencies in the security requirements and recommending improvements. The report must be retained for at least 10 years.

Evidence: Auditor independence and qualification statement; Annual audit report covering methodology, personnel interviewed and systems or facilities examined; Remediation plan for audit findings and evidence of closure; Archival record demonstrating 10-year retention of the audit report

Two reporting duties apply. First, an annual report: a U.S. person that, on or after 2025-10-06, engages in a restricted transaction involving cloud-computing services and has 25 percent or more of its equity owned, directly or indirectly and through any contract, arrangement, understanding or relationship, by a country of concern or covered person must file by March 1 for transactions in place as of December 31 of the previous year. Second, a rejected-transaction report: from 2025-10-06, a U.S. person that receives and affirmatively rejects (including automatically, using software or automated tools) an offer to engage in a prohibited data-brokerage transaction must file within 14 days of the rejection. Both must be signed and certified as true, accurate and complete by an officer, director, a person performing those functions, or an employee responsible for compliance.

Evidence: Ownership look-through calculation showing whether the 25 percent threshold is met; Annual report working papers and filing receipt, covering transaction dates, data types and volumes, transfer method and party names and locations; Rejected-transaction log and copies of the reports filed within 14 days; Signature authority documentation and the certification page for each filing

This is the mandatory track alongside self-audits, and the regulator sets the tempo. Three triggers (Art. 5): processing that carries significant risk such as serious impact on individual rights or a serious lack of security measures; processing that may infringe the rights of numerous individuals; or a personal information security incident causing the leakage, alteration, loss or destruction of more than 1 million individuals’ personal information or more than 100,000 individuals’ sensitive personal information. The same incident or risk may not be made the basis of a second mandated audit, which is a point to raise if a duplicate demand arrives. Once mandated: select the professional institution as the protection department requires (it is not a free choice), complete the audit within the time limit, and, where the matter is complex, obtain the department’s approval for a reasonable extension (Art. 9); provide the support the institution needs and bear the cost (Art. 8); file the institution’s audit report with the department on completion, signed by the institution’s principal and by the audit lead and bearing the institution’s seal (Art. 10); and remediate the findings as required, filing a remediation report WITHIN 15 WORKING DAYS OF COMPLETING THE FIXES (Art. 11). In practice, build this chain into the incident response plan: once an incident’s severity reaches the 1 million / 100,000-sensitive scale, start preparing for a possible mandated audit in parallel — shortlist institutions, identify the budget line and settle the cooperation posture — rather than beginning the search after the clock has already started.

Evidence: The protection department’s audit demand and the internal record starting the response; Selection process and engagement contract for the professional institution, including confidentiality and post-engagement deletion clauses; Records of the audit cost borne and of the support provided to the institution; The compliance audit report issued by the institution, signed by its principal and the audit lead and sealed; Record and acknowledgement of filing the audit report with the protection department; Remediation register: issue, action, owner, completion date, verification result; Remediation report and the filing record showing delivery within 15 working days of completing the fixes; Extension request and the department’s approval, where applicable

The threshold is the single factual entry point to this regime, so first count — and evidence — how many individuals’ personal information is processed. Write the methodology down: a de-duplicated count of identifiable natural persons, covering active users, dormant users, deactivated accounts still inside the retention window, end users reached through an SDK or entrusted processing, individuals captured offline, and non-product data such as employees and candidates; and set explicit rules for merging users who overlap across product lines and legal entities, without which each self-check produces a different number. Once more than 10 million individuals’ personal information is processed, an audit is required at least every two years (Art. 4). Falling below the threshold is not an exemption: Art. 3 requires the processor to have its internal function or an engaged institution audit compliance “regularly”, so the company must fix its own cycle in writing — commonly aligned with the annual internal-control or security assessment cadence. File each count, the basis and date of the determination, and the scheduled date of the next audit; that file is the only material that shows a regulator the cycle has not been allowed to slip.

Evidence: Policy defining the headcount methodology: scope, de-duplication rules, cross-entity merge rules; Headcount results for each period with an explanation of the data sources; Threshold determination record: conclusion, basis, assessor, date; Audit cycle schedule showing the previous and next audit dates; Written decision fixing a self-determined audit cycle where the threshold is not met

Art. 6 requires both self-initiated and mandated audits to follow the annexed Guidelines, whose 27 sections amount to a ready-made audit programme: lawful basis and consent (including re-consent after changes, separate consent and written consent); processing rules set out as a list with the shortest necessary retention period; notice that is prominent and readable; agreements and supervision for joint and entrusted processing; notice when personal information transfers on a merger, restructuring, division or dissolution; separate consent and a prior impact assessment before providing personal information to others; transparency, fairness and a refusal mechanism for automated decision-making; consent-based public disclosure; necessity and signage for image-collection equipment in public places; the limits on processing already-public personal information; sensitive personal information and minors under 14; the three outbound routes and approval before providing information to foreign judicial or law-enforcement authorities; the six grounds for deletion and the duty to stop processing where deletion is technically infeasible; handling and responding to individuals exercising their rights; explaining the processing rules; internal management systems and operating procedures (classification, emergency mechanisms, impact assessment and audit systems, complaints, operating permissions, training, performance appraisal, and accountability for unlawful processing); the effectiveness of security technical measures (confidentiality, integrity and availability, encryption and de-identification, access control); coverage and assessment of training; the personal information protection officer’s qualifications, authority and registration with the authority; the conduct and content of impact assessments; the comprehensiveness of emergency plans and drills; incident response; and, for major platforms, platform rules and the personal information protection social responsibility report. In practice: map all 27 sections onto your own systems, data flows and policy documents to produce working papers with four columns — review point, evidence, owner, conclusion. For AI companies the recurring gaps are the lawful basis for training corpora, retention and deletion of conversation logs, whether personal information in models and logs can actually be deleted, and explanations of automated decisions in recommendation and risk control; evidence those first.

Evidence: Audit plan: scope, sampling method, schedule and division of responsibility; Working papers mapped section by section to the 27 Guidelines items (review point, evidence, owner, conclusion); Inventory of processing activities and data-flow diagrams covering training, inference and logging; Sample lawful-basis and consent records, including separate consent, written consent and re-consent after changes; Explanatory materials for automated decisions, the refusal mechanism, and evidence of the non-profiled option; Prior impact assessments for sensitive personal information and for minors under 14; Materials determining the outbound route: security assessment, standard contract filing, or certification; Execution records and technical notes on giving effect to deletion in applications, logs, backups and models; Internal management systems and operating procedures, training and assessment records, emergency plans and drill records; List of audit findings with the remediation plan

Art. 12 attaches the audit work to named people and bodies. First: a processor handling more than 1 million individuals’ personal information must appoint a personal information protection officer responsible for the organisation’s compliance audit work — note that this threshold (1 million) sits below the 10 million mark that triggers the mandatory two-year cycle, so many companies hit “you need an officer” before “you need a scheduled audit”. Section 22 of the Guidelines adds what is reviewed about that officer: relevant experience and professional knowledge and familiarity with the applicable laws and regulations; clearly defined duties and sufficient authority to coordinate internal departments; the right to give views before major processing decisions are taken; the power to stop non-compliant operations and take necessary corrective measures; and publication of the officer’s contact details, with the name and contact details filed with the protection department. Second: a processor providing important internet platform services with a very large user base and complex business types must set up an independent body composed mainly of external members to supervise the compliance audit — “mainly external” means a committee dominated by internal executives does not qualify, and the membership, rules of procedure and supervisory conclusions all need to be documented.

Evidence: Appointment document and delegation of authority for the personal information protection officer; Officer qualification materials: relevant experience, professional knowledge and training records; Records of the officer giving views before major processing decisions; Records of the officer stopping non-compliant operations and taking corrective measures; Screenshot of the published contact details and the record of filing the name and contact details with the protection department; Establishment document for the independent oversight body, its membership list and the proportion of external members; The oversight body’s rules of procedure, meeting minutes and supervisory conclusions on the compliance audit

The engaging party has to control four things itself, or the problem only surfaces at the moment of engagement. (1) Capability (Art. 7): the institution must be capable of performing the audit, with audit personnel, premises, facilities and funding commensurate with the service, and is encouraged to be certified under the Regulations on Certification and Accreditation — keep verification materials on its personnel, premises, facilities and past work. (2) Confidentiality and deletion (Art. 13): the institution owes confidentiality over the personal information, trade secrets and confidential business information obtained, must not disclose or unlawfully provide it to others, and must delete it promptly once the audit work ends — write both into the engagement contract and obtain a deletion confirmation at closeout. (3) No sub-delegation (Art. 14): the institution may not sub-delegate the audit, so the contract needs an explicit prohibition and a liability clause. (4) Rotation (Art. 15): the same institution and its affiliates, and the same audit lead, may not audit the same subject more than three times consecutively. This is the rule most often discovered at the fourth engagement, because “affiliates” and “same audit lead” are not fields in ordinary vendor management records; keep a dedicated engagement-history register keyed on institution, affiliate relationship and audit lead, and check it before requesting quotes.

Evidence: Capability verification materials: auditors’ credentials, premises and facilities, funding, and certification where held; Contract clauses on confidentiality, post-engagement deletion and the prohibition on sub-delegation; Deletion confirmation letter obtained at closeout; Engagement-history register: institution, affiliate relationships, audit lead, and the years of each engagement; Record of the consecutive-engagement check run before this selection

For content within Art. 17 §1 of the Deep Synthesis Provisions, add the explicit label by modality under Art. 4: for text, a textual or common-symbol prompt at the start, end or an appropriate midpoint, or a conspicuous prompt in the interactive interface or around the text; for audio, a spoken or rhythmic prompt at the start, end or an appropriate midpoint, or a conspicuous prompt in the interactive interface; for images, a conspicuous prompt at an appropriate position; for video, a conspicuous prompt on the opening frame and around the player, optionally also at the end and at appropriate midpoints; for virtual scenes, a conspicuous prompt on the opening frame, optionally also at appropriate points during the session; and for other scenarios, a conspicuous prompt suited to the application. Where download, copy or export functions are offered, the file must still contain a conforming explicit label.

Evidence: Implementation and placement note for the explicit label in each modality: text, audio, image, video and virtual scenes; Sample labelled files per modality, including samples after download, copy and export; Mapping table comparing product functions against the five categories in Art. 17 §1 of the Deep Synthesis Provisions; Technical verification that the label survives the export path

Filing pack for generative AI services and algorithm filing, including the security assessment report

As required by Art. 16 of the Deep Synthesis Provisions, add an implicit label to the metadata of generated and synthetic files, carrying the generated-content attribute, the provider’s name or code and a content identifier among other production elements. Art. 5 §3 defines file metadata as descriptive information embedded in the file header in a specific encoding format, recording the file’s source, attributes and use. The Measures also encourage adding implicit labels in the form of digital watermarks. The specific fields and encoding must conform to GB 45438-2025.

Evidence: Field design document for the implicit label: attribute, provider name or code, and content identifier; Implementation note for metadata writing in each file format, with exported metadata from sample files; Field and encoding conformity check against GB 45438-2025; Digital watermark design and robustness test results, where used; API documentation showing metadata carried in outputs

Filing pack for generative AI services and algorithm filing, including the security assessment report

A provider of network content dissemination services must: verify whether the file metadata carries an implicit label, and where the metadata confirms the content is generated or synthetic, add a conspicuous prompt around the published content telling the public it is generated content; where no implicit label is found but the user declares the content as generated, add a conspicuous prompt telling the public the content may be generated; where no implicit label is found and the user has not declared, but an explicit label or other traces of generation are detected, treat it as suspected generated content and add a conspicuous prompt; and provide the necessary labelling function while prompting users to declare whether their post contains generated content. In the first three situations the platform must also write dissemination elements into the file metadata — the generated-content attribute, the platform’s name or code and a content identifier.

Evidence: Metadata verification workflow, plus the copy and display samples for each of the three prompt tiers; Description of the detection capability for traces of generation, with detection-rate statistics; Implementation note and samples for writing dissemination elements back into the metadata; Screenshot of the user declaration entry point and declaration-rate statistics; Note on how this connects to Art. 9 §2 of the Algorithmic Recommendation Provisions, which requires labelling before transmission continues

The user service agreement must set out the method and style of content labelling and remind users to read and understand the labelling requirements. Where a user asks for generated content without an explicit label, the provider may supply it after the user agreement has made the user’s own labelling duty and usage responsibility clear, and must retain logs including details of the recipient for no less than six months.

Evidence: Service-agreement clauses describing the labelling method and style, with evidence of user acknowledgement; Documented application and approval process for supplying output without an explicit label; Recipient logs (account, entity, timestamp, content identifier) and screenshots of the six-month retention configuration; Usage statistics and anomaly monitoring for unlabelled output

Filing pack for generative AI services and algorithm filing, including the security assessment report

When completing algorithm filing, security assessment and similar procedures, the provider must submit the labelling materials required by these Measures, and must strengthen the sharing of labelling information to support the prevention and investigation of related offences. Labelling must also conform to the applicable laws, administrative regulations, departmental rules and mandatory national standards — namely GB 45438-2025 “Cybersecurity technology — Labeling method for content generated by artificial intelligence” (issued 28 Feb 2025, effective 1 Sep 2025, currently in force).

Evidence: Labelling description filed with the algorithm filing and security assessment materials; Self-assessment checklist and gap list against GB 45438-2025; Reconciliation between the labelling implementation described in the filing and the live product; Description of the mechanism for sharing labelling information and cooperating with enforcement

Filing pack for generative AI services and algorithm filing, including the security assessment report

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

Before applying for certification of an outbound transfer, perform the statutory duties of notice, obtaining separate consent, and running a personal information protection impact assessment. Art. 6 sets out what the assessment must focus on, and it dovetails with the separate consent for outbound transfers in PIPL Art. 39 and the assessment requirements in PIPL Arts. 55–56. The certification body takes this pack as its input for the conformity assessment, and an incomplete pack is a direct cause of failure.

Evidence: Text of the outbound-transfer notice and screenshots of where it is displayed, covering the recipient’s name and contact details, the purposes and methods, the data categories and how rights are exercised; Captured interaction evidence and consent logs for the separate outbound consent; Personal information protection impact assessment report organised around the matters in Art. 6; Remediation items arising from the assessment, with closure evidence

Personal Information Protection Impact Assessment (PIPIA) report

After confirming eligibility under Art. 5, define precisely the scope submitted for certification: the business scenarios covered, the data categories and fields, the onshore and offshore entities, the direction and frequency of transfers, and the recipient jurisdictions. The certified scope then becomes the compliance boundary — Art. 10 requires the certification body to suspend and ultimately revoke the certificate where actual transfers depart from it — so the scope must be neither so narrow that it constrains the business nor so broad that it cannot be evidenced.

Evidence: Scope statement covering business scenarios, data fields, entities, flows and jurisdictions; Eligibility determination record (non-CIIO status, volume thresholds, absence of important data); Intra-group data flow map and entity relationship diagram; Documented change-control process for scope changes

Outbound Data Transfer Risk Self-Assessment Report (per the CAC filing guide template)

Open tool: Transfer Matrix

Apply to a body holding accreditation for personal information protection certification, which carries out the assessment under the basic certification specification and the certification rules and issues a certificate where the requirements are met. Within five working days of issuing a certificate or of any change in its status, the body must report the certificate number, the certified processor’s name, the certified scope and the status change to the national certification and accreditation information platform, so certificate status is publicly checkable. After certification the processor must keep actual transfers within the certified scope and submit to supervision, spot checks and evaluation by SAMR and the CAC.

Evidence: Verification record for the certification body’s accreditation, including its CAC filing; Certification application pack and the certificate issued by the body; Screenshot of the certificate record published on the national certification and accreditation information platform; Periodic reconciliation records comparing actual transfers against the certified scope; Records of responses to supervision, spot checks and evaluation, with remediation closure evidence

A large frontier developer must write, implement, comply with and clearly and conspicuously publish on its website a frontier AI framework describing how it incorporates national standards, international standards and industry-consensus best practices; defines and assesses thresholds, which may be tiered, for identifying capabilities that could pose catastrophic risk; reviews assessments and the adequacy of mitigations as part of the decision to deploy or use a model extensively internally; determines what substantial modifications trigger updated disclosures; and assesses and manages catastrophic risk from internal use, including the risk of a model circumventing oversight mechanisms.

Evidence: Published frontier AI framework text with version history; Definition of capability thresholds and the assessment methodology; Pre-deployment risk assessment and mitigation adequacy review records; Framework update triggers and the record of actual updates

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

A frontier developer must report any critical safety incident involving its frontier models to the Office of Emergency Services within 15 days of discovery. If the incident poses an imminent risk of death or serious physical injury, the developer must disclose it within 24 hours to an appropriate authority, including any law enforcement or public safety agency with jurisdiction, as required by law. Amended reports may be filed as new information emerges. Statutory incident types include unauthorized access to, modification of or exfiltration of model weights resulting in death or bodily injury; loss of control of a frontier model causing death or bodily injury; and a model using deceptive techniques against the developer to subvert its controls or monitoring outside an evaluation designed to elicit that behaviour, in a manner demonstrating materially increased catastrophic risk.

Evidence: Incident classification criteria document; Incident register recording discovery time, classification and reporting time; Reports filed with the Office of Emergency Services and filing receipts; Records of 24-hour disclosures showing recipient and channel

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

Before, or concurrently with, deploying a new frontier model or a substantially modified version of an existing one, a frontier developer must clearly and conspicuously publish a transparency report on its website stating the release date, languages supported, output modalities supported, intended uses and any generally applicable restrictions or conditions on use. A large frontier developer must additionally include summaries of the catastrophic-risk assessments conducted under its frontier AI framework and of the other steps taken to fulfil that framework for the model.

Evidence: Archived transparency report for each model version with publication timestamps; Catastrophic-risk assessment reports mapped to the published summaries; Determination records for what counts as a substantial modification; Release checklist evidencing the sequencing of deployment approval and report publication

Model Card

A large frontier developer must transmit to the Office of Emergency Services a summary of any assessment of catastrophic risk resulting from internal use of its frontier models every three months, or on another reasonable schedule communicated to the Office in writing, with written updates as appropriate. The Office must establish a mechanism for confidential submission and limit access to the reports.

Evidence: Methodology and records for internal-use risk assessments; Written notice of an alternative reporting schedule where the quarterly cadence is not used; Each submitted summary and its filing receipt; Records of internal-use oversight mechanisms and circumvention testing

A frontier developer must not make a materially false or misleading statement about catastrophic risk from its frontier models or about its management of that risk. Read with the transparency report and framework duties, publicly claimed safety evaluations, red-teaming and mitigations must match what is actually performed internally.

Evidence: Reconciliation working papers mapping public safety claims to internal evidence; Raw records of red-teaming and safety evaluations; Compliance review records for marketing and sales materials; Fact-check records for responses to customer security questionnaires

A frontier developer must not make, adopt, enforce or enter into any rule, policy or contract that prevents a covered employee from disclosing, or that retaliates for disclosing, information where the employee has reasonable cause to believe it shows that the developer activities pose a specific and substantial danger to public health or safety from a catastrophic risk, or that the developer violated the TFAIA. Developers must give covered employees clear notice of these rights, either by posting in the workplace or by annual written notice. A large frontier developer must also provide a reasonable internal anonymous disclosure process with monthly status updates to the discloser on the investigation and the actions taken.

Evidence: Records of compliance edits to the employee handbook, confidentiality agreements and restrictive covenants; Proof of workplace posting or delivery and acknowledgement of the annual written notice; Technical design and operating records for the anonymous reporting channel; Case log of disclosures with evidence of monthly status updates

A person may not develop or deploy an AI system in a manner that intentionally aims to incite or encourage a person to commit physical self-harm including suicide, to harm another person, or to engage in criminal activity. This has direct product-design consequences for consumer-facing conversational, companion and content-generation products and must be reflected in system prompts, safety guardrails and red-teaming.

Evidence: Safety guardrail design documents and policy rule sets; Red-team reports and refusal-rate data for self-harm, violence and criminal-facilitation prompts; Description of minor-protection and crisis-referral mechanisms; Safety incident handling and post-incident review records

A person may not develop or distribute an AI system with the sole intent of producing, assisting in producing, or distributing visual material in violation of Texas Penal Code section 43.26 or deep fake videos or images in violation of section 21.165, and may not intentionally develop or distribute an AI system that engages in text-based conversations simulating or describing sexual conduct as defined in section 43.25 while impersonating or imitating a child under 18 years of age.

Evidence: Content safety policy and age-related persona restriction rules; Blocking test reports for minor-related prompts and personas; Output moderation and complaint-handling workflow; Review records for third-party personas or plugins

A person may not develop or deploy an AI system with the intent to unlawfully discriminate against a protected class in violation of state or federal law. The statute is explicit that disparate impact alone is not sufficient to demonstrate intent to discriminate. Protected class covers characteristics protected by state or federal civil rights laws, including race, colour, national origin, sex, age, religion and disability. Insurance entities providing insurance services under applicable insurance statutes are excluded, and a federally insured financial institution that complies with all federal and state banking laws is considered in compliance.

Evidence: Product design intent and permitted-use documentation; Fairness testing and bias mitigation records; Review records covering use of protected-class attributes and proxy variables; Internal compliance approvals and the prohibited-use list

The Texas Attorney General has exclusive enforcement authority and must first give written notice. No action may be brought before the 60th day after notice, or at all if within that period the violator cures and provides a written statement that it cured, supplied supporting documentation showing how, and made any necessary changes to internal policies to reasonably prevent further violations. There is a rebuttable presumption that a person used reasonable care. A defendant is not liable where it discovered the violation through developer or deployer feedback, adversarial or red-team testing, following state agency guidelines, or an internal review process while substantially complying with the latest NIST Artificial Intelligence Risk Management Framework Generative Artificial Intelligence Profile or another recognized framework. No civil penalty action may be brought for an AI system that has not been deployed.

Evidence: Evidence of substantial compliance with the NIST Generative AI Profile, including a mapping table and execution records; Red-team and adversarial testing plans and reports; Internal review process documentation and findings register; Record of any Attorney General notice, the cure actions and the draft written statement

The subtitle applies to a person who promotes, advertises or conducts business in Texas, produces a product or service used by Texas residents, or develops or deploys an AI system in Texas. Consumer is limited to a Texas resident acting in an individual or household context and excludes individuals acting in a commercial or employment context. The scope determination should be documented, since the product-used-by-residents limb is very broad and can be triggered merely by distribution through a U.S. app store.

Evidence: Scope determination memo; Evidence of Texas user distribution and business activity; Inventory of product distribution channels

Article 31 imposes three duties: (1) where a product or service uses high-impact AI or generative AI, users must be informed in advance that it operates on that AI; (2) where generative AI, or a product or service using it, is provided, the output must be marked as generated by generative AI; and (3) where an AI system produces virtual audio, images or video hard to distinguish from reality, the fact that it was generated by an AI system must be notified or marked in a way the user can clearly recognise, with the option, for outputs that are or form part of artistic or creative works, of a method that does not impair their display or enjoyment. Article 23 of the Enforcement Decree adds detail: the prior notice may be given by stating it on the product itself or in the contract, user manual or terms of use; by display on the user’s screen or device; by conspicuous posting at the place where the product or service is supplied; or by another method recognised by the Minister. The Art. 31(2) marking may be human-readable or machine-readable, and where machine-readable it must be accompanied at least once by a textual or audio notice that the output was generated by generative AI. The Art. 31(3) notice or marking must let the user clearly recognise the fact, taking account of whether it can be readily checked visually, aurally or by software, and of the age and physical and social circumstances of the main users. Three exceptions apply: where the use of high-impact or generative AI is already obvious from the product or service name, user screen, product exterior or the wording shown on the output; where the system is used solely for the AI business’s internal operations; and where the Minister notifies, by public notice, other cases warranting full or partial exemption.

Evidence: Screenshots and Korean-language copy of the prior-notice surface; Implementation design for output marking, covering visible indicators and metadata or watermarks; Detection and marking rules for realistic synthetic content; Assessment records where the artistic or creative exception is relied on; Robustness testing of the markings and version-change records

Model Card

Article 32 requires that, for AI systems whose cumulative compute used in training is at or above the threshold set by Presidential Decree, the AI business must implement two things to ensure safety: identification, assessment and mitigation of risk throughout the AI lifecycle; and establishment of a risk-management system that monitors and responds to AI-related safety incidents. The results of that implementation must be submitted to the Minister of Science and ICT. Article 24(1) of the Enforcement Decree defines the threshold as a system meeting all three of the following: cumulative compute used in training of 10^26 floating-point operations or more; being constituted and operated using the most advanced AI technology among those currently applied to AI systems, having regard to the state of the art; and a risk level liable to have a broad and serious effect on human life, bodily safety and fundamental rights. All three are cumulative, so crossing the compute figure alone does not bring a system within the article. The method of calculating cumulative training compute is to be fixed separately by ministerial notice (Decree Art. 24(2)), which was not verified in this pass.

Evidence: Methodology and working papers for cumulative training compute, measured against the 10^26 FLOPs threshold; Item-by-item applicability assessment against all three conditions in Decree Art. 24(1); Lifecycle risk identification, assessment and mitigation records; Documentation of the safety-incident monitoring and response system, including on-call and escalation; Implementation results submitted to MSIT and the acknowledgement; Re-assessment records on each model version iteration

Model CardISO/IEC 42001 AI management system implementation and certification readiness checklist

Article 34(1) requires an AI business providing high-impact AI, or a product or service using it, to implement measures as prescribed by Presidential Decree, comprising six items: establishing and operating a risk-management plan; establishing and implementing, so far as technically feasible, an explanation plan covering the AI’s final output, the main criteria used to reach it and an overview of the training data used in developing and using the AI; establishing and operating a user-protection plan; human management and oversight of the high-impact AI; creating and retaining documentation evidencing the safety and reliability measures; and any other matter deliberated and resolved by the Committee for securing the safety and reliability of high-impact AI. That sixth item is open-ended, so the operative checklist is not limited to the first five and the National AI Strategy Committee’s resolutions must be tracked. The Minister may issue a notice specifying details and recommend compliance. Implementing equivalent measures under other legislation, as prescribed by Presidential Decree, counts as compliance, with the recognition criteria and procedure set out in Annex 1 to the Decree. Article 27 of the Decree adds three directly operational requirements: the key contents of the risk-management plan, the key contents of the explanation plan, the user-protection plan and the name and contact details of the person managing and overseeing the high-impact AI must be posted at the business’s office or premises or on its website (matters that are trade secrets under Art. 2(2) of the Unfair Competition Prevention and Trade Secret Protection Act may be withheld); the evidence of implementing the Art. 34(1) measures must be retained in documentary form, including electronically, for five years; and an AI-using business that receives a system from a business which has implemented all or some of items 1 to 3 is treated as having implemented them itself, provided it has not materially changed the system’s function, such as by significantly altering its original purpose or use. An AI-using business may request from the AI developer the materials needed to discharge these duties, and the developer must endeavour to cooperate.

Evidence: Risk-management plan and operating records; Explanation plan covering final outputs, main criteria and a training-data overview, with the user-facing explanation materials; User-protection plan and complaint-handling records; Human oversight procedure, staffing and intervention logs, plus the published name and contact details of the responsible person; Archived copies of the page published under Decree Art. 27, with the assessment of anything withheld as a trade secret; Documented file of safety and reliability measures with evidence of five-year retention

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

Article 36: an AI business with no address or place of business in Korea that meets the user-count, revenue or other thresholds set by Presidential Decree must designate in writing a person to act for it (the domestic representative) and notify the Minister of Science and ICT. Article 29(1) of the Enforcement Decree sets those thresholds as any one of: prior-year revenue (prior business year for a corporation) of KRW 1 trillion or more; prior-year revenue in the AI services segment of KRW 10 billion or more; a daily average of 1 million or more domestic users of the business’s AI products and services over the three months preceding the end of the prior year; or having previously been fined under Art. 43(1)3. Revenue under the first two limbs is converted into won at the prior year’s average exchange rate (Decree Art. 29(2)). The representative handles: submission of implementation results under Art. 32(2); requests under Art. 33(1) for confirmation of high-impact status; and the support needed to implement the Art. 34(1) safety and reliability measures, including checking that the Art. 34(1)5 documentation is current and accurate. The representative must have an address or place of business in Korea. A violation of the Act by the representative in respect of those matters is deemed committed by the AI business that designated it. Failure to designate is expressly an administrative-fine offence under Art. 43.

Evidence: Written designation of the domestic representative; Record of the notification to MSIT and its acknowledgement; Working papers testing each of the four Decree Art. 29 thresholds, including the exchange-rate basis and the daily-active-user counting methodology; Representative’s checks on the currency and accuracy of the Art. 34(1)5 documentation

Article 33 requires an AI business, before providing AI or a product or service using it, to examine in advance whether that AI constitutes high-impact AI, and permits it to ask the Minister of Science and ICT to confirm that question. The Minister must respond and may establish an expert committee for advice. The Minister may develop and disseminate guidelines on the criteria for, and examples of, high-impact AI. The confirmation procedure is prescribed by Presidential Decree.

Evidence: Prior high-impact examination record for each use case; Basis for the determination and the version of ministerial guidance relied on; Any confirmation request submitted to the Minister and the response; Re-examination records when the use case changes

Article 35(1) provides that an AI business providing a product or service using high-impact AI shall endeavour to assess in advance its impact on people’s fundamental rights, and in doing so must have regard to the nature of the product or service so that the assessment reflects the characteristics of AI-vulnerable groups (the second sentence was added by the 20 January 2026 amendment and commences 21 July 2026). Article 35(2) requires state agencies and equivalent bodies intending to use high-impact AI products or services to give priority to those for which an impact assessment has been conducted. The assessment is therefore an endeavour obligation with real competitive weight in Korean public procurement. Article 28(1) of the Enforcement Decree requires the assessment to cover seven items: identification of the individuals or groups whose life, bodily safety or fundamental rights may be affected by the high-impact AI product or service, reflecting the characteristics of the AI-vulnerable groups defined under Art. 3(5); identification of the types of fundamental rights that may be affected; the nature and extent of the social and economic effects on those rights; the patterns of use of the high-impact AI; the quantitative or qualitative indicators used and how results are produced; prevention, mitigation and loss-recovery measures for the risks identified; and, where the results call for improvement, the implementation plan. The assessment may be carried out by the business itself or commissioned to a third party (Decree Art. 28(2)); remaining requirements are to be set by ministerial notice.

Evidence: Fundamental-rights impact assessment report; Methodology and test results showing how vulnerable-group characteristics were reflected; Record of how assessment findings changed the product design; Assessment materials submitted in public procurement bids

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

Article 40: where the Minister of Science and ICT discovers or learns of a violation or suspected violation of Art. 31(2)–(3), Art. 32(1)–(2) or Art. 34(1), or receives a report or complaint about one, the Minister may require the AI business to submit relevant materials or have officials conduct the necessary investigation, and where necessary enter the business’s offices or premises to inspect books, documents and other materials or objects (with the Administrative Investigation Basic Act applying to the procedure). Where the investigation establishes a violation, the Minister may order the measures necessary to stop or correct it. Failure to comply attracts an administrative fine of up to KRW 30 million under Art. 43.

Evidence: Regulator-enquiry response plan with designated authorised contacts; Index of readily retrievable compliance documentation for Arts. 31, 32 and 34; Correspondence records and list of materials submitted; Evidence of execution and closure of any suspension or corrective order

Inventory every decision point in the product that produces a legal or similarly significant effect for a UK individual (credit or risk refusals, CV screening, account bans, pricing and lending, insurance underwriting, content actions) and determine for each whether there is “meaningful human involvement”. For those that are solely automated, implement and be able to evidence four safeguards: give the individual information about the decision, let them make representations, provide human intervention on the controller’s part, and let them contest the decision. The assessment of meaningfulness must take into account the extent to which the decision is reached by profiling.

Evidence: Automated decision inventory (decision point, input features, output, impact tier, reasoning on whether it is solely automated); Human-intervention design note plus sample intervention records (reviewer authority, evidence that decisions can be overturned); Notice text served to individuals and screenshots of the contest/appeal route; Data protection impact assessment and its review record

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

A significant decision based entirely or partly on Article 9(1) special category data (health, biometrics used for unique identification, race, religion, sexual orientation, trade union membership) may not be taken solely automatically unless the data subject has given explicit consent, or the decision is necessary for entering into or performing a contract with the controller, or is required or authorised by law, and Article 9(2)(g) applies. Separately, a significant decision may not be taken solely automatically where the processing relies entirely or partly on Article 6(1)(ea) (recognised legitimate interests). Engineering must be able to show that special category data and its proxies are absent from, or stripped out of, model inputs.

Evidence: Feature inventory and screening conclusion for special category data and proxies; Memo on the Article 9(2) condition relied on and its legal basis; Records of explicit consent capture and withdrawal (where consent is relied on); Technical note and test report on input filtering/masking for the model

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

Map every data flow out of the UK to the Chinese parent, overseas cloud, model-training environments and third-party labelling vendors, and put an Article 46 safeguard in place for each: the ICO’s International Data Transfer Agreement (IDTA), the UK Addendum to the EU SCCs, or approved binding corporate rules. Then operationalise the technical and organisational measures the clauses promise (access control, encryption, sub-processor approval, government access request handling) and refresh them when vendors or sub-processors change.

Evidence: Data flow map and restricted transfer register (exporter, importer, data categories, purpose, mechanism); Executed IDTA or EU SCCs plus the UK Addendum, including schedules and the technical measures annex; Sub-processor list and onward transfer approval records; Government access request handling and notification procedure

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

Open tool: Transfer Matrix

Complete a DPIA before training, fine-tuning or deploying an AI system on UK personal data and cover, per the ICO’s AI and data protection guidance: separate lawful bases for training and inference; statistical accuracy and fairness including bias testing; data minimisation and privacy-enhancing technologies; security of the model and training data (model inversion and membership inference); and how individuals exercise their rights. Note that the new Schedule 4 recognised legitimate interests basis cannot support processing used for a solely automated significant decision (Article 22B(4)), so check that when selecting a basis. Transparency must explain the model’s purpose, the categories of data sources and the key logic of decisions.

Evidence: AI system DPIA, with separate lawful basis analysis for training and inference; Evidence of data provenance and licence chain (procurement contracts, crawling policy, public-source documentation); Statistical accuracy and bias test reports; Model card / system description and the user-facing transparency notice

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

Under the amended Article 46(1A), signing the IDTA or Addendum is not enough: the exporter must, acting reasonably and proportionately, conclude that the data protection test is met for the transfer or that type of transfer — that protection in the destination is not materially lower than under UK law. The assessment must cover rule of law and human rights, the existence and powers of a data protection authority, government access and surveillance law, and the possibility of onward transfer. For transfers into mainland China it must specifically address government access and cooperation duties under the Cybersecurity Law, Data Security Law and PIPL, and the supplementary measures adopted (encryption, key custody outside the destination, minimisation, refusal of requests lacking legal basis). Keep the conclusion on file and review it periodically.

Evidence: Data protection test / TRA report, tiered by transfer type; Analysis of the destination’s legal environment and external legal opinion, if obtained; List of supplementary technical and organisational measures with effectiveness verification records; Review schedule and the conclusion of the previous review

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

Open tool: Transfer Matrix

Section 78 limits the right of access to what the controller can provide “based on a reasonable and proportionate search”, so define and document in advance: which systems are searched, with what keywords and time windows, and why particular backups or logs are excluded. Section 76 introduces UK GDPR Article 12A, an “applicable time period” that can be paused while identity is confirmed or the scope of the request is clarified. The hard part for AI companies is personal data in training sets, vector stores, prompt logs and model outputs — set an explainable, reproducible search scope before the first request arrives.

Evidence: DSAR procedure, including the method for scoping searches and a proportionality reasoning template; DSAR log (receipt date, reason and duration of any clock pause, response date, what was provided or withheld); System and data source inventory, recording whether training sets, vector stores and prompt logs are searched and why; Response letter templates and exemption reasoning

Section 70 inserts UK GDPR Article 6(1)(ea) and Schedule 4 “recognised legitimate interests”, which remove the need for a balancing test within that list; section 71 and Schedule 5 list further processing treated as compatible with the original purpose. Re-check the lawful basis recorded for each processing activity, identify what can move to the new basis and what still needs a legitimate interests assessment, and update the privacy notice and ROPA. Note that processing relying on Article 6(1)(ea) cannot be used for a solely automated significant decision.

Evidence: Updated ROPA with a lawful-basis mapping table; Legitimate interests assessments and their review conclusions; Versioned privacy notice with effective dates; Cross-check record against the Article 22B(4) restriction

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

From 19 June 2026 a controller must facilitate complaints that processing infringes the UK GDPR or Part 3 of the DPA 2018, by steps such as providing a complaint form that can be completed electronically; acknowledge receipt within 30 days; and without undue delay take appropriate steps to respond — including making enquiries and updating the complainant — and inform them of the outcome. The Secretary of State may by regulations require controllers to report complaint volumes to the Commissioner, so build the counting capability now.

Evidence: Online complaint form and sample submission acknowledgement; Complaints register (acknowledgement date, investigation record, outcome notification date); Internal complaint handling procedure and escalation rules; Monthly/quarterly complaint volume statistics

For every scraped corpus used in pre-training or fine-tuning, assess whether the personal data in it is publicly available. A digital barrier does not by itself defeat public availability, but the assessment must weigh the barrier’s purpose and effect, the number and complexity of steps needed to reach the data, and whether the data is obtainable without restriction elsewhere. Where it is reasonably arguable that the data behind a barrier is not publicly available and the organisation nonetheless relies on the exception, it must record the assessment and reasoning in a DPIA or other written record and produce it if PDPC asks.

Evidence: Inventory of scraped sources annotated with barrier type; Per-source public-availability assessment records; Data protection impact assessment (DPIA); Record of robots.txt and terms-of-service compliance checks for the crawl

Data Card — datasheet for a training, validation or test dataset

Where User Data is used for large-scale training or fine-tuning of generative AI models, a general “new product development” statement is not sufficient consent: para 4.4 states that organisations must provide AI-Specific Notifications for this purpose. The form and wording are for the organisation, but individuals must be able to understand the types of personal data affected, how they will be used to train or fine-tune the model, and the functions of those models. Para 4.6 goes on to say organisations are encouraged to provide, to the extent practicable, four items — the model functions requiring personal data, a clear description of the types of personal data used, how the data will be used to train or fine-tune the model, and how individuals can decline or withdraw consent. Those four are best practice rather than a mandatory checklist, but should be treated as PDPC’s review baseline. Layered notification is acceptable, as is a single notification covering several models; consent to processing beyond what is reasonable to provide the product must not be a condition of supply.

Evidence: AI-Specific Notification text with version history; Privacy policy update announcement and in-product notice screenshots; Opt-out and withdrawal mechanism plus execution records; Reconciliation records between training datasets and users who withdrew consent

Determine, per business line, whether the company is a Model Provider, System Provider or System Deployer, and whether in that capacity it is an organisation or a data intermediary, then configure the obligation set accordingly. A Model Provider that processes personal data for its own purposes — including harvesting downstream prompts and inputs for model development — is an organisation subject to all PDPA obligations; when running inference or hosting data for downstream customers it is a data intermediary owing at least the protection and retention-limitation obligations. The same entity may switch roles between scenarios, and each must be documented in policy.

Evidence: Business-line to role to obligation mapping table; Contract clauses distinguishing organisation and data intermediary capacity; Internal policies and procedures per role; Statement of downstream data-access boundaries for open-weight releases

System Deployers must identify and register the new data sources their systems create — end-user prompts and inputs, generated outputs, agent or tool activity data, and connected internal enterprise data — assign responsibility for each, implement matching safeguards, and educate internal and external users on what categories of personal data may be entered and how it will be processed. Where systems have agentic functionality, deployers must regularly review the sufficiency of safeguards and be transparent about the privacy-utility trade-off. Model and System Providers should disclose downstream the safeguards implemented, testing and performance metrics such as the likelihood of data leakage, and incident response and breach-notification procedures.

Evidence: Register of new data sources with assigned ownership; Guidance on data types permitted in prompts plus staff training records; Access controls and redaction configuration for prompt logs; Downstream-facing safeguards information sheet including data-leakage test metrics; Privacy-utility trade-off assessment for agentic use cases

Access and correction obligations apply to personal data collected, used or disclosed for model or system development and deployment. Organisations must accede unless a PDPA exception applies — for example where the burden or expense of access would be unreasonable to the organisation or disproportionate to the individual’s interests, or where there are reasonable grounds that a correction should not be made. Data transferred to a data intermediary remains under the organisation’s control and must be covered in the response. The guidelines acknowledge the technical difficulty created by embeddings and context windows, but this is not an automatic exemption.

Evidence: Searchable index or data-lineage records for training corpora and User Data; Register of access and correction requests; Written justification and technical-limitation explanation where an exception is relied on; Records of retrieval and correction instructions issued to data intermediaries

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

Collection, use and provision of personal information must rest on one of the grounds in Arts. 15, 17 and 18; where consent is relied on, it must be obtained separately and distinguishably under Art. 22, and service must not be refused because consent beyond what is necessary was declined. Processing the data of a child under 14 requires the legal representative’s consent.

Evidence: Processing inventory mapped to lawful bases; Korean-language consent UI screenshots and itemised consent records; Age-determination records for under-14s and legal-representative consent records; Documentation distinguishing mandatory from optional consent items

Transfers abroad — defined to include provision (including where the data can be queried), entrusted processing and storage — are prohibited unless one of five routes applies: (1) the data subject’s separate consent to the cross-border transfer; (2) a special provision in law, a treaty to which Korea is a party, or another international agreement; (3) entrusted processing or storage necessary to conclude and perform a contract with the data subject, where the Art. 28-8(2) items are disclosed in the privacy policy or notified to the data subject by email or another method prescribed by Presidential Decree; (4) the recipient holds a certification under Art. 32-2 or one recognised by PIPC notice and has taken the safety and rights-protection measures required, plus the measures needed to implement the certified matters in the destination country; or (5) PIPC recognises that the destination country or international organisation has a protection system, scope of rights guarantees and remedial procedures substantially equivalent to this Act. Before consent under route (1), the data subject must be informed of the items transferred, the destination country, timing and method, the recipient’s name and contact details, the recipient’s purpose and retention period, and the method, procedure and effect of refusing; any change requires fresh notice and consent. Contracts for cross-border transfer whose content breaches this Act are prohibited.

Evidence: Cross-border transfer register: recipient, country, data items, purpose, retention period; Separate consent UI and consent records, or archived privacy-policy disclosure page; Certification documents and description of measures implementing the certified matters in the destination country (route 4); The cross-border transfer contract with legal review confirming it does not breach PIPA; Records of fresh notice and consent where transfer particulars changed

Open tool: Transfer Matrix

A controller with no address or place of business in Korea that meets the revenue and data-holding thresholds set by Presidential Decree must designate a domestic representative in writing to handle: complaint handling and damage relief under Art. 31(4)5; the notifications under Art. 34(1)–(2) and the breach report under Art. 34(4); and the submission of materials under Art. 63(1). The representative must have an address or place of business in Korea; where the controller has established a Korean corporation, or a Korean corporation over which it exercises dominant influence on officer appointments or business operations, the representative must be designated from among those entities. The controller must educate, inspect and supervise the representative as prescribed by Presidential Decree. The representative’s name, address, telephone number and email must appear in the privacy policy. A violation by the representative in respect of those matters is deemed committed by the controller.

Evidence: Written designation of the domestic representative; Screenshot of the representative’s details in the published privacy policy; Records of education and business-status inspection of the representative; Register of complaints and breach reports handled by the representative

On becoming aware that personal information has been leaked or otherwise compromised, the controller must without delay inform data subjects of the Art. 34(1) items: the data items involved; the time and circumstances; the specific steps the data subject can take to minimise harm; the controller’s response measures and damage-relief procedures; the department and contact point for reports of harm; the legal rights arising from the breach — damages under Art. 39, statutory damages under Art. 39-2 and dispute mediation under Art. 43 — and how to exercise them; and other matters prescribed by Presidential Decree. The 2026 amendment adds Art. 34(2): where the controller becomes aware of circumstances indicating a possibility of a leak, as prescribed by Presidential Decree, it must without delay inform all potentially affected data subjects of the prescribed matters. The controller must also take measures to prevent the spread of harm, including recovery and deletion, and must report to PIPC or a specialised body without delay as prescribed.

Evidence: Incident response plan covering the Korean reporting path and Korean-language notice templates; Data-subject notice text covering every Art. 34(1) item; Record of the report filed with PIPC or the designated specialised body; Assessment record of a possible leak and proof that notification was sent; Execution records of measures preventing the spread of harm, including recovery and deletion

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

Article 29 requires technical, managerial and physical measures to ensure safety and prevent loss, theft, leakage, forgery, alteration or damage of personal information. Article 64-2(1)9 makes a leak itself surcharge-eligible unless the controller has taken all the measures necessary under Art. 29 — which makes the evidence of Art. 29 implementation the core of any defence. Article 26(4) requires the entrusting controller to supervise and train the entrusted processor, and a failure that results in a violation by that processor is itself surcharge-eligible.

Evidence: Evidence pack of safety measures across technical, managerial and physical categories; Configuration evidence for encryption, access control and log retention; Entrustment agreements plus training and supervision records for processors; Periodic security assessments with remediation closure records

Article 37-2 provides that where a decision is made by processing personal information through a fully automated system, including one applying artificial intelligence technology, and that decision significantly affects the data subject’s rights or obligations, the data subject may require the controller to refuse to apply it — except where the decision is made under Art. 15(1)1, 2 or 4. The data subject may also request an explanation of an automated decision already made. On receiving such a request the controller must, absent justifiable grounds, refrain from applying the automated decision or take necessary measures such as human re-processing and explanation. The controller must also publish, in a form the data subject can readily check, the criteria and procedure for automated decisions and the way personal information is processed.

Evidence: Inventory of automated decisions with the “significant effect” assessment; Published page describing the decision criteria, procedure and processing method; Register of refusal and explanation requests with handling and responses; Standard operating procedure and execution records for human re-processing; Written justification where a request is not acceded to on justifiable grounds

The 2026 amendment inserts Art. 30-3, expressly designating the business owner or representative as the person ultimately responsible for the processing and protection of personal information. Article 31 is strengthened accordingly: the controller must secure the staffing and budget the CPO needs, controllers meeting the Presidential Decree thresholds must file the designation, change or removal of the CPO with the competent authority, and such designation, change or removal must be resolved by the board of directors. Designating a person who does not meet the CPO qualification requirements, failing to obtain a board resolution, or failing to file, attracts administrative fines under Art. 75(2).

Evidence: Board resolution appointing the CPO and the filing acknowledgement; Documentation verifying the CPO qualification requirements; Evidence of the staffing and budget secured for the CPO; Internal governance document recording the owner’s or representative’s accountability

The 2026 amendment adds a proviso to Art. 32-2(1): controllers meeting thresholds set by Presidential Decree on revenue and processing scale must obtain privacy certification. That provision and Art. 75(2)15 (administrative fine for failing to obtain certification) commence on 1 July 2027, so the certification lead time should be planned in advance. Article 28-8(1)4 also makes holding such certification one of the routes for cross-border transfer, so certification carries both compliance and commercial value.

Evidence: Assessment of whether the size thresholds apply; Gap analysis and remediation plan for certification readiness; Certification application and certificate; Description of measures implementing the certified matters in the destination country, where used as a transfer route

Section 10.1(1) requires a report to the Commissioner where it is reasonable in the circumstances to believe that a breach of security safeguards creates a real risk of significant harm to an individual; section 10.1(2) requires the prescribed form and manner, as soon as feasible after the organisation determines the breach occurred; sections 10.1(3) and (6) require direct, conspicuous notification of affected individuals as soon as feasible (indirect notification in prescribed circumstances). Section 10.1(7) defines significant harm to include bodily harm, humiliation, damage to reputation or relationships, loss of employment, business or professional opportunities, financial loss, identity theft, negative effects on the credit record, and damage to or loss of property. Section 10.1(8) lists the real-risk factors: the sensitivity of the information involved, the probability that it has been, is being or will be misused, and any other prescribed factor.

Evidence: Methodology for assessing real risk of significant harm and the per-incident assessments; Report filed with the Commissioner and its acknowledgement; Individual notification text and proof of delivery method; Records of section 10.2 notifications to other organisations or government institutions

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

Schedule 1 clause 4.1.3 makes an organisation responsible for personal information in its possession or custody, including information transferred to a third party for processing, and requires contractual or other means to provide a comparable level of protection during that processing. For Canadian data handed to a Chinese parent, offshore cloud or labelling vendor this means: purpose limitation and no-secondary-use clauses in the data processing agreement, sub-processor approval, a security control schedule, audit and inspection rights, incident notification timelines, a government access request and notification mechanism, and return or destruction on termination. On transparency, the OPC expects organisations to state in their privacy policy that personal information may be processed outside Canada and thereby become subject to local law.

Evidence: Data processing agreement with comparable-protection, sub-processor and audit clauses; Vendor security due diligence questionnaire and assessment conclusion; Privacy policy wording disclosing offshore processing; Evidence of data return or destruction on termination

Open tool: Transfer Matrix

Section 10.3(1) requires an organisation to keep and maintain a record of every breach of security safeguards involving personal information under its control, in the prescribed form — not only those meeting the real-risk threshold — and the Commissioner may request access to it. So even where the assessment concludes that no report is required, the assessment itself must be retained, or the organisation cannot substantiate its decision in an investigation. Knowingly contravening section 10.3(1) is an offence under section 28.

Evidence: Complete breach register, including incidents assessed as not reportable; Risk assessment conclusion and reasoning for each incident; Retention period and access control policy for the register; Procedure for producing the register to the Commissioner

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

The Schedule 1 principles require purposes to be identified at or before collection, knowledge and consent for collection, use and disclosure, collection limited to what is necessary for the identified purposes, and collection by fair and lawful means. The recurring AI flashpoint is whether using user input, conversation logs or uploads for model training falls within the original purpose; in practice, list the training use separately, explain it understandably, offer a choice, and re-obtain consent on a change of purpose. The limiting use, disclosure and retention principle also requires retention periods and destruction at expiry, which directly constrains how long prompt logs and training snapshots may be kept.

Evidence: Purpose inventory and necessity analysis for each collection; Screenshots and version history of consent interfaces, including the separate training-use explanation; Retention matrix and evidence of destruction at expiry; Process and records for re-obtaining consent on a change of purpose

The individual access principle requires an organisation, on request, to inform an individual of the existence, use and disclosure of their personal information and give access, and to allow them to challenge its accuracy and completeness and have it amended. The challenging compliance principle requires a designated individual accountable for compliance and procedures for individuals to challenge it. Section 14 lets a complainant apply to the Federal Court for a hearing on matters covered by the Commissioner’s report after receiving it or being notified the investigation was discontinued. Define in advance: the search scope for access requests (whether prompt logs, vector stores and model outputs are included), identity verification, how third-party information is handled, and how refusals are documented.

Evidence: Access request procedure and documented search scope; Access request log (receipt date, response date, what was provided or refused and why); Designation of the individual accountable for compliance and the published channel; Records of compliance challenges received and how they were handled

Processing digital personal data must rest on the Data Principal’s consent (or fall within a statutory legitimate use), with a notice given at or before the request for consent describing the personal data to be processed, the purpose, how to exercise rights and how to complain to the Board. Consent must be free, specific, informed, unconditional and unambiguous, signified by a clear affirmative action, and limited to the personal data necessary for the specified purpose. It may be withdrawn at any time with comparable ease.

Evidence: Consent notice text, including the option of the languages listed in the Act alongside English; Consent and withdrawal records; Mapping of purposes to the data items necessary for them; Records showing downstream processing stopped after withdrawal

A Data Fiduciary must take reasonable security safeguards to prevent a personal data breach, including in respect of data held by its Data Processors. This carries the highest penalty in the Schedule, up to ₹250 crore. In practice it must cover access control, encryption, logging, vendor management and incident exercises, with implementation evidence that can be shown to the Board.

Evidence: Inventory of security safeguards with implementation evidence; Data Processor contracts with the security requirements annex; Access control and log audit records; Incident exercise records

On a personal data breach, the Data Fiduciary must give notice to the Data Protection Board and to each affected Data Principal in the prescribed form and manner. A personal data breach is defined as any unauthorised processing of personal data, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access, that compromises the confidentiality, integrity or availability of personal data. Failure to notify attracts up to ₹200 crore.

Evidence: Incident response plan including the Indian notification path; Record of the notice filed with the Board; Notice text to affected Data Principals and proof of dispatch; Assessment record characterising the incident as a breach

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

Processing the personal data of a child, or of a person with disability whose lawful guardian acts on their behalf, is subject to the additional obligations in s.9. Breach attracts up to ₹200 crore, the same tier as the breach-notification duty, reflecting India’s emphasis on minors’ data. AI products for education, gaming, social or companionship use targeting India need age assurance and guardian-consent mechanisms.

Evidence: Description of the age-assurance mechanism with accuracy evaluation; Guardian consent records; Description of feature restrictions and default settings for children; Item-by-item compliance checklist for s.9

The Central Government may notify a Data Fiduciary or class of Fiduciaries as a Significant Data Fiduciary based on factors including the volume and sensitivity of personal data processed, risk to Data Principals’ rights, potential impact on the sovereignty and integrity of India, risk to electoral democracy, security of the State and public order. A Significant Data Fiduciary must: appoint a Data Protection Officer who is based in India, is responsible to the board of directors or similar governing body, represents the Fiduciary under the Act and is the point of contact for the grievance redressal mechanism; appoint an independent data auditor to evaluate compliance; and undertake other measures including periodic Data Protection Impact Assessments. Breach of s.10 attracts up to ₹150 crore.

Evidence: DPO appointment documents evidencing India-based status and reporting line; Independent data auditor engagement letter and audit report; Periodic Data Protection Impact Assessment reports; Records of the grievance redressal mechanism in operation

Section 16(1) empowers the Central Government to restrict, by notification, the transfer of personal data by a Data Fiduciary for processing to a country or territory outside India that it notifies. Section 16(2) preserves any Indian law providing a higher degree of protection or a stricter restriction on transfer — so sector rules such as financial and payments data-localisation requirements continue to prevail. Companies should monitor such notifications and keep the data architecture capable of switching the processing location away from a restricted country.

Evidence: Cross-border data flow inventory and processing-location register; Monitoring mechanism and review records for s.16 notifications; Applicability analysis of sectoral localisation rules in finance, payments and health; Processing-location switchover plan and rehearsal records

Open tool: Transfer Matrix

A Data Fiduciary must establish an effective grievance redressal mechanism and publish the means of contacting it so that Data Principals can complain about performance of the Act’s obligations, and must ensure that personal data is accurate, complete and consistent where it is used to make a decision affecting the Data Principal or is disclosed to another Data Fiduciary. In AI contexts, automated decisions based on inaccurate profiles are the paradigm risk under this duty.

Evidence: Published grievance channel and internal response-time rules; Grievance register with closure records; Data accuracy validation rules and execution logs; Inventory of data fields used in decisions and their refresh mechanism

The new exception permits third-party provision of personal data, and acquisition of publicly available sensitive information, without consent, provided the data is secured for use solely in creating statistical information — expressly including AI development that can be characterised as statistics creation. The accompanying controls are: publication of specified items (the name of the acquirer, or of the provider and recipient, and the content of the intended statistics creation); for third-party provision, a written agreement between provider and recipient that the provision is solely for statistics creation; and a prohibition on the acquirer and recipient using or re-providing the data for any other purpose. The precise scope and publication items are to be set by PPC rules.

Evidence: Published page stating the statistics-creation purpose, with archived copies; Written provider-recipient agreement limiting the provision to statistics creation; Technical and process controls preventing use or re-provision for other purposes; Description of the statistical processing pipeline with output samples; Internal legal assessment memo on the scope of the exception

Operators handling face-feature data must publicise specified items: the operator’s name, address and representative, the fact that face-feature data is handled, the purpose of use, the bodily characteristics the data derives from, and the procedure for responding to suspension requests. The grounds for an individual to demand suspension are relaxed so that no unlawful act need be shown, and providing face-feature data to third parties under the opt-out regime is prohibited. The method of publicity and the precise scope are to be set by cabinet order and PPC rules.

Evidence: Text of the face-feature-data notice and record of where it is published; Register of face-feature data processing: source characteristics, purpose, retention period; Records of suspension requests received and executed; System configuration evidence blocking opt-out third-party provision

The amendment imposes an express duty on contractors not to handle entrusted personal data beyond the scope necessary to perform the entrusted work, save where required by law or where urgently necessary for saving life, disaster relief or responding to an emergency. In parallel, where the entrustment contract agrees the entirety of the handling method and the measures enabling the entrusting operator to keep track of the contractor’s handling, that contractor is in principle exempted from the Chapter 4 obligations — but the no-excess-scope duty and the security control duty continue to apply.

Evidence: Entrustment contract fully specifying the handling method and the monitoring measures; Evidence of technical segregation between entrusted data and the vendor’s own data; Internal controls and access logs preventing own-purpose use; Records of any reliance on the emergency exception

Where the individual is under 16, consent and notification must be directed to their legal representative, subject to exceptions (the operator has a legitimate reason for not knowing the individual is under 16; the representative has authorised the individual’s business and the data was acquired in connection with it; the individual has no legal representative). The grounds for that individual to demand suspension of use of retained personal data are relaxed, and a new duty requires operators handling minors’ personal information to give priority to the minor’s best interests according to age and stage of development and to endeavour to take the measures necessary to avoid harming their rights and interests.

Evidence: Age-assurance mechanism and accuracy assessment records; Legal-representative consent workflow and records; Best-interests assessment documentation for minors; Description of feature restrictions and default settings applied to minors

Personally referable information containing descriptions that allow contact with a specific individual — location such as residence or workplace, telephone number, email address, Cookie ID and the like — becomes subject to the same prohibitions on improper use and improper acquisition as personal information, as do pseudonymously and anonymously processed information containing such descriptions. Acquiring such data by deception, or using it to facilitate unlawful acts, is therefore unlawful even where the data is not “personal information” in the holder’s hands.

Evidence: Lawfulness checks on the source of personally referable information; Supplier due diligence and contractual undertakings; Permitted-use and prohibited-use list including a ban on facilitating unlawful acts; Description of the acquisition method and the user-facing notice

The surcharge is calculated on the financial benefit obtained from the violating conduct, and is limited by whether the operator failed to exercise due care. Companies should therefore build and retain evidence of due care — compliance reviews, source-of-data checks, internal approvals; maintain a dedicated register for processing touching Arts. 19, 20(1) and 27(1) and the statistics exception; and be able to separate revenue related to the conduct from unrelated revenue in an investigation. The official outline uses a benchmark of 1,000 data subjects for the large-scale condition.

Evidence: Due-care evidence pack: reviews, approvals, training; Dedicated register of high-risk processing activities; Revenue attribution methodology and working papers for the processing concerned; Records of suspension and remediation once an issue is found

Before providing personal data to a third party under the notified opt-out regime, the provider must first confirm the recipient’s identity (name, address and representative) and purpose of use. Making false statements about the matters confirmed is subject to a non-penal fine. Exceptions apply where, at the time of acquisition, the data had been made public by the individual, a national body or a local government.

Evidence: Records confirming the recipient’s identity and purpose of use; Opt-out notification filing; Recipient due diligence and contract clauses; Evidence supporting reliance on the public-source exception

Keep a written justification for each export flow: (i) it falls within a purpose permitted by PDPL Article 29(1) or one of the three “other purposes” specified in Article 2 of this Regulation (necessary central processing, providing a service or benefit to the data subject, scientific research and studies); (ii) it does not prejudice national security or the Kingdom’s vital interests; (iii) an adequate level of protection exists outside the Kingdom, at least equivalent to that under the Law and Regulations; and (iv) it is limited to the minimum personal data needed. Article 29(3) disapplies the three conditions in cases of extreme necessity to preserve the life or vital interests of the data subject or to prevent, examine or treat disease.

Evidence: Export flow register (purpose, legal basis, recipient, data categories, volume); Minimisation reasoning and field-level evidence (pre- and post-transfer field comparison); Internal review note on national security and vital interests; Adequacy assessment conclusion and supporting material

Open tool: Transfer Matrix

Article 4(1) requires a controller relying on an exemption to implement one of: standard contractual clauses, binding common rules, or a certificate of accreditation. Article 4(2) sets out five exemption cases and their requirements: transfers between public bodies to implement an agreement to which the Kingdom is a party or to serve its interests must include standard personal data protection provisions in the relevant agreements or memoranda; non-recurring or time-limited transfers involving a limited number of data subjects must comply with the standard contractual clauses, or go to a recipient holding an approval certificate from an entity licensed by the Competent Authority with non-sensitive data; transfers necessary for central operations within a group of multinational entities require the controller and its affiliates to comply with binding common rules or the standard contractual clauses, or the recipient to hold an approval certificate; transfers to provide a service or benefit directly to the data subject without violating their expectations or interests must go to a certified recipient with non-sensitive data; and transfers necessary for scientific research and studies must be limited to the minimum data required and comply with the standard contractual clauses or go to a certified recipient with non-sensitive data. Article 4(3) requires the safeguards to ensure compliance with the Law and Regulations and to protect data subjects’ rights, including the right to complain to the Competent Authority and to seek compensation.

Evidence: Executed SDAIA standard contractual clauses or approved binding common rules; Recipient’s accreditation certificate and evidence the issuing body is licensed (where the certification route is used); Memo classifying each flow against the five cases in Article 4(2); Verification that the safeguards operate (access control, complaint and compensation channel, exercise of audit rights)

Open tool: Transfer Matrix

Article 7(1) requires a risk assessment before transfer in two cases: transfers or disclosures made under the Article 4 exemptions, and continuous or widespread transfer or disclosure of sensitive data outside the Kingdom. Article 7(2) requires the assessment to cover at least six elements: the purpose and legal basis for the transfer; a description of its nature, including the processing activities involved and their geographical scope; the appropriate safeguards implemented and their adequacy in ensuring a level of protection not less than that prescribed by the Law and Regulations; the measures used to limit the transfer to the minimum data required, in cases not exempted under Article 29(2)(c); the potential material or moral effects of the transfer and the likelihood of their occurrence; and the measures or controls to prevent potential risks or mitigate their effects. SDAIA’s Risk Assessment Guideline should be the baseline for the template.

Evidence: Transfer risk assessment report covering the six elements of Article 7(2); Analysis of the destination’s legal environment relied on in the assessment; Risk mitigation control list and implementation evidence; Re-assessment trigger rules and the history of re-assessments (changes of recipient, data category or legal environment)

Open tool: Transfer Matrix

PDPL Article 20 requires the controller to notify the Competent Authority upon becoming aware of any breach, damage or illegal access to personal data, and to notify the data subject where the incident would cause damage to their data or prejudice their rights and interests. Article 24(1) of the Implementing Regulation adds that, where the incident potentially causes harm to the personal data or to the data subject or conflicts with their rights or interests, the controller must notify the Competent Authority within no more than 72 hours of becoming aware; Article 24(2) allows supplementary filing in stages where not all required information can be provided within that window. In practice, fix the definition of “aware”, the cross-time-zone on-call and escalation path, and the notification templates in advance.

Evidence: Breach response plan with the definition of “aware” and a 72-hour clock chart; Competent Authority notification template and submission records; Data subject notification text and proof of delivery; Post-incident review report and corrective action tracker

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

Under PDPL Article 30(4)(c) and Article 34 of the Implementing Regulation the Competent Authority maintains a national register of controllers. Article 2 of the National Register Rules requires registration on the National Data Governance Platform where any of the following applies: the controller is a public entity; its main activity is based on personal data processing; it processes sensitive data; or an individual processes personal data for purposes exceeding personal or family use. Registration requires appointing a representative (for private entities, through the Platform by the authorised person), completing entity and representative details, and determining during the process whether a personal data protection officer must be appointed under Article 32 of the Implementing Regulation and the DPO Appointment Rules; where one is appointed, their details must be entered on the Platform. The Platform issues a registration certificate bearing a registration serial number, which may be made available to the public.

Evidence: Registration certificate from the National Data Governance Platform with its serial number; Representative designation document and authorisation chain; Memo determining whether a personal data protection officer is required; Change log and annual review record for the registered particulars

Article 32(1) of the Implementing Regulation and Article 5 of the DPO Appointment Rules set three mandatory cases: a public entity providing services involving large-scale processing; core activities based on processing operations that by their nature require regular and systematic monitoring of data subjects; and core activities based on processing sensitive personal data. The Rules add criteria: large scale is judged on the number of data subjects, volume and type of data, geographical scope and categories of data subjects; “regular” means continuous, at set intervals or periodic, and “systematic” means carried out through technological systems, following a specific methodology, or as part of an overall strategy or plan — with examples including health and fitness data from wearables, behavioural analytics for risk assessment, location tracking, cookies and surveillance cameras. Activities are core where the controller cannot provide its products or services without processing personal data. The DPO may be an executive, an employee or an external contractor, and is responsible for acting as the direct contact point with the Competent Authority, supervising impact assessments and audit reporting, enabling data subjects to exercise their rights, notifying the Competent Authority of breaches, handling requests and complaints, monitoring and updating the records of processing activities, and handling violations and corrective actions.

Evidence: Determination memo against the three cases and the large-scale / regular / systematic / core-activity criteria; DPO appointment document, role description and qualifications; Record of the DPO details entered on the National Data Governance Platform; DPO activity records (impact assessment oversight, breach notifications, request and complaint handling)

PDPL Article 22 requires the controller to conduct an impact assessment of personal data processing in relation to any product or service, based on the nature of its activity and in accordance with the Regulations. Unlike the EU DPIA, the trigger is tied to the product or service, so an AI company should reassess whenever it launches a feature, swaps models, widens data sources or changes how outputs are used, rather than treating it as a one-off. Article 32(3)(b) of the Implementing Regulation makes supervising impact assessment procedures, audit and control reporting, documenting the results and issuing recommendations an express duty of the personal data protection officer.

Evidence: Impact assessment reports organised by product or service; Trigger rules for reassessment (new feature, model swap, data source change, change of output use); DPO oversight notes and recommendations on each assessment; Verification records that mitigation measures were implemented

PDPL Article 19 requires the controller to implement all necessary organisational, administrative and technical measures to protect personal data, including during transfer, in accordance with the controls set out in the Regulations. Article 41 adds that any person engaged in processing personal data must protect its confidentiality even after their occupational or contractual relationship ends. Practically, confidentiality undertakings and access-revocation workflows for outsourced labelling teams, departing engineers and temporary contractors must be evidenced, and the duty survives termination.

Evidence: Security control catalogue and implementation evidence (encryption, access control, transport protection, logging); Confidentiality undertakings for staff and subcontractors, with post-termination survival clauses; Account and access revocation workflow records; Periodic security assessment and remediation records

PDPL Article 31 requires controllers to maintain records of personal data processing activities for the period prescribed by the Regulations, based on the nature of their activity, and to make them available whenever the Competent Authority requests. The record must contain at least the controller’s contact details, the purpose of processing, a description of the categories of data subjects, any other entity to which personal data has been or will be disclosed, whether personal data has been or will be transferred outside the Kingdom or disclosed to an entity outside it, and the expected retention period. For AI companies the “outside the Kingdom” field must reflect where training datasets, inference request logs, vector stores and model checkpoints actually reside and are accessed from, not merely the nominal contracting counterparty.

Evidence: Record of processing activities covering the six elements of Article 31; Inventory of where data is stored and accessed from (training sets, logs, vector stores, model checkpoints); Retention policy and evidence of deletion at expiry; Procedure and history for producing the record to the Competent Authority

Section 37(5) requires a Data Controller falling under the second paragraph of s.5 to designate in writing a representative of the Data Controller who must be in Thailand and who is authorised to act on the controller’s behalf, without any limitation of liability, in respect of the controller’s purposes for collecting, using or disclosing personal data. Breach falls squarely within the THB 3 million fine under s.83. Section 38 paragraph one, however, carves out two categories that must be applied first: a controller that is a public authority as prescribed and announced by the Committee; and a controller engaged in the profession or business of collecting, using or disclosing personal data whose processing is not of the nature described in s.26 (sensitive personal data) and which does not hold a large amount of personal data as prescribed by the Committee under s.41(2). A smaller overseas controller that handles no sensitive data may therefore not need a representative — but the volume threshold must be taken from the Committee’s notification and the assessment documented; the exemption must not be assumed. Section 38 paragraph two applies s.37(5) and paragraph one mutatis mutandis to a Data Processor of a controller caught by s.5 paragraph two.

Evidence: Assessment record on whether the s.38 paragraph one exemption applies, covering both the sensitive-data nature test and the volume threshold; Written instrument designating and authorising the representative, in Thai and English; Published Thai address and contact details of the representative; Register of data-subject requests and regulator correspondence handled by the representative; Agreed liability and cooperation arrangements between representative and controller

Section 37(4): the Data Controller must notify the Office of any personal data breach without delay and, where feasible, within 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of persons. Where the breach is likely to result in a high risk to those rights and freedoms, the controller must also notify the data subject of the breach and the remedial measures without delay. The rules and procedures for notification and the exemption are set by the Committee.

Evidence: Incident response plan defining when the 72-hour clock starts; Record of the time of awareness and the acknowledgement of the notification filed; Risk assessment record distinguishing “unlikely to result in a risk” from “high risk”; Notice text to data subjects with the remedial measures described

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

Section 37(1) requires the Data Controller to provide appropriate security measures preventing unauthorised or unlawful loss, access, use, alteration, correction or disclosure of personal data, to review them when necessary or when technology changes, and to meet the minimum standard specified and announced by the Committee. Section 37(2) requires the controller, where personal data is provided to other persons or legal persons, to take action preventing them from using or disclosing it unlawfully or without authorisation. Section 37(3) requires an examination system for erasure or destruction when the retention period ends, the data becomes irrelevant or exceeds the necessary purpose, or the data subject requests erasure or withdraws consent.

Evidence: Inventory of security measures mapped to the Committee’s minimum standard; Security-measure review records, including reviews triggered by technology change; Use and disclosure restriction clauses in downstream recipient contracts; Operating logs of the erasure and destruction examination system

Section 28: where a Data Controller sends or transfers personal data to a foreign country, the destination country or international organisation must have an adequate data protection standard and the transfer must follow the rules prescribed by the Committee under s.16(5). Exceptions include compliance with the law; consent obtained after the data subject has been informed of the inadequate standard of the destination; necessity for performance of a contract to which the data subject is a party or for pre-contractual steps at their request; performance of a contract between the controller and another person or legal person for the data subject’s benefit; and prevention or suppression of danger. Section 29 adds an intra-group route: where a controller or processor in Thailand has a personal data protection policy for sending or transferring personal data to a controller or processor abroad in the same affiliated business or group of undertakings, for the purpose of jointly operating that business, and the Office has reviewed and certified that policy, transfers made in accordance with it are exempt from s.28.

Evidence: Cross-border transfer register: recipient, country, purpose, data categories; Adequacy assessment of the destination or an assessment of the exception relied on; Where consent is relied on: the notice informing the data subject that the destination standard is inadequate, plus consent records; The s.29 group personal data protection policy and the Office’s review and certification; Transfer contract clauses with the recipient

Open tool: Transfer Matrix

Collection, use or disclosure of personal data must rest on a lawful basis, and sensitive personal data under s.26 — such as racial or ethnic origin, political opinions, religious beliefs, sexual behaviour, criminal records, health data, disability, trade union information and biometric data — in principle requires the data subject’s explicit consent, with only limited statutory grounds permitting processing without it. Section 84 singles out breaches of s.26 paragraph one or three for the highest fine tier in the Act, up to THB 5 million.

Evidence: Mapping of processing activities to lawful bases; Explicit consent UI and consent records in Thai for sensitive data; Assessment of any statutory ground relied on to process without consent; Rules for identifying and tiering sensitive data

Section 39 requires the Data Controller to maintain at least the following records, in written or electronic form, so that the data subject and the Office can check them: the personal data collected; the purpose of collection for each category; details of the Data Controller; the retention period; the rights and methods of access, including the conditions on who may access and how; use or disclosure under s.27 paragraph three; rejections of requests or objections under ss.30 para 3, 31 para 3, 32 para 3 and 36 para 1; and an explanation of the appropriate security measures under s.37(1). Paragraph two applies the duty mutatis mutandis to the representative of a controller under s.5 paragraph two, and paragraph three allows items (1) to (6) and (8) to be disapplied for a controller that is a small organisation under rules prescribed by the Committee — an exemption that depends on those rules and whose applicability must be documented.

Evidence: Record of processing activities covering every s.39 item; Section explaining the security measures; Records of rejected requests and objections; Record update and version-control mechanism

Section 41: a Data Controller and a Data Processor must designate a Data Protection Officer where: the controller or processor is a public authority as prescribed and announced by the Committee; the activities of collecting, using or disclosing personal data require regular monitoring of the personal data or the system because of the large number of personal data as prescribed and announced by the Committee; or the core activity is the collection, use or disclosure of personal data under s.26, that is, sensitive personal data. Controllers or processors in the same affiliated business or group of undertakings operating jointly as prescribed under s.29 paragraph two may jointly designate one DPO.

Evidence: DPO designation document and published contact details; Assessment record of which trigger applies: volume threshold, core activity or public authority; Where jointly designated in a group, arrangements ensuring each establishment can reach the DPO; Description of the resources and independence afforded to the DPO

Build and maintain an item classification register covering advanced computing integrated circuits and their software and technology; high bandwidth memory (3A090.c with the corresponding 3D001 and 3E001), whose licence requirement for Macau and D:5 destinations does not apply to deemed exports or deemed reexports; and AI model weights (ECCN 4E091, a worldwide licence requirement whose licence requirement does not apply to deemed exports or deemed reexports for permanent regular employees of entities headquartered in specified destinations). The classification must be wired into procurement, cloud deployment and model release processes, so every new hardware model or model release passes the classification gate again.

Evidence: Item classification register mapping model to ECCN to licence requirement to the citing provision; Determination and technical rationale for whether model weights fall under 4E091; Reclassification triggers and review rules for new models, versions and destinations; Where applicable, advisory opinion requests submitted to BIS and the responses

Beyond list-based controls, a licence is required where the exporter has knowledge that the item is destined for: the development, production, operation, installation (including on-site installation), maintenance (checking), repair, overhaul or refurbishing of a supercomputer located in or destined to Macau or a Country Group D:5 destination; incorporation into, or the development or production of, any component or equipment to be used in such a supercomputer; the development or production of ICs destined to a facility located in Macau or a D:5 destination where production of advanced-node ICs occurs; and, where the technology node is unknown, Category 3 items in Product Groups B, C, D or E. Companies must translate this knowledge standard into workable customer due diligence questionnaires, red-flag lists and release gates.

Evidence: End-user and end-use statement templates and the signed documents; Red-flag list and due diligence questionnaire covering supercomputer and advanced-node facility identification; Customer and destination screening records including restricted party screening; Release gate approval records and a ledger of refusals and escalations; Use confirmation records for installation, operations and repair services

§742.6(a)(13) imposes a worldwide licence requirement for the export, reexport and in-country transfer of items under ECCN 4E091, and (b)(14) provides that applications are reviewed under a presumption of denial for end users headquartered, or with an ultimate parent headquartered, outside the destinations listed in paragraph (a) of supplement no. 5 to part 740. Companies must therefore control where model weights are stored, who can access them and how they move, bring who may download the weights, which region they are copied to and which entity controls them into access control and audit, and assess case by case whether overseas research collaborations, customer on-premises deployments or open releases amount to a controlled transfer.

Evidence: Model weight asset register (version, storage region, controlling entity); Access control policy and access logs for weights; Controlled-transfer assessments for cross-border transfers, on-premises deliveries and open releases; Deemed export applicability determinations for employees and collaborators; Licence application materials and end-user information where an application is required

From 15 January 2026 the licence review policy for exports to China and Macau of the Nvidia H200 and its equivalents and less advanced chips changes from presumption of denial to case-by-case, subject to two sets of conditions: the semiconductor must have been commercially available in the United States at publication of the rule; and the exporter must certify that there is sufficient supply of the product in the United States, that production for exports to China will not divert global foundry capacity for similar or more advanced products for U.S. end users, that the recipient has demonstrated sufficient security procedures, and that the item undergoes independent third-party testing in the United States to verify its performance specifications. Buyers should therefore agree the certification package, third-party testing arrangements and lead times with suppliers in advance, and write the review uncertainty into the delivery and excuse clauses of purchase contracts.

Evidence: Recipient security procedure documentation (physical security, access control, use restrictions, audit cooperation); Agreed certification checklist and allocation of responsibility with the exporter; Arrangements and reports for independent third-party performance testing in the United States; Licence condition, delivery extension and excuse clauses in the purchase contract; Licence application status tracking and contingency records for alternative models or deployment locations

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

Art. 23 enumerates five obligations: (1) adopt internal security management systems and operating procedures, name a cybersecurity officer and allocate protection responsibility; (2) deploy technical measures against computer viruses, network attacks and intrusions; (3) deploy technical measures to monitor and record network operating status and security events, and retain the relevant network logs for no less than six months; (4) apply data classification and backup and encryption of important data; and (5) perform any other duties set by law or administrative regulation. The aim is to keep the network free from interference, damage and unauthorised access, and to prevent network data from being leaked, stolen or tampered with. A CIIO carries the additional duties in Art. 36 on top of Art. 23.

Evidence: MLPS grading report, expert review opinion and public-security filing certificate; MLPS assessment report and remediation closure records; Appointment letter for the cybersecurity officer; Security management policy and operating-procedure set; Backup and encryption policy for important data, with drill records

Deploy technical measures to monitor and record network operating status and security events, and retain the relevant network logs for no less than six months. For a model service this must cover authentication and login logs, API call logs, and audit logs of administrative operations and data exports, with integrity and tamper-resistance assured.

Evidence: Log-collection scope note and field inventory; Screenshots of the retention policy configuration showing the retention period; Description of log integrity and tamper-resistance controls; Records of sample log retrievals

Network products and services must meet the mandatory requirements of the relevant national standards and must not contain malicious programs; on discovering a security defect or vulnerability the provider must take remedial action immediately, inform users as required and report to the competent authority. Providers must also maintain security support for their products and services and may not terminate it within the prescribed or agreed period. Where a product collects user information, the provider must disclose this and obtain consent.

Evidence: List of applicable mandatory national standards and conformity evidence; Vulnerability management policy, SLA and remediation log; Records of user notifications and reports to the competent authority; Contract clauses on the security-maintenance period and the product lifecycle announcement

When arranging network access or domain registration, handling fixed-line or mobile subscriptions, or providing users with information-publishing or instant-messaging services, the operator must require real identity information when signing the agreement or confirming the service; where the user does not provide it, the service must not be supplied.

Evidence: Design note for real-identity authentication, listing the factors used and the verification channel; Coverage statistics and product evidence showing feature restrictions for unauthenticated users; Identity-authentication clauses in the user agreement; Note on data minimisation and encrypted storage of authentication data

Maintain a cybersecurity incident response plan and promptly deal with system vulnerabilities, computer viruses, network attacks and intrusions; on an incident that endangers cybersecurity, activate the plan immediately, take remedial measures and report to the competent authority as required.

Evidence: Cybersecurity incident response plan with severity criteria and reporting routes; Annual drill plan and drill report; Incident tickets and timeline records; Text of reports to the competent authority and the receipts

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

Under Article 7(4) keep a dedicated personal data record containing the controller’s and DPO’s details, a description of data categories, the list of persons authorised to access the data, processing times, limits and scope, the erasure and modification mechanism, the purpose of processing, any data relating to cross-border movement and processing, and the technical and organisational information-security measures; produce it to the Data Office on request. Article 20 additionally requires encryption and pseudonymisation, continuous confidentiality and integrity of processing systems, timely restoration of access after failure, and regular testing and evaluation of the measures, in line with international best practice.

Evidence: Personal data processing record covering each element of Article 7(4); Access authorisation list and periodic review records; Encryption and pseudonymisation implementation note and key management policy; Testing and evaluation reports on the effectiveness of security measures

Article 10 requires a DPO with sufficient skills and knowledge in three cases: processing that would create a high-level risk to confidentiality and privacy because of new technologies or data volume; processing involving a systematic and comprehensive assessment of sensitive personal data, including profiling and automated processing; and processing of a large volume of sensitive personal data. The DPO may sit inside or outside the UAE but their contact details must be notified to the Data Office. Article 21 requires an impact assessment before using new technologies posing high risk, and makes it mandatory in the two cases above; it must contain at least a systematic description of the operations and purpose, an assessment of necessity and proportionality, a risk assessment and mitigation measures, must be done in coordination with the DPO, and must be reviewed as risk levels change.

Evidence: DPO appointment letter, role description and qualifications; Record of notifying the Data Office of the DPO’s contact details; Impact assessment report covering the four elements in Article 21(3); Periodic review records and the trigger criteria for reassessment

Article 18 gives data subjects the right to object to decisions resulting from automated processing, including profiling, in particular those with a legal impact on or adverse effect for them. The objection is unavailable only where the automated processing is agreed in the contract with the controller, required by other applicable legislation, or covered by the data subject’s prior consent. Even then the controller must adopt appropriate measures to protect the privacy and confidentiality of the data and must not prejudice the data subject’s rights, and must include a human element in reviewing automated decisions at the data subject’s request.

Evidence: Automated decision inventory with the Article 18(2) exception relied on for each; Human review procedure and sample review records; Objection intake channel and case log; Retained contract or consent wording covering the automated processing

Article 9 requires the controller, on becoming aware of any breach or violation that would prejudice the privacy, confidentiality or security of a data subject’s personal data, to notify the Data Office within the period and under the procedures set by the Executive Regulations, attaching the nature and form of the breach, its causes, the approximate number and records affected, the DPO’s details, likely effects, corrective measures taken or proposed, and supporting documents; the data subject must also be notified where the breach would prejudice the privacy and confidentiality of their data, and a processor must notify the controller as soon as it becomes aware. On transfers, Article 22 permits transfers to states or provinces with data protection legislation and a judicial or regulatory authority able to impose measures, or with which the UAE has a bilateral or multilateral data protection agreement; Article 23 provides six alternative routes where an adequate level is not available — a binding contract, explicit data-subject consent, judicial claims, performance of a contract, international judicial cooperation, and public interest. Select and document a route for each flow.

Evidence: Breach response plan and notification template covering the six elements of Article 9(1); Breach register and evidence of notifications to the Data Office and data subjects; Transfer register (flow, recipient, Article 22 or 23 route relied on); Executed transfer contract under Article 23(1)(a) and its enforceable-measures clauses

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

Open tool: Transfer Matrix

New York City Local Law 144 of 2021 prohibits employers and employment agencies from using an automated employment decision tool unless the tool has been subject to a bias audit within one year of its use. The audit must be performed by an independent auditor following the methodology in the DCWP rule, and must be renewed before it lapses or use of the tool must stop.

Evidence: Auditor qualification and independence statement; Bias audit report identifying the audit date and the tool version covered; Description of the dataset used and the sample sizes; Expiry reminders and the plan for re-auditing

Model Card

Employers and employment agencies must provide the required notices to candidates and employees. DCWP clarified in its June 2023 revised presentation materials that the notice must be provided 10 business days before use of an automated employment decision tool. The notice typically states that the tool will be used, the job qualifications and characteristics it assesses, and how to request an alternative process or accommodation.

Evidence: Candidate notice template and dispatch log with timestamps evidencing the 10 business days; Notice records for existing employees; Intake log for requests for an alternative process or accommodation; Hiring process timeline chart marking the notice checkpoint

Information about the bias audit must be made publicly available. In practice the summary of results is published on the careers page or company website, identifying the tool audited, the audit date and the selection or impact ratios by category. DCWP accepts public complaints against employers that fail to post a summary of the bias audit results.

Evidence: Archived copy of the published summary page with its publication date; Reconciliation between the published summary and the audit report; Note on page accessibility and retention period; Archive of historical versions

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

The Business Improvement Exception lets an organisation use, without consent, personal data it previously collected in accordance with the PDPA, for improving or enhancing existing goods and services or developing new ones; improving or developing methods or processes for business operations relating to those goods and services; learning or understanding individuals’ behaviour and preferences, including for segmented groups; and identifying, personalising or customising goods and services for individuals. Before relying on it, confirm and record that the purpose cannot reasonably be achieved without the data in individually identifiable form.

Evidence: Written applicability assessment relying on the Business Improvement Exception; Traceability record of the lawfulness of the source collection; Technical justification that the purpose cannot be met with non-identifiable data; Statement linking the training purpose to the organisation’s goods and services

For R&D without immediate product application, the Research Exception is available only if all of the following hold: the research purpose cannot reasonably be accomplished unless the data is in individually identifiable form; there is a clear public benefit; the results will not be used to make any decision affecting the individual; and any published results do not identify the individual. Disclosure to another party under the exception — including joint development of new AI systems — additionally requires an assessment that obtaining consent would be impracticable.

Evidence: Point-by-point assessment of the four Research Exception conditions; Public-benefit justification and research protocol; Internal undertaking and technical segregation ensuring results are not used in decisions affecting individuals; Data-use restriction clauses in the joint research agreement

When deploying a product with AI recommendation or decision features, explain so far as practicable: the product function requiring collection and processing of personal data; a general description of the types of personal data collected and processed; how that processing is relevant to the product feature; and the specific data features most likely to influence the feature’s output. Delivery may be through pop-up notifications or publicly accessible written policies, as the organisation judges appropriate.

Evidence: AI feature explanation text including the features influencing outputs; Screenshots and delivery logs of the notification surface; Consistency check between feature-importance analysis and public statements; Accessibility verification of the published policy page

Section 12 of the PDPA requires organisations to develop policies and practices to meet their obligations. Organisations using AI systems should set out in written policies the practices and safeguards adopted to achieve fairness and reasonableness, at a level of detail proportionate to the risk of the use case — potential harm to the individual and the AI system’s degree of autonomy. Section 12(d) requires disclosure on request, but the guidelines recommend proactive publication on the organisation’s website, including a short-form version.

Evidence: Written AI governance policy covering fairness and reasonableness safeguards; Record of per-use-case risk tiering and the resulting level of disclosure; Public-facing page and short-form policy; Minutes of the annual policy review

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

Service providers that build bespoke or fully customisable AI systems and thereby process personal data as data intermediaries should, at the pre-processing stage, use data mapping and labelling to track what enters the training dataset, and maintain provenance records identifying the source of training data and how it was transformed during data preparation. These records support assessment of unauthorised access or modification of the training set, and let the deploying organisation judge whether a notifiable data breach has occurred and the scope of impact of any change to the training set.

Evidence: Training-data mapping and labelling inventory; Provenance records tracing source to transformation to inclusion; Training-set integrity checks and change audit logs; Records identifying sensitive personal data and the calibrated handling applied

Data Card — datasheet for a training, validation or test dataset

Under the Data dimension, govern the source, licensing status, quality and bias risk of training data, and be able to explain how the data was obtained and processed. In the Singapore context this links directly to PDPC’s requirement to document reliance on the Publicly Available Exception.

Evidence: Training-data inventory with licensing status; Provenance records of source and transformation; Data quality and bias assessment report; Dataset admission approval records

Data Card — datasheet for a training, validation or test dataset

Under the Trusted Development and Deployment dimension, run baseline evaluations of model capabilities, known risks and limitations, and disclose the scope, method and results to downstream integrators and deployers through a model card or equivalent, so they can judge the boundaries of appropriate use.

Evidence: Model card or system card covering evaluation method and results; Safety evaluation and red-teaming reports; List of known limitations and out-of-scope uses; Version change and re-evaluation records

Model Card

Under the Incident Reporting dimension, put in place monitoring capable of detecting anomalous model behaviour, misuse and harm events, define internal escalation paths and criteria for external notification, and retain records of how incidents were handled. The mechanism must interlock with the PDPA breach-notification deadline of three calendar days after assessment.

Evidence: AI incident severity criteria and response plan; Incident register with closure records; Misuse monitoring and content moderation logs; Documented interlock with the PDPA breach-notification workflow

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

Under the Accountability dimension, define the responsibility boundaries of model developers, application integrators and end deployers, reflect them consistently in customer contracts and internal governance documents, and place each risk with the party best placed to control it.

Evidence: AI governance responsibility matrix (RACI); Responsibility allocation clauses in customer contracts; AI governance committee charter and meeting minutes

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

Under the Content Provenance dimension, apply labelling, watermarking or metadata so that downstream users and platforms can identify machine-generated content. Where the same product also enters Korea, note that Art. 31 of the Korean AI Framework Act makes labelling of generative output a statutory duty.

Evidence: Technical description of the content-marking scheme; Watermark or metadata implementation and robustness test records; Screenshots of the user-facing indication

Model Card

Under the Testing and Assurance dimension, supplement self-assessment with independent third-party testing to raise the credibility of external claims. Singapore has built a testing ecosystem around the AI Verify testing framework and toolkit, including tester accreditation, and participation is commonly probed in tenders and large-customer due diligence.

Evidence: Third-party test report with scope statement; Remediation closure records for test findings; Consistency check between public claims and test conclusions

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

Set the DPO’s competency requirements and scope of duties in line with JPDP’s Data Protection Officer (DPO) Competency Guideline of 1 August 2025, make the designation, and register the DPO under JPDP’s DPO registration guidance. JPDP issued a Management of DPO Training Service Providers Guideline at the same time, indicating regulatory expectations about the source of DPO training; training providers should be checked against it.

Evidence: DPO appointment document and terms of reference; Qualification check against the JPDP Competency Guideline; Records of the DPO registration filing; DPO training records and checks on the training provider

First determine whether the company’s Malaysian activity falls within the classes of data controllers published by JPDP — communications, banking and finance, insurance, health, education, tourism and hospitality, employment agencies, real estate development, utilities, pawnbrokers, moneylenders and others. If so, submit a new or renewal application and obtain the registration certificate; JPDP states that complete applications are reviewed and the status notified within 14 working days. Changes to registered particulars, replacement of a certificate or cancellation must be handled under JPDP’s separate guidance.

Evidence: Assessment of whether a prescribed class applies; Registration application pack and the registration certificate; Records of any change, replacement or cancellation of registration; Certificate validity tracking and renewal reminder mechanism

Build a breach response process that can be triggered on the Malaysian side and file through JPDP’s Data Breach Notification (DBN) system. JPDP publishes a DBN system user manual; account provisioning, preparation of the reporting fields and internal rehearsals should be completed in advance rather than improvised during an incident. Chinese vendors acting as processors should contractually commit to immediate notification to the Malaysian customer so it can file on time.

Evidence: DBN system account provisioning and access records; Incident response plan including the Malaysian filing path; Filing records and acknowledgements; Contractual notification-deadline clauses with processors; Internal rehearsal records

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

Act 709 is structured around a set of personal data protection principles — notice and choice, consent, disclosure, security, retention, data integrity and access. Companies should implement: a bilingual privacy notice in Malay and English; consent capture and record-keeping; restrictions and approvals for external disclosure; security measures; a retention schedule and destruction mechanism; maintenance of data accuracy; and a process for handling data-subject access and correction requests. The precise statutory wording, including as amended in 2024, must be taken from the official text of the Act.

Evidence: Bilingual privacy notice in Malay and English; Consent records and withdrawal mechanism; Retention schedule and destruction execution records; Register of access and correction requests; Evidence of security measures implemented

A business must conduct a risk assessment before initiating any processing that presents significant risk to consumer privacy. The enumerated activities are selling or sharing personal information; processing sensitive personal information (excluding processing of employee and independent contractor sensitive information solely for administering compensation payments, determining and storing employment authorization, administering benefits, providing legally required reasonable accommodation or statutory wage reporting); using ADMT for a significant decision concerning a consumer; and using automated processing to infer or extrapolate a consumer intelligence, ability, aptitude, work performance, economic situation, health including mental health, personal preferences, interests, reliability, predispositions, behaviour, location or movements based on systematic observation of that consumer acting as an education program applicant, job applicant, student, employee or independent contractor.

Evidence: Risk assessment report structured to the elements of section 7152; Processing inventory mapped to the triggering paragraphs; Evidence that the assessment predates the start of processing; Update triggers and records of assessment updates

A business whose processing presents significant risk to consumer security must complete a cybersecurity audit. The triggers are meeting the threshold in Civil Code section 1798.140(d)(1)(C), or meeting the (d)(1)(A) revenue threshold and having processed the personal information of 250,000 or more consumers or households, or the sensitive personal information of 50,000 or more consumers, in the preceding calendar year. First audit reports are phased by revenue: due 2028-04-01 where 2026 annual gross revenue exceeded $100,000,000 as of 2027-01-01, covering 2027-01-01 to 2028-01-01; due 2029-04-01 where 2027 revenue was between $50,000,000 and $100,000,000 as of 2028-01-01, covering 2028-01-01 to 2029-01-01; and due 2030-04-01 where 2028 revenue was below $50,000,000, covering 2029-01-01 to 2030-01-01. After 2030-04-01 the audit becomes a rolling annual obligation.

Evidence: Trigger determination working papers with consumer, household and sensitive information counts; Cybersecurity audit report; Remediation register for audit findings with closure evidence; Revenue evidence for the phasing tier and the calendar reminders for each due date

SOC 2 Type II readiness checklist (Trust Services Criteria)

A business that uses ADMT to make a significant decision concerning a consumer must provide a Pre-use Notice, and unless an exception applies must include in it the right to opt out of that use and how to exercise it. A business using ADMT for significant decisions before 2027-01-01 must be compliant no later than 2027-01-01; a business that begins on or after that date must be compliant at any time it is using ADMT for a significant decision.

Evidence: Pre-use Notice text and screenshots of where it is displayed; Inventory of ADMT uses distinguishing significant decisions from other uses; Delivery records and version control for the notice; Project plan and sign-off evidencing readiness by 2027-01-01

A business must establish and publicize channels and workflows for requests to opt out of ADMT (section 7221) and requests to access ADMT (section 7222). Where the business relies on an exception in section 7221(b) instead of offering an opt-out, it must say so in the Pre-use Notice and give the consumer the explanation that section requires.

Evidence: Screenshots of the opt-out and access request intake pages; Request log recording intake time, identity verification, outcome and turnaround; Memo on any exception relied on and its legal basis; Records of human review and of notifying the consumer of outcomes

First determine whether the company meets the CCPA definition of a business. Effective 2025-01-01 the annual gross revenue threshold in Civil Code section 1798.140(d)(1)(A) is $26,625,000 as adjusted for inflation. The determination should be documented and reviewed annually because the risk assessment, cybersecurity audit and ADMT duties all depend on it.

Evidence: Business-status determination memo covering revenue, consumer counts and the share of revenue from selling or sharing data; Annual review record; Applicability matrix across group entities

For risk assessments conducted in 2026 and 2027 the business must submit the required information to the California Privacy Protection Agency no later than 2028-04-01. For assessments conducted after 2027 submission is due by April 1 of the following year. The submission covers the business name and a point of contact with name, phone and email, the time period covered by month and year, the number of risk assessments conducted or updated in total and per triggering activity, and whether those assessments involved each of the categories of personal and sensitive personal information in Civil Code sections 1798.140(v)(1)(A)-(L), (ae)(1)(A)-(G) and (ae)(2)(A)-(C).

Evidence: Register counting risk assessments per triggering activity; Submission working papers and receipt; Mapping table for the personal and sensitive personal information categories; Point-of-contact authorization and change records

On or before 2026-01-01, and before each subsequent time a generative AI system or service released on or after 2022-01-01, or a substantial modification of it, is made publicly available to Californians, the developer must post documentation on its website covering at least: the sources or owners of the datasets; how the datasets further the intended purpose; the number of data points, which may be given in ranges with estimates for dynamic datasets; the types of data points, meaning label types or the general characteristics of unlabelled data; whether the datasets include material protected by copyright, trademark or patent, or are entirely in the public domain; whether the datasets were purchased or licensed; whether they include personal information as defined in Civil Code section 1798.140(v); whether they include aggregate consumer information as defined in section 1798.140(b); whether the developer cleaned, processed or otherwise modified the datasets and for what purpose; the time period of collection, noting whether collection is ongoing; the dates the datasets were first used in development; and whether the system used or continuously uses synthetic data generation. The duty applies regardless of whether use is for compensation.

Evidence: Archived copies of the training-data disclosure page with timestamps for each release or modification; Dataset inventory recording source, licence status and purchase or licence evidence; Working papers on data point counts and types; Statement on synthetic data use and determinations on personal information and aggregate consumer information

Data Card — datasheet for a training, validation or test dataset

No documentation is required for a generative AI system or service whose sole purpose is to help ensure security and integrity, using the Civil Code section 1798.140(ac) definition but applied to any developer or user rather than only to businesses; whose sole purpose is the operation of aircraft in the national airspace; or that is developed for national security, military or defence purposes and made available only to a federal entity. A developer relying on an exemption should retain a written determination to support enforcement responses and customer diligence.

Evidence: Exemption determination memo citing the specific paragraph relied on; Statement of product purpose and customer scope; Internal approval record

Data Card — datasheet for a training, validation or test dataset

With respect to recruitment, hiring, promotion, renewal of employment, selection for training or apprenticeship, discharge, discipline, tenure, or the terms, privileges or conditions of employment, it is a civil rights violation for an employer to use artificial intelligence that has the effect of subjecting employees to discrimination on the basis of protected classes under this Article, or to use ZIP codes as a proxy for protected classes. Note that the test is effect-based, unlike the intent-based test in the Texas TRAIGA.

Evidence: Inventory of AI tools used in personnel processes with stated purposes; Feature inventory and proxy-variable review records expressly excluding ZIP codes; Outcome disparity analysis by protected class; Vendor contract clauses on fairness testing and cooperation with investigations

It is a civil rights violation for an employer to fail to provide notice to an employee that the employer is using artificial intelligence for the purposes described above. The Illinois Department of Human Rights is directed to adopt rules for implementation and enforcement, including the circumstances and conditions requiring notice, the time period for providing it and the means of providing it, so the operative template and timing should follow those rules.

Evidence: Employee notice text and delivery records; Coverage list keyed to each personnel process in which AI is used; Tracking record for the Department of Human Rights rules and the resulting template versions; Workflow description for onboarding notices and periodic reminders to existing staff

A developer of a high-risk AI system must make available to deployers and other developers a general statement of reasonably foreseeable uses and known harmful or inappropriate uses; documentation disclosing high-level summaries of the training data types, known or reasonably foreseeable limitations including algorithmic discrimination risks, the purpose, intended benefits and uses, and all other information the deployer needs to comply with section 6-1-1703; and documentation describing how the system was evaluated for performance and discrimination mitigation before release, the data governance measures applied to training datasets and the review of data source suitability and bias, intended outputs, mitigation measures taken, and how the system should and should not be used and monitored by a human when making a consequential decision.

Evidence: High-risk system statement covering intended uses, limitations and prohibited uses; Model card and dataset card including high-level training-data summaries and data governance measures; Pre-release performance and algorithmic discrimination evaluation report; Delivery log and version register for documentation provided to deployers

Model CardData Card — datasheet for a training, validation or test dataset

A developer must publish a statement summarizing the types of high-risk systems it has developed or intentionally and substantially modified and currently makes available, and how it manages known or reasonably foreseeable risks of algorithmic discrimination. It must also disclose to the Colorado Attorney General and to known deployers and other developers, within 90 days after discovery or receipt of a credible report from a deployer, that the high-risk system has caused or is reasonably likely to have caused algorithmic discrimination.

Evidence: Archived copy of the public statement with update timestamps; Algorithmic discrimination incident register recording discovery date, source and assessment; Copies of the 90-day notices sent to the Attorney General and to deployers; Investigation and remediation records for each incident

A deployer must implement a risk management policy and program specifying the principles, processes and personnel used to identify, document and mitigate known or reasonably foreseeable risks of algorithmic discrimination, iterated and systematically reviewed and updated over the system life cycle. Reasonableness is assessed against the latest NIST AI Risk Management Framework, ISO/IEC 42001 or another nationally or internationally recognized framework that is substantially equivalent to or more stringent than part 17 (or a framework designated by the Attorney General), together with the size and complexity of the deployer, the nature and scope and intended uses of the systems deployed, and the sensitivity and volume of the data processed.

Evidence: Risk management policy and program text identifying the reference framework and version; Roster of personnel responsible for identifying, documenting and mitigating risks; Periodic review and update records showing dates and changes; Exemption assessment covering full-time equivalent headcount and use of deployer data for training

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

A deployer, or a third party it contracts with, must complete an impact assessment for each high-risk system it deploys, at least annually and within 90 days after an intentional and substantial modification is made available. The assessment must at minimum state the purpose, intended use cases, deployment context and benefits, and analyse whether deployment poses known or reasonably foreseeable risks of algorithmic discrimination, the nature of any such discrimination and the mitigation steps taken, along with the other statutory elements. Records must be retained for at least three years following the final deployment.

Evidence: Impact assessment reports covering the initial, annual and post-modification versions; Developer documentation and internal test data relied on in the assessment; Archive index evidencing three-year retention of impact assessment records; Records of reassessment within 90 days of a substantial modification

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

Where a high-risk system makes, or is a substantial factor in making, a consequential decision, the deployer must notify the consumer directly and in plain language. If the decision is adverse, the deployer must also provide a statement of the principal reasons, including the degree and manner in which the system contributed, the type of data processed and its sources; an opportunity to correct incorrect personal data that was processed; and an opportunity to appeal, allowing human review where technically feasible unless appeal is not in the best interest of the consumer, such as where delay would risk life or safety.

Evidence: Consumer notice template and dispatch records; Adverse-decision reasons template including data type and source fields; Log of data correction requests and their handling; Records of appeals received, human review performed and outcomes

A deployer that discovers, after deployment, that a high-risk system has caused algorithmic discrimination must send a disclosure notice to the Attorney General without unreasonable delay and no later than 90 days after discovery, in the form and manner the Attorney General prescribes. The Attorney General may also require the deployer, or a third party it contracts with, to produce the risk management policy, impact assessment or records within 90 days of a request.

Evidence: Discovery and internal escalation records, including the basis for the discovery date; Disclosure notice filed with the Attorney General and the filing receipt; Index and submission record of materials produced at the Attorney General request; Remediation plan and verification results

A person doing business in Colorado that deploys or makes available an AI system intended to interact with consumers must ensure that each consumer interacting with the system is disclosed that they are interacting with an AI system. This duty is not limited to high-risk systems and applies to consumer-facing conversational products.

Evidence: Interface disclosure copy and screenshots for every entry point; Product requirement documents and release records for the disclosure logic; Consistency checks across localized versions; Memo on any reliance on the obviousness exception

A covered provider must make available, at no cost, an AI detection tool that lets a user assess whether image, video or audio content, or a combination, was created or altered by that provider generative AI system; outputs any system provenance data detected; does not output personal provenance data; is publicly accessible, subject only to reasonable limits to address demonstrable risks to the security or integrity of the system; allows upload of content or a URL; and supports an API so the tool can be invoked without visiting the provider website. The provider must collect and act on user feedback about the tool efficacy, and must not collect or retain personal information from tool users (except contact details of users who opt in to being contacted, used only to improve the tool), must not retain submitted content longer than necessary, and must not retain personal provenance data from submitted content.

Evidence: Detection tool product documentation and API documentation; Monthly user or visitor metrics and methodology used for the threshold test; User feedback collection records and the resulting improvement iterations; Data retention and deletion policy for the tool with evidence of enforcement

A covered provider must include a latent disclosure in AI-generated image, video or audio content created by its system. To the extent technically feasible and reasonable the disclosure must convey, directly or through a link to a permanent website, the provider name, the name and version number of the system that created or altered the content, the time and date of creation or alteration, and a unique identifier. It must be detectable by the provider detection tool, consistent with widely accepted industry standards, and permanent or extraordinarily difficult to remove to the extent technically feasible. The provider must also offer the user the option to include a manifest disclosure that identifies the content as AI-generated, is clear, conspicuous, appropriate for the medium and understandable to a reasonable person, and is likewise permanent or extraordinarily difficult to remove.

Evidence: Technical design for latent disclosures identifying the industry provenance standard used; Sample disclosure payloads and end-to-end verification against the detection tool; Product interface for the manifest disclosure and records of user choices; Robustness test report evidencing removal difficulty

Model Card

If a covered provider licenses its generative AI system to a third party, it must require by contract that the licensee maintain the capability to include the latent disclosure in content the system creates or alters. If the provider knows that a licensee modified the system so that it can no longer do so, the provider must revoke the licence within 96 hours of discovery, and the licensee must cease using the system after revocation.

Evidence: Licence template and executed agreements containing the disclosure-capability covenant; Licensee monitoring mechanism and discovery records; Revocation decision and proof of delivery within 96 hours; Verification that use ceased after revocation

From 2027-01-01 a large online platform must detect whether provenance data compliant with widely adopted specifications from an established standards-setting body is embedded in or attached to content it distributes; provide a user interface disclosing the availability of system provenance data reliably indicating that the content was generated or substantially altered by a GenAI system or captured by a capture device, making clearly and conspicuously available information sufficient to identify authenticity, origin and modification history, including at least whether provenance data is available, the name of the GenAI system or capture device, and whether digital signatures are available; and allow users to inspect all available compliant system provenance data through the interface, by downloading a version with the data attached, or via a link to a provenance display page. The platform must not, to the extent technically feasible, knowingly strip compliant system provenance data or digital signatures from uploaded or distributed content. A large online platform is a public-facing social media, file-sharing, mass messaging platform or stand-alone search engine exceeding 2,000,000 unique monthly users during the preceding 12 months, excluding broadband internet access service and telecommunications service.

Evidence: Technical design and test report for the provenance detection pipeline; User interface designs and production screenshots; Engineering controls and regression tests preventing stripping of provenance data; Unique monthly user metrics and methodology used for the threshold test

From 2027-01-01 a GenAI hosting platform must not knowingly make available a GenAI system that does not place disclosures under section 22757.3. A GenAI hosting platform is an internet website or application that makes available for download the source code or model weights of a generative AI system by a California resident, regardless of compensation, which brings open-weight distribution channels and model marketplaces directly within scope.

Evidence: Listing review workflow and records verifying disclosure capability; Platform rules and developer agreement clauses imposing the disclosure requirement; Records of takedowns or refusals to list; Description of sampling and re-review mechanisms

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

Section 24(1) requires a controller, before or as soon as reasonably practicable after it starts processing personal data, to pay the Data Protection Fee for the twelve months from that date and to notify the Commissioner of its name and address (registered office for a registered company) and the date processing began. Section 24(2) requires a Renewal Fee each year within one month of the anniversary of that date, in the amount set by Board rules. The ADGM Office of Data Protection confirms that all ADGM registered entities processing personal data must register as Data Controllers.

Evidence: Registration confirmation and a screenshot of the registered particulars; Receipts for the Data Protection Fee and each Renewal Fee; Internal record establishing the date processing began; Change log for registered particulars (name, address, DPO)

Section 35(1) requires a DPO where processing is carried out by a public authority (other than courts acting judicially); where the core activities of the controller or processor consist of processing operations that by their nature, scope and purposes require regular and systematic monitoring of data subjects on a large scale; or where core activities consist of large-scale processing of special category data. The DPO may serve one entity, a group or multiple independent entities, may hold other roles, need not be an employee (a written agreement is required) and need not reside in ADGM, provided they are easily accessible to each entity served and no other role conflicts with their duties. Section 35(3) requires appointment on the basis of professional qualities, in particular expert knowledge of data protection law and practice. Section 35(4) requires notification to the Commissioner within one month of appointment or resignation, with the new DPO’s contact details and, on resignation, the reasons.

Evidence: Memo on whether section 35(1) is triggered; DPO appointment document or written service agreement; Record of the appointment/resignation notification to the Commissioner, evidencing the one-month deadline; DPO qualifications and independence note

Section 32(1) requires the controller to notify the Commissioner without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless it is unlikely to result in a risk to the rights of natural persons; a later notification must be accompanied by reasons for the delay. Section 32(2) requires a processor to notify the controller without undue delay. The notification must describe the nature of the breach (including categories and approximate numbers of data subjects and records), give the DPO or contact point, describe likely consequences and the measures taken or proposed; information may be provided in phases without undue further delay. Section 32(5) requires documentation of all breaches, their effects and remedial action, sufficient for the Commissioner to verify compliance.

Evidence: Breach response plan and the rule for determining when the 72-hour clock starts; Breach register recording facts, effects and remedial action; Submission record of the Commissioner notification and any delay reasoning; Text and proof of delivery of data subject communications where section 33 is triggered

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

On exports: section 41 permits transfers under a Commissioner adequacy decision, and the Commissioner may take into account a European Commission adequacy decision under GDPR Article 45(3). Absent adequacy, section 42 allows reliance without specific authorisation on a legally binding instrument between public authorities, binding corporate rules, standard data protection clauses adopted by the Commissioner under section 42(2) (the Commissioner may approve the European Commission’s or another supervisory authority’s standard contractual clauses, which are then incorporated by reference), or an approved code of conduct or certification mechanism with binding and enforceable commitments; bespoke contractual clauses and administrative arrangements under section 42(4) need the Commissioner’s authorisation. Only if none is available do the section 44 derogations apply, including explicit consent after being informed of the risks of the absence of adequacy and safeguards. On automated decisions: section 20(1) gives the right not to be subject to solely automated decisions with legal or similarly significant effects, with exceptions for contract necessity, explicit consent, and where required or authorised by applicable law (including fraud prevention, AML, and security and integrity purposes). For that third exception the controller must, as soon as reasonably practicable, notify the data subject in writing that a solely automated decision has been taken, and the exception holds only if within one month of receiving that notification the data subject has not asked the controller to reconsider or to take a new decision that is not solely automated. Section 20(3) requires suitable measures for the contract and consent cases, at least the right to obtain human intervention, express a point of view and contest the decision.

Evidence: Export register mapping each flow to section 41, 42 or 44; Executed standard data protection clauses, BCR approval or Commissioner authorisation; Written notification template for solely automated decisions and the sending log; Tracking of the one-month objection window and the outcomes of reconsideration or new human decisions

Open tool: Transfer Matrix

Determine, activity by activity, a legal basis under Article 7 (personal data) or Article 11 (sensitive personal data), and give clear, adequate and conspicuous notice of the purposes, the form and duration of processing, the controller’s identity and contact details, with whom the data is shared and why, and the data subject’s rights and how to exercise them. Where consent is the basis it must be given in writing or by another means that demonstrates it, be specific to the purpose, and be withdrawable at any time by an equally easy procedure; consent relating to children’s data, sensitive data and international transfers must be obtained separately and prominently. AI products should note that using user input to train models is a different purpose from delivering the service and needs its own disclosure and basis.

Evidence: Mapping table of processing activities to legal bases; Versioned Portuguese-language privacy notice with effective dates; Technical records of consent capture and withdrawal (timestamp, version, scope); Product screenshots of the separate training-use notice and any opt-out

Data subjects may request review of decisions taken solely on the basis of automated processing that affect their interests, including decisions intended to define their personal, professional, consumer or credit profile or aspects of their personality. Note: the operative text (as amended by Lei nº 13.853/2019) dropped the original “by a natural person” qualifier, so the statute no longer expressly mandates human review — but Article 20 §1 requires the controller, whenever asked, to provide clear and adequate information about the criteria and procedures used in the automated decision, subject to commercial and industrial secrecy, and §2 provides that where the controller withholds that information on secrecy grounds the ANPD may carry out an audit to check for discriminatory aspects in the automated processing. Design for this up front: explainability outputs, a review ticket workflow, and records of review outcomes that can be reconstructed later.

Evidence: Automated decision inventory and impact assessment; Review request intake channel, ticket workflow and turnaround records; External explanation of the criteria and procedures, with reasoning for any trade-secret redactions; Sample review conclusions and overturned decisions

Article 33 permits international transfers only in nine cases (I–IX): (I) to countries or international organisations providing a degree of protection adequate to that in the Law, as determined by the ANPD; (II) where the controller offers and demonstrates guarantees of compliance with the principles, data subject rights and data protection regime of the Law, in the form of specific contractual clauses for a given transfer, standard contractual clauses, global corporate rules, or regularly issued seals, certificates and codes of conduct; (III) where necessary for international legal cooperation between intelligence, investigation and prosecution bodies under instruments of international law; (IV) where necessary to protect the life or physical safety of the data subject or a third party; (V) where the national authority authorises it; (VI) where the transfer results from a commitment made in an international cooperation agreement; (VII) where necessary to execute a public policy or a legal attribution of public service, published under Article 23(I); (VIII) where the data subject has given specific and highlighted consent to the transfer, informed beforehand of its international character and with that purpose clearly distinguished from others; and (IX) where necessary to meet Article 7(II) (compliance with a legal obligation), (V) (judicial, arbitral or administrative proceedings) or (VI) (protection of life or physical safety). For a Chinese AI company repatriating Brazilian user data for training, the realistic route is (II), backed by minimisation, encryption and access control; route (VIII) sets a high bar (separate, highlighted, with prior notice of the international character) and should not carry bulk training-data transfers.

Evidence: International transfer register (recipient, country, data categories, Article 33 route relied on); Executed contractual clauses or global corporate rules; Records of separate transfer-specific consent where that route is used; Evidence of supplementary technical measures (encryption, minimisation, access logs)

Open tool: Transfer Matrix

Under Article 48 the controller must notify the ANPD and the data subject of a security incident that may create relevant risk or damage to data subjects, within a reasonable period “as defined by the national authority” (see the deadline field on this obligation), with at least the nature of the affected data, information about the data subjects involved, the technical and security measures used, the risks related to the incident, the reasons for delay where notification was not immediate, and the measures taken or to be taken to reverse or mitigate the harm. Under Article 37 controllers and processors must keep records of the processing operations they carry out, especially when based on legitimate interests. AI companies should include prompt logs, vector stores and model checkpoints in the blast-radius assessment.

Evidence: Security incident response plan and ANPD notification template; Incident register and submission records, including reasons for any delay; Records of processing operations, including those based on legitimate interests; Blast-radius assessment checklist covering prompt logs, vector stores and model checkpoints

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

The LGPD imposes heightened rules on children’s and adolescents’ data (Article 14): processing must be in their best interests, and children’s data generally requires specific and prominent consent from a parent or legal guardian. Recent ANPD enforcement puts minors at the centre: on the retrieval date its site announced a BRL 153.7 million fine against a platform for failures in protecting children’s and adolescents’ data, and reminded digital platforms to publish transparency reports by 17 September 2026 under the Digital Statute of the Child and Adolescent (ECA Digital). Companies bringing social, generative, companion or education AI products to Brazil should build age assurance and routing, parental consent, stricter defaults for minors, and assess whether the platform transparency reporting duty applies to them.

Evidence: Age assurance and routing design note and test report; Parental or guardian consent workflow and records; Documentation of default settings and content safety policy for minors; Applicability assessment for the ECA Digital transparency reporting duty

Appoint an officer under Article 41 as the point of contact for data subjects and the ANPD, and publish their identity and contact details (typically in the privacy notice and prominently on the site). The role covers receiving complaints and communications from data subjects and providing explanations and taking action, receiving communications from the ANPD and acting on them, and guiding employees and contractors on data protection practices. Where an offshore entity has no Brazilian establishment, it should still designate someone able to receive communications in Portuguese and publish the channel.

Evidence: Officer appointment document and role description; Screenshot of the published identity and contact details on the site or in the privacy notice; Log of communications handled from data subjects and the ANPD; Data protection training records for employees and contractors

Before entering the Saudi market, tier each AI system against the “Scope” section of the AI Ethics Principles: little or no risk, limited risk, high risk, unacceptable risk. For systems assessed as high risk the document requires pre- and post-conformity assessments and compliance with the relevant statutory requirements in addition to ethics. Uses falling into the unacceptable tier — social profiling, exploitation of children, likely distortion of behaviour — must not be deployed. Record the tiering conclusion and reasoning in the product compliance file and re-assess on functional change.

Evidence: Risk tiering worksheet (system, use case, tier, reasoning); Pre-deployment conformity assessment report for high-risk systems; Post-deployment monitoring and post-conformity assessment records; Excluded-use list for the unacceptable tier and technical evidence of enforcement in the product

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

Map the seven principles — Fairness, Privacy & Security, Humanity, Social & Environmental Benefits, Reliability & Safety, Transparency & Explainability, and Accountability & Responsibility — onto concrete controls in the four lifecycle stages: plan and design, prepare input data, build and validate, deploy and monitor. Under Humanity the document requires the model to be designed and built on fundamental human rights and Saudi cultural values, and requires designers to define how the system and its outcomes align with them. Under Fairness it requires fairness-aware design to start at the beginning of the lifecycle as a collaborative effort. Under Privacy & Security it sets the specific controls described above (no personally identifying characteristics as automated decision criteria; profiling only with compliance-officer approval or under a sector regulator’s code; data classification and profiling planned at the data architecture stage; de-identification planned for sensitive or personal data with group-based read/write/update authorisation). Each control needs an owner, execution evidence and a review cycle.

Evidence: Control mapping from the seven principles to the four lifecycle stages, with owners and review cycles; Fairness assessment reports and bias mitigation records; Compliance approval record for profiling use cases (compliance officer sign-off or reference to a sector regulator’s code); De-identification design, data classification output and the group-based authorisation matrix

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

The Generative AI Guidelines for the Public apply to all stakeholders designing, developing, deploying, implementing, using or affected by GenAI systems within the Kingdom. They distinguish “Users” (any natural or legal person consuming or making use of goods or services produced by GenAI systems, covering companies, NGOs and individuals) from “Developers” (any natural or legal person developing GenAI systems to achieve certain goals, including AI developers, data scientists and researchers), and set out GenAI principles, risks and potential mitigations. Build a Saudi-facing GenAI risk register on that basis: map each risk the guidance lists onto your product, state the mitigations adopted and the residual risk, and reflect them in user terms and in-product notices. SDAIA also publishes a government edition of the GenAI guidance and a deepfakes document; align to those as well when delivering to government customers.

Evidence: GenAI risk register (risk, mitigation, residual risk, owner); Technical note and test records for content safety and abuse prevention; User terms, acceptable use policy and in-product notices; Alignment note against the government edition of the guidance for public-sector deliveries

Model CardISO/IEC 42001 AI management system implementation and certification readiness checklist

Section 5 of the FTC Act prohibits unfair or deceptive acts or practices in commerce. In its Operation AI Comply sweep the FTC stated that using AI tools to trick, mislead or defraud people is illegal and that there is no AI exemption from the laws on the books. The cases announced included a company promoting an AI tool that enabled customers to create fake reviews, a company claiming to sell AI Lawyer services, and companies claiming AI could help consumers make money through online storefronts. Companies must therefore hold substantiation before publishing accuracy, performance, autonomy or earnings claims.

Evidence: Claims register mapped to supporting evidence, recording benchmark set, methodology, date and owner; Raw benchmark data and reproducible evaluation scripts; Compliance review records and version history for marketing materials; Verification records for testimonials and endorsements

Model Card

In the Rite Aid matter the FTC alleged that the retailer deployed AI-based facial recognition in hundreds of stores without taking reasonable measures to prevent harm to consumers, who were erroneously flagged as shoplifters or troublemakers and suffered humiliation and other harm. The order requires comprehensive safeguards when deploying automated systems that use biometric information to track or flag consumers, requires discontinuing the technology where potential risks to consumers cannot be controlled, and requires a robust information security program overseen by senior company executives. This establishes an enforcement baseline that deployment must come with safeguards.

Evidence: Pre-deployment risk assessment and accuracy or false-positive testing reports broken down by demographic group; Design documentation for human review and appeal mechanisms; Notification plan for affected individuals; Minutes evidencing senior executive oversight of security and algorithm governance

FTC enforcement outcomes have strong demonstrative effect: the safeguards, prohibitions and executive oversight arrangements imposed in peer consent orders typically become the de facto standard used in customer diligence and procurement questionnaires. Companies should track FTC actions against comparable business models, map their requirements into internal controls, and be able to give evidenced answers in customer security questionnaires and investor diligence.

Evidence: Tracking register of peer enforcement developments; Mapping table from enforcement requirements to internal controls; Standard answer library for customer security questionnaires with an evidence index; Annual compliance self-assessment report

Because the Act creates no penalties, approvals or filings, AI compliance in Japan must be assessed under existing law: the APPI (including the 2026 amendment), the Copyright Act (training and outputs), the Unfair Competition Prevention Act, product liability law, and sectoral regulation in finance, healthcare, automotive and telecommunications. Internally, companies should maintain an explicit mapping recording that the Japanese AI Act creates no standalone duties while the relevant duties sit in other statutes, so that the Act is not mistaken for a compliance clearance.

Evidence: Mapping of Japanese AI-relevant legal duties to statutes and owning functions; Compliance status assessment under each applicable statute; Legal-change monitoring mechanism and review records

Article 7 defines a “utilisation business” as a person intending to develop or supply products or services using AI-related technologies, or otherwise to use such technologies in business activities. It requires them to endeavour, in line with the basic principles, to make their operations more efficient and advanced and to create new industries through active use of AI, and to cooperate with measures implemented by the State under Art. 4 and by local governments under Art. 5. This is a responsibility clause, not a sanctionable duty; in practice it means responding to government surveys, taking part in guideline and standards development, and answering requests for information.

Evidence: Correspondence records of cooperation with government surveys and information requests; Records of participation in guideline or standards development; Internal AI utilisation policy document

Article 13 requires the State to develop guidelines consistent with international norms, and take other necessary measures, to ensure the appropriate conduct of AI research, development and use; Article 18 requires the government to adopt an AI Basic Plan. Companies should treat both as the baseline governance expectation for the Japanese market, fold them into their internal AI governance, and answer against them in public procurement and large-customer due diligence. The AI Basic Plan was adopted by Cabinet decision on 23 December 2025.

Evidence: Mapping table between internal AI governance policy and the State guidelines; Tracking record of Basic Plan measures relevant to the business; Working papers for due-diligence questionnaire responses

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

Utah Code section 13-2-12 (generative artificial intelligence and its impact on liability under consumer protection law) established two rules: that generative AI making the violative statement or undertaking the violative act is not a defence, and a disclosure arrangement tied to regulated occupations. The official historical version page for that section is expressly marked effective 2024-05-01 and repealed 2025-05-07. Before giving a client a conclusion, verify where the disclosure duty now sits after the 2025 amendments and quote the current wording rather than the repealed section number.

Evidence: Statutory research record noting search date, source page and section number; Consumer-facing AI disclosure copy and where it is displayed; Disclosure workflow for regulated occupation scenarios; Regulatory change tracking register

A participant that uses or wants to use AI technology in Utah may apply for a regulatory mitigation agreement or a joint interpretation agreement under the criteria and procedures set by the Office of Artificial Intelligence Policy within the Department of Commerce. Such an agreement specifies limitations on the scope of use, which may include the number and types of users, geographic limitations and other implementation limits; safeguards to be implemented; any regulatory mitigation granted; required consumer disclosures; and reporting requirements supporting Office audits. The Office performs regular audits while the agreement is in effect, and the participant remains subject to all legal and regulatory requirements not expressly waived or modified.

Evidence: Application materials and eligibility evidence; Executed agreement text including scope limits and safeguards; Periodic reports submitted to the Office; Evidence of implementing the required consumer disclosures

Under Article 29 of the Senate-approved text, the developer of a general-purpose or generative AI system must, in addition to the relevant development documentation, carry out a preliminary assessment to identify its expected risk levels, including potential systemic risk, taking into account reasonably expected uses and the criteria in Section III of Chapter III. The readiness action now is to fold this assessment into the existing model release review, produce an assessment report template that will map onto the Brazilian framing, and share a single source document with the EU AI Act general-purpose model technical documentation to avoid duplicated work later.

Evidence: Preliminary assessment report template and a first trial assessment; List of reasonably expected uses and the basis for the risk determination; Internal criteria and conclusion on systemic risk; Field mapping against the EU general-purpose model technical documentation

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

Under Article 30 of the Senate-approved text, before making a systemic-risk general-purpose or generative AI system available or placing it on the market for commercial purposes, the developer must: describe the general-purpose AI model; document the tests and analyses performed to identify and manage reasonably foreseeable risks, as appropriate and technically feasible; document residual non-mitigable risks remaining after development; process and incorporate only datasets collected and handled in accordance with legal requirements and subject to adequate data governance, and, where personal data is involved, with Lei nº 13.709/2018 and Chapter II of this Law; publish a summary of the training dataset as regulated; design and develop the systems using applicable standards to reduce energy and resource use and waste and increase energy and overall system efficiency in the context of use; and produce intelligible technical documentation and instructions for use so that developers, distributors and applicators understand how the system works (item VII). Article 30 §1 is pointed: compliance is required regardless of whether the system is supplied as a standalone model, embedded in another AI system or product, under free and open-source licences, as a service, or through other distribution channels — which matters most to Chinese vendors releasing open-weight models. Article 30 §2 lets developers draw up or adhere to codes of good practice to demonstrate conformity. Readiness action: start producing training data provenance and licence chains, evaluation and red-team records, a residual risk register, technical documentation and instructions for use, and a publishable training data summary now, so the evidence is reconstructable when the law takes effect.

Evidence: Model description (architecture, capability boundaries, intended and prohibited uses); Risk testing and analysis records (red-teaming, evaluation suites and conclusions); Residual risk register with mitigation status; Training data provenance and licence evidence, plus a draft publishable training dataset summary; Technical documentation and instructions for use aimed at developers, distributors and applicators (Article 30(VII)); Design note on energy and resource efficiency and the standards relied on

Model CardData Card — datasheet for a training, validation or test dataset

The SEC published the final climate-related disclosure rules in the Federal Register on 2024-03-28 (89 FR 21668), originally effective 2024-05-28. On 2024-04-12 it announced (89 FR 25804) that the effective date is delayed indefinitely pending completion of the consolidated Eighth Circuit review, with a further Federal Register notification to follow. On 2026-06-03 the SEC published a proposed rule (91 FR 33296) to rescind those climate-related disclosure rules, with comments due 2026-08-03. No final rescission rule was observed as of 2026-09-12. Companies listed or listing in the United States should therefore not prepare disclosure as though the rules were in force, but equally should not infer that no other climate disclosure obligations apply.

Evidence: Status tracking register recording Federal Register citations and the date checked; Statement of the status assumptions underlying the disclosure preparation plan; Confirmation records with auditors and counsel; Comparison table of climate disclosure duties in other jurisdictions, to avoid generalizing from the U.S. status

ISSB (IFRS S1 / S2) sustainability-related financial disclosure report outline

Even while the federal rule is stalled, climate data capability retains commercial value: supply chain questionnaires from U.S. enterprise customers, investor diligence and mandatory regimes in other jurisdictions all draw on the same underlying data. Retain the emissions accounting boundary, activity data collection processes and data quality controls rather than suspending the build-out as the rule status changes. This item is practical guidance and does not assert a current SEC mandate.

Evidence: Emissions accounting boundary and methodology documentation; Activity data collection workflow and data quality control records; History of responses to customer supply chain questionnaires; Internal allocation of responsibility for climate data governance

Greenhouse gas inventory workpaper (GHG Protocol Scope 1 / 2 / 3)ISSB (IFRS S1 / S2) sustainability-related financial disclosure report outlineThird-party sustainability assurance readiness checklist (starting from limited assurance)

Open tool: Carbon Estimator