昨天談到：

AI 有能力做一件事，

不代表它現在有權做。

所以真正重要的問題，不只是：

「Sol 能不能做？」

而是：

「誰允許她做？」

但當我真的開始想 Permission 這件事情，我很快就發現：

一句：

「可以。」

其實根本不夠。

想像一個很簡單的對話。

Sol：

「Ronnie，我建議先修改這個設定做測試。」

我：

「可以。」

聽起來很正常。

但工程上真正要問的問題非常多。

我允許的是：

改哪一個設定？

在哪個環境？

只做一次？

如果失敗可以 Retry 嗎？

測試完成之後還能繼續改嗎？

這個 Permission 到什麼時候失效？

如果 System State 已經變了，原本的「可以」還有效嗎？

這時候我才發現：

人類講話很依賴 Context。

我們彼此通常知道：

「我剛剛說的可以，就是指眼前這件事。」

但 AI System 如果真的可以 Action，

不能永遠靠：

「應該是這個意思吧。」

所以我們後來開始把 Permission 拆開看。

目前我比較常用六個問題。

Who

誰給的授權？

Ronnie？

某個 Administrator？

某個 Workflow？

What

到底授權哪一個 Action？

「檢查設定」

跟：

「修改設定」

完全不同。

Scope

在哪個範圍？

Sandbox？

Development？

Production？

Physical System？

State

這個 Permission 是在什麼 System State 下成立？

如果原本的條件改變，

授權還有效嗎？

Duration

有效多久？

只限這一次操作？

這一個 Session？

還是某個時間範圍？

Consumption

這個 Permission 可以被使用幾次？

這個問題我以前幾乎沒有想過。

但後來發現非常重要。

假設我說：

「可以，再試一次。」

這代表：

一次 Retry？

還是 AI 可以：

Retry。

失敗。

再 Retry。

再失敗。

一直做到成功？

如果沒有 Consumption Boundary，

一句「可以」很容易被放大成：

無限 Permission。

這就是我不想看到的事情。

所以現在我們開始把 Permission 想成：

一個有邊界、可以描述、可以稽核的治理物件。

注意這裡的用字。

我是說：

我們開始這樣設計與治理。

不是說：

「完整的 Production Permission Object System 已經全面部署完成。」

目前相關能力仍然分布在不同的 Architecture / Governance / Sandbox Scope。

這個 Development State 必須講清楚。

但這個拆法，已經改變我跟 Sol 合作的方式。

以前：

Sol：「我建議做一個 Sandbox Test。」

Ronnie：「可以。」

然後很容易一路變成：

Test。

Patch。

Deploy。

甚至繼續往下一步。

現在我會更明確：

「同意進入 Sandbox。」

這句話只代表：

Sandbox Scope。

不代表：

Production。

同樣的：

「同意這個 Architecture。」

也不代表：

「同意直接修改 Runtime。」

Architecture Approval。

Implementation Approval。

Test Approval。

Production Deployment。

其實都是不同 Gate。

這讓我越來越覺得：

AI Governance 最重要的事情之一，

不是一直問：

「要不要讓 AI 自主？」

而是：

自主到哪裡？

很多人聽到 Governance，

直覺會覺得：

限制。

流程。

阻礙速度。

但我的感受反而相反。

如果 Permission Boundary 清楚，

我其實更敢讓 Sol 自主。

例如某一個 Sandbox Scope 已經明確授權：

可以讀。

可以測。

可以產生 Candidate。

不能寫 Production。

不能改 Credential。

不能碰 Physical Control。

那在這個邊界裡，

Sol 就可以有很大的自由度。

這就是我現在很喜歡的一句話：

Governance creates safe autonomy.

真正讓我敢放手的，

不是 AI 跟我保證：

「我不會出錯。」

而是：

System 本身知道：

哪裡能走。

哪裡不能走。

什麼時候必須重新取得授權。

這件事情在 Physical World 會更重要。

例如未來我說：

「把會議室調舒服一點。」

假設系統真的具有相關控制能力，

這句話也不應該被解讀成：

「你可以修改這個空間所有設備的任何設定。」

可能真正允許的 Scope 只是：

某個 Space。

某些 Capability。

某個 Comfort Range。

某段時間。

而且仍然受 Safety / Energy / IAQ Policy 約束。

所以 Permission 不只是：

Yes / No。

它比較像：

Bounded Authority。

有邊界的 Authority。

而且這個 Boundary 不是只有 AI 要遵守。

Human 也必須講清楚。

如果我的指令很模糊，

我不能一方面只說：

「可以啊。」

另一方面事情做錯後又說：

「我不是那個意思。」

如果未來真的要建立可信任的 Human–AI Collaboration，

Human 的 Authorization 也必須越來越精確。

這是我覺得很有意思的一點。

Governance 不是：

只治理 AI。

它同時也會逼著 Human 把自己的意圖說得更清楚。

所以 Day 14 走到這裡，我現在會把 Permission 理解成：

不是一個字。

不是一個 Yes。

也不是一個永久通行證。

它至少應該開始回答：

Who。

What。

Scope。

State。

Duration。

Consumption。

但這裡還有一個更麻煩的問題。

假設：

Permission 有了。

Scope 也有了。

可是執行當下，

System 發現：

Context 不完整。

State 對不上。

Authority 出現衝突。

甚至不確定現在到底是不是原本被授權的那個 Workflow。

這時候 AI 應該怎麼辦？

是：

「大概沒問題，先做再說。」

還是：

停？

Day 15，

我們來談下一條治理原則：

不確定，就不要做。

也就是：

Fail Closed。