英国 意見募集：AIのサイバーセキュリティ (2024.08.02)

こんにちは、丸山満彦です。

AIに対するサイバーセキュリティ対策について、英国政府はガイダンスを設けるということですよね...

同時に発表されている「ソフトウェアベンダーのための実践規範」と連動しているようです...

● GOV.UK

・2024.08.02 Cyber security of AI: a call for views

・2024.08.02 A call for views on the cyber security of AI

目次...

Executive summary	エグゼクティブサマリー
1: Introduction	1: 序文
2: Our technology security programme	2: 当社のテクノロジー・セキュリティ・プログラム
3: Voluntary Code of Practice and Global Standard	3: 自主行動規範とグローバル標準
AI Cyber Security Code of Practice	AIサイバーセキュリティ実践規範
4: How to respond to the Call for Views and our next steps	4：意見募集への対応方法と次のステップ
Annex A: Research findings	附属書A：調査結果
Annex B: Global approach to AI	附属書B：AIに対するグローバルなアプローチ
Annex C: Glossary of terms	附属書C：用語集
Annex D: Call for views survey questionnaire	附属書D：意見募集アンケート
Annex E: Other interventions considered	附属書E：検討されたその他の介入策
Annex F: Bibliography of relevant publications mapped to principles by Mindgard	附属書F：マインドガードによる原則にマッピングされた関連出版物の書誌

エグゼクティブサマリー...

Executive summary	エグゼクティブサマリー
AI is transforming our daily lives. As the technology continues to evolve and be embedded, it is crucial that we ensure cyber security is a key underpinning of AI safety. This Call for Views sets out specific interventions to help secure AI, so that the many benefits of AI can be realised.	AIは我々の日常生活を一変させつつある。技術が進化し、組み込まれ続ける中、サイバーセキュリティがAIの安全性を支える重要な基盤であることを確実にすることが極めて重要である。この意見募集では、AIの安全確保を支援するための具体的な介入策を提示し、AIがもたらす多くのメリットを実現できるようにする。
This work has primarily focused specifically on the cyber security risks to AI, rather than wider issues such as safety or the cyber security risks that stem from AI. This work is relevant to all AI technologies, regardless of the sector in which AI is used or the form of AI technology, because security is an essential component and should be considered across the entire AI lifecycle. This work sits alongside wider government activity on AI, much of which is noted in the AI regulation white paper response (see Chapter 2).	この作業は、安全性やAIに起因するサイバーセキュリティ・リスクといったより広範な問題ではなく、主にAIに特有のサイバーセキュリティ・リスクに焦点を当てている。なぜなら、セキュリティは不可欠な要素であり、AIのライフサイクル全体にわたって考慮されるべきものだからである。この作業は、AIに関する政府の広範な活動と並行して進められるものであり、その多くはAI規制白書（セクション2 参照）への回答で述べられている。
The government is proposing to take forward a two-part intervention in the form of a voluntary Code of Practice that will be taken into a global standards development organisation for further development. The proposed voluntary Code sets baseline security requirements for all AI technologies and distinguishes actions that need to be taken by different stakeholders across the AI supply chain.	政府は、自主的な行動規範という形で、2つの部分からなる介入を進めることを提案している。提案されている自主規範は、すべてのAI技術に対する基本的なセキュリティ要件を設定し、AIのサプライチェーン全体にわたって、さまざまな利害関係者が取るべき行動を区別している。
The voluntary Code of Practice was developed by the Department for Science, Innovation & Technology (DSIT) and is based on the National Cyber Security Centre’s (NCSC) Guidelines for secure AI system development which were published in November 2023, alongside the US Cybersecurity and Infrastructure Security Agency and other international cyber partners. The guidelines were co-sealed by agencies from 18 countries. The voluntary Code has also been informed by research we commissioned, including a risk assessment and a mapping of cyber security research in this area. Stakeholder engagement is a key component of our approach and will continue to be embedded throughout this Call for Views process and beyond.	この自主規範は、科学技術革新省（DSIT）によって策定され、国家サイバーセキュリティセンター（NCSC）が2023年11月に米国サイバーセキュリティ・インフラセキュリティ庁やその他の国際的なサイバーパートナーとともに発表した、安全なAIシステム開発のためのガイドラインに基づいている。このガイドラインは、18カ国の機関によって共同承認された。自主行動規範は、リスクアセスメントやこの分野のサイバーセキュリティ研究のマッピングなど、私たちが委託した調査にも基づいている。ステークホルダーの参画は、我々のアプローチの重要な要素であり、今回の「意見募集」のプロセスを通じて、またそれ以降も継続していく予定である。
We want to enable AI developers to be able to distinguish themselves from their competitors by highlighting their commitment to security. We also recognise the importance of developing international alignment and ensuring that stakeholders that make up the AI supply chain have a clear understanding of what they need to implement. To that end, we’ve been engaging closely with international partners and mapped recommendations by industry and other governments to ensure this document sits in support of their efforts. We are also involved in various standards development organisations and multilateral fora to promote the need for security as part of discussions on AI (see Annex B).	我々は、AI開発者がセキュリティへの取り組みを強調することで、競合他社と差別化できるようにしたいと考えている。また、国際的な協調を発展させ、AIのサプライチェーンを構成する関係者が、何を実施する必要があるのかを明確に理解できるようにすることの重要性も認識している。そのため、我々は国際的なパートナーと緊密に連携し、産業界や他の政府による勧告をマッピングし、この文書が彼らの取り組みを支援するものとなるようにしてきた。また、様々な標準開発組織や多国間フォーラムに参加し、AIに関する議論の一環としてセキュリティの必要性を推進している（附属書B参照）。
This publication is intended as the starting point of a much more extensive dialogue with our stakeholders, including industry and international partners. The cyber security of AI requires a global approach, as the risks cross international borders, and so international engagement has been a key element of our approach. We are now holding a Call for Views for 12 weeks until 9 August 2024 to gather feedback on the proposed interventions, including the Code of Practice and the intention to develop a global standard. The feedback will be used to inform UK government policy and our next steps.	本書は、産業界や国際的なパートナーを含むステークホルダーとの、より広範な対話の出発点となることを意図している。AIのサイバーセキュリティは、リスクが国境を越えるため、グローバルなアプローチが必要であり、国際的な関与が我々のアプローチの重要な要素となっている。現在、2024年8月9日までの12週間、意見募集を行い、行動規範や世界標準を策定する意向など、提案されている介入策について意見を集めている。このフィードバックは、英国政府の方針と私たちの次のステップに役立てられる。

実践規範...

Code of Practice Principles	実践規範の原則
Secure Design	安全な設計
Principle 1: Raise staff awareness of threats and risks	原則1：脅威とリスクに対する職員の意識を高める
Principle 2: Design your system for security as well as functionality and performance	原則2：機能や性能だけでなく、セキュリティも考慮してシステムを設計する
Principle 3: Model the threats to your system	原則3：システムに対する脅威をモデル化する。
Principle 4: Ensure decisions on user interactions are informed by AI-specific risks	原則4：AI特有のリスクに基づいて、ユーザとのインタラクションに関する意思決定が行われるようにする。
Principle 5: Identify, track and protect your assets	原則5：資産を識別、追跡、保護する。
Principle 6: Secure your infrastructure	原則6：インフラストラクチャーの安全性を確保する。
Principle 7: Secure your supply chain	原則7：サプライチェーンの安全性を確保する。
Principle 8: Document your data, models and prompts[	原則8：データ、モデル、プロンプトを文書化する。
Principle 9: Conduct appropriate testing and evaluation	原則9：適切なテストと評価を実施する。
Secure Deployment	安全な配備
Principle 10: Communication and processes associated with end-users	原則10：エンドユーザ[脚注 37]とのコミュニケーションとプロセス
Secure Maintenance	安全な保守
Principle 11: Maintain regular security updates for AI model and systems	原則11：AIモデルとシステムのセキュリティ更新を定期的に行う。
Principle 12: Monitor your system’s behaviour	原則12：システムの挙動を監視する

・2024.05.15 Cyber security of AI: call for views

・2024.08.02 Call for views on the Cyber Security of AI

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2024.06.27 英国 国家サイバーセキュリティセンター 人工知能 (AI) のサイバーセキュリティに関する研究 (2024.05.15)

AI Cyber Security Code of Practice	AIサイバーセキュリティ規範
Background	背景
This proposed voluntary Code of Practice was developed by DSIT and is based on NCSC’s Guidelines for secure AI system development which were published in November 2023, alongside the US Cybersecurity and Infrastructure Security Agency and other international cyber partners. The Code has also been informed by an assessment of the cyber security risks to AI as well as a literature review that mapped accessible technical recommendations made by industry and other governments. The findings of the literature review have been used to map relevant publications to the Code’s principles to offer an indication of where there are crossovers.[footnote 21]	この自主的な実践規範案はDSITによって作成され、米国のサイバーセキュリティ・インフラセキュリティ庁やその他の国際的なサイバーパートナーとともに2023年11月に発表されたNCSCの安全なAIシステム開発のためのガイドラインに基づいている。また、この規範は、AIに対するサイバーセキュリティリスクのアセスメントや、産業界や他の政府による技術的勧告にアクセス可能な文献レビューに基づいている。文献レビューの結果は、関連する出版物を行動規範の原則にマッピングするために使用され、どこでクロスオーバーが生じるかを示すものである。
The Code sets out practical steps for stakeholders across the AI supply chain, particularly Developers and System Operators, to protect end-users. The Code applies to all AI technologies and will help ensure that security is effectively built into AI models and systems as well as across the AI lifecycle. We have applied this broad scope because a lot of the complexity in an AI system resides out of the model, and there is a significant dependency on data. It is important for stakeholders to note that this voluntary Code sits in support of the UK Government’s wider efforts for AI and regulations, such as UK data protection law. Stakeholders across the AI supply chain must ensure that they comply with their regulatory obligations. Considering the direct interlinkage between data and security within the context of an AI model and system; both areas are addressed through the Code’s requirements.	本規範は、AIのサプライチェーン全体の関係者、特に開発者とシステム運営者がエンドユーザーを保護するための実践的な手順を定めている。本規範は、すべてのAI技術に適用され、AIモデルやシステムにセキュリティが効果的に組み込まれるとともに、AIのライフサイクル全体にわたってセキュリティが確保される助けとなる。AIシステムの複雑性の多くはモデル外に存在し、データに大きく依存するため、このように広い範囲を適用した。輸入事業者にとって重要なのは、この自主規範が、AIに対する英国政府の広範な取り組みと、英国データ保護法などの規制をサポートするものであることだ。AIのサプライチェーン全体の関係者は、規制上の義務を確実に遵守しなければならない。AIモデルとシステムの文脈におけるデータとセキュリティの直接的な相互関係を考慮すると、この2つの領域はコードの要求事項を通じて対処されている。
Our expectation is that organisations in scope would, at a minimum, also adhere to the provisions in both the Software and Cyber Governance Codes of Practice. While the Cyber Governance Code of Practice sets the baseline expectations for all organisations using digital technologies as part of their business function, the Software Code will also be relevant since software is an integral part of how AI models and systems function. Organisations deemed in scope of this Code would also be expected to assess whether their circumstances warrant consideration of adherence to additional Codes covering more specific products or services depending on their business function.	私たちが期待するのは、適用範囲に含まれる組織は、最低限、ソフトウェアとサイバーガバナンスの両実務コードの規定も遵守することである。サイバーガバナンス実践規範は、ビジネス機能の一部としてデジタル技術を使用するすべての組織に対する基本的な期待事項を定めているが、ソフトウェアはAIモデルやシステムが機能する上で不可欠な部分であるため、ソフトウェア規範も関連する。また、この規範の適用範囲とみなされた組織は、そのビジネス機能に応じて、より特定の製品やサービスをカバーする追加の規範の遵守を検討することが、その状況に応じて正当化されるかどうかをアセスメントすることが期待される。
Millions of businesses and consumers are using AI models and systems, and it is important that they, and the global economy, can benefit from the opportunities provided by AI. It is therefore essential that as new updates are rolled out and new products come to market, security is a core consideration throughout the AI lifecycle. The Code is intended to help inform the policy and practices that organisations currently have in place.	何百万もの企業や消費者がAIモデルやシステムを使用しており、彼らや世界経済がAIによってもたらされる機会から利益を得られるようにすることが重要である。したがって、新たなアップデートが展開され、新製品が市場に投入される際には、AIのライフサイクル全体を通じてセキュリティを中核に据えることが不可欠である。本規範は、組織が現在実施しているポリシーやプラクティスに情報を提供する一助となることを意図している。
Furthermore, we recognise that several industry and standards bodies, as well as other countries, have compiled recommendations to address the cyber security risks to AI. This voluntary Code of Practice is designed to be complementary to, and supportive of, those efforts. This is particularly important when working groups have been set up in various standards development organisations, including the Secure AI Technical Committee in the European Telecommunications Standards Institute (ETSI).	さらに、いくつかの業界団体や標準団体、そして他の国々が、AIのサイバーセキュリティ・リスクに対処するための提言をまとめていることも認識している。この自主的な行動規範は、これらの取り組みを補完し、支援することを目的としている。欧州電気通信標準化機構（ETSI）のセキュアAI技術委員会をはじめ、さまざまな標準開発機構にワーキンググループが設置されている中で、このことは特に重要である。
As set out in the Call for Views document, we are encouraging feedback from global stakeholders. This is because the Government’s intention, depending on the feedback received during the Call for Views, is to submit the updated voluntary Code to ETSI in September 2024 to help inform the development of a global standard. This Code will be reviewed, and if necessary updated, where there are changes in the technology itself, the risk landscape and the regulatory regimes.[footnote 22] We are therefore proposing monitoring and evaluation activities to assess uptake of the Code’s principles among key stakeholders (see Call for Views document – points 3.6 and 3.7).	意見募集の文書にあるように、我々は世界の利害関係者からのフィードバックを奨励している。というのも、政府としては、意見募集中に寄せられたフィードバックに応じて、2024年9月にETSIに最新の自主規範を提出し、世界標準の策定に役立てたいと考えているからである。この規範は、技術自体、リスク環境、規制制度に変化があった場合に見直され、必要であれば更新される[脚注 22]。そのため、主要な利害関係者の間で規範の原則が浸透しているかを評価するためのモニタリングと評価活動を提案している（意見募集文書-ポイント3.6と3.7を参照）。
Audience	想定読者
An indication is given for each principle within this voluntary Code as to which stakeholder is primarily responsible for implementation. The stakeholders are defined as:	この自主行動規範の各原則には、どのステークホルダーが実施に主な責任を負うかを示している。ステークホルダーは以下のように定義されている：
Stakeholder / Definitions	ステークホルダー／定義
Developers	開発者
This encompasses any type of business or organisation across any sector as well as individuals that are responsible for creating an AI model and/or system. This applies to all AI technologies and both proprietary and open-source models. For context, a business or organisation that creates an AI model and who is also responsible for embedding/deploying that model/system in their organisation would be defined in this voluntary Code to be both a Developer and a System Operator.	これは、AIモデルおよび／またはシステムの作成を担当する個人だけでなく、あらゆる業種の企業や組織を包含する。これは、すべてのAIテクノロジー、プロプライエタリ・モデルとオープンソース・モデルの両方に適用される。文脈上、AIモデルを作成し、そのモデル／システムを組織内に組み込み／展開する責任を負う企業や組織は、この自主規範では開発者であると同時にシステム運用者であると定義される。
System Operators	システムオペレータ
This includes any type of business or organisation across any sector that has responsibility for embedding / deploying an AI model and system within their infrastructure. This applies to all AI technologies and both proprietary and open-source models. This term also includes those businesses that provide a contractual service to organisations to embed / deploy an AI model and system for business purposes.	これには、あらゆるセクターのあらゆる種類の企業や組織が含まれ、そのインフラ内にAIモデルやシステムを組み込み／展開する責任を負う。これは、すべてのAIテクノロジー、プロプライエタリ・モデルとオープンソース・モデルの両方に適用される。また、この用語には、ビジネス目的のためにAIモデルおよびシステムを組み込み／展開するための契約上のサービスを組織に提供する事業者も含まれる。
Data controllers	データ管理者
This includes any type of business, organisation or individual that control data permissions and the integrity of data that is used for any AI model or system to function. In the context of an AI system, there could be multiple data controllers involved because some data used to create a model could come from the organisation that is deploying/embedding the system in their infrastructure and other data could be from public databases and other sources.	これには、AIモデルやシステムが機能するために使用されるデータの許可や完全性を制御するあらゆる種類の企業、組織、個人が含まれる。AIシステムの文脈では、モデルを作成するために使用されるデータの一部は、そのインフラにシステムを導入／組み込んでいる組織から提供される可能性があり、その他のデータは公開データベースやその他のソースから提供される可能性があるため、複数のデータ管理者が関与する可能性がある。
End-users	エンドユーザー
This encompasses any employee within an organisation or business and UK consumers who use an AI model and system for any purpose, including to support their work and day-to-day activities. This applies to all AI technologies and both proprietary and open-source models. End-users are not expected or required to implement this Code. This stakeholder group has been created because the voluntary Code has placed expectations on Developers, System Operators and Data controllers to help inform and protect end-users.	これは、仕事や日々の活動をサポートするためなど、あらゆる目的でAIモデルやシステムを使用する組織や企業内の従業員、および英国の消費者を包含する。これは、すべてのAI技術、プロプライエタリ・モデルとオープンソース・モデルの両方に適用される。エンドユーザーは、本規定を実施することを期待されたり義務付けられたりするものではない。このステークホルダー・グループは、自主的な行動規範が開発者、システム運営者、データ管理者に、エンドユーザーへの情報提供と保護に役立つことを期待するものであることから設立された。
The table below gives examples of common cases involving different types of organisations that are relevant to this voluntary Code of Practice as well as the Software Resilience voluntary Code of Practice.	以下の表は、この自主行動規範および自主行動規範「ソフトウエア・レジリエンス」に関連する、さまざまなタイプの組織が関与する一般的なケースの例である。
Stakeholder Groups / Guidance	ステークホルダー・グループ／ガイダンス
Software vendors who also offer AI services to customers/end-users	顧客／エンドユーザにも AI サービスを提供しているソフトウェアベンダー
These organisations are a Developer and therefore are in scope of this Code and the Software Resilience Code of Practice.	これらの組織は開発者であり、この規範とソフトウェアレジリエンス自主行動規範の適用範囲である。
Software vendors who use AI in their own infrastructure which has been created by an external provider	外部のプロバイダが作成した独自のインフラでAIを使用するソフトウェア・ベンダー
These organisations are a System Operator and therefore are in scope of relevant parts of the Code and the Software Resilience Code of Practice.	このような組織はシステムオペレータであり、この規範の関連部分と「ソフトウェア・レジリエンス規範」の適用範囲内である。
Software vendors who create AI in-house and implement it within their infrastructure	社内でAIを作成し、自社のインフラに実装しているソフトウェアベンダー
These organisations are a Developer and System Operator and therefore are in scope of this Code and the Software Resilience Code of Practice.	これらの組織はデベロッパーであり、システムオペレーターであるため、このコードとソフトウェアレジリエンス実践規範の適用範囲内である。
Software vendors who only use third-party AI (components) for their in-house use	サードパーティ製のAI（コンポーネント）のみを自社で使用するソフトウェアベンダー。
These organisations are a System Operator and therefore are in scope of relevant parts of the Code and the Software Resilience Code of Practice.	これらの組織はシステムオペレータであるため、この規範の関連部分とソフトウェア・レジリエンス規範の適用範囲内である。
Organisation that creates an AI system for in-house use	社内で使用するためにAIシステムを作成する組織
These organisations are a Developer and therefore are in scope of this Code.	これらの組織は開発者であり、このコードの適用範囲に含まれる。
Organisation that only uses third-party AI components	サードパーティ製の AI コンポーネントのみを使用する組織
These organisations are a System Operator and therefore are in scope of relevant parts of the Code.	これらの組織はシステムオペレータであり、本規程の適用範囲内である。
AI Vendors	AI ベンダー
Organisations that offer or sell models and components, but do not play a role in developing or deploying them, are not in scope of this Code. These organisations are in scope of the Software Code of Practice and Cyber Governance Code.	モデルやコンポーネントを提供または販売するが、その開発や配備には関与しない組織は、本規程の適用範囲外である。これらの組織は、ソフトウェア規範とサイバーガバナンス・コードの適用範囲内である。
What does the terminology mean in the voluntary Code of Practice?	自主行動規範における用語の意味は？
We have used “shall” and “should” terminology for each provision in the voluntary Code to align with the wording used by standards development organisations.[footnote 23] The table below sets out the definitions of these words in the context of the voluntary nature of this Code of Practice.	自主行動規範の各条項には、標準開発組織で使用されている表現に合わせるため、「shall」と「should」の用語を使用している[脚注 23]。 以下の表は、この実施規範の自主的な性質に照らして、これらの用語の定義を示したものである。
Term / Definition	用語／定義
Shall; Indicates a requirement for the voluntary Code	しなければならない； 任意規範の要求事項を示す。
Should; Indicates a recommendation for the voluntary Code	べきである：自主的な行動規範に対する勧告を示す。
Can/could; Indicates where something is possible, for example, that an organisation or individual is able to do something	できる； 組織や個人が何かをできるなど、何かが可能であることを示す。
Code of Practice Principles	行動規範の原則
Secure Design	安全な設計
Principle 1: Raise staff awareness of threats and risks	原則 1： 脅威とリスクに対するスタッフの意識を高める
Primarily applies to: System Operators, Developers, and Data Controllers	主に以下に適用される： システム運用者、開発者、データ管理者
[NIST 2022, NIST 2023, ASD 2023, WEF 2024, OWASP 2024, MITRE 2024, Google 2023, ESLA 2023, Cisco 2022, Deloitte 2023, Microsoft 2022]	[NIST 2022, NIST 2023, ASD 2023, WEF 2024, OWASP 2024, MITRE 2024, Google 2023, ESLA 2023, Cisco 2022, Deloitte 2023, Microsoft 2022].
1.1.   Organisations shall establish and maintain a continuous security awareness program to educate their staff about the evolving threat landscape specific to AI systems.	1.1.   組織は、AI システム特有の進化する脅威の状況について従業員を教育するために、継続的なセキュリティ意識向上プログラムを確立し、維持する。
1.1.1. The AI-Security security awareness content shall be reviewed and updated where necessary at least every six months.	1.1.1. AI-Security」のセキュリティ啓発の内容は、少なくとも6か月ごとに見直し、必要に応じて更新する。
1.1.2. AI-specific security awareness training could be incorporated into existing infosec training for staff.	1.1.2. AIに特化したセキュリティ意識向上およびトレーニングは、職員向けの既存の情報セキュリティトレーニングに組み込むことができる。
1.2.   Developer organisations should provide their staff with regular updates on the latest security threats and vulnerabilities that could impact AI systems	1.2.   開発者組織は、AI システムに影響を及ぼす可能性のある最新のセキュリティ上の脅威や脆弱性に関する最新情報を定期的にスタッフに提供する。
1.2.1. These updates should be communicated through multiple channels, such as security bulletins, newsletters, or internal knowledge-sharing platforms, to ensure broad dissemination and understanding among the staff.	1.2.1. これらの最新情報は、セキュリティ情報誌、ニュースレター、社内の知識共有 プラットフォームなど、複数のチャネルを通じてコミュニケーションすることで、 スタッフの間に広く浸透し、理解されるようにする。
1.3. Developers shall receive training in secure coding techniques specific to AI development, with a focus on preventing and mitigating security vulnerabilities in AI algorithms, models, and associated software.	1.3. 開発者は、AI アルゴリズム、モデル及び関連ソフトウエアにおけるセ キュリティ脆弱性の防止と低減に焦点を当てた、AI 開発に特化したセキュアな コーディング技術に関するトレーニングを受ける。
1.3.1 Developer training should also include content on how developers may leverage AI/LLMs to improve code security	1.3.1 開発者トレーニングには、開発者が AI/LLM を活用してコードセキュリティを改善する方法に関する内容も含める。
1.4 Developers shall receive awareness training in the characteristics of machine learning and AI systems in general that make them especially complex (and hence particularly vulnerable to technical debt and security issues) – these often include convoluted data dependencies, multi-layered software architectures, and intricate configurations.	1.4 開発者は、複雑なデータ依存関係、多層的なソフトウェアアーキテクチャ、複雑な構成など、機械学習やAIシステム全般を特に複雑にしている（したがって、技術的負債やセキュリティ上の問題に対して特に脆弱である）特性に関する意識向上およびトレーニングを受ける。
Principle 2: Design your system for security as well as functionality and performance[footnote 24]	原則 2： 機能や性能だけでなく、セキュリティも考慮してシステムを設計する[脚注 24]。
Primarily applies to: System Operator	主に以下に該当する： システム運用者
[OWASP 2024, MITRE 2024, WEF 2024, ENISA 2023, NCSC 2023, BSI1 2023, Cisco 2022, Microsoft 2022, G7 2023, HHS 2021, OpenAI2 2024, ASD 2023, ICO 2020]	[OWASP 2024、MITRE 2024、WEF 2024、ENISA 2023、NCSC 2023、BSI1 2023、Cisco 2022、Microsoft 2022、G7 2023、HHS 2021、OpenAI2 2024、ASD 2023、ICO 2020]。
2.1 As part of deciding whether to create an AI system, a System Operator shall determine and document the business requirements and/or problem they are seeking to address.	2.1 AI システムを構築するかどうかを決定する一環として、システム運用者は、ビジネス要件および/または 解決しようとしている問題を決定し、文書化するものとする。
2.1.1 Data controllers shall be part of internal discussions when determining the requirements and data needs of an AI system.	2.1.1 AI システムの要件とデータニーズを決定する際、データ管理者は内部協議に参加するものとする。
NCSC Guidelines for Secure AI System Development - other areas to consider include:	安全なAIシステム開発のためのNCSCガイドライン - 考慮すべき他の領域は以下の通りである：
・The complexity of the model they are using, specifically the chosen architecture and number of parameters.	・使用するモデルの複雑さ、特に選択したアーキテクチャとパラメータ数。
・The model’s chosen architecture and number of parameters will, among other factors, affect how much training data it requires and how robust it is to changes in input data when in use.	・使用するモデルの複雑さ、特に選択されたアーキテクチャとパラメータ数。モデルの選択されたアーキテクチャとパラメータ数は、他の要因の中でも、それが必要とする学習データの量と、使用時の入力データの変化に対するロバスト性に影響する。
・The appropriateness of the model for their use case and/or feasibility of adapting it to their specific need (for example by fine-tuning).	・ユースケースに対するモデルの妥当性、および／または、（微調整などによる）特定のニーズへの適応の可能性。
・The ability to align, interpret and explain their model’s outputs (for example for debugging, audit or regulatory compliance); there may be benefits to using simpler, more transparent models over large and complex ones which are more difficult to interpret.	・モデルの出力を整合させ、解釈し、説明する能力（例えば、デバッグ、監査、規制遵守のため）； 解釈がより困難な大規模で複雑なモデルよりも、より単純で透明性の高いモデルを使用することに利点があるかもしれない。
・The characteristics of training dataset(s), including size, integrity, quality, sensitivity, age, relevance and diversity the value of using model hardening (such as adversarial training), regularisation and/or privacy enhancing techniques.	・サイズ、完全性、品質、感度、年齢、関連性、多様性など、トレーニング・データセットの特性 モデル・ハードニング（敵対的トレーニングなど）、正則化、プライバシー強化技術の使用価値。
The provenance and supply chains of components including the model or foundation model, training data and associated tools.	モデルまたは基礎モデル、トレーニングデータ、関連ツールを含むコンポーネントの出所とサプライチェーン。
See NCSC Machine Learning Principles for more information.	詳細は NCSC 機械学習原則を参照のこと。
2.2 To support the process of preparing data for an AI system, Developers shall document and audit trail the creation, operation, and life cycle management of models, datasets and prompts incorporated into the system.	2.2 AI システムのためにデータを準備するプロセスを支援するために、開発者はシステムに組み 込まれるモデル、データセット、プロンプトの作成、運用、ライフサイクル管理を文書化し、 監査証跡を残さなければならない。
2.3 If a Developer and/or System Operator decides to use an external Application Programming Interface (API), they shall apply appropriate controls to data that can be sent to services outside of their organisation’s control, such as requiring users to log in and confirm before sending potentially sensitive information.	2.3 開発者及び／又はシステム運用者が、外部のアプリケーションプログラミングインタフェース （API）を使用することを決定した場合、開発者及び／又はシステム運用者は、潜在的にセンシティブな 情報を送信する前にユーザにログインと確認を要求するなど、組織の管理外のサービスに送信 される可能性のあるデータに対して適切な管理を適用しなければならない。
2.4 Data controllers shall ensure that the intended usage of the system is appropriate with the sensitivity of the data it was controlled on as well as the controls intended to ensure the safety of data.	2.4 データ管理者は、システムの意図された使用方法が、データの安全性を確保するために意図された管理だけでなく、管理されたデータの機微性に応じて適切であることを確認しなければならない。
2.5 Where the AI system will be interacting with other systems, (be they internal or external), Developers and System Operators shall ensure that the permissions used by the system are only provided as required for functionality and are risk assessed.	2.5 AI システムが他のシステム（内部であれ外部であれ）と相互作用する場合、開発者及びシス テム運用者は、システムによって使用される権限が、機能上必要な場合にのみ提供され、リ スクアセスメントされていることを保証しなければならない。
This includes ensuring identities used by the AI system are constrained in scope and privilege to the access required. This includes external AI and non-AI fail-safes if necessary.	これには、AI システムで使用される ID が、必要なアクセスの範囲と権限に制約されていることを保証することが含まれる。これには、必要に応じて、外部の AI および非 AI のフェイルセーフが含まれる。
2.6 If a System Operator chooses to work with an external model provider, they shall undertake a due diligence assessment of that provider’s security.	2.6 システムオペレーターが外部のモデルプロバイダーと協働することを選択した場合、システムオ ペレーターはそのプロバイダーのセキュリティのデューデリジェンス評価を実施しなければならない。
This assessment could involve implement scanning and isolation/sandboxing when importing third-party models, serialised weights or untrusted third-party code.	この評価には、サードパーティ製モデル、シリアル化されたウェイト、または信頼できないサードパーティ製 コードを輸入する際のスキャニングと隔離／サンドボックス化が含まれる。
2.7 If a Developer and/or System Operator decides to use an external library, they shall complete a due diligence assessment.[footnote 25]	2.7 開発者及び／又はシステム運用者が外部ライブラリの使用を決定した場合、開発者及び／又はシス テム運用者はデューディリジェンス評価を完了しなければならない[脚注 25]。
This assessment could consider whether the model can be obtained as a safe model and if not, then doing checks to ensure the library has controls that prevent the system loading untrusted models without immediately exposing itself to arbitrary code execution.	このアセスメントでは、そのモデルが安全なモデルとして入手できるかどうかを検討し、そうでない 場合は、そのライブラリが、システムが信頼できないモデルをロードしても、直ちに任意のコード実行にさらされ ないような制御を備えていることを確認する。
Principle 3: Model the threats to your system[footnote 26]	原則3：システム[脚注26]に対する脅威をモデル化する。
Primarily applies to: Developers and System Operators	主に以下に適用される： 開発者とシステム運用者
[OWASP 2024, WEF 2024, Nvidia 2023, ENISA 2023, Google 2023, G7 2023, NCSC 2023, Deloitte 2023]	[OWASP 2024、WEF 2024、Nvidia 2023、ENISA 2023、Google 2023、G7 2023、NCSC 2023、Deloitte 2023]。
3.1 Developers and System Operators shall undertake modelling of the threats to a system as part of their risk management process.	3.1 開発者とシステム運用者は、リスクマネジメントプロセスの一環として、システムに対する脅威のモデリングを実施する。
NCSC Guidelines for Secure AI System Development: This modelling could include understanding the potential impacts to all AI-responsible stakeholders, end-users, and wider society if an AI component becomes compromised or behaves unexpectedly. Additionally, the modelling could be informed by AI-specific attacks and failure modes, as well as more traditional IT system attacks. The modelling could factor the total range of possible outputs, (including worst case scenarios), from AI components and their impact on the system.	セキュアな AI システム開発のための NCSC ガイドライン このモデリングには、AIのコンポーネントが危殆化したり予期せぬ挙動を示したりした場合に、AIに責任を持つすべての利害関係者、エンドユーザー、より広い社会が受ける潜在的な影響を理解することが含まれる。さらに、モデリングは、より伝統的なITシステム攻撃だけでなく、AI特有の攻撃や故障モードからも情報を得ることができる。モデリングは、AIコンポーネントから出力される可能性のある総範囲（最悪のシナリオを含む）と、それらがシステムに与える影響を考慮することができる。
3.1.1 The risk management process shall be conducted to address any security risks that arise when a new setting or configuration option is implemented at any stage of the AI lifecycle.	3.1.1 AIのライフサイクルのどの段階においても、新しい設定又は構成オプションを実装する 際に発生するセキュリティリスクに対処するために、リスクマネジメントプロセスを実施 するものとする。
3.1.2 As part of this process, Developers shall create a document that includes a list of adversarial motivations and possible attack routes in line with those motivations.	3.1.2 このプロセスの一環として、開発者は敵対的な動機のリストと、その動機に沿った攻撃経路の可能性を含む 文書を作成しなければならない。
The type of attacks could include indirect attacks where attackers poison data which might later be used by, or sent to, the model.	攻撃の種類には、後にモデル・ポイズニングによって使用されたり、モデル・ポイズニングに 送られたりする可能性のあるデータを攻撃者がポイズニングする間接的な攻撃も含まれる。
3.1.3 Developers shall manage the risks associated with models that provide multiple functionality, where increased functionality leads to increased risk. For example, where a multi-modal model is being used but only single modality is used for system function.	3.1.3 開発者は、多機能を提供するモデルに関連するリスクをマネジメントしなければならない。例えば、マルチモダ ルモデルが使用されているが、システム機能には単一モダリティのみが使用されている場合など である。
3.2 Data controllers should conduct a data protection impact assessment when necessary as a measure under UK data protection obligations to determine what controls are needed.	3.2 データ管理者は、どのような管理が必要かを判断するために、英国のデータ保護 義務に基づく措置として、必要に応じてデータ保護影響アセスメントを実施するべ きである。
3.3 Where threats are identified that cannot be resolved by Developers, this shall be communicated to System Operators and End-users to allow them to appropriately threat model their systems.	3.3 開発者によって解決できない脅威が特定された場合は、システム運用者及びエンドユーザがシステ ムを適切に脅威モデル化できるように、そのことを伝えなければならない。
3.4 Where third-party organisations have responsibility for risks identified within an organisations infrastructure, System Operators should attain assurance that these parties are able to address the risk.	3.4 組織のインフラ内で識別されたリスクに対してサードパーティが責任を持つ場合、システムオペレ ータは、サードパーティがリスクに対処できるという保証を得るべきである。
3.5 System Operators should seek to apply controls to risks identified through the analysis based on a range of considerations, including the cost of implementation in line with their corporate risk tolerance.	3.5 システム運用者は、企業のリスク許容度に沿った実装コストを含む様々な考慮事項に基づいて、 分析を通じて特定されたリスクに対するコントロールの適用を求めるべきである。
3.6 Developers and System Operators should recognise and accept that a level of risk will remain despite the application of controls to mitigate against them, and continuously monitor and review their system infrastructure according to risk appetite.	3.6 開発者及びシステム運用者は、リスクを軽減するためのコントロールの適用にもかかわらず、 リスクのレベルが残ることを認識し、受け入れ、リスク選好度に従ってシステムインフラストラ クチャを継続的に監視し、見直すべきである。
Principle 4: Ensure decisions on user interactions are informed by AI-specific risks[footnote 27]	原則4：AI特有のリスク[脚注27]に基づいて、ユーザとのインタラクションに関する意思決定が行われるようにする。
Primarily applies to: Developers and System Operators	主に以下に適用される： 開発者とシステム運用者
[OWASP 2024, MITRE 2024, BSI1 2023, Microsoft 2022]	[OWASP 2024、MITRE 2024、BSI1 2023、Microsoft 2022]。
4.1 Developers and System Operators shall ensure that their system provides effective safeguards around model outputs through non-AI components and processes.	4.1 開発者及びシステム運用者は、そのシステムが、非AIコンポーネント及びプロセスを通じて、モデル出 力に関する効果的なセーフガードを提供することを確実にしなければならない。
This could also include the use of trained human oversight.	これには、訓練された人間の監視の使用も含まれる。
4.2 Developers shall take steps to validate that the designed controls specified by the Data Controller have been built into the system.	4.2 開発者は、データ管理者が指定した設計された管理がシステムに組み込まれていること を検証するための手段を講じなければならない。
4.3 Developers should consider placing limits on the rate of model access (e.g. via APIs) to prevent attacks based on experimentation, and limit resource usage for single model inputs to prevent the overuse of resources.	4.3 開発者は、実験に基づく攻撃を防止するために、（API経由などの）モデルへのアクセス 率に制限を設けること、及びリソースの過剰使用を防止するために、単一のモデル入力に対 するリソース使用を制限することを検討すべきである。
4.4 Developers and System Operators should ensure end-users are aware of prohibited use cases of the AI system.	4.4 開発者及びシステム運用者は、AI システムの禁止された使用事例をエンドユーザに確実に認識させるべきである。
4.5 Developers and System Operators should be transparent with end-users about known limitations or potential failure modes to protect against overreliance.	4.5 開発者とシステム運用者は、過信を防ぐために、既知の制限や潜在的な故障モードについて、 エンドユーザに透明であるべきである。
4.6 If a Developer offers an API to external customers or collaborators, they shall apply appropriate controls that mitigate attacks on the AI system via the API.	4.6 開発者が外部の顧客や協力者に API を提供する場合、API を介した AI システムへの攻撃を軽減する適切な管理を適用しなければならない。
Secure Development	セキュアな開発
Principle 5: Identify, track and protect your assets[footnote 28]	原則5：資産を識別、追跡、保護する[脚注28]。
Primarily applies to: Developers, System Operators and Data Controllers	主に以下に適用される： 開発者、システム運用者、データ管理者
[OWASP 2024, Nvidia 2023, NCSC 2023, BSI1 2023, Cisco 2022, Deloitte 2023, Amazon 2023, G7 2023, ICO 2020]	[OWASP 2024、Nvidia 2023、NCSC 2023、BSI1 2023、Cisco 2022、Deloitte 2023、Amazon 2023、G7 2023、ICO 2020]。
5.1 Developers, Data Controllers and System Operators shall know where their assets reside and have assessed and accepted any associated risks as they evolve.	5.1 開発者、データ管理者、システム運用者は、自らの資産がどこに存在するかを把握し、それらが進化する際に関連するリスクをアセスメントし、受け入れていなければならない。
These assets could include AI models, data (including user feedback), prompts, software, documentation, logs and assessments (including information about potentially unsafe capabilities and failure modes).	これらの資産には、AIモデル、データ（ユーザからのフィードバックを含む）、プロンプト、ソフトウェア、文書、ログ及びアセスメント（潜在的に安全でない機能及び故障モードに関する情報を含む）が含まれ得る。
5.2 Developers, Data Controllers and System Operators shall have processes and tools to track, authenticate, manage version control and secure their assets.	5.2 開発者、データ管理者、システム運用者は、資産を追跡し、認証し、バージョン管理を行い、安全性を確保するためのプロセスとツールを持たなければならない。
5.3 System Operators shall have the ability to restore their systems to a known good state in the event of compromise.	5.3 システム運用者は、危殆化が発生した場合、システムを既知の良好な状態に復元する能力を有す るものとする。
5.4 All responsible stakeholders in this Code shall take steps to protect sensitive data, such as training or test data, against unauthorised access (see 6.2 and 6.2.1 for details on securing your data and other assets).	5.4 この規程のすべての責任ある関係者は、トレーニングデータやテストデータなどの機密データを、不正アクセ スから保護するための措置を講じなければならない（データおよびその他の資産の保護に関する詳細は、6.2 および 6.2.1 を参照）。
5.4.1 Developers, Data Controllers and System Operators shall apply checks and sanitisation to data and inputs when designing the model [based on their access to said data and inputs and where those data and inputs are stored]. This shall be repeated when model revisions are made in response to user feedback or continuous learning [See principle 6 for relevant provisions for open source].	5.4.1 開発者、データ管理者、及びシステムオペレーターは、モデルを設計する際、［当該データ及び 入力へのアクセス、並びにそれらのデータ及び入力が保管されている場所に基づいて］データ及び 入力に対してチェック及びサニタイズを適用しなければならない。これは、ユーザーからのフィードバックや継続的な学習に応じてモデルを改訂する際にも繰り返さなければならない［オープンソースに関する関連規定については、原則6を参照のこと］。
Principle 6: Secure your infrastructure[footnote 29]	原則6：インフラストラクチャーの安全性を確保する[脚注29]。
Primarily applies to: Developers and System Operators	主に以下の者に適用される： 開発者とシステム運用者
[OWASP 2024, MITRE 2024, WEF 2024, NCSC 2023, Microsoft 2022, ICO 2020]	[OWASP 2024、MITRE 2024、WEF 2024、NCSC 2023、Microsoft 2022、ICO 2020]。
6.1 Alongside implementing essential cyber security practices for securing system infrastructure[footnote 30], Developers and System Operators shall adopt appropriate access controls to their APIs, models and data, and to their training and processing pipelines.[footnote 31]	6.1 システムインフラ[注釈 30]の安全性を確保するために不可欠なサイバーセキュリティの実践を実施するのと並行して、開発者とシス テム運用者は、API、モデル、データ、及び、学習と処理のパイプラインに適切なアクセス管理を採用しなければならない[注釈 31]。
6.2 Developers and System Operators shall create segregated environments to enforce sensitivity and threat boundaries.	6.2 開発者とシステム運用者は、感度と脅威の境界を強制するために、分離された環境を構築しなければならない。
6.2.1 Developers, System Operators and Data Controllers shall create segregated environments for storing critical data, such as sensitive, training or test data [where this training data is not based on publicly available data – see 7.3.1 and 7.3.2].	6.2.1 開発者、システム運用者及びデータ管理者は、機密データ、学習データ又はテストデータ［この学習データが一般に利用可能なデータに基づくものでない場合-7.3.1 及び 7.3.2 を参照］のような重要なデータを保存するために、分離された環境を構築しなければならない。
6.2.2 Developers shall also create a segregated environment for where research is done and where production models are developed and/or accessed.	6.2.2 開発者はまた、研究が行われる場所と、本番モデルが開発及び／又はアクセスされる場所と の分離環境を構築しなければならない。
Stakeholders could use containerisation and virtualisation as methods for segregation. See NCSC containerisation guidance: [web]	利害関係者は、分離の方法としてコンテナ化や仮想化を使用することができる。NCSC コンテナ化ガイダンス（[web] ）を参照のこと。
6.3 Developers and System Operators shall implement and publish an effective vulnerability disclosure process to support a transparent and open culture within the organisation.[footnote 32]	6.3 開発者とシステム運用者は、組織内の透明でオープンな文化を支援するために、効果的な脆弱性開示プロ セスを実装し、公開しなければならない[脚注 32]。
6.4 Developers and System Operators shall create an incident management plan.	6.4 開発者とシステム運用者は、インシデント管理計画を策定しなければならない。
Principle 7: Secure your supply chain[footnote 33]	原則 7: サプライチェーンの安全性を確保する[脚注 33]。
Primarily applies to: Developers, System Operators and Data Controllers	主に以下に適用される： 開発者、システム運用者、データ管理者
[OWASP 2024, NCSC 2023, Microsoft 2022, ASD 2023]	[OWASP 2024、NCSC 2023、Microsoft 2022、ASD 2023]。
7.1 Developers and System Operators shall require suppliers to adhere to the same security expectations and requirements that they apply to other software components to develop new software/AI products. This shall align with their risk management policies.	7.1. 開発者とシステムオペレータは、新しいソフトウェア/AI 製品を開発するために、他のソフトウ ェアコンポーネントに適用するのと同じセキュリティ期待と要求事項を遵守するよう、サプラ イヤに要求しなければならない。これは、自社のリスクマネジメント方針と整合させるものとする。
7.2 If a component is not produced in-house, Developers and System Operators should acquire and maintain well-secured and well-documented hardware and software components (for example, models, data, software libraries, modules, middleware, frameworks, and external APIs) from verified commercial, open-source, and other third-party developers to ensure robust security in your systems.	7.2 コンポーネントが自社で製造されていない場合、開発者とシステム運用者は、システムの強固なセキュリ ティを確保するために、検証された商用、オープンソース、その他のサードパーティ開発者から、十分にセキュリ ティが確保され、十分に文書化されたハードウェアとソフトウェアのコンポーネント（例えば、モデル、データ、ソフ トウェアライブラリ、モジュール、ミドルウェア、フレームワーク、外部API）を入手し、維持すること。
7.2.1 Developers that choose to use any models, or components, which are not well-documented or secured shall be able to justify why, (for example if there was no other supplier for said component), and be prepared to share this explanation with end-users, and System Operators if required.	7.2.1 十分な文書化もセキュリティ保護もされていないモデルやコンポーネントを使用することを選択した 開発者は、その理由（例えば、当該コンポーネントに他の供給者がいなかった場合など）を正当化でき、 必要に応じてエンドユーザやシステム運用者とこの説明を共有できるように準備しなければならない。
Particular attention should be given to the use of open-source models, where the responsibility of model maintenance and security becomes complex.	モデルの保守とセキュリティの責任が複雑になるオープンソースモデルの使用には、特 に注意を払うべきである。
7.3 Developers and System Operators should be prepared to failover to alternate solutions for mission-critical systems, if their security criteria are not met.[footnote 34]	7.3 開発者及びシステム運用者は、ミッションクリティカルなシステムのセキュリティ基準が満たされな い場合、代替ソリューションにフェイルオーバーする用意をしておくべきである[脚注 34]。
7.3.1 Where training data has been sourced from publicly available sources, Developers and Data controllers shall need to validate that such training data will not compromise the integrity of their security protocols.	7.3.1 学習データが一般に入手可能なソースから提供されている場合、開発者及びデータ管理者は、 そのような学習データがセキュリティプロトコルの完全性を損なわないことを検証する必要がある。
7.3.2 Data controllers should continually monitor the source of publicly available data that could be used for creating a model, such as for changes in the data sources that may risk creating vulnerabilities.	7.3.2 データ管理者は、モデルの作成に使用される可能性のある、一般に入手可能なデータのソース を継続的に監視し、脆弱性を生み出すリスクのあるデータソースの変更がないかなどを監視す る。
Principle 8: Document your data, models and prompts[footnote 35]	原則8：データ、モデル、プロンプトを文書化する[脚注35]。
Primarily applies to: Developers	主に以下に適用される： 開発者
[OWASP 2024, WEF 2024, NCSC 2023, Cisco 2022, Microsoft 2022, ICO 2020]	[OWASP2024、WEF2024、NCSC2023、シスコ2022、マイクロソフト2022、ICO2020]。
8.1 Developers shall document and maintain a clear audit trail of their model design and post-deployment maintenance plans.	8.1 開発者は、モデルの設計と配備後の保守計画を文書化し、明確な監査証跡を維持しなければならない。
8.1.1 Developers should ensure that the document includes security-relevant information, such as the sources of training data (including fine-tuning data and human or other operational feedback), intended scope and limitations, guardrails, cryptographic hashes or signatures, retention time, suggested review frequency and potential failure modes.	8.1.1 開発者は、文書に、訓練データの情報源（微調整データ及び人間又は他の運用上のフィードバックを含む）、意図された範囲と制限、ガードレール、暗号ハッシュ又は署名、保持時間、推奨されるレビュー頻度及び潜在的な故障モードのようなセキュリティに関連する情報が含まれていることを確実にしなければならない。
8.1.2 Developers should pay particular attention to document areas of model and system complexity that could lead to unexpected security issues, including details of software dependencies and configurations.	8.1.2 開発者は、ソフトウエアの依存関係や設定の詳細を含め、予期せぬセキュリティ問題につながる可能性のある、 モデルやシステムの複雑な領域の文書化に特に注意を払うべきである。
8.2 Developers should ensure that model outputs include only the necessary information for downstream purposes and do not include additional meta-data that might be used for honing attacks against the model.	8.2 開発者は、モデルの出力が下流の目的のために必要な情報のみを含み、モデルに対する攻撃を研 究するために使用される可能性のある付加的なメタデータを含まないことを確実にすべきである。
Principle 9: Conduct appropriate testing and evaluation[footnote 36]	原則9：適切なテストと評価[脚注36]を実施する。
Primarily applies to: Developers	主に以下の者に適用される： 開発者
[OWASP 2024, WEF 2024, Nvidia 2023, NCSC 2023, ENISA 2023, Google 2023, G7 2023]	[OWASP 2024、WEF 2024、Nvidia 2023、NCSC 2023、ENISA 2023、Google 2023、G7 2023]。
9.1 Developers shall ensure that no models, applications or systems are released that haven’t been tested as part of a security assessment process.	9.1 開発者は、セキュリティアセスメントプロセスの一環としてテストされていないモデル、アプリケーショ ン、システムをリリースしてはならない。
9.2 Developers shall validate that AI models perform as intended through testing.	9.2 開発者は、テストを通じて、AI モデルが意図したとおりに動作することを検証しなければならない。
9.2.1 Developers shall work closely with System Operators for post-deployment testing when maintaining a system. (see 2.1.2 for more details)	9.2.1 開発者は、システムを保守する際、システム運用者と緊密に連携して、配備後のテストを行う。(詳細は 2.1.2 を参照のこと）。
9.2.2 Evaluations of AI systems should involve red teaming or other adversarial testing as part of a whole system approach.	9.2.2 AI システムの評価には、システム全体のアプローチの一部として、レッドチームまたは他の敵対的なテストを含むべきである。
9.2.3 Evaluations of AI systems should be undertaken by suitably skilled testers. Where possible, this should be an independent external evaluation.	9.2.3 AI システムの評価は、適切に熟練したテスト実施者によって実施されなければならない。可能であれば、これは独立した外部評価であるべきである。
9.3 Developers should perform benchmarking as part of their risk management process throughout the AI development lifecycle (see principle 2 for more detail).	9.3 開発者は、AI 開発のライフサイクルを通じて、リスクマネジメントの一環としてベンチマーキングを実施す べきである（詳細は原則 2 を参照）。
9.4 Developers should ensure that the findings from the testing and evaluation are shared with System Operators, to inform their own testing and evaluation.	9.4 開発者は、テストと評価から得られた知見をシステム運用者と確実に共有し、自らのテストと評価に役立てるべきである。
Secure Deployment	安全な実装
Principle 10: Communication and processes associated with end-users[footnote 37]	原則 10：エンドユーザ[脚注 37]とのコミュニケーションとプロセス
Primarily applies to: Developers and System Operators	主に以下に適用される： 開発者とシステム運用者
10.1 In the context of AI, Developers shall state clearly to end-users (where possible) which aspects of security the end-user is responsible for and are transparent about where and how their data might be used, accessed or stored (for example, if it is used for model retraining, or reviewed by employees or partners).	10.1 AI の文脈では、開発者はエンドユーザに対して（可能であれば）、エンドユーザがどのようなセキュリティの側面に責任を持つかを明確に表明し、そのデータがどこでどのように使用され、アクセスされ、保存される可能性があるか（例えば、モデルの再教育に使用される場合、従業員やパートナーによってレビューされる場合）について透明性を確保しなければならない。
10.2 Developers should ensure that the organisation proactively supports affected End-users and System Operators during and following a cyber security incident to contain and mitigate the impacts of an incident. The process for undertaking this should be documented and agreed in contracts with end-users.	10.2 開発者は、サイバーセキュリティインシデント発生中及び発生後、影響を受けるエンドユーザとシス テムオペレータを組織が積極的に支援し、インシデントの影響を抑制・軽減することを確実にする。これを行うためのプロセスは文書化され、 エンドユーザとの契約において合意されるべきである。
10.3 Developers should provide end-users with guidance on how to use, manage, integrate, and configure the software product or service securely.	10.3 開発者は、ソフトウェア製品またはサービスを安全に使用、マネージド・ サービス・サービス・プロバイダーとして統合、設定する方法に関するガイダンスをエンドユー ザーに提供すべきである。
10.3.1 In the context of AI, this should include the appropriate use of your model or system, which includes highlighting limitations and potential failure modes.	10.3.1 AIの文脈では、これにはモデルやシステムの適切な使用方法を含めるべきであり、これには制限や潜在的な故障モードの強調も含まれる。
10.3.2 Moreover, Developers shall inform end-users of additional AI model functionality, and allow an opt-out option.	10.3.2 さらに、開発者は AI モデルの追加機能についてエンドユーザに通知し、オプトアウトオプションを許可しなければならない。
Secure Maintenance	安全な保守
Principle 11: Maintain regular security updates for AI model and systems[footnote 38]	原則11：AIモデルとシステムのセキュリティ更新を定期的に行う[脚注38]。
Primarily applies to: Developers and System Operators	主に以下の者に適用される： 開発者とシステム運用者
[ICO 2020]	[ICO 2020] を参照されたい。
11.1 Developers and System Operators shall ensure that when documenting their project requirements, their plans include conducting regular security audits and updates and working with external providers (where needed) to achieve this.	11.1 開発者とシステム運用者は、プロジェクト要件を文書化する際、その計画に、 定期的なセキュリティ監査と更新の実施、及びそのための外部プロバイダとの協働（必 要な場合）を含めることを確実にしなければならない。
11.2 Developers shall provide security updates and patches, where possible, and notify System Operators and End-users of the security updates.	11.2 開発者は、可能であればセキュリティ更新とパッチを提供し、システム運用者とエンドユーザに セキュリティ更新を通知しなければならない。
11.2.1 In instances where updates can’t be provided, Developers shall have mechanisms for escalating issues to the wider community, particularly customers and other Developers.	11.2.1 アップデートが提供できない場合、 開発者は問題をより広いコミュニティ、 特に顧客や他の開発者に知らせる仕組みを持たなければならない。
To help deliver this, they could publish bulletins responding to vulnerability disclosures, including detailed and complete common vulnerability enumeration.	これを実現するために、 開発者は脆弱性の公開に対応した速報 (bulletins) を発行することができる。
11.3 Developers should treat major system updates as though a new version of a model has been developed, and therefore undertake a new testing and evaluation process for each to help protect users.	11.3 開発者はシステムのメジャーアップデートを、 モデルの新バージョンが開発されたかのように扱うべきであり、 そのためにユーザを保護するための新しいテストと評価のプロセスを、 それぞれ実施すべきである。
11.4 Developers should support System Operators to evaluate and respond to model changes, (for example by providing preview access via beta-testing and versioned APIs).	11.4 開発者は、システム運用者がモデルの変更を評価し対応できるよう、(例えばベータテストや バージョン別APIによるプレビューアクセスをプロバイダに提供するなどして)支援す べきである。
Principle 12: Monitor your system’s behaviour	原則12：システムの挙動を監視する
Primarily applies to: Developers and System Operators	主に以下に適用される： 開発者とシステム運用者
[OWASP 2024, WEF 2024, Nvidia 2023, ENISA 2023, BSI1 2023, Cisco 2022, Deloitte 2023, G7 2023, Amazon 2023, ICO 2020]	[OWASP 2024, WEF 2024, Nvidia 2023, ENISA 2023, BSI1 2023, Cisco 2022, Deloitte 2023, G7 2023, Amazon 2023, ICO 2020].
12.1 In line with privacy and data protection requirements, Systems Operators should log all inputs and outputs to/from their AI system to enable auditing, compliance obligations, investigation and remediation in the case of compromise or misuse.	12.1 プライバシー・データ保護要件に沿って、システム運用者は、危殆化または誤用が発生した場合の監査、コンプライアンス義務、調査、修復を可能にするために、AI システムへの／からのすべての入出力を記録すべきである。
12.2 System Operators and Developers should also consider logging internal states of their AI models where they feel this could better enable them to address security threats, or to enable future security analytics.	12.2 システム運用者と開発者は、セキュリティ上の脅威に対処するため、あるいは将来のセキュリティ分析を可能にするために、AI モデルの内部状態をログに記録することも検討すべきである。
12.3 System Operators and Developers should monitor the performance of their models and system over time so that they can detect sudden or gradual changes in behaviour that could affect security.	12.3 システム運用者と開発者は、セキュリティに影響を及ぼす可能性のある突然の又は漸進的な挙動の変化を検知できるように、モデル及びシステムのパフォーマ ンスを経時的に監視するべきである。
This can be achieved by using tools that detect anomalous inputs that will skew outputs, without knowing what malicious input looks like. There are specific methods that could be implemented to mitigate input that is out of distribution or invalid, such as outlier detection, anomaly detection, novelty detection, and open set recognition.	これは、悪意のある入力がどのように見えるかを知らなくても、出力を歪めるような異常な入力を検知するツールを使用することによって達成できる。異常値検知、異常検知、新規性検知、オープンセット認識など、分布外や無効な入力を緩和するために実装可能な特定の方法がある。
12.4 System Operators and Developers should analyse their logs to ensure that AI models continue to produce desired outputs over time.	12.4 システム運用者および開発者は、AI モデルが長期にわたって望ましい出力を生成し続けることを確 認するために、ログを分析すべきである。

24	See Guideline on “Design your system for security as well as functionality and performance” in Guidelines for secure AI system development, NCSC, 2023. Additionally, Software Vendors should review Principle 1 on “Secure design and development” for further requirements in the Software Code of Practice. ↩	安全なAIシステム開発のためのガイドライン」（NCSC、2023）の「機能と性能だけでなく、セキュリ ティも考慮してシステムを設計すること」に関するガイドラインを参照のこと。さらに、ソフトウェア・ベンダーは、ソフトウェア実施規範におけるさらなる要件について、「安全な設計と開発」に関する原則1を確認する必要がある。
25	Guidelines for secure AI System Development, NCSC, 2023: This will help ensure the library has controls that prevent the system loading untrusted models without immediately exposing themselves to arbitrary code execution. ↩	Guidelines for secure AI System Development, NCSC, 2023： これは、システムが信頼できないモデルをロードしても、直ちに任意のコード実行にさらされることを防ぐ制御をライブラリが持っていることを確認するのに役立つ。
26	See “Model the threats to your system” and “Raise staff awareness of threats and risks” in Guidelines for secure AI system development, NCSC, 2023. Additionally, Software Vendors should review Principle 1 on “Secure design and development” for further requirements in the Software Code of Practice. ↩	安全なAIシステム開発のためのガイドライン（Guidelines for secure AI system development, NCSC, 2023）の「システムに対する脅威をモデル化する（Model the threats to your system）」と「脅威とリスクに対するスタッフの意識を高める（Raise staff awareness of threats and risks）」を参照のこと。さらに、ソフトウエアベンダーは、ソフトウエア実施規範の「安全な設計と開発」に関する原則1を確認し、さらなる要件を確認する必要がある。
27	See “Design your system for security as well as functionality and performance” in Guidelines for secure AI system development, NCSC, 2023.  Additionally, Software Vendors should review Principle 1 on “Secure design and development” for further requirements in the Software Code of Practice. ↩	安全なAIシステム開発のためのガイドライン（Guidelines for secure AI system development, NCSC, 2023）の「機能と性能だけでなく、セキュリティのためにシステムを設計する」を参照のこと。 さらに、ソフトウェア・ベンダーは、「ソフトウェア実施基準」におけるさらなる要件について、「安全な設計と開発」に関する原則1を確認すること。
28	See “Identify, track and protect your assets” in Guidelines for secure AI system development, NCSC, 2023. Additionally, Software Vendors should review Principle 1 on “Secure design and development” for further requirements in the Software Code of Practice. ↩	安全なAIシステム開発のためのガイドライン」（NCSC, 2023）の「資産の識別、追跡、保護」を参照のこと。さらに、ソフトウェア・ベンダーは、ソフトウェア実施規範の「安全な設計と開発」に関する原則 1 を確認し、さらなる要件を確認すること。
29	See “Secure your infrastructure” in Guidelines for secure AI system development, NCSC, 2023. ↩	セキュアなAIシステム開発のためのガイドライン』（NCSC、2023年）の「インフラをセキュアにする」を参照のこと。
30	Organisations should review DSIT’s Cyber Governance Code of Practice, NCSC’s Business Toolkit and Cyber Essentials. ↩	組織は、DSITのサイバーガバナンス実践規範、NCSCのビジネスツールキット、サイバーエッセンシャルを確認する必要がある。
31	Strategies include: encryption of data at rest, technical access controls for the data to limit access according to least privilege principles, centralised access controls for the data, operational security to protect stored data, logging and monitoring to detect suspicious manipulation of data (e.g. outside of office hours). ↩	防御策としては、静止データの暗号化、最小権限の原則に従ってアクセスを制限するデータの技術的アクセス管理、データの集中アクセス管理、保存データを保護する運用セキュリティ、データの不審な操作を検知するロギングと監視（営業時間外など）などがある。
32	Software Vendors should review Principle 3 on Secure deployment and maintenance for further requirements in Software Code of Practice. ↩	ソフトウェア・ベンダーは、「ソフトウェア規範」の「原則3 安全な配備と保守」を確認する必要がある。
33	See “Secure your supply chain” in Guidelines for secure AI system development, NCSC, 2023. Additionally, Software Vendors should review Principle 1 on “Secure design and development” for further requirements in the Software Code of Practice ↩	安全なAIシステム開発のためのガイドライン」（NCSC、2023年）の「サプライチェーンの安全確保」を参照のこと。さらに、ソフトウエアベンダーは、ソフトウエア実施基準における更なる要件について、「安全な設計と開 発」に関する原則 1 を見直すべきである。
34	See Supply chain security guidance, NCSC, 2018, and frameworks such as Safeguarding artifact integrity across any software supply chain, Supply Chain Levels for Software Artifacts (SLSA), for tracking attestations of the supply chain and software development life cycles. ↩	サプライチェーンセキュリティガイダンス（NCSC、2018年）、及びサプライチェーンとソフトウエア開発ライフサイクルの認証の追跡については、あらゆるソフトウエアサプライチェーンにおける成果物の完全性の保護（Safeguarding artifact integrity across any software supply chain）、ソフトウエア成果物のサプライチェーンレベル（Supply Chain Levels for Software Artifacts）（SLSA）などのフレームワークを参照すること。
35	See “Document your data, models and prompts” in Guidelines for secure AI system development, NCSC, 2023. Additionally, Software Vendors should review Principle 1 on “Secure design and development” for further requirements in the Software Code of Practice. ↩	安全なAIシステム開発のためのガイドライン、NCSC、2023の「データ、モデル、プロンプトを文書化する」を参照のこと。さらに、ソフトウエアベンダーは、ソフトウエア実施規範の「安全な設計と開発」に関する原則1を確認する必要がある。
36	See “Release AI responsibly” in Guidelines for secure AI system development, NCSC, 2023. Additionally, Software Vendors should review Principle 1 on “Secure design and development” for further requirements in the Software Code of Practice. See also AI Safety Institute for testing AI models at the Frontier. ↩	安全なAIシステム開発のためのガイドライン」（NCSC, 2023）の「責任を持ってAIをリリースする」を参照のこと。さらに、ソフトウェア・ベンダーは、ソフトウェア実施規範におけるさらなる要件について、「安全な設計と開発」に関する原則1を確認する必要がある。フロンティアでのAIモデルのテストについては、AI安全研究所も参照のこと。
37	See “Make it easy for users to do the right things” and “Develop incident management procedures (for further information)“ in Guidelines for secure AI system development, NCSC, 2023. Additionally, Software Vendors should review Principle 4 on “Communication with customers” for further requirements in the Software Code of Practice. ↩	安全なAIシステム開発のためのガイドライン、NCSC、2023の「ユーザーが正しいことを簡単にできるようにする」と「インシデント管理手順の開発（詳細）」を参照のこと。さらに、ソフトウェア・ベンダーは、ソフトウェア規範のさらなる要件について、原則4の「顧客とのコミュニケーション」を確認する必要がある。
38	See “Follow a secure by design approach to updates” in Guidelines for secure AI system development, NCSC, 2023. Additionally, Software Vendors should review Principle 3 on “Secure deployment and maintenance” for further requirements in the Software Code of Practice. ↩	安全なAIシステム開発のためのガイドライン（Guidelines for Secure AI system development）」（NCSC、2023）の「更新に対する安全な設計手法に従う（Follow a secure by design approach to updates）」を参照のこと。さらに、ソフトウエアベンダーは、ソフトウエア実施基準におけるさらなる要件について、「安全な配備と保守」に関する原則3を確認すること。