EU AI Act 監査準備：あなたの AI ランタイムは証拠を出せるか
AI 判断の完全な記録を求められたとき、モデル品質だけでは足りない。ランタイムは認可、証拠、監督、監査履歴を示せなければならない。
結論から言うと： 監査が問うのはあなたのモデルではない。それぞれの AI のアクションを誰が認可し、何を変更し、その証拠はどこにあるのかを、あなたのランタイムが示せるかどうかだ――そして監査可能性は後から付け足すことはできず、起きたその瞬間に記録しておくしかない。
ある会議室を思い浮かべてほしい。
ヨーロッパで事業を展開する保険会社が、外部監査人を招いて AI Act のコンプライアンス予行演習を行った。監査人は席に着き、パソコンを開き、世間話もなしに、最初の問いを発した。
「先月、AI が自動で『高い不正リスク』とフラグを立て、その結果として支払いを拒否した請求について、その経緯を丸ごと出して見せてほしい――誰が起動し、AI はどのデータに基づき、どのルールを使い、誰が再審査し、顧客の異議申し立てはどんなプロセスをたどったのか。」
そして部屋は静まり返った。
この支払い拒否が必ず誤りだったからではない。この判断の中で AI が関与したその一部分が、システムの中に、完全で、連続していて、否認できない形で取り出せる場所が一つもなかった からだ。請求データは一つのシステムに、AI のスコアリングサービスは別のシステムに、再審査の記録は三つ目に、しかも人手の操作と同じ帳簿には乗っていない。監査人の求めるあの一本の線をつなぎ合わせるには、三つのチームが三日かけてログを掘り返さねばならず、それでもつなぎ合わせられる保証はない。
この会社はこのとき罰せられなかった――それはただの予行演習だったからだ。だが AI Act の罰則枠組みは、全世界売上高に対する割合 で計算され、どの会社も真剣に受け止めるに足る桁になる。そして予行演習が露呈させた問題は、本番の監査でそっくりそのままもう一度問われるものだ。
この静まり返った会議室こそ、AI Act の義務が段階的に適用されていくなかで、多くの企業が準備すべき場面だ。
カウントダウンは本物だが、段階的だ
EU AI Act は一つの締切ではない。2024 年に発効し、その後段階的に適用されている。すでに適用されている義務もあれば、透明性やガバナンス関連の義務は 2026 年 8 月ごろにかけて段階的に進み、高リスクシステムには別の実装スケジュールがある。2026 年 6 月には、EU が Cloud and AI Development Act（CADA）も提案し、クラウドと AI の主権にも注目が集まった。ヨーロッパに事業がある、あるいはヨーロッパの顧客にサービスを提供する企業にとって、重要なのはカレンダー上の一日ではない。監査人が一つの具体的な AI 判断を求める前に、監査可能性が存在していることだ。
実務上の問いは単純だ。あなたのチームは、90 日以内に独立した AI ガバナンス監査に耐えられるだろうか。コンプライアンスをやりたくないのではない。いざあの会議室に入ると、記録を出せない企業が多いのだ。
監査が見るのはモデルではなく、ランタイムだ
多くのチームがコンプライアンスのために最初にやることは、モデルの評価だ――認証はあるか、有害な出力をしないか。これらも重要だが、監査の主戦場ではない。規制が本当に求めているのは、AI が業務に触れるたびの動作 について、三つのことをはっきり言えるかどうかだ。
| 監査人が問うこと | それが調べていること | 答えられない場合の帰結 |
|---|---|---|
| これらのデータの処理は合法か? | データはどこにあり、誰が読め、EU 域外に出たことはあるか | データレジデンシー違反、CLOUD Act への露出 |
| この動作は誰が AI に認可したのか? | 支払い拒否や融資実行といった動作は、誰の権限で算定されるか | 責任の帰属が不可能、動作が制御不能 |
| AI が関与したそのステップは痕跡を残したか? | 完全で、否認できない証拠の連鎖を出せるか | 監査は即座に失敗 |
どの問いもモデルに関するものではない。すべてが、モデルの外側のあの層――データを担い、権限を強制し、証拠を記録するランタイム――に関するものだ。
AI Act は「高リスクシステム」に何を求めているのか
これは抽象的な「コンプライアンスせよ」ではない。AI Act は高リスク AI システム(請求処理、与信、採用、重要インフラといったもの)に対して、いくつかの硬い義務を名指しで列挙している。一条ずつ照らし合わせる価値がある――それらがほぼすべて、モデルではなくランタイムに落ちるからだ。
| AI Act の要求 | どの層に落ちるか | モデルは提供できるか |
|---|---|---|
| イベントログの自動記録(追跡可能) | ランタイムの監査帳簿 | できない、モデルは痕跡を残さない |
| 人間による監督(重要な判断に介入でき、覆せる) | ランタイムの承認とフロー | できない、フローで強制するしかない |
| 判断の説明可能性(何に基づいたか) | ランタイムが記録した入力とルール | 部分的には、だが否認できない記録はランタイムにある |
| データガバナンス(出所、権限、レジデンシー) | ランタイムの権限とデプロイ | できない |
おわかりのとおり、モデルがどれほど強くても、この表のチェックは一つもつけられない。これこそ、これほど多くのチームが「モデルは真剣に選んだのにコンプライアンスを通過できない」根本原因だ――彼らは間違った層で力を入れている。規制が求めるものは、構造的にランタイムの上に生えている。
コンプライアンスツールを一つ買えばいいのでは?
最も自然な反応はこうだ。市場には「AI Act コンプライアンスプラットフォーム」が山ほどあり、ベンダーも自らのコンプライアンスを宣伝している。DPA を一通り結び、認証を一つ取れば、この件を外注できるのでは?
この道は一部を解決できるが、あの会議室の問題は解決できない。
コンプライアンスツールと認証がやるのは 記録と裏書き だ――それは規制当局に「我々にはプロセスがあり、ドキュメントがあり、データ処理契約がある」と告げる。だが監査人が求めるのは「プロセスがあるかどうか」ではなく、「この一件の完全な経緯を出してくれ」だ。ドキュメントは、ある具体的な一回の動作の合法性を証明できないし、DPA も『この支払い拒否は AI がどの権限に基づいて行い、誰が再審査したのか』に答えられない。 この種の証拠は、その動作を実際に実行したランタイムが、動作が起きたその瞬間に記録するしかない。ツールを買えば「制度の層」を管理する手助けにはなるが、「動作の層」は管理できない――そして監査は突き詰めると、いつもある一つの具体的な動作を問うのだ。
監査可能性は、後から足せない
ここから多くの人が気づいていない硬い道理が導かれる。コンプライアンスは Q3 に駆け込みで仕上げる一通のドキュメントではなく、システムが備えているか、備えていないかのどちらかである属性だ。
監査人が求めるあの証拠の連鎖は、動作が 起きるその瞬間 に記録されていなければならない。もしランタイムがそのとき記録していなければ、8 月までにどれほど突貫したところで、先月のあの支払い拒否の本当の経緯を生み出すことはできない――あなたにできるのは「再構築」だけで、再構築された記録は、監査人が一目で採用できないと分かる。
これこそ「まず AI を導入して、コンプライアンスは後で考える」が 2026 年に危険な賭けである理由だ。あなたが賭けているのは、監査がそのとき記録しなかった動作を問わないことだ。いったん問われれば、その期間のすべての AI 判断が、立証できない空白になる。
監査室に入る前に、まずこの五つの問いで自己診断しよう――どれか一つでも「はい」と答えられなければ、その項目があなたのリスクポイントだ。
- AI が関与した業務動作を適当に一つ選んで、その完全な経緯をその場で取り出せるか?
- 権限はランタイムが 強制 しているのか、それとも プロンプト に書いてあるだけか?
- 人と agent の動作は、同じ一冊 の監査帳簿に記録されているか?
- これらのデータと処理過程は、誰の 管轄権 の下に落ちているか?
- 問題が起きたとき、ある agent やある種の動作を ワンクリックで止め られるか?
なぜ「ルールをプロンプトに書く」ではこの関門を通れないのか
少なからぬチームは実はガバナンスをやっているのだが、場所を間違えている――プロンプトに書いているのだ。「あなたは現在のユーザーが権限を持つデータしか照会できない」「高リスクの請求は人手の再審査が必要」、普段は機能しているように見える。だがそれは監査を通れない。二つの理由、どちらも致命的だ。
第一に、プロンプトは提案であって、制御ではない。 それはモデルが「言うことを聞いてくれる」ことで効力を持ち、一度のジェイルブレイク、一つのカバーされていない境界で迂回される。監査人が「ある種の請求が必ず人手の再審査を経ることを、どうやって 保証 するのか」と問うとき、「プロンプトに書きました」はサインできる答えではない。
第二に、プロンプトは記録を生まない。 監査が求めるのは構造化された、否認できない証拠であり、プロンプトはそれを提供できない。
コンプライアンスが本当に要求するのは、ガバナンスを「プロンプトの中の提案」から「実行エンジンの中の強制」へ移すことだ――権限は読み書きのたびにランタイムが検証し、監査は動作の自然な副産物になる。
CADA 以後、「データはどこにあるか」が硬い指標になった――だがセルフホストは免罪符ではない
CADA はもう一つのことを表舞台に押し出した。データ主権だ。それは本質的にこう問う。あなたのデータと AI の処理過程は、誰の管轄権の下にあるのか? この問いは直接、デプロイの形態を指す。本物の業務データを読み取る AI ランタイムを、内部を見ることのできない、しかも CLOUD Act の管轄下にある外部の SaaS に委ねることは、新しいフレームワークの下ではますますサインしにくくなる。セルフホストはデータレジデンシー、第三者への露出、可視性を一挙に改善できる――セルフホストすべきは必ずしもモデルではなく、オブジェクト、権限、ツール、承認、監査証拠を担うあのランタイムだ。
だが正直に一言。セルフホストは免罪符ではなく、一つの取引だ。 ランタイムがあなた自身のインフラ上で動くとき、パッチ当て、鍵のローテーション、ログを失わないことの保証、事が起きたときのワンクリック遮断――これらの操作と立証の責任も、一緒にあなたの頭上に落ちる。あなたが手にするのは制御権で、その代償は責任だ。逆に、その責任を誰かに肩代わりしてほしいなら、たいていデータも一緒に渡すことを意味する。この帳簿にタダで手に入る側はない。どちらの代償ならあなたが担えて、サインできるか次第だ。
サインできるランタイムは、どんな見た目か
上の要求を裏返せば、それが検収のチェックリストになる。最も直接的な検証は、製品紹介を見ることではなく、それが監査人の求めるあの記録をその場で吐き出せるかを見ることだ。ObjectOS の上では、冒頭のあの支払い拒否を取り出すと、こんな一本のレコードになる。
{
"event": "claim.decision.update",
"actor": { "type": "agent", "on_behalf_of": "user:risk.bot.supervised" },
"object": "ins_claim/CLM-88231",
"decision": { "from": "pending", "to": "rejected", "reason_code": "fraud_high" },
"model_evidence": ["device_mismatch", "velocity_anomaly"],
"permission_checked": "claims_adjuster → allowDecide: true",
"human_review": { "rule": "fraud_high → 人手の再審査が必須", "by": "user:wang.adjuster", "at": "2026-05-12T09:40:55Z" },
"timestamp": "2026-05-12T09:31:02Z"
}このレコードには、誰が、何をし、AI は何に基づき、どの権限に該当し、誰が再審査し、いつ――すべてが入っている。それは後から足した工事ではなく、agent が監督下の身分でガバナンスされたツールを呼び出したとき、ランタイムがついでに残した一筆だ。人と agent は同じ権限エンジンを通り、同じ帳簿に記録する。業務定義(オブジェクト、権限、再審査フロー)は、あなたのリポジトリの中で diff が取れ、追跡できるメタデータだ――監査人が「どの種類の請求が人手の再審査を必須とするか」と問えば、答えは誰かの頭の中ではなく、フローの定義の中に書かれている。
結び
8 月まであと数週間。あの会議室に戻ろう。もし監査人が今この場で席に着き、先月のある AI 判断の完全な経緯を求めてきたら、あなたのシステムはその瞬間に、三つのチームが三日かけてログを掘り返すことなく、それを吐き出せるか?
答えられないのは、ほとんどの場合モデルが駄目だからではなく、ガバナンスが間違った層に置かれたからだ――プロンプトに入れられ、制度ドキュメントに外注され、ランタイムに落ちていない。それをランタイムに戻せば、あの証拠の連鎖は、あなたが必要とする前からそこにある。この件は後から足せない。今すぐ成立させるしかない。
npm i -g @objectstack/cli && os startある agent を、あるユーザーの身分でデータを一件変えにいかせて、それから監査記録を開いてみよう――監査人が求めるあの一本の線が、もともとそこにあるのが見えるはずだ。