受監管行業的AI模型訪問控制：誰可以查詢什麼

大多數企業對應用程序和數據庫有成熟的基於角色的訪問控制。薪資系統知道HR可以查看薪資數據，經理可以查看其直接下屬。法律DMS知道只有被分配到某事務的律師才能訪問其文件。

在大多數組織中，AI模型完全沒有這些。任何擁有API密鑰的人都可以向模型發送任何內容並接收響應。沒有角色，沒有對查詢中可以出現什麼數據的限制，通常也沒有誰查詢了什麼的日誌。

在受監管行業，這是一個合規問題。在某些情況下，這是一個法律問題。

為什麼AI訪問控制與數據訪問控制不同

傳統訪問控制管理誰可以讀取或寫入數據。AI訪問控制管理更複雜的事情：誰可以查詢哪個模型、用什麼數據，以及他們可以用輸出做什麼。

當護士搜索患者記錄時，你控制他們可以訪問什麼記錄。當同一位護士用患者的詳細信息查詢AI以獲得臨床建議時，三件事同時發生：數據流向AI系統，AI處理它，輸出流回來。每個階段都有不同的治理含義。

AI的訪問控制問題有四個傳統RBAC沒有完全解決的維度：

模型訪問：哪些用戶和角色可以查詢哪些模型。實習臨床醫生不應該擁有與主治醫師相同的AI能力訪問權限。初級律師不應在沒有監督的情況下用合夥人級別的客戶事務查詢AI。初級分析師不應在沒有審查的情況下提交財務模型進行AI輔助監管分析。

查詢中的數據訪問：可以在AI提示中包含什麼數據。即使用戶有讀取文件的訪問權限，將其包含在AI查詢中也會創造新的風險——該文件現在傳輸到AI系統，可能超出你的安全邊界，AI的響應可能以原始文件沒有的方式合成和暴露信息。

輸出訪問：誰可以看到AI輸出。在醫療保健中，如果廣泛共享，AI生成的診斷建議可能有HIPAA含義。在法律領域，對特權事務的AI生成分析本身可能是特權的——廣泛共享可能放棄該特權。在金融領域，AI生成的交易信號根據背景可能是重大非公開信息。

行動訪問：AI輸出可以觸發哪些下游行動。最危險的訪問控制失敗不是用戶看到他們不應看到的AI輸出——而是用戶或自動化系統在沒有適當授權的情況下根據該輸出采取行動。批准貸款、安排手術、提交監管文件——行動訪問層是AI治理失敗變得有後果的地方。

行業特定要求

醫療保健：最小必要原則和HIPAA

HIPAA最小必要標準（45 CFR §164.514）要求受保實體作出合理努力，將對PHI的訪問限制在實現預期目的所必需的最小範圍。

應用於AI：護士查詢AI關於患者護理的問題，應該只能查詢其直接護理的患者。計費編碼員應該能夠查詢AI關於編碼問題，但不能查詢與計費無關的臨床細節。AI系統的訪問控制應該執行這些角色區分，而不僅僅依賴個人合規性。

HIPAA的審計控制要求（45 CFR §164.312(b)）要求受保實體實施記錄和檢查包含PHI的系統中活動的機制。AI交互日誌——誰查詢了什麼、何時、用什麼數據——必須是PHI訪問審計跟蹤的一部分。

實際含義：你的AI系統需要知道用戶是誰（認證）、他們的角色授權他們做什麼（授權），並記錄每次查詢及其上下文（審計）。這對臨床應用是標準的。它對AI很少實施。

法律：特權和事務訪問

律師-客戶特權為AI訪問控制創造了具體要求。在法律工作中使用的AI系統應執行與事務所文件管理系統一致的事務級訪問控制。只有被分配到某事務的律師和受監督人員才能用該事務的文件查詢AI。

除了事務訪問，還有一個監督層。根據ABA示範規則5.1和5.3，監督律師對其監督下的助理律師和非律師的工作負責。AI治理框架應實施這一點：初級人員查詢AI進行法律研究或起草；輸出在用於工作成果之前被標記以供監督律師審查。

法律AI的查詢日誌需要捕獲足夠的上下文，以便監督律師可以審查AI被問了什麼以及它說了什麼——而不僅僅是查詢發生了。

金融：職責分離

SR 11-7的有效挑戰要求意味著構建和使用模型的團隊不應該是驗證它的團隊。訪問控制是執行這種分離的機制。

模型開發人員應該能夠在開發/暫存環境中查詢模型。他們不應該對實際客戶數據的生產模型查詢擁有不受限制的訪問。驗證人員應對模型行為日誌有讀取訪問權限，但應與開發團隊的配置隔離，以確保獨立評估。

對於用於客戶對向決策的AI——信貸、保險、投資建議——查詢級訪問控制應防止人員使用AI處理他們沒有業務授權處理的數據，即使他們在技術上有系統訪問權限。

影子AI問題

對AI訪問控制最常見的反對意見是它們過於限制性——如果企業系統限制太多，人員會直接使用個人AI帳戶。

這是真的。這是一個正確設置訪問控制而非放棄的論點。

當人員使用個人AI帳戶工作時，你會得到：數據外泄到不受控制的系統、無審計跟蹤、潛在的HIPAA/GDPR違規（醫療保健/歐盟運營）、特權風險（法律領域），以及沒有AI輔助工作成果的機構記錄。這比一個有些限制的企業系統更糟糕。

企業AI訪問控制的目標不是防止所有AI使用。而是通過可以記錄、治理和審計的系統引導AI使用——同時防止最高風險的模式（個人帳戶中的PHI、消費AI中的特權文件、不受控制系統中的財務數據）。

實際實施

模型級控制：為不同角色部署不同的模型。臨床決策支持模型不應對計費團隊可訪問。特權文件分析模型不應對沒有事務訪問的人員可訪問。在你的網絡上本地運行的微調模型（通過Ollama或llama.cpp部署）可以通過你現有的網絡訪問控制限定到特定用戶和角色——查詢不離開你的邊界。

查詢級DLP：掃描提示中不應出現在AI查詢中的模式的數據丟失防護規則——非臨床人員查詢中的PHI標識符、未授權人員查詢中的客戶事務號碼、沒有適當授權的系統查詢中的PII模式。

輸出級可見性：帶審計跟蹤的AI輸出的基於角色的可見性。某些輸出在使用前應要求主管審查。所有輸出都應記錄用戶身份和時間戳。

SSO集成：AI訪問應通過你的企業SSO管理，而非通過團隊內共享的獨立API密鑰。API密鑰創造問責差距——你無法從共享密鑰追蹤查詢到個人用戶。

審計日誌：每次AI查詢都應生成審計日誌條目：用戶身份、角色、時間戳、查詢中存在的數據類型（如果包含PHI則不記錄完整查詢）、查詢的模型版本，以及輸出是否用於下游行動。

本地部署的優勢

雲端AI API創造了一個結構性訪問控制挑戰：查詢在你的訪問控制完全評估它之前就離開了你的邊界。DLP規則可以在發送之前掃描提示，但執行點在你的網絡邊緣，而非AI系統內部。

本地運行的微調模型改變了這一點。當模型在你的基礎設施上運行時，你現有的網絡訪問控制、認證系統和審計日誌記錄適用於AI，就像它們適用於網絡上的任何其他系統一樣。沒有第三方API可以繞過你的控制。

預約與 Ertas 的發現電話 →

Ertas Data Suite 完全在你的基礎設施上運行——推論期間沒有數據外泄，沒有第三方API調用。你現有的訪問控制基礎設施適用。每個處理步驟都記錄了操作員ID和時間戳。對於AI訪問控制是合規要求的受監管行業，本地架構是架構上正確的基礎。

對於微調步驟：在雲端GPU上用你自己的數據訓練你的領域模型，導出為GGUF，然後在你的訪問控制後本地部署。雲端用於訓練，本地用於推論。