HITL 工作流程設計工作表：將任何 AI 使用案例轉化為人在迴路系統
在 AI 工作流程中設計人類監督的實用工作表。涵蓋風險評估、干預點、審查介面要求、升級閾值和稽核要求。
人在迴路（HITL）不是一種哲學——而是一個工程決策。對於每個需要人類監督的 AI 使用案例，需要有人精確指定：人類在哪裡干預、他們是誰、他們看到什麼、他們有多長時間，以及如果他們不回應會發生什麼？沒有這些細節，「我們有人類監督」只是一個意圖聲明，而非控制措施。
對你正在部署的每個需要人類監督的 AI 使用案例使用此工作表。每個系統一張完整的工作表。隨模型庫存條目一起保存。
第 1 部分：使用案例概況
在進行任何技術設計之前填寫此部分。如果你不能清楚地回答這些問題，使用案例還沒有準備好實施。
使用案例名稱：_______________________________________________
系統所有者（姓名和職稱）：_______________________________________________
完成日期：_______________________________________________
簡要描述 — AI 做什麼，用一兩句話？
它接收什麼輸入？
它產生什麼輸出？（具體說明：分數、分類標注、生成的文字、推薦操作等）
輸出觸發什麼下游操作？（如果輸出被接受，接下來發生什麼？）
第 2 部分：風險評估
在兩個維度上對此使用案例進行評級，然後使用結果矩陣確定你所需的監督模式。
後果嚴重性：錯誤輸出有多糟糕？
| 級別 | 定義 | 示例 |
|---|---|---|
| 高 | 對個人造成重大傷害；難以或不可能逆轉 | 貸款拒絕、醫療治療建議、法律文件、帳戶終止 |
| 中 | 實質性影響，花費精力和成本可以逆轉 | 錯誤定價、向用戶顯示錯誤內容、服務延遲 |
| 低 | 輕微不便，可以輕易糾正且沒有持久影響 | 自動完成建議、標籤建議、內部摘要 |
你的評級：[ ] 高 [ ] 中 [ ] 低
決策頻率：每天有多少個決策？
| 級別 | 使用量 |
|---|---|
| 高 | 每天超過 10,000 個決策 |
| 中 | 每天 100 到 10,000 個決策 |
| 低 | 每天少於 100 個決策 |
你的評級：[ ] 高 [ ] 中 [ ] 低
結果矩陣
| 低頻率 | 中頻率 | 高頻率 | |
|---|---|---|---|
| 高後果 | 需要 HITL | 需要 HITL | 需要 HITL |
| 中後果 | 建議 HITL | 帶抽樣的 HOTL | 帶抽樣的 HOTL |
| 低後果 | 帶記錄的 HOOTL | 帶記錄的 HOOTL | 帶記錄的 HOOTL |
你的監督模式：
[ ] HITL — 人類在採取下游操作之前批准每個輸出
[ ] HOTL — 人類以定義的抽樣率監控；可以覆蓋。抽樣率：_______%
[ ] HOOTL — 完全自動化；聚合指標由人類監控
注意：如果你組織的治理政策無論使用量如何都強制要求此風險級別的 HITL，該政策優先於此矩陣。
第 3 部分：干預點設計
僅對 HITL 和 HOTL 系統完成此部分。
人類審查在哪裡進行？
標記所有適用的：
[ ] 在模型運行之前（人類審查輸入資料並決定是否繼續）
[ ] 在模型產生輸出之後但在下游操作之前（HITL 最常見）
[ ] 在多步驟工作流程中的特定下游操作之前（在下面指定哪個操作）
[ ] 以上所有
需要人類批准的特定操作（如適用）：
審查員規範
指定審查員是誰？（角色/職稱，而非個人姓名——在你團隊的 RACI 中指定個人分配）
是否有用於升級的二級審查員？（角色/職稱）
最大可接受審查時間（SLA）是多少？
如果審查員在 SLA 內不回應，會發生什麼？
[ ] 升級到二級審查員
[ ] 升級到[角色]：_______________
[ ] 自動拒絕（不採取下游操作）
[ ] 自動批准（僅對有書面理由的三級系統）
[ ] 暫停整個工作流程並提醒系統所有者
審查員可以在決定之前請求額外信息嗎？
[ ] 不——審查員必須根據顯示的內容做出決定
[ ] 是——審查員可以請求：_______________________________________________
信息請求響應的 SLA：_______________
第 4 部分：審查介面要求
審查介面是自動化偏差風險最高的地方。只看到 AI 輸出加上單個批准/拒絕按鈕的審查員 會對大多數輸出橡皮圖章批准。介面必須顯示足夠的上下文，讓審查員能夠做出真正的判斷。
必需元素 — 勾選所有在審查介面中必須存在的：
[ ] AI 輸出（具體的建議、分類或生成的文字）
[ ] 置信度分數或概率（如果模型產生）
[ ] 模型考慮的備選輸出（前 N 個備選，如適用）
[ ] 產生此輸出的輸入資料
[ ] 產生此輸出的模型版本
[ ] 類似的過去案例及其結果（參考案例）
[ ] 此決策類型的相關監管或政策上下文
[ ] 審查 SLA 的剩餘時間（可見倒計時）
[ ] 如果輸入超出模型訓練分布的標誌或異常指示器
[ ] 此審查員過去在類似案例上的決定（支持校準）
此特定使用案例所需的額外上下文：
審查員拒絕時必須記錄什麼？
[ ] 拒絕原因（必填，自由文字）
[ ] 拒絕類別（必填，從列表中選擇）：_______________
[ ] 推薦更正：_______________
第 5 部分：升級閾值
定義確定每個決策路由的閾值。要具體——模糊的閾值會產生不一致的行為。
| 路由 | 條件 |
|---|---|
| 自動批准 | 置信度 > _____% 且輸出類型 = _____ 且未引發標誌 |
| 標準審查 | 置信度在 _____% 到 % 之間或以下任何標誌： |
| 資深審查 | 置信度低於 % 或輸出包含以下任何一項： |
| 自動拒絕 | 輸出包含以下任何一項：_____（例如，禁止內容、超出範圍請求） |
關於設置閾值的注意事項：在獲得模型實際置信度校準的實證資料之前，不要設置自動批准閾值。在影子模式下運行模型（記錄輸出但不採取下游操作）至少 30 天，在最終確定閾值之前審查置信度分數與人工審查員決定的分布。
第 6 部分：防止自動化偏差
自動化偏差——人類審查員傾向於在沒有真正獨立評估的情況下遵從 AI 輸出——破壞 HITL 控制。這些控制可以減少它。
事後抽查
[ ] _____% 的自動批准決策每週由資深審查員事後審查
審查員校準
[ ] 審查員至少每月在一組已知案例上接受測試（正確答案已確定的）。所需合格率：_____。未通過校準測試的審查員 在返回審查職責之前需要重新培訓。
覆蓋率監控
[ ] 每週計算覆蓋率。目標覆蓋率範圍：_____% 到 _____%
[ ] 覆蓋率偏離基準範圍超過 % 觸發：__________________________________________
審查員輪換
[ ] 任何給定週中，沒有單一審查員處理超過 _____% 的案例
[ ] 最少活躍審查員數量：_____
反饋迴路
[ ] 審查員決定用於定期評估模型性能。當審查員一致覆蓋特定輸入類型的模型時，在 _____ 天內觸發模型評估。
第 7 部分：稽核追蹤要求
對於此工作流程中的每個人類決策，以下內容必須自動記錄。對於第一層或第二層系統，這不是可選的——根據 SR 11-7、EU AI Act 第 30 條和 HIPAA（如適用），這是監管要求。
必需的日誌字段 — 確認每個 都將被捕獲：
[ ] UTC 時間戳（非本地時間）
[ ] 審查員身份（用戶 ID，而非姓名——姓名可以改變；用戶 ID 持續存在）
[ ] 被審查的 AI 輸出（準確的文字、分數或分類）
[ ] 產生輸出的模型版本（非應用程式版本——模型工件版本）
[ ] 審查員決定：批准 / 拒絕 / 升級
[ ] 審查員推理（自由文字——拒絕和升級必填）
[ ] 審查所用時間（從顯示到決定的秒數）
[ ] 因審查決定而採取的下游操作
[ ] 案例或實體識別符（以便你可以重建哪個個人受到了影響）
日誌保留期：_______________________________________________
日誌存儲位置：_______________________________________________
防篡改機制（哈希鏈、一次寫入存儲等）：_______________________________________________
第 8 部分：有效性指標
在啟動前定義目標值。每月對照它們進行測量。如果你不建立基準，就無法檢測漂移。
| 指標 | 目標 | 如何測量 |
|---|---|---|
| 審查完成率 | _____% 需要審查的案例實際收到審查 | 已審查案例 / 需要審查的案例 |
| 覆蓋率 | _____%（30 天後建立基準） | 被拒絕或升級的案例 / 已審查案例 |
| 決策時間 | 平均 _____ 分鐘 | 審查持續時間日誌字段的平均值 |
| 假陰性率 | _____% | AI 批准；資深事後審查員不同意 |
| 稽核日誌完整性 | 100% | 日誌記錄 / 已審查案例的推論記錄 |
| 審查員校準合格率 | _____% | 校準測試結果，每月 |
報告週期：這些指標每[週/月]報告給 _____________________。
升級觸發器 — 如果任何指標超出可接受範圍，採取以下操作：
完成示例：合約條款審查 AI
為了說明此工作表的實際工作方式，以下是法律技術使用案例的填寫示例。
使用案例名稱：合約條款風險篩選器
簡要描述：AI 審查上傳的合約條款，標記具有非標準條款、缺少保護或不尋常責任分配的條款，並產生風險評級（低/中/高）和摘要說明。
輸入：個別合約條款文字（從上 傳的 PDF 中提取）
輸出：風險評級（低/中/高）和 2-3 句解釋標記問題
下游操作：高評級條款自動排入律師審查隊列；低評級條款自動接受；中等評級排入平行法律助理審查
後果嚴重性：高（遺漏高風險條款的法律和財務後果）
決策頻率：中（每天 200-500 個條款）
監督模式：高評級條款的 HITL；中評級條款的 HOTL（10% 抽樣）
審查員：資深合夥律師（高評級）；法律助理（中等抽樣審查）
SLA：高評級：4 小時；中等抽樣審查：24 小時
SLA 違反操作：升級到值班合夥律師
自動批准閾值：置信度 > 92% 且評級 = 低且未標記 IP 或賠償條款
資深審查閾值：模型置信度低於 70% 的任何條款，或涉及責任限制、知識產權所有權或適用法律的條款
覆蓋率目標：高評級條款為 15-25%（如果覆蓋 率降至 10% 以下，審查員可能在橡皮圖章批准；如果超過 35%，模型可能過度標記）
連接到你的稽核基礎設施
此工作表的第 7 部分指定了每個人類審查決策所需的精確日誌字段。這些字段需要由你的審查介面捕獲，並存儲在可以按需向監管機構提供的系統中。
如果你正在建立自訂審查介面，日誌完整性應該是啟動的阻礙要求——而非啟動後的改進。記錄修復之前缺失的稽核記錄已經消失了；它們無法重建。
Ertas Data Suite 內建的操作員記錄和人工審查追蹤自動捕獲資料管道審查步驟的第 7 部分字段，具有防篡改存儲和用於監管提交的結構化匯出。
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading
How to Design a Human-in-the-Loop Workflow for Your AI Pipeline
A practical framework for embedding human oversight into AI systems — from risk assessment to review interface design. Goes beyond theory to what actually works in production.
What Is Human-in-the-Loop AI? A Practical Guide for Enterprise Teams
Human-in-the-loop AI keeps humans in the decision chain — but the details matter. Here's what HITL actually means in practice and why it's non-negotiable in regulated industries.
Human-in-the-Loop vs. Human-on-the-Loop vs. Human-out-of-the-Loop: What's the Difference
Three terms that sound similar but represent fundamentally different risk profiles. Understanding the distinction matters more than ever as AI moves into high-stakes decisions.