Reading DS-920, Japan's Government Guideline for Procuring Generative AI

Hello, this is Ryuta Hamamoto from TIMEWELL.

Last week I read a 64-page PDF from beginning to end. It is the Digital Agency's 行政の進化と革新のための生成AIの調達・利活用に係るガイドライン (Guideline on the Procurement and Use of Generative AI for the Advancement and Innovation of Government), catalogued as DS-920.¹ The Steering Committee of the Digital Society Promotion Council adopted it on June 12, 2026, and under its supplementary provisions it took effect on September 1, 2026. At the time of writing it has been live for a matter of days.

It is a government document, so you may assume it has nothing to do with you. I opened it with the same assumption. I had changed my mind by the time I finished. Most of the content is about what a buyer of generative AI should check with the seller, and almost all of that transfers directly into a private-sector procurement specification. It is also written as rules to be followed, not as background reading.

Two of my predictions turned out to be wrong. One was about how the text handles where data physically sits. The other was about how it treats the question of not locking yourself to a single model. I will take them in order.

Two groups of readers should care about this. If you are an overseas vendor selling generative AI systems into Japanese ministries, this is the document your buyer is holding while they read your proposal. If you sit on the procurement side of a Japanese company, it is the best free template you are going to find for the specification you are about to write.

If you want to know where your own organization stands before you go any further, running our free AI readiness check first makes the rest of this a lot more concrete.

The 64 pages that went live on September 1

Start with what this document is. The Digital Agency's standard guideline family contains documents that offer reference information and documents that set out rules to be followed. DS-920 is the second kind. It is explicitly marked as Normative. The first edition came out on May 27, 2025, and what I read is the revision dated June 12, 2026. The Digital Agency publishes an English announcement of it as well.²

Before this, business use of generative AI inside government sat under a separate document, ChatGPT等の生成AIの業務利用に関する申合せ (Agreement on the Business Use of Generative AI such as ChatGPT).³ That agreement was abolished at version 2.1, and everything now runs through DS-920. If you only read one Japanese government text on this subject, the fact that the entry point has been consolidated into a single document makes the choice easy.

The revision history is worth a minute, because it tells you what moved in the past year. The Act on the Promotion of Research and Development and Utilization of AI-Related Technologies (人工知能関連技術の研究開発及び活用の推進に関する法律, Act No. 53 of 2025) was enacted.⁴ The AI Basic Plan (人工知能基本計画) made under it was adopted by Cabinet decision on December 23, 2025.⁵ The 人工知能関連技術の研究開発及び活用の適正性確保に関する指針 (Guideline on Ensuring the Appropriateness of Research and Development and Utilization of AI-Related Technologies) was decided on December 19 of the same year.⁶ The AI Business Operator Guidelines from the Ministry of Internal Affairs and Communications and the Ministry of Economy, Trade and Industry moved to version 1.2.⁷ DS-920 is the edition that absorbs all of that. My reading is that Japan's AI rules acquired a full skeleton by the end of 2025, and this document is one of the first things built on top of it.

The commencement was staged, which is itself instructive. The main body applies from September 1, 2026. For the provisions concerning each ministry's AI統括責任者 (Chief AI Officer), the necessary measures had to be settled by June 30, 2026, and the AI governance framework covering the generative AI in scope applies from July 1, 2026. Put the person in charge in place first, then switch on the rules. You can read the sequencing straight off the dates.

How the scope is drawn is also worth copying. The guideline covers, in principle, generative AI whose input is text and audio and whose output is text, images or audio. Systems that take images or video as input, systems that generate video, and more capable systems such as AI agents are handled differently. No specific action items are set for them, but they are still brought inside the AI governance framework. Rather than trying to regulate everything at once, the document puts structure and reporting over the newer categories and leaves the detailed requirements for later. As an implementation order, that is realistic.

There is also a set of areas cut out of scope entirely. Government information systems handling Specially Designated Secrets (特定秘密), Important Economic Security Information (重要経済安保情報), or information classified as secret documents under the Guidelines for the Management of Administrative Documents fall outside the whole of DS-920. Systems handling sensitive information such as national security or the maintenance of public safety and order are excluded on the same basis. This is not a relaxation. It is a statement that those areas belong to a different framework. The private-sector version of the same move is worth imitating: decide what will never go near a generative AI system, then write the rules for whatever is left.

One more note on audience. Independent administrative agencies and designated corporations are expected to take measures in line with the guideline, and local governments are expected to refer to it as needed. The direct addressees are national government officials, but the document was clearly written with a wider readership in mind.

The government never once writes "region"

Here is the first thing I got wrong. I wanted to know how the government describes where data lives, so I searched the full text. The word "region" does not appear anywhere in the 64 pages.

What sits in its place is ISMAP.

本ガイドラインの対象となる生成 AI システムに関して、要機密情報を取り扱うクラウドサービスを調達する場合においては、政府情報システムのためのセキュリティ評価制度（ISMAP：Information system Security Management and Assessment Program）の原則利用の考え方に基づき、原則として ISMAP 等クラウドサービスリストから選定した上で、別途、本ガイドラインによる対応を行う必要がある。

In English: where a generative AI system in scope involves procuring a cloud service that handles confidential information, the service must in principle be selected from the ISMAP or equivalent cloud service list, following the principle of using ISMAP for government information systems, and the measures under this guideline must then be carried out separately.

The government is not binding data to a place name. It is binding it to an assessment scheme. And picking from the list is not the end of it. The text goes out of its way to say that because the risks specific to generative AI are addressed separately by this guideline, selecting a service from the list does not remove the obligation to apply the guideline's own measures. A scheme narrows the entrance, and individual checks follow behind it.

Write "the Japanese government also requires a domestic region" into an internal memo without knowing that structure and you have written something factually wrong. I worked through the difference between availability and where processing actually happens in running LLMs in Japanese regions. Approaching it from the government-document side leads to the same conclusion by a different road. What is being constrained is the scheme, not the map.

ISMAP registration attaches to the platform, not to individual models

A footnote adds something practical. Consider the case where a cloud provider receives models from model providers and offers a service on top of its own generative AI development platform, which applies security management functions to the data. That is the PaaS-equivalent shape. If that development platform is included in the scope of the declaration (言明対象範囲) and registered with ISMAP, then the security of the data handled by the service is normally treated as satisfying ISMAP requirements. The text then states plainly that the individual models offered on the platform do not need to be included in that scope, and the models themselves do not need to be ISMAP-registered.

So the question "is this model ISMAP-certified?" is malformed from the start. It does not match how the scheme is built. The thing to look at is the registered scope of the platform. That footnote deserves more attention than it is likely to get.

The passage about overseas servers is not about personal data law

How, then, does the government express the risk of data leaving the country? Here is the passage.

※ 国外にサーバ装置を設置している場合は、現地の法令が適用され、現地の政府等による検閲や接収を受ける可能性がある。

Where server equipment is located outside Japan, local law applies, and censorship or seizure by the local government or similar authorities is possible.

The reasons given are the applicable law and the possibility of censorship or seizure by that country's authorities. Not personal data protection law. DS-920 did not invent this framing either. It is lifted from the Common Standards for Information Security Measures for Government Agencies and Related Agencies (政府機関等のサイバーセキュリティ対策のための統一基準群),⁸ which offers it as an example of a risk worth weighing even when no confidential information is involved. The same point is repeated in the annex written for end users.

In that context, DS-920 asks readers to take account of the alert issued on February 6, 2025, DeepSeek等の生成AIの業務利用に関する注意喚起 (Alert on the Business Use of Generative AI such as DeepSeek).⁹ The fact that the government issued an alert about a specific service, and the specific grounds it cited, are both worth getting right. Read the alert itself and three points come out. The secretariat of the Personal Information Protection Commission had provided information about the country in which servers holding data acquired through use of the service are located, and about the laws applying to that data.¹⁰ The Common Standards give the overseas-server situation as an example risk. And the service falls within the scope of the agreement on IT procurement.¹¹ It is not a document that evaluates the technical merits of a service or the conduct of a company. It is an alert about one thing only, which is the legal jurisdiction the data ends up under.

Building on that, DS-920 requires that even where use involves no procurement at all, officials seek advice from the National Cyber Office (国家サイバー統括室) before judging whether the use is appropriate. In other words, the shortcut of "it's free, so it doesn't need an approval process" has been closed off by rule. Anyone who has watched a free tier quietly spread through an organization will recognize why that sentence exists.

The procurement checklist runs to 33 requirements, and 20 are baseline

This is where the second surprise was waiting. DS-920 carries a procurement checklist as Annex 3, and it rewards reading as much as the main body does.

The structure works like this. Three classifications, covering organizational requirements, development and operation process requirements, and basic functional requirements for the generative AI system, hold 21 evaluation viewpoints between them, and 33 requirements hang off those. Each requirement carries a label. Those that should in principle be required of a system procured by a government agency are basic items. Those worth considering as circumstances warrant are optional additional items that earn extra credit. Counting them out gives 20 basic items and 6 additional items. The remaining 7 come with conditions attached, along the lines of "applies where unspecified external parties use the system from outside the ministry" or "applies where personal information is handled."

The five requirements under evaluation viewpoint 8, the avoidance of vendor lock-in, are the ones I want to put in front of you.

Requirement	Classification	Substance (summarized)
8	Basic item	The generative AI model in use can be identified, including its version information
9	Additional item	Information can be disclosed to the planning side within a reasonable scope, so that it can be confirmed that no part of the prompt or the parameters is concealed
10	Additional item	The technology is available to save chat history, register prompt templates, and export both
11	Additional item	Where use of one specific model is not the main purpose, the technology is available to select the best model from several generative AI models, or to combine them
12	Basic item	Architecture design and implementation allow development and operation that takes account of ease of vendor and system migration

Read the classifications carefully, because this is exactly where summaries go wrong. Being able to choose among several models is an additional item. What is required in principle is being able to state the version, and being able to migrate. The accurate reading is that the government put "can you replace it later" on the mandatory side and left "what are you choosing today" on the optional side. As a practitioner I find that ordering easy to accept. Good models get replaced within six months. A structure you cannot get out of stays for years.

The countermeasure examples under requirement 12 go further than I expected a procurement document to go. Design AI components as loosely coupled, using standardized interfaces and protocols. Provide an abstraction layer, an adapter, that anticipates switching models or vendors, and build the exit strategy in at the architecture level. Design the component architecture so that models, treated as replaceable parts, are easy to swap. Even system prompts get a mention, with a recommendation to clarify the role of each paragraph and raise modularity. As language destined for a specification sheet, that is unusually specific.

Why go that far? The answer is in the risk chapter. Among the risks government bodies are told to weigh, two sit next to each other: increased cost and entrenched bias arising from dependence on a single family of models, and unnecessary cost increases arising from vendor lock-in. Both cost and bias are named as reasons. This is not only a conversation about money.

Security is handled with the same concreteness. DS-920 draws on the Ministry of Internal Affairs and Communications' AIのセキュリティ確保のための技術的対策に係るガイドライン (Guideline on Technical Measures for Securing AI) and lays out, in table form, the countermeasures available to developers and to providers for three attack types: direct prompt injection, indirect prompt injection, and denial of service.¹² The framing is that the factors giving rise to these threats are difficult to eliminate completely, and a single countermeasure may not be enough, so as many measures as possible should be layered. The same instinct runs through the whole document. Do not bet everything on one mechanism.

"Multiple models" turns up in three separate places

What I find genuinely interesting is that the multiple-model idea is not confined to the procurement requirements. Search the full text and it appears three times, in three unrelated contexts.

The first is the lock-in requirement we just looked at, requirement 11. The second is under fairness and inclusiveness, in the countermeasure examples for requirement 20, which suggest using several models in view of the fact that models may carry different ideologies and biases. The same passage asks that information be organized and provided about the possibility that a model has output restrictions in particular fields under laws and regulations. The third is under the prevention of false and misleading output, in the countermeasure examples for requirement 17, which is a basic item. The method described there is to feed the same factual test data into a model other than the one the system is planned to use, and check whether the output is semantically the same.

Lock-in avoidance, bias mitigation, and fact verification. Three purposes, one shared instrument. I do not read this as the government promoting a particular product architecture. I read it as what happens when you look at the side effects of single-model dependence from three angles and keep arriving at the same answer.

The supporting material listed for requirement 20 is worth quoting in full: 生成AIモデルの提供企業の所在国におけるAIに対する規律や当該生成AIモデルの生成結果のバイアスに対する評価結果等, meaning the rules governing AI in the country where the company providing the generative AI model is located, together with assessment results on bias in that model's output. The buyer is expected to gather, as supporting evidence, which country's rules a model sits under. I honestly did not expect to find that framework written into a public document. What makes it workable in practice is that the wording applies the same test to a model from any country.

Getting "which model do we use, and when do we change it" into a form an organization can actually operate month to month is close to the work we have been doing for enterprises with ZEROCK. Now that a government procurement document has spelled the requirements out this precisely, the argument inside a company has a lot more to lean on.

Twelve things a private buyer can take home

From everything above, here are the twelve points I think travel regardless of industry. The premise stays the same throughout. DS-920 addresses government officials and does not apply to private companies. This is a case of reading a well-built set of procurement requirements and borrowing from it.

Some parts do not travel. The arrangements for evaluating digital startups in procurement, and the use of the Digital Marketplace operated by the Digital Agency,¹³ only make sense inside a public procurement framework. So does the instruction to consult the section on use errors specific to AI systems in the Usability Guideline before release.¹⁴ What you can lift is the part about what to ask the vendor.

First, decide what will not go into a generative AI system, before anything else. The government removed systems handling Specially Designated Secrets and Important Economic Security Information from scope entirely. Drawing that line first, then designing rules for the remainder, is simply faster than the reverse.

Second, vary the level of requirement by adoption type. DS-920 splits usage into type A, where nothing is developed individually and use begins by agreeing to standard terms; type B, where an individual contract is signed on top of those terms; and type C, where both individual development and an individual contract are involved. For type A, the premise is that confidential information will not be handled. If you have requirements you actually want enforced, the text tells you to consider procuring under B or C. Not auditing everything against the same bar sounds obvious, and it is still worth having written down.

The third through fifth points are about structure. Write clearly in your internal rules that the standard-terms route does not handle confidential information. Judge whether a use case is high risk along three axes: the nature of the work, the scope of use, and whether a person reviews the appropriateness of the output before it is used. Then appoint one accountable person. The government created the role of AI統括責任者 (Chief AI Officer) and provided that it is held by officials at the level of the ministry's デジタル統括責任者 (Chief Digital Officer). Leave that ambiguous and no amount of rigor in individual tool reviews will save you.

The sixth through ninth points can go into a specification sheet more or less as written. Require the model in use to be disclosed, including version information. Write ease of migration in as an architecture requirement. Make export of chat history and prompts a requirement. And build into the contract an obligation to re-verify output quality and safety when the model receives a major update. What strikes me as significant here is the precedent. Words like abstraction layer and loose coupling are now demonstrably acceptable in a procurement document.

The last three are contractual. DS-920 carries a contract checklist as Annex 4, in which nine agreement items are all classified as basic items. They cover the definition of inputs and the purpose of their use, the prohibition of use beyond that purpose, the terms of use including whether inputs are used for training, and where rights sit. The same treatment is required for outputs and for the results of processing them. Add logging of inputs, outputs and access history, and an advance commitment that the vendor will supply data for root-cause investigation and cooperate with audits if an incident or a risk case occurs, and you have twelve.

Having listed all twelve, the line I think matters most in practice is a supplementary note attached to that contract checklist.

生成 AI モデルに起因する性能・出力品質については、学習データや基盤モデル等の特性にも左右され、「○○以上の精度」等の成果保証を行うことが困難な場合があるため、その場合には、当該部分は成果保証ではなく、性能改善・品質向上に向けた技術的支援を受ける等の契約形態を取ることが望ましい。

Performance and output quality attributable to a generative AI model depend on the characteristics of the training data and the foundation model, so guaranteeing results in the form of "accuracy of at least X" may be difficult. Where that is the case, the note says, it is preferable to structure that part of the contract not as a guarantee of results but as, for example, the provision of technical support toward improving performance and quality.

A buyer's own document admitting head-on that accuracy is hard to promise strikes me as an unusually honest piece of drafting. Procurement that extracts a numeric accuracy guarantee feels reassuring on the day the contract is signed and makes nobody happy once the system is running. What should be committed to is not a number at the end, but the work of continuing to raise quality. I agree with where they landed.

What stayed with me after finishing it

Reading all 64 pages left me less interested in how the government intends to use generative AI than in how well the thing works as a procurement document. It names no specific product and no specific country, and lists only the properties you should verify. It separates basic items from additional items, so the line between required and recommended is visible. It concedes that accuracy is hard to guarantee, and then says what to require instead. Those three qualities make it a decent model for anyone rewriting their own procurement standards.

It also works as a mirror held up to your own architecture. Could you name the version of the model you are running right now, without looking it up? If you decided today to change vendors, how many months would it take? Stumble on either and you are not yet at the level the government treats as required in principle. Whether your prompts and history survive the end of a contract is on the optional side of their list, but measured by how much trouble it causes when it goes wrong, I would weigh it just as heavily.

People often come to me having been handed responsibility for procuring generative AI, with no idea what to check first. My advice is to read this PDF. It is free, it is a primary source, and it is written at a level of detail you can copy into your own specification. If you would then like to work through how it maps onto your business, get in touch through our individual consultation. We can start from turning what you have read into your own procurement standard.

---

Footnotes

1. Digital Agency, "デジタル社会推進標準ガイドライン DS-920 行政の進化と革新のための生成AIの調達・利活用に係るガイドライン" (Digital Society Promotion Standard Guidelines DS-920, Guideline on the Procurement and Use of Generative AI for the Advancement and Innovation of Government), decided by the Steering Committee of the Digital Society Promotion Council on June 12, 2026 (Reiwa 8). Positioned as Normative, 64 pages in total. First edition May 27, 2025. Every quotation, requirement number and classification used here comes from the body and annexes of that PDF. https://www.digital.go.jp/assets/contents/node/information/field_ref_resources/decb64eb-f26e-41cb-8d37-f3dd173108b8/59054b35/20260612_resources_standard_guidelines_guideline_01.pdf ↩

2. Digital Agency information page for the guideline, including the English announcement. https://www.digital.go.jp/en/news/decb64eb-f26e-41cb-8d37-f3dd173108b8 ↩

3. "ChatGPT等の生成AIの業務利用に関する申合せ（第2版）" (Agreement on the Business Use of Generative AI such as ChatGPT, second edition), agreed by the Steering Committee of the Digital Society Promotion Council on September 15, 2023 (Reiwa 5). Version 2.1 has been abolished and consolidated into DS-920. https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c64badc7-6f43-406a-b6ed-63f91e0bc7cf/e2fe5e16/20230915_meeting_executive_outline_03.pdf ↩

4. 人工知能関連技術の研究開発及び活用の推進に関する法律 (Act on the Promotion of Research and Development and Utilization of AI-Related Technologies, Act No. 53 of 2025). https://laws.e-gov.go.jp/law/507AC0000000053 ↩

5. Cabinet Office, "人工知能基本計画" (AI Basic Plan), adopted by Cabinet decision on December 23, 2025 (Reiwa 7). https://www8.cao.go.jp/cstp/ai/ai_plan/aiplan_20251223.pdf ↩

6. "人工知能関連技術の研究開発及び活用の適正性確保に関する指針" (Guideline on Ensuring the Appropriateness of Research and Development and Utilization of AI-Related Technologies), decided by the AI Strategy Headquarters on December 19, 2025 (Reiwa 7). https://www8.cao.go.jp/cstp/ai/ai_guideline/ai_gl_2025.pdf ↩

7. Ministry of Internal Affairs and Communications and Ministry of Economy, Trade and Industry, "AI事業者ガイドライン（第1.2版）" (AI Business Operator Guidelines, version 1.2), March 31, 2026 (Reiwa 8). DS-920 asks government officials to work in line with "第2部 C. 共通の指針" (Part 2, Section C, the common guiding principles) of those guidelines. https://www.soumu.go.jp/main_content/001064279.pdf ↩

8. National center of Incident readiness and Strategy for Cybersecurity, "政府機関等のサイバーセキュリティ対策のための統一基準群" (Common Standards for Information Security Measures for Government Agencies and Related Agencies). The point about overseas servers originates in the commentary to those standards, where it is given as an example of a risk to consider even where confidential information is not handled. https://www.nisc.go.jp/policy/group/general/kijun.html ↩

9. Secretariat of the Steering Committee of the Digital Society Promotion Council, "DeepSeek等の生成AIの業務利用に関する注意喚起（事務連絡）" (Alert on the Business Use of Generative AI such as DeepSeek, administrative communication), February 6, 2025 (Reiwa 7). https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/d2a5bbd2-ae8f-450c-adaa-33979181d26a/e7bfeba7/20250206_councils_social-promotion-executive_outline_01.pdf ↩

10. Secretariat of the Personal Information Protection Commission, "DeepSeekに関する情報提供" (Provision of Information concerning DeepSeek), February 3, 2025 (Reiwa 7). https://www.ppc.go.jp/news/careful_information/250203_alert_deepseek/ ↩

11. "IT調達に係る国等の物品等又は役務の調達方針及び調達手続に関する申合せ" (Agreement on Procurement Policies and Procedures for Goods and Services of the State and Others Relating to IT Procurement), agreed among the relevant ministries on December 10, 2018 (Heisei 30). https://www.nisc.go.jp/pdf/policy/kihon-2/IT_moushiawase.pdf ↩

12. Ministry of Internal Affairs and Communications, "AIのセキュリティ確保のための技術的対策に係るガイドライン" (Guideline on Technical Measures for Securing AI). DS-920 draws its overview of the main countermeasures against prompt injection attacks and denial-of-service attacks from that guideline. https://www.soumu.go.jp/menu_news/s-news/01cyber01_02000001_00282.html ↩

13. Digital Agency, "デジタルマーケットプレイス" (Digital Marketplace). DS-920 cites use of the marketplace when considering SaaS-type generative AI systems. https://www.dmp-official.digital.go.jp/ ↩

14. Digital Agency, "DS-670.1 ユーザビリティガイドライン" (DS-670.1 Usability Guideline), June 12, 2026. DS-920 asks that this guideline be consulted when ensuring usability ahead of release. https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/a0942cf4/20260612_usability_guidelines.pdf ↩