G7 Hiroshima AI Process: Turn the Voluntary Code Into Evidence

On 30 October 2023, G7 leaders agreed international guiding principles and a voluntary code of conduct for organizations developing advanced AI systems. The European Commission's official Code page describes a risk-based, lifecycle approach for advanced foundation models and generative AI systems. Its 11 actions assign work across several control owners. Turning them into one gateway requirement would erase the model and organization work, along with the infrastructure and content-provenance work the text assigns elsewhere.

I would reject a control map that marks the whole Hiroshima AI Process green because a company publishes a model card. One document cannot prove 11 operating actions.

TL;DR

• The G7 adopted guiding principles and a voluntary code for advanced AI systems on 30 October 2023.
• The code's 11 actions cover lifecycle testing and incidents; transparency and governance; security and provenance; research and standards; and data protections.
• The framework is a living, risk-based document rather than a certification or binding statute.
• HTTP request policy can support routed-use evidence. Model testing and weight security need other owners, as do provenance and public reporting.

The process produced two linked instruments

The official International Guiding Principles page says the principles build on the OECD AI Principles and apply across design and development as well as deployment and use where relevant. They address organizations in academia and civil society, along with the private and public sectors. The separate Code turns that direction into voluntary actions for organizations developing advanced AI systems.

This status belongs at the top of every control map. The G7 text guides conduct and risk management. It creates no certification mark, audit opinion, or automatic legal safe harbor. Different jurisdictions can implement the actions through their own approaches, and the documents describe themselves as living instruments subject to review.

That makes implementation an evidence exercise rather than a checkbox exercise. For each applicable action, record the owner and system boundary; the risk decision and control; the test and evidence location; and the exception and review date. The AI governance framework provides the organizational structure around that map.

Lifecycle testing and incident evidence

Actions 1 and 2 cover risk identification and evaluation, along with mitigation and post-deployment monitoring. The Code calls for internal testing and independent external testing, including red teaming, with traceability for datasets and processes as well as development decisions. After deployment, organizations should monitor vulnerabilities and incidents, along with emerging risks and misuse, then maintain documentation and mitigation records.

A useful evidence package links one identified risk to its test case and result, its accepted threshold and mitigation, and its owner and retest. Incident evidence should identify the report and affected release; the timeline and containment decision; and the corrective action and closure test. The package also needs the rationale for risks judged inapplicable.

During an overnight incident, a responder should see the deployed model version and incident owner on the same screen as the current containment instruction. Six disconnected slide decks are governance theater. My opinion is that an untested incident procedure should be recorded as a planned control, never an implemented one.

NIST AI RMF implementation offers a compatible way to separate governance and mapping artifacts from measurement and management artifacts.

Transparency, information sharing, and governance

Actions 3, 4, and 5 assign work beyond technical enforcement. The Code calls for public reporting on capabilities and limitations; appropriate and inappropriate uses; evaluations; and material risks for significant releases. It also encourages responsible incident and risk information sharing across industry and government as well as civil society and academia. Internal AI governance structures and policies should support accountable implementation.

These actions need named publication and disclosure processes. Model teams own evaluation records and known limitations. Legal and communications owners govern public reports. Incident leadership controls external sharing. The board or delegated governance body approves risk policy and accountability, including escalation.

Preserve each published report and the evidence behind it. Record the release it covers and approval date; the accountable signer and source evaluations; and the disclosed limitations and later correction. The public artifact should join to internal evidence without exposing secrets or personal data. A runtime request log may support one incident timeline. It cannot author a transparency report or decide which security detail is safe to disclose.

Security, provenance, and standards require separate controls

Actions 6 through 10 cover security controls and content authentication with provenance. They also cover safety research, development directed toward global challenges, and international technical standards. Action 11 calls for input protections that account for privacy and intellectual property. It also covers quality and harmful bias, plus transparency about training sources.

Each action belongs to a different control surface. Security engineering protects model weights and algorithms, along with servers and datasets. Content-provenance owners test watermarks and labels or other mechanisms, then preserve the service or model identifier. Research leadership tracks funded work and resulting mitigations. Standards teams document participation and adopted specifications. Data governance owners maintain provenance and rights; quality tests and personal-data controls; and bias assessments.

A red-team report cannot prove training-data rights. A watermark cannot prove weight access control. An HTTP gateway record cannot establish that a dataset license permits model training. The AI accountability framework should retain these owners separately even when one incident draws evidence from several systems.

Routed-use evidence supports a narrow slice

A deployed application creates an additional evidence stream when an authenticated user or agent sends HTTP traffic to an LLM. A policy point on that route can record the supplied identity and role; the request classification and model destination; and the policy version, decision, and timestamp. Those fields can support post-deployment monitoring and misuse investigation. They can also support incident reconstruction and enforcement of approved-use rules.

The coverage claim must name the route. It applies to traffic deliberately sent through the enforcement point. Local inference and model training sit elsewhere, as do weight storage and content watermarking. Training-data provenance, direct browser use outside the route, and model evaluations also sit elsewhere. The gateway also depends on the calling application for trustworthy identity context.

Run a concrete test against the approved route. Send a synthetic restricted prompt through an approved application and verify the expected block. Retrieve the signed decision record, then join it to the incident or exception workflow. Finally, attempt a documented bypass path. Record the gap instead of borrowing coverage from the successful routed test.

Responsible AI governance explains how request evidence joins a broader governance record without claiming the whole program.

A practical Hiroshima control map

Start with the 11 actions and group them by evidence owner. Keep the source language and the implementation decision in separate fields.

• Model assurance: lifecycle risk analysis and red teaming; evaluations and limitations; and retests.
• Incident operations: vulnerability intake and misuse monitoring; incident records and mitigation; and responsible information sharing.
• Corporate governance: risk policy and accountability; approvals and exceptions; and public transparency reporting.
• Infrastructure security: model weights and algorithms; servers and datasets; access controls; and insider-threat safeguards.
• Content provenance: service or model identifiers and labels, along with watermark tests and user-facing verification mechanisms.
• Research and standards: funded mitigation work and adopted specifications, plus standards participation.
• Data governance: rights and privacy; input quality and bias testing; and training-data transparency.
• Routed use: authenticated request context and classification; destination and policy decision; and independent event evidence.

For every row, specify applicability and owner; test and evidence; and failure behavior and review date. Use partial status when evidence covers only one deployment or route. The control map becomes defensible when a reviewer can rerun the test and retrieve the same class of evidence.

DeepInspect

DeepInspect covers the routed-use portion of a Hiroshima evidence map. It sits as a stateless proxy between authenticated users or agents and deliberately routed HTTP LLM endpoints. The application supplies identity context. DeepInspect evaluates classification and role, along with destination and versioned policy, before forwarding the request. It then writes a signed, tamper-evident decision record.

That record can support approved-use enforcement and misuse investigation, along with incident reconstruction for traffic inside the route. Model development and independent evaluation remain with their assigned owners. So do weight protection and public reporting, plus watermarking, standards participation, and training-data governance. Book a technical deep dive at deepinspect.ai.