2026 美國 AI 法規控管地圖

以前大家只要交一份美國 AI 政策就夠，現在得先做一張可追溯的控管地圖。

我追 AI 法規這件事，真的有點像盯 production incident。不是因為我愛看法條，是因為它老是卡進實際上線流程。你以為產品只要過一次法務就能全美開跑，結果州法先跳出來；你以為聯邦會先定調，結果又是行政命令、機關指引、州議會提案一起亂舞。整個局面很像大家都在寫規則，但沒人願意先把責任講清楚。

我最近一直回頭看 Software Improvement Group 的 2026 US AI legislation overview，因為它很直接地點出一件事：現在要交的不是一套漂亮說法，而是證據。你有沒有系統清單、誰負責、在哪裡跑、適用哪些州、測過什麼，這些才是會被問的東西。

先承認一件事：美國 AI 規則就是碎的

“The complexity of federalism still makes a unified AI policy difficult.”

翻譯一下就是，美國沒辦法靠一份全國統一的 AI 政策直接收工。只要你的系統碰到多州使用者，你就不能假設一份內部政策能蓋住全部情境。這不是理論問題，是你 release 時會不會踩到州法的問題。

SIG 提到，到 2026 年 3 月，45 個州已經提出 1,561 件 AI 相關法案，而且這個數字已經超過 2024 年全年總量。這個數字我看了只想翻白眼，因為它代表的不是熱鬧，是維運成本。州級追蹤現在已經是 release planning 的一部分，跟隱私、無障礙、資安一樣，不能再當成法務桌上的附錄。

我之前幫一個產品團隊看美國推薦系統上線，他們原本的想法很單純：法務簽一次，全美上。結果一拉使用者地理分布、資料流向、產品用途，風險就分裂了。某些州會在告知、選擇退出、影響評估或人工審查上要求不同東西。單一政策直接失效。

實操寫法很簡單：先做一張 jurisdiction matrix。每個 AI 系統至少記四件事：公司在哪、服務在哪跑、使用者在哪、可能適用哪些州法。這張表不要寫得漂亮，寫得準就好。只要這四格答不出來，你就還沒準備好做合規審查。

• 系統名稱
• 部署地區
• 使用者地理分布
• 可能適用的州法

別再把 AI 當旁支，先把系統盤點做出來

SIG 這篇我最認同的地方，是它一直強調 evidence of control。白話就是，你要能拿出一份真的有用的 AI inventory。不是簡報，不是願景圖，是每個模型、每個供應商、每個 owner、每個資料來源都列得出來的清單。

也就是說，團隊現在要做的不是先寫一份很厚的 AI governance policy，而是先知道自己到底有多少 AI。很多公司嘴上說沒有大規模導入，實際上 prototype、外掛、SaaS、browser plugin、workflow automation 全都在偷偷用。等到出事才找，通常都找不乾淨。

我看過最常見的破口，就是 shadow AI。某個產品經理拿 hosted model 做 demo，客服團隊裝了摘要工具，營運同仁把 API 接進表單流程。半年後大家才發現公司裡早就不是「有沒有 AI」的問題，而是「誰在管這堆 AI」的問題。

實操寫法是先做 AI register，欄位不要少。至少要有：系統名稱、用途、業務 owner、技術 owner、供應商、模型類型、資料來源、部署地區、使用者族群、人工監督、法律狀態。欄位不知道就寫 unknown，不要硬裝完成。假裝完整只會讓後面的人更痛苦。

• 業務 owner
• 技術 owner
• 供應商或模型提供者
• 部署環境
• 決策影響程度

聯邦政策還在動，別拿行政命令當終局

SIG 提到 Executive Order 14365，簽於 2025 年 12 月 11 日，內容是要求聯邦機關推動一個「minimally burdensome」的國家 AI 架構，還設了 AI Litigation Task Force 去挑戰被認為和聯邦政策不一致的州法。這不是完整答案，這只是白宮想先把方向拉住。

翻譯一下就是，聯邦層級現在想往一個方向推，但州政府還是照自己的節奏寫可執行的規則。國會之前也不是沒試著把州法壓掉，像那個 10 年 freeze 的提案就被參議院 99 比 1 拿掉了。這種局面下，指望聯邦直接把州法清空，基本上是在賭政治，不是在做法遵。

我很常看到工程或產品團隊把 executive order 當成「那應該就定了吧」。沒有這種事。行政命令會影響機關行為、採購與執法方向，但它不等於一部完整的 AI statute。你如果把 compliance roadmap 建在未來某個 preemption 勝利上，那你是在拿 release schedule 當籌碼。

實操寫法：你的合規計畫要分兩條線。第一條管現在已經生效的州級義務，第二條追聯邦動向，像是採購規範、機關 rulemaking、訴訟進度。聯邦真的變了，就更新第二條；第一條不要亂刪。

我會固定看這些來源：白宮 2025 年 1 月的 AI 相關行政命令、White House AI Action Plan、NCSL AI Legislation Database，還有 MultiState。這幾個至少比靠印象可靠。

高風險模型的管制會從側門回來

SIG 說美國政府正在考慮對 frontier AI model 加上 pre-release evaluation 要求，理由是國安風險。它還提到 CAISI，也就是重新命名後的 US AI Safety Institute，已經跟 Google、Microsoft、xAI 做 evaluation 合作。這個訊號其實很清楚：你不能把「放鬆」解讀成「沒人管」。

也就是說，越接近 frontier capability 的系統，越可能被要求先測、先審、先留紀錄再上線。名詞可能變，控制樣式不太會變：你要證明自己有看過、有測過、有留痕，才准放出去。

我做過幾輪資安審查後，對這套流程很有感。最順的團隊，通常不是模型最強的那批，而是早就把 evaluation logs、red-team notes、model card、incident response path、release approval 都準備好的人。最慘的永遠是那種說「先上線，之後補文件」的團隊。那種文件通常永遠補不完。

實操寫法：只要你的系統接近 frontier 級別，就先定一份 pre-release checklist。至少包含安全評估、誤用測試、隱私審查、資安審查、rollback 條件。若你用第三方模型，就直接跟供應商要同樣證據。拿不出來，不是小缺口，是採購問題。

這裡我會順手看 Anthropic、Microsoft、Google 的 AI blog、xAI 的公開資訊，因為 SIG 提到的合作對象就是這些。

州法會各走各的，所以控制項要能拆開

SIG 最實用的一點，是它把州法講得很直接：州級規則已經在生效，而且可執行。這代表你的控制設計不能是一整坨全國通用的文字。你需要的是可以依地區、用途、產品面拆開的控制模組。

翻譯一下就是，同一個模型在不同場景可能要過不同關卡。招募工具、消費者 chatbot、詐欺偵測，不能因為都叫 machine learning 就放在同一個桶子裡。你如果把 policy 寫得太泛，法務看不懂，工程也不知道怎麼做。

我以前看過一家公司把所有東西都叫「AI governance」，聽起來很完整，實際上完全沒法用。有人問這份 policy 有沒有管 employment decision，有沒有管 biometric data，有沒有管 consumer disclosure，結果大家翻三份文件加一個沒人信的 SharePoint folder，最後還是沒答案。

實操寫法：把控制拆成可重用模組。像是 inventory、human oversight、model evaluation、vendor review、incident handling、jurisdiction mapping 這幾塊分開做。之後每個 AI 系統依風險和地理位置掛上對應模組。這樣 legal、security、product 才有共同語言，不會每次都重新吵一輪。

• 盤點模組
• 風險模組
• 供應商模組
• 法域模組
• 上線核准模組

我會怎麼跟團隊說：先證明你有控管

如果要我把 SIG 這篇壓成一句話，我會說：別再問 AI 有沒有被管，先問你能不能證明自己有控管。這篇一直在繞同一件事打轉，只是角度不同而已。美國沒有一部乾淨俐落的聯邦 AI 法。州法在動。聯邦 preemption 還在吵。高風險模型可能會更嚴。那代表內部證據比想像重要得多。

也就是說，今年能活得比較穩的團隊，不是最會講 AI 故事的那批，而是能快速回答基本題的人：有哪些系統、誰負責、在哪裡跑、用了什麼資料、適用哪些法域、上線前測了什麼。這些都不性感，但就是工作。

我自己的建議很直白：把 AI governance 當 release engineering 做，不要把它當 policy memo。只要你沒辦法從 idea 追到 deployment，再追到 oversight，你就一定會被 surprise。這種 surprise 通常不是小插曲，是延期。

可抄的模板

# AI System Compliance Register

## 1) System details
- System name:
- Business purpose:
- Product or workflow:
- Business owner:
- Technical owner:
- Vendor / model provider:
- Model type:
- Deployment date:

## 2) Where it runs
- Hosting region:
- Cloud / on-prem / hybrid:
- User geographies:
- Data residency constraints:

## 3) What it touches
- Input data types:
- Personal data used? (yes/no):
- Sensitive data used? (yes/no):
- Automated decision-making? (yes/no):
- Human-in-the-loop? (yes/no):

## 4) Jurisdiction check
- Federal obligations:
- State obligations:
- Sector-specific obligations:
- Pending legislation watched:
- Legal reviewer:

## 5) Controls and evidence
- Risk assessment completed? (yes/no)
- Safety / misuse testing completed? (yes/no):
- Security review completed? (yes/no):
- Privacy review completed? (yes/no):
- Vendor due diligence completed? (yes/no):
- Release approval recorded? (yes/no):
- Monitoring plan defined? (yes/no):
- Incident response path defined? (yes/no):

## 6) Ownership and review
- Review cadence:
- Next review date:
- Change trigger events:
- Escalation contact:

## 7) Evidence links
- Policy link:
- Test report link:
- Approval record link:
- Monitoring dashboard link:
- Vendor contract / DPA link:

## 8) Decision
- Approved / conditionally approved / rejected:
- Conditions:
- Notes:

這份模板就是我把 SIG 那篇話翻成工程可用版本：先盤點，再看法域，再留證據。你只要能把每個 AI 系統都填成這樣，基本上就已經比多數團隊多走好幾步。

原始來源是 Software Improvement Group 的 “AI legislation in the US: A 2026 overview”。我這篇是把它拆成實務版 checklist，裡面有些判斷與模板是我自己整理出來的，但法律脈絡和來源引用都來自 SIG。