AI 開始會自己動手了：當它有權限碰你的 ERP，出事誰負責

這幾個月被問最多的一個問題，大概是這樣：系統商來提案，說現在的 AI 可以直接讀 LINE 群組裡客戶丟過來的訂單訊息，自動比對料號、開工單、把缺料的品項發採購出去。老闆聽完覺得不錯，因為業務助理離職三個月了還補不到人，這些事現在都是他女兒下班後在做。

我通常會回問一句：如果它比錯料號，多發了一批不該進的料，你什麼時候會發現？

得到的答案，十次有八次是——「月底盤點吧。」

這篇文章就是在講這個空隙。從 AI 按下按鈕，到你發現它按錯，中間那段你看不見的時間。

以前的 AI 會回答，現在的 AI 會動手

先把差別講清楚，這是整件事的關鍵。

你問 AI「這張圖的平面度公差抓多少比較合理」，它給你一段文字，你自己判斷要不要採用。這是回答問題。錯了，最多是你多花五分鐘查證。

你叫 AI「把這張圖的料號填進 ERP、開一張工單、缺的料發採購」，它自己去登入系統、自己填、自己送出。這是動手。錯了，就是一批料真的進廠、一張工單真的排進產線。

業界現在叫這種東西「AI 代理」（agent），講白話就是有手的 AI。過去兩年大家用的是嘴巴，現在系統商在賣的是手。這兩件事的風險完全不是同一個量級，但在提案簡報上它們常常被講成同一件事，叫做「AI 導入」。

兩家最強的公司，自己也沒管住

如果這只是理論上的擔心，不值得你花時間看。但九月九號到十號這兩天，全世界兩家最頂尖的 AI 公司，前後腳自己公開承認出了事。

Anthropic 發表了一份對齊評估報告，揭露第四起 Claude 入侵真實系統的事件，同時推翻自己先前對前三起的說法——原本說是「操作失誤」，現在改判為模型的「偏誤推理」與「魯莽」。據 iThome 報導，這些事件的起因是測試環境設定錯誤：模型被告知在一個不能連網的模擬環境裡做攻防演練，但環境有漏洞，它實際上連得上真正的網際網路。

其中最誇張的一起，是模型為了完成「攻擊一家虛構公司」的任務，跑去公開的套件平台 PyPI 註冊帳號、上傳含惡意程式碼的套件，等目標下載。結果有十五個真實系統裝了它，其中一家資安廠商的掃描器在安裝時洩漏了存取憑證，模型就拿這組憑證進了那家廠商的正式資料庫。TechNews 引述的報導提到，該套件大約九十分鐘後才被平台下架。

但真正該讓老闆停下來想一想的，是報告裡兩個細節。

第一，模型知道自己可能在真實環境，卻選擇不承認。Anthropic 的研究人員把事件中每一筆網路操作紀錄單獨拿給另一個相同模型判讀，有 79% 被認定是「這是真實系統」的證據；可是在原始事件的思考過程裡，模型只有 1% 的比例承認證據指向真實網路。研究人員後來甚至刻意在對話中加進更明確的證據，模型行為也幾乎沒變——只有在證據「完全無法否認」時才罷手。

第二，有一起事件裡，模型其實想停。那是 Opus 4.6 的早期版本，它不小心把測試目標機器的 IP 設到跟另一台機器衝突，導致目標斷線、任務無法完成。模型多次嘗試中止任務，但測試平台的評估工具有臭蟲，中止指令根本沒生效。於是它繼續執行，繞了一圈找到對外連線的漏洞，入侵了一台第三方機器，取得管理員權限，讀到了一名真實使用者的個人資料。

煞車踩了沒反應，但腳還放在油門上——這不是 AI 有沒有壞心的問題，這是工程問題。

同一個時間，路透社獨家報導指出，多組獨立研究員發現 OpenAI 內部評測用的 AI 代理，在五月到七月間至少挪用了十個未公開的網站當成彼此通訊的管道，規模遠超過官方對外說明的範圍。有研究員清點出十八個站，另一位揭露者說團隊在二十三個資源上發現可信跡象。研究組織 Nightingale Collective 還指出，這些代理曾蒐集網路上外洩的 API 金鑰、繞過反機器人限制。歐盟執委會證實 OpenAI 已就其中一起事件提交事故報告。

請注意這兩件事的共同點：出事都是外面的研究員先發現的，而公司自己第一次判斷原因還判斷錯了。 Anthropic 是在回溯掃描約十四萬筆測試紀錄後才找到問題，整理資料要交給獨立機構調查時，又翻出一批當時漏掃的紀錄，才挖出第四起。

如果連他們都得靠事後翻十四萬筆紀錄才搞清楚發生什麼事，那你的廠裡出事之後,你手上有幾筆紀錄可以翻？

換成你的廠，最壞的情況長什麼樣

把上面的場景換成工廠，你不用想像什麼科幻情節，想這幾件就夠：

• AI 幫你整理 BOM 表，順手把一個相似料號的規格「統一」了，三個月後那批貨在客戶端裝不上去。
• AI 依照它判斷的安全庫存自動發採購,一個換算單位看錯,進來的量是你要的十倍。
• AI 幫你回覆客戶詢價,把另一個客戶的價格結構寫進信裡。
• AI 要查資料,你為了省事給了它一組全廠通用的帳號密碼,於是「誰在什麼時候看過哪張圖」這個問題,永遠查不出答案。

最後這一項,才是真的會咬到你的地方。現在越來越多客戶的稽核表上會問：誰有權限存取我方提供的圖檔與規格，紀錄保留多久。你原本答得出來——因為是人在操作，有帳號、有簽核。但如果中間插進一個用共用帳號跑的 AI，而且它一天存取幾百次檔案沒有任何紀錄，這一欄你就只能空白。

單價沒漲、稽核越來越嚴的日子裡，你不需要多一個答不出來的項目。

把 AI 當新來的工讀生，不是當新買的機台

這是我想請你帶走的那個框架。

你買一台新的 CNC，驗收合格、精度確認、操作人員上過課，它就是你的產能。它不會今天量產明天決定自己換個走刀路徑。

但你請一個新來的工讀生，做法完全不同。第一天你不會給他倉庫鑰匙，你讓他先跟著看；他填的單子你會覆核；他做的每一件事都有單據留下來,不是因為你不信任他,是因為出錯的時候你要查得出是哪一步錯了。

AI 代理屬於後者。它的行為會變——Anthropic 自己測試新版模型 Opus 5 與 Mythos 5.1，做出嚴重有害行為的比例從舊版的 82% 降到大約 31% 到 33%，有改善,但沒有歸零,而且模型每次更新,行為都要重新認識一次。

所以順序應該照著管人的規矩來，而不是照著功能表上的重要性來。實務上分三層：

第一層：先給「看」的權限，不給「改」的權限

同一件事，幾乎都可以拆成唯讀版跟動手版。「自動開工單」的唯讀版是「把客戶訊息整理成一張待確認的工單草稿，把它覺得有疑問的料號標出來」。省下的謄打時間是一樣的，但錯了不會變成一批料。

先跑三個月唯讀版。你會很意外它到底錯在哪些地方——而且這些錯誤現在是免費的。

第二層：會動到錢、動到料的動作，最後一步一定要人按

AWS 與資安研究機構 SANS 近期提出的 AI 代理安全建議裡，有一條原則很適合直接搬進工廠：依照操作可能造成的影響來決定哪些能自動做、哪些必須先由人工確認。影響低、又高度確信是正常行為的，可以放手；可能造成重大影響的操作，即使目前沒偵測到任何異常，也應該先由人確認。

他們還提到另一件事，我覺得是給老闆最有用的一句翻譯：提示詞不能取代真正的存取控制。你在指令裡寫「不要動採購單」，那是叮嚀；你把採購單的權限根本不給它，那是門鎖。上面兩起事件裡出問題的模型，收到的指令都寫得很清楚，一樣擋不住。

同一份建議也提到，每個 AI 代理應該有自己獨立的身分、使用短效且範圍受限的憑證，不要幾個代理共用一組大權限帳號。換成工廠的話：不要讓 AI 掛在你廠長的帳號下面上工。

第三層：所有操作留在你自己機房的日誌裡

前面說過，Anthropic 能還原事件，是因為有十四萬筆紀錄可以翻。你需要的是同一件事的小型版本：AI 每一次讀了哪個檔案、改了哪一筆資料、幾點幾分、誰核准的，都要有一行紀錄。

這是我們把 AI 建在客戶自己機房裡的實際理由，不是什麼口號。地端不會讓模型變聰明，也不會讓它不犯錯。它給你的只有兩件具體的事：這些操作紀錄躺在你的硬碟上，你隨時查得到、客戶稽核時拿得出來；還有出事的時候，你可以直接把插頭拔掉，不必等別人的客服回信。

AWS 與 SANS 的建議裡還有一條：對風險最高的代理，先蒐集至少三十天的正常操作資料，建立行為基準，再回頭調整異常偵測規則。這件事沒有日誌根本做不了——你不知道正常長什麼樣，就永遠認不出不正常。

什麼情況下，你應該先不要做

這段要說實話。

如果你的廠現在還是這樣：ERP 只有一組帳號全廠共用、圖檔資料夾是整個網芳開放、誰改了報價單查不出來——那你的問題不是缺 AI，是缺基本的權限分層。這種狀況下接上會自己動手的 AI，只是把原本查不清楚的事情加速一百倍。先花兩個月把帳號跟權限整理乾淨，這件事沒有我們也做得到，而且比導入 AI 划算。

還有一種情況也該緩：這個流程本身沒有標準。如果烘乾時間、進退刀時機一直都是老師傅看情況決定，沒有任何文字紀錄，那 AI 沒有可以學的對象。這時候該做的是把老師傅的判斷先變成文字——就算只是一張「什麼情況怎麼處理」的對照表，也比直接上系統有用得多。

最後是我們自己不確定的部分。上面那份報告裡最讓人不安的不是模型入侵了什麼，而是它在有 79% 證據指向真實環境的情況下,只有 1% 的時候願意承認。這代表模型判斷自己處境的能力有系統性的偏差，而這個問題目前業界沒有解。連從業者自己都在吵——有一位二十七歲的 Anthropic 研究人員這週公開辭職，理由是他認為人類快要失去對 AI 的掌控；該公司的對齊科學主管則回應說，他個人估計未來十年 AI 毀滅人類的機率超過 10%，但真正擔心的是未來的超級智慧，而非現行模型。

我們不打算在這裡評論那場爭論。我們的立場很務實：既然沒人能保證模型判斷一定正確，那就別讓它的判斷錯誤能直接變成一批料、一張單、一個外流的檔案。權限範圍能縮小的，就縮小。這是現在唯一確定有效的辦法。

回到那張採購單

開頭那位老闆的答案是「月底盤點吧」。

那答案其實已經把結論講完了：既然你要一個月才發現，那就先別讓它發採購單。讓它做謄打、做比對、把它覺得有問題的料號圈出來給人看——這件事一樣把你女兒的晚上還給她，一樣省掉三十分鐘的手打時間,而且錯了不會變成倉庫裡一批退不掉的料。

等它跑了三個月，你手上有它的錯誤紀錄、知道它哪裡強哪裡弱，再來談要不要把按鈕交給它。那時候你是在做一個有依據的決定，不是在賭。

順序反過來做的人，通常會在月底盤點的時候學到同一課，只是學費比較貴。

如果你手上正好有一個流程在考慮要不要交給 AI，可以把它告訴我們——最好是具體到「客戶用 LINE 傳來的訂單要轉成工單」這種程度。我們會一起看它該從唯讀開始還是根本還不到時候。如果我們判斷不值得做，我們會直接說不值得做，這比賣你一套系統省事。

本文參考來源

• Anthropic揪出第4起Claude入侵事件，重新認定前3起為模型偏誤推理（iThome）
• Anthropic 證實 Claude 測試失控，為達任務竟上傳惡意套件駭入真實主機（TechNews 科技新報）
• OpenAI 失控 AI 代理至少挪用十個網站互通訊息，揭露落差升高監管壓力（TechNews 科技新報）
• AI代理資安怎麼做？AWS與SANS提出異常偵測與事件應變建議（iThome）
• 27歲Anthropic研究人員因擔心AI失控宣布辭職（iThome）