Human-in-the-loop 其實就是 AI 可以協助判斷或提出操作，但某些重要動作真正執行以前，需要經過人類確認，例如使用者告訴客服 AI 需要退款，AI 可以先確認訂單、整理退款原因，甚至準備好退款資料，但如果退款金額超過一定程度就先不要執行，使用者或客服人員確認之後 Backend 才真正執行退款，這樣 AI 還是可以完成大部分工作，但重要操作不會完全由模型自己決定。

用 JavaScript 做個簡單例子

假設我們規定超過 NT$10,000 的退款需要人工確認：

async function requestRefund(orderId, amount) {
  if (amount > 10000) {
    return {
      status: "pending_approval",
      message: "退款金額超過 NT$10,000，需要人工確認"
    };
  }
  return await refundOrder(orderId, amount);
}

AI 可以呼叫 requestRefund()，但它沒有辦法因為自己說這筆退款已經確認就直接跳過規則，因為真正的限制寫在 Application / Backend 裡，不要只告訴 AI 記得詢問使用者，而是讓程式真的要求 Approval。

這時候可能會想說為甚麼不直接寫在 System Prompt 裡，但前面已經介紹過 Prompt Injection、Jailbreak 等攻擊，如果模型受到操控，單純依賴 Prompt 並不是可靠的安全邊界，所以真正的 Approval 還是應該由程式控制。

if (!approved) {
  throw new Error("Approval required");
}
await refundOrder(orderId, amount);

即使 AI 認為使用者同意了，Backend 沒有收到真正的 Approval 就不能執行。不過當然也不是 AI 做任何事情都要問一次，不然使用 AI 自動化就失去意義了，像是查詢訂單狀態、整理文件、摘要 Email 這種小事通常不需要每次都讓人按確認，但如果涉及的操作具有較高風險，就比較適合加入 Approval，例如：刪除重要資料、修改帳號權限、對外寄送 Email 等，判斷的重點要放在如果 AI 判斷錯誤，這個操作造成的影響有多大？影響越大，就越值得加入人工確認。

Least Privilege + Human-in-the-loop

上一篇與今天的內容其實可以搭配使用，Least Privilege 解決的是 AI 到底有能力做什麼？Human-in-the-loop 解決的是 AI 有能力做，但什麼時候可以真的執行？例如客服 AI 確實需要退款功能，所以我們給它退款 Tool，但可以同時限制最多只能處理自己的客服案件，超過 NT$10,000 必須人工確認，更高金額甚至直接交給主管處理，這樣就比單純在 System Prompt 裡面寫小心使用退款功能還要可靠的多。

Human-in-the-loop 的目的不是讓人類重新做一次 AI 的工作，而是在高風險操作真正發生以前，保留一個可以阻止錯誤的機會，前面幾天其實也逐漸形成了一個共同概念，我們不假設 LLM 永遠不會犯錯，而是思考即使模型真的犯錯，系統還有哪些機制可以阻止傷害發生，不過接下來還有另一個很常見的問題，AI Application 要連接 API、Database 或其他服務時，經常需要使用 API Key、Token 等敏感憑證，那這些東西應該放在哪裡？

下一篇：Day 20｜Secret Management：API Key 到底應該放在哪裡？