歐盟 AI 法案與顧客 WiFi：行銷人員需要知道的事
歐盟 AI 法案（Regulation 2024/1689）引入了基於風險的框架，直接影響場所營運商如何部署 AI 驅動的 WiFi 行銷、Captive Portal 和顧客分析。本指南將該法案的四個風險等級與實際的顧客 WiFi 使用案例進行對照，識別包括情緒推論和社會評分在內的禁用行為，並為在餐旅、零售、活動和公共部門環境中運作的 IT 團隊和行銷總監提供可操作的合規步驟。了解您的部署在風險光譜中所處的位置，並針對 AI 聊天機器人和對話式入口網站實施第 50 條的透明度義務，已不再是可選項目：禁用行為的執法已於 2025 年 2 月開始。
收聽此指南
查看播客逐字稿
執行摘要
歐盟人工智慧法案（EU AI Act，法規 2024/1689）是全球首部針對人工智慧的全面性法律框架，並直接適用於場域營運商如何在 Guest WiFi 基礎架構中部署 AI。該法案將 AI 系統劃分為四個風險等級：禁用、高風險、有限風險和極低風險，並據此分配法規遵循義務。對於大多數 餐飲旅宿 與 零售 營運商而言，最直接的營運影響落在兩個領域：第一，確保 Captive Portal 上的任何 AI 驅動對話介面皆帶有明確的第 50 條透明度揭露；第二，審計現有的行銷技術堆疊，以確認其未使用禁用的實踐行為，例如情緒推論、社會評分或基於敏感屬性的生物特徵分類。
第 5 條規定的禁用實踐條款已於 2025 年 2 月開始強制執行。附件 III 下的高風險系統義務將自 2026 年 8 月起適用。違反禁用實踐的罰鍰最高可達 3,500 萬歐元或全球年營業額的 7%。本指南為 IT 經理、網路架構師和合規主管提供技術參考，協助其評估目前的部署並在本季度實施所需的變更。
技術深度解析
四級風險框架
歐盟 AI 法案根據 AI 系統對基本權利、安全和民主價值造成的風險進行分類。此分類決定了適用於提供者（AI 系統的開發商或供應商）和部署者（將系統投入服務的組織，通常為場域營運商或 IT 團隊）的合規義務。
對應至 Guest WiFi 和場域行銷情境的四個等級如下：
| 風險等級 | AI 法案條款參考 | WiFi 行銷範例 | 合規義務 |
|---|---|---|---|
| 禁用 | 第 5 條 | 對 Portal 互動進行情緒推論；對訪客進行社會評分；依種族/宗教進行生物特徵分類 | 立即停止；不允許任何部署 |
| 高風險 | 附件 III | 在 Captive Portal 進行生物特徵驗證；用於存取基本服務的 AI 畫像分析 | 符合性評估、技術文件、風險管理系統、歐盟資料庫註冊 |
| 有限風險 | 第 50 條 | Captive Portal 上的 AI 聊天機器人；生成式 AI 歡迎頁面；情緒識別系統（非禁用情境） | 在互動前/互動期間向終端用戶進行透明度揭露 |
| 最低風險 | 無特定義務 | 總體人流量分析；停留時間熱點圖；基於規則的個人化；頻寬優化 AI | 無 AI Act 特定的義務（GDPR 仍適用） |
第 5 條規定的禁用行為
AI Act 第 5 條定義了八類禁用的 AI 行為。其中三類與場域 WiFi 行銷部署直接相關。
操縱性與欺騙性技術。 該法案禁止部署潛意識、操縱性或欺騙性技術以扭曲個人行為並損害其做出知情決定之能力的 AI 系統，且此類行為會造成或可能造成重大損害。在 WiFi 行銷的情境中，這主要針對利用在 Captive Portal 擷取的行為訊號（如點擊猶豫、滾動模式、頁面停留時間）來推斷心理弱點並提供操縱性優惠的系統。關鍵門檻在於重大損害；監管機構將根據具體情境進行評估，但原則很明確：繞過理性自主權的 AI 驅動誘導行為是不被允許的。
社會評分。 該法案禁止根據個人的社會行為或個人特徵對其進行評估或分類，進而導致不利或不友善對待的 AI 系統。若 WiFi 會員系統使用 AI 模型根據行為模式（造訪頻率、停留時間、購買訊號）對顧客進行評分，進而限制存取速度或對評分較低的顧客扣留優惠，即屬於此禁用範圍。允許的個人化與禁用的社會評分之間的區別在於，該 AI 分類是否會產生不利對待：為優質顧客提供更好的優惠屬於個人化；拒絕評分較低的顧客存取服務則屬於社會評分。
敏感屬性的生物識別分類。 該法案禁止使用生物識別數據來推斷敏感屬性的 AI 系統，包括種族、政治觀點、工會成員身份、宗教或哲學信仰、性生活或性取向。這對於結合使用攝影機分析與 WiFi 數據的場域尤為相關。如果 AI 系統將裝置 MAC 位址數據與視覺分析進行交叉比對，以推斷種族並據此提供個人化內容，這將直接違反第 5 條規定。無論該生物識別數據是即時處理還是批次處理，此禁用規定皆適用。 情緒推論 — 適用範圍釐清。 該法案禁止在工作場所和教育機構中進行情緒推論。此禁令不會自動延伸至針對顧客的零售場所、飯店或體育場館。然而，如果您的場所同時也是工作場所 — 例如企業園區、共享工作空間、醫院 — 且您對連接到 guest WiFi 的員工使用情緒推論，這將是被禁止的。場所營運商在假設情緒推論禁令不適用之前，應仔細盤點其使用者群體。
附件三（Annex III）規定的高風險系統
該法案的附件三列出了被歸類為高風險的使用案例。對於 Guest WiFi 部署，有兩個類別直接相關。
第一，生物辨識系統：遠端生物辨識系統（不包括僅確認人員身分的簡單生物特徵驗證）以及推論敏感或受保護屬性的生物特徵分類系統均屬於高風險。如果您的 Captive Portal 使用臉部辨識來驗證回訪顧客，該系統則需要進行完整的合規性評估、技術文件記錄、貫穿系統生命週期的風險管理系統，並在歐盟人工智慧法案（EU AI Act）資料庫中進行註冊。
第二，個人畫像分析：附件三中列出的任何 AI 系統，如果對個人進行畫像分析（定義為自動處理個人資料以評估個人生活的各個方面，包括偏好、興趣、行為、位置或移動軌跡），則一律被視為高風險。這一條款最有可能影響到建立持續性個人畫像並將其用於自動化行銷決策的 WiFi Analytics 平台。關鍵問題在於，該 AI 系統是否根據畫像特徵，對個別顧客做出自動化決策，或對其產生實質性影響。
第 50 條透明度義務 — 當務之急
對於當今大多數場所營運商而言，第 50 條是營運上最相關的條款。它涵蓋了三種情境：
對話式 AI 系統（第 50(1) 條）：提供者必須確保旨在與自然人互動的 AI 系統在設計上能讓使用者知悉其正在與 AI 系統互動，除非從情境中顯而易見。部署者必須確保此類資訊揭露已落實。這適用於部署在 Captive Portal 上的任何 AI 聊天機器人 — 無論是用於顧客服務、飯店入住協助、場館導航還是行銷諮詢。
情緒識別與生物特徵分類（第 50(3) 條）：情緒識別系統或生物特徵分類系統的部署者，必須告知接觸這些系統的自然人。這是一項獨立於聊天機器人揭露之外的義務，即使在系統未被禁止的情況下也同樣適用。
合成內容 (第 50(4) 條)：生成合成語音、影像、影片或文字內容的 AI 系統，必須將該內容標記為 AI 生成。如果您的 Captive Portal 使用生成式 AI 來產生個人化的歡迎訊息或促銷文案，則該內容必須予以標記。
AI 法案與 GDPR：多層次的合規架構
AI 法案並非取代 GDPR，而是平行運作。對於場域營運商而言，這意味著這兩個架構的合規義務同時適用於 AI 驅動的 WiFi 行銷部署。
在 GDPR 規範下，與 AI 驅動的 WiFi 行銷相關的條款包括：第 6 條（處理的合法基礎）、第 9 條（特殊類別資料 — 若處理生物特徵資料則相關）、第 13/14 條（隱私聲明中的透明度義務）、第 22 條（對自動化個人決策的限制），以及第 35 條（針對高風險處理的資料保護影響評估）。
AI 法案則增加了：第 5 條（禁用行為合規性）、第 50 條（在 AI 互動點的透明度揭露），以及 — 針對高風險系統 — 第 8-17 條（風險管理、技術文件、符合性評估、註冊）。
在 GDPR 要求針對高風險資料處理進行 DPIA 的地方，AI 法案則要求針對高風險 AI 系統建立風險管理系統。這兩者可以且應該保持一致：將涵蓋資料處理風險 (GDPR) 與 AI 系統風險 (AI 法案) 的單一整合式評估結合，不僅更有效率，還能向監管機構展現成熟的治理姿態。
GDPR 第 22 條與 AI 驅動的 Captive Portal 特別相關。它限制了僅憑自動化決策對個人產生法律或類似重大影響的行為。如果您的 AI 系統在沒有人工監督的情況下，針對 WiFi 存取層級、促銷資格或服務品質做出自動化決策，您需要評估第 22 條是否適用，以及您是否必須為顧客提供要求人工審查的權利。
實作指南
步驟 1：建立您的 AI 資產清單
在評估合規性之前，您需要完整掌握 WiFi 行銷技術堆疊中每個 AI 系統的輪廓。這意味著除了您自己的部署之外，還必須包括嵌入在第三方平台中的 AI 組件 — 行銷自動化工具、分析儀表板、Captive Portal 廠商和 CRM 整合。
針對每個系統，記錄：系統功能、其處理的資料、提供商及任何次級處理商、AI 法案下的風險層級，以及適用的合規義務。此清單是您 AI 法案合規姿態的基礎，且在監管機構要求提供盡職調查證明時將是必需的。
步驟 2：對照風險層級為每個系統進行分類
將此四級框架套用至您清單中的每個系統。分類問題如下：
- 該系統是否使用了第 5 條所列的任何做法？如果是，則屬於禁用類別 — 請停止部署。
- 該系統是否用於生物特徵驗證、存取服務的個人特徵分析，或任何其他附件 III 的使用案例？如果是，則屬於高風險 — 請開始規劃合規性評估。
- 該系統是否以對話方式與自然人互動、生成合成內容或進行情緒識別？如果是，則屬於有限風險 — 請實施第 50 條的揭露要求。
- 以上皆非？則屬於極低風險 — 無 AI Act 的特定義務，但仍必須遵守 GDPR。
步驟 3：實施第 50 條揭露要求
對於您 Captive Portal 上的任何 AI 聊天機器人或對話介面，請在互動開始前實施明確的揭露。該揭露必須是顯著的 — 不能是隱含的，也不能埋在條款與條件中。在工作階段開始時，顯示「您正在與 AI 助理聊天」的簡單 UI 元素即可滿足此義務。這是一項前端變更，而非系統重建，且應可在單一 Sprint 內部署完成。
對於在您的場域中運作的情緒識別系統（在未被禁用的情況下），請在運作區域增設顯眼的告示，告知顧客正在使用情緒識別系統。
步驟 4：審查第三方供應商子處理者協議
作為部署者，您與供應商共同承擔因使用禁用做法而產生的法律責任。請審查您與 WiFi 行銷平台提供商、分析供應商以及 Captive Portal 供應商的合約。要求其明確確認其 AI Act 分類與合規性文件。增訂合約條款，要求供應商在其次級 AI 系統發生任何可能影響風險分類的變更時通知您。
步驟 5：與 GDPR 治理保持一致
讓您的資料保護官（DPO）參與 AI Act 合規流程。更新您的處理活動紀錄（ROPA），以納入 AI 系統分類。若高風險資料處理依 GDPR 要求需進行 DPIA，請將其擴展至涵蓋 AI Act 的風險管理要求。確保更新您的隱私權聲明，以反映 AI 驅動的處理程序與第 50 條的揭露內容。
步驟 6：規劃高風險系統合規（2026 年 8 月截止期限）
若您的任何系統被歸類為高風險，請立即開始合規性評估流程。考慮到技術文件準備、風險管理系統實施以及歐盟資料庫註冊所需的時間，2026 年 8 月附件 III 系統的截止期限比想像中更近。請儘早與您的供應商聯絡，以瞭解他們能提供哪些文件，以及您作為部署者需要產出哪些內容。
最佳實踐
在 AI 部署中採用「隱私設計（Privacy-by-Design）」方法。 AI 法案對高風險系統的要求（包括整個生命週期的風險管理、數據治理、技術文件）在系統架構設計之初就融入其中，會比事後改造更有效率。在評估新的 AI 驅動行銷工具時，請將 AI 法案合規要求與 GDPR 合規性以及 ISO 27001 和 PCI DSS 等安全標準一同納入您的採購標準中。
優先選擇第一方、基於同意的數據，而非推導出的屬性。 該法案的禁用行為和高風險分類主要針對推導敏感特徵或對個人做出重大自動化決策的 AI 系統。使用明確同意的第一方數據（例如電子郵件地址、聲明的偏好、會員計劃資格）來推動個人化服務的系統，其監管風險顯著低於從行為訊號中推導特徵的系統。
保持網路營運 AI 與行銷 AI 的分離。 用於網路管理的 AI 系統（如頻寬分配、干擾緩解、負載平衡）在該法案下屬於極低風險。而用於顧客輪廓分析和行銷個人化的 AI 系統則具有較高風險。在架構上保持這些系統的分離，可以簡化您的風險分類，並限制行銷技術棧中任何合規問題的波及範圍。
參考 IEEE 802.1X 和 WPA3 進行驗證架構設計。 在 Captive Portal 使用生物識別驗證時，請確保底層驗證架構符合當前標準。IEEE 802.1X 提供基於連接埠且具備強驗證功能的網路存取控制，而 WPA3 則為無線層提供增強的加密。這些標準不綁定特定廠商，且在企業安全框架和 GDPR 關於適當技術措施的指引中均有引用。
記錄您的 AI 法案合規決策。 即使是極低風險的系統，記錄您的分類理由也能向監管機構證明您已盡到盡職調查。AI 法案要求高風險系統的提供者在將系統投放市場前記錄其評估；作為部署者，為您自己的風險評估保留同等的記錄是最佳實踐。
疑難排解與風險緩解
風險：廠商的 AI 實踐不透明。 許多行銷自動化和 WiFi 分析平台嵌入了未明確說明的 AI 功能。緩解措施：向所有廠商發送正式的 AI 法案合規問卷。要求其提供系統分類、技術文件以及避免禁用行為的證明。在全新和續簽的合約中，將符合 AI 法案納入合約條款要求。
風險：Captive Portal 聊天機器人缺乏第 50 條規定的揭露。 這是目前部署中最常見的合規漏洞。緩解措施：審計您的 Captive Portal 使用者介面。如果任何對話式 AI 介面缺乏明確的互動前揭露，這將是優先修復的項目。此修復僅需幾天即可部署 UI 變更。
風險：分析平台建立個人設定檔，觸發高風險分類。 如果您的 WiFi 分析 平台建立持續性的個人設定檔並用於自動化行銷決策，您可能在未進行必要符合性評估的情況下，運行著一個高風險系統。緩解措施：審查平台的數據模型。如果系統正在建立個人設定檔並用於自動化決策，請與您的供應商討論其 AI 法案分類，並啟動符合性評估程序。
風險：將 GDPR 與 AI 法案合規視為獨立的工作流程。 將 GDPR 和 AI 法案合規交由不同團隊管理的企業，將面臨工作重複、漏洞以及文件不一致的風險。緩解措施：建立統一的 AI 治理框架，同時應對這兩個法規框架。單一整合的 DPIA/AI 風險評估流程更有效率，且更具防禦力。
風險：情緒推論範圍的錯誤分類。 情緒推論的禁令適用於工作場所和教育機構。同時也是工作場所的場所（如企業園區、醫院、共同工作空間）必須將此禁令應用於面向員工的系統，而不僅僅是面向顧客的系統。緩解措施：規劃您的使用者群體，並將此禁令應用於員工可能受到情緒推論影響的所有情境。
投資報酬率與商業影響
遵守歐盟 AI 法案並不純粹是成本支出。在執法浪潮前建立 AI 治理框架的企業，將獲得可衡量的競爭優勢。
降低監管風險。 違反禁用實踐的罰款高達 3500 萬歐元或全球年度總營業額的 7%，這對任何在歐盟成員國大規模營運的企業來說，都代表著實質的財務風險。主動的合規姿態可消除此風險敞口。
供應商差異化。 隨著 AI 法案合規成為採購要求，能夠展示清晰風險分類、透明 AI 實踐以及符合第 50 條規定介面的平台，將比無法做到的平台更受青睞。對於評估 WiFi 行銷平台的 旅宿餐飲業 和 零售業 營運商而言，AI 法案合規文件正成為標準的 RFP 要求。 顧客信任與第一方數據品質。 妥善履行第 50 條規定的透明度義務，能有效提升顧客的信任度。當顧客了解 AI 如何應用於其互動過程時，他們更傾向於進行真實的互動，並提供更高品質的第一方數據。這將直接提升個人化模型的精準度以及行銷活動的投資報酬率（ROI）。
透過統一治理提升營運效率。 將 GDPR 與 AI Act 合規架構整合為單一治理結構的企業，能減少法務、IT 和行銷團隊之間的重複工作。隨著監管環境持續演變，投資建立此架構將帶來長遠回報——AI Act 之後還會推出更多針對 AI 的法規，而成熟的治理態勢將提供穩固的基石。
對於 大眾運輸 營運商和公共部門機構而言，鑑於公共空間中的 AI 系統受到更嚴格的審查，遵守 AI Act 顯得尤為重要。主動合規能向監管機構和公眾展現負責任的態度，進而支持更廣泛的數位信任目標。
欲深入閱讀相關合規架構，請參閱我們的 加拿大 Guest WiFi 的 PIPEDA 合規指南 ，該指南涵蓋了加拿大背景下類似的同意與透明度要求。
線上收聽：歐盟 AI Act 與 Guest WiFi 播客
關鍵定義
提供者 (歐盟人工智慧法案)
開發 AI 系統或通用 AI 模型，或委託他人開發 AI 系統或通用 AI 模型，並以其自身名稱或商標將其投放市場或投入使用的自然人、法人、公共機構、機關或其他團體，無論是收費還是免費。
在 Guest WiFi 的情境中，提供者通常是 WiFi 行銷平台廠商或 AI 個人化引擎的開發商。根據該法案，高風險系統的提供者承擔最沉重的合規義務。
部署者 (歐盟人工智慧法案)
在其自身授權下使用 AI 系統的自然人、法人、公共機構、機關或其他團體，但該 AI 系統是在個人非專業活動過程中使用之情況除外。
場所營運商（如飯店集團、零售連鎖店、體育場館營運商）即為部署者。部署者負責履行第 50 條的透明度揭露義務，並確保其使用的 AI 系統符合該法案的要求，即使這些系統是由第三方提供的也是如此。
生物特徵分類系統
旨在根據自然人的生物特徵數據（如面部、動作、步態、姿勢、聲音、外觀、行為或其他生理或行為特徵）將其歸入特定類別的 AI 系統。
適用於結合 AI 使用基於攝影機的分析或裝置指紋識別的場所營運商。根據第 5 條，禁止從生物特徵數據中推斷敏感屬性（種族、宗教、政治觀點）的系統。根據附錄三，進行生物特徵分類但不推斷敏感屬性的系統可能被視為高風險系統。
情緒識別系統
旨在根據自然人的生物特徵數據識別或推斷其情緒或意圖的 AI 系統。
根據第 5 條，在工作場所和教育機構中禁用。在其他場所情境（零售、餐旅業）中，情緒識別系統根據附錄三被列為高風險系統進行監管，並要求部署者根據第 50(3) 條通知受影響的人員。行銷「基於情緒」或「參與狀態」功能的廠商應對照此定義進行評估。
個人畫像分析
對個人資料進行的任何形式的自動化處理，即利用個人資料來評估與自然人相關的某些個人層面，特別是分析或預測與該自然人的表現、經濟狀況、健康、個人偏好、興趣、可靠性、行為、位置或移動相關的層面。
附錄三中列出的 AI 系統如果對個人進行畫像分析，一律被視為高風險系統。建立持久個人畫像並將其用於自動化行銷決策的 WiFi 分析平台，必須對照此定義進行評估，以確定其是否屬於高風險系統。
社會評分
在一段時間內，根據自然人或群體的社會行為或已知、推斷或預測的個人或性格特徵對其進行評估或分類，且該社會評分會導致在與最初產生或收集數據的情境無關的社會情境中，對這些人或群體進行損害性或不利的對待。
根據第 5 條予以禁止。在 WiFi 行銷情境中，這針對的是根據賓客的行為模式進行評分，並利用這些評分來限制存取、拒絕提供優惠或提供較差服務的 AI 系統。關鍵要素是「不利對待」——為高價值賓客提升體驗的個人化服務不屬於社會評分，除非它同時使評分較低的賓客處於不利地位。
Captive Portal
在向新連接的 WiFi 網路使用者授予更廣泛的網際網路存取權限之前，向其呈現的網頁或驗證閘道。場所營運商用其來收集賓客數據、呈現服務條款並發送行銷內容。
AI 驅動的 WiFi 行銷之主要部署介面。Captive Portal 上的 AI 功能（聊天機器人、個人化歡迎頁面、推薦引擎）須遵守第 50 條的透明度義務。Captive Portal 通常也是獲取 GDPR 數據處理同意的地點。
符合性評估
驗證高風險 AI 系統是否符合歐盟人工智慧法案中所規定要求的過程，這些要求包括風險管理、數據治理、技術文件、透明度、人工監督、準確性、穩健性和網路安全。
高風險 AI 系統在投放市場或投入使用前必須進行此評估。對於附錄三中的大多數高風險系統，提供者可以進行自我評估。對於生物特徵識別系統，則需要第三方評估。部署高風險 AI 系統的場所營運商需要確保其廠商已完成所需的符合性評估並能提供相關文件。
DPIA (數據保護影響評估)
根據 GDPR 第 35 條，針對可能對自然人的權利和自由帶來高風險的處理操作所要求的程序。DPIA 必須描述處理過程、評估必要性和比例性，並識別和減輕風險。
根據 GDPR，高風險數據處理（包括大規模畫像分析和對公共可存取區域的系統性監控）需要進行此評估。在人工智慧法案的情境下，DPIA 應擴展到涵蓋 AI 系統風險管理要求，從而建立一個同時滿足兩個監管框架的統一評估。
第 50 條透明度義務
歐盟人工智慧法案第 50 條的要求，即提供者應確保旨在與自然人互動的 AI 系統在設計上能讓這些人獲知他們正在與 AI 系統互動，除非從情境中可以明顯看出這一點。部署者必須確保此揭露機制落實到位。
對於在 Captive Portal 上擁有 AI 聊天機器人或對話介面的場所營運商而言，這是最能立即執行的合規義務。該揭露必須清晰且提前進行（在互動開始之前），而不是隱藏在條款和條件中。適用於所有 AI 對話系統，不論其風險等級為何。
範例
一家在五個歐盟成員國營運、擁有 450 間客房的酒店集團，在其 Captive Portal 上部署了 AI 驅動的聊天機器人，以處理房客入住查詢、餐廳推薦和 WiFi 故障排除。該聊天機器人由第三方 LLM 平台提供技術支援。行銷團隊還使用了一個 WiFi 分析平台，該平台可以建立個人房客檔案（包括訪問歷史、在場館區域的停留時間以及推斷的人口統計細分），以便透過 Captive Portal 登入頁面提供個人化的促銷優惠。CTO 需要在下次董事會會議之前評估這兩個系統的 AI Act 合規狀況。
步驟 1 — 對聊天機器人進行分類。 AI 驅動的聊天機器人是一個與自然人互動的對話式 AI 系統。根據第 50(1) 條，它屬於「有限風險」（Limited Risk）系統。立即採取的行動是在 Captive Portal 使用者介面上實施明確的互動前揭露：『您正在與 AI 助理聊天。』這是一個前端變更。即使底層 LLM 是由第三方提供，酒店集團作為部署者（deployer）也必須負責此項揭露。審查供應商合約以確認提供商的 AI Act 分類，並索取其技術文件。
步驟 2 — 對分析平台進行分類。 該 WiFi 分析平台建立個人房客檔案，並利用這些檔案透過自動化決策提供個人化優惠。關鍵問題在於，這是否構成附件 III（Annex III）下的個人畫像（individual profiling）— 即評估偏好、興趣、行為和位置的個人資料自動化處理。如果是，該系統即為「高風險」（high-risk）。索取供應商的 AI Act 分類文件。如果供應商將該系統分類為「極低風險」（minimal risk），請取得其書面合理解釋並評估其是否站得住腳。如果系統屬於高風險，請在 2026 年 8 月截止日期之前開始規劃符合性評估（conformity assessment）合規工作。
步驟 3 — 審計推斷的人口統計細分。 如果分析平台使用 AI 模型推斷包含敏感屬性（年齡段、性別、國籍）的人口統計細分，請評估這是否構成第 5 條規定的敏感屬性生物識別分類。如果細分是基於宣告的資料（會員計劃資格、明確提供的偏好）而非來自行為訊號的 AI 推斷，則風險較低。如果是透過行為訊號進行 AI 推斷，則需要進行仔細的法律審查。
步驟 4 — 與 GDPR 保持一致。 確保酒店集團的隱私權聲明反映了 AI 驅動的處理方式以及第 50 條的揭露內容。根據 GDPR 第 6 條審查分析處理的合法基礎。如果處理是基於正當利益，請進行一項考慮到 AI Act 風險分類的正當利益評估。更新 DPIA 以涵蓋 GDPR 和 AI Act 的風險維度。
一家在德國、法國和荷蘭擁有 120 家門市的國家零售連鎖店，正在評估一個新的 WiFi 行銷平台，該平台包含一個被供應商稱為「基於情緒的個人化」的 AI 功能 — 該系統分析房客與 Captive Portal 互動的速度和模式，以推斷其「參與狀態」，並相應地調整在登入頁面上提供的促銷內容。IT 總監需要評估此功能在歐盟 AI Act 下是否被允許。
步驟 1 — 識別 AI 實踐。 「基於情緒的個人化」功能分析行為訊號（互動速度和模式）以推斷「參與狀態」— 這在功能上屬於情感或心理狀態。這屬於情緒推斷（emotion inference）。
步驟 2 — 應用第 5 條禁止性測試。 第 5 條禁止在工作場所和教育機構中進行情緒推斷。對於房客而言，零售商店並非工作場所，因此這一特定禁令不適用於零售情境中的房客群體。然而，如果該功能部署了操縱性技術以扭曲行為並損害知情決策，從而造成重大損害，則根據第 5(1)(a) 條，該功能仍可能被禁止。利用推斷出的情緒狀態來提供操縱性的促銷內容 — 例如，針對被識別為「沮喪」的房客提供基於緊迫感的優惠 — 很可能落入此禁令範圍。
步驟 3 — 評估 GDPR 影響。 根據 GDPR，從行為資料中推斷情緒狀態構成了基於畫像分析目的的個人資料處理。必須評估此處理的合法基礎。正當利益不太可能成為用於行銷目的之情緒推斷的合理依據。明確同意是最合適的基礎，但同意機制必須是具體且細緻的 — 同意 WiFi 存取並不構成對情緒推斷的同意。
步驟 4 — 建議。 在沒有詳細法律評估的情況下，請勿部署「基於情緒的個人化」功能。違反第 5 條（特別是操縱禁令）的風險是實質存在的。要求供應商提供該功能在 AI Act 分類下的法律分析。如果供應商無法提供站得住腳的分類，請將該功能視為禁用功能且不要啟用。基於客觀指標（訪問頻率、一天中的時間、宣告的偏好）的標準行為個人化是允許的，且合規風險顯著降低。
練習題
Q1. 您場所的 WiFi 行銷平台廠商剛發布了一項名為「訪客情緒評分」的新功能，該功能透過分析訪客在 Captive Portal 互動時的速度、順序和猶豫模式，來評定情緒分數（正向、中立、挫折），並據此調整所提供的宣傳內容。廠商的說明文件將此描述為「行為分析」而非「情緒識別」。作為 IT 總監，您如何評估此功能在歐盟人工智慧法案（EU AI Act）下的合規狀態，以及您會採取哪些行動？
提示：專注於系統的技術功能，而非廠商的行銷用語。請思考：該系統實際上在做什麼？它是否正透過行為訊號推斷情感或心理狀態？然後應用 Article 5 的禁止測試與 Article 50 的透明度測試。
查看標準答案
無論廠商如何標記，該功能在實質上就是一個情緒識別系統。分析互動模式以推斷「挫折」或「正向情緒」屬於情緒推斷。第一步是應用 Article 5 的禁止測試：此系統是否用於工作場所或教育機構？如果該場所是零售店或飯店，則 Article 5 的工作場所禁止規定不適用於訪客。然而，如果系統利用推斷出的情緒來提供具操縱性的內容（例如：針對「感到挫折」的訪客提供基於緊迫感的優惠），則可能適用 Article 5(1)(a) 的操縱禁止規定。第二步是評估該系統是否屬於 Annex III 所列的情緒識別系統，這將使其被歸類為高風險。第三步是要求廠商提供書面的人工智慧法案分類與法律分析。如果廠商無法提供具說服力的分類說明，請勿啟用該功能。無論結果如何，皆應記錄您的評估理由。
Q2. 一家經營 60,000 人容量場館的體育場營運商，使用 Purple 的 Guest WiFi 平台在活動中收集第一方數據。行銷團隊希望在 Captive Portal 上部署一個 AI 聊天機器人，以回答球迷關於設施、商品和即將舉行活動的諮詢。該聊天機器人由第三方 LLM API 驅動。場館的法務團隊詢問：Article 50 的義務是什麼、誰負責合規，以及在實務上該如何落實？
提示：識別部署者（deployer）、提供者（provider）以及適用的 Article 50 情境。然後具體說明揭露聲明必須呈現的外觀以及應在何時出現。
查看標準答案
體育場營運商為部署者（deployer）；LLM API 提供者為提供者（provider）。根據 Article 50(1)，部署者有責任確保訪客在開始互動前，已被告知他們正在與 AI 系統進行互動。在實務落實上，需要在 Captive Portal 使用者介面上顯示清晰的揭露聲明（例如在發送第一條訊息前顯示「您正在與 AI 助理聊天」等標章或引導訊息）。這是對 Captive Portal 範本的前端調整。該揭露聲明必須明確且顯眼，不能隱藏在服務條款中。LLM 提供者作為提供者有其自身的義務（技術文件、使用說明），但部署者不能依賴提供者來履行部署者自身的透明度義務。此外，體育場營運商必須確保聊天機器人的數據處理符合 GDPR — 必須確立處理對話中分享之任何個人數據的合法基礎，且隱私權聲明必須反映此 AI 驅動的處理程序。
Q3. 某家零售連鎖店的 WiFi 分析平台兩年來一直在建立個人訪客畫像，將 WiFi 連線階段數據（裝置 MAC 位址、停留時間、造訪頻率、店內位置）與 CRM 數據（購買歷史、會員計劃等級）相結合，以輸入至 AI 模型中，進而自動決策在 Captive Portal 向每位訪客提供哪些促銷優惠。該連鎖店新任的合規主管被要求評估此系統在歐盟人工智慧法案 Annex III 個人畫像條款下是否屬於高風險。其評估方法與可能的結果為何？
提示：應用 Annex III 的個人畫像（individual profiling）測試：該 AI 系統是否對個人數據進行自動化處理，以評估個人的偏好、興趣、行為或位置？然後考慮這些自動化決策是否重大到足以觸發高風險分類。
查看標準答案
評估方法分為三個步驟。首先，確認該系統為 AI 系統（而非簡單的基於規則的引擎）— 如果促銷決策是由機器學習模型而非確定性的規則引擎做出，則它屬於 AI 系統。其次，應用 Annex III 個人畫像測試：該系統正在處理個人數據（WiFi 連線階段數據、CRM 數據）以評估個人偏好、興趣、行為和位置。這符合個人畫像的定義。第三，評估該系統是否列於 Annex III 的使用案例中 — 最相關的類別是「獲取和享受基本的公共與私人服務」，其中包括用於評估服務獲取資格的 AI 系統。促銷優惠決策是否構成「獲取服務」屬於灰色地帶；如果該 AI 系統可以拒絕訪客獲取實質影響其購買決策的促銷優惠，監管機構可能會認為這是重大的。可能的結果是，該系統應被視為具有潛在的高風險，並應進行正式評估。該連鎖店應與平台廠商聯繫以取得其人工智慧法案分類，啟動 DPIA/AI 風險評估，並在 2026 年 8 月截止日期前開始規劃符合性評估合規工作。
繼續閱讀本系列
如何設定 SCEP 以實現自動化企業級 WiFi 憑證註冊
本指南說明如何設定 SCEP（簡單憑證註冊協定）以實現自動化企業級 WiFi 憑證註冊，涵蓋從 PKI 和 NDES 到 MDM 設定檔部署以及 RADIUS 驗證的完整架構。本指南專為飯店、零售連鎖店、體育場館、會議中心和公共部門組織的 IT 經理、網路架構師和 CTO 所設計，旨在協助他們淘汰預先共用金鑰，並實作具擴充性、基於身分識別的 802.1X EAP-TLS 驗證。Purple 獨立於硬體的雲端重疊平台可直接與此架構整合，提供與憑證驗證員工網路並行的訪客和 BYOD WiFi 層。
企業 SCEP 指南：部署簡單憑證登錄協定以實現自動化校園 WiFi 安全
本技術參考指南為使用 SCEP 的企業 WiFi 憑證部署提供了權威的架構藍圖和逐步實施策略。內容涵蓋 SCEP 與 PKCS 之間的核心差異、成功部署所需的確切順序，以及 IT 主管的實際風險緩釋策略。
如何實施 SCEP 以實現自動化 WiFi 憑證登錄
本指南說明如何在企業場域中實施 SCEP（簡單憑證登錄協定）以實現自動化 WiFi 憑證登錄。內容涵蓋完整的架構藍圖——從 PKI 設計和 MDM 整合到強制性的三步驟部署流程——並向 IT 主管和網路架構師展示如何消除共享認證、自動化憑證生命週期管理，以及大規模滿足 PCI DSS 和 GDPR 的要求。