The OECD reports under the Hiroshima AI Process are a reporting framework in which AI developers describe how they assess risk, test, disclose and handle incidents; twenty organisations answered in the first round. This is for Thai companies buying AI, who get the same topics to put to a vendor: whether your data trains the model, how long it is kept, and when incidents are reported.
- The first HAIP reporting round (Feb–Jun 2025) drew 20 voluntary reports; the OECD did not verify them.
- Training data is what large developers disclose least; B2B customers usually get it only through contracts.
- The ETDA Generative AI guideline tells organisations to assess external products, but says itself it is not law.
- If an AI vendor processes personal data for you, PDPA section 40 requires an agreement and breach reporting back to you.
- When a vendor cannot answer, log it as a risk in your register and let management decide whether to accept it.
When a procurement team asks an AI vendor for information, it usually gets marketing material and a few links to a trust centre. The deeper problem is that procurement often does not know what to ask, or what a good enough answer looks like.
A 2025 publication helps. The OECD compiled reports from twenty AI developers describing, in their own words, how they assess risk, test systems, disclose information and handle incidents. The AIPDPA team adapted that paper into a Thai-language note. This article keeps only what an AI buyer can use and turns it into questions for vendors.
What is the Hiroshima AI Process reporting framework?
It is a reporting template the OECD built at the G7's request to track how organisations that adopted the *International Code of Conduct for Organisations Developing Advanced AI Systems* actually apply it. The Code dates from Japan's 2023 G7 presidency and has eleven actions; the reporting framework went live in February 2025.
The first round, February to June 2025, drew twenty reports, mostly from Japan and the United States. Seventeen came from technology and telecom firms such as Google, Microsoft, OpenAI, Anthropic, Salesforce, Fujitsu, NEC and SoftBank; three from advisory and research bodies. All of this comes from the AIPDPA team's note adapted from OECD AI Paper No. 45.
| Section | What it asks | How a buyer uses it |
|---|---|---|
| I Risk identification and evaluation | Risk tiering, testing, standards used | Ask what the vendor tests before release |
| II Risk management and security | Data quality, privacy, IP, cyber | Ask about training on your data, retention, safeguards |
| III Transparency | Documentation of capabilities, limits, data sources | Request a model card or system card |
| IV Governance and incidents | Oversight, incident logging and handling | Ask when you will be told about an incident |
| V Content provenance | AI disclosure, labels, watermarks | Ask about audit trails and labelling |
| VI Safety research | Research and collaboration | Use as one vendor-selection criterion |
| VII Societal benefit | Social and environmental programmes | Count in ESG reporting if you publish one |
What do the big AI developers disclose?
The team's note boils down to five points that matter directly to buyers. Each is something respondents reported doing, not something proven.
Risk is assessed repeatedly, not once
Most respondents assess across the whole system life cycle, from design to retirement, mixing numbers such as bias scores or error rates with expert judgement. Some use three or four risk tiers. Red teaming, where a team plays the attacker, is standard practice.
Customer data is handled mainly by contract
Firms selling to businesses report using data processing agreements and privacy clauses; some, such as Salesforce, keep no customer prompts or outputs after processing (zero data retention). On intellectual property, several let website owners opt out of collection through robots.txt, while business customers rely on contracts.
Transparency depends on who the customer is
Consumer-facing firms publish model or system cards describing capabilities, limits and safety evaluations. B2B firms disclose through contracts and customer-specific documents instead. Across every group, the least disclosed item is the data used to train the model.
AI incidents run through the IT incident pipeline
Nearly all respondents fold AI risk into their existing risk management, run dedicated incident teams, and some, such as Preferred Networks and SoftBank, attach AI incidents to the IT incident process they already have.
Telling users it is AI is now routine
Telling users they are interacting with AI, through on-screen messages or warnings, is widespread among respondents. Technical provenance such as watermarking or C2PA is still limited to a few. B2B vendors offer audit trails so customers can see afterwards how the system was used.
What does the ETDA guideline say about AI vendors?
The Generative AI Governance Guideline for Organizations, from the AI Governance Center (AIGC) under ETDA, is the closest Thai document on this topic. Its status needs to be clear first: the guideline says itself that it is guidance, not law. The guideline file carries an English rendering, quoted below.
Therefore, non-compliance with this guideline, or adapting only part of it, is not a violation of or non-compliance with relevant laws and requirements.
Even so, it is clear on vendors. Item 8 of section 3.2 on risk management asks organisations to assess and check tools, models and datasets from external parties, and to keep monitoring them rather than checking once at purchase.
8) Monitor and Evaluate Products/Services by External Parties — Assess risks and check products or services (such as tools, models, and datasets) from external parties, to ensure consistency with the organization's risk management policy, including regular performance monitoring
The guideline's annex, a sample Generative AI use policy, flags something many buyers miss: free services may keep what users type and use it for training.
Because Generative AI applications or services provided — particularly free applications or services — may access or record interaction data or data received from users for use in training Generative AI models
The same sample policy puts approval of the tool list in one place. That is exactly why a vendor questionnaire matters: whoever approves needs facts to decide on.
5) The IT Steering Committee (IT Steering) is responsible for considering and approving the list of Generative AI applications or services appropriate for use within the Office.
Which part does Thai law actually require?
The binding part is the Personal Data Protection Act B.E. 2562 (2019). If an AI vendor processes personal data on your instructions, it is a data processor. Section 40 paragraph three requires you to have an agreement with it, and section 40 (2) sets two vendor duties that match the checklist: security measures, and reporting breaches back to you.
(2) provide appropriate security measures for preventing unauthorized or unlawful loss, access to, use, alteration, correction or disclosure, of Personal Data, and notify the Data Controller of the Personal Data breach that occurred;
Section 40 does not mention model training as such. But section 40 (1) limits the processor to acting on the controller's instructions, so writing "no training on our data" into the agreement is simply making that instruction explicit. Drafting details are in the processor agreement guide.
Ten questions to ask an AI vendor before signing
The AIPDPA team built this checklist from the topics large AI developers reported to the OECD, cross-checked against the ETDA guideline and section 40. It is not a list set by law. Get the answers in writing and keep them in that vendor's file.
| # | Question | Why ask | What you can point to |
|---|---|---|---|
| 1 | Are our inputs, prompts and outputs used to train or improve the model? Can that be switched off and written into the contract? | Some large firms run zero data retention, but free services may train on inputs | Section 40 (1) · ETDA guideline annex 4.2 |
| 2 | How long are prompts, outputs and logs kept, when are they deleted, and can we request deletion? | You need this to set your own retention periods | Agreement under section 40 paragraph three |
| 3 | In which countries is data processed and stored, and which subcontractors are used? | Transfers abroad have their own conditions | Cross-border transfer guide |
| 4 | Is there a model card or system card, and what known limitations does it list? | This is how large firms disclose capabilities and limits | HAIP section III (team note) |
| 5 | How do you test for bias and attacks, and can we see a summary? | Most respondents report red teaming | HAIP section I · NIST MEASURE |
| 6 | If data leaks or the system fails badly, how fast will you tell us, and through which channel? | You need time to meet your own duties as controller | Section 40 (2) |
| 7 | Are you certified to ISO/IEC 27001 or ISO/IEC 42001, and can we see the certificate? | A certificate is independent evidence, unlike a claim | ISO 42001 or NIST |
| 8 | Where does the training data come from, and who is responsible if an output infringes someone's copyright? | Training data is the least disclosed topic | ETDA guideline example 2 · AI copyright |
| 9 | Is there an audit trail or usage log our administrators can see? | B2B vendors use audit trails instead of public disclosure | HAIP section V |
| 10 | Will you tell us when the model version changes, and is there a change log? | A model change is a reason to reassess risk | NIST MANAGE 3.2 |
Question 10 is often forgotten, yet the NIST AI RMF states plainly that externally pre-trained models belong in routine monitoring. If a vendor swaps the model quietly, the assessment you did is out of date overnight.
MANAGE 3.2: Pre-trained models which are used for development are monitored as part of AI system regular monitoring and maintenance.
What if the vendor cannot answer?
Do not skip the question. The team's note recommends recording the vendor's inability to answer as a risk in your AI registry and having someone with authority decide whether to accept it. A decision with a named owner beats a question that quietly disappears.
Use it only for work with no personal or confidential data, in line with annex 4.2 of the ETDA guideline, and record it as an accepted risk.
Many B2B respondents disclose through contracts rather than public documents.
"Promptly" cannot be checked. Set a time frame that leaves you room to meet your own duties as controller.
NIST has no certification; a claim that names no outcomes cannot be verified.
How should a Thai company start, in 90 days?
The team's note compresses the seven HAIP sections into three phases for organisations that deploy other people's AI, each built on documents you already keep for the PDPA.
- Days 1–30List every AI system in use, including AI embedded in purchased software; assign risk tiers; name one owner; issue a short AI use policy.Sections I · IV
- Days 31–60Send the ten questions to every vendor; amend agreements that say nothing about training or log retention; add AI disclosure wherever users meet AI.PDPA s.40 · Sections II · III · V
- Days 61–90Assess impact for high-risk systems, add AI incidents to the breach response plan, and report to management.Sections I · IV
The mistake the team sees most is treating what Google or Microsoft does as the floor for a much smaller company. Respondents themselves note that large firms focus on societal risk while smaller ones focus on the risk of a specific use. Size the effort to fit.
AIPDPA keeps an AI registry and a vendor register that hold each vendor's answers together, with Thai and English processor agreement templates. If you have no AI use policy yet, start with the GenAI policy guide, and for staff use of chatbots read ChatGPT at work and four Thai laws.
Frequently asked questions
Does the OECD HAIP framework apply to Thai companies?
No. It is voluntary reporting by organisations that adopted the G7 Code of Conduct. Thai companies need not file anything, but can use the seven sections to check themselves or question vendors.
Must we follow the ETDA Generative AI guideline?
It is guidance. The guideline states that not following it, or following only part, is not a breach of law. It is still a useful Thai reference when setting policy.
Is an AI vendor always a data processor under the PDPA?
Not always. It depends on whether the vendor processes personal data on your instructions or on your behalf. If so, section 40 paragraph three requires an agreement; if no personal data enters the system, section 40 does not come into play.
The vendor will not say what data trained its model. Should we walk away?
Not necessarily. Training data is what large developers disclose least. Record it as a risk, limit the use, and have someone with authority decide in writing.
Can we cite this OECD work to say we meet international standards?
Better not. It is not a standard; it describes what twenty organisations say they do. If you cite it, say "several leading organisations report doing...". For verifiable evidence, look at ISO/IEC 42001.
Law and sources
- AIPDPA team note adapted from OECD Artificial Intelligence Papers No. 45 (Sept 2025) on the Hiroshima AI Process reporting framework (not law, not an official OECD document)
- Generative AI Governance Guideline for Organizations, AI Governance Center (AIGC), ETDA (guideline, not law) — 3.2 Clause 8) · Annex 4.2 · Annex 5, item 5)
- Personal Data Protection Act B.E. 2562 (2019) — Section 40 (2)
- NIST AI 100-1 (AI RMF 1.0) · voluntary framework — MANAGE 3.2
Text in the "The text" boxes is copied word for word from AIPDPA's legal knowledge base, transcribed from the Royal Gazette and official documents; every edit is checked by the system against that base, character by character. English wording is an unofficial translation; the Thai text prevails. This article is general information, not legal advice for a particular case.
Do it in the system
Who stands behind this guide?
Written by the AIPDPA legal team · Content owner: Phuwara Krobtaku, Attorney-at-law · Thai Barrister-at-Law · technology & intellectual property counsel
Lawyer's licence no. 477/2558 · Thai Barrister-at-Law · LL.M. in Intellectual Property & IT Law (Gold Medal)