導入 AI 的責任與邊界: AI 能拿多大的權、出事誰扛，以及當新系統開始吃掉舊場景時，怎麼不讓舊團隊被架空

前面 27 天，我一直在證明同一件事: AI 扛人類不可及這件事。 昨天 D28 也處理完了到底怎麼算。

今天是最後一個技術性的問題，也是最不舒服的那一個: 它一定會出錯，誰扛?

這題不能等到真的出事那天才想。等到那天，答案會自動變成「誰按下去的誰負責」——而那個答案在大多數情況下是錯的，還會順手毀掉你花了一整季建起來的信任。

先給我的結論: AI 的錯要靠設計把它關在可承受的半徑裡; 而照著設計好的流程做仍然出錯的時候，錯在設計，不在操作的那個人。 而同一套設計邏輯放大到組織層，就是這篇最後要處理的那題:

「當一個新系統真的開始吃掉舊場景，怎麼不讓舊團隊被架空」。

三問劃完界之後，還剩下哪一題?

D07 給過一組判斷基準: 這件事可逆嗎、結果可查證嗎、出事誰扛責? 三問決定一件事該給 AI 到什麼程度。而「什麼程度」不是開關，是一條橫軸的光譜:

• 輔助: AI 只給資訊與建議，人全程操作。
• 半自動: AI 出草案、出預警，人審核之後才生效。
• 全自動: AI 直接執行，人事後抽查。

三套上線系統各自站在哪一格，D07 其實已經劇透過了。這裡只把它擺成一張表，不重複講之前的東西:

三套沒有一套是全自動，而理由沒有一個是「技術做不到」。 全自動的部分技術上都做得出來。

但你會發現，三問全部是事前的判準——它幫你決定「這件事要不要交出去」。它回答不了事後: 交出去了、流程也照著跑了，錯還是發生了。

剩下的這一題，是今天的主題。

AI 一定會出錯，那該控制的到底是什麼?

不是錯誤率，是影響半徑。

這個轉換很重要，因為「把錯誤率壓到零」是做不到的事——D06 那篇已經用 WEBEX 的例子演過一次，那東西會用非常有自信的語氣講錯的話。你可以把錯誤率壓低，但你不能把它壓成零，所以拿它當防線的系統遲早會破。

能被設計的是另一件事: 當它錯了，那個錯最遠會跑到哪裡。 三套系統用的是同一組三道設計:

• 第一道，邊界。 用 prompt 把 AI 關在一個角色裡，只讓它做那個角色該做的事。D23 那句「當記者，不要當顧問」就是這道——它可以描述這條漏洞影響什麼，但不准建議客戶該怎麼處置。因為描述錯了會被下一個讀的人抓到，建議錯了會直接變成別人的動作。
• 第二道，抽驗。 人對 AI 的判讀做抽樣查證，不是全信，也不是全查。全信等於沒有防線，全查等於這套系統沒有存在的意義——抽驗是唯一能長期跑下去的那個中間值，而抽多少、抽哪幾種，是可以隨著它被驗證過幾次慢慢調的。
• 第三道，影響半徑。 這是最硬的一條: AI 的失誤最遠只能跑到「一版還要被人審的草案」為止，不能直接變成對外送出的文件、也不能直接變成設備上的變更。

第三道其實就是「事實靠程式、行文靠 AI」那條分工線(D20、D23)的權責版本。會被拿去當證據的那一半——料號對不對、價格是多少、這條漏洞影響的是不是這台——交給非LLM的確定性程式算;

AI 負責判讀與生成那一半，而那一半的產物永遠掛著「生成」兩個字。D27 那個用詞是刻意的，它在組織上的意思就是這句: 它的錯有一個天花板。

這裡順帶跟 D28 分工清楚，兩篇講的是不同的「壞掉」: D28 講技術上壞了怎麼不拖垮全部(某一塊掛了能降級續跑，不用人半夜起來救); 今天講權責上錯了誰負責、影響到哪。一個是可用性，一個是責任。

照著流程做，最後還是錯了——這時候誰扛?

直覺的答案是「簽名的那個人扛」。這個答案對，但只對一半，而漏掉的那一半正是企業導入 AI 真正卡住的地方。

出錯之後，先把它分成兩種:

• 第一種: 那個人看得到 AI 憑什麼這樣判、有足夠的時間看、而且他有權說不。他看過了、放行了，錯了——責任在他。這是正常的，也是他這個位置本來就該承擔的。
• 第二種: 他照著流程做了，但系統沒有給他判斷的依據、或者給了他卻沒有給他否決的權——他要嘛看不出哪裡不對，要嘛看出來了也擋不下來。這種錯了，錯在設計。

所以出錯之後，第一個該問的問題不是「誰按的」，是「這個流程，有沒有設計出給人擋下來的機會」。

而「有沒有給人擋下來的機會」可以拆成三個很具體、可以逐條檢查的條件，它們剛好就是這一路上一項一項交出去的東西:

• 他看得懂 AI 憑什麼這樣判嗎? 依據要跟結論一起出現。這是 D06 的教訓變成的規格——一個你查不動的判斷，等於要你替它背書。
• 他有權說不嗎? 系統說今晚該停機升級，他說今天不行，那就不行，而且不需要為了擋一個自動化流程去寫報告解釋自己(D07)。
• 他退得回去嗎? 舊的那條路還在、上游的資料還在他手上，他不需要任何人同意就能停下來(D13)。

三條缺一條，那個位置就不是負責的位置，是背鍋的位置。這也是我從 D07 一路講到今天的那句話最實際的收尾: 給責任的同時要給能力——而能力有一半是技術給的(把守不住的量接下來)，另一半只有組織給得起(讓他真的能說不)。

免責邊界要在事情發生之前寫下來，不是出事之後才拿出來講。 事後才宣布的原則對已經被檢討的人沒有意義，而且沒有人會相信第二次。

那當一個新系統真的開始吃掉舊場景，舊團隊會不會被架空?

先誠實講一件事: 我還沒有執行到這篇講述的階段。

D12 診斷完那件事之後，我給自己留了兩條約束——不打到他們的系統、不讓比較發生——D13 那整篇就是照著這兩條做出來的解法。目前為止的重疊，是被設計繞開的，不是還沒撞上。

所以這一節我不寫一份事後的檢討。原因很直接: 因為這篇的潛在讀者其實是能夠認出系統畫面的人員。

一份寫得再小心的覆盤，只要當事人讀得出來那是自己，它就不會是分析而是變成公開的評語——而那正是 D08 到 D12 花了好幾篇想化解的東西。

所以我在設計系統時，都特意擺入這些規則。 三條，全部是 D13 那套邀請框架往前延伸的版本:

• 不做一個更好的輪子，去當他那個輪子的第一個認真使用者。 他的系統仍然是那份資料唯一的真相來源; 我的應用只讀它，輸出走自己的出口。系統越成功，他那份資料被引用得越多——他不是被取代的人，他是上游。
• 重疊真的發生的時候，先動的是設計，不是人。 新的東西疊上去、舊的那條路留著跑(D13 的平行導入)，給的是時間跟位置: 讓那件事怎麼交接、交接到哪，是他一起決定的，不是他被通知的(D09 設計權的部門版)。
• 資料對不上的時候，判準永遠是他。 那些不寫在資料裡的例外、那些「這一筆為什麼長這樣」的來由，都在他身上。這個位置不是我讓給他的客氣，是只有他做得到。

至於這三條哪一天會被真的考驗到，我不知道。但把它寫在這裡，它就變成一份可以被拿出來對照的東西——包括被實際讀者拿出來對照。

所以，「取代」的到底是什麼?

把三系統的三種形狀擺在一起看，答案其實已經很清楚了:

• 設備分析是加法——這件事本來就沒有人做得到，它沒取代誰，是憑空長出一塊新的疆域(D21)。
• CVE 通報是做滿——漏洞管理本來就是人人在做的本質工作，AI 沒有取代它，是讓這件「該做卻永遠做不滿」的事，終於跟得上全球的規模(D24)。
• 下單報價最硬，因為那件事真的有人在做——而 AI 接走的是「湊料號、比即時價」那段誰做都累的苦工，人回到懂客戶、會談判、敢簽名那半(D27)。

三種方向不一樣，但呼應的是底下同一句: 被換掉的是舊的做事方式，不是做事的人。

部門對立的根因，就是這兩件事被讀成同一件: 人把「我這套系統、我這套流程被取代」聽成了「我這個人被取代」。 而這個誤讀不會因為你不提就消失——它得靠設計去拆: 平行導入讓舊路還在、上游仍然是他、交接的方式他有份參與。這些都是設計問題，不是情緒問題，用「你想太多」是打發不掉的。

D27 已經在個人層講完一次: 那個業務沒有被取代。今天在組織層把它收齊: 當新東西疊上來，舊團隊要換的是位置，不是被抽掉。

至於換過去之後要拿那個位置做什麼——那件事每個組織都不一樣，而你比我清楚你的團隊手上還缺什麼。

文末結論——一頁權責與失誤邊界

• AI 的權限是光譜，不是開關: 站在輔助/半自動/全自動哪一格，由 D07 三問決定，不是由技術上限決定——三套上線系統沒有一套是全自動，理由沒有一個是「做不到」。
• 要控制的不是錯誤率，是影響半徑: 錯誤率壓不到零; 能設計的是「錯最遠跑到哪」——邊界(關在角色裡)、抽驗(不全信也不全查)、影響半徑(最多停在一版待審草案)。
• 會被當證據的那一半，不給 AI 碰: 事實靠確定性程式、判讀與行文靠 AI——這條分工線就是失誤天花板的技術實作。
• 出錯後第一個問題是「這流程有沒有給人擋下來的機會」，不是「誰按的」: 看得到依據、有權說不、退得回去——三條缺一條，那就不是負責的位置，是背鍋的位置。
• 照流程做仍然出錯，錯在設計不在操作者: 而這條免責邊界要寫在出事之前，出事之後才講的沒有人會信。
• 架空是設計問題，不是情緒問題: 平行導入給時間與位置、上游仍然是他、交接他有份參與; 至於位置換過去之後怎麼發揮，由人自己選，不是被安排。
• 取代的是舊場景，不是人: 個人層 D27 已經證過，組織層在這裡收齊。

到這裡，該給 AI 多少權、錯了怎麼收、人要拿到什麼才守得住——這一季欠的設計面問題都答完了。

明天 D30，我把 30 篇拉出來逐條對帳: 開賽時開的每一張支票——兩個承諾、三道人力牆、三條讀者路線——到底兌現了沒。然後把這一路跑通的東西，正式交到你手上。