第30章：企业内部数据市场与共享治理

骆阳（Yang Luo）；Fang Gao；杜文卓（Wenzhuo Du）

摘要

许多组织并非缺乏数据，而是数据被困在团队、系统与权限边界之内，导致跨团队重复采集、重复清洗、权限不清与质量不透明，其成本被分散在多个项目中而很少被统一核算。本章讨论企业内部数据市场（internal data market）与共享治理，它把数据资产、数据产品、授权流程、使用审计、价值反馈与共享激励连接成一个可持续运行的治理系统。首先剖析数据孤岛的隐性成本，提出内部数据市场以可发现、可访问、可互操作、可复用（FAIR）为基础的价值主张；继而界定数据提供方、消费方、审批方、平台方与安全合规方五类角色及其标准协作流程与责任矩阵；随后讨论共享治理的核心机制——数据申请、结合基于角色与基于属性的访问控制（RBAC 与 ABAC）的授权模型、用途限制、访问日志、过期回收与违规处置；并说明高价值共享资产如何沉淀为长期供给的数据产品。最后给出内部数据市场的运营指标与共享激励机制，并以一份客户风险数据产品进入数据市场并多链路复用的端到端案例加以贯通。

关键词

内部数据市场；共享治理；数据产品；授权审计；价值反馈；共享激励

学习目标

• 能够解释数据孤岛的隐性成本，并以 FAIR（可发现、可访问、可互操作、可复用）阐明内部数据市场的价值主张。
• 能够界定数据提供方、消费方、审批方、平台方与安全合规方五类角色的协作流程与责任矩阵。
• 能够设计结合 RBAC 与 ABAC 的授权模型，并落地用途限制、访问日志、过期回收与违规处置等共享治理机制。
• 能够设计将高价值共享资产沉淀为长期供给数据产品的路径。
• 能够构建内部数据市场的运营指标与共享激励机制，使共享行为可观测、可评价、可改进。

---

章节导读

在前几章中，我们讨论了数据目录、元数据治理、数据产品化、数据契约以及数据价值评估。它们分别回答了几个基础问题：数据能否被找到，能否被理解，能否被稳定依赖，能否被衡量价值。可发现、可访问、可互操作和可复用，是数据资产真正进入组织协作网络的基础条件（Wilkinson et al. 2016）。但在企业内部，数据真正创造价值，还需要跨过另一道门槛：数据能否被合适的人、在合适的边界内、以合适的方式共享和复用。

很多组织并不是没有数据，而是数据被困在团队、系统和权限边界之内。一个团队刚刚清洗完客户主数据，另一个团队又重新做一遍；一个项目已经完成字段标准化，另一个项目仍然从原始日志中重新解析；一份高质量指标口径在某个业务域内部运行良好，却无法被其他部门发现和申请。

这种状态的成本较高。重复采集会消耗业务接口和外部采购预算，重复清洗会制造多份相似但不一致的数据，权限不清会让数据申请在邮件和聊天记录中来回流转，质量不透明则会让消费者在使用后才发现数据不可信。

更严重的是，这些成本往往被分散在多个项目中，很少被统一核算。每个团队只看到自己为了“快速交付”多做了一点工作，组织整体却承担了成倍的重复建设、审计风险和口径分裂。

企业内部数据市场要解决的，正是这种“数据存在但流动困难”的问题。它并不是把企业内部数据简单摆成一个目录，也不是把权限审批做成一个表单，而是把数据资产、数据产品、授权流程、使用审计、价值反馈和共享激励连接成一个可持续运行的治理系统。数据市场研究强调，市场机制的核心不只是目录展示，还包括供需匹配、交易规则、质量信号和信任机制（Schomm, Stahl and Vossen 2013）。

内部数据市场的目标，不是让所有数据无条件开放。恰恰相反，它要让数据共享更有边界、更有证据、更有责任。哪些数据可以自助获取，哪些数据需要审批，哪些数据只能在限定用途下使用，哪些数据必须脱敏或隔离计算，都应当被清晰定义。数据治理研究通常把决策权、责任边界和控制机制视为治理设计的核心（Khatri and Brown 2010; Abraham, Schneider and vom Brocke 2019）。

本章围绕四个核心问题展开。第一，为什么企业需要内部数据市场，它如何减少跨团队重复采集、重复清洗、权限不清和质量不透明带来的成本。第二，数据市场中的角色与流程如何设计，包括数据提供方、消费方、审批方、平台方、安全合规方之间的接口。第三，如何治理共享、授权与审计，覆盖数据申请、用途限制、访问日志、过期回收和违规处置。第四，如何从共享走向产品生态，让高价值数据资产沉淀为企业内部可持续的数据产品。

在此基础上，本章还会补充两类落地问题：一是内部数据市场的运营指标与激励机制，说明如何让共享行为可观测、可评价、可改进；二是一个端到端案例，展示一份客户风险数据产品如何从团队内部资产进入企业数据市场，并在多条业务链路中复用。

---

30.1 为什么企业需要内部数据市场

30.1.1 数据孤岛的成本不只是不方便

企业谈到数据孤岛时，常常把它理解为一个协作问题：数据在 A 团队手里，B 团队拿不到，所以沟通不顺畅。这种理解只说对了一部分。数据孤岛的真正问题，是它会在组织内部持续制造重复成本、质量差异、风险盲区和决策延迟。

当数据不能被稳定共享时，每个团队都会倾向于重新采集一份自己能控制的数据。短期看，这似乎比走共享流程更快；长期看，组织会得到多份来源相近、口径不同、质量不一的数据副本。这些副本会进入不同报表、模型、风控规则、客户画像和运营系统。随着业务运行，它们逐渐形成各自的依赖，最终很难再合并。一旦出现指标差异，各团队会花大量时间解释“为什么两个团队的客户数不一致”。这种解释成本常被低估，却是企业数据治理中最常见、最顽固的浪费之一。

数据孤岛还会让数据质量治理失去规模效应。一份数据如果只服务一个团队，质量问题只会在一个团队内部被发现和修复；但如果它被多个团队重复采集，每个团队都会独立处理缺失、重复、异常和口径转换。这意味着同样的问题会被修复多次，且修复方式未必一致。一个团队把空值填成“未知”，另一个团队直接丢弃空值，第三个团队把空值解释为“不适用”，下游分析结果自然会分裂。

内部数据市场的意义，在于把这些分散的重复动作重新组织起来。它让高质量数据资产以受控方式被发现、申请、授权、复用和评价，从而让一次治理投入服务更多下游场景。把信息作为可度量和可运营的资产，是信息资产管理与数据价值管理长期强调的基本思想（Moody and Walsh 1999; Laney 2017）。

30.1.2 重复采集：看不见的预算消耗

重复采集是内部数据市场最直接要解决的问题之一。在大型企业中，同一类数据经常由多个团队独立采集。例如，客户基本信息可能由营销团队、客服团队、风控团队和财务团队分别维护；供应商信息可能存在采购系统、合同系统、财务系统和风险系统中；设备状态数据可能由生产系统、运维系统和质量系统分别记录。这些重复采集并不总是显性浪费。每个团队都能给出合理解释：自己的系统需要更实时的数据，自己的字段更贴近业务，自己的权限流程更可控，自己的项目排期无法等待统一治理。问题在于，当组织不记录这些重复采集的总成本时，它们就会不断发生。

重复采集的成本至少包括四部分。第一是接口成本。业务系统需要为多个团队开放接口、维护权限、处理查询压力。第二是采购成本。外部数据源可能被多个团队重复购买，或者以不同合同分别采购。第三是处理成本。每个团队都要做清洗、标准化、去重、脱敏和质检。第四是协调成本。当数据不一致时，团队需要反复对账。内部数据市场通过统一的数据资产登记和产品目录，把“已有可复用数据”暴露给潜在消费者。消费者在发起新采集前，应先检索市场中是否存在满足需求的数据产品。如果已有数据产品可以满足需求，消费者可以通过申请授权直接使用。如果已有产品只能部分满足需求，则可以提出增强需求，由提供方和平台方评估是否扩展产品能力。这种机制不会消除所有重复采集。某些场景确实需要独立数据链路，例如高实时性交易风控、隔离环境中的敏感计算、或法规要求下的数据分域保存。但它至少能让重复采集从默认选择变成需要说明理由的选择。

30.1.3 重复清洗：相似数据产生不一致答案

重复清洗比重复采集更隐蔽。即使多个团队使用同一份原始数据，只要清洗逻辑不同，最终得到的数据资产也可能完全不同。例如，订单金额字段中存在退款、折扣、税费和手续费。如果营销团队把退款订单排除，财务团队把退款作为负数计入，风控团队只看交易发起金额，那么三方对“客户消费能力”的理解就会不同。再如，客户手机号字段需要去重。一个团队按手机号去重，另一个团队按证件号去重，第三个团队按手机号加姓名去重。最终的客户数量、客户生命周期和客户价值都会发生差异。这些差异并不一定代表某个团队错了。很多时候，口径差异来自业务目标差异。

内部数据市场要做的，不是强行要求所有团队使用同一个清洗逻辑，而是把清洗逻辑产品化、文档化和可选择化。一份共享数据产品应当清楚说明自己的业务口径、清洗规则、适用场景和不适用场景。如果同一原始数据需要服务多个口径，市场中可以存在多个派生产品，但它们之间的关系应通过血缘和说明文档被清楚呈现。这样，消费者不是在不知情的情况下拿到一份“看起来像标准数据”的结果，而是在理解口径后选择最适合自己场景的数据产品。

30.1.4 权限不清：共享从协作变成风险

数据共享的另一个痛点是权限不清。在很多组织中，数据申请仍然依赖邮件、即时消息、线下确认和临时授权。申请人不清楚找谁，数据 Owner 不清楚能否批准，安全团队不清楚使用目的，平台团队只负责开权限却不承担业务判断。这种流程会带来两个相反的问题。一方面，合法合理的数据使用被拖慢，业务团队因为等待授权而延迟交付。另一方面，不该开放的数据可能因为临时沟通和历史权限残留而被过度共享。权限不清的根源，是企业没有把“谁能决定数据共享”制度化。

内部数据市场需要把授权责任拆解清楚。数据提供方负责确认数据内容、质量和口径；业务审批方负责判断申请目的是否合理；安全合规方负责判断敏感级别、脱敏要求和用途限制；平台方负责执行权限开通、日志记录和到期回收。当这些角色都被流程化以后，数据共享就不再依赖个人关系和临时判断，而是进入可审计、可复盘、可优化的治理链路。权限治理的关键不是让审批变复杂，而是让审批有依据。一个申请如果用途清晰、数据等级较低、消费者身份可信、已有类似授权记录，就可以走快速通道；如果数据敏感、用途模糊、涉及外部共享或模型训练，就需要更严格审查。

30.1.5 质量不透明：市场无法建立信任

任何市场都需要信任。内部数据市场也一样。如果消费者不知道一份数据的质量状态，就不敢把它接入核心业务链路。即使市场中列出了很多数据产品，也可能没有消费者选择使用。

质量不透明主要表现为四类问题。第一，消费者不知道数据是否新鲜。第二，消费者不知道字段是否稳定。第三，消费者不知道异常率、缺失率和重复率。第四，消费者不知道质量问题发生后谁负责修复。

因此，数据市场中的每个共享数据产品都应附带质量信息。质量信息不需要一开始就非常复杂，但至少应包括更新时间、质量等级、关键字段完整率、最近异常记录、SLA、Owner 和问题反馈入口。高价值数据产品还应提供质量趋势。消费者不仅要知道今天的数据是否正常，还要知道过去一段时间是否稳定。

质量透明会改变消费者行为。当一份数据产品质量稳定、说明清晰、响应及时时，消费者更愿意复用它；当一份数据产品质量差且无人维护时，即使它被放进市场，也不会形成真实流通。这说明内部数据市场不是单纯的“上架系统”，而是要把质量、责任和使用反馈一起纳入治理。

30.1.6 内部数据市场的基本价值主张

综合来看，内部数据市场的基本价值主张可以概括为四句话。

第一，让数据可发现。消费者在新建数据链路前，能够先搜索企业中已有的数据资产和数据产品。

第二，让共享有边界。数据使用必须经过合适的授权、用途约束和审计记录，而不是无序扩散。第三，让质量可判断。消费者在使用前就能看到数据口径、质量状态、SLA 和历史问题。

第四，让复用可持续。高价值共享数据应沉淀为数据产品，形成稳定供给、持续维护和价值反馈。

这四点共同构成内部数据市场区别于普通数据目录的地方。目录回答“有什么数据”，市场进一步回答“谁能用、怎么用、用得怎么样、是否值得持续供给”。内部数据市场也区别于单纯的权限系统。权限系统关注访问控制，数据市场还关注数据产品质量、消费者体验、复用收益和资产运营。

因此，内部数据市场是数据治理、数据平台和数据产品管理的交汇点。图30-1给出了内部数据市场的整体架构，展示了数据资产、产品目录、授权流程、使用审计与价值反馈之间的连接关系。

图30-1：内部数据市场架构图。

30.1.7 本节小结

本节说明了企业为什么需要内部数据市场。跨团队重复采集、重复清洗、权限不清和质量不透明，会持续制造成本、风险和口径分裂。内部数据市场通过统一的数据产品目录、受控授权流程、质量透明机制和复用反馈机制，让数据从分散资源变成可治理、可交易、可运营的内部资产。

它的目标不是让所有数据自由流动，而是让数据在清晰边界内高效流动。

---

30.2 数据市场的角色与流程

30.2.1 市场不是系统，而是一组协作关系

很多企业建设内部数据市场时，容易先从系统功能出发：需要搜索框、申请按钮、审批页面、权限开通、访问日志和评分功能。数据管理知识体系通常把这些能力放在数据治理、元数据、数据质量、安全和数据架构的交叉区域中理解，而不是把它们视为单一系统功能（DAMA International 2017）。这些功能当然重要，但它们只是市场的表层。内部数据市场真正要建立的，是一组跨角色协作关系。如果角色边界不清，即使系统功能完备，也会出现问题。数据提供方不知道上架后要维护什么，消费方不知道如何表达需求，审批方不知道按什么标准批准，平台方只负责技术开通，安全合规方只能在事后追责。

因此，在设计流程之前，必须先定义市场中的关键角色。本章把内部数据市场中的角色分为五类：数据提供方、数据消费方、审批方、平台方、安全合规方。这五类角色不是固定组织名称，而是治理职责。一个团队可能同时承担多个角色，一个角色也可能由多个团队共同承担。关键在于，每一次共享行为都能找到对应的责任主体。

30.2.2 数据提供方：从拥有数据到供给产品

数据提供方是共享数据的生产者和维护者。在传统数据管理中，提供方往往只是“拥有这份数据的人”。但在数据市场中，提供方需要承担更明确的产品责任。数据网格提出的“数据即产品”思想，也强调领域团队应对数据产品的可发现性、可理解性、可信赖性和可用性负责（Dehghani 2022）。

提供方首先要定义数据资产边界。它需要说明上架的是一张表、一组表、一个指标集、一个标签包、一个 API，还是一个包含文档、样例、质量报告和契约的数据产品。提供方还要说明业务口径。消费者最关心的问题不是字段名是什么，而是字段代表什么、如何计算、适合什么场景、不适合什么场景。另一方面，提供方还需要维护质量。共享数据一旦被多个下游依赖，质量问题的影响范围就会扩大。提供方应配置质量监控、异常告警和问题响应机制。提供方还需要处理变更。字段新增、字段废弃、口径调整、数据源替换和刷新频率变化，都应通过数据契约或变更通知提前告知消费者。

从这个意义上说，数据提供方不是把数据“放出来”就完成任务，而是要持续运营一个可被依赖的数据产品。

30.2.3 数据消费方：从索取数据到声明用途

数据消费方是共享数据的使用者。在内部数据市场中，消费方不应只是提出“我要某张表”的请求，而应清楚说明使用目的、使用场景、访问方式、数据范围、使用期限和下游影响。

用途声明是消费方最重要的责任之一。同一份数据用于报表分析、模型训练、客户触达、风险决策和外部披露，风险等级完全不同。如果消费方只申请数据而不说明用途，审批方和合规方就无法判断授权是否合理。消费方还需要承担最小必要原则。它应申请完成业务目的所需的最小字段、最小时间范围和最小访问权限。例如，做区域销售趋势分析可能只需要城市级汇总数据，不需要客户级明细；做模型特征开发可能只需要脱敏后的行为特征，不需要原始个人身份信息。消费方还应对使用后的反馈负责。数据是否满足需求，字段是否清楚，质量是否稳定，申请流程是否顺畅，这些反馈应回流到市场，帮助提供方和平台方改进产品。

30.2.4 审批方：把业务合理性制度化

审批方负责判断一次数据共享是否具有业务合理性。审批方通常来自数据所属业务域、数据治理委员会或数据 Owner 所在组织。它的职责不是简单地“同意”或“拒绝”，而是基于数据等级、用途、消费者身份、历史授权记录和风险要求做出判断。

审批方应关注几个问题。申请用途是否真实明确，所申请数据是否与用途匹配，是否存在更低敏的替代数据，访问期限是否合理，下游是否会继续转授权，是否涉及模型训练或自动化决策。

审批方还应维护授权标准。对于低敏、低风险、常规用途的数据，可以定义自动审批或快速审批规则。对于高敏、跨域、面向外部或涉及个人权益的数据，则应进入严格审批。审批方的存在，避免了平台方承担不属于自己的业务判断，也避免了安全合规方独自决定所有共享请求。

30.2.5 平台方：把流程变成可执行能力

平台方负责把数据市场流程落到系统能力上。它需要提供数据目录、搜索、上架、申请、审批流、权限开通、访问控制、日志采集、到期回收、质量展示和使用反馈等能力。现代数据平台的关键任务，正是把数据生命周期中的采集、存储、处理、服务、治理和可观测性连接成稳定工程能力（Reis and Housley 2022）。

平台方还负责接口标准化。不同数据产品可能以表、API、文件、指标、特征、向量索引或知识库形式存在，但市场需要为它们提供统一的发现、申请和审计体验。平台方不应替代业务审批，也不应替代合规判断。它的核心职责是让流程可执行、可追踪、可自动化。

如果平台只能上架数据，却不能把授权结果写入权限系统，市场就会停留在展示层。如果平台只能开权限，却不能记录用途和到期时间，审计就会失效。因此，数据市场平台必须与身份管理、权限系统、数据目录、血缘系统、质量监控、工单系统和审计平台联动。

30.2.6 安全合规方：把共享边界显性化

安全合规方负责定义数据共享的边界。它需要根据数据敏感级别、法规要求、企业制度和场景风险，制定共享策略。共享策略通常包括数据分级分类、脱敏要求、访问控制、用途限制、留存期限、审计要求、跨境或外部共享限制、违规处置规则。安全合规方不应只在流程末端做否决者。更好的方式，是把合规规则前置到市场平台中。例如，某类高敏字段默认不可明文共享；某类数据只能在隔离分析环境中使用；某类数据申请必须附带项目编号和业务负责人；某类授权最多持续 90 天。这些规则如果系统化，审批效率反而会提高。因为常规场景可以自动匹配规则，高风险场景才进入人工审查。

30.2.7 数据市场的标准流程

一个标准的数据市场流程，可以分为七个阶段。

第一阶段是数据产品上架。提供方登记数据产品，填写业务口径、字段说明、质量指标、敏感等级、SLA、Owner、使用示例和申请条件。

第二阶段是消费者检索。消费方通过关键词、业务域、标签、指标、场景和血缘关系查找可用数据产品。第三阶段是申请提交。消费方选择数据范围、访问方式、用途、使用期限和项目归属，并说明是否涉及模型训练、客户触达、外部披露等高风险用途。

第四阶段是策略判断。平台根据数据等级、用途类型、消费者身份和历史授权记录，判断是否自动审批、快速审批或进入多方审批。第五阶段是审批决策。审批方和安全合规方按照规则完成业务与风险判断，必要时要求消费方缩小范围、改用脱敏版本或补充说明。

第六阶段是权限发放。平台将审批结果写入权限系统，开通访问，并记录授权范围、有效期、用途限制和责任人。第七阶段是使用审计与反馈。平台持续记录访问日志、使用频率、异常行为、到期状态和消费者反馈，并把信息回流到数据产品运营和复盘中。图30-2展示了上述授权审批流程在各阶段的流转与角色衔接。

图30-2：授权审批流程。

30.2.8 角色责任矩阵

为了让流程可执行，需要把各角色责任明确到关键动作。角色责任矩阵不只是项目管理工具，也是审计依据。当数据共享出现争议时，组织可以回到矩阵中判断哪个环节应承担解释、修复或改进责任。数据治理组织设计研究表明，治理职责需要根据业务复杂度、集中化程度和决策权分布进行适配，不存在一种适合所有企业的固定模式（Weber, Otto and Österle 2009; Otto 2011; Alhassan, Sammon and Daly 2016）。表30-1按治理动作逐项列出了五类角色的责任划分。

表 30-1：内部数据市场角色责任矩阵。

治理动作	数据提供方	数据消费方	审批方	平台方	安全合规方
数据产品上架	负责定义口径、字段、质量和 Owner	提供潜在需求反馈	确认业务归属	提供上架工具和模板	确认敏感等级规则
数据发现	维护可检索描述与标签	检索和比较候选产品	监督重点资产覆盖	提供搜索、推荐和目录能力	提供合规标签
数据申请	响应产品咨询	说明用途、范围和期限	判断业务合理性	提供申请表单和流程	判断风险与限制
授权审批	确认数据内容和可供给性	补充用途说明	作出业务审批	编排审批流	作出合规审查
权限发放	确认授权范围	按范围使用	确认审批结果	写入权限系统	定义控制要求
使用审计	关注异常使用反馈	接受日志记录和抽查	复盘授权合理性	采集访问日志	监控违规风险
质量维护	负责问题修复和变更通知	反馈质量问题	协调跨域影响	展示质量指标	评估质量风险
到期回收	确认是否可续期	提交续期或停止使用	审批续期	自动回收权限	审查长期授权

矩阵中的责任可以根据企业实际组织结构调整。重要的是，每个动作都不能只有参与者，而没有责任人。

30.2.9 本节小结

本节把内部数据市场拆解为五类角色和七个流程阶段。数据提供方负责把数据供给成产品，消费方负责声明用途和最小必要范围，审批方负责业务合理性，平台方负责流程自动化，安全合规方负责共享边界。只有当这些角色通过标准流程连接起来，内部数据市场才不是一个静态目录，而是一套可执行的共享治理机制。

---

30.3 共享、授权与审计

30.3.1 共享治理的核心原则

内部数据市场的共享治理，需要在效率和安全之间取得平衡。如果所有数据都层层审批，市场会变成新的流程瓶颈，消费者最终绕开平台，回到私下找人要数据的老路。安全与隐私控制体系强调，访问控制、审计、用途约束和问责机制应当按风险分层，而不是对所有对象采用同一种强度（NIST 2020a; NIST 2020b）。如果所有数据都开放自助获取，敏感数据又会失去边界，组织难以满足审计、隐私和监管要求。因此，共享治理应遵循四个原则。

第一是最小必要原则。消费者只能获得完成声明用途所需的最小数据范围和最小权限。第二是用途绑定原则。授权不是对“人”的永久开放，而是对特定项目、特定用途、特定期限的开放。第三是可追溯原则。谁在何时因为什么用途访问了哪些数据，应当可以被审计。第四是动态回收原则。权限不是一次开通永久有效，而应随项目结束、用途变化、人员变动和风险变化而回收或调整。这四个原则共同构成共享治理的底线。

30.3.2 数据申请

数据申请是共享治理的入口。一个好的申请表单，不应只问“申请哪张表”，而应帮助消费者把需求表达清楚。申请内容至少应包括申请人、所属团队、项目编号、业务负责人、申请数据产品、字段范围、时间范围、访问方式、使用期限、使用目的、下游系统、是否涉及模型训练、是否涉及客户触达、是否涉及外部共享。

对于敏感数据，还应要求填写替代方案说明。也就是说，申请人需要说明为什么不能使用脱敏数据、汇总数据或低敏字段。申请表单还应提供示例。很多消费者并不是故意模糊用途，而是不知道怎样描述才符合审批需要。

平台可以通过模板引导消费者选择用途类型，例如经营分析、风险建模、客户运营、产品实验、审计核查、监管报送、研发测试。用途类型会直接影响审批路径。例如，经营分析可能只需要业务审批，风险建模可能需要模型治理参与，客户运营可能需要隐私和合规审查，外部共享则可能需要更高级别审批。

30.3.3 授权模型

传统数据权限往往围绕表、库、目录或系统账号设计。这种模型在简单分析场景中可用，但在内部数据市场中远远不够。基于角色的访问控制为企业权限管理提供了基础模型，而基于属性的访问控制进一步支持把主体、资源、环境和用途等条件纳入策略判断（Ferraiolo and Kuhn 1992; Sandhu et al. 1996; Hu et al. 2014）。因为共享治理关注的不只是“能否访问”，还关注“为什么访问、如何访问、访问多久、能否转用”。因此，内部数据市场应从表权限走向用途权限。

用途权限可以理解为一组约束的组合：数据对象、字段范围、行级范围、访问方式、使用场景、有效期限、使用环境和再共享限制。例如，同一份客户数据，对财务审计项目可以开放客户编号、交易金额和合同状态，对营销分析项目只能开放脱敏客户 ID 和汇总标签，对模型训练项目则需要进入隔离环境并禁止导出明文。用途权限的实现，需要平台支持策略化授权。审批结果不应只生成“允许访问表 A”，而应生成一条结构化授权策略。这条策略可以被权限系统、查询引擎、API 网关、数据脱敏系统和审计系统共同执行。

30.3.4 用途限制

数据授权容易被误解为所有权转移。一旦某个团队拿到数据，就开始在其他项目、其他模型、其他报表中继续使用，甚至再分享给第三方团队。这种做法会让原始授权失效。审批方批准的是特定用途，而不是无限制使用。因此，内部数据市场必须显式记录用途限制。

用途限制可以包括禁止外部共享、禁止用于客户触达、禁止用于自动化决策、禁止用于模型训练、禁止导出明文、禁止与某类数据拼接、仅允许在指定环境使用。用途限制应在申请页面、审批记录、权限策略和数据产品说明中同时出现。

对于高风险数据，平台还可以通过技术手段执行限制。例如，敏感数据只能在安全沙箱中查询，查询结果只能导出聚合值，模型训练任务必须登记实验编号，API 调用必须附带项目 Token。用途限制不是为了增加使用障碍，而是为了让共享行为可持续。如果提供方和合规方相信数据不会被无限扩散，它们就更愿意把高价值数据放入市场。

30.3.5 访问日志

访问日志是共享治理的基础。没有日志，组织无法知道授权是否被按预期使用，也无法在风险事件发生后追踪影响范围。审计与可追踪性也是安全控制基线中的关键能力，它们让访问行为从不可见的系统事件变成可复核的治理事实（NIST 2020a）。访问日志至少应记录访问主体、访问时间、数据产品、数据版本、字段范围、查询条件、访问方式、用途标识、授权编号、返回行数和异常标记。对于高敏数据，还应记录查询来源、设备信息、网络环境、导出行为和二次加工链路。

访问日志的价值不只在追责。它还可以用于市场运营。例如，一份数据产品访问频率高，说明它可能是核心资产；一份数据产品申请很多但实际访问很少，说明申请门槛、数据质量或说明文档可能存在问题；一份数据产品在授权到期前仍被频繁访问，说明需要提醒消费者续期或迁移。访问日志还可以发现异常行为。短时间内大量下载、访问非工作时间异常、查询范围突然扩大、与声明用途不符的访问，都应触发告警或复核。审计不是只在事故发生后翻记录，而是把使用事实持续纳入治理。

30.3.6 过期回收

数据权限如果没有生命周期，就会不断膨胀。人员转岗、项目结束、模型下线、报表废弃、系统迁移之后，历史权限仍然残留，是企业数据安全中常见的问题。内部数据市场应默认所有授权都有有效期。低敏数据可以设置较长有效期，高敏数据应设置较短有效期，项目型授权应与项目周期绑定，临时排查授权应更短。

到期前，平台应提醒消费方确认是否续期。续期不能只是点击确认，而应重新校验用途是否仍然存在、数据范围是否仍然必要、消费者是否仍在项目中、风险等级是否变化。如果没有续期，平台应自动回收权限，并保留回收记录。对于长期高频使用的数据，反复短期授权可能增加管理成本。此时可以把使用关系升级为稳定订阅，但订阅也应有周期复盘。权限生命周期治理的目标，是让数据访问权随真实业务需要变化，而不是随组织历史沉淀无限积累。

30.3.7 违规处置

共享治理如果没有违规处置，就很难形成约束力。违规行为可以分为多类：超出用途使用，未经批准转共享，导出敏感数据，绕开平台访问，长期占用过期权限，使用数据造成隐私或合规事件，拒不配合审计。不同违规行为应有不同处置方式。

对于违规行为，轻微违规可以要求整改、补充说明或重新申请；重复违规可以暂停授权、限制申请资格或通知团队负责人；严重违规则需要进入安全事件流程，触发审计、问责和合规处置。处置规则应在市场规则中提前说明。消费者在申请数据时，应确认理解用途限制和违规后果。提供方和审批方也应遵守规则。如果提供方未按承诺维护质量，或审批方长期积压申请，也应进入市场运营复盘。共享治理不是只约束消费者，而是约束整个市场生态中的所有角色。

30.3.8 授权审批流程表

为了便于落地，可以把授权审批流程拆成可执行节点。表30-2将整个流程分解为从需求提交到到期复核的各个节点，并标注了主要动作、责任角色与输出结果。

表 30-2：授权审批流程节点。

阶段	主要动作	责任角色	输出结果
需求提交	填写用途、范围、期限和项目	数据消费方	数据申请单
自动校验	校验身份、数据等级和必填信息	平台方	初始风险判断
业务审批	判断用途是否合理、范围是否必要	审批方	业务审批结论
合规审查	判断敏感级别、脱敏和限制要求	安全合规方	合规控制条件
授权执行	写入权限系统、生成授权编号	平台方	可执行权限策略
使用监控	采集访问日志、识别异常行为	平台方、安全合规方	审计记录与告警
到期复核	续期、缩权或回收	消费方、审批方、平台方	权限生命周期记录

这个流程可以根据风险等级简化或增强。低风险数据可以自动完成部分节点，高风险数据则需要更完整的人工审查。

30.3.9 本节小结

本节讨论了共享、授权与审计的治理机制。内部数据市场的授权不应停留在表权限，而应绑定用途、范围、期限、环境和再共享限制。数据申请、访问日志、过期回收和违规处置共同构成共享治理闭环，使数据既能流动，又不失控。

---

30.4 从共享到产品生态

30.4.1 共享只是起点，产品化才是长期供给

内部数据市场的早期目标，是让数据能够被发现和申请。但如果市场只停留在共享层面，很快会遇到新的问题：上架的数据很多，真正可依赖的数据很少；申请流程存在，但消费者仍然不知道哪份数据更适合；提供方完成一次授权后，缺少持续维护动力。因此，内部数据市场必须从共享走向产品生态。

共享强调“把已有数据开放给别人用”。产品化强调“围绕稳定需求，持续提供可依赖的数据能力”。这与数据产品化和数据网格中的领域责任思想一致，即数据不只是交付物，而是需要被长期运营的产品能力（Dehghani 2022）。一份共享表可以没有清晰 SLA，没有消费者反馈，没有版本路线图。但一份数据产品必须有明确口径、质量承诺、契约、文档、Owner、变更机制和支持渠道。内部数据市场的成熟标志，不是上架了多少数据，而是形成了多少被持续消费、持续维护、持续改进的数据产品。

30.4.2 高价值共享资产如何沉淀为数据产品

并非所有共享数据都需要产品化。有些数据只服务一次性分析，有些数据只在小范围内低频使用，有些数据还处在探索阶段。真正应当产品化的，是那些复用频率高、消费方多、业务价值明确、质量要求稳定、维护责任可承担的数据资产。市场平台可以通过使用日志识别这些候选资产。例如，一份数据被多个团队重复申请，说明它有横向复用价值；一份数据访问频率高且申请人持续续期，说明它已经进入稳定业务链路；一份数据频繁收到质量反馈，说明消费者依赖它但现有供给能力不足。当这些信号出现时，平台方可以发起产品化建议，由数据提供方、主要消费方和治理团队共同评估。

产品化过程通常包括五步。第一，重新定义资产边界。第二，补齐字段说明、口径文档和使用示例。第三，建立质量监控和 SLA。第四，签订数据契约和变更机制。第五，形成产品目录页和支持流程。这五步完成后，数据就不再只是被动共享的资源，而成为可以被长期订阅和复用的内部数据产品。

30.4.3 共享数据产品目录示例

数据产品目录是内部数据市场的核心界面。它既服务消费者检索，也服务治理团队管理资产组合。

一个好的目录页应能在消费者打开时回答几个问题：这是什么数据，适合什么场景，谁在维护，质量如何，能否申请，申请需要什么条件，已有谁在使用，最近是否发生变更。数据集说明文档的研究强调，数据的来源、构成、用途、限制和维护信息应显式记录，才能支持负责任的复用（Gebru et al. 2021）。表30-3给出了一个共享数据产品目录的示例，覆盖客户、交易、风控等多个业务域。

表 30-3：共享数据产品目录示例。

产品名称	业务域	主要内容	适用场景	敏感等级	质量状态	申请方式	Owner
客户统一画像	客户域	客户基础属性、生命周期、标签	运营分析、客户分群	中	正常，日更	审批后订阅	客户数据团队
交易明细宽表	交易域	订单、支付、退款、渠道字段	经营分析、财务核对	高	正常，小时级	严格审批	交易数据团队
风险事件标签	风控域	欺诈、逾期、黑名单、设备风险	风控建模、策略验证	高	正常，日更	隔离环境使用	风控数据团队
产品指标口径包	产品域	活跃、留存、转化、漏斗指标	产品分析、实验评估	低	正常，日更	自助订阅	产品分析团队
合同主数据	法务域	合同主体、状态、期限、金额	财务审计、履约分析	中	部分字段待修复	审批后订阅	法务数据团队
知识库文档索引	知识域	制度、流程、FAQ、政策文档	RAG、智能问答	中	正常，周更	审批后接入	知识管理团队

目录示例中的字段并不复杂，但它把消费者最关心的信息放在一起。消费者可以先比较数据产品，再决定是否申请。提供方也能通过目录看到产品是否被充分描述。

30.4.4 产品等级与运营策略

数据产品进入市场后，需要分级运营。一种实用分级方式，是把共享数据产品分为核心产品、重点产品、普通产品、观察产品和退役候选产品。核心产品支撑多个关键业务链路，应有明确 SLA、质量监控、变更通知、专人维护和季度复盘。重点产品对特定业务域需要重点关注，应保持稳定维护，并主动收集消费者反馈。普通产品有稳定但有限的使用场景，可以采用标准维护流程。观察产品价值尚不明确，应控制维护成本，观察使用趋势。退役候选产品长期无人使用、质量差或风险高，应进入下线评估。这种分级与上一章的数据价值评估相互衔接。数据市场提供使用事实，价值评估提供分级依据，产品运营负责采取动作。

30.4.5 从一次授权到长期订阅

数据市场中的使用关系，可以从一次授权逐步演变为长期订阅。一次授权适合临时分析、短期项目、验证性实验和低频审计。长期订阅适合稳定报表、生产模型、RAG 知识库、核心指标服务和跨系统数据同步。当消费方连续多次申请同一数据产品，且用途稳定、访问频率高、风险可控时，平台可以建议升级为订阅。订阅关系应包含订阅用途、数据范围、刷新频率、SLA、变更通知、质量反馈、续期周期和退出机制。订阅不是永久授权。它只是把重复审批简化为周期复盘。这种机制能够同时提高效率和治理质量。消费者不必频繁提交相同申请，提供方也能更清楚地知道哪些下游是稳定依赖。

30.4.6 反馈、评分与产品改进

内部数据市场要形成生态，必须建立反馈机制。消费者应能对数据产品的质量、文档、申请流程、响应速度和适用性进行反馈。反馈不应只是星级评分。星级评分容易情绪化，也不利于定位问题。更实用的反馈结构包括问题类型、影响程度、复现方式、期望修复时间、是否阻塞业务、是否存在替代数据。

平台方可以把反馈聚合为产品运营指标。例如，平均响应时间、未解决问题数、质量问题复发率、申请通过率、消费者满意度、复用团队数。这些指标应反馈给数据提供方，作为产品改进和资源投入的依据。高价值产品如果持续收到质量问题反馈，说明需要追加治理投入。低价值产品如果长期无人反馈且无人使用，则可能进入退役候选。反馈机制让数据市场从静态目录变成持续学习的产品生态。

30.4.7 本节小结

本节说明了内部数据市场如何从共享走向产品生态。共享解决“能不能用”，产品化解决“能不能长期可靠地用”。高价值共享资产应通过资产边界定义、口径文档、质量监控、数据契约、目录页和订阅机制，沉淀为可持续的数据产品。

---

30.5 内部数据市场的运营指标与激励机制

30.5.1 为什么需要运营指标

内部数据市场上线后，不能只看“上架了多少数据”。上架数量很容易增长，但它未必代表真实价值。一个市场可以有上千个条目，却只有少数被使用；也可以有大量申请记录，却因为审批慢、质量差和说明不清而无法支撑业务。因此，数据市场需要运营指标。

运营指标的作用，是把市场运行状态从主观感受变成可观测事实。它帮助平台团队判断哪些流程卡住了，帮助提供方知道哪些产品值得维护，帮助治理团队识别风险，帮助管理者决定资源投向。没有持续可观测的治理反馈，数据平台很容易积累隐性技术债和无人负责的长期依赖（Sculley et al. 2015）。运营指标应覆盖供给、需求、效率、质量、风险和价值六个方面。

30.5.2 供给侧指标

供给侧指标关注市场中有什么数据，以及这些数据是否具备可复用条件。常见指标包括上架数据产品数、活跃数据产品数、有 Owner 产品占比、有质量指标产品占比、有字段说明产品占比、有 SLA 产品占比、有契约产品占比。仅有上架数量是不够的。

如果一个产品没有 Owner、没有质量指标、没有说明文档、没有申请规则，它就更像一个“目录条目”，而不是可被市场消费的数据产品。供给侧指标还应关注产品覆盖。企业可以按业务域、数据类型、敏感等级和使用场景统计供给情况。如果某个核心业务域几乎没有可复用数据产品，就说明市场供给存在结构性缺口。

30.5.3 需求侧指标

需求侧指标关注消费者如何使用市场。常见指标包括搜索次数、产品浏览次数、申请次数、订阅数、复用团队数、跨域复用次数、重复申请次数、申请转化率。

搜索无结果是需要重点关注的信号。如果大量消费者搜索某类关键词但没有找到产品，说明企业可能缺少对应数据资产，或者已有资产命名和标签不清。申请被拒绝也应分析原因。拒绝可能来自用途不合理，也可能来自申请范围过大、数据敏感、缺少脱敏版本或产品说明不清。这些信号可以反向推动数据产品建设。

30.5.4 效率指标

效率指标关注市场流程是否顺畅。常见指标包括平均审批时长、自动审批占比、快速审批占比、权限开通时长、到期回收及时率、续期处理时长、申请退回次数。审批时长应按数据等级和用途类型分层统计。低风险数据如果审批很慢，说明流程设计过重。高风险数据如果审批过快，则可能存在风险识别不足。权限开通时长也很关键。如果审批已经完成，但权限迟迟未开通，消费者仍然会认为市场低效。因此，市场效率不只取决于审批方，也取决于平台自动化程度。

30.5.5 质量与风险指标

质量指标关注数据产品是否可靠。常见指标包括质量异常次数、异常修复时长、SLA 达成率、字段变更次数、消费者质量投诉数、问题复发率。风险指标关注共享是否受控。常见指标包括高敏数据申请数、超期权限数、异常访问告警数、违规使用事件数、长期未复核授权数、用途不匹配访问数。质量与风险指标应同时观察。一份数据产品质量很好但风险很高，需要严格授权和审计。一份数据风险很低但质量很差，也不应被推荐给关键业务链路。

30.5.6 价值指标与激励

价值指标关注市场是否真正减少重复建设、促进复用和沉淀产品。常见指标包括复用节省工时、减少重复采购金额、复用团队数、因共享减少的新建链路数、由共享升级为数据产品的资产数、核心产品贡献的下游场景数。

这些指标可以用于激励机制。对数据提供方，应认可其产品被复用带来的组织价值。否则，提供方只承担维护成本，却看不到收益。对数据消费方，也应认可其复用已有产品而非重复建设的行为。复用不是降低投入，而是组织效率提升。对平台方，应关注市场流程效率、消费者体验和治理闭环，而不是单纯追求上架数量。激励机制的目标，是让共享和复用成为更划算的选择。

30.5.7 本节小结

本节提出了内部数据市场的运营指标体系。供给、需求、效率、质量、风险和价值六类指标共同描述市场是否健康。只有通过指标持续运营，内部数据市场才能避免沦为静态目录，并逐步形成可持续的数据产品生态。

---

30.6 案例：客户风险数据产品进入内部数据市场

30.6.1 案例背景

设想一家金融服务企业已经建立了客户风险标签体系。最初，这套标签只由风控团队内部使用，用于贷款审批、反欺诈和逾期预测。随着业务发展，客服团队希望用风险标签优化人工审核优先级，营销团队希望识别不适合高风险活动的人群，合规团队希望在客户投诉处理中快速定位历史风险事件，数据科学团队希望把风险事件作为模型评测样本。如果每个团队都单独向风控系统要数据，就会产生重复申请、重复解释、重复脱敏和重复审查。因此，企业决定把这套标签沉淀为内部数据市场中的共享数据产品，命名为 customer_risk_profile。

30.6.2 产品上架

风控数据团队作为提供方，首先定义产品边界。customer_risk_profile 不直接暴露原始风控规则和敏感明细，而提供客户级风险等级、风险类型、最近风险事件时间、风险标签置信度和标签更新时间。产品说明中明确写出适用场景：风险分析、客服优先级、合规核查、模型评测。同时也写出不适用场景：未经审批的客户营销触达、外部共享、自动拒绝客户服务请求。安全合规方将该产品定为高敏数据产品，要求所有访问必须绑定项目用途，禁止明文导出客户身份信息，模型训练用途必须在隔离环境中进行。平台方为该产品创建目录页，展示字段说明、质量状态、刷新频率、申请条件、Owner、SLA 和历史变更记录。

30.6.3 授权与使用

客服团队提交申请，说明用途是对高风险投诉工单进行优先分派。审批方认为用途合理，但要求只开放脱敏客户 ID、风险等级和风险类型，不开放详细规则命中记录。平台方根据审批结果开通 API 访问，有效期 180 天，并要求调用时附带客服工单编号。营销团队也提交申请，希望排除高风险客户参与某项活动。安全合规方认为该用途涉及客户权益影响，要求营销团队使用汇总人群包，不得直接访问客户级风险标签，并要求活动策略经过合规复核。数据科学团队申请用于模型评测。审批结果允许其在隔离环境中使用样本，但禁止导出明文客户标识。这些不同授权说明，同一数据产品可以服务多个场景，但每个场景的访问范围和用途限制不同。

30.6.4 审计与反馈

上线三个月后，平台数据显示 customer_risk_profile 被四个团队复用，累计授权六次，其中三次为长期订阅。访问日志显示，客服团队调用频率最高，但有几次查询集中在非工作时间。安全团队复核后发现，这是夜间批处理任务造成的正常访问，于是将该任务登记为固定作业，减少后续误报。消费者反馈显示，风险标签更新时间对客服场景很关键。原有日更频率在部分高风险投诉中不够及时。风控数据团队评估后，将高风险事件字段改为小时级增量更新，并在数据契约中说明低风险字段仍保持日更。这次反馈让数据产品能力得到增强，也让其他消费者受益。

30.6.5 从共享资产到核心产品

经过两个季度运行，customer_risk_profile 的复用团队数持续增加，质量投诉下降，授权流程稳定，且多次减少重复取数和重复脱敏工作。数据治理委员会将其评为核心数据产品。核心产品等级带来几项变化。第一，产品进入市场首页推荐。第二，质量监控升级，关键字段异常会自动告警。第三，变更需要提前通知所有订阅方。第四，季度复盘中必须报告复用价值、风险事件和改进计划。

这个案例说明，内部数据市场不是一次性开放数据，而是让数据在受控共享中逐步沉淀为稳定产品。当产品价值被使用事实证明后，组织就有理由继续投入质量、文档、SLA 和自动化能力。

30.6.6 本节小结

本节通过客户风险数据产品案例，展示了内部数据市场的端到端过程。一份原本只在风控团队内部使用的数据资产，通过产品上架、用途声明、差异化授权、访问审计、反馈改进和产品分级，逐步成为跨团队复用的核心数据产品。案例也说明，数据共享的价值来自受控流动，而不是无边界开放。

---

30.7 落地反模式与验收清单

30.7.1 反模式一：把数据市场做成静态目录

内部数据市场最常见的反模式，是把它做成一个“更漂亮的数据目录”。团队投入大量精力整理名称、标签和说明，却没有把申请、授权、审计、质量反馈和产品运营接起来。数据治理文献反复强调，制度、流程、角色和控制机制必须与技术平台共同设计，否则治理能力很容易停留在文档层面（Ladley 2019; Abraham, Schneider and vom Brocke 2019）。

这种市场上线初期看起来很完整，真正使用时却会暴露问题。消费者找到数据后仍然不知道怎么申请，申请后仍然需要线下找人审批，拿到权限后没有用途记录，使用过程中发现质量问题也没有反馈入口。静态目录只能改善发现效率，不能解决共享治理。真正的数据市场必须形成闭环：发现数据、提交申请、完成审批、开通权限、记录使用、反馈质量、复盘价值。判断市场是否陷入静态目录反模式，可以看一个简单问题：消费者从搜索到可用数据，是否能在平台内完成主要步骤。如果关键步骤仍然依赖邮件、聊天和人工开权限，市场就还没有真正形成。

30.7.2 反模式二：只强调管控，不改善体验

第二类反模式，是把内部数据市场建设成新的审批关卡。所有数据都要申请，所有申请都要多人审批，所有权限都要等待人工开通，结果消费者觉得市场比过去更慢。这种做法会伤害市场生命力。数据消费者最终会绕开平台，通过私下共享、历史账号、临时文件和脚本复制继续获取数据。治理越重，绕行越多，实际风险反而更高。

好的共享治理应当分层。低敏、低风险、常规用途的数据应尽可能自助化或快速审批；高敏、跨域、外部共享、模型训练和客户触达等场景才需要更严格审查。体验不是治理的对立面。清晰的目录、标准化申请模板、自动策略判断、审批进度透明、权限自动开通和到期提醒，都是提升治理质量的手段。如果消费者愿意主动走市场流程，说明市场同时提供了效率和信任。

30.7.3 反模式三：上架后无人维护

第三类反模式，是数据产品上架后无人维护。提供方完成上架任务后，字段说明不再更新，质量异常无人响应，消费者反馈长期积压，变更也不通知下游。这种反模式会快速消耗市场信任。消费者一旦在关键项目中被低质量数据影响，就会降低对整个市场的信心，而不仅仅是不再使用某一份产品。

要避免这一点，市场必须把 Owner、SLA、质量指标和反馈响应纳入上架条件。没有明确 Owner 的数据，不应作为正式数据产品上架；没有质量承诺的数据，只能作为观察资产或探索资产展示。市场运营团队还应定期检查无人维护产品。长期无人访问、无人响应、质量异常频发或 Owner 缺失的数据产品，应进入整改或退役流程。

30.7.4 反模式四：忽视消费者反馈

第四类反模式，是把消费者反馈当成可选意见，而不是产品改进信号。很多市场只记录申请和访问，却不系统记录使用体验。消费者反馈能够揭示目录和指标看不到的问题。例如字段说明难以理解、示例查询不可运行、申请条件不清、质量指标不能解释业务异常、刷新频率不满足真实使用场景。这些反馈如果不被处理，市场会出现“有供给、无信任”的状态。数据产品虽然存在，但消费者仍然选择自己重新加工数据。

因此，市场应把反馈分为咨询、质量问题、口径问题、权限问题、性能问题和增强需求，并为不同类型设定响应时限。高频反馈还应进入产品路线图。一个数据产品如果长期被要求增加同类字段或提高刷新频率，说明它的产品边界需要重新设计。

30.7.5 反模式五：缺少退役机制

第五类反模式，是只上架不下架。随着时间推移，市场中的数据产品越来越多，旧产品、重复产品、无人维护产品和质量较差的产品混在一起，消费者反而更难找到可信数据。

内部数据市场必须允许产品退役。退役不是简单删除，而是有序结束供给关系。退役流程应包括影响分析、消费者通知、替代产品推荐、观察期、权限回收和归档策略。对于仍有低频审计价值的数据，可以从正式产品降级为归档资产。对于存在高风险且无人使用的数据，应停止新增授权，并在确认无依赖后下线。没有退役机制的市场，最终会变成新的数据负债仓库。

30.7.6 落地验收清单

为了判断内部数据市场是否具备基础生产能力，可以使用一份简化验收清单。

第一，关键数据产品是否具备 Owner、业务口径、字段说明、质量状态和申请规则。

第二，消费者是否能在平台内完成搜索、申请、审批进度查看和权限开通。

第三，授权是否绑定用途、范围、期限和访问方式，而不是只开通表级永久权限。

第四，高敏数据是否具备脱敏、隔离环境、访问日志和异常告警机制。

第五，权限是否能够到期提醒、续期复核和自动回收。

第六，市场是否记录访问频率、申请转化、审批时长、质量反馈和复用团队数。

第七，高价值共享资产是否能够升级为数据产品，低价值或高风险资产是否能够降级、归档或退役。

如果这些问题都能得到系统性回答，说明内部数据市场已经从展示型目录进入治理型市场。

30.7.7 本节小结

本节补充了内部数据市场落地时容易出现的五类反模式：静态目录、过度管控、无人维护、忽视反馈和缺少退役。这些反模式的共同根源，是把数据市场看成一次系统建设，而不是持续运营机制。真正可用的内部数据市场，应当既能促进共享，又能控制风险；既能改善消费者体验，又能沉淀数据产品；既能让资产上架，也能让低价值资产有序退出。

---

本章小结

企业内部数据市场要解决的，是"数据存在但流动困难"的问题。数据被困在团队与权限边界之内所引发的重复采集、重复清洗、权限不清与质量不透明，其成本往往被分散在各项目中而不被统一核算；内部数据市场以 FAIR 为基础，把数据资产、授权流程、使用审计、价值反馈与共享激励连接为一个可持续运行的治理系统，目标不是让数据无条件开放，而是让共享更有边界、更有证据、更有责任。

实现这一目标依赖角色分工与共享治理机制的协同：数据提供方、消费方、审批方、平台方与安全合规方通过标准流程与责任矩阵各司其职；授权模型在基于角色的访问控制之上叠加基于属性的访问控制，从"能否访问"走向"为何访问、如何访问、访问多久"的用途权限，并辅以用途限制、访问日志、过期回收与违规处置。共享只是起点，高价值资产应进一步沉淀为带 SLA 与数据契约、可长期订阅的数据产品，并以运营指标和共享激励，让共享行为可观测、可评价、可改进。

参考文献

Abraham R, Schneider J, vom Brocke J (2019) Data governance: A conceptual framework, structured review, and research agenda. International Journal of Information Management 49:424-438.

Alhassan I, Sammon D, Daly M (2016) Data governance activities: an analysis of the literature. Journal of Decision Systems 25(sup1):64-75. https://doi.org/10.1080/12460125.2016.1187397.

DAMA International (2017) DAMA-DMBOK: Data Management Body of Knowledge, 2nd Edition. Technics Publications.

Dehghani Z (2022) Data Mesh: Delivering Data-Driven Value at Scale. O'Reilly Media.

Ferraiolo D F, Kuhn D R (1992) Role-Based Access Controls. In: Proceedings of the 15th National Computer Security Conference, pp 554-563.

Gebru T, Morgenstern J, Vecchione B, Vaughan J W, Wallach H, Daumé III H, Crawford K (2021) Datasheets for Datasets. Communications of the ACM 64(12):86-92.

Hu V C, Ferraiolo D, Kuhn R, Schnitzer A, Sandlin K, Miller R, Scarfone K (2014) Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST Special Publication 800-162. https://doi.org/10.6028/nist.sp.800-162.

Khatri V, Brown C V (2010) Designing data governance. Communications of the ACM 53(1):148-152. https://doi.org/10.1145/1629175.1629210.

Ladley J (2019) Data Governance: How to Design, Deploy, and Sustain an Effective Data Governance Program, 2nd Edition. Academic Press.

Laney D B (2017) Infonomics: How to Monetize, Manage, and Measure Information as an Asset for Competitive Advantage. Routledge, New York.

Moody D, Walsh P (1999) Measuring the Value of Information: An Asset Valuation Approach. In: Proceedings of the 7th European Conference on Information Systems (ECIS), pp 496-512.

National Institute of Standards and Technology (2020a) Security and Privacy Controls for Information Systems and Organizations. NIST Special Publication 800-53 Revision 5.

National Institute of Standards and Technology (2020b) NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0. https://doi.org/10.6028/nist.cswp.10.

Otto B (2011) Data Governance. Business & Information Systems Engineering 3(4):241-244. https://doi.org/10.1002/9781118269053.ch4.

Reis J, Housley M (2022) Fundamentals of Data Engineering. O'Reilly Media.

Sandhu R S, Coyne E J, Feinstein H L, Youman C E (1996) Role-Based Access Control Models. IEEE Computer 29(2):38-47.

Schomm F, Stahl F, Vossen G (2013) Marketplaces for data: an initial survey. ACM SIGMOD Record 42(1):15-26.

Sculley D, Holt G, Golovin D, Davydov E, Phillips T, Ebner D, Chaudhary V, Young M, Crespo J-F, Dennison D (2015) Hidden Technical Debt in Machine Learning Systems. In: Advances in Neural Information Processing Systems 28, pp 2503-2511.

Weber K, Otto B, Österle H (2009) One Size Does Not Fit All: A Contingency Approach to Data Governance. ACM Journal of Data and Information Quality 1(1):4.

Wilkinson M D, Dumontier M, Aalbersberg I J, Appleton G, Axton M, Baak A, Blomberg N, Boiten J-W, da Silva Santos L B, Bourne P E, Bouwman J, Brookes A J, Clark T, Crosas M, Dillo I, Dumon O, Edmunds S, Evelo C T, Finkers R, Gonzalez-Beltran A, Gray A J G, Groth P, Goble C, Grethe J S, Heringa J, 't Hoen P A C, Hooft R, Kuhn T, Kok R, Kok J, Lusher S J, Martone M E, Mons A, Packer A L, Persson B, Rocca-Serra P, Roos M, van Schaik R, Sansone S-A, Schultes E, Sengstag T, Slater T, Strawn G, Swertz M A, Thompson M, van der Lei J, van Mulligen E, Velterop J, Waagmeester A, Wittenburg P, Wolstencroft K, Zhao J, Mons B (2016) The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data 3:160018. https://doi.org/10.1038/sdata.2016.18.