Oracle Deep Trust AI Architecture 將 AI 防護措施納入企業技術堆疊
Oracle 於 10 月 26 日公布 Oracle Deep Trust AI Architecture，將防護措施部署於企業技術的四個層面，而非把執行責任留給個別 AI 應用程式。此藍圖涵蓋軟件平台、資料、資料存取及應用程式開發。其核心論點相當務實：即使 AI 模型出錯，企業仍需要持續有效的控制措施。
此公告針對 AI 代理，即利用模型選擇工具並執行工作的軟件。這些系統帶來一個棘手的架構問題：若代理經由新途徑存取業務資料，既有應用程式內建的限制是否仍然適用？
Oracle 的答案著重於在應用程式底層執行控制。AWS 則透過位於代理執行邊界以外的 AgentCore 控制項，追求相關目標。真正有意義的比較，在於各方案於何處執行政策、涵蓋甚麼，以及客戶仍須設定甚麼。對企業買家而言，這次公告既關乎責任分配，也關乎軟件本身。
Oracle Deep Trust AI Architecture 連接四個控制層面
Oracle 展示的是一套整合既有產品能力的架構藍圖，而非公布一個保證行為可靠的模型。
10 月 26 日於拉斯維加斯 Oracle AI World 發表的 企業 AI 架構 公告，整合了 Oracle AI Database、Oracle Autonomous AI Database 及 Oracle APEX AI Application Generator。
Oracle 將此方法與其用於設計可靠系統的 Maximum Availability Architecture 藍圖作比較。此處的組織目標，是維持對 AI 存取及行動的控制。公司表示，共享保護措施可減少依賴每個應用程式各自實施的防護機制。
在評估實際改變時，這項分別相當重要。一項架構公告可以確立共同的設計方向，但不代表所有元件都會在公告當日新近推出。買家應區分藍圖的公布，與其計劃部署的各項能力之推出狀態。
實際意義在於這些元件預期如何協同運作。企業可能已有資料庫權限、應用程式檢查及營運安全流程。架構上的問題是，當代理為系統引入另一條路徑時，這些措施是否仍構成一致的邊界。
試想一個假設的採購助理，會讀取採購紀錄並草擬變更。其日常應用程式介面或會拒絕超出僱員權限的要求。即使助理從未開啟該介面，若另有連接通往底層資料，該連接亦需要同等限制。
此例說明 Oracle 所要處理的問題，而非記錄某個客戶部署。一項控制措施只有在工作流程實際遇上它時，才可保護該流程。若另一條途徑完全避過檢查，額外加入應用程式檢查所提供的保證便相當有限。
因此，Oracle 的方案改變了評估對象。買家需要檢視由人的要求至具有實質後果的系統行動之間的完整路徑。只審視助理可見的對話，會讓這條路徑的重要部分未被探究。
四層框架亦區分了「信任」的不同含義。維持平台更新，與限制存取某項紀錄並不相同；限制存取，亦不同於正確解讀財務問題。應用程式可在其中一項責任上表現良好，卻在另一項上失敗。
對關注這次公告的讀者而言，這種區分至關重要。「可信 AI」聽起來可能像單一產品特性；但在此藍圖中，它代表多項需要不同證據、負責人及驗收準則的工程責任。
新聞重點是協調一致的架構及其對執行控制的強調。它並不證明每間採用此藍圖的企業，均已解決這些責任。
資料擁有人面對最艱難的管治決策
將執行措施下移至技術堆疊更深層，會令準確定義規則變得更重要。
Oracle 的 資料安全設計 說明，資料庫會根據最終使用者已驗證的身分執行控制。用於查詢及修改關聯式資料的語言 SQL，仍須遵守這些規則。
公司亦介紹 SQL Assertions，即當變更違反已定義業務要求時會拒絕變更的資料庫條件。其示例涉及僱員的開支上限。這些機制處理存取及有效變更，而非依賴代理記住指令。
對企業團隊而言，這意味著組織層面的工作。必須有人決定哪些權限及業務條件應屬於該執行環節。技術系統可以一致地套用規則，但組織仍可能對規則應容許甚麼存在分歧。
假設的採購流程可清楚說明這項分別。獲准查看採購申請，未必等於獲准批核申請。批核申請的權限，可能取決於部門、申請用途，或臨時授權安排。
這些問題既屬流程擁有人的責任，也屬開發人員的責任。資料庫管理員可協助實施已獲同意的條件，但不應被迫從非正式對話中推斷含糊的採購政策。
因此，Oracle AI 管治令企業政策定義的質素承受更大壓力。僅以習慣表達的規則，當軟件需要明確決定時會更難管理。例外情況尤其值得注意，因為它們往往揭示日常流程中隱藏的假設。
這並不表示每項判斷都應置於資料庫內。有些決定取決於其範圍以外的資訊；另一些則需要人為酌情處理，或由另一個系統批核。此架構需要清楚界定每項控制可判斷甚麼。
採購例子亦揭示資格與意圖之間的分別。一項申請可能符合開支上限，卻購買了不合適的項目。執行上限處理的是已定義條件，並不能證明該採購符合業務需要。
這項分別應影響採購決定。團隊需要識別建議的控制措施能防止哪些失誤，以及哪些失誤仍有可能發生。與其作出籠統的管治承諾，不如明確交代所涵蓋的行動。
開發人員亦面對相關的責任轉變。共享執行措施可減少重複工作，但應用程式仍須正確處理拒絕情況。助理應準確說明行動被拒的原因，並避免把拒絕視為應設法繞過的技術問題。
資料擁有人亦需要有修改政策的流程。部署時正確的規則，可能在重組或修訂批核流程後變得過時。可靠的執行機制令有紀律的更新更有價值，因為影響會延伸至每個受涵蓋的應用程式。
因此，相關的成功指標不僅是政策引擎是否運作。組織需要就政策含義、擁有權、例外情況及檢討達成共識。這些決定會界定一致執行措施實際能達成甚麼。
共享執行措施改變 Oracle 與 AWS 的比較方式
Oracle 對應用程式底層控制的重視，屬於一場更廣泛的競爭：企業 AI 權限應設於何處。
AWS 在其 AgentCore 政策執行 文件中，描述了設於 Gateway 的控制機制；Gateway 是一項協調工具存取的服務。AWS 指出，Policy 會在代理程式碼以外評估工具呼叫，並套用規管允許行動的規則。
這提供了重要比較，但並不表示兩者涵蓋範圍等同。Oracle 強調資料庫及應用程式堆疊；AWS 則描述圍繞工具存取的執行措施。兩者均挑戰依賴嵌入代理內部指令的做法，但其執行點擔當不同的架構角色。
閘道可以評估擬議的工具呼叫是否獲允許。當要求抵達資料庫時，資料庫控制可以評估存取或變更。企業是否需要其中一種方法，還是兩者兼用，取決於其工作流程及現有系統。
因此，對買家有用的問題很具體：要求在產生效果前，必須經過哪裏？只有當團隊能識別所有繞過或超出執行點的路徑時，顯示執行點的圖表才具意義。
例如，設想一個可透過獲批工具更新業務紀錄的助理。同一環境可能亦有另一項擁有更大權限的整合。評估應檢視兩條路徑，而非假定獲批工具代表完整邊界。
這是一個分析示例，並非聲稱任一供應商產品存在已識別的弱點。它說明為何比較功能名稱只能提供有限指引。涵蓋範圍取決於實際部署，以及其元件獲賦予的權限。
因此，Oracle 代理安全應根據客戶的資料路徑評估。當相關紀錄及規則位於資料庫內時，以資料庫為核心的設計值得密切關注。涵蓋外部服務的工作流程，亦需要適合該等服務的控制措施。
比較時不應把 Oracle 的方法視為競爭對手完全依賴提示詞的證據。AWS 文件明確描述外部執行措施。競爭上的分別在於整合、涵蓋範圍、管理方式，以及維持一致政策所需的工作。
整合責任亦存在取捨。共享控制可讓團隊有共同位置檢視政策，從而簡化監管；但共享設定出錯時，亦可能對多個應用程式造成後果。
反之，把檢查分散至工具及服務中可保留本地脈絡，但亦可能令一致性更難評估。無論採用哪種架構取向，都不能免除理解身分、權限及決定如何穿越完整工作流程的需要。
對買家而言，營運配合度比一般性的架構優越聲稱更具參考價值。最有力的評估，會採用組織本身的權限邊界及真實任務。以陌生的示範流程建立的演示，對部署準備程度提供的證據較少。
此公告提出一項實質的競爭議題：企業購買的不只是產生 AI 行為的系統，還包括約束這些行為的系統。這些約束的價值，取決於它們能否在企業實際使用的各條路徑上保持有效。
準確答案不僅需要權限檢查
代理可以正當地存取資料，卻仍然產生具誤導性的業務答案。
Oracle 的 Deep Trust capabilities 包括 Deep NL2SQL，這是一套把自然語言問題轉換成資料庫查詢的系統。Oracle 表示，系統會納入業務脈絡，並支援旨在提升答案品質的回饋與驗證。
這所處理的責任與授權不同；授權是判斷某項行動是否獲准。即使獲准的查詢，仍可能誤解問題。有效的結果，也可能支持底層數據無法合理佐證的詮釋。
試想一個假設的財務助理，被要求識別最強的客戶關係。「最強」可以指收入、留存率、盈利能力，或策略重要性。若未經澄清便選擇其中一種詮釋，便會在檢索任何紀錄前塑造答案。
問題未必是計算錯誤。助理或許能正確計算其所選用的指標。失敗之處在於，該指標是否回答了業務問題。
這正是 Oracle AI 管治與知識管理交會之處。組織需要持續維護其術語、核准指標及相關脈絡的說明。管控存取權限的政策，無法取代這些定義。
對正在比較資訊系統的讀者而言，個人與團隊知識之間的分別提供了有用脈絡。個人理解與組織定義各有不同用途。業務答案需要與任務相稱的權威來源。
分析上的挑戰，是決定誰的詮釋會成為系統的一部分。銷售主管與財務主管可能基於合理原因，以不同方式使用同一個詞語。有用的實作應保留該等脈絡，而非悄然將每個問題標準化為單一含義。
回饋帶來另一項責任。修正一個答案可以改善某次互動，但共享定義亦會影響日後的問題。當多個團隊依賴相同概念時，任何變更都需要審視其更廣泛的影響。
因此，買家應要求提供涉及模糊情況的例子，而不只是答案顯而易見的問題。系統如何回應規格不足的要求，能揭示它會尋求澄清、說明假設，還是將某種詮釋當作既定事實。
答案品質亦需要合適的評估標準。如果先前答案採用了過時定義，即使與之吻合也不足夠。審查流程需要區分一致性與正確性。
這些考量並不減弱資料庫控制的重要性。它們說明了為何此藍圖涵蓋的不只是安全。即使由同一個助理執行兩項任務，防止未經授權的存取與產生值得據此決策的答案，仍是不同目標。
對知識工作者而言，這是最直接的含義。若答案背後的業務假設仍然不可見，即使內容精緻亦值得仔細審視。企業信任除了權限界線外，還需要可理解的定義及可追溯的推理。
Oracle Deep Trust AI Architecture 將這些責任納入同一個敘事。其成效仍取決於組織知識的品質，以及用以驗證答案的證據。
信任主張仍需要部署證據
這項公告確立了 Oracle 的設計立場；但並未獨立證實客戶部署的安全性或準確性。
Oracle 對 AI 無法繞過的保護措施所作的廣泛表述，應在已配置控制措施的範圍內理解。不應延伸解讀為整個企業系統不受濫用影響的主張。
OWASP 的 過度代理指引指出，不必要的功能、過多權限及過度自主性均會帶來風險。其建議包括限制能力，並在相關使用者的安全脈絡內執行行動。
該指引支持限制權限的架構原則。它並非對 Oracle 實作的評估。這一分別很重要，因為符合設計原則，不能取代關於特定產品或配置的證據。
審慎評估應同時檢視一般錯誤與蓄意攻擊。助理可能誤讀要求、選錯紀錄，或嘗試使用者從未打算執行的行動。在這些情況下，控制措施需要產生可理解的結果。
提示注入，即嘗試令模型遵循嵌入於不受信任材料中的指令，帶來另一類測試。買家除了應檢視模型是否能辨識惡意指令，也應檢視在這類嘗試後仍可取得甚麼權限。
核心分析問題是失敗的後果。如果模型行為不正確，哪些行動仍可能發生？評估這種後果，比起詢問助理是否通常遵循指令，更能產生有用證據。
支持性的分析師評論同樣需要脈絡。在 Oracle 發布的 架構信任觀點中，theCUBE Research 的 Dave Vellante 認為此架構有潛力減少整合工作。他亦強調，企業仍須對政策、驗證及部署管治負責。
這些評論刊載於 Oracle 自己的網站。它們是由供應商挑選並附上出處的外部觀點，而非獨立的比較測試。讀者在衡量市場對該公告的反應時，應保留這一分別。
本文審閱的材料並未提供獨立比較基準，以證實整體安全性或答案準確度。這限制了可從發布中得出的結論。它並不表示這些控制措施無效。
部署證據亦應包括系統拒絕的正當工作。限制措施可以阻止不當行動，同時亦可能阻礙必要任務。過度拒絕會促使員工採取人手繞過方式，削弱原定流程。
同樣地，成功執行控制後應留下足夠資訊供調查。團隊需要了解哪個身分發起請求、套用了哪項規則，以及結果如何。拒絕而沒有可理解的解釋，會造成另一種營運負擔。
適當的結論應有所界限。Oracle 已闡述可信的架構問題及協調一致的回應。買家仍需要證據，證明按其環境配置的所選組件，能處理他們關注的失效情況。
買家應在 2027 年初前觀察甚麼
下一批有用證據將關乎可部署性、量度結果及營運責任歸屬。
首個訊號，是針對買家擬使用的特定功能提供清晰的部署資訊。至 2027 年初，客戶應留意涵蓋支援環境、先決條件、限制及組件可用性的精確文件。
這些資料可將寬泛藍圖轉化為可評估的實作，從而提升 Oracle Deep Trust AI Architecture 的實際價值。即使整體設計仍具吸引力，若對要求持續存在不確定性，採用規劃仍會更困難。
這一訊號很重要，因為企業環境各不相同。組織應能判斷提案的哪些部分適用於其現有系統。關於架構範圍的一般聲明，無法回答每一個組件層面的部署問題。
第二個訊號，是包括失敗案例的評估證據。有用的結果會檢視未經授權的請求、錯誤詮釋、獲准行動，以及被控制措施拒絕的正當任務。買家應尋找清楚說明的設定及明確限制。
外部評估或有文件記錄的客戶評估，會比另一項概括性背書更能增強信心。僅限於狹窄示範的結果，只能支持較狹窄的結論。
關鍵在於評估是否符合所提出的主張。證明某一項禁止請求失敗的測試，並不能證實對無關行動的涵蓋範圍。來自已定義問題集的準確度結果，不應變成普遍可靠性的主張。
第三個訊號，是關於長期操作控制措施的客戶證據。組織應留意有關政策變更、身分更新、例外處理及維護的記述。這些細節揭示架構在初次部署後是否仍可管理。
這也是競爭比較變得更有用的地方。Oracle 與 AWS 的文件描述不同的強制執行位置。客戶經驗有助釐清，在真實的資料庫、應用程式及外部服務組合中維持涵蓋範圍所需的工作。
這些訊號均不需要預測市場勝者。它們提供評估架構是否帶來實際價值的方法。清晰的部署要求、相關評估及可問責的營運，將會加強 Oracle 的論點。
對開發人員而言，直接含義是區分產生行動與授權行動。對企業買家而言，則是要求在強制執行邊界提供證據。對知識工作者而言，則是追問答案由哪些定義支撐。
在擴大助理權限前，先選擇一個團隊理解其規則與後果的工作流程。要求供應商以該工作流程展示一項獲准請求、一項被禁止請求及一項含糊請求。檢視模型作出錯誤選擇時會發生甚麼事，然後識別由誰負責隨之而來的政策或知識修正。應將證據附於實際部署，而非把產品名稱當作認可。Oracle Deep Trust AI Architecture 為這個討論提供了具體起點。利用它提出一個精確問題：當助理把下一步弄錯時，哪項控制措施可防止錯誤步驟變成業務行動？
