甚麼是 organisational context？

Organisational context 是令工作有意義的周邊狀態。

在這篇文章，organisational context 指角色、歷史、優先次序、語言、責任、證據、關係、標準和時間；這些元素解釋一項資訊為甚麼重要，以及下一步應該發生甚麼。

孤立數據點本身很少帶有這種意義。「合約 30 日後到期」會因供應商、使用量、預算負責人、續約條款、關係歷史、批准門檻、策略優先次序，以及是否已有替代項目而有不同意思。「客戶要求更新」亦會因之前承諾過甚麼、matter 是否敏感、對方角色和最新證據而有不同意思。

AI 系統需要這種背景，因為專業決定不是只由數據作出，而是由數據在某個情境裏被詮釋後作出。

所以 context 不應被視為 prompt 裝飾。在專業工作中，context 是控制面的一部分：它告訴系統一個事實代表甚麼、誰可以使用它，以及判斷要在哪裏交回給人。

這是 operating intelligence 本身未夠：來源還需要機構意義。

Organisational Context 的工作定義

Organisational context 是一組事實和關係，用來解釋工作在特定機構內應如何被理解。

它包括：

• 角色：誰負責、審閱、批准、建議、執行或受影響。
• 歷史：之前發生過甚麼、甚麼已改變，以及甚麼不能被忘記。
• 優先次序：現在甚麼重要，以及哪些取捨已經作出。
• 語言：本地使用的術語、標籤、分類和意思。
• 責任：承諾、期限、批准、政策、合約和職責。
• 證據：文件、筆記、決定、來源和審計軌跡。
• 關係：客戶、合作夥伴、團隊、供應商、持份者和信任歷史。
• 標準：質素門檻、專業規範、監管限制和內部規則。
• 時間：節奏、期限、次序、迫切性和可行動窗口。

這個定義比 database schema 更闊。Schema 可以描述欄位；context 解釋意義。

組織研究中的 sensemaking 在這裏有幫助。Weick、Sutcliffe 和 Obstfeld 把 organising 描述為人在含糊情境中創造意義，並以該意義作為行動基礎的過程（Weick, Sutcliffe, and Obstfeld）。

這就是 context 重要的原因：它把事件變成可以行動的情境。

為甚麼孤立數據未夠

大部分機構擁有的數據，比可用背景更多。

它們有文件、任務、會議、筆記、訊息、交易、tickets、CRM entries、合約、政策和試算表。但工作的意義經常活在這些紀錄之間。

任務可能寫着「send proposal」。背景會說明是哪個版本、要回應哪個 objection、適用哪條 pricing boundary、誰必須審閱、上次通話承諾過甚麼，以及客戶關係是否脆弱。

只看到任務的 AI 系統可能行動得很快，但錯得很快。有背景的人可能慢一點，但更適當。

這是 AI 進入機構的核心挑戰。大型語言模型在語言、綜合和規劃上很有能力，但能力不等於本地機構理解。Anthropic 的 agent 指引強調，有效系統需要清晰工作流、工具介面、回饋和合適自主程度，而不是為複雜而複雜（Anthropic^{5Anthropic: Building Effective Agents}）。這些系統仍需要 context 才知道行動代表甚麼。

Context 的實務層次

Organisational context 不是單一物件，而是一個分層營運模型。

角色

角色定義權限和責任。Account owner、finance approver、matter partner、delivery lead、reviewer、vendor manager 或 safeguarding lead 可以出現在同一工作流，但權限並不相同。

歷史

歷史解釋現狀為甚麼重要。過往承諾、之前錯誤、昔日決定、關係敏感位和學到的教訓，都可以改變當前要求的意思。

優先次序

優先次序產生取捨。團隊可能選速度多於打磨、毛利多於增長、延續性多於重組，或者減低風險多於擴張。沒有這些優先次序，AI 可能優化錯東西。

語言

每個機構都有本地語言。「case」、「matter」、「client」、「partner」、「risk」、「review」或「done」在一個團隊內可以有精確意思，在另一個團隊則不同。

責任

責任是應該塑造行動的承諾和限制：期限、批准、合約責任、專業標準、治理要求和內部政策。

證據

證據令 context 有來源。決定應該可以連回文件、筆記、數據、批准或其他紀錄。沒有 source links，context 就變成傳聞。

關係

關係解釋語氣、信任、敏感度和期望。同一個事實更新，會因關係歷史而需要不同處理。

在專業工作中，這種背景經常決定「正確」和「合適」之間的分別。某個客戶可能需要先電話溝通才適合發正式電郵；某個供應商可能已有長期爭議，令看似普通的續約提醒變成敏感談判。AI 如果不知道這些關係背景，容易把所有情況處理成同一種標準答案。

標準

標準定義甚麼叫做做好。例如 ISO 9001:2015 明確要求機構理解自己的 context，作為質量管理系統要求的一部分（ISO^{4ISO 9001:2015 Quality management systems}）。更廣泛的教訓是，質素取決於知道工作發生在哪個環境。

時間

時間決定一個行動是有幫助、太早、太遲還是高風險。很多專業決定依賴次序和節奏，不只是內容。

時間背景亦包括資訊的新舊程度。最新會議筆記可能推翻上週計劃；已過通知期的續約條款會改變選項；一個本來只是提醒的 deadline，接近到期時可能變成升級事項。Context layer 要保存事件次序和最近更新，否則 AI 可能引用正確但已不合時宜的材料。

為甚麼 AI 需要 Organisational Context

AI 需要 organisational context 有三個原因。

第一，檢索取決於知道要檢索甚麼。如果系統分不清草稿和已批准來源，或者 casual comment 和 commitment，它可能把輸出 grounding 在錯誤材料上。

第二，行動取決於權限。AI 系統可能可以草擬，但不可以發送；可以更新內部任務，但不可以改客戶紀錄；可以建議升級，但不可以批准決定。

第三，判斷取決於意義。期限、投訴、續約、例外或會議筆記，只有在 organisational context 中被詮釋後才會變成可行動。

NIST 的 AI Risk Management Framework 相關，因為它把 context、governance、measurement、management、accountability 和 human-AI oversight 視為可信 AI 實務的一部分（NIST AI RMF^{6NIST: Artificial Intelligence Risk Management Framework}）。對機構 AI 來說，這些控制不是可有可無的外殼，而是 context 安全可用的方法。

令 Context 可讀

實務任務是令 organisational context 對人和軟件都可讀。

這意味着要從文件、電郵、會議、日曆、任務、CRM、財務工具、個案系統、支援工具和資料庫帶入相關紀錄；然後清理、連結、加上權限，並標準化為穩定概念，例如 person、role、owner、client、matter、decision、source、obligation、deadline、approval、risk 和 next step。

同時，這個狀態要保存在能保留 source links、permissions、version history 和 audit trails 的系統中，再透過受控方法讓人和 agents 使用：搜尋、brief generation、草擬、建立任務、review queues、source inspection、update tools 和 escalation paths。

這就是把孤立文件交給 AI，和給 AI 一個營運環境之間的分別。

實務例子

合約續約

孤立數據說續約到期。Organisational context 會說明供應商是否策略性、使用量有否下降、誰擁有預算、通知期如何、有哪些替代方案，以及誰可以批准行動。

客戶更新

孤立數據說客戶要求進度。Context 會說明之前承諾過甚麼、甚麼已改變、哪些證據已準備好、哪些內容敏感，以及誰必須審閱回覆。

招聘決定

孤立數據說候選人通過面試。Context 會說明哪個職位缺口重要、團隊限制是甚麼、適用甚麼標準，以及決定如何配合招聘計劃。

交付風險

孤立數據說項目延遲。Context 會說明延遲是否影響承諾、預算、依賴、客戶關係、監管日期或內部 capacity plan。

限制和誤用

不是所有 context 都應被捕捉，也不是所有已捕捉 context 都應該開放給每個系統。

有些資訊敏感、無關、推測性、過時，或會造成不公平偏見。Context systems 需要權限、保留規則、修正機制和審閱。它們應該保留證據和不確定性，而不是把每個推論都變成表面事實。

這點對 AI 特別重要，因為模型很容易把「可能」寫成「是」。如果系統推斷某個客戶不滿、某個員工表現有問題，或某個供應商有風險，這些推論必須標明來源和不確定性，並受權限和審閱控制。Context 的目標是幫助判斷，不是把未驗證印象變成永久紀錄。

目標不是全面監控。目標是負責任的可讀性：有足夠背景令工作更好，同時受私隱、治理和人類問責約束。

Organisational Context 的論點

Organisational context 令人在工作中理解意義。

AI 系統需要它，因為孤立數據不能解釋角色、歷史、優先次序、語言、責任、證據、關係、標準或時間。沒有 context，AI 可以在不完整前提下摘要、草擬和行動。有了 context，它可以準備更好的工作，更負責任地分派決定，並知道何時停下來。

同時，context 不是越多越好。過多未整理背景會令系統更難判斷，亦可能引入不應使用的敏感資料。好的 context layer 需要選擇、結構和治理：哪些資料與這個工作有關，哪些只是噪音；哪些可被模型讀取，哪些只可作權限判斷；哪些推論需要標明不確定，哪些事實已有來源支持。

Context 亦要能處理衝突。兩份紀錄可能說法不同，兩個團隊可能使用不同名稱，同一個客戶可能在不同系統有不同身份。好的 context layer 不應把衝突靜悄悄平均掉，而應顯示差異、保留來源，並在需要時要求人確認。對專業工作來說，知道「我們未能確定」往往比生成一個自信答案更有價值。

實務挑戰不只是連接更多數據，而是建立一個有來源、有權限、保持當前，並可供人和 agents 使用的 context layer。

要令 organisational context 可用，團隊可以先從「決定前需要知道甚麼」倒推，而不是從「我們有甚麼數據」出發。例如客戶更新前要知道最近承諾、最新證據、敏感位和審閱者；續約前要知道使用量、預算負責人、通知期和替代方案；合規審閱前要知道政策版本、例外紀錄和批准歷史。

然後，團隊要把這些需要轉成可維護的欄位、關係和規則。哪些背景必須有來源？哪些只是輔助提示？哪些資料過期後不能再用？哪些人可以查看或修改？Context 如果沒有維護方法，很快會變成另一堆過時筆記。Context layer 要有更新節奏、權限和修正機制，才會保持可信。

換言之，context 是一種持續營運資產。它需要被整理、更新、保護和審閱，才可以支援 AI 和人共同工作。真正有用的 context，不只是多，而是清楚、當前、可查和有邊界。

如果 context 沒有被治理，它很快會變成風險來源。過時背景會令建議偏離現況；未授權背景會造成私隱和保密問題；未標明來源的背景會令人難以追溯責任。這也是為甚麼 organisational context 要和 source links、permissions、version history、audit trails 以及 review paths 一起設計。

因此，建立 organisational context 的工作往往不是先買更多工具，而是先把本地語言和責任講清楚。甚麼叫「已完成」？甚麼叫「需要審閱」？哪類要求必須升級？哪個文件狀態代表可以對外使用？這些定義如果只存在於人的習慣中，AI 就只能猜。

一旦這些定義被建成可讀規則和可查詢狀態，系統才有機會可靠地協助。它可以知道哪份文件有權威、哪個承諾仍未完成、哪個決定需要審閱，以及甚麼時候應該停下來問人。

這就是 context 和普通資料的分別：資料提供片段，context 解釋片段在機構中的意義、權限和下一步。沒有這層解釋，AI 只能從孤立材料推測；有了這層解釋，它才有機會準備可審閱、可問責的工作。

這層解釋，就是專業判斷可以交接和審閱的基礎。

也是 AI 可安全使用的基礎。

資料來源

1. Weick, Sutcliffe, and Obstfeld: Organizing and the Process of Sensemaking
2. Maitlis and Christianson: Sensemaking in Organizations
3. Ren and Argote: Transactive Memory Systems 1985-2010
4. ISO 9001:2015 Quality management systems
5. Anthropic: Building Effective Agents
6. NIST: Artificial Intelligence Risk Management Framework