监管、标准与合规演进

• AI Act 高风险系统的文档义务：技术文档、风险管理、日志、数据治理
• 文档类别：技术文档（Technical Documentation）、风险管理文档、日志记录、合格评定
• 贯穿全生命周期的合规流程

当 AI 系统被 AI Act 归类为高风险后，开发流程需追加的文档主要包括：技术文档（描述系统架构、训练数据、算法逻辑、测试方法与结果，用于监管评估）；风险管理文档（建立并持续运行风险管理流程，识别并缓解风险，记录风险分析结果）；数据治理文档（说明训练/验证/测试数据集的来源、清洗、标注与质量评估过程）；日志记录能力（系统需记录可追溯的日志，用于事后监控与审计）；系统说明与使用指示（面向部署者的说明，确保可理解与可控）；合格评定（Conformity Assessment）相关材料，以及建立完备的质量管理体系（QMS）与事后市场监控（Post-Market Monitoring）记录。这些文档不是一次性交付，而是贯穿系统全生命周期，需随模型更新持续更新。工程上应把文档生成与 CI/CD 流程集成，做到"随代码变更自动更新"，避免事后补文档。

AI Act 高风险分类要求"可证明的合规"而非"口头合规"，文档是合规证据的载体。核心是把文档义务纳入工程流程而非附加工作，使合规可追溯、可持续。文档类型与欧盟 AI Act 附件要求对应。

• 四部法规的适用地域与主体
• 架构约束：数据最小化、权限控制、数据驻留、跨境传输、删除与可携带
• 加密与匿名化、审计日志、DPIA

这些法规对架构设计的约束可归纳为几个层面：数据最小化与目的限制——架构应只采集与处理必要数据，避免过度采集；权限与访问控制——基于角色的最小权限、数据脱敏、加密存储与传输；数据驻留与跨境传输——GDPR 与 PIPL 都限制数据出境，架构需支持区域化部署与数据本地化，跨境需评估机制（SCC、标准合同、安全评估）；主体权利——删除权、更正权、可携带权，架构需支持数据删除与导出接口；审计与日志——需记录数据处理活动与访问日志，满足可追溯；安全事件响应——需有事件检测与通知机制。中国《数据安全法》与《个人信息保护法》还要求数据分类分级（重要数据识别与保护）、网络安全等级保护（等保 2.0）以及个人信息保护的评估（如个保影响评估）。GDPR 还要求 Privacy by Design（设计即隐私）与 DPIA（数据保护影响评估）。整体上，架构需在"存储、传输、访问、删除、跨境、审计"六个环节都纳入合规设计。

这些法规的共同主线是"数据生命周期合规"：从采集、存储、访问、跨境到删除，每个环节都有架构约束。核心是"把合规当架构约束而非上线后补丁"，通过数据分类分级与最小权限设计降低合规成本。

• GPAI 定义与分层：GPAI 与系统性风险 GPAI
• 合规义务：文档、版权、训练数据透明度、系统性风险治理
• 开源 GPAI 的豁免与边界

AI Act 将通用目的 AI（GPAI）与高风险系统分开治理，GPAI 的合规义务相对较轻，但按其是否构成"系统性风险"（Systemic Risk）分为两层。基础 GPAI 的义务包括：提供技术文档（模型卡、能力与限制说明）、遵循版权与训练数据透明度要求（汇总公开训练数据来源）、遵守下游使用政策。具有系统性风险的 GPAI（如参数量或算力达到阈值、或评估形成系统性风险）需追加更重的义务：模型评估、对抗性测试、缺陷报告、重大事件的网络安全防护与事件报告。开源 GPAI 有一定豁免，但系统性风险与版权相关义务仍适用。合规边界的关键是区分"GPAI 供应商"与"高风险的 AI 系统部署者"——GPAI 模型本身是通用工具，其下游某具体应用是否构成高风险系统，由部署者按应用场景评估。真实合规边界在于：GPAI 义务聚焦"模型本身的可追溯与透明度"，而高风险义务聚焦"具体应用的部署与使用"，两者对象不同、义务不同。

AI Act 对 GPAI 与高风险系统采用"分层+按角色"的治理。GPAI 的核心是"模型透明与版权",高风险的核心是"应用安全"。理解边界是区分"模型供应商"与"应用部署者"两类角色及其相应义务。

• 三者定位：NIST AI RMF（风险框架）、ISO 42001（AI 管理体系）、ISO 27001（信息安全管理体系）
• 落地难度差异：框架 vs 可认证体系
• 实施步骤：差距分析、体系建设、资源投入

三者的落地难度差异明显。NIST AI RMF 是"自愿性风险框架"，提供 AI 风险治理的方向（Govern、Map、Measure、Manage），无强制认证，落地难度相对较低，适合作为"风险管理起点"；ISO/IEC 42001 是"AI 管理体系"的可认证标准，要求建立完整的 AI 管理体系（AIMS），需要组织、流程、文档、审计体系的建设，落地难度与成本较高，适合有明确合规与认证需求的企业；ISO/IEC 27001 是信息安全管理体系（ISMS），是相对成熟、广泛部署的认证，落地难度取决于企业已有信息安全基础，已过 27001 的企业整合 42001 会更容易。真实落地难度还取决于：企业规模与成熟度、现有合规体系、资源投入、业务类型（AI 密集度）。落地顺序通常建议：先做差距分析（Gap Analysis），评估现有流程与标准要求的差距，再按优先级分阶段推进，避免一次上全量体系。真实难点在于"把标准要求转化为工程团队日常可执行的流程"，而非单纯拿证书。

三者的落地难度本质是"框架 vs 认证体系"的差异。NIST AI RMF 是轻量方向，ISO 42001 与 27001 是重体系认证。落地关键是"差距分析驱动的分阶段实施"，并让标准真正融入工程流程而非纸面合规。

• 等保 2.0 的分级与测评要求
• 关基条例对关键信息基础设施的额外要求
• 工程落地：安全防护、日志留存、数据保护、应急响应

等保 2.0（网络安全等级保护 2.0）将系统按重要性分为 1-5 级，要求相应等级的安全防护、测评与整改。对工程的影响体现在：安全防护建设（访问控制、入侵检测、web 应用防火墙、安全审计、身份认证、数据加密）、日志留存（留存相关日志并满足时限要求）、安全测评（定期等级测评与整改）、以及安全管理制度。关键信息基础设施（关基）在等保基础上据《关基条例》有更严格要求：优先采购安全可信产品、安全负责人与专门机构、定期检测评估、数据安全与个人信息保护强化、应急预案与演练、供应链安全（关键设备和软件的审查）。对工程实践的真实影响：一是部署与运维需纳入安全基线（如安全加固、日志集中、审计追溯）；二是需满足数据本地化与备份要求；三是新增系统需评估是否属于关键信息基础设施或达到一定等保等级；四是安全评估与合规成本进入日常开发排期。对个人工程师而言，意味着安全能力（身份认证、加密、日志、漏洞管理）成为基础工程要求。

等保 2.0 与关基条例把"安全合规"变成硬性工程约束。核心影响是"安全基线"与"数据保护"进入日常开发与运维，而非事后补丁。理解分级与关基区分的差异，能合理规划合规投入。

• HIPAA 审计：访问日志、隐私规则、安全事件
• PCI-DSS 审计：持卡数据保护、访问控制、日志、妥协恢复
• SOX 审计：财务数据完整性、变更管理、访问审计

面向医疗、金融的 SaaS 系统，应在架构层落地审计相关的支柱能力：一是不可篡改的审计日志（Audit Log）——记录谁、何时、对什么数据、做了什么操作，且日志需防篡改、防删除、可追溯；二是细粒度访问控制与特权管理——基于角色的最小权限、禁止共享凭据、特权操作审批；三是数据隔离与加密——多租户隔离、传输与静态加密、密钥管理（KMS）；四是变更管理与可追溯——代码变更、配置变更、数据变更需留痕并可审计（SOX 特别关注财务数据相关的变更）；五是数据保留与处置策略——按法规要求设置日志与数据保留期并支持合规删除；六是安全事件检测与响应——异常行为监控、告警、事故响应流程。架构层落地意味着这些能力不是"上线后加装"，而是"内建于平台"——例如统一审计服务、统一身份与访问管理（IAM）、统一密钥管理、统一日志聚合。PCI-DSS 还要求持卡数据的环境隔离与传输加密，HIPAA 要求保护 PHI 的隐私与安全规则。

这些合规审计要求的共同底层是"可证明、可追溯、可隔离"。架构层落地审计能力，能把合规审计从"事后补录"变成"内建能力"。核心是"统一审计基础设施+细粒度访问控制+数据隔离"，这是面向受监管行业 SaaS 的通用审计底座。

• AI Act 罚款结构：按违规类型分档（如 3500 万欧元或全球营业额的 7%/3%/1.5%）
• 罚款上限对企业的影响：风险敞口、合规投入、战略决策
• 真实影响评估：合规成本 vs 罚款风险、业务弹性

AI Act 的罚款上限按违规类型分档，最高可至 3500 万欧元或全球年度营业额的 7%（取较高者），中/低档为 3% 与 1.5%（或 1500 万/750 万欧元）。对企业的真实业务影响在于：它把"AI 合规"从抽象风险变成"可量化、可入账的财务风险敞口"，促使企业把合规投入当作"风险管理成本"而非"额外支出"。对大型企业，全球营业额基数大，罚款绝对金额高，风险敞口显著，因此更愿意投入合规资源（文档、治理、测评）；对中小型企业，罚款绝对值相对有限，但合规成本占比可能更高，需要在"合规投入"与"罚款风险"之间权衡。真实影响还体现在企业会更谨慎地分类 AI 系统（避免被误判为高风险）、倾向于使用已有合规评估的供应商（把合规责任前移）、以及在 AI 投入节奏上更审慎（先做合规评估再扩张）。罚款上限本身更多是"威慑与导向"，而非"日常运营成本"；其真正影响是重塑了企业 AI 治理的优先级与投入结构。

罚款上限的实质是"把合规风险量化"。企业评估 AI 投入时会把"罚款敞口+合规成本+负责任采用收益"三者纳入 ROI。理解罚款分档与营业额挂钩机制，能合理地评估风险敞口并安排合规投入。

• CCRC 与信息安全服务资质的定位（中国网络安全认证）
• 资质类别：服务资质、产品认证、人员认证、安全审查
• 真实价值：招投标门槛、合规证明、信任信号

CCRC（中国网络安全审查认证和市场监管大数据中心）与信息安全服务资质（如信息安全服务资质认证、等级保护测评机构资质等）在企业的真实价值主要体现在：一是招投标门槛——在中国政府采购与许多行业项目中，具备相应信息安全服务资质是"入场券"，无资质可能直接丧失投标资格，这是最直接的市场价值；二是合规证明——作为等保、关基等合规工作的能力背书，向监管与客户证明安全能力；三是信任信号——对外展示安全治理水平，增强客户与合作伙伴信任。但资质价值有明显边界：资质是"准入资格"而非"技术能力证明"，覆盖的是"是否具备基本条件"，不代表实际安全水平或工程质量。企业应把资质当作"合规与市场准入的工具"，同时以实际安全能力（漏洞管理、渗透测试、应急响应、安全架构）作为真正的竞争力。个人工程师角度，了解资质体系有助于理解国内安全合规的市场逻辑，但不必将资质等价于个人技术能力。

资质的核心价值是"市场准入与合规背书"，而非"技术能力证明"。理解资质在招投标与合规中的"是否具备"作用，避免把"有资质"误读为"能力强"。资质是门槛，实际能力才是竞争力。

• 各协议变化：HashiCorp 从 MPL 转 BSL、Elasticsearch 从 Apache 转 SSPL、AGPLv3 的传染性
• 协议影响：商用限制、云服务商限制、许可证合规风险
• 真实影响：直接使用 vs 作为依赖 vs 构建竞品

这些协议变化对企业的影响取决于使用方式。BSL（Business Source License）允许源码查看与内部使用，但限制生产/商业用途与云厂商提供托管服务，到期后转为开放许可，HashiCorp 从 MPL 转 BSL 主要影响的是"云厂商直接托管提供其产品"的场景，对普通企业"内部使用"影响有限，但限制其作为 SaaS 对外增值服务。SSPL（Server Side Public License，Elasticsearch 采用）允许修改与使用，但对外提供"服务化"版本时需开源整个服务端源代码，其影响主要在高管制的"托管服务商"场景，普通企业直接使用一般不受影响，但需注意 AGPL 类的传染性。AGPLv3 的网络传播条款使"通过网页提供服务"也可能触发源代码开放义务，对提供 SaaS 服务的企业有传染性风险。真实影响的核心是"许可证审查"：企业应在引入开源组件时做许可证合规审查，区分"内部使用/依赖/二次分发/托管服务"等不同场景，评估条款风险，并准备替代方案（如 fork 或商业许可）。对大多数企业，直接用这些项目内部使用通常风险可控，但"打包对外提供服务"与"集成进闭源产品"时需特别谨慎。

协议变化的真实影响取决于"使用形态"而非"是否开源"。核心是区分"内部使用/依赖/再分发/托管服务"四种场景对应不同的许可证义务。企业应建立许可证合规审查机制，避免在不自知的情况下触发开源义务。

• 认证对工程流程的增量：变更管理、访问控制、日志、文档、监控
• 现有流程与认证要求的差距
• SOC 2 的控制点（信任服务标准）

这些认证对工程团队的实际增量是把"最佳实践制度化"，使日常开发与运维纳入可审计的流程约束。具体增量包括：变更管理（代码/配置变更需走审批与留痕流程）、访问控制（最小权限、特权账号管理、定期权限审阅）、日志与监控（安全事件日志、告警、审计可追溯）、漏洞管理（定期扫描与修复）、备份与恢复（DR 与演练）、供应商管理（第三方评估）、安全意识培训与文档化流程。对 SOC 2 而言，其按信任服务标准（安全、可用性、保密性、处理完整性、隐私）设立控制点，需要团队配合证据收集与持续监控。对 HIPAA 而言，需在架构与流程中落实 PHI 的保护、访问审计与事件响应。这些认证不是"一次性过审"，而是需要"持续合规"——定期审计、证据留存、控制点持续有效。对工程团队而言，增量感受是"更多流程与文档要求"，但长期看能提升工程规范与可追溯性。实际落地时需平衡"合规流程"与"开发效率"，避免为满足审计而过度文档化。

认证的增量本质是"把临时最佳实践变成制度化约束"。核心是"持续合规"而非"一次性过审"——控制点需持续有效并留存证据。工程团队需在合规流程与开发效率之间取得平衡。

• 暂行办法适用范围：面向公众提供生成式 AI 服务
• 合规要求：内容安全、算法备案、数据来源、标识
• 工程影响：内容审核、安全过滤、备案流程、日志

《生成式 AI 服务管理暂行办法》对模型部署的真实工程影响主要体现在：一是内容安全——面向公众的生成式 AI 服务需落实内容安全主体责任，部署时需内置内容审核与安全过滤机制（输入输出内容安全检测、防止生成违法与不良信息）；二是算法备案与合规——提供相关服务需落实算法备案与安全评估，部署前需准备相应材料并纳入上线流程；三是数据合规——训练与使用数据来源需合法，涉及个人信息需合规；四是标识与服务规范——需提供明确的服务规则与用户提示，必要时进行生成内容标识；五是日志与可追溯——对生成的违规内容需可追溯与处理。对工程团队的影响是：模型部署不再是"纯性能与效果问题"，而是"内容安全+合规+可追溯"的复合问题。上线节奏需预留合规评估与备案时间，架构上需设计内容安全网关、合规审核、日志留痕等组件。对"面向公众"的生成式服务约束最重，企业内部/非公众用途相对宽松。

暂行办法的核心是"面向公众服务的合规红线"：内容安全、备案、数据合规、标识。工程影响是把"安全与合规"内建到模型部署链路中，而非上线后补丁。理解"面向公众"与"内部使用"的边界，能合理判断合规投入。

• SSDF 定位：将安全实践融入软件开发生命周期（SDLC）的组织框架
• 四大实践组：组织准备、保护软件、安全生产方式、漏洞响应
• 真实应用：与 CI/CD 集成、SBOM、供应链安全

NIST SSDF（Secure Software Development Framework）将安全实践系统化地融入整个开发生命周期，分为四个实践组：组织准备（Prepare the Organization）——定义安全需求、角色与治理；保护软件（Protect the Software）——保护源码、环境与构建流程的完整性；安全生产方式（Produce Well-Secured Software）——在开发中落实安全编码、测试、漏洞扫描与安全配置；漏洞响应（Respond to Vulnerabilities）——识别、评估、修复与披露漏洞。真实应用的核心是把这些实践与 CI/CD 流程集成：构建链中的依赖与 SBOM（软件物料清单）生成、签名与校验、供应链来源验证（防投毒）、自动化安全扫描进流水线、漏洞响应与安全补丁流程。SSDF 提供的是"可执行的实践框架"，而非强制认证，企业可据此建立自己的安全开发生命周期，并支撑供应链安全合规（如与 EO 14028、SBOM 要求、以及中国供应链安全相关要求衔接）。对工程团队而言，SSDF 落地意味着"安全从测试阶段左移到开发阶段"——依赖管理、代码扫描、安全设计评审成为日常。

SSDF 的价值在于"把安全左移并制度化到 SDLC"。其四组实践覆盖从组织准备到漏洞响应的完整闭环，真实应用在于与 CI/CD、SBOM、供应链安全集成。理解 SSDF 是"框架而非认证"，能灵活地落地。

• 监管变化到业务影响的时滞与传导路径
• 提前布局：监测监管信号、评估影响、储备能力
• 建立"合规雷达"与预测机制

监管影响滞后进入业务讨论，是因为从法规草案、意见征求、正式发布到实施细则与执法实践，通常需要数月到一年以上。提前布局的方法：一是建立"监管雷达"——持续跟踪监管机构（欧盟 AI 办公室、中国网信办、各行业监管机构）的草案、征求意见稿、指南与执法案例，识别"即将生效"的信号；二是评估影响面——针对新监管要求，评估其对现有系统、数据、流程的影响范围，提前做差距分析；三是储备能力——建立可复用的合规能力（数据治理、内容安全、审计日志、可追溯），使未来合规改造成本更低；四是参与标准与反馈——在征求意见窗口期参与行业反馈，提前掌握规则走向；五是建立"合规前瞻"的决策机制——把监管趋势纳入技术路线图与产品规划，当监管细则尘埃落定前，已具备应对能力。个人层面，提前布局意味着在技术选择与架构设计中预留"合规可扩展性"（如数据可审计、可删除、可隔离），避免因监管收紧而返工。

监管影响的时滞是"机会窗口"。提前布局的本质是"用可复用能力应对不确定的合规要求"，把"预测监管"转化为"储备合规能力"。核心是合规雷达+能力储备+架构预留，降低被动应对成本。

• 多区域合规的差异：数据驻留、跨境、主体权利、同意机制
• 架构挑战：区域隔离、数据分类、跨境机制、统一 vs 差异化
• 部署模式：多区域部署 vs 全球统一 + 合规层

多区域部署的合规挑战主要源于各地法规的差异：GDPR 强调数据主体权利与跨境传输机制（SCC 等）、CCPA 侧重消费者的知情与选择（opt-out）、PIPL 强调数据本地化与出境安全评估。这些差异导致架构挑战：一是数据驻留与隔离——不同区域需将数据存储于对应区域，需支持区域级的数据隔离与路由；二是数据分类与流控——需识别哪些数据受哪些法规约束，控制数据跨境流动；三是统一 vs 差异化——全球统一架构（一套代码处理多区域）与区域差异化架构（每区域独立）的权衡，前者成本低但合规控制难，后者合规清晰但成本高、运维复杂；四是主体权利与同意机制——需支持各区域不同的权利行使与同意偏好管理；五是审计与报告——需支持多区域合规的证据与审计。真实挑战是"合规粒度的选择"：在"数据本地化"与"全球统一体验"之间权衡，通常采取"全局统一平台 + 区域合规层"的混合模式，用数据分类与路由把合规逻辑集中管理，避免重复建设。多区域部署还带来多云、多区域容灾与运维成本上升。

多区域合规挑战的核心是"数据主权与统一体验的矛盾"。关键是落定制合规粒度（数据级/区域级）与"统一平台+区域合规层"的混合架构，用数据分类与路由集中管理合规逻辑，平衡成本与合规。

• 《深度合成规定》的显著标识义务：对合成内容进行标识
• C2PA 内容凭证：内容来源与编辑历史的可验证标准
• 技术落地：水印、元数据、内容签名、检测

中国《互联网信息服务深度合成管理规定》要求深度合成内容需显著标识，防止误导公众，明确"显式标识"与"隐式标识"（如特定内容的元数据标识）义务。C2PA（Coalition for Content Provenance and Authenticity）提供内容凭证（Content Credentials）技术方案，通过加密签名记录内容的来源、拍摄/生成信息与编辑历史，形成可验证的"内容来源链"。落地方式：一是生成端标识——AI 生成内容时在图片/视频/音频中加入可见水印或隐式元数据，并生成 C2PA 凭证；二是传播端校验——平台在发布与展示时检测内容凭证、识别合成内容并按要求标识；三是元数据与签名——用 C2PA 的 manifest 结构记录内容 provenance，配合内容签名防止篡改；四是检测与追溯——支持对内容的真实性验证与来源追溯。工程落地需把标识能力内建到内容生成与分发链路（生成器、媒体管线、上传服务、CDN），并制定统一的标识规范，兼顾"可识别"与"不破坏体验"。中国要求与 C2PA 技术路线可以结合：以技术手段实现标识义务的可执行与可追溯，但需注意中国规范与 C2PA 标准在标识格式、元数据与监管接口上的差异。

深度合成标识的核心是"让 AI 内容可识别、可追溯"。中国规定提供义务框架，C2PA 提供技术实现路径。落地关键是"生成端标识+传播端校验+元数据签名"的完整链路，并兼顾合规与体验。

• 训练数据版权：数据来源、抓取、条款授权
• 厂商与使用方的责任边界：厂商负责训练数据来源，使用方负责输入与输出用途
• 企业自建 RAG 的合规：知识库内容授权、输出版权、条款

AI 训练数据的版权与授权合规涉及模型厂商与使用方两类责任主体。模型厂商（训练方）负责训练数据来源的合法性——包括抓取行为是否遵守网站条款、是否使用受版权保护内容、是否取得必要授权，以及对其训练数据来源的透明度与合规声明；使用方（部署方）负责输入数据与输出内容的使用合规——即是否使用有授权的数据作为输入、是否将有版权风险的输出用于商业用途。责任边界大致是"厂商负责训练端的来源，使用方负责使用端的授权"。企业在自建 RAG 知识库时需规避风险：一是知识库内容授权——确保纳入 RAG 的数据（文档、网页、数据库）均有合法来源与授权，避免抓取未授权且受版权保护的资料；二是输出版权——RAG 检索生成的内容可能引用或复现受版权内容，需结合内容过滤与引用控制，避免侵权输出；三是数据来源合规——对爬取内容遵守网站条款与 robots 协议，对个人数据遵守隐私法规；四是合同与责任条款——通过供应商合同明确数据来源保证与责任划分，并建立内容来源审计机制。核心是"输入授权核查+输出风险控制+合同责任划分"三层防护。

RAG 版权风险的核心是"输入与输出两端"。厂商负责训练端，使用方负责使用端与知识库构建。规避关键是"输入授权核查+输出版权控制+合同责任界分"，把合规责任在合同与机制中明确。

• DSA 的透明度与算法问责：透明度报告、推荐系统披露、内容审核
• DMA 的互操作义务：核心平台服务的互操作、数据可移植
• 对平台型 AI 应用的影响：推送算法、内容审核、AI 助手

DSA（数字服务法）与 DMA（数字市场法）对平台型 AI 应用提出合规要求。DSA 聚焦"平台与用户的内容安全与透明度"：要求平台发布透明度报告（内容审核数量、措施）、对推荐系统（含 AI 推荐）披露关键参数与用户选择机制、设置内容审核与投诉机制、对超大型平台（VLOP）做系统性风险评估。对平台型 AI 应用意味着：推荐算法需可解释与可审计、AI 生成内容需标识与审核、需向用户提供调整推荐的能力。DMA 聚焦"守门人（Gatekeeper）平台"的公平竞争：要求核心平台服务实现互操作义务（如即时通信、App 生态）、数据可移植与第三方访问、禁止自我优待。对平台型 AI 应用的影响：AI 功能若嵌入守门人平台，需考虑互操作与数据可访问的义务，避免通过 AI 能力进行自我优待或数据滥用。工程落地影响：需要建立推荐/内容系统的可审计日志、透明度报告的数据收集、用户控制机制、以及跨平台互操作与数据接口设计。DSA 与 DMA 对"平台"的约束尤其重，普通 AI 应用若作为平台服务需评估其是否落入适用范围。

DSA 重"内容与透明度"，DMA 重"竞争与互操作"。对平台型 AI 的核心影响是"算法可审计、透明度报告、用户控制、互操作与数据可移植"。落地需把这些义务内建到平台设计中。

• 备案适用范围：面向公众提供生成式 AI 服务
• 材料准备：主体信息、安全评估、算法说明、服务规范
• 时间成本：备案周期、资格评估、安全评测

中国生成式 AI 服务备案针对"面向公众提供生成式 AI 服务"的经营者，涉及算法备案与生成式 AI 服务备案等流程。适用范围主要是面向公众的服务，企业内部/非公众用途通常不受同样约束。材料准备通常包括：服务提供方主体信息（营业执照等）、安全评估报告（含内容安全、数据安全评估）、算法备案材料（算法原理、用途、安全自评估）、服务规范（服务协议、用户提示、内容管理规则）、安全管理制度与责任体系。时间成本需规划：备案与安全评估通常需要数周至数月，取决于资质完备度、评估机构与排队情况，且可能需多轮整改补正。上线规划建议：把备案与安全评估与产品开发"并行推进"，在开发阶段就同步准备材料与安全测评，预留 1-3 个月的缓冲期；上线前完成备案（或按属地要求完成备案/登记），并持续满足运行中的合规要求。对工程团队，应把"合规评估的时间"纳入排期，避免"技术就绪但合规未就绪"导致上线推迟。

备案的时间成本是"上线排期"的隐性约束。关键是把合规流程与开发并行，提前盘点材料与安全测评，预留缓冲。理解"面向公众"的适用范围，是合理规划合规投入的前提。

• 两者的关系：AI Act 管 AI 系统，GDPR 管个人数据处理
• 协同要求：AI 处理个人数据需同时满足两者
• 冲突地带：定义分歧、处理合法性、责任划分

AI Act 与 GDPR 在欧盟形成"AI 系统治理 + 个人数据保护"的双重合规框架。协同要求体现在：AI 系统处理个人数据时，需同时满足 GDPR（数据最小化、合法性、透明、主体权利）与 AI Act（高风险系统的风险管理、文档、透明度）。例如高风险 AI 用于人脸识别处理个人数据，既需 GDPR 合法性基础，又需 AI Act 的风险管理。冲突地带包括：概念定义差异（"个人数据"、"高风险"的界定不同）、处理合法性的衔接（AI 训练数据能否基于合法利益、科研豁免解释变化）、透明义务的边界（GDPR 的算法解释权 vs AI Act 的技术文档义务）、以及责任划分（数据控制者/处理者与 AI 供应商/部署者的角色对应）。合规实践上，企业应做"联合评估"——统筹 AI 合规与数据合规，建立统一的算法治理与数据治理机制，避免重复建设或遗漏。当前 GDPR 与 AI Act 在"基于 AI 的决策自动化"等议题上存在解释与衔接的不确定性，需持续跟踪执法实践。

AI Act 与 GDPR 的关系是"互补+叠加"。核心是识别"AI 治理"与"数据保护"的交叉面，做联合评估、统一治理。冲突地带源于定义与角色的差异，需结合执法实践持续校准。

• AI Act 的分级时间表：不同义务的生效时间点
• 高风险分类的过渡期安排
• 差距分析（Gap Analysis）的分阶段方法

AI Act 采用分阶段生效的时间表：法规发布后，部分禁止性条款（Prohibited Practices）较早生效，GPAI 相关义务与高风险系统的主要义务在更晚的时间点生效，期间有过渡期让企业适应。高风险分类的过渡期安排意味着企业需在"合规窗口"内完成整改。企业按阶段推进差距分析的步骤：第一阶段（现状盘点）——识别现有 AI 系统，判断哪些可能落入高风险分类；第二阶段（差距识别）——对照 AI Act 要求（技术文档、风险管理、数据治理、透明度、日志、合规评估）评估现有流程的差距；第三阶段（优先级排序）——按风险等级与合规时间表排序整改优先级，高风险且即将生效的优先；第四阶段（分阶段整改）——制定整改路线图，先补齐高风险系统的关键义务，再完善管理体系；第五阶段（持续合规）——建立随更新持续评估的机制。利用合规窗口的关键是把"差距分析"与"整改路线图"提前做，在过渡期内完成高风险系统的合规就绪，避免窗口关闭时被动。同时利用过渡期参与行业标准与实施指南的讨论。

AI Act 的分阶段时间表提供了"合规窗口"。关键是"提前识别高风险分类+按时间表排定整改优先级+在窗口内完成就绪"。差距分析是"现状-要求-差距"的闭环，用路线图驱动分阶段整改。