昨天談到 Permission。

就算我真的說：

「可以。」

還是要知道：

誰？

做什麼？

哪個 Scope？

什麼 State？

有效多久？

可以用幾次？

但把 Permission 拆清楚以後，我們又遇到下一個更麻煩的問題。

假設：

Permission 有。

Action 也在 Scope 裡。

可是到了真正要執行的那一刻，

System 突然發現：

Context 不完整。

State 對不上。

Authority 有衝突。

甚至不知道現在綁的是不是原本被授權的 Workflow。

這時候 AI 應該怎麼辦？

最直覺的做法可能是：

「大概沒問題，先做。」

但這正是我越來越不敢接受的事情。

因為：

在聊天裡猜錯，跟在 Action 裡猜錯，成本完全不同。

如果我問 Sol：

「這份文件大概是哪一版？」

她回答錯，

我可以再查。

但如果是：

「這個 Permission 還有效嗎？」

「現在這個 State 還是原本那個 State 嗎？」

「這個 Action 綁的是不是同一個 Workflow？」

這些問題如果靠猜，

後果可能是：

錯誤 Action 被放行。

舊 Permission 被重複使用。

新的 State 被舊 Context 誤判。

甚至未來 Physical World 裡真的控制到錯的目標。

所以我們後來很明確地採納一個治理原則：

Fail Closed

意思是：

當關鍵條件無法被安全確認時，

不自動放行。

不是：

「AI 永遠不可以做。」

而是：

證據不足、State 不清、Authority 不明時，先停。

我自己很喜歡把它跟另一種做法對比。

Fail Open

遇到不確定：

「先讓它過吧。」

「應該沒事。」

「大概就是這個意思。」

這種做法在低風險情境可能很方便。

但只要開始碰：

Production。

Authority。

Sensitive State。

Physical Action。

我就會很不安心。

所以對 Sol，我現在比較希望的是：

思考可以大膽。

行動必須保守。

這也是我們後來很常講的一句：

Think broadly. Act narrowly.

在 Reasoning 階段，

Sol 可以提出很多可能。

可以假設。

可以探索。

可以 Challenge 我。

可以想十種解法。

但到了真正要改變 State 的地方，

Action Scope 必須非常窄。

例如：

Sol 可以說：

「我有三種可能解法。」

很好。

她可以分析：

A。

B。

C。

但如果最後只有 B 被 Human Approved，

那 Execution 不應該因為 A「看起來也合理」就順便做。

Reasoning 可以廣。

Execution 必須窄。

這個差異我覺得非常重要。

因為很多人擔心 Governance 會讓 AI 變得：

很笨。

很慢。

什麼都要問。

但我現在反而覺得：

Governance 應該限制 Action，不應該限制 Thought。

AI 可以想很多。

但真正執行時，

只走被授權的那條路。

所以 Fail Closed 並不是：

「一遇到不確定，整個 System 永遠停止。」

而是：

關鍵 Gate 不成立時，

不要假裝它成立。

例如：

Context Unknown

不知道現在是不是原本那個任務。

→ Stop.

State Conflict

UI 顯示一個 State，

Runtime 卻是另一個。

→ Stop.

Authority Ambiguous

知道有人說過「可以」，

但不知道是不是針對眼前這個 Action。

→ Stop.

Material Drift

原本授權時的條件，

跟現在已經明顯不同。

→ Stop and Re-evaluate.

我覺得這裡有一個非常重要的工程觀念：

Unknown 不應該偷偷被轉譯成 Yes。

Day 11 我們已經接受：

「不知道」是一個合法的 Evidence State。

Day 15 往前一步：

當這個 Unknown 會影響 Action，

它就應該成為：

Stop Condition。

這件事情未來到了 Physical AI 會更明顯。

假設有人說：

「把房間調舒服一點。」

如果 System 不知道：

現在到底有人嗎？

設備是不是 Maintenance Mode？

這個人有沒有 Authority？

目前能源限制是什麼？

那就不應該：

「先猜一個最舒服的設定。」

因為這不是文字生成。

它真的可能改變環境。

不過這裡我也要守住一條 Claim Boundary。

目前 Fail Closed 對我們來說是：

Governance Principle

並且已經進入我們的 Architecture / Sandbox Governance 思維。

但我不會寫成：

「Sol 現在所有 Runtime、所有 Tool、所有 Physical Action 都已經全面 Fail Closed Enforcement。」

還沒有。

這也是為什麼今天我要講的是：

治理原則已經確立。

不是：

Production Enforcement 已經全部完成。

我覺得這件事情其實跟人很像。

真正成熟的判斷，不一定是：

每次都敢做。

有時候反而是：

知道自己現在資訊不夠，

所以先不要做。

所以如果今天問我：

AI 什麼時候最讓我安心？

不一定是：

它永遠回答得很快。

有時候反而是：

它知道什麼時候應該說：

「這個 State 我現在無法確認，所以我不會自動執行。」

我會覺得這比：

「放心，我幫你處理好了。」

更值得信任。

而當我們採納 Fail Closed 之後，

下一個問題又出現了。

假設我直接對 Sol 說：

「停。」

看起來很清楚吧？

但如果同一時間有：

Workflow A。

Workflow B。

Tool Call C。

Background Process D。

那：

到底要停哪一個？

Day 16，

我們來談一個很生活化、但其實非常工程的問題：

我說「停」，AI 到底應該停哪一個 State？