AI 法開始執法：台灣模型、SaaS 與內容平台進歐盟，誰是 provider、誰是 deployer？

AI Act Article 2 把數種情形納入範圍。設於歐盟或第三國的 provider，只要在歐盟市場投放 AI 系統或 GPAI 模型，便可能受規範；歐盟境內的 deployer 也在範圍內。即使 provider 或 deployer 位於第三國，若其 AI 系統產生的輸出在歐盟使用，也可能適用。^[3][4]

這使「我們的伺服器在台灣」成為不充分的答案。假設台灣 SaaS 直接向德國企業收費，讓其歐洲人資部門使用 AI 篩選履歷，明顯存在歐盟市場與使用連結。即使合約由台灣母公司簽署、推論在亞洲資料中心完成，輸出仍被歐盟企業用於人事流程。

另一個場景是台灣公司只和美國總部簽約，但系統輸出被跨國集團的法國分公司使用。合理推論｜中高信心：若供應商知道或設計上預期輸出會用在歐盟，不能只靠帳單地址排除 AI Act。不過，具體適用仍要看提供方式、預定用途、契約與實際控制。

範圍也不是無限延伸。Article 2 另有個人非專業活動、國安軍事、特定研究與開源等條件或例外，適用方式須依條文判斷。^[4] 「輸出在歐盟使用」不是歐盟對全世界所有 AI 的普遍管轄，而是要求產品鏈確實具有歐盟市場或使用連結。

台灣團隊習慣把模型開發商叫 provider，把付費客戶叫 user。AI Act 的角色更細。AI system provider 的關鍵通常包括：開發或委託開發一套 AI 系統，並以自己的名稱或商標把它投放市場或投入服務。這意味接第三方模型 API 的 SaaS，也可能是自己系統的 provider，因為終端客戶購買的是它定義、整合與標示的功能。

例如，一家台灣客服 SaaS 使用美國模型，加入自己的知識庫檢索、提示管理、敏感詞過濾與客服介面，並以自有品牌賣給歐盟零售商。底層模型公司可能是 GPAI model provider；台灣 SaaS 公司則可能是整體客服 AI 系統的 provider；歐盟零售商把系統用於營運，可能是 deployer。三者不是互斥答案，而是不同層次的角色。

角色也會移動。歐盟代理商若只是依原品牌轉售，可能接近 importer 或 distributor；若把高風險系統換成自己的商標、作出實質修改，或把原本非高風險用途改成高風險用途，則可能依 Article 25 轉為 provider。^[3] 契約寫「本公司只是經銷商」不能凌駕實際行為。

因此，企業不能只做一張公司級問卷。每個產品至少要記錄：對外品牌、開發與控制者、底層模型、微調與提示、預定用途、禁止用途、客戶地區、代理結構、版本差異，以及誰有權改變功能。角色判斷需要這些事實。

Deployer 指在其權限下使用 AI 系統的自然人或法人，但個人非專業活動通常不在這個概念內。^[3] 歐盟企業用台灣 SaaS 處理招聘、信用、教育或工作管理時，可能是 deployer；台灣公司在自己的營運中使用第三方 AI，也可能在相關輸出於歐盟使用時面臨境外適用問題。

Deployer 的責任不只是按下按鈕。依風險與用途不同，它可能要依使用說明操作、監督輸入與輸出、保存紀錄、安排人工監督、告知受影響者，或完成基本權利影響評估。具體義務不能在未判定產品分類前一概而論。

內容平台尤其容易同時具有多個身分。平台自己開發 AI 推薦、標記或生成工具並提供給用戶，可能是 provider；使用第三方模型做內部內容審核，可能是 deployer；承載用戶上傳內容時，還有其他數位服務規範。把整個平台只寫成「deployer」，會把對外功能的 provider 義務漏掉。

通用型 AI 模型（GPAI model）可以被整合進大量下游系統。AI Act 對 GPAI provider 設有模型文件、向下游提供資訊、著作權政策與訓練內容摘要等義務；具有系統性風險的模型還有評估、對抗測試、事故通報與資安要求。^[2][8] 這些義務與某個下游客服或分析系統的風險分類不同。

歐盟委員會說明，GPAI 義務自 2025 年 8 月 2 日起對新的相關模型適用，既有模型有分階段調整期；AI Office 自 2026 年 8 月 2 日起可執法。^[8] 企業要檢查模型首次投放時間與版本，不應用單一日期涵蓋所有情形。

GPAI Code of Practice 是自願工具，目的是協助業者說明如何遵循法定義務。^[2] 自願不等於不重要：採用可能降低舉證摩擦；但它也不是法律本身，未簽署 Code 不代表自動違法，簽署也不保證任何產品全面合規。企業仍要對照正式法規與自身事實。

對台灣模型商而言，最重要的是維持模型與下游系統之間的文件接口。要能向整合商說明能力、限制、測試、訓練資料政策與安全措施；也要從下游取得必要的使用情境與事故回饋。若供應鏈雙方都把責任推給對方，最後通常是終端輸出出了問題卻找不到完整證據。

2026 年最直接影響 SaaS 與內容平台的，是 Article 50 透明義務。^[5] 它至少包含幾種不同情形。第一，設計用來直接與人互動的 AI 系統，provider 原則上要確保人們知道自己正在與 AI 互動，除非從情境上已很明顯。

第二，生成合成音訊、影像、影片或文字的系統，provider 要確保輸出以機器可讀方式標記，並可被偵測為人工生成或操弄，程度受技術可行性等條件約束。^[5] 這比較像系統層的技術能力，不只是畫面上放一行免責聲明。

第三，deployers 使用情緒辨識或生物特徵分類等特定系統時，要對受影響者履行告知。第四，deployers 發布 deepfake，原則上須揭露內容經人工生成或操弄；藝術、創作、諷刺等作品有較限定的揭露方式。第五，deployers 發布由 AI 生成或操弄、用於告知公共利益事項的文字，也有揭露義務；但若經人工審查或編輯控制，且有自然人或法人承擔編輯責任，條文設有例外。^[5][6]

這些義務的主體不同。底層模型商可能要提供可標記能力；SaaS provider 要把能力整合到系統；內容平台或媒體作為 deployer，可能要確保發布時對人揭露。若合約只寫「供應商保證符合 AI Act」，卻沒有規定標記資訊如何沿 API、檔案轉換與發布流程保留，透明度會在供應鏈中消失。

委員會 2026 年指南進一步說明 Article 50 的執行，並指出對 2026 年 8 月 2 日前已投放市場、涉及 Article 50(2) 的系統，provider 有至 2026 年 12 月 2 日的調整期。^[6] 因此，不能把所有既有生成式功能都寫成 8 月 2 日零時起立即同樣違規，也不能忽略年底節點。

台灣軟體與硬體產業擅長 OEM、ODM 與白牌合作。一套 AI 功能可能由台灣公司開發、由歐洲品牌命名、再交給企業客戶部署。商業上可以用契約分工，法定角色卻會看誰以自己的名稱投放；對高風險系統，還要看誰做實質修改或改變預定用途。^[3]

假設台灣公司提供一套通用客服引擎，法國品牌把它重新命名、加入產業知識庫並限定保險理賠用途。台灣公司可能仍是某些元件或原始系統的 provider，法國品牌也可能因自有品牌與用途控制承擔 provider 角色；最終保險公司則是 deployer。不能用「真正的 provider 只有一個」簡化。

另一個情境是台灣硬體商把視覺模型嵌入工業設備。設備若僅做品質檢測，與用於工作者績效或安全決策的風險可能不同。歐洲客戶若改變用途，可能改變角色與分類；供應商需要技術限制、用途聲明、變更通知及日誌，才能證明責任邊界。

合理推論｜高信心：白牌鏈最需要的不是一份籠統賠償條款，而是角色附表。每一版本應列出市場投放者、商標、模型、系統控制、預定用途、禁止用途、透明介面、事故通知與文件交付。法律角色不能完全由契約創造，但契約可以讓各方有能力履行真實角色。

2026 年的 AI Omnibus 於 7 月 27 日生效，調整部分高風險 AI 規則的時程。^[10] 委員會說明，Annex III 所列高風險用例的相關時程延至 2027 年 12 月 2 日；嵌入其他受管制實體產品的高風險 AI 系統則延至 2028 年 8 月 2 日。

這項變更容易被行銷成「歐盟 AI Act 延後」。它只對特定高風險規則與分類節點有影響，不會讓 2026 年開始的透明義務、GPAI 執法、禁用實務或治理準備一起消失。^[1][10] 企業若停止全部合規工作，會把不同法規時鐘混成一個。

延期也不代表高風險產品可以等到最後一年才盤點。判定系統是否涉及招聘、教育、關鍵服務、生物特徵或受管制產品，需要產品、法務與客戶共同整理用途；建立資料品質、日誌、風險管理、人工監督與供應鏈文件也需要時間。延後提供的是修正與實作窗口，不是無需準備的證明。

第一種是模型公司。若台灣團隊把自有 GPAI 模型透過 API 或下載方式向歐盟市場提供，它可能是 GPAI model provider；若又推出完整聊天或分析應用，也可能同時是 AI system provider。公司要分開模型文件、下游資訊與應用層透明控制，不能用一份模型卡涵蓋全部產品。

第二種是 SaaS 公司。即使底層模型來自第三方，只要台灣公司以自有品牌提供一套有特定目的的 AI 系統，它仍可能是系統 provider。歐盟企業客戶可能是 deployer，代理商可能是 importer 或 distributor。若 SaaS 允許客戶自由改變用途，還要以產品限制、契約與監測處理分類漂移。

第三種是內容平台。平台提供生成工具時可能是 provider；用 AI 審核內容時是 deployer；發布或協助發布 deepfake、公共利益文本時，又要檢查 Article 50 的揭露責任。平台需要追蹤內容來源、合成標記是否在壓縮與轉檔後保留、人工編輯責任由誰承擔，而不只是新增「AI 生成」按鈕。

這三種公司還可能互相重疊。一家有自研模型的內容 SaaS，完全可能同時擁有所有角色。AI Act 的難處就在於角色是沿著產品鏈生成，不是由營業登記項目決定。

第一份是產品線角色矩陣。逐列記錄模型、AI 系統、功能、品牌、投放者、歐盟客戶、代理、終端用途、可能角色與待確認事實。不要只列公司名稱；同一產品的企業版、API 版與白牌版可能有不同結論。

第二份是歐盟連結清單。整理歐盟營收、用戶、代理商、資料輸出使用地、行銷頁面與合約服務範圍。對「不知道輸出在哪裡使用」的 API，要設計客戶聲明、地區控制或用途資訊，而不是把未知當成不存在。

第三份是版本與控制證據。保存底層模型版本、微調、系統提示、資料來源、評估、已知限制、人工監督、標記機制與變更紀錄。角色與風險可能因實質修改而改變，沒有版本紀錄就無法重建當時產品狀態。

第四份是責任接口。契約要規定誰提供技術文件、誰保留日誌、誰處理事故與主管機關詢問、誰維持標記、誰告知終端使用者，以及白牌或用途改變時如何重新評估。這份接口不能替代法定責任，卻能避免每一方都以為別人會做。

已確認的是，AI Act 有明確的境外適用路徑；台灣公司沒有歐盟法人，並不足以排除規範。2026 年 8 月 2 日是 AI Office 執法與特定透明義務的重要節點，GPAI、既有系統與高風險規則則各有分階段時程。^[1][4][8]

已確認的另一面，是 provider、deployer、GPAI model provider、importer 與 distributor 各自對應不同市場行為。底層模型不是自己訓練，不代表自有品牌 SaaS 一定不是系統 provider；企業客戶也不必然是唯一 deployer。

合理推論｜高信心：台灣企業最大的短期風險，是用公司自稱代替產品鏈分析。白牌、重新命名，以及高風險系統的實質修改或用途改變，會讓角色沿著供應鏈移動。合規工作若沒有逐版本角色矩陣，容易對錯產品、錯角色、錯日期做準備。

仍未知的是，每個產品的最終分類、主管機關執法優先順序、透明標記技術標準與個案措施。本文不能替任何公司做法律結論；這些都需要依實際產品、契約與部署進一步判斷。

對台灣模型商、SaaS 與內容平台而言，AI Act 的第一份交付物不應是一張「已合規」徽章，而是一幅誠實的產品鏈地圖：模型從哪裡來，誰把它變成系統，誰用自己的品牌提供，誰決定用途，輸出在哪裡被使用，誰能在出錯時重建紀錄。只有先回答每個環節的「我是誰」，企業才知道該履行哪一組義務，也才有能力在歐盟開始真正執法時提出可驗證的答案。