AI 供應商治理與信任架構：共競、依賴與退出
題面來自台大官方試卷；解析與逐項自評標準（rubric）為本站依已複查來源整理的非官方內容，策略申論容許有條件且有證據的替代論點。
考古題證據邊界： 考古題只證明此範圍曾出現；題面均為申論或開放題，答案非官方，課程練習採 rubric self-review，絕不進自動計分或完整模擬考。
第一次接觸也沒關係
這堂先懂這些詞
先記住白話意思，不必急著背英文。看到正文時，再把正式名稱接回來。
AI 可信賴性
也會看到：trustworthiness、trustworthy AIAI 在準確、安全、公平、隱私、透明與可問責等面向值得依賴的程度。
- 生活例子：
- 貸款模型除了準確，還要能申訴、保護資料並監測歧視。
- 別搞混：
- 不等於使用者主觀相信品牌，也不是單一分數。
自建／採購／委外／訂閱服務
也會看到：build、buy、outsource、SaaS分別是自己開發、買現成軟體、請外部廠商執行，以及按期訂閱雲端軟體。
- 生活例子：
- 自己煮、買調理包、請外燴、訂月費餐盒。
- 別搞混：
- 委外只轉移執行，不會把需求與治理責任一起丟掉。
透明、問責與救濟
也會看到：transparency、accountability、redress讓人知道系統怎麼影響自己、有人對結果負責，受害時有申訴與補救管道。
- 生活例子：
- 信用被誤判時能看懂原因、找得到負責單位並要求更正。
- 別搞混：
- 只貼隱私政策不等於透明，也不等於已可問責。
深入 AI 時代的供應商治理挑戰：當供應商既是合作夥伴又是潛在競爭者，如何建立信任、管理依賴、規劃退出？
先抓住這幾件事
- 分析 AI 供應商的 coopetition 動態與信任風險
- 設計多供應商策略的評估框架
- 建立 AI 供應商合約的關鍵條款清單
- 規劃 vendor exit 策略以降低 lock-in 風險
1.共競（Coopetition）改變供應商關係
Coopetition（共競）是 Brandenburger & Nalebuff 提出的概念：兩家企業可以同時是合作夥伴和競爭對手。在 AI 時代，這個概念特別適用於大型雲端和 AI 供應商（AWS、Google、Microsoft）與它們的企業客戶之間的關係。 以 AWS 為例：(1) 作為合作夥伴——提供 IaaS/PaaS 基礎設施、AI/ML 服務（SageMaker、Bedrock）、全球化部署能力。企業透過 AWS 加速創新和擴展。(2) 作為潛在競爭者——Amazon 可能利用平台資料理解市場趨勢，推出自有產品（Amazon Basics 就是一個例子——觀察平台上的暢銷商品後推出自有品牌）。同樣的邏輯在 AI 領域也存在：供應商觀察客戶的使用模式後可能開發競爭性的 AI 應用。 評估 coopetition 風險的框架：(1) 資料風險——供應商能否存取你的業務資料？是否用你的資料改進它的通用模型？(2) 策略風險——供應商是否可能進入你的市場？它的 roadmap 是否與你的競爭對手合作？(3) 生態系統風險——你對這個供應商生態系統的依賴程度如何？競爭者是否在同一個生態系統中？(4) 定價風險——供應商是否可能在你高度依賴後提高價格？ 考試常見：分析企業與 AI 供應商的 coopetition 動態、評估供應商選擇的策略風險。
- Coopetition：供應商同時是合作夥伴和潛在競爭者——AI 時代更普遍
- Amazon 觀察平台暢銷商品後推出自有品牌——同邏輯適用於 AI 領域
- 評估四面風險：資料（被用來訓練模型？）、策略（進入你的市場？）、生態系統（依賴程度？）、定價（依賴後提價？）
- Coopetition 不代表不應合作——而是要在合作的同時管理競爭風險
- 開源替代方案降低但不消除依賴——因為維運能力和生態系統仍可能被鎖定
2.多供應商策略的權衡
分散供應商降低單點依賴風險，但增加整合和管理成本。Best-of-breed（每類選最佳）vs Integrated suite（單一供應商全包）的決策不只是技術問題——它影響組織的技能結構、成本模型和治理複雜度。 Multi-cloud 策略（同時使用 AWS、Azure、GCP）的現實考量：(1) 技術複雜度——每個雲端有不同的服務命名、API 設計、安全模型和計費方式，團隊需要掌握多套工具。(2) 最低公約數問題——為了保持可攜性，你可能被迫只使用各雲端都支援的基本功能，放棄每個雲端的差異化服務（managed database、serverless、ML services）。(3) 治理複雜度——統一的監控、安全和合規需要額外的 abstraction layer。(4) 成本——多供應商可能失去量折扣的議價能力。 資料可攜性（data portability）是最關鍵的 lock-in 防線——如果你能帶走資料，就永遠有退出的選擇。合約需要明確約定：資料匯出的格式、頻率、成本和 SLA。API 抽象層（abstraction layer）可以降低但不消除切換成本——它讓應用程式不直接呼叫供應商 API，未來切換時只需改抽象層的實作，不需改應用程式。但抽象層本身也有維護成本，而且可能限制了對供應商進階功能的使用。 過度分散的風險：談判籌碼稀釋（每個供應商的合約金額都小，沒有議價空間）、技術深度不足（團隊對每個平台都只會皮毛）、整合測試和故障排除成本倍增。
- Multi-cloud 現實考量：技術複雜度、最低公約數問題、治理複雜度、成本
- 資料可攜性是最關鍵的 lock-in 防線——能帶走資料就永遠有退出選擇
- API 抽象層降低切換成本但有維護成本且可能限制進階功能使用
- 過度分散有反效果：議價力稀釋、技術深度不足、整合成本倍增
- 不是越多供應商越好——集中和分散各有成本，需要按業務風險取捨
3.AI 供應商合約的特殊條款
AI 服務合約需要超越傳統 IT 合約的條款。傳統 IT 合約主要規範：服務範圍、SLA（uptime、response time）、計費方式、知識產權、保密、終止條件。AI 服務合約需要額外覆蓋： (1) 資料使用條款——客戶上傳的資料（training data、prompts、fine-tuning data）供應商是否可以使用？用於什麼目的？是否與其他客戶的資料混合？OpenAI 的 API terms 在這方面經歷過多次修改——早期版本允許使用客戶資料改進模型，後來改為預設不使用（opt-out）。合約要明確約定 data usage、data isolation、data residency（資料存放地區，例如歐盟客戶要求資料不離開歐洲）。 (2) 模型透明度——供應商是否提供 model card（模型的能力、限制、訓練資料描述、已知偏見）？是否提供 training data sheet（訓練資料的來源和品質資訊）？是否提供 audit report（獨立評估報告）？這些資訊對企業評估 AI 風險至關重要，但很多供應商不願意公開。 (3) SLA 擴展——AI 服務的 SLA 不只是 uptime 和 response time。還需要覆蓋：latency（推論延遲）、throughput（每秒可處理的請求數）、accuracy degradation（模型品質下降的監控和通知義務）、model deprecation notice period（模型退役的預告時間——如果供應商要停止某個模型版本，需要提前多久通知？）。 (4) Indemnification（賠償條款）——如果 AI 生成的內容侵犯了第三方的智慧財產權，誰負責？Microsoft、Google 和 OpenAI 都已經為各自的商業 AI 服務提供了某種程度的 IP indemnification，但覆蓋範圍和條件不同。 (5) 模型更新管理——供應商升級模型版本時，是否給客戶 migration testing 的時間？是否支援 version pinning（鎖定特定版本）？更新後如果行為改變，責任歸屬如何？
- AI 合約額外條款：data usage、model transparency、SLA 擴展、indemnification、更新管理
- Data usage 要明確：供應商能否用客戶資料改進模型？data isolation 和 residency 呢？
- Model card 和 training data sheet 是評估 AI 風險的基礎——但很多供應商不願公開
- AI SLA 除了 uptime 還要覆蓋 latency、throughput、accuracy degradation、deprecation notice
- IP indemnification 條款在 AI 生成內容的版權爭議中特別重要
4.Exit strategy 要在 entry 時就設計
Exit strategy 不是在供應商出問題時才想的——是在選擇供應商時就要設計。如果你在選擇前沒有想過退出方案，選擇後就已經被鎖定了。 設計 exit strategy 的四個面向：(1) 可攜性評估——盤點哪些 artifacts 需要帶走：原始資料（能否完整匯出？格式是什麼？）、模型權重（如果是 fine-tuned 模型，權重歸誰？）、特徵工程邏輯（pipeline 程式碼）、監控規則和告警設定、歷史評估報告。(2) 替代方案維護——持續評估市場上的替代供應商，保持團隊對替代技術的基本熟悉度（不需精通，但要能在 3 個月內切換）。(3) 合約條款——明確約定 transition period 的 SLA 和支援義務（供應商在你切換期間仍需維持服務）、資料匯出的時間表和格式、提前終止的條件和費用。(4) 定期演練——exit drill（退出演練）模擬切換流程，驗證資料匯出、替代方案部署和服務恢復的時間。就像 disaster recovery drill 一樣，不演練就不知道計劃是否可行。 技術層面的 lock-in 降低：容器化（Docker/Kubernetes）讓應用程式不依賴特定基礎設施。Infrastructure as Code（Terraform、Pulumi）讓基礎設施配置可以在不同雲端重建。Open standards（ONNX 模型格式、OpenAPI 介面規格）降低模型和 API 的供應商綁定。但這些只降低技術層面的 lock-in——資料、人才和生態系統的 lock-in 需要其他策略。 考試提醒：不要把 exit strategy 寫成「選另一個供應商」——要寫出具體的退出計劃（帶走什麼、怎麼遷移、多久完成、風險是什麼）。
- Exit strategy 在選擇供應商時就要設計——選擇後才想就已經被鎖定了
- 四面向：可攜性評估、替代方案維護、合約條款、定期退出演練
- 定期做 exit drill——就像 disaster recovery drill，不演練就不知道計劃是否可行
- 容器化和 IaC 降低技術 lock-in，但資料和人才 lock-in 需要其他策略
- 不要寫「選另一個供應商」——要寫具體退出計劃（帶什麼、怎麼遷、多久、風險）
一起搭作答骨架
範例 1：如何回答「AI 供應商治理與信任架構」的比較題？
- 定義比較軸與分析單位。
- 各寫一條作用機制。
- 加入至少兩項條件或風險。
- 用案例與指標驗證。
所以作答主軸是：可接受的答案不只一種；關鍵是條件透明、概念正確、推論可追蹤，並能說明限制。
範例 2：題目要求提出建議時，如何避免只列 buzzwords？
- 先指出要改善的問題。
- 說明建議如何改變流程、資訊或激勵。
- 指定責任人與衡量方式。
- 補上失敗訊號與替代方案。
所以作答主軸是：建議應包含 action、mechanism、metric 與 risk，而不是只寫「導入 AI／雲端／平台」。
這裡最容易寫偏
- 把工具名稱當成因果解釋
- 沒有說明分析層級與前提
- 只寫單一立場，不處理權衡
- 把非官方參考解析當唯一標準答案
- 引用時事卻沒有日期與來源邊界
換你快速判斷
先用自己的話說出定義、機制、條件與取捨，再展開答案。
最後用考古題自評
請先完成自己的申論，再依非官方解析和逐項自評標準檢查；不使用 A–E 假選項或虛假分數。
開始本課申論自評參考來源
- Management Information Systems: Managing the Digital Firm, 17th Edition — Kenneth C. Laudon; Jane P. Laudon