gen-zh-hant: ship 權限/實例 and the straddled locative 裡

content/blog/ai-agent-business-data-security-boundaries/index.zh-Hant.mdx

@@ -1,7 +1,7 @@
 ---
 # @generated zh-Hant from zh-Hans (s2twp) — edit the zh-Hans file; delete this line to hand-maintain.
-title: AI Agent 資料安全邊界：如何在企業許可權內工作
-description: 企業不是不想讓 AI agent 使用業務資料，而是不允許它繞過身份、許可權、審批和審計。真正可上線的 agent，必須像一個受控使用者，而不是影子管理員。
+title: AI Agent 資料安全邊界：如何在企業權限內工作
+description: 企業不是不想讓 AI agent 使用業務資料，而是不允許它繞過身份、權限、審批和審計。真正可上線的 agent，必須像一個受控使用者，而不是影子管理員。
 author: ObjectStack Team
 date: 2026-06-04
 status: published
@@ -12,10 +12,10 @@ industries: []
 cover: ./cover.jpg
 tags:
   - AI 智慧體
-  - 智慧體許可權
+  - 智慧體權限
 ---
 
-**先給結論**：可上線的 AI agent 必須像一個受控使用者：繼承使用者身份，許可權落到物件、記錄、欄位和動作；先只讀再執行，高風險動作要審批可回滾，每步可審計。真正的區別是：它是受控使用者，還是影子管理員。
+**先給結論**：可上線的 AI agent 必須像一個受控使用者：繼承使用者身份，權限落到物件、記錄、欄位和動作；先只讀再執行，高風險動作要審批可回滾，每步可審計。真正的區別是：它是受控使用者，還是影子管理員。
 
 很多企業討論 AI agent 時，第一反應是問：
 
@@ -25,44 +25,44 @@ tags:
 
 > 它以誰的身份訪問？能看什麼？能改什麼？出問題時能不能知道它做過什麼，並立刻停下來？
 
-如果這些問題沒有答案，agent 越聰明，風險越大。它會變成一個披著 AI 外衣的“影子管理員”：能跨系統查資料、能呼叫工具、能修改記錄，但不受任何人的崗位許可權約束。
+如果這些問題沒有答案，agent 越聰明，風險越大。它會變成一個披著 AI 外衣的“影子管理員”：能跨系統查資料、能呼叫工具、能修改記錄，但不受任何人的崗位權限約束。
 
-企業級 agent 的目標不是讓 AI 獲得超級許可權，而是讓它在清晰邊界內幫助使用者完成工作。
+企業級 agent 的目標不是讓 AI 獲得超級權限，而是讓它在清晰邊界內幫助使用者完成工作。
 
 ![AI Agent 的安全邊界](./security-boundaries.webp)
 
 ## 第一層邊界：agent 必須繼承使用者身份
 
-agent 不應該擁有一個獨立的萬能賬號，更不應該直接拿資料庫管理員許可權。
+agent 不應該擁有一個獨立的萬能賬號，更不應該直接拿資料庫管理員權限。
 
 它應該代表當前登入使用者行動。銷售只能看自己負責的客戶，agent 也只能看這些客戶；客服只能處理自己佇列裡的工單，agent 也只能在這個佇列內查詢和建議；工程師不能看合同金額，agent 也不能因為“需要分析”就繞過去。
 
 這條規則看似簡單，卻決定了整個系統是否可控：
 
 - 使用者離職，agent 的訪問能力隨之消失；
-- 使用者轉崗，agent 的可見範圍隨許可權變化；
+- 使用者轉崗，agent 的可見範圍隨權限變化；
 - 使用者無權訪問的記錄、欄位和動作，agent 也無權訪問；
 - 審計日誌可以把每次 agent 行為關聯回真實使用者。
 
-不要把這件事交給提示詞。提示詞可以提醒模型“不要越權”，但真正可靠的邊界必須由執行時許可權系統強制執行。
+不要把這件事交給提示詞。提示詞可以提醒模型“不要越權”，但真正可靠的邊界必須由執行時權限系統強制執行。
 
-## 第二層邊界：許可權要落到物件、記錄、欄位和動作
+## 第二層邊界：權限要落到物件、記錄、欄位和動作
 
-企業許可權不是一句“允許訪問 CRM”就夠了。
+企業權限不是一句“允許訪問 CRM”就夠了。
 
 一個安全的 agent 需要同時尊重四類邊界：
 
-**物件級許可權**：使用者是否能訪問客戶、訂單、工單、合同這些物件。
+**物件級權限**：使用者是否能訪問客戶、訂單、工單、合同這些物件。
 
-**記錄級許可權**：使用者能訪問哪些具體記錄，例如自己的客戶、所在區域的訂單、某個團隊的工單。
+**記錄級權限**：使用者能訪問哪些具體記錄，例如自己的客戶、所在區域的訂單、某個團隊的工單。
 
-**欄位級許可權**：使用者能不能看合同金額、成本、身份證號、內部備註等敏感欄位。
+**欄位級權限**：使用者能不能看合同金額、成本、身份證號、內部備註等敏感欄位。
 
-**動作級許可權**：使用者能不能建立任務、修改階段、關閉工單、傳送報價、調整折扣、變更許可權。
+**動作級權限**：使用者能不能建立任務、修改階段、關閉工單、傳送報價、調整折扣、變更權限。
 
-很多 agent 專案失敗，不是模型不夠好，而是許可權模型太粗。系統只知道“這個 agent 可以查客戶”，卻不知道它不能查所有客戶，不能讀取敏感欄位，不能執行高風險動作。
+很多 agent 專案失敗，不是模型不夠好，而是權限模型太粗。系統只知道“這個 agent 可以查客戶”，卻不知道它不能查所有客戶，不能讀取敏感欄位，不能執行高風險動作。
 
-ObjectOS 的思路是把業務物件、欄位、動作和許可權都變成宣告式後設資料。agent 不是直接碰表，也不是直接調任意 API，而是通過受控工具在這些後設資料定義的邊界內工作。
+ObjectOS 的思路是把業務物件、欄位、動作和權限都變成宣告式後設資料。agent 不是直接碰表，也不是直接調任意 API，而是通過受控工具在這些後設資料定義的邊界內工作。
 
 ## 第三層邊界：先只讀，再建議，再執行
 
@@ -76,7 +76,7 @@ ObjectOS 的思路是把業務物件、欄位、動作和許可權都變成宣
 
 **受控執行階段**：對低風險、邊界明確、可回滾的動作，agent 可以自動執行。例如建立內部任務、更新普通狀態、補全非敏感欄位。高風險動作仍然需要審批。
 
-這個分層很重要。它讓企業可以逐步擴大 agent 的許可權，而不是在“完全不用”和“全自動執行”之間二選一。
+這個分層很重要。它讓企業可以逐步擴大 agent 的權限，而不是在“完全不用”和“全自動執行”之間二選一。
 
 ## 第四層邊界：高風險動作必須審批和可回滾
 
@@ -86,10 +86,10 @@ ObjectOS 的思路是把業務物件、欄位、動作和許可權都變成宣
 - 批次修改客戶、訂單、合同、庫存或財務資料；
 - 修改金額、折扣、賬期、信用額度；
 - 對外發送正式郵件、報價、合同或通知；
-- 修改角色、許可權、組織關係；
+- 修改角色、權限、組織關係；
 - 呼叫會產生真實成本的外部服務。
 
-這些動作不能只靠模型判斷“應該沒問題”。系統需要在執行前展示影響範圍、原因和差異，讓有許可權的人確認。
+這些動作不能只靠模型判斷“應該沒問題”。系統需要在執行前展示影響範圍、原因和差異，讓有權限的人確認。
 
 同時，系統要記錄執行前後的狀態。出錯時至少能撤銷、補償或人工恢復。如果 agent 一次準備改 500 條記錄、命中敏感客戶、超過金額上限，系統應該自動剎車並升級給人。
 
@@ -112,14 +112,14 @@ ObjectOS 的思路是把業務物件、欄位、動作和許可權都變成宣
 - 執行前後資料如何變化；
 - 哪些步驟失敗、越權或升級審批。
 
-審計不是事後甩鍋，而是讓團隊有能力逐步放寬許可權。沒有審計，企業只能保守地把 agent 關在業務系統外面。有了審計，IT 和業務團隊才能知道哪些場景已經穩定，哪些場景還需要人守著。
+審計不是事後甩鍋，而是讓團隊有能力逐步放寬權限。沒有審計，企業只能保守地把 agent 關在業務系統外面。有了審計，IT 和業務團隊才能知道哪些場景已經穩定，哪些場景還需要人守著。
 
 ## 一個判斷標準：它是受控使用者，還是影子管理員？
 
 評估一個企業 agent 架構，可以問 6 個問題：
 
 1. agent 是否以真實使用者身份執行？
-2. 它是否繼承物件、記錄、欄位和動作許可權？
+2. 它是否繼承物件、記錄、欄位和動作權限？
 3. 它是否通過受控工具訪問資料，而不是直接讀取整庫？
 4. 它是否支援只讀、建議、執行的分級授權？
 5. 高風險動作是否需要審批、可回滾、可剎車？
@@ -131,8 +131,8 @@ ObjectOS 的思路是把業務物件、欄位、動作和許可權都變成宣
 
 ObjectOS 預設接受一個現實：真正有價值的 AI 一定會進入業務系統。
 
-它需要讀客戶、訂單、工單、合同和審批；它需要理解業務物件之間的關係；它也需要在授權後推動流程。但它不能繞過企業已有的身份、許可權、審批和審計。
+它需要讀客戶、訂單、工單、合同和審批；它需要理解業務物件之間的關係；它也需要在授權後推動流程。但它不能繞過企業已有的身份、權限、審批和審計。
 
-所以 ObjectOS 把物件、欄位、流程、許可權和動作都放進統一後設資料層，讓 agent 通過這層結構工作。AI 能更接近真實業務，同時每一步都有身份、有邊界、有記錄。
+所以 ObjectOS 把物件、欄位、流程、權限和動作都放進統一後設資料層，讓 agent 通過這層結構工作。AI 能更接近真實業務，同時每一步都有身份、有邊界、有記錄。
 
 企業不缺會聊天的 AI。企業缺的是能安全使用業務資料、能被授權、能被審計、能隨時停下來的 AI。

content/blog/ai-agent-workbench/index.zh-Hant.mdx

@@ -1,7 +1,7 @@
 ---
 # @generated zh-Hant from zh-Hans (s2twp) — edit the zh-Hans file; delete this line to hand-maintain.
 title: AI Agent 工作臺：讓 agent 在業務系統內受控執行
-description: 企業 agent 不能只是會聊天，而要能在業務物件、工具、許可權、審批和審計邊界內執行任務。工作臺的關鍵是受控執行，而不是萬能許可權。
+description: 企業 agent 不能只是會聊天，而要能在業務物件、工具、權限、審批和審計邊界內執行任務。工作臺的關鍵是受控執行，而不是萬能權限。
 author: ObjectStack Team
 date: 2026-06-05
 status: published
@@ -13,18 +13,18 @@ cover: ./cover.png
 tags:
   - 受治理的工具
   - AI 智慧體
-  - 智慧體許可權
+  - 智慧體權限
 ---
 
-**先給結論**：企業 Agent 的關鍵不是聰明，而是能不能受控執行——把物件、工具、許可權、審批和審計做成後設資料，Agent 才能在邊界內真正辦事，而不只是會聊天。
+**先給結論**：企業 Agent 的關鍵不是聰明，而是能不能受控執行——把物件、工具、權限、審批和審計做成後設資料，Agent 才能在邊界內真正辦事，而不只是會聊天。
 
 很多企業已經有了 AI 聊天入口，但真正的問題很快會出現：聊完以後，業務還是要人去系統裡操作。
 
 使用者問“哪些客戶有續約風險”，AI 能回答；但要建立跟進任務，還要切 CRM。使用者問“這份合同有哪些風險”，AI 能總結；但要發起審批，還要去合同系統。使用者問“哪些工單快超時”，AI 能列出來；但要轉派、升級、通知負責人，還要人工處理。
 
 所以企業下一步需要的，不只是聊天助手，而是可執行任務的 AI 工作臺。
 
-它不是讓 Agent 拿到管理員許可權到處亂跑，而是把業務物件、工具、許可權、審批和審計放在同一個執行邊界裡。
+它不是讓 Agent 拿到管理員權限到處亂跑，而是把業務物件、工具、權限、審批和審計放在同一個執行邊界裡。
 
 你可以對平臺說：
 
@@ -48,7 +48,7 @@ tags:
 
 所以企業 Agent 的核心不是“模型有多聰明”，而是“它能不能在業務系統的邊界裡執行”。
 
-這要求 Agent 工作臺必須後設資料驅動。業務物件定義它能理解什麼，工具定義它能做什麼，許可權定義它能代表誰做，審批定義哪些動作要確認，審計定義事後如何追蹤。
+這要求 Agent 工作臺必須後設資料驅動。業務物件定義它能理解什麼，工具定義它能做什麼，權限定義它能代表誰做，審批定義哪些動作要確認，審計定義事後如何追蹤。
 
 ## 用自然語言生成 Agent 工作臺
 
@@ -70,7 +70,7 @@ tags:
 
 Agent 不會直接憑空執行。它應該先：
 
-1. 檢查使用者是否有許可權檢視企業客戶工單；
+1. 檢查使用者是否有權限檢視企業客戶工單；
 2. 呼叫工單查詢工具；
 3. 生成候選工單列表；
 4. 說明將建立哪些任務；
@@ -86,7 +86,7 @@ Agent 工作臺的能力會逐步擴大。管理員可以說：
 
 > 讓銷售主管可以批次建立商機跟進任務，但不能修改商機金額和合同條款。
 
-平臺應生成工具許可權：允許建立任務，禁止修改金額和合同。
+平臺應生成工具權限：允許建立任務，禁止修改金額和合同。
 
 合規負責人可以說：
 
@@ -148,7 +148,7 @@ Agent 查詢合同條款物件，生成風險列表，發起複核審批，並
 
 高風險動作需要審批：
 
-- 修改金額、合同、許可權和主資料；
+- 修改金額、合同、權限和主資料；
 - 對外發送承諾；
 - 批次匯出客戶資料；
 - 關閉合規或審計問題；
@@ -172,13 +172,13 @@ Agent 工作臺不應該一開始覆蓋所有系統。更好的路徑是從一
 
 第六，逐步跨系統擴充套件，把多個業務物件連線成更完整的執行工作臺。
 
-這條路徑讓企業可以先驗證價值，再擴大 Agent 的許可權。
+這條路徑讓企業可以先驗證價值，再擴大 Agent 的權限。
 
 ## ObjectStack 的價值：把 Agent 放進業務執行時
 
-很多 Agent 演示看起來很強，但一到企業生產環境就卡住，因為它們沒有物件、許可權、流程和審計邊界。
+很多 Agent 演示看起來很強，但一到企業生產環境就卡住，因為它們沒有物件、權限、流程和審計邊界。
 
-ObjectStack 的後設資料驅動能力，讓業務系統天然可以暴露成受控工具：物件定義資料語義，許可權定義訪問範圍，流程定義動作路徑，審批定義人工關口，審計記錄每一次 Agent 行為。
+ObjectStack 的後設資料驅動能力，讓業務系統天然可以暴露成受控工具：物件定義資料語義，權限定義訪問範圍，流程定義動作路徑，審批定義人工關口，審計記錄每一次 Agent 行為。
 
 用自然語言搭建 Agent 工作臺，本質上不是生成一個聊天機器人，而是生成一個業務執行層。
 

content/blog/ai-compliance-control/index.zh-Hant.mdx

@@ -18,7 +18,7 @@ tags: []
 
 合規檢查最累的地方，常常不是不知道制度在哪裡，而是要把制度、業務記錄和證據材料對起來。
 
-制度裡寫著訪問許可權要定期複核，實際複核記錄在哪？合同審批要求超過一定金額必須法務確認，哪些合同有證據？資料匯出需要留痕，日誌是否完整？供應商資質要每年更新，過期材料是否整改？
+制度裡寫著訪問權限要定期複核，實際複核記錄在哪？合同審批要求超過一定金額必須法務確認，哪些合同有證據？資料匯出需要留痕，日誌是否完整？供應商資質要每年更新，過期材料是否整改？
 
 傳統合規檢查大量依賴人工翻制度、拉清單、問業務、收截圖、做表格。AI 可以改變這個過程，但前提是不能只做制度問答。
 
@@ -37,7 +37,7 @@ AI 內控檢查應用應該把制度條款變成控制點，把控制點關聯
 
 第一，制度文本多，而且經常不是結構化的。很多規則寫在制度、流程、合同模板、監管要求和內部通知裡。
 
-第二，證據分散。審批記錄在 OA，許可權記錄在 IAM，合同在合同系統，供應商材料在採購系統，日誌在安全平臺，整改進度在表格裡。
+第二，證據分散。審批記錄在 OA，權限記錄在 IAM，合同在合同系統，供應商材料在採購系統，日誌在安全平臺，整改進度在表格裡。
 
 AI 擅長閱讀和匹配，但它必須知道自己匹配的是什麼。制度條款、檢查項、證據、缺口、整改都需要成為物件。
 
@@ -57,7 +57,7 @@ AI 擅長閱讀和匹配，但它必須知道自己匹配的是什麼。制度
 | `remediation_task` | 整改措施、負責人、截止時間、複核結果 |
 | `audit_log` | AI 分析、人工確認、審批和證據變更記錄 |
 
-例如制度寫著“生產環境許可權應每季度複核”。AI 應該把它拆成一個 `control_item`，要求每季度檢查生產環境許可權清單和複核記錄。如果找不到最近季度的複核證據，就建立 `compliance_gap`，並生成整改任務。
+例如制度寫著“生產環境權限應每季度複核”。AI 應該把它拆成一個 `control_item`，要求每季度檢查生產環境權限清單和複核記錄。如果找不到最近季度的複核證據，就建立 `compliance_gap`，並生成整改任務。
 
 ## 搭建後持續用語言調整檢查口徑
 
@@ -75,11 +75,11 @@ AI 擅長閱讀和匹配，但它必須知道自己匹配的是什麼。制度
 
 IT 負責人可以說：
 
-> 對低風險系統，許可權複核週期從季度改成半年；核心系統保持季度。
+> 對低風險系統，權限複核週期從季度改成半年；核心系統保持季度。
 
 這會生成按系統等級區分的檢查頻率規則。
 
-自然語言搭建讓檢查口徑可以被業務和合規共同維護，而不是藏在一個難改的腳本里。
+自然語言搭建讓檢查口徑可以被業務和合規共同維護，而不是藏在一個難改的腳本裡。
 
 ## 檢查人員如何用自然語言工作
 
@@ -136,7 +136,7 @@ AI 適合做：
 
 ## 第一版怎麼搭
 
-AI 內控檢查應用可以從一個範圍清楚的場景開始，比如許可權複核、合同審批、供應商資質或資料匯出。
+AI 內控檢查應用可以從一個範圍清楚的場景開始，比如權限複核、合同審批、供應商資質或資料匯出。
 
 第一步，匯入制度和流程檔案，讓 AI 生成條款和控制點草稿。
 

content/blog/ai-content-workbench/index.zh-Hant.mdx

@@ -100,7 +100,7 @@ AI 可以從 `source_material` 中讀取銷售記錄、客戶問題、產品文
 
 AI 可以返回一組選題，並說明依據：
 
-- 最近 30 天客戶多次問到 AI Agent 許可權邊界；
+- 最近 30 天客戶多次問到 AI Agent 權限邊界；
 - 銷售在三個商機中反饋客戶擔心私有化部署；
 - 現有部落格裡有 CRM 文章，但缺少審批和合同場景；
 - 建議寫一篇面向業務負責人的應用搭建文章。