The debate over how to secure trust in AI has advanced considerably over the past few years. Tailoring responses to the magnitude of risk, requiring transparency and risk management in products, and demanding agile governance structures of organizations—these frameworks common to “trustworthy AI” have been fairly well established through international standards and guidelines, and through legislations of the European Union and other countries.The problem, however, lies beyond that. Even where laws, standards, and governance frameworks establish clear obligations, they rarely provide, on their own, a complete and commonly recognized basis for implementation and assessment across every sector, use case, and position in the AI value chain. What is still needed is a set of practical, modular specifications that connects these obligations and foundational standards with implementation and assessment that help determine what is in scope, which party is responsible, how requirements will be evaluated, and what evidence will demonstrate that the applicable criteria have been met. Without such specifications, it is hard to build trust across the AI supply chain, where many different parties are closely connected. And to create it, we need the active involvement of the companies that understand each field from the inside.This is the problem that this series will explore. In five parts, we will ask how to build a supply chain for "trustworthy AI," and what role companies should play in making it real. Part 1 (this article) presents the overall picture. The later parts will look at the specific fields where the specifications for trust are now being created: physical AI such as autonomous driving, as well as healthcare, finance, and security.The Distance Between Rules and the FieldOne of the most frequently referenced standards for managing AI risk is ISO/IEC 42001（※1）. It requires organizations to assess the risks of AI systems throughout their lifecycle and to establish policies and management structures, as well as to implement technical controls to address identified risks. Similarly often referenced is the U.S. NIST AI Risk Management Framework（※2）, which offers a model for organizations to engage continually with AI risk through four functions: Govern, Map, Measure, and Manage. The best-known legal regulation is probably the EU’s AI Act, which classifies AI systems into categories such as “prohibited AI practices,” “high-risk AI systems,” and “general-purpose AI models,” and imposes obligations on each. However, none of these rules spells out concrete actions of the “just do this and you’re fine” variety—nor should they, as the expected actions, results, and evidence are dependent upon industry, application, and use case.For example, Article 9 of the EU AI Act requires providers of high-risk AI systems to identify and evaluate the risks the system may pose, to adopt "appropriate and targeted" risk-management measures, and to ensure that any remaining ("residual") risk is "judged to be acceptable." But the Act does not spell out what those "appropriate and targeted" measures actually are, where the line of acceptability concretely lies, or how much re-testing is required each time the system is updated（※3）.The development of AI rules is currently advancing in many parts of the world, but in every case the challenge at present is how to concretely implement them in the field.Why High-Level Rules Cannot Provide Every Implementation Detail?So why can’t rules, such as laws, policies, and high-level standards, describe concrete processes or target values? There are several reasons due to the characteristics of AI.First, AI does not always give the same answer. Because its outputs are generated from statistics and probability, the result is not fixed in advance. This is especially true of generative AI, where the same prompt (input) can produce a different answer each time. That makes it hard for rules to set a "concrete target value"—a single, expected output—beforehand.Second, AI systems and their operating environments are not static. Their behavior may change when models, training or reference data, prompts, configurations, interfaces, or surrounding software are updated. As a result, evidence that was sufficient for one version or deployment may not remain sufficient for another.Third, AI risk depends on context. The same model may be acceptable in one setting but not in another, depending on the field, the purpose, and the people affected. What must be evaluated, what level of performance is acceptable, and which evidence is relevant therefore depend on the intended purpose, the affected parties, the operating environment, and the consequences of failure.Take the single word "safety." For a self-driving car, safety means not hitting people or objects. For a conversational AI, it means not producing discriminatory or harmful statements, or false information. The meaning of "safety" can differ this much from case to case, so it is impossible to define it in advance for every AI and every situation. This makes a single universal checklist inadequate, but it does not prevent the development of shared building blocks, evaluation methods, and sector-specific criteria.After all, laws, policies, and high-level standards are not necessarily incomplete because they do not prescribe every implementation detail. Their goal should be to establish objectives, obligations, governance expectations, and sometimes required outcomes. This is, in fact, why the Japanese government, too, calls for making regulation "goal-based.（※4）" The methods, measures, evidence, and acceptance criteria needed to apply those requirements may then need to be developed for particular technologies, sectors, roles, and uses.The Need for a Practical and Common “Specifications”If rules are abstract, then what should each company do to demonstrate that it satisfies their requirements? Scattered, individual efforts alone result in as many different judgments as there are people. For objective evaluation, common, practical specifications are needed. For example, it becomes important for the relevant parties to agree on points such as "what is in scope," "who bears responsibility and to what extent," "what is measured and how," and "what is presented as evidence." For assessment to be consistent, relevant parties need shared ways to identify what is being examined, which actors are responsible for which elements, which requirements apply, how those requirements are evaluated, and what evidence is produced. The applicable law, contract, or sectoral framework, may determine the threshold that must be met. The common specification provides the shared basis for understanding how the result was reached.This matters most along a supply chain. If an evaluation result carries the same meaning across companies, sectors, and borders, a downstream business no longer has to prove from scratch what an upstream business has already shown. This is what we might call "interoperable assurance": just as data can move between systems that share a format, a demonstration of trustworthiness can move along the supply chain—reused rather than rebuilt at each step. That evidence can be reused for the object, version, role, and criteria to which it applies, while each downstream actor remains responsible for its own integration, configuration, deployment, and context-specific obligations. This is the practical aim of interoperable assurance: not one universal certificate, but evidence and assessment results that can be understood, combined, and relied upon across organizational boundaries.Common specifications are what make it possible.And the movement to jointly create such common specifications internationally has already begun. For example, in an international initiative called the Appia Foundation, launched in June 2026 under the Linux Foundation’s JDF, businesses responsible for testing and certification, companies that implement AI in fields such as industry, energy, telecommunications, and payments, and companies that develop and supply models and platforms have joined together to formulate publicly available, modular specifications that build on existing international and sectoral standards（※5）.Why Participating in the Standard-Setting Process MattersSo why is it important for companies to participate proactively in setting those specifications?Participation matters because practical specifications are strongest when they reflect the experience of those who design, supply, integrate, assess, procure, and use AI systems. Companies can contribute knowledge of real technologies, sectoral constraints, existing standards, supply-chain relationships, and implementation costs. Broad participation also helps prevent one sector, geography, or business model from being treated as universal. For participating companies, early engagement provides an opportunity to improve technical feasibility, interoperability, and alignment with existing processes.Participation also helps companies anticipate emerging expectations and reduce the risk of costly late-stage changes to products, evaluation processes, and supplier requirements.For example, consider the safety specifications for autonomous vehicles. In the end-to-end AI that has spread rapidly in recent years—which learns the entire path from sensor input to steering as a single unit—behavior is determined not by rules written by humans, but by millions of parameters the machine has derived from vast amounts of driving data. Because of this, the conventional approach of measuring the safety of each separate component can no longer adequately evaluate how the system performs.Part 2 will examine how horizontal AI requirements, automotive standards, and reusable evaluation methods can be combined without replacing sector-specific safety expertise.ConclusionTrust in AI will not come from rules alone. Rules can point the direction, but they cannot tell each company what to actually do in its own field. That gap can only be closed by common, practical specifications—shared agreements on what to check, who is responsible, how to measure it, and what counts as proof. This is what makes "interoperable assurance" possible: a way of demonstrating trustworthiness that can be translated and reused across the supply chain, rather than rebuilt from scratch at every step.These specifications are not something to wait for others to hand down. They are being written now, and the companies that take part are the ones that shape the field—building in the realities of their own technology rather than following terms set by others after the fact.This is the work ahead. In the articles that follow, we turn to the fields where these specifications are now taking shape—physical AI such as autonomous driving, and then healthcare, finance, and security—to see concretely what is being debated, and how a common specification can be made to work.【This series was prepared by Smart Governance Ltd. based on the results of joint research conducted with Microsoft Corporation.】（※1） ISO/IEC. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. 2023.（※2）National Institute of Standards and Technology (NIST). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. 2023. https://doi.org/10.6028/NIST.AI.100-1. （※3）To give such laws concrete shape, the AI Act provides that the details of the required processes and specifications be set out in “European harmonized standards.” However, these harmonized specifications has not yet established.（※4）Ministry of Economy, Trade and Industry (METI) / Ministry of Internal Affairs and Communications (MIC), "AI Guidelines for Business" Ver. 1.2 (2026), https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_1.pdf, Ministry of Economy, Trade and Industry (METI) “GOVERNANCE INNOVATION Vol.3: Agile Governance Overview and Current State” (2022)（※5）Linux Foundation Launches Appia Foundation to Establish Standardiized Conformity Specifications Across the AI Value Chain (2026), https://www.linuxfoundation.org/press/linux-foundation-launches-appia-foundation-to-establish-specificationized-conformity-specifications-across-the-ai-value-chain 【Related】▶ Japanese version of this article －抽象的なAIルールから、実装・評価の共通仕様へ【連載「信頼できるAI」第1回】▶ Designing an AI System Certification Scheme: An Attempt at Joint Certification via Integrating Risk Control Measures and Organizational Management (White Paper, PDF)▶ AIへの信頼性を付与する認証制度の最新動向～「Joint Certification」とは～本稿は公開情報や執筆者の専門的知見に基づいた一般的な分析・見解を提供するものです。本稿に記載の見解は執筆担当者の個人的見解であり、当社または当社のクライアントの見解ではありません。