智慧體問數，誰能問哪些數？權限要卡在資料行上

一句「幫我查一下」，跨了三個部門

週一早上，銷售總監在對話方塊裡敲了一行字：把華南區今年上半年的毛利率按客戶拉一下。三秒後圖表出來，前五名客戶一目瞭然。

這行字背後發生了什麼？系統要知道「華南區」在這個組織裡對應哪幾個銷售組織、哪幾個工廠的出貨；要知道「毛利率」用的是哪一版口徑——含不含運費、返利算不算成本；還要知道提問的人有沒有權限看到客戶級的價格與成本。三件事裡任何一件沒答對，圖都出不來，或者出一個錯的。

而最容易出事的，是第四件事：這個人到底該不該看到這些客戶的價格。

AI 問數讓取數變簡單了，同時也讓越權變簡單了。以前要越權，得知道去哪個選單、點哪個匯出、繞過誰的審批；現在只需要把問題問得委婉一點。所以智慧體上線時真正要設計的東西，不是「能問多少」，而是「誰能問哪些」。

智慧體不是新開一個資料出口

很多企業上 AI 問數，第一反應是給智慧體配一份「資料來源賬號」。這個動作看似省事，實際上是給全公司開了一個只讀的後門：智慧體用一個高權限賬號連庫，然後所有提問的人都借這個賬號取數。

問題在於，這個賬號的權限跟提問的人沒有關係。倉管問一句「上個月原材料成本多少」，智慧體照樣答得出來——因為它連的是那個高權限賬號。這類系統在演示時體驗極好，一進審計就解釋不通：誰在什麼時候看了什麼資料，日誌裡只有「智慧體」。

正確的做法反過來：智慧體不持有自己的資料權限，它繼承當前登入人的權限上下文。使用者是誰、屬於哪個部門、擔任什麼崗位、能看到哪些資料行，這些在請求進來的那一刻就確定了，智慧體只是在這個邊界內組織查詢、生成圖表、寫清口徑。

判斷一個 AI 問數產品是不是這麼做的，有個很簡單的問法：把同一個人從 A 部門調到 B 部門，第二天他問同樣的問題，答案會不會變？會變，說明權限是真的在起作用；不變，說明權限是裝飾。

JEDP 的雙智慧體就是這個結構：設計態用自然語言建模、經設計器釋出；執行態在本人授權範圍內問數，可輸出對話方塊圖文，也可匯出 Office、HTML、Markdown，並可經平臺業務介面建立單據、辦理稽核。它不直寫資料庫，取數也不會超出當前賬號在對應列表頁上命中的權限組。

權限組決定智慧體能查到哪些行

平臺列表取數本來有兩道關：頁面上的過濾條件由前端打包下來，釋出時配的權限組由服務端強制執行。智慧體問數只認後面這一道——它拿不到前端的過濾包，也不該拿。所以真正決定「智慧體能問到哪些數」的，是權限組，不是模型自覺。

一個人命中多個組時取並集；一個組都沒命中、或者這個列表頁壓根沒配權限組，落到本人可見——這是最嚴的一檔，不是最松。所謂本人可見，也不只是「我建的單」，還包括我待辦過、已辦過、被抄送或轉發過的流程單據。平臺列表就是這麼算的，智慧體必須對齊，否則使用者會立刻發現「列表裡有、問數查不到」。

使用者問的那句話未必帶著列表頁。系統會先按列表名反查、再按主表反查，逐級往下找；都找不到，仍然落到本人可見。不管走哪條路徑，鐵律只有一條：同一個登入人，智慧體可見的行必須是他能在對應列表頁看到的行的子集——可以更嚴，不能更寬。

欄位權限更容易出岔子：藏起來不等於問不出來。列表上把「成本價」這一列藏了，如果只在頁面上隱藏、執行層沒把列裁掉，使用者換個說法——「幫我把這個物料的採購單價列出來」——資料照樣出來。隱藏是展示，裁列才是權限。

越權要當場拒絕，而且要留痕

「先問出來再說」是 AI 問數最危險的一句話。它的誘惑在於：資料反正已經在庫裡，模型也讀到了，不給看有點浪費。

但拒絕本身是有價值的。使用者問「華南區客戶毛利」而他只有華東權限時，系統應該明確告訴他：當前賬號的資料範圍是華東，無法返回華南客戶明細。這句話同時完成了三件事——告知邊界、避免誤判為系統故障、留下一條可審計的記錄。

最後一行值得多說一句。真正的越權往往不是一次拿全，而是分十次拿區域性再自己拼。單條日誌都合規，只有把同一賬號的提問序列放在一起看，才看得出意圖。所以問數日誌要能按人、按時間、按指標聚合，而不是隻留一句「誰問過什麼」。

匯出與辦理：比「看一眼」危險得多

查詢和匯出不是一個風險等級。查詢的結果留在系統裡，匯出會把資料帶到系統外，一次匯出可能等於一次資料外流。

匯出至少要管三件事：欄位範圍（敏感欄位預設不進匯出模板）、次數與體量（超出閾值要審批或直接拒絕）、可追溯（檔案帶水印或可定位到人）。薪酬、成本、客戶協議價這類域，建議預設只給彙總不給明細。

寫操作的風險還要再上一級。讓智慧體「幫我把這張不合格單關掉」，聽起來是效率提升，實際上是繞過了審批鏈。合規的做法是：智慧體可以發起、可以預填、可以提示缺什麼欄位，但提交必須走業務介面，落到原來的流程節點上，由該節點的審批人辦理。智慧體不代他人審批，這一點沒有例外。

權限從哪來：別在智慧體裡另建一套

如果智慧體需要單獨維護一份「誰能問什麼」的配置，那它遲早會和主權限系統對不上。對不上的後果不是報錯，而是兩邊都有人相信：業務以為智慧體受限，IT 以為主系統受限，中間那段就是空洞。

授權應該只有一處來源。人員入職、調崗、兼崗、離職，權限在主系統裡變一次，智慧體這邊自動跟著變。權限組在列表頁釋出時一次配好——適用人員、資料範圍、欄位權限都在那一處；組織引擎提供部門樹、崗位任職與彙報關係供條件引用，智慧體只做消費方。

有兩個細節決定了這套東西能不能長期用下去。第一是授權隨任職生效日切換，兼崗、借調、代理要顯式建模並設期限，否則「先開著方便」會變成永久超額權限。第二是回收：離職、調崗、專案結束時的授權回收要有人負責、有時間點，權限債務不會自己消失，只會積累到某次審計爆發。

開放順序：先凍口徑，再放範圍，最後開寫

很多專案一上線就把問數範圍開到最大，理由是「讓大家先體驗到價值」。這個順序恰好是最危險的。

每一步都設一個明確的完成標誌，比設一個上線日期有用得多。特別是第一步——口徑沒凍結就開放問數，得到的是「同一個毛利率有三個數」的混亂，而且模型會把這種混亂放大，因為它答得又快又自信。

六項驗收：能演示才算做到

權限設計最容易停在 PPT 上。驗收時不要看架構圖，讓對方當場演示這六個動作：

1. 用 A 部門賬號問 B 部門的資料，系統明確拒絕並說明範圍
2. 用同一賬號問超出欄位權限的敏感列，只拒絕該列，其餘正常返回
3. 換一個只有檢視權限的賬號，嘗試發起單據，被拒絕
4. 把賬號從 A 部門調到 B 部門，第二天同一問題答案隨範圍變化
5. 連續快速匯出二十次，觸發限流或審批
6. 查一條越權記錄，能看到誰、什麼時候、問了什麼、被哪條規則拒絕

六項都能演，權限才算落到了系統裡。有一項演不出來，就說明那塊還停留在制度層面。

什麼情況下先別上

最後說邊界。有三種情況，我的建議是先把基礎打好，別急著開放問數。

第一種，權限矩陣本身很亂——角色按人複製、資料範圍靠約定、離職賬號沒人停用。這種情況下上智慧體，等於把原來要層層點開才能拿到的資料壓縮成一句話就能拿到，風險被放大而不是被收斂。

第二種，指標口徑還在每週改。模型會把每一版口徑都講得很有道理，使用者會以為那是結論。

第三種，主資料沒有唯一性——同一個客戶三個檔案、同一個物料兩種編碼。問數結果會在聚合時把同一件事算成兩件，而且看不出來。

這三種都不是 AI 的問題，AI 只是把它們暴露得更快。反過來說，如果這三件已經做好了，AI 問數帶來的效率提升是真實的：不用等人導表、不用為了一個數開半小時會、口徑說明跟著答案一起出來。

• 雙智慧體：設計態與執行態的能力邊界
• 權限引擎：資料行與欄位級授權
• 組織引擎：以人為核心的組織主資料
• 多租戶與組織隔離決策表
• 設計態與執行態為什麼必須分開