我們與誰合作

一個人工智慧專案。
三個小組必須批准。

當業務、技術和風險領導者可以根據自己的職責評估同一系統時,企業人工智慧就可以投入正式運行。我們將這些決策作為一個交付路徑的一部分。
採購委員會

不同的職責。
一個正式運行決策。

我們不會將專案分為業務推廣、技術建構和治理審查。此交付模式為所有三個群體提供了共同行動所需的證據。

01 · 商業與創新
當這個人工智慧系統運作時,可能會產生什麼操作結果?
通常:業務發起人、轉型領導者、產品負責人或負責工作流程及其價值的營運領導者。

讓用例具有可操作性,而不是戲劇性的

引人注目的人工智慧演示還不是一種業務能力。工作流程需要一個所有者、明確的決策或輸出、明確的人員責任以及適合組織實際運作方式的發布路徑。

您需要批准什麼
  • 具體的工作流程和操作結果
  • 人工智慧輔助與人類判斷之間的明確界限
  • 從試點到正式運行的分階段路徑
  • 判斷每個版本是否在改進系統的方法
我們首先要調整什麼

在選擇模型或設計介面之前,我們先映射工作流程、參與者、決策、來源資料和操作約束。

委員會的收穫
  • 正式運行結果的共同定義
  • 跨業務和交付的指定職責
  • 發布與營運目標相關的證據
討論業務流程 主要行動:討論人工智慧專案,並考慮工作流程和決策
02 · 產品與技術
原型很簡單。正式運行系統才是真正的工程問題。
通常:技術長、工程副總裁、產品負責人、人工智慧負責人或負責架構和發布品質的平台所有者。

將模型建構到圍繞它的系統中

正式運行級人工智慧不僅僅依賴模型呼叫。這取決於它可以讀取的數據、它可以使用的工具、它必須生存的 API、控制發布的評估以及保持工作流程可觀察的基礎設施。

您需要批准什麼
  • 企業資料的落地與權限邊界
  • 版本到達使用者之前的評估閾值
  • 安全控制、可觀察性、回退和回滾路徑
  • 內部團隊可以操作和擴展的架構
我們設計什麼

我們從人工智慧原生產品開始,一直到其下面的資料、API、應用程式和基礎設施,保持發布路徑端到端可見。

委員會的收穫
  • 具有命名控制點的正式運行架構
  • 每個版本均附有證據
  • 準備移交的文件、憑證和代碼
探討技術路徑 主要行動:討論人工智慧專案及其必須使用的系統
03·風險與治理
我們需要知道系統可以做什麼、誰對其進行審查以及誰批准更改。
通常:負責營運邊界和責任的風險、合規、安全、法律、保證或執行利害關係人。

使控製成為產品架構的一部分

系統建成後,治理不能加入為報告。訪問、人工審核檢查點、評估證據、批准記錄和變更控制需要與從設計到營運的工作流程一起進行。

您需要批准什麼
  • 顯式資料、工具和使用者存取邊界
  • 對低置信度或高風險案例進行人工審查
  • 可追蹤的模型、提示、流程和策略更改
  • 無需對系統進行逆向工程即可審查的證據
我們讓什麼可見

我們記錄誰可以存取什麼、檢查發布的門、人員何時介入以及如何批准和追蹤變更。

委員會的收穫
  • 跨業務和技術的共享控制模型
  • 可審查的證據而不是黑盒子保證
  • 批准、例外和升級的明確所有權
討論治理模式 主要行動:討論人工智慧專案及其必須獲得的批准

需要三個組別都在同一對話中嗎?

這是正常的企業人工智慧購買流程。帶來用例、當前系統和批准約束;我們將幫助制定一條每個小組都可以評估的正式運行路徑。

討論您的人工智慧項目
一個共同的起點

引入工作流
程、堆疊和批准標準。

我們將利用它們來建立一條人工智慧原生交付路徑,供業務、技術和風險領導者共同審查。

業務成果的定義 正式運行路徑可見 控制設計於
建構企業人工智慧?從用例到受控正式運行
討論您的項目