Question 1

AI Sandbox 是什麼？

Accepted Answer

AI Sandbox 是讓企業 AI 真正上線的 On‑Prem Tamed AI 解決方案（Secure • Smart • Simple）。核心是把「AI 很強，但企業最怕出事」的風險收斂成 **可治理、可稽核、可驗收** 的交付。

#### 三個關鍵（可導入｜可整合｜可擴充）

- **可導入（Secure）**：內網部署、離線可用、權限可稽核；資料不出內網。
- **可整合（Simple）**：OpenAPI・企業 API，AI 可以橋接官網與既有系統；不打掉重練，讓系統開始聽得懂人話。
- **可擴充（Smart）**：匯入文件・圖片・影音，AI 自動建立結構與索引（知識圖譜/向量索引），生成可維運知識庫，匯入就能問；並支援多模態資料一次整合（PDF/Word/SOP、Excel/財報/KPI、BI/Dashboard、條文/合約/判例、錄音/逐字稿等）。

#### 一台 Box，就能跑企業 AI

- 可搭配 NVIDIA DGX Spark：1,000 TOPS 企業級推論效能、240W 低功耗運作，支援 24/7 穩定運作。

Question 2

AI Sandbox 跟一般 Chatbot 有什麼不同？

Accepted Answer

一般 Chatbot 多半停留在「對話」，企業導入最常卡在四件事：能追溯嗎、出事誰負責、資料一上雲就不再完全由貴方掌控、導入要不要打掉重練/怎麼維運。AI Sandbox 用 On‑Prem Tamed AI 把這些問題變成可治理的交付：

- **可追溯**：回答附出處、權限可稽核；操作與對答可追溯（問了什麼、引用哪些來源、輸出什麼）。「誰提問」的身分識別需搭配客戶既有 SSO 機制。
- **可驗收**：知識庫可回歸測試、可持續優化；不只「會聊」，而是能制度化交付。
- **可整合**：不打掉重練，透過 OpenAPI/企業 API 讓既有系統開始聽得懂人話。
- **可營運**：支援長期維運（技術支援/安全更新）與主機備援重建流程（匯出/匯入）。

Question 3

AI Sandbox 跟一般公有雲 AI 工具有什麼差異？（企業評估重點）

Accepted Answer

AI Sandbox 不是「更會聊天的工具」，而是把企業最在意的資安、合規與責任邊界做成可交付的系統：

- **資料邊界（Data Residency）**：支援 On‑Prem / Private 部署，資料不出內網（可離線）。
- **治理與稽核**：沿用 SSO/RBAC；可設定治理規則/護欄；回答附出處；操作可追溯（何時問了什麼、依據哪些來源）；「誰提問」的身分識別需搭配客戶既有 SSO 機制。
- **企業知識庫（Knowledge Documents）**：匯入內部 PDF/Word/Excel 等資料，建立可維運知識庫（索引/權限/回歸測試），讓全員共享同一份「可驗收答案」。
- **風險可合約化**：正式上線可在 NDA/DPA 與企業合約中明確資料邊界、保存與稽核責任（以合約為準）。

相較之下，一般公有雲 AI 工具多以個人帳號與單次對話為中心，資料邊界、權限稽核與合規責任往往需要企業自行承擔與補齊。

Question 4

適合用在哪些流程？

Accepted Answer

適合資料量大、重複性高，而且資料不能離開公司的流程。最常從這三件事開始：

- **重複訂單**：上百行的訂單不用再逐欄抄進 ERP；AI 先整理好，對不上的才交給人確認。客戶實績：單筆 240 分鐘 → 5 分鐘。
- **新訂單與設計稿**：開模之前，AI 先比對上萬筆設計稿，找出能沿用的設計，由工程師決定改哪裡。
- **合約審核**：AI 依您的審查標準讀完整份合約，高風險條款先標出來，法務在原本的 Word 裡修訂。

不確定從哪裡開始？帶一張最頭痛的訂單或文件來，30 分鐘評估告訴您能不能做、怎麼驗收、多久上線。

Question 5

評估：地端 AI 與 雲端 AI 最大的差別是什麼？

Accepted Answer

差異的核心不在「模型誰比較強」，而在 **資料邊界、治理責任與可稽核性**：

- **資料邊界（Data Residency）**：雲端 AI 常涉及資料出內網與跨境處理；地端 AI 可把資料留在內網/私有環境（可離線），降低外洩與合規風險。
- **權限與稽核**：雲端 AI 多以個人帳號與單次對話為中心；地端 AI 可沿用 SSO/RBAC，並保留審計追溯（何時問了什麼、依據哪些來源）；「誰提問」的身分識別需搭配客戶既有 SSO 機制。
- **可驗收與可維運**：雲端工具常以「好用」為主；企業導入更在意「可治理、可回歸測試、可持續優化」。
- **責任邊界可合約化**：地端 AI 更容易在 NDA/DPA 與企業合約中明確資料保存、稽核、維運與責任分工（以合約為準）。

Question 6

評估：我們的 AI Sandbox 和 一般的地端 AI 最大的差異是什麼？

Accepted Answer

AI Sandbox 的差異在於：我們交付的不只是「把模型放進內網」，而是把企業最在意的 **治理、稽核與驗收** 做成可交付的系統（On‑Prem Tamed AI）：

- **可治理**：沿用 SSO/RBAC；可設定治理規則/護欄；關鍵流程可「先確認再執行」。
- **可稽核**：回答附出處；操作可追溯（何時問了什麼、依據哪些來源、產出什麼結果）；「誰提問」的身分識別需搭配客戶既有 SSO 機制。
- **可驗收**：支援題庫（回歸測試題）與持續優化；把品質從「靠感覺」變成「可驗收交付」。
- **可整合**：OpenAPI／企業 API 串接既有系統；不打掉重練，讓系統開始聽得懂人話。
- **可維運**：支援匯出/匯入重建（備援/換機流程）、技術支援與安全更新（以合約為準）。

Question 7

（資安與合規）評估：資料是否會出內網？是否支援離線運作？

Accepted Answer

正式交付支援 On‑Prem / Private 部署，**資料不出內網**；可依交付設定支援 **離線可用**（以合約與實際環境為準）。若是試用（Demo），僅供評估/POC，請勿輸入任何個資/機密。

Question 8

（資安與合規）評估：資料會被拿去訓練模型嗎？

Accepted Answer

- **On‑Prem / Private（正式交付）**：資料與日誌通常保存在貴方環境；除非貴方於合約中另有授權，我們不會將貴方資料用於對外公開模型訓練或對外再利用。
- **試用（Demo）**：為資安防護與除錯目的，可能會記錄必要的輸入/輸出，但仍不以其訓練對外公開模型（除非您明確同意或合約另有約定）。
- **第三方供應者（如貴方自選）**：是否用於訓練取決於貴方選擇與其條款/設定；建議以 DPA/採購文件先確認。

Question 9

（資安與合規）評估：是否支援 PII（個資）自動遮蔽？

Accepted Answer

可依貴方規範，對輸入內容做個資辨識與遮蔽/替換，降低敏感資料外流風險（以合約與設定為準）。

Question 10

（資安與合規）評估：是否支援加密（傳輸/儲存）與去識別化策略？

Accepted Answer

若情境需要跨系統傳輸，建議採 **加密與去識別化** 策略，並以審計日誌保留可追溯證據；實際加密/金鑰管理方式依部署架構與貴方資安規範對齊（以合約與設定為準）。

Question 11

（資安與合規）評估：權限與網路邊界怎麼界定？可以限制哪些人能用嗎？

Accepted Answer

AI Sandbox 不代管權限：沿用貴方 SSO/RBAC 或既有身分/權限系統，由貴方決定誰能用、能做什麼，並可稽核（以合約與設定為準）。

Question 12

（資安與合規）評估：是否提供弱點修補、安全更新與版本升級機制？

Accepted Answer

正式交付包含維運與安全更新的安排（以維護合約（MA）與交付版本為準）；版本升級會在貴方可控的時段內進行，並以回歸題庫驗證降低風險。

Question 13

（資安與合規）評估：是否能配合資安稽核（弱點掃描/滲透測試）與供應鏈審查需求？

Accepted Answer

可依貴方資安流程對齊評估：包含部署架構與網路邊界說明、版本與修補政策、以及必要的稽核配合方式；實際可交付的稽核資料與配合範圍以合約與貴方要求為準。

Question 14

（資安與合規）評估：日誌/對話/知識庫資料保留多久？能否由客戶決定？

Accepted Answer

On‑Prem / Private 環境下，資料與日誌通常由貴方保存並可設定；保留期限與存放位置建議依貴方內控/稽核需求設定（以合約與設定為準）。

Question 15

（資安與合規）評估：若發生事故（誤答/外洩風險），如何做追溯與處置？

Accepted Answer

透過 **回答附出處、審計追溯與治理護欄** 先降低風險；若仍發生事故，可用日誌追溯「何時問了什麼、依據哪些來源、產出什麼結果」；「誰提問」的身分識別需由客戶既有 SSO 機制對應，並以題庫與治理規則修正與回歸驗證（以合約與流程為準）。

Question 16

（資安與合規）評估：試用（Demo）有哪些資料與使用限制？

Accepted Answer

Demo 僅供體驗/評估/POC：請勿上傳任何個資、帳密、金流或機密。若需用真實資料驗證，建議走 On‑Prem / Private 交付並先完成 NDA/DPA。

Question 17

（治理與可稽核）評估：是否支援 SSO 與 RBAC？能沿用既有權限嗎？

Accepted Answer

支援沿用貴方既有身分/權限系統（SSO/RBAC），並可依貴方權限驗證結果提供功能與記錄（以合約與設定為準）。

Question 18

（治理與可稽核）評估：是否提供審計日誌（Audit trail）？能追溯到哪些細節？

Accepted Answer

可追溯「何時問了什麼、AI 依據哪些來源回覆、產出什麼結果、是否被核准/執行」等紀錄。「誰提問」的身分識別需搭配客戶既有 SSO 機制；沙盒不內建帳號管理（以合約與設定為準）。

Question 19

（治理與可稽核）評估：回答是否會附出處？能對來源做權限控管嗎？

Accepted Answer

回答可附出處，並可結合貴方權限控管規則，讓不同角色只看到其有權存取的知識來源與答案範圍（以合約與設定為準）。

Question 20

（治理與可稽核）評估：是否能設定治理規則/護欄（例如禁答、敏感詞、格式要求）？

Accepted Answer

可設定治理規則/護欄與輸出格式/話術範本，降低誤答與外洩風險，並讓回覆風格一致（以合約與版本為準）。

Question 21

（治理與可稽核）評估：是否支援「先確認再執行」以降低誤操作風險？

Accepted Answer

可採「先確認再執行」的模式，把自然語言需求轉成可檢核、可控執行的流程，並保留可回溯紀錄（以合約與整合範圍為準）。

Question 22

（治理與可稽核）評估：知識庫是否可版本化？更新後如何避免答案漂移？

Accepted Answer

可用「知識來源清單、版本管理、題庫回歸測試」控制品質：更新來源後，透過題庫驗證確保關鍵問題答案不漂移（以合約與版本為準）。

Question 23

（治理與可稽核）評估：是否提供題庫（回歸測試題）與品質檢核機制？

Accepted Answer

支援題庫（回歸測試題）作為驗收與持續優化工具；把品質從「靠感覺」變成「可測、可驗收」的交付（以合約與版本為準）。

Question 24

（治理與可稽核）評估：是否支援 Human‑in‑the‑Loop 覆核流程？

Accepted Answer

可用覆核流程搭配題庫與治理規則，把高風險輸出納入人工確認，並持續校正知識與規則（以合約與版本為準）。

Question 25

（治理與可稽核）評估：管理員可治理的範圍有哪些？

Accepted Answer

管理員可治理的範圍（範例）：情境設定、知識來源/知識庫管理、治理規則/護欄、題庫（回歸測試）、輸出格式與話術範本等（以合約與版本為準）。

Question 26

（治理與可稽核）評估：導入後如何衡量成效（命中率/轉人工率/品質）？

Accepted Answer

可用「命中率、轉人工率、常見問題、錯誤分類」等指標做迭代；並以題庫回歸測試確保品質可控（以實際導入與驗收標準為準）。

Question 27

（整合與可導入）評估：如何串接官網智慧客服？是否需要改網站？

Accepted Answer

一段嵌入碼（1‑Line Script）即可把 AI 智慧客服放到官網，No Site Changes；回答內容來自貴方的公開/授權知識庫，並可依需求串接人工客服/工單。

Question 28

（整合與可導入）評估：如何串接既有系統？會不會需要打掉重練？

Accepted Answer

不打掉重練：透過 OpenAPI／企業 API，把 AI Sandbox 接到既有系統，讓使用者用人話查資料、跑流程；執行權與權限仍由貴方掌握。

Question 29

（整合與可導入）評估：整合時建議先做哪些「低風險」起步？

Accepted Answer

建議先從讀取型整合開始（查詢/彙整/說明），再逐步導入可控的寫入/流程（先確認再執行），並保留審計追溯。

Question 30

（整合與可導入）評估：ERP 串接的典型路徑是什麼？

Accepted Answer

典型做法是「先知識化，再整合」：先把 ERP 模組文件/SOP/欄位規格變成可查的企業知識庫，再依 ERP 開放介面（API/報表匯出等）逐步導入查詢與報表助理（以實際 ERP 廠牌/版本與貴方資安規範為準）。

Question 31

（整合與可導入）評估：支援哪些資料型態匯入？（PDF/Word/Excel/影音）

Accepted Answer

支援多模態資料一次整合：PDF/Word/SOP、Excel/財報/KPI、BI/Dashboard、條文/合約/判例、錄音/逐字稿等；匯入後自動建立結構與索引，生成可維運知識庫。

Question 32

（整合與可導入）評估：如何處理既有文件的權限分級與跨部門隔離？

Accepted Answer

可沿用貴方 IAM/權限規則，將知識來源依部門/角色分級，並在查詢與回答層做權限控管與稽核追溯（以合約與設定為準）。

Question 33

（整合與可導入）評估：導入交付內容包含什麼？時程如何估？

Accepted Answer

交付為可驗收的 production 環境，並含導入顧問服務；時程以對齊應用情境、資料準備與驗收標準為準（以報價/訂單/企業合約為準）。

Question 34

（整合與可導入）評估：是否支援多語系？能否讓不同語系共用同一套知識庫？

Accepted Answer

可依需求支援多語系體驗；知識庫是否共用、以及跨語系的出處與品質要求，建議在導入時對齊並以題庫驗收（以合約與設定為準）。

Question 35

（整合與可導入）評估：效能與規模（同時使用人數/延遲）如何評估？

Accepted Answer

建議以貴方實際情境做容量規劃：同時使用人數、資料量、查詢延遲與可用性要求；可在導入時做壓測與調校並納入驗收（以合約與交付設定為準）。

Question 36

（整合與可導入）評估：若未來要擴充新情境（Agent），流程是什麼？

Accepted Answer

先從一個最頭痛的流程導入；之後要擴充新情境，貴方提出目標任務/資料邊界/驗收方式，由 eGroupAI 評估可行性與風險後以版本打包交付（以合約與交付範圍為準）。

Question 37

（品質與可驗收）評估：如何把「會用」變成「可驗收」？驗收標準怎麼定？

Accepted Answer

建議先定義「高頻問題清單」與「可觀察輸出」（含出處、格式、可追溯性），再以題庫回歸測試驗證；把品質從主觀感受變成可測的驗收標準（以合約與版本為準）。

Question 38

（品質與可驗收）評估：如何降低幻覺與錯誤？

Accepted Answer

用「回答附出處 + 治理護欄 + 題庫回歸測試 + 覆核流程」把風險收斂在可接受範圍；並以多模態資料整合與可維運知識庫提升準確度（以合約與設定為準）。

Question 39

（品質與可驗收）評估：回答出處不足或來源不一致時，怎麼處理？

Accepted Answer

可透過補齊知識來源、修正文件版本、調整索引與題庫驗證，讓關鍵問題的出處與答案一致；高風險問題可納入覆核流程（以合約與設定為準）。

Question 40

（品質與可驗收）評估：是否能對「必答格式」做控制（例如表格、JSON、摘要結構）？

Accepted Answer

可用輸出格式與話術範本，要求固定結構（例如條列、表格或結構化輸出），並搭配題庫驗證確保一致性（以合約與版本為準）。

Question 41

（品質與可驗收）評估：題庫怎麼建立？誰負責維護？

Accepted Answer

題庫可從 FAQ、SOP、客服工單與關鍵流程萃取高頻問題；貴方提供業務/流程知識與驗收要求，eGroupAI 協助建置與最佳化（以合約與導入方式為準）。

Question 42

（品質與可驗收）評估：是否支援錯誤分類（Error Taxonomy）與持續改進？

Accepted Answer

可用錯誤分類搭配題庫回歸測試，定位「資料缺漏/出處錯/權限錯/誤解題意」等原因並迭代修正（以合約與版本為準）。

Question 43

（品質與可驗收）評估：線上 Demo 的輸出能否直接當作正式上線品質？

Accepted Answer

不建議：Demo 僅供評估/POC，資料與設定通常不同於貴方正式環境；您可先自行試用（Demo），顧問將主動與您聯絡協助線上最終調校（final tune）與測試驗證，但正式上線仍需在貴方 AI Sandbox（On‑Prem / Private）以資料邊界、權限與題庫驗收為準。

Question 44

（品質與可驗收）評估：是否支援在高風險領域（法務/授信/內控）導入？

Accepted Answer

適合高頻、可標準化且需要權限稽核的流程；但高風險領域仍建議搭配覆核流程與題庫驗收，並以合約界定責任邊界（以合約與設定為準）。

Question 45

（品質與可驗收）評估：模型可以自行調整或更換嗎？這會如何影響一致性？

Accepted Answer

不提供使用者自行更換/調參/改模型；模型由 eGroupAI 最佳化後套裝灌入主機，以確保治理與一致性。若需特定能力，請提出情境與需求，由 eGroupAI 評估後以版本交付（以合約為準）。

Question 46

（品質與可驗收）評估：有哪些情境不建議交給 AI？如何做風險控管？

Accepted Answer

涉及機密外洩、高額交易或不可逆操作的情境，建議採「先確認再執行」與 Human‑in‑the‑Loop 覆核；並以治理護欄與題庫驗證降低風險（以合約與設定為準）。

Question 47

（維運與總擁有成本）評估：授權與費用如何計算？一次買斷包含哪些？

Accepted Answer

AI Sandbox 主體採一次買斷（軟體 + 硬體）並交付可用的 production 環境；實際費用與範圍以報價/訂單/企業合約為準。

Question 48

（維運與總擁有成本）評估：保固與年度維護（MA）包含什麼？

Accepted Answer

保固與維運摘要：首年維運免費，第 2 年起每年 9 萬（未稅），含軟體與硬體保固，硬體故障直接換新；並含技術支援與安全更新；細節以合約為準。

Question 49

（維運與總擁有成本）評估：支援與 SLA 是什麼？發生問題多久會回覆？

Accepted Answer

在有效保固維運期間內，eGroupAI 依約提供技術支援與服務回應，協助確認問題、排除異常並追蹤處理進度。服務時段、問題分級與回應方式依報價或維護合約約定；若確認為軟體異常，提供約定範圍內的修正與安全更新。

Question 50

（維運與總擁有成本）評估：資料如何匯出與備份？未來換機/故障如何復原？

Accepted Answer

貴方需定期匯出保存；若主機故障更換通常會格式化，不包含資料救援；能否復原取決於貴方備份。可匯出資產包含情境設定、知識來源清單、治理規則/護欄、題庫、話術範本、Prompt、對答紀錄等（以合約與版本為準）。

Question 51

（維運與總擁有成本）評估：版本升級會不會影響既有流程？如何降低升級風險？

Accepted Answer

版本升級建議搭配題庫回歸測試做前後驗證；並在貴方可控的時段內升級與回復（rollback）規劃，降低對營運影響（以合約與導入流程為準）。

Question 52

（維運與總擁有成本）評估：主機故障是否包含資料救援？有哪些限制？

Accepted Answer

硬體更換不包含原主機資料救援（修復通常會格式化）；故障復原以貴方備份與匯入重建流程為準（以合約與檢測/佐證為準）。

Question 53

（維運與總擁有成本）評估：導入後誰負責日常維運？eGroupAI 介入到什麼程度？

Accepted Answer

eGroupAI 提供技術支援與版本更新；貴方負責資料邊界、權限與備份策略等日常治理。實際責任分工以企業合約與維護合約（MA）為準。

Question 54

（維運與總擁有成本）評估：若要做災難備援（DR）或異地備份，建議怎麼規劃？

Accepted Answer

建議以貴方內控/稽核要求設計：定期匯出/備份、保存位置與權限、復原演練與驗收題庫；可在導入時對齊並納入驗收（以合約與設定為準）。

Question 55

（維運與總擁有成本）評估：如何避免「導入後只有少數人會用」？

Accepted Answer

用「高頻情境優先 + 題庫驗收 + 角色化入口（SSO/RBAC）+ 持續迭代」建立使用習慣；並用命中率/轉人工率/常見問題回饋做內容與流程優化（以實際導入為準）。

Question 56

（維運與總擁有成本）評估：若未來要退出或替換方案，資料與設定能否帶走？

Accepted Answer

貴方可定期匯出可匯出資產並自行保存；是否能在新環境重建取決於貴方備份與匯入流程。建議在採購時把「可匯出範圍」與「交接責任」寫入企業合約（以合約為準）。

Question 57

官網智慧客服如何串接？

Accepted Answer

> 一段嵌入碼（1‑Line Script）即可把 AI 智慧客服放到官網；回答內容來自貴方的公開/授權知識庫，並可依需求串接人工客服/工單。

- **Step 1｜定義入口與體驗**：決定要顯示的位置（全站/指定頁）、語系與品牌樣式。
- **Step 2｜準備可公開的知識來源**：FAQ、產品說明、政策條款與常見流程；上線前先以題庫做回歸測試。
- **Step 3｜上線與迭代**：嵌入後即可運作；後續用「命中率/轉人工率/常見問題」持續優化。

> 提醒：正式上線若涉及內部資料或客資，建議採 On‑Prem / Private，並以貴方權限與稽核要求定義資料邊界（以合約與設定為準）。

Question 58

既有系統如何串接？

Accepted Answer

> 不打掉重練：透過 OpenAPI／企業 API，把 AI Sandbox 接到既有系統，讓使用者用人話查資料、跑流程；執行權與權限仍由貴方掌握。

- **先做讀取型整合**：先從查詢/彙整/說明開始（例如查 SOP、查客戶狀態、彙整報表）。
- **再做可控的寫入/流程**：需要寫入或觸發流程時，採「先確認再執行」，並保留審計追溯。
- **權限沿用**：沿用既有 SSO/RBAC；哪些角色能查、能做什麼，由貴方規範。

Question 59

ERP 系統如何串接？

Accepted Answer

> 典型做法是「先知識化，再整合」：先把 ERP 模組文件/SOP/欄位規格變成可查的企業知識庫，再依 ERP 開放介面（API/報表匯出等）逐步導入查詢與報表助理。

- **第一階段（快速可用）**：用人話問「欄位怎麼填、流程怎麼跑、這張報表代表什麼」。
- **第二階段（資料查詢/彙整）**：串接 ERP 可用的查詢/報表出口，讓報表生成與解讀更快。
- **第三階段（流程助理）**：在貴方授權下，把高頻流程做成可驗收的動作步驟（以合約與版本為準）。

> 提醒：實際串接方式與可自動化範圍，取決於 ERP 廠牌/版本/介面與貴方資安規範，會在導入時對齊。

Question 60

官網嵌入需要改哪些東西？

Accepted Answer

原則上不需要改網站架構或後端：通常只要把 **1‑Line Script** 加到官網指定頁面即可。若貴方有較嚴格的安全政策（例如 CSP），可能需要把允許清單（script-src / connect-src 等）對齊後才能上線（以貴方資安規範為準）。

Question 61

什麼是 No Site Changes？

Accepted Answer

No Site Changes 指的是：不需要為了導入 AI Sandbox 去調整貴方的網站系統架構或重做頁面。多數情況下是「加一段嵌入碼 → 指定知識來源 → 上線」，必要時再逐步加上 API 串接（以貴方需求與驗收為準）。

Question 62

官網智慧客服的外觀可以做哪些品牌化？

Accepted Answer

可對齊常見品牌元素，例如：Logo、主色/按鈕樣式、問候語與語氣、語系、顯示位置（全站或指定頁）。更深度的 UI/互動客製（例如特殊流程、表單或多步驟導引）會依交付範圍評估（以合約為準）。

Question 63

可以轉接人工客服/工單嗎？

Accepted Answer

可以。常見做法是設定「轉接條件」（例如高風險/需要人審、客訴、超出知識範圍）並把必要資訊（問題、上下文、引用來源、使用者識別/工單欄位）送到貴方既有客服或工單系統；同時保留稽核追溯（以整合範圍為準）。

Question 64

串接企業 API 時，認證與權限怎麼處理？

Accepted Answer

原則是 **沿用貴方既有 SSO/RBAC**：誰能查什麼、能不能做動作，都以貴方權限與流程為準。AI Sandbox 以貴方允許的方式呼叫企業 API（讀取/動作），並保留可追溯紀錄（以架構與合約為準）。

官網智慧客服如何串接？

既有系統如何串接？

ERP 系統如何串接？

官網嵌入需要改哪些東西？

什麼是 No Site Changes？

官網智慧客服的外觀可以做哪些品牌化？

可以轉接人工客服/工單嗎？

串接企業 API 時，認證與權限怎麼處理？

如何做到「先確認再執行」？

系統串接交付會給哪些文件/成果？

官網智慧客服如何串接？

既有系統如何串接？

ERP 系統如何串接？

官網嵌入需要改哪些東西？

什麼是 No Site Changes？

官網智慧客服的外觀可以做哪些品牌化？

可以轉接人工客服/工單嗎？

串接企業 API 時，認證與權限怎麼處理？

如何做到「先確認再執行」？

系統串接交付會給哪些文件/成果？