身為系統架構師,我們常追求「自動化」與「端到端」的流暢感。想像一個場景:你剛完成了一套嚴謹的權限矩陣——定義了「六個角色、五類資源、四種動作」的白名單規則。為了確保新系統與舊數據相容,你回頭對歷史留痕紀錄進行了一次稽核掃描。
原本你預期會看到滿屏象徵合規的綠燈,甚至準備再次慶祝那些曾被列為「自動化轉型成功案例」的專案。然而,掃描結果卻令你驚出一身冷汗:那些曾經在內部會議上被公開表揚的高效率案件,在權限矩陣這面「照妖鏡」下,竟通通變成了紅色的重大安全違規。這正是權限管理最殘酷的真相:它不只是填寫幾張角色表,而是對「責任」邊界的最終審判。
在缺乏權限矩陣的治理真空期,「違規」往往披著「高效」的外衣。以案號 C-2026-0008 為例,在系統開發第 15 天時,這筆案件曾被我當作「端到端收官」的漂亮成果寫進文章。當時,案件從失敗(Failed)狀態迅速被重啟並獲得核准,流程極其順暢。
然而,當「六角色×五資源×四動作」的矩陣建立後,系統揭露了令人尷尬的真相:該案件是由流程負責人(陳潔如)重啟了案件,隨後竟然又「自行核准」了同一筆資源。在沒有職能分離(SoD, Separation of Duties)的約束下,這種「球員兼裁判」的操作看起來就像是完美的自動化。
> 架構師點評: 在缺乏矩陣定義的情況下,違規行為與成功成果在表面上幾乎無法區分。權限矩陣的核心價值,在於它強制拉開了「操作者」與「審核者」的距離。我們必須意識到:沒有權限矩陣,你所慶祝的高效率,可能只是因為防線蕩然無存。
在實務治理中,我們發現系統雖然勤奮地記錄了「留痕」,卻常因缺乏身份識別而導致溯源失效。在稽核案件 C-2026-0004 時,我們發現 actor(執行者)竟是匿名職稱「收件檢視人(虛構)」,導致案件從 Failed 變更為 Processing 的責任歸屬完全落空。
這裡存在一個具備諷刺意味的教訓:身為架構師,我在第 9 天走查時才剛寫下「交接要具名」的準則,卻在第 14 天建立種子資料時,親手犯下了這個錯誤。這讓我體會到,僅靠口頭要求是不夠的,必須建立 「具名名冊 (ROSTER)」與「白名單制 (White-list)」 作為第一道防線。
在導入 AI 代理(AI Agent)的架構中,權限矩陣必須劃定絕對的禁區。這不是為了限制技術,而是為了確保系統的公正性。我們在矩陣中寫下了最嚴肅的硬規則:
> AI 代理在任何資源上都沒有「核准權」與「編修權」。
這意味著 AI 絕對不能核准自己產出的結果,也絕對不能修改它據以判斷的原始知識庫內容。如果讓 AI 擁有修改「證據」或「規則」的權限,系統將陷入無法被稽核的黑洞。核准權,必須始終握在具名的人類手中。
在系統架構設計上,我們必須貫徹「說『不』與說『可以』是同一顆印章」的概念。這顆印章(核准權)與「修改權」必須絕對分離。
流程負責人雖然有權重啟(Restart)一個失敗的案件以確保業務持續,但他絕對不能同時擁有對該案件的核准權。這並非行政官僚的刻意刁難,而是一種架構上的互信機制。如果一個人既能修改內容,又能決定內容是否通過,那麼審核留痕將失去意義。透過權限矩陣強制區隔,才能確保流程中的每一個環節都有「第二雙眼睛(Four-eyes principle)」進行覆核。
當權限矩陣揭露了 C-2026-0004 與 C-2026-0008 這兩筆歷史違規時,我們面臨一個治理倫理的選擇:是否要修改這些紀錄以換取一份「乾淨」的報告?
身為架構師,我的答案是:「留痕不可變(Immutable History)」是系統治理的地基。 我們不應抹除過去的錯誤,而是採取以下行動:

權限矩陣的建立,標誌著系統從「能動就好」進化到了「按規矩動」。它為系統透明度做出了巨大貢獻,讓我們看清了每一個動作背後的權力邊界。
然而,矩陣僅僅定義了「誰能核准」,真正的挑戰在於核准發生的「現場」。這就是為什麼我們下一步必須建構「人工決策站」的原因——當高風險結果產出後,系統必須停下來,等待那個在名冊內、擁有權限、且具名的人類按下按鍵。
在追求自動化的過程中,我們是否在無意中交出了那顆代表「責任」的印章?在權限矩陣這面照妖鏡前,每位架構師都該捫心自問。