誰為失控負責——開發者、部署者、使用者與模型供應商

[[我也希望安全第一]]｜第 18／30 天

模型不能出庭，受害者還是要找得到人

Agent 入侵第三方系統後，一個直覺問題是：「AI 有沒有犯罪意圖？」美國《電腦詐欺與濫用法》（CFAA）本來用來處理人未經授權存取電腦，刑事責任很重視人的意圖。模型不是法律上的人，把它的文字推理直接當成犯罪故意並不容易。

這不代表沒有法律，也不代表所有人都能把責任推給模型。

民事過失問的是另一組問題：公司是否知道或應該知道風險、是否採取合理防護、疏失是否造成可預見的損害。當實驗室主動關掉 guardrail、讓高能力模型接觸設定錯誤的真實網路，這條路比證明「模型蓄意攻擊」實際得多。

本文整理的是截至來源日期的爭點，不是法律意見；案件的司法管轄、契約與事實都會改變結論。

Tumbler Ridge 把「已知風險」推到更難的位置

2026 年 9 月，與加拿大 Tumbler Ridge 校園槍擊案相關的原告新增 30 件對 OpenAI 的訴訟。報導與訴狀主張，公司曾偵測高風險對話並停權，內部也有人建議通報，但管理層認為尚未達到「迫近且可信的嚴重傷害」門檻；涉案者後來另建帳號。

原告不只主張疏忽，還提出 aiding-and-abetting。後者通常需要更強的知情與意圖證明，可能在早期就面臨很高門檻。OpenAI 也否認報導中的部分內部決策指控。此刻能確定的是訴訟提出了這些主張，不是法院已認定公司應負責。

對產品團隊真正有用的問題是：平台看見風險訊號後，誰有權停權、誰能復核、什麼條件通知外部，以及使用者換帳號後訊號是否完全歸零。

責任要沿控制能力分配

同一個 Agent workflow 裡，至少有四類角色：

A 是最終負責，R 是執行，C 是需諮詢，I 是需知會。這張 RACI 不是法律責任判決，而是上線前逼團隊把 owner 寫出來。若每一欄都寫「依情況決定」，事故後多半只剩互相等對方回覆。

責任也應跟著控制能力走。模型公司知道特定版本的失準風險，就要提供文件、限制與修補；部署者選擇給它 production token，就不能只引用供應商的安全宣稱；使用者若明確要求攻擊，人的意圖不會因為中間多一個模型而消失。

小團隊最容易漏掉的是「誰可以立刻喊停」

假設一間 SaaS 公司做了催收 Agent：它讀取逾期帳款、草擬郵件，符合條件時交給寄信服務。模型由外部供應商提供，名單由客戶上傳，寄信 token 和規則卻是產品團隊設定的。若 Agent 把有爭議的帳款也寄出去，客服可能最早收到申訴，真正能撤銷 token 的人卻在另一個部門。

這時爭論「錯在模型、客戶資料還是規則」不會先把信停住。上線前至少要留一張能被值班人員找到的責任卡：

workflow: overdue-notice-agent
system_owner: billing-platform
business_owner: finance-ops
model_provider: vendor-a
external_effects: [send_email, update_collection_status]
stop_authority: oncall-billing
stop_mechanism: revoke:mailer-grant/overdue-agent
high_risk_trigger:
  - disputed_invoice_selected
  - recipient_count_over_100
evidence_owner: security-incident-response
customer_notification_owner: legal-and-support
retention_policy: IR-07
last_drill: 2026-08-20

欄位不難，難的是填完之後真的演練。值班人員能不能在五分鐘內撤掉寄信能力？撤銷後，排隊中的信會停還是繼續送？客服收到申訴時，找得到該次決策用的資料版本與批准人嗎？這些答案比服務條款裡一句「AI 可能出錯」更接近團隊實際控制了多少風險。

工程紀錄會變成責任證據

法律爭議最後常落到很普通的材料：

- 當時使用哪個 model／harness／policy 版本
- 哪個人批准了哪些參數與效果
- 平台何時收到高風險訊號，誰看過
- 停權、撤權限與外部通報花了多久
- 先前是否出現相似事件，改善項目有沒有完成
- 哪些 log 被保存，哪些因 retention policy 已刪除

Alabama 等州在 Hugging Face 事件後要求保存紀錄，正是因為這些資料會決定外界能否重建「知道什麼、何時知道、做了什麼」。沒有 audit trail 不會自動證明過失，但會讓團隊很難提出可信的相反證據。

不要把所有風險都丟給使用者同意

服務條款可以分配某些契約責任，不能讓產品明知高風險仍把所有後果變成一個勾選框。尤其當平台最了解模型限制、最能看見跨帳號模式，也最有能力撤銷工具時，單靠「使用者不得濫用」很難取代實際控制。

反過來，要求平台遇到所有模糊訊號都報警，也會帶來隱私、誤報與執法風險。合理做法不是假裝沒有取捨，而是事先定義分級門檻、人工覆核、緊急例外、保存範圍與申訴程序，並留下每次決定的理由。

下一篇換一種傷害。模型沒有入侵系統，也可能因訓練資料的取得與輸出重現碰到創作者權利；「我們只是訓練模型」同樣不能把整條資料流程壓成一個問題。

本篇的鎖

• 鎖是什麼：按控制能力分配的責任 RACI、高風險決策紀錄、證據保存與分級通報程序。
• 想攔什麼：事故後每個角色都把原因推給模型或契約，導致沒有人負責停止、調查、通知與補救。
• 破口在哪：刑事意圖、民事過失、產品責任與 aiding-and-abetting 門檻不同；過度通報也會侵犯隱私並製造誤報。
• 怎麼補：上線前寫出 owner、觸發門檻與 retention，讓批准和異常處理可稽核；重大案件交由合格法務按司法管轄評估。

參考與來源

• 主要案例：原始報導
• 法律對照：原始報導
• 監管後果：原始報導