Hiroshima AI Process Transparency Report Template (OECD HAIP v2.0)
OECD HAIP Reporting Framework v2.0: role, risk identification, risk management and security, transparency, governance, provenance, research, societal benefit, evidence
Cómo usar: Use it when your organisation prepares a voluntary report under the OECD Hiroshima AI Process Reporting Framework. Fill the role and scope, then section 1 risk thresholds and deployment decision process, and the evidence register with public links first. The main pitfall is describing policies with no public evidence or including confidential detail in a report that is published in full.
Vista previa
Hiroshima AI Process Transparency Report: [Organisation name]
Working draft of an organisation's voluntary report under the OECD Hiroshima AI Process (HAIP) Reporting Framework, Version 2.0, which monitors application of the G7 Hiroshima Process International Code of Conduct for Organizations Developing Advanced AI Systems. It follows the seven sections of the v2.0 questionnaire: risk identification and evaluation; risk management and information security; transparency reporting; organisational governance and incident management; content authentication and provenance; research and investment; and advancing human and global interests. Questions are paraphrased and numbered as in the OECD questionnaire. Replace every
[bracketed]value and every row marked Example. Official submission happens only through the OECD.AI portal. This is a documentation format, not legal advice.
Document control
| Field | Value |
|---|---|
| Document ID | [HAIP-RPT-2026] |
| Organisation | [Legal name, headquarters jurisdiction] |
| Eligibility basis | [OECD member / GPAI member / Adherent to the OECD AI Recommendation] |
| Role(s) in the AI lifecycle | [Model developer / Application developer / Deployer / Other] |
| Organisation size | [Micro / Small / Medium / Large] |
| Systems in scope | [Advanced AI systems covered by this report] |
| Reporting period | YYYY-MM-DD to YYYY-MM-DD |
| Framework version | OECD HAIP Reporting Framework v2.0 |
| Report owner | [@report-owner] |
| Attesting officer | [@officer, title] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Submitted / Published] |
| Approvers / reviewers | [@legal], [@security], [@comms], [@ai-governance] |
| Last updated | YYYY-MM-DD |
| Portal submission date | YYYY-MM-DD |
| Next resubmission due | [within 12 months of submission] |
| Classification | [Internal draft; public once submitted] |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| AI governance lead | [@name] | [Approve content] | YYYY-MM-DD |
| Legal counsel | [@name] | [Cleared for publication] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Security disclosures cleared] | YYYY-MM-DD |
| Attesting officer | [@name] | [Attest accuracy] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Evidence gathered for sections 1 to 3 |
| 0.5 | YYYY-MM-DD | [@name] | Example: All sections drafted, legal review comments addressed |
| 1.0 | YYYY-MM-DD | [@name] | Example: Submitted through the OECD.AI portal |
| 1.1 | YYYY-MM-DD | [@name] | Example: Complementary submission after OECD request |
Contents
- Organisation profile and role
- Section 1: Risk identification and evaluation
- Section 2: Risk management and information security
- Section 3: Transparency reporting on advanced AI systems
- Section 4: Organisational governance, incident management and transparency
- Section 5: Content authentication and provenance
- Section 6: Research and investment for safety and societal risks
- Section 7: Advancing human and global interests
- Evidence and link register
- Submission checklist and timeline
- Glossary and references
1. Organisation profile and role
| Item | Answer |
|---|---|
| Role(s) | [Model developer (provider) / Application developer (provider) / Deployer / Other: specify] |
| Organisation size | [Micro (under 10) / Small (10 to 49) / Medium (50 to 249) / Large (250 or more)] |
| Advanced AI systems covered | [Model or product names and versions] |
| Main markets | [Countries or regions] |
| Public AI governance page | [URL] |
| Contact for the report | [Role mailbox, not a personal address] |
Describe in three to five sentences what the organisation builds or uses, which advanced AI systems this report covers, and where it sits in the value chain. Readers of published reports compare organisations; a clear scope prevents your answers being read as covering products they do not cover.
The sections below map to the actions of the International Code of Conduct as the questionnaire indicates: section 1 to Actions 1, 4, 6 and 10; section 2 to Actions 1, 2, 4, 6, 10 and 11; section 3 to Actions 3, 4, 5, 10 and 11; section 4 to Actions 2, 4, 5, 10 and 11; section 5 to Actions 7 and 10; section 6 to Actions 1, 7 and 8; and section 7 to Action 9.
2. Section 1: Risk identification and evaluation
| Q | Topic (paraphrased) | Answer | Evidence |
|---|---|---|---|
| 1 | How the organisation defines and classifies AI risk types (internal taxonomy, capability thresholds with required safeguards, external consultation on taxonomy) | [Selected options and explanation] | EVD-001 |
| 1A | How thresholds are set at which severe risks, if not mitigated, would be unacceptable; examples of such contexts; how mitigations scale with capability; any specific treatment of generative and agentic AI | [Narrative] | EVD-002 |
| 2 | Practices used before and after deployment to identify and evaluate vulnerabilities, incidents, emerging risks and misuse (internal and external red teaming, involvement of AI safety institutes, benchmarks, qualitative review, vulnerable groups, impact assessments, telemetry, agentic and multi-agent risk, multilingual evaluation) | [Selected options] | EVD-003 |
| 2A | Decision process for deploying a model or system: who decides, evidence and criteria required | [Narrative] | EVD-004 |
| 2B | How incident reports, including those from other organisations, update risk assessments and trigger corrective action after deployment | [Narrative] | EVD-005 |
| 3 to 3D | Mechanisms to receive and share reports of risks, incidents and vulnerabilities with third parties; which stakeholders can use them and when; how and what information is shared | [Selected options, URLs] | EVD-006 |
| 4 | Programmes that encourage disclosure of risks, incidents and vulnerabilities (for example bug bounties) | [Answer] | EVD-007 |
| 5 | Use of, or contribution to, international standards and tools for risk identification and evaluation | [Answer] | EVD-008 |
| 6 | Collaboration with stakeholders across sectors on risks with broad or cascading socio-economic impact | [Answer] | EVD-009 |
Example answer for 1A (model developer): "We apply a published
frontier safety policy (link) that defines capability thresholds for
chemical and biological uplift, offensive cyber operations and
autonomous replication. Crossing a threshold requires the safeguards
listed for that level before external deployment. Our deployment board,
chaired by the chief risk officer, decides on release using evaluation
results, red-team findings and residual risk ratings. Agentic features
receive an additional review of tool permissions and human approval
points." Link to Frontier Safety Framework (ai-data/frontier-safety-framework)
if you maintain one.
3. Section 2: Risk management and information security
3.1 Lifecycle risk management (Q7)
| Lifecycle stage | Practices, tools and metrics used |
|---|---|
| Plan and design | Example: Use-case intake and AI impact assessment; threat modelling |
| Collect and process data | Example: Dataset audits, personal data filtering, licence checks |
| Build, integrate and interpret model | Example: Safety fine-tuning, interpretability probes |
| Verify and validate | Example: Capability and safety evaluations, red teaming |
| Deploy | Example: Staged release, usage policy, guardrails |
| Operate and monitor | Example: Abuse monitoring, incident response, drift checks |
Q7A asks for a consolidated description of how these practices fit
together, how often they are reviewed and which events trigger an
update. Q7B asks how you ensure data quality and fairness during data
collection and curation. For fairness evidence, Algorithmic Bias
Profile (ai-data/bias-profile-7003) gives a structured record.
3.2 Security, IP, privacy and agentic controls
| Q | Topic (paraphrased) | Answer | Evidence |
|---|---|---|---|
| 8 | Security measures used when testing AI systems | [Selected options] | EVD-010 |
| 9 | How intellectual property, including copyright-protected content, is protected | [Answer] | EVD-011 |
| 10 | How privacy is protected and disclosure of confidential or sensitive data is prevented across the lifecycle | [Answer] | EVD-012 |
| 11 | How cybersecurity risks to advanced AI systems are assessed and policies implemented, including insider threats and model weight protection where relevant | [Answer] | EVD-013 |
| 12 | Vulnerability management process and collaboration with others to address identified risks | [Answer] | EVD-014 |
| 13 | Post-deployment practices to monitor and respond to vulnerabilities, incidents, emerging risks and misuse | [Answer] | EVD-015 |
| 14, 14A | Whether the organisation develops or deploys agentic AI and which categories of controls it applies (for example constraints on action space, sandboxing, allow-lists) | [Yes / No / Not applicable; selected controls] | EVD-016 |
For agentic systems, the evidence for Q14 usually sits in an Agentic
AI Threat Model (ai-data/agentic-threat-model) and an Agentic AI
Governance Assessment (ai-data/agentic-ai-governance-singapore).
Describe control categories without disclosing details an attacker
could use.
4. Section 3: Transparency reporting on advanced AI systems
| Q | Topic (paraphrased) | Answer | Evidence |
|---|---|---|---|
| 15 | Whether public reports or technical documentation describe capabilities, limitations and appropriate and inappropriate uses, in terms non-technical readers can follow | [Yes / No / Not applicable] | EVD-017 |
| 15A | Which items public documentation contains (risk policies, evaluation results including impacts on groups, red-team results, capabilities and limitations, instructions for use, plain-language summaries) | [Selected items with links] | EVD-018 |
| 15B | How often documentation is updated (at releases, on a fixed cadence, on material change) | [Answer] | EVD-019 |
| 16 | How results of risk and impact evaluations are shared with other organisations, governments, civil society and academia | [Answer] | EVD-020 |
| 17 | Whether public privacy policies cover personal data, user prompts and outputs | [Answer, link] | EVD-021 |
| 18 | Information provided about sources of training data, including annotation and enrichment | [Answer] | EVD-022 |
| 19 | Other transparency methods | [Answer] | EVD-023 |
| 20 | Whether statistical insights from anonymised, aggregated usage data are published to inform understanding of AI adoption and economic impact | [Answer] | EVD-024 |
Useful sources inside the organisation: AI System Card
(ai-data/ai-system-card), Model Card (ai-data/model-card), and, for
EU general-purpose models, GPAI Model Documentation
(ai-data/gpai-model-documentation).
5. Section 4: Organisational governance, incident management and transparency
| Q | Topic (paraphrased) | Answer | Evidence |
|---|---|---|---|
| 21 | Which bodies oversee AI risk (board, executive, senior management, governance committee, independent advisory body) | [Selected options] | EVD-025 |
| 21A | How AI risk management is built into governance: advisory versus decision roles, final accountability, policy review frequency and triggers | [Narrative] | EVD-026 |
| 22 | Whether relevant staff are trained on governance policies and risk practices | [Answer] | EVD-027 |
| 23 | Whether steps taken on reported incidents are documented and kept internally | [Answer] | EVD-028 |
| 24 | Whether research and good practice on managing risk are shared | [Answer] | EVD-029 |
| 25 | Use of international technical standards or good practice for AI risk management and governance | [Answer, for example ISO/IEC 42001, NIST AI RMF] | EVD-030 |
Example: The diagram above shows an organisation where the executive
AI council holds final decision authority on high-risk launches and the
board risk committee receives a quarterly report. Replace it with your
own structure. Link the incident process to AI Incident Report
(ai-data/ai-incident-report) and the management system to
ISO/IEC 42001 AI Management System (compliance/iso-42001-ai-management).
6. Section 5: Content authentication and provenance
| Q | Topic (paraphrased) | Answer | Evidence |
|---|---|---|---|
| 26 | Mechanisms that let users know they are interacting with an advanced AI system (notices, persistent indicators, labels, documentation, provenance information) | [Selected options] | EVD-031 |
| 26A | Further context, for example mechanisms planned, in testing or limited to some products | [Narrative] | EVD-032 |
| 27 | Whether provenance, labelling or watermarking lets users identify AI-generated content | [Yes / No / Not applicable] | EVD-033 |
| 27A | How: hidden (latent) disclosure, visible (manifest) disclosure, detection tools, use of standards such as C2PA | [Selected options] | EVD-034 |
| 27B | Whether international standards or good practice are used | [Answer] | EVD-035 |
| 27C | Whether the organisation collaborates on or funds provenance research | [Answer] | EVD-036 |
| 27D | Description of implementation, standards and tools, collaborations, and robustness testing against removal or tampering | [Narrative] | EVD-037 |
| Media type | Disclosure to user | Marking method | Detection available | Robustness tested |
|---|---|---|---|---|
| Text (Example) | Chat banner | None (not reliable for short text) | No | Not applicable |
| Images (Example) | Label in UI | C2PA manifest plus invisible watermark | Yes, public verifier | Cropping, compression |
| Audio (Example) | Spoken notice | Audio watermark | Internal only | Re-recording |
| [Media] | [How] | [Method] | [Yes/No] | [Tests] |
For a full plan, see AI Content Transparency Plan
(ai-data/ai-content-transparency-plan).
7. Section 6: Research and investment for safety and societal risks
| Q | Topic (paraphrased) | Answer | Evidence |
|---|---|---|---|
| 28 | Research and investment areas (security, safety, data quality and representativeness, information integrity, performance, explainability, transparency, robustness) | [Selected areas] | EVD-038 |
| 28A | Key initiatives, for example dedicated safety teams, research funding, open-source safety tools | [Narrative] | EVD-039 |
| 29 | Research or investment on socio-economic or environmental aspects of AI development and deployment | [Answer] | EVD-040 |
| Initiative | Area | Scale | Public output | Period |
|---|---|---|---|---|
| [Safety evaluation team] (Example) | Safety, robustness | 12 FTE | Two papers, one open-source eval suite | 2025 to 2026 |
| [University partnership] (Example) | Explainability | USD 400,000 grant | Workshop report | 2026 |
| [Energy reporting] (Example) | Environment | Internal | Training energy disclosed in model card | Ongoing |
8. Section 7: Advancing human and global interests
| Q | Topic (paraphrased) | Answer | Evidence |
|---|---|---|---|
| 30 | Support for digital literacy, education or training that helps people understand capabilities and limits of advanced AI | [Answer] | EVD-041 |
| 31 | AI projects aimed at societal or public benefit, including partnerships with civil society and community groups | [Answer] | EVD-042 |
Example: "We provide a free AI literacy course in six languages,
completed by 40,000 learners in 2026, and partner with two public
hospitals on triage research with independent ethics review." Internal
staff programmes can be documented in AI Literacy Plan
(ai-data/ai-literacy-plan).
9. Evidence and link register
| ID | Document | Public URL | Owner | Last checked |
|---|---|---|---|---|
| EVD-001 (Example) | AI risk taxonomy summary | [https://example.org/ai/risk-taxonomy] | [@ai-governance] | YYYY-MM-DD |
| EVD-002 (Example) | Frontier safety policy | [URL] | [@safety] | YYYY-MM-DD |
| EVD-006 (Example) | Vulnerability disclosure page | [URL] | [@security] | YYYY-MM-DD |
| EVD-018 (Example) | Model and system cards | [URL] | [@product] | YYYY-MM-DD |
| EVD-0NN | [Document] | [URL] | [@name] | YYYY-MM-DD |
Internal-only evidence: keep a separate list of non-public documents that support your answers. The OECD may ask for additional non-public supporting information; know in advance who can release it.
10. Submission checklist and timeline
| Step | Owner | Target date | Done |
|---|---|---|---|
| Confirm eligibility (OECD member, GPAI member or Adherent jurisdiction) | [@legal] | YYYY-MM-DD | [ ] |
| Download current questionnaire and instructions; check version | [@report-owner] | YYYY-MM-DD | [ ] |
| Assign each section to an owner; gather evidence | [@report-owner] | YYYY-MM-DD | [ ] |
| Draft answers in this template | Section owners | YYYY-MM-DD | [ ] |
| Remove confidential and security-sensitive detail | [@security], [@legal] | YYYY-MM-DD | [ ] |
| Verify every link is public and working | [@comms] | YYYY-MM-DD | [ ] |
| Attestation of accuracy by authorised officer | [@officer] | YYYY-MM-DD | [ ] |
| Register and submit through the OECD.AI portal | [@report-owner] | YYYY-MM-DD | [ ] |
| Respond to any OECD request for complementary information | [@report-owner] | Within the requested time | [ ] |
| Schedule resubmission within 12 months | [@report-owner] | YYYY-MM-DD | [ ] |
The Secretariat checks eligibility, completeness and that supporting material is accessible; it does not verify the substance of answers, and listing is not a certification of compliance with the Code of Conduct. An organisation can be delisted if it misses the 12-month cycle, fails to answer requests in time, acts inconsistently with its report, or provides inaccurate information. For the 2026 round the OECD.AI page stated that reports submitted by 30 September 2026 would feed the next analytical review; check the page for the current cycle.
11. Glossary and references
| Term | Meaning in this document |
|---|---|
| Advanced AI system | The most capable AI systems, including foundation and generative models, as used in the Code of Conduct |
| Model developer | Organisation that designs, builds and trains AI models |
| Application developer | Organisation that builds applications or services on AI models and provides them to deployers |
| Deployer | Organisation that puts AI applications into real-world use and operates them |
| Latent disclosure | Provenance information hidden in content, such as metadata or watermarks |
| Manifest disclosure | Visible label telling people that content is AI-generated |
| HAIP brand | Recognition displayed on published reports of organisations that complete the framework |
References:
- OECD, Hiroshima AI Process Reporting Framework, Version 2.0, questionnaire and instructions, https://oecd.ai/en/transparency
- OECD.AI, Reporting framework FAQ, https://oecd.ai/en/transparency/faq
- G7, Hiroshima Process International Code of Conduct for Organizations Developing Advanced AI Systems (October 2023)
- G7, Hiroshima Process International Guiding Principles for Organizations Developing Advanced AI Systems (October 2023)
- OECD Recommendation of the Council on Artificial Intelligence (OECD AI Principles, as revised in 2024)
- OECD.AI Catalogue of Tools and Metrics for Trustworthy AI
- Related templates: AI Risk Assessment (
ai-data/ai-risk-assessment), GenAI Risk Profile (ai-data/genai-risk-profile), AI Regulatory Applicability Register (compliance/ai-regulatory-applicability-register)
Standard and licence note
Based on the OECD Hiroshima AI Process Reporting Framework, Version 2.0 (questionnaire and instructions published on OECD.AI, consulted October 2026), which monitors the G7 Hiroshima Process International Code of Conduct for Organizations Developing Advanced AI Systems. The section titles, question numbers and action mapping follow the questionnaire; all question summaries, tables and examples are original paraphrases and no OECD text is reproduced. Reporting is voluntary and publication is not an endorsement or certification. Check oecd.ai for the current questionnaire, deadlines and conditions before submitting. This is a documentation format, not legal advice. Template licence: MIT.
Plantillas relacionadas
A2A Agent Card and Interface Specification Template (A2A 1.0)
A2A agent spec: Agent Card fields, skills, bindings, security schemes, operations, task states, parts, push, errors, discovery, example card, conformance
IA y datosAI Agent Evaluation Plan Template (Task Success, Trajectory, Tool Calls)
Agent task suite, success, trajectory, tool-call and argument metrics, sandboxed harness, online tests, calibrated graders, statistics, ASI safety cases, gates
IA y datosAgent Safety Case Template (GSN, OWASP Agentic)
Agent safety case: autonomy, hazards, GSN-style claims, arguments, evidence, defeaters, residual risk, OWASP ASI and Singapore MGF mapping