上個月我用一個下午的時間,翻閱了三份被更頻繁引用的人工智能治理文件:歐盟《人工智能法案》(EU AI Act)、NIST 的《人工智能風險管理框架》(NIST AI RMF)以及某家大型實驗室發佈的一個安全框架。目標很簡單:找出“算力所有權”(compute ownership)在治理中具體出現在什麼地方。在這三份文件中,答案基本上是哪裏都沒有。
讓我印象深刻的並不是人們漏掉了它。問題在於,敘事方式本身讓它看不見。治理層面的討論把模型行爲當作可被控制的變量,而把基礎設施當作中性的背景——也就是承載 AI 發生的管道。這個假設悄悄地做了很多工作。
我找不到任何公告、也沒有找到更新紀錄(changelog)——在 API 回應標頭裡也沒有版本跳號。有某種東西改變了模型的推理方式,而那個改變在沒有明示的情況下,悄悄滲透到我產品建立在其上的所有流程。我的使用者比我更早察覺,而這個細節比問題本身更讓我介意。
這裡,AI 平台依賴開始與先前那些風險分道揚鑣。應用程式商店規則的變更會附帶文件。社群 API 的關閉會伴隨除役公告(deprecation notices)、日期,以及你能夠提前規劃的特定時刻。但當你產品中的智慧層寄居在別人的訓練流程裡,地面就可能不帶時間戳地挪動。他們內部的重新訓練決策會按他們的時程成為你產品的行為,且不必告訴你究竟什麼地方被改動了。
讓我感到困擾的是,我們的注意力已經變得多麼誤導。關於 AI 責任的學科正在增長:評估、審計、對抗測試。幾乎所有的焦點都集中在模型層。但模型並不是孤立運行的。路由決策、服務層更新、運行時的靜默配置更改,這些在模型卡上都沒有顯示,也不會在評估中浮現。我們把模型視爲一個穩定、可知的對象。而基礎設施讓這種假設變得脆弱,審計從未設計來捕捉這些問題。