编者按 7 月 16 日，欧盟委员会依据《数字市场法》（DMA）向谷歌发出两套有法律约束力的技术规格要求（specification measures）：一是，安卓操作系统中 11 项对 AI 服务至关重要的功能，必须向第三方 AI 助手开放与 Gemini 同等的接入权限和能力；二是谷歌搜索必须按公平条件向第三方搜索引擎（含具备搜索功能的 AI 聊天机器人）共享经匿名化的搜索数据。搜索数据共享自 2027 年 1 月启动，安卓改造随 Android 18 落地、最迟 2027 年 8 月 1 日完成。
该执法措施不直接罚款，却可能比罚款更深地改变产品形态：欧委会第一次把 DMA 第 6(7) 条抽象的"同等互操作"义务，拆成了一张可验收的功能清单——从唤醒词、屏幕自动化到端侧模型调用，逐项写明谷歌必须开放什么、何时开放。这是全球监管机构首次系统性拆解"操作系统级 AI 助手"的竞争瓶颈，对所有做 AI 助手、AI 搜索的出海开发者都是直接的市场机会。
欧委会向谷歌发出指引：安卓 AI 互操作与搜索数据共享
两套措施要解决什么问题
按欧委会 7 月 16 日新闻稿，第一套规格措施针对安卓 AI 互操作：目前在安卓手机上，竞争对手的 AI 助手只能受限访问安卓系统的关键功能，而谷歌自家 AI 服务（如 Gemini）享有完全访问权限，双方并非在同一起跑线上竞争。第三方 AI 助手因此难以充分施展其创新服务——而欧盟 60% 的用户使用安卓设备。
决定落地后，用户将可以像"Hey Google"一样，用语音指令唤起自己偏好的 AI 助手；可以让第三方 AI 助手代为在应用内执行操作，例如叫车、在聊天应用中获得回复建议、询问最近去过的地方。欧委会同时强调，措施内置了保护用户隐私、设备完整性与安全的稳健保障。
第二套规格措施针对谷歌搜索数据共享：数据共享对第三方搜索引擎的开发和优化至关重要，有助于与谷歌搜索形成更公平的竞争环境，并培育创新搜索服务（包括主打隐私的替代品）。针对谷歌此前数据共享方案"迄今无效"的几个关键症结，决定明确：提供搜索功能的 AI 聊天机器人也有资格获取共享数据；在匿名化前提下，谷歌应共享其用于优化自家搜索服务的同样的数据。
匿名化方面，决定规定了一套多层匿名化方法，由欧委会与内外部隐私专家密切合作制定，并与欧委会和欧盟数据保护委员会（EDPB）就 DMA 与 GDPR 衔接问题发布的联合指引草案保持一致。谷歌可以在共享前评估向特定第三方共享数据是否构成严重的网络安全与数据保护风险。欧委会还保留根据市场发展（包括独立第三方评估）修改决定的权力，特别是匿名化措施部分。此外，决定给出了共享数据的公平定价公式和透明的数据获取流程。
负责清洁、公正与竞争转型的执行副主席里贝拉（Teresa Ribera）表示：
Our decision will help smaller competitors, search engines, or AI assistants, to compete and provide that choice, while protecting the user's privacy.
我们的决定将帮助较小的竞争者——搜索引擎或 AI 助手——参与竞争并提供选择，同时保护用户隐私。
负责技术主权、安全与民主的执行副主席维尔库宁（Henna Virkkunen）则点名期待"谷歌搜索和 Gemini 之外的替代选择"能够涌现。
程序脉络与规格程序的性质
谷歌搜索、Google Play、谷歌地图、YouTube、安卓操作系统、Chrome、Google Shopping 及其在线广告服务于 2023 年 9 月 6 日被指定为 DMA"核心平台服务"，谷歌自 2024 年 3 月 7 日起须全面履行 DMA 义务——包括就安卓功能提供有效互操作（第 6(7) 条）、向第三方开放匿名化搜索数据（第 6(11) 条）。
2026 年 1 月 27 日，欧委会就这两项义务启动规格程序（specification proceedings）；4 月 16 日和 4 月 27 日分别向谷歌通报初步结论并公布拟议措施、公开征求第三方意见；7 月 16 日通过最终决定。
需要特别理解规格程序的性质：它区别于不合规调查（non-compliance investigation），不评判守门人是否违法，因此不涉及罚款——它的功能是把 DMA 义务"应当如何履行"写成可执行的清单。但规格决定本身具有法律约束力，谷歌必须按决定所载条件和时限执行；决定同时充分尊重谷歌的抗辩权，并接受独立司法审查。
时间表：谷歌须自 2027 年 1 月起向符合条件的搜索引擎共享搜索数据；安卓侧的变化自 2027 年 7 月起惠及用户。
以下进入本文主体：安卓 AI 互操作规格决定的完整拆解（依据欧委会 DMA 开发者门户发布的官方 Q&A 文件）。
为什么要"规格化"：Gemini 的独享接入
欧委会给出的出发点很直白：AI 助手正在成为用户与移动设备交互的主要方式，而背靠谷歌全栈 AI 能力的 Gemini，处于成为移动端头部 AI 服务的独特位置。
约 60% 的欧洲移动用户使用安卓设备，安卓因此是 AI 服务触达用户的关键渠道。谷歌已经在用这张分发网络输送自家 AI 服务，并确保 Gemini 获得对关键系统功能的深层访问——语音唤起助手、在其他应用上执行操作、理解用户上下文等关键功能，几乎为 Gemini 独享，用户自行安装的 AI 助手被挡在门外。
欧委会的判断是：只有当替代性 AI 服务提供者能够提供与谷歌同样强大的助手时，真正的竞争和创新才会发生——这要求对安卓操作系统的深层访问达到与谷歌自家 AI 服务同等的水平。
11 项功能清单：谷歌必须开放什么
决定覆盖安卓的 11 项功能，欧委会称之为 AI 服务赖以运行的"高层积木"，分四大类：唤起（invocation）、上下文（context）、对应用和操作系统的操作（actions）、资源访问（access to resources）。用户始终可以对其选择安装的 AI 助手，就每一项功能明示同意是否授权。
先用一张表总览，逐项细节见后文：
| | |
|---|
| | |
| | |
| | |
| | |
| | |
| | App Functions 开放，含 Gmail 等谷歌应用 |
| | Computer Control 不再为 Gemini 独占 |
| | |
| | |
| | |
| | |
唤起类（2 项）
1. 长按 Home 键/导航条唤起。用户将能通过按压居中的 Home 键（或导航条）唤起第三方服务，并基于上下文数据获得服务。这类入口不得再为谷歌服务（如经由 Circle to Search 的谷歌搜索）保留。
2. 常驻唤醒词检测。用户将能通过说出"唤醒词"激活第三方服务——无论是在开车、做饭还是用耳机听播客时，即便屏幕关闭、设备处于省电或待机模式。措施还要求支持多服务并发接入唤醒词检测，让用户可以对不同任务使用不同的 AI 服务。唤醒词不得再为谷歌服务（如经由"Hey/OK Google"的谷歌助手或 Gemini）独占。
上下文类（3 项）
3. 集中访问设备端应用数据。对于应用选择存储在设备本地、且应用和用户同意向其他 AI 助手共享的数据，替代 AI 服务将能以集中方式（而非逐个应用对接）访问——与谷歌服务目前通过 AppSearch 实现的方式相同。设备端存储相比云端有隐私更好、响应更快、跨应用检索更高效、离线可用等优势；集中访问则使 AI 服务能够自主规划和执行操作。
4. 情境感知智能。第三方将能提供根据用户情境个性化、持续在场、可在用户未主动唤起时基于用户需要建议操作（即"主动式"服务）的 AI 服务，以用户同意为前提。该功能开放的能力包括：输入端的物理与数字情境数据（如屏幕内容、位置信号等设备传感器数据），把输入转化为主动建议的处理资源，以及展示这些体验的输出"界面"。例如：实时翻译、通话中显示航班预订号、聊天时主动推荐餐厅——这些能力谷歌自家服务已经在用（如 Magic Cue 的主动建议）。
5. 环境数据。即设备核心传感器（麦克风、摄像头、屏幕、扬声器）的实时输入/输出连续流，支撑声音检测、实时屏幕引导、物体识别等体验。第三方 AI 服务将获得与谷歌同等的实时传感器访问，适用与谷歌相同的用户同意和知情条件。
操作类（3 项）
6. 结构化设备端集成。AI 服务将能便捷地与设备上其他应用交互并代用户执行任务（发消息、建笔记、约会议等），限于应用和用户选择向 AI 服务开放的任务。这包括对 Gmail、日历、Drive、Docs、地图、YouTube、Messages、电话等谷歌应用的访问——Alphabet 须通过操作系统级集成通道开放。安卓现有的实现是 App Functions，此后不得再为谷歌助手或 Gemini 独占。
7. 屏幕自动化。AI 服务将能在用户同意后，通过在独立虚拟窗口中模拟用户行为，代用户自动完成应用内的多步骤任务——后台执行，用户可同时做别的事。例如让 AI 按购物清单在本地超市应用下单：后台打开清单应用读取内容，再打开超市应用逐项下单。安卓现有实现是 Computer Control，目前为 Gemini 等谷歌服务独占。
8. 系统集成。第三方 AI 服务将能与操作系统及其设置无缝集成：调节亮度、控制媒体播放、开启勿扰模式、关闭蓝牙等。
资源访问类（3 项）
9. 系统级端侧模型。AI 服务将能调用属于 DMA 指定操作系统一部分、已预装在安卓设备上的端侧模型（on-device models，ODM），包括 Gemini Nano。措施保证第三方获得与谷歌服务同等的访问质量（例如性能层面）。端侧模型在设备本地处理数据而非经由云端，响应更快、可离线、隐私保护更强，可用于文本摘要、校对、语音识别等。
10. 端侧模型部署。第三方将能在与谷歌自家模型相同的硬件资源和后台执行条件下安装、运行和使用自己的端侧模型，并可将其模型集中共享给其他应用。端侧模型的多样性关乎创新——不同模型在体积、速度、精度上各有所长，且可超越文本、处理图像声音视频。
11. 后台执行。允许应用在用户未注视应用甚至未使用设备时及时执行后台操作——这对 AI 应用尤其关键，因为它们往往要在用户做其他事情时提供帮助，或在熄屏状态下自动完成任务。第三方应用将依照透明、客观、精确且非歧视的规则，获得与谷歌应用同等的后台执行权限。
适用于全部功能的通用措施
- 谷歌须在整个安卓生态（包括其他厂商的安卓设备）免费开放上述互操作；
- 互操作方案须与谷歌自用方案同等有效，不得附加繁琐设置、额外用户摩擦，不得以第三方 AI 取得"默认"地位为条件;
- 谷歌须提供完整技术文档、允许第三方测试（包括 beta 测试）、提供必要技术协助；
- 任何功能出现新能力时，须在谷歌自家（AI）服务可用的同时向第三方开放。
实施时间表
- 全部措施须在下一个安卓大版本 Android 18 中落地，最迟 2027 年 8 月 1 日；
- 其中"多服务并发唤醒词检测"须在 Android 19 落地，最迟 2028 年 8 月 1 日。
隐私、安全与生态的平衡设计
安全保障的责任仍在守门人。依 DMA，实施严格必要且相称的系统完整性保护措施是守门人自己的责任；GDPR、《网络弹性法》等欧盟隐私与安全法规继续全面适用。用户通过同意机制决定使用哪个 AI 服务、允许其访问哪些功能——包括选择隐私与安全表现更好的服务。
五项敏感功能可设资格门槛。鉴于部分功能的敏感性，谷歌可以在例外情形下设置客观、非歧视的资格条件，把访问限于满足特定隐私、安全与完整性标准的第三方——但不得附加任何商业性要求。适用资格机制的五项功能是：屏幕自动化、结构化设备端集成、系统集成、集中访问设备端应用数据、情境感知智能。
资格认证由谷歌与独立第三方共同执行，时间表已经写死：2027 年 2 月 1 日前公布资格计划条款草案供第三方和欧委会评议；2027 年 5 月 1 日前公布最终条款并开始受理认证申请；收到申请后四周内必须完成审核。非 AI 服务可经由单独流程申请功能访问。
设备厂商不受限制。厂商仍可自由定制安卓和相关功能，只要不妨碍有效互操作；预装应用、设置开箱默认（并借此变现推广位）、差异化软硬件和品牌均不受影响。
不会推高设备成本。措施不要求超出设备现有技术能力的任何配置——例如语音唤起措施只适用于已配备相应芯片的设备。实施互操作方案的义务在谷歌，谷歌不得把实施负担转嫁给设备厂商。
防规避条款。决定要求的是与 11 项功能的"有效互操作"，不锁定具体技术实现——谷歌无法通过改名换姓逃避义务。被覆盖功能新增的能力须同步开放；未被决定覆盖的新功能，谷歌仍须依 DMA 互操作义务自行确保合规。
持续监督与公开。未来两年欧委会将重点监督实施，谷歌须定期报告互操作方案的设计、开发、实施和发布进度。措施清单和规格决定的非保密版本都将在欧委会网站公开（案号 DMA.100220）——措施列明谷歌必须做什么，决定说明欧委会为什么这样要求，两者应对照阅读。
法条对照：这组决定改变了什么
1. DMA 第 6(7) 条：抽象的"同等互操作"变成 11 项验收清单
DMA Article 6(7): The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant … as are available to services or hardware provided by the gatekeeper. … The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.
第 6(7) 条：守门人应允许服务提供者和硬件提供者免费获得与经由操作系统或虚拟助手访问或控制的软硬件功能的有效互操作——范围与守门人自家服务或硬件可用的功能相同。……守门人可以采取严格必要且相称的措施确保互操作不损害操作系统、虚拟助手、软硬件功能的完整性，但须充分说明理由。
本案的适用：欧委会把"与守门人自家服务可用的相同功能"这句抽象表述，落成了唤醒词、屏幕自动化、端侧模型等 11 项具体功能，并配套"同等有效、免费、无额外摩擦、新功能同步开放"的通用标准。
对该条的意义有三层。其一，这是第 6(7) 条首次被系统性适用于 AI 助手场景——条文 2022 年写就时针对的还是传统虚拟助手，本案确认操作系统级 AI 能力完全落入其射程，"同等接入"以 Gemini 实际享有的接入水平为基准。其二，条文中"严格必要且相称"的完整性豁免被程序化了：谷歌不能笼统援引安全理由拒绝开放，只能对五项敏感功能设置客观资格条件，且条款要接受公开评议、审核有四周时限、认证引入独立第三方。安全豁免从守门人的"盾牌"变成了受监管的"闸机"。其三，"免费"和"不得以默认地位为条件"堵住了变相收费和流量交换两条常见的软抵抗路径。
2. DMA 第 6(11) 条：搜索数据共享从"纸面可用"到"实际可用"
DMA Article 6(11): The gatekeeper shall provide to any third-party undertaking providing online search engines, at its request, with access on fair, reasonable and non-discriminatory terms to ranking, query, click and view data in relation to free and paid search generated by end users on its online search engines. Any such query, click and view data that constitutes personal data shall be anonymised.
第 6(11) 条：守门人应依第三方在线搜索引擎企业的请求，按公平、合理、非歧视条件向其开放最终用户在其在线搜索引擎上生成的、与免费和付费搜索相关的排序、查询、点击和浏览数据。构成个人数据的查询、点击和浏览数据均应匿名化。
本案的适用：谷歌 2024 年 3 月起就背负这条义务，但欧委会认定其数据共享方案"迄今无效"，遂用规格决定逐项校正——明确 AI 聊天机器人具备受让资格、以"谷歌自用什么就共享什么"划定数据范围、规定多层匿名化方法、给出定价公式和透明流程。
对该条的意义：第一，"提供在线搜索引擎的第三方企业"被扩张解释到提供搜索功能的 AI 聊天机器人——这等于承认生成式 AI 产品是搜索市场的参与者，是 DMA 条文向 AI 时代延伸的又一实例。第二，共享范围锚定"谷歌为优化自家搜索所收集的同样数据"，堵住了共享低价值残余数据的应付空间。第三，条文最后一句的"匿名化"义务第一次有了官方技术标准——与 DMA/GDPR 联合指引草案衔接的多层匿名化方法，且允许谷歌逐案评估严重网络安全与数据保护风险后拒绝共享。竞争义务与数据保护义务的冲突，在这份决定里给出了迄今最完整的调和样本。
3. DMA 第 8(2) 条：规格程序这件"不罚款的武器"
DMA Article 8(2): The Commission may, on its own initiative or at the request of a gatekeeper …, open proceedings pursuant to Article 20. The Commission may adopt an implementing act, specifying the measures that the gatekeeper concerned is to implement in order to effectively comply with the obligations laid down in Articles 6 and 7. That implementing act shall be adopted within 6 months from the opening of proceedings ….
第 8(2) 条：欧委会可以主动或应守门人请求启动程序，并通过实施法案，具体规定守门人为有效履行第 6 条和第 7 条义务而应实施的措施。该实施法案应在程序启动后 6 个月内通过。
本案的适用：程序 1 月 27 日启动、7 月 16 日出决定，几乎顶着 6 个月法定时限完成；期间完成了初步结论通报、拟议措施公示、第三方公开评议（第 8(5)、(6) 条要求的程序步骤）。
对该条的意义：本案是规格程序迄今最重磅的适用，展示了这个工具的独特价值——不认定违法、不罚款，但直接改写产品。与动辄数年的不合规调查相比，规格程序 6 个月出结果、直达技术细节（精确到 App Functions、Computer Control 这样的接口层），且决定通过后即转化为可执行义务，守门人若不执行，等待它的才是不合规调查和最高全球营业额 10% 的罚款。对监管者，这是"以图纸代替罚单"的事前监管范式；对守门人，抗辩战场从"有没有违法"前移到了"清单怎么写"。
对中国企业的启示
这组决定对不同位置的中国企业含义不同：
- AI 助手与 AI 应用开发者：这是机会清单，不是合规负担。11 项功能对所有第三方开放，包括中国出海开发者。值得现在就做的事：对照清单评估自家产品能用上哪几项（唤醒词、屏幕自动化、端侧模型的想象空间最大）；盯住 2027 年 2 月 1 日资格计划条款草案公示节点，参与评议并提前准备隐私、安全资质材料；规划 Android 18 时间线上的产品方案。
- AI 搜索与聊天机器人厂商：搜索数据通道 2027 年 1 月打开。具备搜索功能的聊天机器人明确有受让资格，可以开始评估数据申请的成本（定价公式）与合规成本（匿名化数据的 GDPR 处理基础）。
- 平台型出海企业：读懂规格程序的信号。DMA 的执法重心正在从罚款转向"按图施工"，Apple 互操作规格决定在前，谷歌 AI 规格决定随后——被指定为守门人（或未来可能被指定）的企业，应把"监管机构可能替你写产品需求文档"纳入风险评估。
- 对关联行业的扩展。欧盟把"AI 助手对操作系统功能的同等接入"确立为竞争法命题后，类似逻辑向其他法域扩散只是时间问题。手机厂商与 AI 服务纵向一体化程度高的企业，值得提前审视自家生态的接口开放政策。
结语
这份决定最值得回味的地方，是欧委会没有等到"AI 助手市场已经倾斜"再出手，而是在 Gemini 的入口优势刚刚成形时，就用一张 11 项功能的清单把操作系统层拆开了。规格程序没有罚款的戏剧性，但它回答了一个更根本的问题：当竞争瓶颈藏在唤醒词和后台执行权限这样的技术细节里时，监管者愿意也有能力跟进到什么深度。2027 年 8 月 1 日 Android 18 的最后期限到来时，答案会写在每一部欧洲安卓手机里。
参考来源
- European Commission: Commission provides guidance to Google for AI interoperability on Android and sharing of Google Search data under the Digital Markets Act (IP/26/1634), 2026-07-16, https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1634
- European Commission (DMA Developer Portal): Alphabet specification proceedings — Interoperability for AI services (Q&A), https://digital-markets-act.ec.europa.eu/developer-portal/interoperability/alphabet-specification-proceedings-interoperability-ai-services_en
- Regulation (EU) 2022/1925 (Digital Markets Act) 第 6、8 条条文原文, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R1925
