EU AI Act 台灣工程師合規指南：從風險分類到最小合規路徑

你的 HR 篩選工具、信用評分功能、AI 客服系統，有哪些算是「高風險 AI」？大多數台灣工程師不知道答案，但這個答案決定了你在 2026-08-02 之前要做的事。

歐盟 AI 法案（EU AI Act）的高風險 AI 義務即將在 2026 年 8 月 2 日全面生效，違規最高罰 €15M 或全球營收 3%。跟 GDPR 一樣，這套法規不管你公司在哪裡，只要 AI 輸出影響到歐盟境內的人，就在管轄範圍內。

這篇文章給台灣 AI/SaaS 工程師一條可執行的路線：5 分鐘自評是不是高風險 → 確認自己的法規角色 → 用最小成本準備技術文件 → 4 個月倒數行動計畫。不需要律師，你就能完成前三步。

TL;DR

• 只要 AI 產品輸出影響歐盟境內用戶，不管公司註冊在哪，都受 EU AI Act 管轄
• 高風險 AI（履歷篩選、信用評分、醫療決策等）的合規截止日是 2026-08-02
• 用 Claude/GPT API 開發產品，你同時是 Deployer（對模型）和 Provider（對自家產品），兩套義務都要承擔
• 現在合規的最強推動力是 B2B 客戶的採購要求，不是罰款恐懼（截至目前零罰款紀錄）
• 先用官方 Compliance Checker 做 5 分鐘自評，這是最先該做的事

你的 SaaS 在 EU AI Act 管轄範圍嗎？

很多台灣工程師的第一反應是「我公司又不在歐洲，關我什麼事？」答案是：EU AI Act 採用輸出地原則（output-based jurisdiction），跟 GDPR 一樣。不管 provider 設立在哪，只要你的 AI 系統被「放置於歐盟市場」或「投入歐盟服務」，就受規管。

白話翻譯：你的 SaaS 有歐洲用戶在用，你的 AI 輸出影響到歐盟境內的自然人，那你就在射程範圍內。

具體來說，以下情境都會觸發義務：

• 你的 HR SaaS 被歐洲分公司拿來篩選履歷
• 你的 FinTech 產品被歐洲客戶用於信用評估
• 你的 AI 客服系統處理歐洲用戶的查詢

「我只有幾個歐洲用戶，也要管嗎？」坦白說，法規沒有設「小到不需要管」的門檻。高風險 AI 系統的義務不分規模，都適用。但別恐慌，先做完 Annex III 自評再說。如果你的系統根本不是高風險，很多重型義務都跟你無關。

Annex III 自評：5 分鐘判斷你的 AI 是不是高風險

這是整個合規流程最重要的第一步，但也是最常被跳過的。根據工程師社群的觀察，大多數人拿到合規要求後直接去寫 Annex IV 技術文件，結果跳過了風險分類。問題是，如果你的系統根本不是高風險 AI，你寫了一堆文件也沒用。

Annex III 列出 8 大類高風險 AI 系統。台灣 SaaS 最常命中的是這三類：

類別	Annex III 分類	台灣常見 SaaS 落點
就業管理	第 4 類	HR 篩選、績效評估、升遷/解僱決策
基本服務	第 5 類	信用評分、貸款審核、保險定價
生物辨識	第 1 類	人臉辨識、身分驗證系統

值得注意的例外：純反詐欺用途的 AI 不列高風險。如果你的 FinTech 產品只用 AI 抓異常交易，不涉及信用評分，可能不在高風險範圍。

實際操作：打開歐盟官方 Compliance Checker，這是專為中小企業設計的免費互動工具，5-10 分鐘就能完成自評。結果會告訴你：

• 非高風險 → 只需滿足基本透明度要求（告知用戶在與 AI 互動），壓力大幅降低
• 高風險 → 需要繼續往下走，準備技術文件、人類監督機制等

先分類，再決定文件，這個順序很重要。

Provider 還是 Deployer？用 API 開發 SaaS 的責任邊界

確認是高風險之後，第二個關鍵問題是：你在這條 AI 價值鏈上扮演什麼角色？

Article 3 定義了兩個核心角色：

• Provider：以自己名義開發 AI 系統並投入市場的個人或法人
• Deployer：在職業活動中使用 AI 系統的自然人或法人

聽起來很清楚，但實際情況是：如果你用 Claude 或 GPT API 開發自家 SaaS 產品，你同時是兩個角色。

對底層模型（Claude/GPT），你是 Deployer，需要遵守 Article 26 的義務（依指示使用、確保輸入資料品質、監控運作）。但對你自己品牌推出的完整 AI 產品，你是 Provider，需要承擔 Articles 9-22 的全套義務（技術文件、CE 標誌、風控系統、EU 資料庫登記）。

角色	主要義務	適用法條
Provider	技術文件、風控系統、CE 標誌、EU 資料庫登記、符合性評估	Articles 9-22
Deployer	依指示使用、輸入資料品質、運作監控、指派合格監督人員	Article 26

有個常見的誤解是「我用 OpenAI 的 API，合規是 OpenAI 的事」。不是這樣的。OpenAI 對他們的 GPAI 模型有自己的義務，但你對自家產品的 Provider 義務是獨立的，不能互相抵消。

更要注意的升格規則：如果你對第三方 GPAI 模型做了實質修改，或者加上自己的品牌重新包裝用途，你直接升格為完整的 Provider，承擔全套義務。

建議行動：建立一份 AI Inventory（AI 清冊），列出每個 AI 功能模組，逐一確認角色：

AI 功能	底層模型	對模型角色	對產品角色	義務等級
履歷篩選	Claude API	Deployer	Provider	Articles 9-22 + 26
AI 客服	GPT API	Deployer	Provider	Articles 9-22 + 26
內部分析工具	自訓模型	N/A	Provider	Articles 9-22

Annex IV 技術文件 MVP：小型團隊的最小可行版本

如果你確認是高風險 AI 的 Provider，就需要準備 Annex IV 技術文件。聽起來很嚇人，但核心其實是：整理你已有的設計決策記錄，不是從零開始寫一本書。

Annex IV 有 9 個章節，以下是每個章節的「最小可行版本」：

章節	內容	你可能已有的對應文件
1. 一般描述	系統用途、版本、預期用戶	產品 README、PRD
2. 開發元素	架構、訓練方法、資料來源	架構圖、設計文件
3. 監控與控制	能力限制、特定族群準確率	測試報告、監控 dashboard
4. 效能指標	準確率、誤判率、公平性指標	模型評估報告
5. 風險管理系統	已識別風險與緩解措施	風控文件、incident log
6. 變更記錄	版本歷史、重大更新	Git log、changelog
7. 標準適用	採用哪些標準或替代方案	合規對照表
8. 符合性聲明	EU 符合性聲明副本	需新建
9. 上市後監控	持續監控計畫	監控 SOP

法規明確允許中小企業以「簡化方式」提交，而且歐盟委員會計畫推出 SME 專用簡化表格（截至 2026 年 4 月尚未正式發布）。

根據業界經驗，如果你開發時有持續記錄設計決策，準備這些文件大約需要 40-80 小時。最大的工作量不在「寫新文件」，而在「把散落各處的記錄對應到 Annex IV 框架」。

有個技術標準上的現實必須面對：CEN-CENELEC 的 harmonized standards 預計要到 2026 年底才能完成，但合規截止日是 2026-08-02。這代表截止日之前不會有完整的官方技術標準。

目前業界最佳替代路徑：用 ISO 42001（AI 管理系統標準）作為框架，搭配西班牙 AESIA 指南（目前唯一完整的 EU AI Act 實施指南）。這些在任何時間點都有效，不會因為未來標準出爐就白費。

Article 14 人類監督的工程實作：不只是一個按鈕

Article 14 要求高風險 AI 系統必須設計為允許人類有效監督。很多工程師的直覺是「那就加一個 Override 按鈕」，但這遠遠不夠。

工程師社群的共識是：meaningful override 是架構設計問題，不是 UI 問題。如果你的 audit trail 在異常時 fallback 到允許模式（allow-mode），那你製造的是虛假的合規紀錄。

Article 14 的 5 大工程要求：

1. HMI 介面工具：提供 dashboards、alerts 讓操作者即時監控 AI 決策異常
2. 可中止機制：操作者必須能真正阻斷 AI 輸出，不只是在 UI 上「忽略」
3. 防自動化偏誤設計：系統需要讓人員保持對過度依賴 AI 的意識
4. 解讀工具：提供可解釋性工具，讓監督人員理解 AI 為何做出某個決策
5. 能力邊界揭露：讓監督人員清楚系統的限制在哪裡

設計原則是 fail-closed：AI 系統不確定時，預設應該拒絕做決策，而不是預設允許。這跟大多數工程師的直覺相反，但這才是法規要求的「meaningful」的含義。

具體檢查清單：

• 異常時系統預設拒絕決策（fail-closed），而非預設通過（fail-open）
• audit trail 記錄每次人類介入，且無法被系統自動繞過
• 監督人員有實際授權和技術能力執行 override
• override 機制在系統架構層面生效，不只是前端 UI

2026-08-02 倒數 4 個月：行動計畫

根據 Orrick 發布的合規指南，以下是 6 大步驟。好消息是：步驟 1-3 一個人就能完成。

步驟 1：AI Mapping（本週就能做）

逐部門盤點所有 AI 系統與 GPAI 模型，包含透過 API 存取的工具。列出每個系統的用途、資料來源、影響對象。

步驟 2：角色確認（本週就能做）

對每個系統確定你是 Provider、Deployer、還是兩者皆是。參考前面的 AI Inventory 表格。

步驟 3：Annex III 風險分類（本週就能做）

用官方 Compliance Checker 完成每個 AI 功能的自評。如果全部都不是高風險，恭喜你，後續的重型義務都不適用。

步驟 4：技術文件（4-5 月）

針對高風險系統，開始將現有設計文件對應到 Annex IV 9 章節框架。用 ISO 42001 作為治理架構基礎。

步驟 5：合約更新與盡職調查（5-6 月）

修訂 AI 服務合約，處理第三方 API 的授權修改權限。確認上游 GPAI 供應商的合規狀態。

步驟 6：AI 治理框架（6-7 月）

建立內部 AI 政策、AI 素養訓練機制、跨部門協作流程。AI 素養義務其實從 2025-02-02 就已經生效了。

如果你的產品確定是高風險 AI 且需要面對歐洲市場，還有一項隱形成本：EU 境內授權代理人（Authorized Representative）。非歐盟公司的高風險 AI Provider 必須在歐盟境內指定一位授權代理人。根據業界估算，透過第三方合規服務商指定代理人的年費大約 €2,000-5,000，這應該納入合規預算規劃。

台灣 AI 基本法：雙軌還是擇一？

台灣《人工智慧基本法》在 2026-01-14 正式施行，但跟 EU AI Act 有個根本差異：台灣法案對私部門沒有直接罰款義務。它是原則性框架，不是合規清單。

結論是雙軌並行，但 EU AI Act 才是有強制力的那個。好消息是，如果你按 EU AI Act 的標準做了技術文件和治理框架，台灣 AI 基本法的要求基本上也同時涵蓋。一套文件可以適配兩邊。

執法現況與合規的真實驅動力

需要誠實面對的現實是：截至 2026 年，27 個歐盟成員國中只有 8 個正式設立了 AI Act 執法機構，而且目前零罰款紀錄。歐盟委員會提出的 Digital Omnibus 草案甚至可能把高風險義務延後到 2027 年底。

那為什麼現在要行動？

真正的驅動力不是罰款恐懼，是 B2B 客戶壓力。 根據 AIF 知勢的分析，台灣電子零組件（41.3%）和資通訊產品（19.3%）高度命中歐盟高風險類別。歐洲企業採購 SaaS 時已經開始要求合規聲明。先完成合規的台灣公司，在 B2B 銷售上直接多了一張牌。

幾個常被忽略的風險：

LLM API + GDPR 的交叉義務：如果你的系統把含有個人資料的 prompt 傳給第三方 LLM API（像是用 Claude 處理歐洲用戶的履歷），同時觸發 GDPR 的 DPA（資料處理協議）義務。最低成本的解法是在送給 LLM 之前先剝除個人識別資料。大多數工程師完全沒意識到這一層。

跨法規重疊：如果你在金融科技領域，可能同時要面對 DORA（數位營運韌性法案）+ GDPR + AI Act 三套法規。DORA 的 4 小時事件通報窗口跟 AI Act 的文件要求可能產生工程衝突，需要提前規劃。

Digital Omnibus 不是免死金牌：即使草案通過（還需要歐洲議會和理事會批准），最多延後 16 個月。現在開始做 AI Mapping 和文件整理的成本不會因為延後而白費，ISO 42001 框架在任何時間點都有效。而且，不合規的歷史紀錄未來可能成為追溯對象。

結論

EU AI Act 對台灣工程師的影響是真實的，但合規路徑比法規條文讀起來更可操作。最常見的錯誤是跳過分類直接寫文件，或者假設「用第三方 API 就不用自己管」。

你今天就能做的第一步：打開官方 Compliance Checker，花 5 分鐘完成 Annex III 自評。結果會告訴你到底需要做到什麼程度，可能比你想的輕鬆很多。