滿 18 歲的勾選框有替代品了：Win11 年齡 API 只交區間，生日留在微軟手上

微軟把年齡驗證從勾選框升級成作業系統服務：應用程式只拿得到年齡區間與驗證狀態，生日期料不出帳戶，而英國、歐盟與加州排隊生效的法規，正把這份作業派給所有作業系統業者。

每一臺 PC 上大概都有一個最沒有人當真的按鈕：「我已年滿 18 歲」。輸入生日可以亂填，支付資訊核驗成本高，第三方身分核驗更少有應用程式真的做。多年來，數位世界的年齡閘門大致靠這幾種湊合的方式運轉，大家心照不宣。

微軟現在打算把這道閘門收歸作業系統。9 月 4 日，微軟透過官方文件與 Windows SDK 最新發布說明，揭曉 Windows 11 的系統級年齡驗證設計：今年稍晚，一套全新的 API 將向「已註冊」的應用程式提供使用者年齡段與驗證狀態。整份方案最關鍵的一句話是，應用程式拿不到使用者的具體出生日期。

兩個 API，一道註冊閘門

第一個 API 叫 GetUserAgeRangeAsync，回傳的是年齡區間：10 歲以下（0 至 9 歲）、10 至 12 歲、13 至 15 歲、16 至 17 歲、18 歲以上，外加「未知」。微軟的邏輯很直接：對年齡驗證場景來說，應用只需要知道使用者是否低於某個門檻，給區間就夠用，沒有必要給精確年齡。

第二個 API 是 GetAgeVerificationStatusAsync，回傳驗證狀態：已驗證、未驗證、已選擇退出、暫時不可用、不適用。兩者搭配，開發者能據此調整內容、限制功能、套用家長監護，並處理 COPPA（美國《兒童線上隱私保護法》）之類的兒童安全法規遵循，全程不必強制收集或儲存任何人的生日。

第三道設計是閘門。開發者呼叫 API 前，必須先向微軟的數位安全平臺註冊，平臺驗證呼叫方身分之後，才會回傳有效值。換句話說，並非任何安裝在電腦上的程式都能讀取年齡訊號，「誰有資格問年齡」本身也被納入管制。

時程也值得記下。微軟明言這些 API 目前尚未在執行階段啟用，今年稍晚的版本才會正式上線；在那之前，呼叫不會回傳任何年齡資料，應用應維持原本的預設行為。對開發者來說，現在能做的是把介接邏輯寫好，等開關打開。

時機：法規把到期日排到了 2027

這套方案會在此刻出現，很難只用產品考量解釋，真正的推力來自三個方向的監管。

英國走得最快。主管機關 Ofcom 依《線上安全法》要求年齡保證措施在技術準確性、穩健性與可靠性上達到「高效」（Highly Effective）標準，2026 年 7 月的年齡保證報告更明確排除把年齡推斷用於最低年齡執法。兩個條件疊起來，自我宣告式的勾選框與行為推測都過不了關，可驗證的年齡來源成了剛性需求。

歐盟選了一條更講究隱私的路。歐盟執委會推動「保護隱私的年齡證明」，其中的「迷你錢包」（Mini Wallet）方案讓使用者證明自己已滿 18 歲，同時不透露其他任何資訊，門檻也可以換成 13 歲以上或 65 歲以上。方向與微軟一致：證明夠用就好，資料愈少愈好。

美國由州級立法領跑。加州《數位年齡保證法案》（DAAA）2025 年 10 月簽署成為法律，2027 年 1 月 1 日生效，直接要求作業系統業者在裝置設定過程收集使用者年齡，並向應用程式商店與開發者傳輸年齡區間訊號，法定區間為 13 歲以下、13 至 15 歲、16 至 17 歲、18 歲以上。聯邦層級，眾議院 2026 年 4 月 13 日提出《家長決定法案》（H.R. 8250），要求 Windows、macOS 與 Linux 在內的所有作業系統業者在使用者設定帳戶時驗證年齡，18 歲以下須由父母或法定監護人核實。

把生效日壓在 2027 年、逼業者提前動手的立法節奏，並非美國獨有。中國智駕兩項強制國標同樣採「先發布、後分批生效」的安排，標準先行，市場在生效日之前逐季消化。順帶一提，微軟的五個年齡段與加州的四段並不衝突，13 歲以下可由「10 歲以下」加「10 至 12 歲」合併得出，但跨區營運的應用仍得自己處理不同司法管轄區的區間換算。

Google 與 Apple 已經先跑了半步

這條路上微軟不是第一個。Google Play 的 Age Signals API（測試版）預設回傳 0 至 12 歲、13 至 15 歲、16 至 17 歲、18 歲以上四個年齡段，與加州法定區間完全對齊。Apple 的 Declared Age Range API 依應用請求回傳年齡段；家庭共享中的兒童，家長或監護人可以設定年齡資訊要一律共享、不共享，或逐應用詢問。

微軟的差異在兩處。其一是場域：加州法案把收集年齡的責任放在作業系統業者身上，PC 桌面端因此第一次被直接納管，過去 Windows 上的遊戲與應用程式幾乎沒有統一的年齡訊號可用。其二是閘門：Google 與 Apple 的機制掛在各自的商店與家庭體系內，微軟則要求呼叫方先通過數位安全平臺的身分驗證，多了一層審核。

各方換到什麼

開發者是直接受益的一端。過去應用要自己處理年齡驗證，手段不外索取生日、核對支付資訊、購買第三方身分核驗服務，或擺一個沒有約束力的勾選框。未來改成呼叫一個 API，內容分級、功能限制、應用內交易的年齡門檻都有了單一訊號來源，遵循責任的一部分也隨之移轉給平臺。資源有限的小型開發團隊省下的功夫最多。

使用者換到的是少填幾次生日。年齡資料集中在作業系統層級，應用只拿到區間，資料外流的點位變少。對家長來說，家長監護有了更上遊的施力點，不必逐應用設定。

代價則寫在權力配置上。年齡從「使用者自己說了算」變成「平臺替你作證」，而作證的機構是微軟、Google 與 Apple。應用程式商店被要求傳輸區間訊號，驗證責任上移，作業系統則多了一個別人拿不走的中介位置。另外，「已選擇退出」與「未知」的使用者會遇到什麼待遇，規則交給應用自訂：保守的應用可能直接當未成年人處理，寬鬆的可能照樣放行，這會是新的灰色地帶。

把功能從個別應用往上收，在微軟近期的產品動作裡並不陌生。Teams 管理員應用將在 10 月退場、入口收進管理中心，與年齡驗證收進作業系統，走的是同一種集中化邏輯：入口變少，權責變清楚，對平臺的依賴也變深。

接下來盯什麼

第一個訊號是啟用時點。今年稍晚的 Windows 更新會打開執行階段開關，測試人員管道通常先看到，屆時才會知道回傳值在真機上的實際行為。

第二個是「已驗證」的成色。年齡段要滿足 Ofcom 的「高效」標準，驗證管道的權威性是關鍵。微軟帳戶裡的年齡資料從哪裡來、家長核實怎麼運作，啟用時的完整文件必須說清楚，這也是整套機制的信任基礎。

第三個是未知與退出的實際體驗。應用端如何處理這兩種回傳值，決定家長與使用者換到的是更安全的環境，還是更破碎的使用經驗。

第四個是跨平臺對齊。Google 與 Apple 的 API 何時從測試版轉正、同時支援 Windows 與手機的應用如何統一年齡邏輯，會直接影響開發者的採用意願，也決定 2027 年加州生效日之前，這套訊號能鋪得多廣。

短期內，勾選框還不會消失：API 要今年稍晚才啟用，舊版 Windows 與未註冊的應用都拿不到年齡訊號。但方向已定，年齡驗證正從每個應用各自為政，走向作業系統統一供給，而 2027 年的加州生效日與可能推進的美國聯邦立法，會把這件事從微軟的選擇，變成所有作業系統的必答題。下一次設定新電腦、開新帳戶時，不妨多看一眼那一步問了什麼。從今以後，那一步收集的資料，會跟著你走進每一個支援這套訊號的應用。