AI辅助整理：本文基于下方列出的公开原始来源改写，不代替原文。
核心摘要： AWS 官方博客介绍，托管版 MLflow 与 SageMaker AI 模型注册表的同步能力已升级：数据科学家在 MLflow 注册模型后，会自动在注册表生成模型包组与版本，并携带训练指标、评估结果、推理规格与血缘信息。治理人员可在 SageMaker Studio 中完成审核、批准与生命周期推进，数据科学家无需离开原有实验流程。文章还给出用 IAM 条件键限制“谁能把模型推到生产”的做法，以及用资源标签冻结已批准模型的方式。
业务背景：模型从实验走向生产，治理缺口随之出现
企业在做 AI 应用时，数据科学家通常在 MLflow 里管理大量候选实验，而治理人员需要一份权威清单来判断哪些模型可以进入生产。过去这两套系统之间是断开的：模型虽然能同步到注册表，但训练指标、评估结果和血缘信息不会一起过去，治理人员只能回到 MLflow 手工收集上下文。
AWS 官方博客指出，这种割裂会让组织难以维持一份“可审核、可批准”的生产候选视图。模型治理因此常常停留在流程文档层面，而不是系统能力层面。
问题：审批信息不完整，生命周期推进也断在实验工具里
文章描述了两个具体痛点。第一，治理人员无法只凭注册表验证候选模型，必须跳回实验工具或人工整理材料。第二，同步不带生命周期阶段推进，数据科学家无法在 MLflow 工作流内把模型从预发推进到生产，导致审批与发布动作分散在不同系统。
这两个问题叠加的结果是：模型上线依赖个人经验与临时沟通，缺少可追溯的审批记录。
AI 怎么落地：注册即同步，指标、评估、推理规格与血缘一起流转
开启同步后，数据科学家在 MLflow 注册模型，注册表会自动创建对应的模型包组与版本。同步内容包含四类信息：运行元数据（参数、训练指标、训练数据位置、模型产物路径）、评估指标（以模型卡形式呈现）、推理规格（容器镜像、模型数据位置、支持的实例类型），以及血缘关系（实验、模型版本、容器镜像与模型包组之间的关联）。
推理规格的存在让模型可以直接从注册表部署，但文章也提醒，模型产物中需要包含推理处理程序，否则部署链路不完整。
实施步骤：管理员设门禁，数据科学家注册，治理人员审批
第一步由平台管理员完成一次性配置：在 MLflow 应用上开启模型注册同步，为应用服务角色授予创建模型包组与版本、打标签、记录血缘的权限，并给数据科学家角色附加限制策略。
第二步，数据科学家在笔记本中训练、记录评估指标与推理规格、注册模型，并通过生命周期别名把模型置为预发待审。若其尝试推进生产，会被策略拒绝。
第三步，治理人员在 SageMaker Studio 的模型视图中查看同步过来的指标、评估卡与血缘图，确认后推进到生产并标记为已批准。审批状态与生命周期阶段是两个独立属性，文章强调这样可以让“是否可发布”和“是否已批准”保持分离。
结果证据与边界：能力明确，量化收益未披露
来源给出的证据集中在机制层面：同步会携带训练指标、评估指标、推理规格与血缘；生命周期变更会发出事件并形成审计轨迹；已批准模型可用资源标签冻结，阻止后续改动。
需要说明的是，来源未披露具体客户名称、上线周期或效率提升幅度，也没有给出成本数据。因此这套方案的价值判断应基于流程可控性，而非现成的投资回报数字。
可复制动作：把治理前移到注册环节
对多数企业而言，可复制的不是具体命令，而是三个设计选择：让实验工具继续做数据科学家的主界面，让注册表成为唯一的生产准入记录，让权限系统而不是流程约定来决定谁能推进生产。
此外，把生命周期变更事件接入现有审计、工单或发布流水线，可以让模型治理与既有 IT 治理体系衔接，而不是另起一套。
证据与边界
- 来源为 AWS 官方博客，正文含完整配置命令与 IAM 策略示例
- 同步能力为可选，默认关闭，需设置 AutoModelRegistrationEnabled
- 文章为两部分系列的第一篇，第二篇将覆盖跨账号治理拓扑
- 来源未披露具体客户名称与量化收益
企业今天可以做什么
建议分三步落地：第一，梳理现有模型上线流程，明确“实验记录”和“生产准入”两个系统各自的职责；第二，为数据科学家与治理角色分别设计 IAM 权限，用条件键禁止前者直接推进生产；第三，对已批准模型加资源标签冻结，防止审批后被再次改动，并把生命周期变更事件接入现有审计或工单系统。