要約

  • 9月24日のIESG議題には、IRTFのNMRGによる draft-irtf-nmrg-ai-challenges-06 のRFC 5742に基づく衝突審査が入っている。予定する文書区分はInformationalで、IETFの標準案ではない。
  • 回答案 -00 には無衝突という結論案と、AIへの攻撃と危険な出力を区別する注記があった。24日の -01 は結論案を残し、注記を削除した。DatatrackerはなおIESG Evaluationと未解消のDISCUSSを示す。
  • 学習データを守る試験と、AIが実行を求める設定変更の上限を守る試験は別々に必要だ。いずれも現時点でIESGが認証したわけではない。

回線にない帯域を割り当てようとする指示は、学習データが汚染されていなくても出せる。一方、巧妙に細工されたデータでトラフィック分類器が誤認するなら、設定値の上限だけを調べても攻撃の経路は見えない。どちらも運用現場では「AIが間違えた」に縮められがちだが、調査する対象は入力と出力に分かれる。止める仕組みも一つでは足りない。

区別は一度、IESGの回答案にも姿を見せた。-00 はNMRG草案とIETF作業は衝突しないと提案し、IRSGで出た9.2節と9.3節に関する意見を検討するよう求めた。履歴によれば、Mohamed Boucadairは無衝突という主結論に同意する一方、この回答でIRSGのコメントへの対応を要求することには反対し、Tommy Jensenも賛同した。24日の -01 は注記を除き、主結論案だけを残した。この順序だけで修正の全理由を断定できないし、IESG EvaluationとDISCUSSが残る以上、最終決定とも呼べない。二種類の危険は現在の回答案ではなく研究草案に残っている。

9.2節は学習データへの毒入れ、分類をすり抜ける操作、学習情報の推測など、AIそのものへの攻撃を扱う。9.3節はAIの出す結果に目を移し、アクセス方針を損なうフィルタ表の変更や、物理回線の能力を超えるQoS配分を挙げる。後者の問題に必要なのは、モデルが自信を持ったかどうかではなく、装置の状態と権限に照らして命令を拒める境界だ。草案には段階的な操作と巻き戻しの議論もあるが、特定製品で検証された証拠ではない。

RFC 5742の役割は、IRTFなど別の出版経路の文書とIETFの作業との衝突を調べることに限られる。NMRGの研究上の合意があっても、それはインターネット標準の承認とは異なる。提案された無衝突回答が将来成立しても、AI制御装置の安全性、実地導入、障害の有無について何も証明しない。今回確認できる資料には、そのような実装や事故の記録はない。

運用者がこの研究を参照するなら、Daniel Kadeは二枚の確認票を勧める。一枚はデータとモデルを誰が変更できるか、毒入れや回避をどう試したか。もう一枚はAIに許す設定操作、独立して確認する容量・方針の上限、停止条件、巻き戻した後の実際の状態だ。これは編集上の提案で、IETFの新しい義務ではない。研究を現場に持ち込む判断を、狭い手続き上の回答に肩代わりさせないための記録である。

Sources