AI 規範圖出你該守的規則

以前 AI 政策只剩空話，現在我把規範拆成你能直接照做的規則。

我盯 AI 政策一陣子了。老實說，最煩的不是它變多，而是很多團隊還在用一張紙想解決所有事：寫個 policy、貼個 trust statement、交差。這招在 demo 時代還能混，產品一旦碰到招募、授信、醫療、內容審核，整個就會露餡。你以為自己在做治理，其實只是把風險包裝得比較像樣。

真正讓我想通的，是我去看了 Wikipedia 的人工智慧規範頁。它不是某家廠商的漂亮框架，反而因為夠雜，才把現場長什麼樣講清楚：硬法、軟法、各國規則、國際倡議，還有 trustworthy AI、responsible AI、ethical AI 這些常被混著用的字。很多時候，它們根本不是同一回事。

我把這頁拆一拆，抓出對開發者真的有用的部分。不是空泛辯論，是你在寫產品、過法務、做 launch gate 時，會真的撞到的結構。你如果在台灣做 AI 產品，這篇就是給你一份可以直接抄的治理骨架。

AI 規範不是一本法典，是一堆壓力疊在一起

“The regulatory and policy landscape for AI is an emerging issue in jurisdictions worldwide.”

白話翻譯就是：你找不到一本讀完就結案的 AI 法規大全。你面對的是地方性法律、產業法規、國際指引、標準、公司內規一起壓下來。只看單一 checklist，通常就是自己騙自己。

我以前跟工程團隊講 AI 治理，他們最常問我一句：到底合不合法？我懂，這問題很自然，但太乾淨了。現實比較像：哪個國家、哪個場景、哪個風險等級、哪個部門先看。這些條件一變，答案就變。

Wikipedia 也提到像 OECD、IEEE 這種不一定直接執法的機構，也在塑造 AI 該怎麼被看待。這代表規範不只有法律，還包括標準、原則、框架。你如果只看法條，會錯過很多在法條落地前就先定調的東西。

實操寫法很簡單：不要找「一份 AI 政策」，改成做「政策堆疊」。

• 一層管產品風險分級。
• 一層管各地法規差異。
• 一層管內部審核與核准。
• 一層管紀錄、稽核、事件處理。

這聽起來很官僚，我知道。但被法務追著問、被客戶稽核、被主管機關點名的時候，官僚至少還能救命。

軟法最容易被嫌煩，卻最早決定你會不會踩雷

“Since 2016, numerous AI ethics guidelines have been published in order to maintain social control over the technology.”

翻譯一下就是：很多政府和機構會先丟原則、指南、守則，先把大家的期待框起來，再慢慢往硬法走。這些文件單獨看不一定有強制力，但它們會先變成大家講話的共同語言。

頁面裡提到 Partnership on AI、IEEE Global Initiative on Ethics of Autonomous and Intelligent Systems、OECD AI Principles。它們不是法條，但它們會影響採購問卷、企業客戶審查、風險部門怎麼問你問題。你如果看不懂這套語言，policy 寫得再漂亮也像沒上過場。

我看過不少團隊把 soft law 當公關文案。結果一到 enterprise sales，對方問的每一題都剛好踩在那些原則上。更麻煩的是，出事後主管機關也常拿這些原則回頭問：你當時有沒有合理注意？

實操寫法：把軟法當成早期預警系統。

• 先列出你對外宣稱的原則。
• 對照客戶常要求的框架。
• 把每個原則翻成一個控制項。
• 寫清楚誰負責、怎麼測、多久重看一次。

像「透明」這種字不要只留在簡報裡。它至少要對應到 model card、使用者揭露、紀錄保存、以及可解釋流程。

硬法慢，但它真的決定你能不能上線

“The European Union adopted in 2024 a common legal framework for AI with the AI Act.”

這句話的意思很直接：AI 規範已經從政策討論，走到可執行義務。EU AI Act 是最清楚的訊號之一。它不是唯一要看的一條，但很多團隊會拿它當參考座標，因為它把風險分級治理講得很具體。

Wikipedia 也寫到，美國聯邦機關在 2024 年推出了 59 項 AI 相關規範，45 個州合計提出將近 700 項 AI 相關法案。這代表美國不是在等一部超大聯邦法一次收工，而是機關命令、州法壓力一起來。你的產品只要碰美國市場，就不能假裝那邊還沒開始動。

這裡最常出事的是產品團隊。大家很會想 launch，不太會先想 classification。但規範看的是 use case，不是你模型名字叫什麼。拿來聊天的 bot 跟拿來做招募篩選、醫療分流，待遇本來就不一樣。

實操寫法：建立 use-case inventory，不要只管 model inventory。

• 列出每個對外功能。
• 寫清楚它影響什麼決策。
• 標出上線地區。
• 標記是否碰到權益、存取、或安全。

如果你只追模型版本號，很多真正的風險你根本沒記到。

真正該管的是責任歸屬，不只是準確率

“AI governance... encompass[es] the questions of who is accountable for AI systems, what elements are governed, when governance occurs within the development lifecycle, and how it is implemented through frameworks, tools, or models.”

白話翻譯就是：治理不是哲學課，是責任地圖。系統出事時，不能只說「是供應商的模型」或「是 AI 團隊的事」。組織內部一定要有人對這個風險負責。

Wikipedia 也提到，部署 AI 的組織在建立 trustworthy AI、遵守原則、承擔風險緩解責任上，扮演核心角色。這句很重要，因為它直接打掉一種常見偷懶：上游模型商不會替你扛下游後果。你只要把它放進產品，你就在鏈上。

我自己最有感的是這件事。模型可能來自 API，但 prompt、閾值、人工覆核、使用者看到的說法，全都是你自己的。只要使用者依賴這個結果，你就不可能假裝自己只是轉發別人的輸出。

實操寫法：責任一定要寫進文件，不要只停在 Slack。

• 每個 AI 功能都指定 business owner。
• 每個模型或工作流都指定 technical owner。
• 高風險場景要有 legal 或 risk reviewer。
• 補上事件、申訴、覆寫的升級路徑。

最好把這些責任放進 release 流程。能不能上線，不該等到出事後才問。

政策字眼會變，別拿漂亮詞當治理

“Trustworthy AI”, “responsible AI”, and “ethical AI” have shifted in meaning over time and are often used interchangeably.

翻譯一下就是：政策文件裡的詞會老化，而且老得比產品快。兩年前看起來很精準的字，今天可能已經很空。問題是很多團隊超愛把這些詞直接貼進文件，卻從來沒定義。

頁面引用 Charlotte Stix 的觀察，我覺得很準。你如果寫了「ethical AI」，但沒寫出對應控制，那不是治理，那是品牌文案。trustworthy、responsible、human-centered 這些詞都一樣，聽起來很順，落地卻常常是空的。

我也整理過很多文件，裡面每段都在換同義字，像在比誰比較會寫字。通常那代表大家都不想寫出那句難看的話：規則是什麼、誰執行、失敗怎麼辦。

實操寫法：把抽象標籤改成操作定義。

• 不要寫 transparent，改寫要揭露什麼。
• 不要寫 fair，改寫要做哪種偏誤檢查。
• 不要寫 safe，改寫哪個門檻會擋 release。
• 不要寫 accountable，改寫誰核准、誰背書。

如果一個詞不能被翻成控制項，就直接刪掉。省事，也比較誠實。

節奏問題才是麻煩，政策得比模型跑得快

“AI technology is rapidly evolving leading to a ‘pacing problem’ where traditional laws and regulations often cannot keep up.”

意思很簡單：你不能等法規完全講清楚才開始做控制。等規則定案，你的系統大概已經改兩輪了。真正該做的是，讓你的政策可以跟著變，不要每次都重寫。

這點我很有感。很多團隊想等「最終答案」，但 AI 的現實不是這樣。你要做的是建立一個能吸收新規則的流程，而不是等一份完美政策。也就是說，風險審查、文件版本、變更管理、區域追蹤，這些都要先有。

Wikipedia 也提到，硬法會慢，部分原因是 AI 應用太多樣，既有機關的管轄範圍又有限。這不是叫你躺平，是叫你把治理做成軟體：模組化、可測試、可更新。

實操寫法：做成活文件，不要做成 PDF 墳場。

• 高風險功能固定週期重審。
• 政策版本跟 code 一樣留紀錄。
• 按地區和產業追蹤法規變化。
• 留一組可以快速加強的控制項。

政策一改，團隊要知道改了什麼、為什麼改。沒這件事，大家最後只會照舊做。

跨國協調很重要，因為 AI 本來就不守邊界

“In 2023, the United Kingdom started a series of international summits on AI.”

白話翻譯就是：AI 規範不是單一國家的故事。頁面提到 AI Safety Summit、AI Seoul Summit、AI Action Summit in Paris、AI Impact Summit in New Delhi。各國雖然細節不同，但都在試著對齊一些共同問題。

這件事對做全球產品的人很重要。你的功能可能在一個市場上線，在另一個市場被審查，第三個市場的客戶又帶著不同期待來問你。如果你只看公司註冊地在哪裡，通常會漏掉真正的暴露面。

我在 enterprise 案子裡也常看到這種狀況。某個區域的客戶要一份文件，另一個市場又要不同標準。最後你的「一份 policy」變成三份，然後大家還是覺得自己有統一治理。

實操寫法：做 region-aware controls。

• 追蹤每個功能在哪些地區可用。
• 存放各地需要的揭露文字。
• 維護一張區域義務對照表。
• 指定人追蹤跨境政策變化。

如果你賣全球，合規故事也得是全球版。只靠一份本地想像，撐不住。

可抄的模板

# AI Governance Policy Template

## 1) Scope
This policy applies to all AI systems, models, prompts, datasets, and automated decision workflows used by the company.

## 2) Definitions
- AI system: any software that generates predictions, content, recommendations, classifications, or decisions using statistical or machine-learning methods.
- High-impact use case: any AI feature that affects employment, credit, housing, healthcare, education, legal status, safety, access to services, or materially important decisions.
- Human review: a trained person who can inspect, override, or block AI output before it is acted on.

## 3) Ownership
For each AI feature, the team must name:
- Business owner
- Technical owner
- Risk/legal reviewer for high-impact use cases
- Incident responder

## 4) Use-case inventory
Before launch, record:
- Feature name
- Purpose
- Model/provider
- Data sources
- User-facing outputs
- Jurisdictions where it ships
- Whether it is high-impact
- Required disclosures

## 5) Risk classification
Classify each feature as:
- Low risk
- Medium risk
- High risk

A feature is high risk if it can influence rights, access, safety, or materially important decisions.

## 6) Required controls
### Low risk
- Basic documentation
- Logging enabled
- User disclosure if AI output is visible

### Medium risk
- Documented testing
- Human review for sensitive outputs
- Bias and quality checks
- Rollback plan

### High risk
- Formal approval before release
- Written legal/risk review
- Human override path
- Audit log retention
- Incident response procedure
- Periodic re-review after launch

## 7) Disclosure rules
If users interact with AI or rely on AI-generated outputs, the product must disclose:
- That AI is being used
- What the AI is used for
- Any material limitations
- Whether a human can review or override the output

## 8) Testing and validation
Before release and after material changes:
- Test for accuracy on representative cases
- Test for bias and disparate outcomes where relevant
- Test for prompt injection or misuse if the system is user-facing
- Record results and remediation steps

## 9) Change management
Any material change to model, prompt, data source, threshold, or user workflow requires:
- Versioning
- Re-review of risk classification
- Updated documentation
- Approval for high-risk systems

## 10) Incident response
If an AI system causes or may cause harm:
- Pause or disable the feature if needed
- Notify the owner and reviewer
- Preserve logs and prompts
- Investigate root cause
- Record corrective actions
- Decide whether customer notice is required

## 11) Review cadence
- Low risk: annual review
- Medium risk: semiannual review
- High risk: quarterly review and after any material incident

## 12) Exceptions
Any exception must be:
- Written
- Time-limited
- Approved by the business owner and risk/legal reviewer
- Reviewed again before expiry

## 13) Attestation
By launching or operating this AI feature, the owners confirm that the required controls are in place and the documentation is current.

Owner: ____________________
Date: _____________________
Feature: __________________
Risk level: ________________

這份模板不花俏，但我就是要它不花俏。它把「我們應該做 AI policy」變成一份可運作的文件：有 owner、有風險、有審核、有事件處理。這樣才像真的能拿去跑。

如果是我先落地，我會先做兩件事：先補 inventory，再補 ownership。這兩塊先補起來，很多混亂會直接少一半。接著加 disclosure 跟 incident response，因為那是最容易被拖到出事才補的部分。

最後別把它丟在法務資料夾裡當裝飾。放到產品、工程、PM 真正在看的地方，讓它變成 launch gate 的一部分。沒人會看的 policy，本質上就是漂亮廢紙。

原始拆解來源是 Wikipedia：Regulation of artificial intelligence。我這篇的框架、白話翻譯和模板是我自己整理的，但底層概念、機構名稱與脈絡，主要衍生自該頁與其引用來源。