Hello, this is Hamamoto from TIMEWELL.
Japan's AI Business Operator Guideline was revised to version 1.2 on March 31, 2026[^1]. In the same week, the Ministry of Internal Affairs and Communications (MIC) released its AI Security Assurance Guideline[^3]; the week before, the Financial Services Agency (FSA) issued the AI Discussion Paper version 1.1[^4]; in April, AISI and IPA published the Healthcare AI Safety Evaluation Guide[^5]; and at the end of April, AISI released its annual report[^2]. Japanese AI policy documents have arrived back to back, and over the past two months I have been fielding the same question from many readers: "Given all of this, which document should we actually be reading, and where do we start?"
I personally worked through the minutes of the METI and MIC study groups, the main text of each guideline, the accompanying annexes, and the comparison documents against overseas regulation. What follows is essentially my reading notes, reorganized so that compliance leads and IT directors can act on them starting next week. The full set of documents runs well over a hundred pages when printed; this article is meant as a map you can consult before diving into the originals.
One important point up front. The AI Business Operator Guideline is not a law, and there is no penalty for non-compliance. The reason companies still need to act on it is that procurement reviews, IPO preparation, overseas counterparty assessments, and bank credit reviews increasingly reference it retroactively as the de facto industry baseline. Catching up later is dramatically more expensive than building the foundations from day one. This is not just my own field instinct; it is the consistent experience reported by clients who have already been put through audits and due diligence.
What Changed in v1.2, Published on March 31, 2026
The AI Business Operator Guideline is a joint deliverable from METI and MIC: a self-regulatory guidance document for businesses that develop, provide, or use AI. Since v1.0 was issued in April 2024, the document has been updated roughly once a year, and v1.2 is the third revision[^1].
The reason for v1.2, put bluntly, is that the rapid spread of AI agent implementations had outpaced the document. According to Stanford HAI's 2026 AI Index, AI adoption inside organizations worldwide has reached 88%, and 74% of business users now cite "inaccuracy" as the largest risk[^9]. The center of gravity has shifted from the chatbot era — where a human always reviewed AI output before anything happened — to the agent era, where systems autonomously decompose and execute tasks. The earlier text simply assumed too much human oversight.
There are three main changes.
| Change | Up to v1.1 | v1.2 |
|---|---|---|
| Definition of AI agents | Not explicitly defined | Formally defined as "AI systems that autonomously decompose and execute tasks and act on external systems" |
| Definition of physical AI | Not explicitly defined | A separate category covering robotics, autonomous driving, industrial machinery, and other AI that acts directly on the physical world |
| Human-in-the-Loop (HITL) | Recommended | Effectively required wherever an "external action" is involved |
Human-in-the-Loop (HITL), in this context, means a mechanism in which AI is not left to take important judgments or external actions on its own — a human checks and approves the final action just before it happens. Version 1.2 enumerates concrete examples of "external actions" — sending email, writing to external APIs, deploying to production, making payments, controlling physical devices, publishing information that cannot be retracted — and requires a human checkpoint immediately upstream of each[^11].
The other major shift is that the traceability of training data has been upgraded from "recommended" to "required"[^11]. If you fine-tune with internal data or reference knowledge via Retrieval-Augmented Generation (RAG), you must be able to reconstruct the origin, usage rights, and processing history of that data after the fact. Operations that rely on "data of unknown provenance" to train models are now clearly out of bounds under v1.2.
One more practical note. While the body of v1.2 inherits the structure of v1.1, the annexes are far more substantial[^11]. Risk scenario catalogs, accountability templates, and checklists tailored to each of the three roles have been added. Reading only the main text leaves you short on implementation resolution. When you go to the originals, read the annexes through.
The Three Roles — Developer, Provider, User — and Where Your Company Sits
The guideline structures everything around three actor categories. Even inside a single company, the role shifts depending on the service, which makes this categorization the starting point for everything else.
- AI Developers: companies that train and build AI models themselves. This includes not only foundation-model vendors but also any company fine-tuning its own models on internal data.
- AI Providers: companies that embed third-party AI (OpenAI, Anthropic, Gemini, etc.) or their own models into services delivered to others. Most SaaS vendors, business-system integrators, and consulting firms fall here.
- AI Users: the side that uses AI services in their work. This is further split into "business users" (using AI as part of business activity) and "non-business users" (using it privately).
The practical complication is that almost every enterprise is "all three at once." Running a small classification model on your own servers makes you a developer; offering a customer-facing FAQ bot via the ChatGPT API makes you a provider; having employees summarize meeting notes with Copilot makes you a user. Because the guideline asks different things of each role, sloppy inventory work at this stage will throw everything downstream off course.
What I recommend to clients is to build an eight-column spreadsheet: service name, owning department, role we occupy, presence of personal data, type of external action, current HITL level, model used, country of data residence. It is unglamorous, but this sheet becomes the company's master ledger for AI governance. When the executive team asks "are we okay on AI?", whether or not this ledger appears determines how mature your governance looks from the outside.
One trap to flag when classifying your roles. Most companies that think "we are only a user, so this is easy" actually have provider responsibilities as well. If you place an AI chatbot on your public website, you are a provider. If a business system you built with an outsourcer includes AI features, depending on how the contract is worded you may carry provider liability. Inventory your sales front-ends and your website once. The scope is almost always wider than people assume.
Looking for AI training and consulting?
Learn about WARP training programs and consulting services in our materials.
How the Three Parallel Guidelines (MIC Security, FSA Paper, AISI Healthcare) Relate
This is the section I most wanted to write. Version 1.2 does not stand alone — you only see the whole picture when you read it together with the three other guidelines published around the same time.
| Guideline | Publisher | Date | Scope | Character |
|---|---|---|---|---|
| AI Business Operator Guideline v1.2 | METI / MIC | 2026-03-31[^1] | All AI operators across industries | Cross-industry self-regulation (soft law) |
| AI Security Assurance Technical Measures Guideline | MIC | 2026-03-27[^3] | AI developers and providers broadly | Implementation manual for technical measures |
| AI Discussion Paper v1.1 | FSA | 2026-03-03[^4] | Financial institutions | Initial issue mapping by industry |
| Healthcare AI Safety Evaluation Guide v1.0 | AISI / IPA | 2026-04-02[^5] | Medical and healthcare AI | Industry-specific evaluation framework |
MIC's AI Security Assurance Guideline brings together technical countermeasures against AI-specific attacks — prompt injection, model poisoning, data poisoning, and so on[^3]. Treat it as the implementation-level companion to the "security assurance" sections of v1.2. The annex of implementation examples in particular has direct value for any company running an internal RAG or business-facing chatbot[^3].
The FSA's AI Discussion Paper v1.1 reflects discussions held through December 2025 at the "Public-Private AI Forum"[^4]. It explicitly calls 2025 "the dawn of the AI agent era" and begins to lay out how autonomous decision systems should be treated in financial transactions. Even if you are not a financial institution, anything you do that touches insurance, credit, or payments is worth reviewing now. Reading it as "the financial-sector implementation notes for v1.2" makes its subtext easier to follow.
The AISI/IPA Healthcare AI Safety Evaluation Guide v1.0 is the healthcare instance of AISI's broader "Trustworthy AI" evaluation program[^5]. It presents an evaluation framework that crosses ten evaluation perspectives (controlling harmful output, preventing misinformation, privacy protection, security assurance, handling high-risk use, fairness and inclusion, explainability, robustness, data quality, verifiability) with five lifecycle stages (product design, model selection, implementation, verification, deployment and operation). Reading it alongside AISI's annual report[^2] makes the rationale for those particular ten perspectives much clearer.
The practical takeaway is straightforward. If your company touches finance, medicine, or healthcare, read v1.2 together with the matching industry guideline as a two-layer set. For other industries, treat v1.2 + the MIC AI Security Assurance Guideline as the minimum two-layer baseline. That is the standard answer for May 2026.
Comparison with Overseas Regulation (EU AI Act, NIST AI RMF) and Harmonization
The era when satisfying domestic guidelines alone was enough is over. Even companies with no overseas operations are asked about alignment with overseas standards during vendor reviews by international counterparties, due diligence by global investors, and procurement assessments for foreign SaaS. Two key documents are worth tracking.
| Regulation / Standard | Character | Key milestones |
|---|---|---|
| EU AI Act | Statute with penalties; extraterritorial application to non-EU operators | Application delayed under Omnibus VII. High-risk systems now apply from December 2, 2027; embedded products from August 2, 2028[^7] |
| NIST AI RMF | Voluntary framework from NIST in the US | Critical Infrastructure Profile concept released on April 7, 2026[^6] |
The EU AI Act was substantially restructured under the so-called "Omnibus VII (simplification package)" with the provisional agreement between the Council and the European Parliament on May 7, 2026[^7]. Full applicability of stand-alone high-risk AI systems was pushed back to December 2, 2027, and embedded products to August 2, 2028. At the same time, transparency obligations for AI-generated content (such as labeling of synthetic media) were brought forward to December 2, 2026[^7]. Reading this as "obligations are delayed, so we can take our time" is dangerous. Transparency obligations are accelerated, not delayed; departments using generative AI in marketing and communications need to start preparing immediately.
NIST AI RMF is the voluntary risk-management framework published by NIST in the US. It is built around four functions — GOVERN, MAP, MEASURE, MANAGE — with the Generative AI Profile (NIST AI 600-1) added in July 2024, followed by the Critical Infrastructure Profile concept released on April 7, 2026[^6]. Operators of critical infrastructure — energy, telecommunications, finance, water, healthcare — will end up reading this alongside v1.2.
Trying to comply with all three separately will overwhelm your operations team. What I recommend to clients is to build a single set of governance documents around the common management items, and then map those documents onto each regulation or standard. v1.2, the EU AI Act, and NIST AI RMF all share the same skeleton: risk assessment, governance, data management, lifecycle management, and accountability. Lock in the common skeleton first, and manage only the regulation-specific deltas in side tables. This is by far the cheapest configuration to operate.
In Enterprise AI Governance: SOC 2, ISO 27001 and ISO 42001 Audit Controls in Practice, I go deeper into how these connect to international standards. If your team handles overseas transactions, that piece is a useful complement to this one.
Five Steps Companies Should Take Now (Governance / Risk Assessment / Technology / Education / Audit)
From here on, this is the "start moving next week" portion of the article. I have organized the minimum response to v1.2 into five steps. The order matters, so please work through them top to bottom if you can.
Step 1: Stand Up Governance
The first bottleneck is almost always organizational, not technical. AI governance cuts across five axes — executives, IT, legal, HR, and the business — so until someone is named owner, it will spin indefinitely.
What I recommend to clients is to start a three-person "AI Governance Committee": the CIO (or head of IT), the CRO (or compliance lead), and a representative of the business unit where AI adoption is furthest along. A light-touch cadence of quarterly briefings to the executive committee is enough for now. The committee's first three deliverables can be limited to: the role inventory, a draft of the AI Usage Policy, and an agreed split of responsibilities.
According to JIPDEC's 2026 Corporate IT Utilization Survey, roughly 70% of Japanese companies already have an AI governance structure in place[^10]. The 30% with no structure is a concern in itself, but the survey also flags that within the 70% that do, "ensuring final human judgment," "explainability," and "executive-level policy maturity" remain weak[^10]. The way to keep the committee from becoming a paper tiger is to put the role inventory and the external-action inventory from v1.2 on its very first agenda.
Step 2: Run a Risk Assessment
Once the committee exists, the next task is to inventory the risks specific to your AI. Some AI risks overlap with conventional system risks; others are entirely new.
At a minimum, six categories deserve attention.
- Hallucination (factually wrong output that misleads business decisions)
- Sensitive data leakage (prompts that include personal information or trade secrets)
- Data poisoning (tampering with training or RAG reference data)
- Prompt injection (malicious inputs that escalate privileges)
- Unauthorized external actions (mis-sent emails, mistaken payments, premature disclosures)
- Bias and discriminatory output (impacts on hiring, credit, evaluations)
Score each on impact (five levels) and likelihood (five levels), and you have a usable risk matrix. The realistic move is to focus controls on the top three to five items. The MIC AI Security Assurance Guideline annex (implementation examples)[^3] patterns concrete countermeasures against each risk, so it works well as a ready-made checklist.
Step 3: Implement Technical Controls
For the top risks identified above, install technical controls. You will need both AI-specific measures and extensions to your existing IT security controls.
The key surface areas are: input validation (prompt injection defense), output validation (factuality checks, sensitive-data filtering), access control (models, data, API keys), logging (prompts, outputs, external actions, approvals), fallback design (alternative behavior when inference fails), and change management (model updates, prompt changes). Six items.
Let me say a few words about ZEROCK here. The enterprise AI platform we develop and operate, ZEROCK, is configured with domestic AWS hosting, GraphRAG-based grounding, knowledge control, and audit logs as standard. The technical foundations v1.2 asks for — traceability (provenance of training and reference data), explainability (visibility of grounding via GraphRAG), data sovereignty (in-country servers), and Human-in-the-Loop (approval flows) — are in place from day one without you having to assemble them yourself. From a guideline-compliance angle, that is a substantial advantage. We are seeing more financial, medical, and public-sector customers — exactly the ones who say "we want to use AI but we cannot put our data on overseas SaaS" — choose ZEROCK for this reason.
Step 4: Operationalize Employee Education
Even when the technology and the operational rules are in place, things stall if employees cannot act on them. I recommend a two-layer education program: company-wide, plus role-based.
The company-wide layer can be a once-a-year 30-minute e-learning. The goals are narrow: communicate the existence of v1.2, the three-role concept, the risk of shadow AI, and where to go for questions. That is all. Deep technical knowledge is not required at this layer.
The role-based layer typically consists of three tracks: a track for AI practitioners (prompt design, HITL implementation, log review), a track for developers (secure development, data provenance, model evaluation), and a track for managers (governance responsibility, incident response). SHIFT's AI Usage and Management Survey[^12] also identifies insufficient education as the primary driver of shadow AI (off-the-books use).
Step 5: Build an Audit Loop and a Cycle of Continuous Improvement
The last step is audit. To keep governance from becoming theater, build in an annual internal audit of compliance with v1.2.
Sample audit items:
- Is the three-role inventory ledger being kept current?
- Is Human-in-the-Loop actually implemented for high-risk AI systems?
- Is the provenance of training and reference data traceable?
- Are incident logs being collected, with quarterly reviews?
- What is the completion rate of the education program, and the results of comprehension testing?
- Is alignment with overseas regulation (EU AI Act, NIST AI RMF) being checked?
Report audit results to the executive committee, and feed them into next year's improvement plan. Once this annual cycle starts turning, AI governance stops being window dressing and the operational quality of the field genuinely improves.
The five steps are listed in order, but in practice you can run them in parallel. What matters is to commit to all five and start moving. Finishing one step perfectly while leaving the other four at zero will not impress an auditor or a counterparty doing due diligence.
Free Download: ZEROCK Enterprise AI Whitepaper
How do you meet the technical requirements of AI Business Operator Guideline v1.2 with domestic servers, GraphRAG, and knowledge control? We have put together an A4 whitepaper that walks through ZEROCK's design philosophy and implementation architecture.
Download the whitepaper for free
How ZEROCK Lands a "Guideline-Compliant AI" Implementation
For readers who have followed this far, I expect a common reaction is: "The five steps make sense, but we do not have the bandwidth to run all of them ourselves." In fact, around 80% of the companies that come to us are in exactly that state — AI usage has already started, but governance has not caught up.
ZEROCK offers the option to "let the platform handle the v1.2 requirements rather than implementing them in-house." Specifically, what comes as standard is:
- Hosting on domestic AWS infrastructure (data sovereignty / removes cross-border concerns)
- GraphRAG-based grounding (explainability / verifiability)
- Knowledge control (data access management by department and role)
- Prompt library (sharing and version management of approved prompts)
- Audit logs (complete recording of prompts, outputs, reference data, and external actions)
- Human-in-the-Loop support (approval flows for important actions)
- Data provenance tracking (origin management for training data and RAG reference data)
Seven items. If you read v1.2 and its annexes side by side, you will notice that each of these maps one-to-one onto "the minimum technical requirements the guideline asks of operators." Functionality that takes six months to a year to build in-house ships pre-integrated. That is the central reason companies pick ZEROCK.
Many organizations are also stuck in a "departments are using ChatGPT on their own" situation — shadow AI. Consolidating that back onto an official channel is another place where ZEROCK provides a realistic answer. Ending fragmented overseas SaaS contracts and unifying on a domestic platform meaningfully reduces the burden of procurement, contracting, and audit.
For requests like "help us start with the three-role inventory" or "we want to roll out ZEROCK and the governance documentation in parallel," our specialist team will work with you end to end. We start with a discovery conversation about your current state.
FAQ and Wrap-Up
To close, three of the most common questions we receive.
Q1. Do mid-market and small businesses need to respond too?
A. Yes. The de facto requirement appears in transactions with large enterprises, in bank credit reviews, in overseas counterparty assessments, and in IPO preparation. Even getting just the three-role inventory, a shadow-AI map, and a draft AI Usage Policy in place ahead of time will dramatically reduce the cost of everything that follows.
Q2. Can existing ISMS (ISO 27001) certification substitute for this?
A. Partially, but it is not enough. ISO 27001 is fundamentally an information-security standard and does not directly cover AI-specific risks (hallucination, explainability, data provenance). The 2026 standard answer is to layer either ISO/IEC 42001 (AI management systems) or AI Business Operator Guideline v1.2 on top of an ISO 27001 foundation.
Q3. Now that EU AI Act application has slipped under Omnibus VII, can we just wait and see?
A. Waiting is not advisable. The full applicability of high-risk systems has been delayed, but transparency obligations for AI-generated content have actually been brought forward to December 2, 2026[^7]. On top of that, formal adoption of Omnibus VII is scheduled by August 2, 2026[^7], so further changes are possible. Rather than reacting once everything is fixed, the realistic stance is to keep a single common-skeleton governance document ready for a regulatory environment that will keep moving.
To wrap everything up in five lines:
- v1.2 has upgraded HITL and traceability from "recommended" to "required" in response to the arrival of the AI agent era.
- Read together with the MIC AI Security Assurance Guideline, the FSA Paper v1.1, and the AISI Healthcare Guide, the full picture becomes visible across these four documents.
- Overseas regulation (EU AI Act Omnibus VII, NIST AI RMF Critical Infrastructure Profile) is moving in parallel, and consolidating governance documentation around a common skeleton is the most cost-efficient approach.
- The work for companies is the five steps: stand up governance, run a risk assessment, implement technical controls, build the education program, and close the audit loop. Run all five, not just one.
- For the technical side of compliance, delegating to a domestic AI platform such as ZEROCK is a realistic option.
The guideline is updated annually. If you have a common-skeleton governance set ready in time for v1.3 (anticipated for March 2027), each annual revision becomes a minor update rather than a fire drill. From the field, what I have seen is that companies who build the foundation early quietly pull ahead. I hope this article serves as a useful map for next week's first moves.
Want to Build a Guideline-Compliant AI Environment?
If you would rather not implement the traceability, explainability, data sovereignty, and Human-in-the-Loop requirements of AI Business Operator Guideline v1.2 from scratch — and instead delegate them to a platform — ZEROCK is an enterprise AI offering with domestic AWS hosting, GraphRAG, knowledge control, and audit logs as standard.
See ZEROCK's capabilities in detail Book a free 30-minute consultation
References
[^1]: "AI Business Operator Guideline (Version 1.2)" — Ministry of Economy, Trade and Industry / Ministry of Internal Affairs and Communications — 2026-03-31 — https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html [^2]: "AI Safety Annual Report 2025" — AI Safety Institute (AISI) — 2026-04-28 — https://aisi.go.jp/output/output_information/260428/ [^3]: "Guidelines on Technical Measures for AI Security Assurance" — Ministry of Internal Affairs and Communications — 2026-03-27 — https://www.soumu.go.jp/main_content/001048178.pdf [^4]: "AI Discussion Paper (Version 1.1)" — Financial Services Agency — 2026-03-03 — https://www.fsa.go.jp/news/r7/sonota/20260303/aidp_version1.1.pdf [^5]: "Healthcare AI Safety Evaluation Guide (Version 1.0)" — AISI / IPA — 2026-04-02 — https://www.ipa.go.jp/pressrelease/2026/press20260403.html [^6]: "AI Risk Management Framework" — National Institute of Standards and Technology (NIST) — Critical Infrastructure Profile concept released April 7, 2026 — https://www.nist.gov/itl/ai-risk-management-framework [^7]: "Artificial Intelligence: Council and Parliament agree to simplify and streamline rules" — Council of the European Union — 2026-05-07 — https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/ [^8]: "Notice on the Use of Generative AI" — Personal Information Protection Commission — https://www.ppc.go.jp [^9]: "The 2026 AI Index Report" — Stanford HAI — 2026 (88% organizational adoption rate, 74% inaccuracy risk) — https://hai.stanford.edu/ai-index/2026-ai-index-report [^10]: "Corporate IT Utilization Survey 2026" — JIPDEC — 2026 (survey on AI governance maturity at Japanese companies) — https://www.jipdec.or.jp/library/it-resarch/it-resarch2026.html [^11]: "AI Business Operator Guideline (Version 1.2) Annex" — Ministry of Internal Affairs and Communications — 2026-03-31 — https://www.soumu.go.jp/main_content/001064286.pdf [^12]: "AI Usage and Management Survey" — SHIFT Inc. — 2026-04-22 — https://www.shiftinc.jp/news/20260422_ai-usage-management-survey/