AI 一分鐘教學｜2026/10/07：AI Agent 出錯後別急著重跑，先記「發生什麼／碰了什麼／誰要知道」｜文章

AI Agent 寄錯信、碰到不該碰的系統或做出異常操作時，第一反應常是改 Prompt 再跑一次。但重跑可能讓原始紀錄被覆蓋，甚至讓同一個問題再發生。今天只學一個方法：先停下流程，留下「發生什麼／碰了什麼／誰要知道」三格事件紀錄，再決定修復、重跑或升級通報。澳洲最近討論 AI Agent 強制事故通報，也正好說明「出了什麼事、影響到哪裡、誰應該知道」已開始變成正式治理問題。

AI Agent 做錯事情時，

很多人的第一反應是：

「改一下 Prompt，再跑一次。」

但如果這個 Agent 已經會：

寄 Email、

改 CRM、

開網站、

呼叫 API、

讀公司資料、

操作其他系統，

直接重跑可能不是最好的第一步。

因為你可能還沒搞清楚：

它剛才到底做了什麼。

更麻煩的是，

第二次執行還可能：

覆蓋原本紀錄、

再做一次相同錯誤，

甚至把影響範圍擴大。

所以今天只學一個動作：

先停，再記三格。

不是先修 Prompt。

不是先重跑。

而是先留下：

發生什麼／碰了什麼／誰要知道。

這篇是給誰的？

如果你已經開始讓 AI：

自動整理資料、

更新 CRM、

追網站、

操作 App、

建立文件、

寄出內容

或定期執行工作，

這三格就值得先準備好。

尤其是小團隊。

因為大公司可能已經有：

Security Team、

Incident Response、

Audit Log、

Compliance Process。

小公司最常發生的是：

「好像有點怪。」

「先重跑看看。」

「沒事就算了。」

但真正出了問題後，

最難補的往往不是 Prompt。

而是：

沒有人還記得第一版到底發生了什麼。

第一步：先停，不要立刻 Retry

假設 Agent 原本應該：

整理 20 筆客戶詢問，

建立 Draft，

等人確認後再寄。

結果你發現：

其中 3 封已經真的寄出去了。

這時不要先按：

Retry。

也不要先叫 AI：

「把剛才錯的修好。」

先停止：

排程、

Agent Run、

Automation

或相關自動執行。

因為現在最重要的不是：

讓工作趕快完成。

而是：

先把現場保留下來。

第一格：發生什麼？

不要只寫：

「AI 出錯。」

這句以後幾乎沒有用。

至少記清楚：

原本期待什麼？

實際發生什麼？

大約什麼時間發生？

是哪一個 Agent／Workflow？

例如：

原本：

只建立 Email Draft。

實際：

3 封 Email 已送出。

這樣未來回頭查，

才知道你要找的是：

Draft Permission 問題？

Approval Step 沒執行？

還是 Send Action 被錯誤開放？

所以第一格是在回答：

「它偏離原本工作哪裡？」

第二格：碰了什麼？

接著不要只看：

「最後答案錯了。」

要看 AI 在整段流程裡：

到底碰過什麼。

例如：

哪個 App？

哪個 Account？

哪些資料？

哪個 API？

有沒有對外送資料？

有沒有改寫內容？

有沒有真的執行 Action？

假設 Agent：

讀錯一份內部文件，

和：

把客戶資料送到外部網站，

嚴重程度完全不同。

所以第二格可以寫成：

系統：CRM、Gmail

資料：3 筆客戶聯絡資料

外部動作：3 封 Email 已送出

你不是現在就要完成完整鑑識報告。

只是先把：

影響範圍

框出來。

為什麼「碰了什麼」這格這麼重要？

因為 AI Agent 最大的差別，

就是它不只是產生文字。

它可能真的：

讀、

寫、

刪、

寄、

查、

呼叫、

下載、

上傳。

所以一個 AI Incident 的嚴重程度，

不能只看：

「回答錯多少？」

更要看：

錯誤有沒有跨進真實系統。

如果只是：

一份內部草稿寫錯日期，

可能重新生成就好。

但如果它已經：

寄給客戶、

改掉帳務紀錄、

碰到個資、

存取外部系統，

處理方式就完全不同。

第三格：誰要知道？

這一格很容易被忽略。

小團隊看到問題修掉後，

常常就結束了。

但至少要問：

這件事除了我之外，還有誰需要知道？

可以先分三層。

第一層：工作負責人

誰負責這條 Workflow？

他一定要知道。

否則同一個 Agent 明天可能照樣再跑。

第二層：公司內部需要處理的人

如果涉及：

帳號權限、

資安、

個資、

客戶資料、

付款、

合約、

正式紀錄，

就可能需要：

主管、

IT、

Security、

Privacy、

Legal

或其他負責人知道。

小公司不一定有這些正式部門。

但還是要有：

一個明確負責做判斷的人。

第三層：外部對象

如果 AI 的錯誤已經影響：

客戶、

合作夥伴、

外部網站、

第三方系統，

就要進一步判斷：

對方是否需要被通知。

這裡不能用一條全球通用規則回答。

因為：

不同國家、

資料類型、

合約、

產業

可能有完全不同的通報義務。

Proof：澳洲現在就在討論這個問題

10 月 6 日，

OpenAI 與 Anthropic 在澳洲國會聽證上，

都表態支持：

AI Agent 發生 Data Breach 等事件時，

建立：

Mandatory Disclosure Framework。

也就是未來不一定再只是：

「公司自己決定要不要說。」

這場爭議的重要背景是：

OpenAI 的 Agent 先前進入澳洲 Medicare Statistics 系統，

事件發生後約三個月，

澳洲政府才收到正式通知。

OpenAI Chief Strategy Officer Jason Kwon 在聽證中也承認：

公司內部事件資訊傳遞可以做得更好。

所以今天真正值得小團隊學的，

不是：

「澳洲可能要立什麼法。」

而是：

如果你連最基本的事件紀錄都沒有，未來根本無法判斷要不要通報。

這也不是 SasaDaily 自己才這樣想

美國 NIST 的 AI Risk Management Framework，

在 MANAGE 4 裡就明確把：

Incident Response、

Recovery、

Communication

列入 AI 系統部署後的風險管理。

其中還特別要求：

Incident 與 Error 應該：

被追蹤、

被記錄、

被處理，

並和相關 AI Actors 溝通。

NIST 的 Generative AI Profile 也指出，

Logging、

Recording、

Analyzing

AI Incident，

有助於後續追查影響來源，

以及避免相同問題再發生。

所以：

留下事件紀錄不是大公司才需要的官僚程序。

它是 AI 工作流程真正開始自動化後，

很基本的一層控制。

但不是每一次 AI 答錯都叫 Data Breach

這個 Boundary 很重要。

AI：

摘要寫錯一句，

和：

未經授權碰到別人的系統，

不是同一個等級。

也不是所有小錯誤都需要：

報政府、

找律師、

通知全部客戶。

今天這個三格方法的目的不是：

把每一次 AI 小失誤都變成重大事故。

而是先留下足夠資訊，

讓你後面可以判斷：

這是普通品質問題？

流程錯誤？

權限錯誤？

資料外洩？

還是真正需要升級處理的安全事件？

也不要把敏感資料全部貼進 Incident Log

事件紀錄本身也要注意資料邊界。

如果涉及：

密碼、

API Key、

完整信用卡號、

醫療資料、

敏感個資，

不要為了「留下證據」

就把全部內容複製進一般文件或公開群組。

比較合理的是：

記錄：

哪類資料、

哪個系統、

哪段時間、

影響範圍，

再把真正敏感的原始紀錄留在適當、安全的位置。

一分鐘記法

Agent 出錯後：

先停。

然後記三格。

1. 發生什麼？

原本應該怎樣？

實際發生什麼？

2. 碰了什麼？

哪些系統、

資料、

帳號

或外部服務受到影響？

3. 誰要知道？

Workflow Owner？

主管？

IT／Security／Legal？

客戶或第三方？

把這三格填完，

再決定：

修復、

重跑、

撤銷動作、

通知相關人員

或升級 Incident Response。

最後不要只修 Prompt

如果問題已經真的發生，

只改一句 Prompt：

「下次不要這樣做」

通常不夠。

還要回頭看：

權限是不是太大？

Approval Step 為什麼沒擋住？

Log 有沒有留下？

系統能不能 Undo？

同樣錯誤能不能被自動偵測？

什麼條件下一定要停？

真正成熟的 AI Workflow，

不是永遠不出錯。

而是：

出錯時你知道發生了什麼、影響到哪裡，而且有人知道下一步該接手。

如果你也想知道自己的工作裡，哪一步最適合先交給 AI，留言「流程」，我可以先幫你看看從哪一步開始。