ISO27017とは何を確かめる規格？｜AIを預ける側の管理策

「取引先から、預けているクラウドについて27017の認証はあるかと聞かれました。うちは提供する側ではなく使う側なのですが、これは答えられる話なのでしょうか」「社内に入れたいAIサービスの資料に27017取得と書いてありました。これで安全だと判断してよいのか、どこまで確かめればよいのかが分かりません」。——この2つは、同じ問いの表と裏です。片方は預ける側として何を示すのかを聞いていて、もう片方は預かる側が示したものをどう読むのかを聞いています。情報マネジメントシステム認定センターが2024年3月11日に公表した資料では、クラウド固有の管理策を対象にした認証の登録数が500件を超えたとされています。同じ機関が2024年12月27日に公表した資料では、情報セキュリティの本体の認証の登録数が8,000件を超えたとされています。公表の時点が9か月ずれるため単純な割り算はできませんが、本体の認証を持つ組織のうち、クラウド固有の追加まで取っている組織は限られるという分布は読み取れます。この記事では、この規格が27001の何に足されるもので、預ける側と預かる側で読み方がどう変わり、AIサービスを社内に入れてよいかの審査で実際にどの欄が効くのかを、確かめられる形で書きます。

この規格が答えているのは「クラウドだと何が余分に要るのか」だけ

名前だけを見ると、クラウドの安全を丸ごと定めた規格に見えます。実際の位置づけはもっと狭く、はっきりしています。情報セキュリティの管理策を並べた規格が別にあり、その管理策をクラウドサービスで使うときの実施の手引として書かれたものが27017です。2015年に国際規格として発行され、日本産業規格としては2016年の版があります。ゼロから新しい要求を立てた規格ではなく、既にある欄に注釈を全面に付け直したもの、と読むのが正確です。

この位置づけを外すと、会話が噛み合わなくなります。「27017に対応していますか」と聞かれた側が答えに詰まる原因の多くは、規格番号だけがやり取りされていて、本体のどの管理策の話なのかが特定されていないことにあります。この規格は単独では守るべきことの一覧になりません。本体の管理策の一覧を横に置き、欄ごとに突き合わせて初めて読める作りだからです。番号ではなく欄の名前で聞くのが、往復を減らすいちばん確実な方法になります。

預ける側にとっての利点は、確かめる項目が既に欄の形で並んでいることです。質問を自分で作ると、思いついた順に並び、思いつかなかった領域がそのまま空白になります。契約が終わった後のデータの扱い、管理画面の権限、記録が自分の側から見えるかどうか。この3つは自作の確認票でいちばん抜けやすい項目で、どれもこの規格には固有の欄があります。欄を借りるだけでも、審査の穴は目に見えて減ります。

27001との関係は、置き換えではなく上に積む形

番号が近いので同列に見えますが、役割の層が違います。27001は仕組みそのものへの要求を定めた規格で、認証の対象になるのはこちらです。27002は管理策の実施の手引で、27001の附属書に並ぶ欄をどう実施するかを説明します。27017はさらにその上に乗り、27002の欄をクラウドサービスで使う場合に読み替える手引と、クラウドにしかない管理策を足します。3つを1本の線に並べると、要求、実施の手引、クラウド向けの読み替え、という順番になります。

認証の作りも、この層の関係をそのまま映しています。国内のクラウドセキュリティの認証は、情報セキュリティの本体の認証の拡張として設計されていて、認証基準は27017の2015年版と、それに対応する日本産業規格の2016年版に基づくと明記されています。本体の認証を持たない組織が、この認証だけを単独で取ることはできません。「27017を取っています」という言い方は、本体の認証を持っていることを含んでいることになります。

実務の負担も層で決まります。本体の仕組みが既にあるなら、足されるのは欄の読み替えと追加の管理策の分だけです。認定機関の説明では、拡張の認証であるため本体の定期審査のときや再認証審査のときに併せて実施できるとされています。逆に、本体の仕組みが無い状態でクラウドの管理策だけを整えても、認証にはたどり着きません。順番を逆にすると、作り込んだ資料の置き場所が無くなります。

足されるのは2つ。欄ごとの読み替えと、クラウドにしかない7つ

足される中身は2種類だけです。1つ目は、本体の管理策の一覧に対するクラウド向けの実施の手引です。下敷きになっている2013年発行の版には114の管理策が並んでいて、その欄に沿って、クラウドで使う場合の読み方が書き足されています。2つ目が、附属書に置かれたクラウドサービスに固有の追加の管理策で、番号の頭に区別のための記号が付いた7つがこれにあたります。

番号	管理策の名称	預ける側が確かめること
CLD.6.3.1	クラウドコンピューティング環境における役割及び責任の共有及び分担	どこまでが相手の仕事で、どこからが自社の仕事かが書面になっているか
CLD.8.1.5	クラウドサービスカスタマの資産の除去	契約が終わった後、何がいつ消え、何が残るか
CLD.9.5.1	仮想コンピューティング環境における分離	他社の利用と自社の利用が混ざらない作りか（自分では見に行けない）
CLD.9.5.2	仮想マシンの要塞化	使われていない機能や口が閉じられているか（自分では見に行けない）
CLD.12.1.5	実務管理者の運用のセキュリティ	管理画面で何ができ、その操作が記録され、自社に示されるか
CLD.12.4.5	クラウドサービスの監視	記録が残る範囲と期間、そして自社が取り出せる形式
CLD.13.1.4	仮想及び物理ネットワークのセキュリティ管理の整合	仮想側と物理側で守り方がちぐはぐでないか（自分では見に行けない）

表を眺めると、7つの性格が2つに割れているのが分かります。役割の分担、資産の除去、管理者の運用、サービスの監視は契約と運用の取り決めの話で、預ける側が相手に求めれば確かめられます。分離、要塞化、ネットワークの整合は相手の内部の作りの話で、預ける側が自分で見に行くことはできません。確かめられるものと、示してもらうしかないものが、同じ7つの中に混ざっているため、聞き方を分けないと確認票が空回りします。

同じ管理策が、預ける側と預かる側で別の文になる

この規格のいちばん独特な作りは、1つの欄に2人の読み手に向けた文が並んでいることです。クラウドサービスを利用する側と、提供する側です。資産の目録の欄を例にすると、利用する側には、クラウド環境に保存される情報と資産を目録に含めることが求められ、提供する側には、預かった側のデータと、サービスを動かす過程で生まれたデータを分けて明記することが求められます。同じ欄で、やることが違います。

だから、読む前に自社の立場を決めないと読めません。認定機関の説明でも、認証の適用範囲に、提供する側と利用する側のどちらの立場であるかを明確にすることが求められています。両方にあたる組織もあります。自社のサービスを提供しながら、その裏側で他社のクラウドを使っている場合です。この場合は同じ欄を2回読むことになります。立場を1つに決めてから読み始めると、必ず片側が抜けるので、両方に当たるなら最初から2列の表にして埋めます。

利用する側にも、やるべきことが具体的に書かれている点は見落とされがちです。認定機関の説明では、利用する側は、提供する側から得られた情報も含めてクラウドサービスの利用に関するリスクを評価し、必要であれば利用する側に対する追加の管理策を実施する必要がある、とされています。相手の認証を確かめて終わりにはならないという構造が、制度の側にはっきり書かれているわけです。預ける側の宿題は、相手が認証を持っていても消えません。

AIサービスを審査するとき、7つのうち先に開く4つ

生成AIも社内向けのAIも、多くは他社のクラウドの上で動きます。審査に使える時間は限られるので、7つの追加の管理策と読み替えの手引を等しく見るのは現実的ではありません。AIの審査で先に効くのは4つです。役割の分担、資産の除去、サービスの監視、管理者の運用。この4つは、AIサービス特有の困りごとがそのまま欄に対応しています。

• 役割の分担：入力された内容の扱い、出力の確認、利用者の管理を、どちらがどこまで負うのかが書面にあるか
• 資産の除去：入力した文章、やり取りの履歴、不正利用を見つけるための記録が、契約の終了後にいつ消えるか
• サービスの監視：誰がいつ何を入力したかの記録が残るか、その記録を自社が取り出せるか
• 管理者の運用：管理画面で何ができるか、提供する側の技術者が自社のデータに触れる場面があるか

逆に、後回しにしてよい欄もはっきりします。仮想環境の分離、要塞化、ネットワークの整合は、預ける側が確かめようのない領域です。認証の有無と、その認証の範囲に自社が使う環境が入っているかどうかで代替するのが現実的な扱いになります。時間の配分を先に決めておかないと、確かめようのない欄をめぐる議論で会議の大半が消えます。

資産の除去——契約が終わった後、何が消えて何が残るか

AIサービスの審査でいちばん効くのが、利用する側の資産の除去を扱う欄です。理由は単純で、AIサービスは入力したものが複数の場所に残るからです。入力した文章そのもの、やり取りの履歴、不適切な利用を見つけるために保管される記録、品質を確かめるために抜き出された一部。契約が終わったときに消えるのがどれで、残るのがどれかは、それぞれ別の取り決めになっています。

聞き方を欄に合わせると、答えが噛み合います。「データは削除されますか」と聞くと、ほぼ必ず「削除されます」と返ってきて、何も分かりません。対象、時期、方法、証跡の4つに割って聞くと、初めて差が出ます。解約から何日で消えるのか、控えの保管先からはいつ消えるのか、消えたことを示す書面が出るのか。消えないものがあると答えられる相手のほうが、実は確かめやすいというのが、この欄を使ったときの手触りです。

落とし穴は自社の側にもあります。利用する側の資産を除去するには、どこに何を置いたかを自社が把握している必要があります。部署ごとに別々の契約で同じAIサービスを使っていると、解約の対象から漏れた契約が残り、そこに置いた資料だけが消えません。除去の欄を確かめる作業は、自社の契約の棚卸しとセットでしか成立しない、ということです。棚卸しの単位は、サービス名ではなく契約の単位にします。

サービスの監視——相手が見ているかではなく、自分から見えるか

監視の欄は、預ける側にとっては「相手が見ているか」ではなく「自分が見られるか」を聞く欄として使います。AIサービスで問題になるのは、誰がいつ何を入力したかの記録です。社外に出してはいけない資料が入力された疑いが出たとき、社内の調査でその記録を自分たちの手で取り出せるかどうかで、対応にかかる時間が桁で変わります。

確かめる項目は4つに絞れます。記録が残る範囲、残る期間、自社が取り出せるかどうか、取り出せる形式です。期間は思っているより短いことが多いので、社内の規程が定める保存期間と突き合わせます。30日しか残らないサービスに対して、社内規程が1年の保存を求めているなら、その差を自社側で埋めるか、規程の側を直すかの判断になります。差を見つけるのが目的で、差が無いことを確かめるのが目的ではないという向きで使う欄です。

取り出せる形式も先に聞いておきます。画面でしか見られない記録は、事故の調査では使えません。表の形で落とせるか、期間を指定して落とせるか、落とした記録に利用者を識別する値が入っているか。識別する値が社内の人事情報とつながらない形だと、誰の操作かを特定できません。相手の管理画面での表示名が個人の名前ではなく連番の場合、対応表を自社側で持つ必要が出ます。ここまで聞いて、監視の欄がやっと埋まります。

管理者の運用——クラウドでは、できることが管理画面に集まる

実務管理者の運用のセキュリティを扱う欄は、クラウドでは特に重くなります。自社が物理的な機器を持たない代わりに、できることの全部が管理画面に集まるからです。AIサービスでは、ここに利用者の追加、使える機能の制御、入力内容の閲覧、記録の消去までが並ぶことがあります。1人の管理者の権限で全部に手が届く作りになっていないかが、確かめる中心になります。

自社の側で決めることは3つです。管理者を何人にするか、その人の操作の記録を誰が見るか、退職や異動のときに誰がいつ権限を外すか。いちばん抜けるのは3つ目で、人事の手続きとサービスの管理画面が別々に動いているため、辞めた人の管理者権限だけが残り続けます。四半期に一度、管理者の一覧を人事情報と突き合わせる作業を、誰の仕事かまで決めて置きます。

相手に聞く側では、提供する側の技術者が自社のデータに触れられる場面があるかを確かめます。触れられる場合、その操作は記録され、後から自社に示されるか。触れられる場面が一つも無いと答える相手には、根拠の欄を追加で聞くほうが安全です。障害からの復旧や、利用者からの問い合わせへの対応では、触れる必要が出るのが普通だからです。無いと答える相手が誠実とは限らず、条件付きで有ると答える相手のほうが管理の実態を持っていることがあります。

分離と要塞化——確かめようのない欄を、どう扱うか

残る3つ、仮想の計算環境における分離、仮想マシンの要塞化、仮想と物理のネットワークのセキュリティ管理の整合は、性格が違います。預ける側が自分で確かめる手段が無い領域です。相手の設備に入って見ることはできませんし、設定の一覧を見せてもらっても、それが実際に適用されているかを自社で検証することはできません。

だから、ここは確かめ方を替えます。3つとも、第三者の審査を通っているかどうかで代替します。このとき見るのは認証の有無そのものではありません。認証の範囲に、自社が使う環境が入っているかのほうです。同じ会社が提供する複数のサービスのうち、一部だけが範囲に入っていることは珍しくありません。登録証に書かれた適用範囲の文面を、会社名ではなくサービス名の単位で読みます。

範囲に入っていなかった場合の扱いも、先に決めておきます。使わないと決めるのか、使うが扱う情報の種類を制限するのか、期限を切って範囲に入るのを待つのか。3択のどれを選んだかを記録に残すことが、後から見たときの価値になります。範囲外だと分かった時点で止まる審査は、止まった理由が残らないため、次に同じ検討をするときに一から調べ直すことになります。残すのは判断の一文で十分です。

認証を取る側の手順は、本体の認証に足す形になる

求められる側になったときの手順も、層の関係のとおりです。本体の情報セキュリティの認証が先にあり、その拡張としてクラウドの認証を足します。既に本体を持っているなら、定期審査のときや再認証審査のときに併せて受けられます。いちばん時間がかかるのは審査そのものではなく、適用範囲の文面を決めるところです。ここが決まらないと、どの管理策を埋めるべきかも決まりません。

4つ目の書き分けが、その後の運用を左右します。立場を明確にすることが求められている以上、範囲の文面は取引先が読む物差しそのものになります。狭く書けば審査は軽くなりますが、取引先が知りたいサービスが範囲から外れれば、認証を持っていても確認票の往復は減りません。軽さと使いやすさが逆を向く場面なので、審査を受ける部署だけで決めないようにします。

求める側と求められる側で、この認証の意味は反転する

同じ認証でも、求める側から見るか求められる側から見るかで、使い方が変わります。反転する場所を先に押さえておくと、確認票のやり取りが噛み合います。

立場	この認証をどう使うか	外しやすい点
求める側（預ける側）	聞く項目を減らせる相手の目印として使う。範囲の文面を読み、自社が使うサービスが入っているかを確かめる	合否の条件にしてしまい、持っていない相手を理由を聞かずに落とす
求められる側（預かる側）	確認票の往復を減らす道具として使う。範囲の説明文を1枚作り、窓口が使える場所に置く	登録証の写しを送るだけで終わらせ、範囲の説明を付けない
両方にあたる組織	提供する側の欄と利用する側の欄を2列に並べ、同じ管理策を2回読む	提供する側の立場だけで整理し、他社のクラウドを使っている部分が抜ける

求める側が外しやすいのは、認証を合否の条件にしてしまうことです。選定基準に「この認証を持っていること」と書くと、持っていない相手を一律に落とすことになります。持っていない理由が、規模が小さいからなのか、別の枠組みで範囲が覆われているからなのかは、聞かないと分かりません。条件ではなく聞く項目を減らせる相手の目印として使うほうが、実態に合います。

求められる側が外しやすいのは、取った後に何を示すかを決めていないことです。取引先が欲しいのは登録証の写しではなく、範囲の文面と、自分たちが使うサービスがそこに含まれているかの説明です。登録証を送るだけの運用は、確認票の往復を1回も減らさないので、範囲の説明文を1枚作って、窓口の担当がすぐ取り出せる場所に置きます。

認証があること＝安全ではない。物差しとしての限界は3つ

この規格を審査の物差しに使うときの限界は、3つに整理できます。1つ目は範囲です。認証は組織の一部に対して取れます。会社として持っていても、自社が使うサービスが範囲外なら、その認証は自社にとっての根拠になりません。2つ目は時点で、審査は過去のある時点の状態を見ています。3つ目は版です。

3つ目が、AIの審査ではいちばん効きます。この規格は2015年の発行で、下敷きの管理策は2013年の版です。生成AIが業務に入る前に書かれた欄の集まりだということです。入力した内容が学習に使われるか、出力の権利がどちらにあるか、使われているモデルが予告なく差し替わるか。この3つは、規格の欄には固有の置き場所がありません。規格の欄で全部が埋まると考えると、AIに固有の論点がまるごと抜けることになります。欄の外側に自社で3行を足す、という扱いが必要です。

数の側からも見ておきます。認定機関が2024年3月11日に公表した資料では、クラウド固有の管理策を対象にした認証の登録数が500件を超えたとされ、推移のグラフは2016年から2023年までを示しています。同じ機関が2024年12月27日に公表した資料では、情報セキュリティの本体の認証の登録数が8,000件を超え、2022年9月以降の2年3か月で約1,000件増えたとされています。公表の時点が9か月ずれるので単純な割り算はできませんが、本体の認証を持つ組織のうち、クラウドの追加まで取っている組織は限られるという分布は読み取れます。持っていないことを、そのまま不合格の根拠にはできないということです。

隣にある規格や書類と、性格を混ぜない

番号の近い規格と、性格の違う書類が周辺にあります。混ぜると、確かめたつもりの範囲がずれます。27018は、公開されたクラウドで個人情報を扱うときの保護の指針を示す規格で、守る対象が情報の種類の側から決まっています。27017が使い方の側から決まるのとは、切り口が違います。個人情報を大量に預けるなら両方が要り、預けないなら27018の側は使いません。

AIそのものの管理を扱う規格も別にあります。あちらが対象にするのはAIを作り、使う組織の仕組みで、こちらが対象にするのはクラウドの使い方です。AIサービスを審査するなら、多くの場合は両方の視点が要ります。片方だけを見て「AIの安全は確かめた」と審査記録に書くと、後で読み返したときに何を確かめていないのかが分からなくなります。

保証報告書の類も、性格が違います。認証は基準に適合していることを第三者が証明する形ですが、報告書は監査人が意見を述べる形で、読む側が中身を読み解く前提で作られています。求めるものを選ぶときは、自社に読む人がいるかどうかで決めます。読む人がいない書類を求めても、届いた時点で審査が止まるからです。読む人がいないなら、認証の範囲を読むところまでで止める設計にします。

AIに任せてよいのは、対応づけと下書きと食い違いの指摘まで

この審査の作業の中で、AIが確実に役に立つ場所は3つです。1つ目は、届いた資料や相手の規程を読ませてどの管理策の欄に当たるかを対応づけさせること。2つ目は、自社の確認票の下書きを作らせること。3つ目は、返ってきた回答のうち、質問に答えていない箇所を指摘させることです。3つとも、人が原文と突き合わせて確かめられる作業だという点が共通しています。

外せない条件が1つあります。どの記述を根拠にそう判断したかを、必ず併記させることです。対応づけの結果だけが並んだ表は、確かめる手間のほうが高くつきます。根拠として引かれた文が原文に見当たらなければ、その行は捨てます。根拠の欄が空の行は、結論が正しくても採用しないという決めを先に置くと、人が読む範囲が自動的に絞られます。

任せてはいけない範囲も、名指しで決めます。社内に入れてよいかどうかの可否、範囲外の環境を使う場合の条件、いったん止めるときの判断。この3つは人が決め、決めた人の名前を審査の記録に残します。可否をAIに出させると、根拠のある否と、材料が足りないだけの否が同じ形で出てきて、区別できなくなります。区別できない否は、半年後に誰も覆せません。

• 規格番号だけで「対応していますか」と聞く。本体のどの欄の話かが特定されないまま往復が続き、答える側も何を示せばよいか分からない
• 認証の有無だけを選定基準に書く。範囲外のサービスを使う場合でも通ってしまい、逆に範囲が十分な相手を理由も聞かずに落とす
• 確かめようのない欄に時間を使う。分離や要塞化の作りを自社で検証しようとして会議が終わり、削除や記録の欄が空のまま残る
• 契約の棚卸しをせずに除去の欄を確かめる。部署ごとの別契約が漏れ、解約しても資料が残る契約が見つからない
• AIに可否を出させて、そのまま審査記録に貼る。根拠のある否と材料不足の否が同じ形になり、後から誰も判断を覆せない

よくある質問

クラウドを使う側でも、この認証は取れますか

取れます。認定機関の説明では、クラウドサービスを提供している組織、利用している組織、あるいはその両方である組織が対象とされています。利用する側で取る場合は、適用範囲に利用する側の立場であることを明確にし、利用する側に向けて書かれた欄を埋めます。提供する側のための制度だと思い込んで検討から外している組織が多いのが実情です。

本体の認証を持っていないと取れませんか

この認証は本体の情報セキュリティの認証の拡張として設計されているため、単独では取得できません。同時に取るか、本体を取った後に足す形になります。既に本体を持っている組織は、定期審査のときや再認証審査のときに併せて受けられるため、追加の負担は想像より小さいことが多いです。

相手がこの認証を持っていれば、確認票は省略してよいですか

省略はできません。減らせるのは、相手の内部の作りに関する項目です。分離、要塞化、ネットワークの整合にあたる欄は、範囲に自社の使う環境が入っていることを確かめたうえで、第三者の審査に委ねる扱いにできます。役割の分担、資産の除去、記録の取り出し、管理者の権限は、認証の有無にかかわらず個別に聞きます。相手ごとに答えが違うからです。

AIサービスの審査は、この規格の欄だけで足りますか

足りません。この規格の欄は、クラウドの使い方に関する部分を覆いますが、入力内容の学習への利用、出力の権利の帰属、使われているモデルの差し替えといったAIに固有の論点には、固有の置き場所がありません。規格の欄で覆える部分と、自社で足す部分を、確認票の上で見分けが付くように分けておきます。

どの版を見ればよいですか

国内の認証の基準は、2015年に発行された国際規格と、それに対応する2016年の日本産業規格に基づくとされています。審査や確認票のやり取りでは、規格番号だけでなくどの版を指しているかを一度は明示すると、後の食い違いが減ります。相手の登録証にも版が書かれているので、そこと突き合わせます。

• 認証の位置づけ、対象となる組織、適用範囲に立場を明記する必要があること、利用する側が提供する側から得た情報も含めてリスクを評価し必要な追加の管理策を実施すること、拡張の認証であるため定期審査や再認証審査に併せて実施できることは、情報マネジメントシステム認定センターおよび運営団体が公開している制度の説明とよくある質問の記載に基づいています
• クラウド固有の管理策を対象にした認証の登録数が500件を超えたことは2024年3月11日の公表、情報セキュリティの本体の認証の登録数が8,000件を超え2022年9月以降の2年3か月で約1,000件増えたことは2024年12月27日の公表によります。2つの数字は公表の時点が9か月異なり、対象も集計の期間も同じではないため、割合として計算することはできません
• 追加の管理策7つの番号と名称、および下敷きになっている管理策の本体が2013年発行の版で114の管理策から成ることは、複数の解説の記述を突き合わせて一致を確認した内容です。正確な条文と実施の手引は、規格そのものまたは対応する日本産業規格を参照してください
• この記事はクラウドの使い方に関する管理策を扱っています。AIそのもののマネジメントに関する規格の要求、個人情報を扱う組織の認証制度における生成AIの審査論点、監査人が意見を述べる形の保証報告書の読み方、確認票への回答の作り方、契約条項の選定項目は、いずれも別の作業として整理する必要があります
• 規格の版が2015年であることから、入力内容の学習への利用、出力の権利、モデルの差し替えといったAIに固有の論点は欄の外にあります。これらは規格への適合とは別に、契約と確認票の側で確かめる必要があります

まとめ

27017は、クラウドを安全にするための独立した規格ではありません。情報セキュリティの管理策の本体があり、その欄をクラウドサービスで使う場合に読み替える手引と、クラウドにしかない7つの追加の管理策を足した層です。2015年に国際規格として発行され、対応する日本産業規格は2016年の版です。だから単独では読めず、本体の一覧を横に置いて欄ごとに突き合わせる読み方になります。「27017に対応していますか」という問いが噛み合わないのは、規格番号だけがやり取りされて、本体のどの欄の話かが特定されていないからです。この規格のいちばん独特な作りは、1つの欄に利用する側と提供する側の2つの文が並んでいることです。資産の目録の欄では、利用する側はクラウド環境に置いた情報と資産を目録に含め、提供する側は預かったデータとサービス由来のデータを分けて明記します。だから、読む前に自社の立場を決めます。認証の適用範囲にも、どちらの立場かを明確にすることが求められています。両方にあたるなら、最初から2列の表にして同じ欄を2回読みます。追加の7つは性格が2つに割れます。役割の分担、資産の除去、管理者の運用、サービスの監視は契約と運用の取り決めなので、相手に求めれば確かめられます。分離、要塞化、ネットワークの整合は相手の内部の作りなので、自分では見に行けません。だから前者は個別に聞き、後者は認証の範囲に自社が使う環境が入っているかで代替します。AIサービスの審査で先に開くのは前者の4つで、中でも資産の除去がいちばん効きます。入力した文章、やり取りの履歴、不正利用を見つけるための記録は、消える時期がそれぞれ違うからです。聞くときは対象、時期、方法、証跡の4つに割ります。認証があることは安全の証明ではありません。限界は範囲と時点と版の3つで、AIの審査では版がいちばん効きます。2015年の規格に、入力内容の学習への利用、出力の権利、モデルの差し替えを置く欄はありません。認定機関が2024年3月11日に公表した資料ではクラウド固有の認証の登録数が500件を超え、2024年12月27日の資料では本体の認証が8,000件を超えています。時点がずれるので割り算はできませんが、持っていない相手を一律に落とす根拠にはならない分布です。AIに任せてよいのは、資料を読ませて管理策の欄に対応づけること、確認票の下書き、答えていない箇所の指摘までで、根拠となる記述を必ず併記させます。可否と、範囲外の環境を使う条件と、止める判断は人が決め、決めた人の名前を残します。次の一手は規格そのものを買うことではありません。いま社内で使っているAIサービスを契約の単位で並べ、それぞれについて、契約が終わった後に何がいつ消えるかを1行で書けるかを試してみる。書けない行が1つでもあれば、そこがこの規格を開く場所です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。