跨部门数据共享怎么实现？

跨部门数据共享卡住，通常卡在四个地方：不知道有哪些数据、同名指标口径不同、审批链条太长、出了问题找不到责任人。把这四件事拆开处理，共享才能从一次性取数变成可重复使用的机制。

下面按一条完整链路展开：先定共享对象和权威源，再写口径契约，接着做分级授权和例外审批，最后用审计与纠错收尾。文末给出一份可直接填写的责任单和四周试点安排。

一、先定共享什么，以及由谁提供

1. 从一个高频决策倒推数据清单

跨部门共享容易从“把数据都汇过来”开始，结果汇了很多表，业务还是不用。更有效的起点是一个反复发生的决策。比如市场和运营都要分析同一批用户，市场想知道哪些渠道带来高留存用户，运营想知道这些用户在哪一天流失、该发什么内容召回。

把这些问题拆成四列：要回答的问题、需要的指标、拆分维度、数据所在系统。列完以后，通常会看到两类需求。一类是少数几个核心指标被多个部门反复使用，另一类是大量临时取数。第一类适合做成共享资产，第二类先走自助查询或临时授权。

上海交通大学建设共享库时，先调研各部门业务系统的功能和数据情况，用 U/C 矩阵标出谁产生数据、谁使用数据，再确定高频共享清单和权威源。这个顺序比先买平台更稳，因为共享范围来自真实需求，不来自系统清单。

2. 一数一源，先定权威源

同一个客户，客户关系管理系统、订单系统、客服系统各有一份记录。共享时如果不指定权威源，接收方会拿到三份都能自圆其说的数据。没有权威源，共享出去的每份数据都像真的，争论永远结束不了。

权威源要写清系统、表、字段、更新频率和责任人。数据目录不必一开始就很全，先把高频共享的 20 到 30 个数据项登记清楚，比做一份没人维护的全量目录更有用。

3. 原始明细、指标和标签分开共享

三种数据形态的风险和使用方式不同，共享方式也要分开。

• 原始明细适合放在受控环境里查询，能不给下载就不给下载。
• 指标适合通过统一出口提供，避免每个部门各算一遍。
• 标签适合只输出结果，不暴露打标规则和原始行为。

共享方式跟着数据形态走，能少给明细就少给。这样既降低泄露风险，也减少接收方的理解成本。

二、把口径写成共享契约

1. 一个指标只留一处定义

口径争议往往在共享之后才暴露。市场说活跃用户是登录过的用户，运营说有核心行为的用户，财务只认付费用户。三个部门都没错，错在没有共同定义。

一个可执行的口径至少包含八项：业务含义、计算公式、统计粒度、时间窗口、过滤条件、排除规则、责任人和版本。 以活跃用户为例，要回答是按登录去重，还是按有业务行为去重；统计自然日，还是滚动 30 天；是否剔除内部账号和测试账号。这些问题不写清，开会就会变成对数会。

指标数量多、变更频繁时，可以考虑用指标管理平台承接定义、版本和权限。更彻底的做法是把指标定义放进统一语义层，让报表、自然语言问数和 Agent 任务都调用同一处定义。

2. 变更走版本

口径变更要有申请、影响范围、生效日期和通知对象。能并行跑一段新旧口径就并行，至少保留一个完整周期的对照数据。没有版本记录，历史报表就会失去可比性，业务会逐渐不再相信数据。

3. 用共享清单固定边界

共享清单是责任单的附件，也是权限配置的依据。下面是一张可以直接使用的表。

没有列入清单的数据，默认不共享。 临时需求走单独申请，不靠口头答应。

三、按敏感度分级授权

1. 先分级，再谈共享方式

《数据安全法》第二十一条要求建立数据分类分级保护制度，按数据的重要程度，以及一旦被篡改、破坏、泄露或者非法获取、非法利用可能造成的危害程度实施保护。企业可以据此把共享数据分成四级：公开数据、内部数据、敏感数据、个人信息与重要数据。

分级结果决定审批层级、可见范围、脱敏要求和保存期限。不要用一套权限覆盖所有数据。客户手机号和门店销售额放在同一个审批层级，既拖慢低风险需求，也放松了高风险数据。

2. 内部共享与对外提供要分开

同一家公司内部，部门之间共享数据，通常不构成《个人信息保护法》第二十三条所说的向其他个人信息处理者提供。内部共享仍然要有合法依据、最小必要、访问控制和操作记录。《个人信息保护法》第五十一条要求对个人信息实行分类管理，采取加密、去标识化等措施，并合理确定操作权限。

如果接收方是独立法人、外部服务商或合作伙伴，就进入对外提供场景。第二十三条要求告知个人接收方名称或者姓名、联系方式、处理目的、处理方式和个人信息种类，并取得单独同意；接收方变更目的或者方式，还要重新取得同意。

同一公司内部部门共享与向外部处理者提供，适用不同的合规路径。 把这条边界写进责任单，审批人才能判断该走内部授权还是对外提供流程。涉及敏感个人信息、重要数据或者跨境的，再交给法务和安全团队做专项评估。

3. 最小权限的几种做法

权限配置的目标是让接收方完成当前任务，不让他拥有一个部门的全部数据。常用做法有几种。

• 行列权限：只开放需要的列，只开放管辖范围内的行。
• 脱敏展示：手机号、身份证号等字段只显示必要部分。
• 时限控制：按项目开通，到期自动回收。
• 沙箱查询：数据不出环境，只带走查询结果。
• API 调用：按接口和调用频率授权，不交付全量文件。
• 水印与导出审批：批量导出单独审批，文件带追踪标识。

这些手段可以组合。市场做分群时给标签结果和聚合人数，运营做召回时给受控明细，财务做收入分析时给汇总指标，不必给同一份原始表。

四、把审批从逐单签字改成分级授权

1. 高频低敏数据做预授权

审批慢，往往因为每单都重新判断一次。高频、低敏感、用途稳定的数据，可以提前把规则定好，让系统自动判断，人工只处理例外。

东航把数据做成标准化卡片，员工在统一入口像订阅服务一样申请，审批流程线上化。公开报道显示，数据流转时间从平均 7 天缩短到 3 天以内，审批效率提升近 60%，覆盖飞行运行、机务维修、市场营销等 8 个业务领域。这个案例可复用的点，是把同一类、低风险、高频次的申请固化成规则，不靠审批人临时拍板。

2. 高敏数据保留例外审批

高敏数据、对外提供和二次共享，仍然要逐单看。审批材料至少回答六个问题：用途是否具体、范围是否必要、保存多久、是否对外提供、采取什么安全措施、谁负责复核。审批人缺其中任何一项，都很难判断风险。

例外审批的数量应该少，规则要清楚。否则申请人不知道什么时候该走哪条路径，又会回到排队。

3. 一次授权设置有效期

吉安市推行“一次授权、平台共享”，数据提供部门把高频数据调用权限集中授予市大数据中心，由中心统一研判和授权。国家数据局公布的案例显示，平台接入近 500 个部门、超 32 亿条数据，审批周期从 10 余天缩短到分钟级。

企业可以借鉴授权集中和流程前移，但不要把“一次授权”理解成永久授权。一次授权要有有效期和回收机制。 更稳妥的做法是按年度或者按项目设置期限，到期前由数据所有方复核用途、范围和访问记录，再决定续期或者回收。

五、共享之后怎么追踪和纠错

1. 使用记录要能回答五个问题

谁在用、用了什么、为什么用、什么时候用、数据流向了哪里。日志要覆盖申请、授权、查询、导出、接口调用和二次共享。对批量导出、非工作时间访问、超出申请范围的查询设置告警。

日志的价值在于事后能还原，也在于事前有约束。接收方知道操作会被记录，申请时会写得更具体。

2. 质量问题和口径争议要有 owner

数据质量问题和口径争议要分开处理。数据错误由权威源责任人修，口径争议由指标 owner 裁决，权限异常由安全团队处理。每类问题给一个响应时限，处理结果回写到共享清单。

数据质量在共享前就要管。 源头治理和跨源数据关联没有做好，共享只会把错误放大。上海交通大学在共享库建设中安排了专员持续运维，并建立数据异常反馈和修正机制。这个做法说明，共享库需要有人负责日常维护，不能只在项目期有人管。

3. 定期清理

每季度看三件事：低使用率的接口和数据卡片、到期的权限、无人维护的数据项。该下线的下线，该回收的回收。共享机制的成本在维护，不在第一次开通。

六、一份可直接填写的跨部门数据申请与使用责任单

把前面的规则收在一张表里，审批和使用就有共同依据。下面这份责任单可以直接复制到文档或者工单系统。

责任单要留版本号。规则变了，旧版本保留，新申请用新版本。

配套的最小流程可以压缩成七步。

• 申请人提交责任单。
• 数据所有方确认口径、权威源和可行性。
• 安全或者法务按敏感级别审批。
• 平台团队开通最小权限。
• 申请人按约定用途使用并保留记录。
• 发现问题按类型提交反馈，责任方处理。
• 到期复核，续期或者回收。

每一步都要有名字和时限，否则责任单只是一张表格。

七、技术侧承接什么

1. 四类基础能力

技术侧通常要承接四类能力：数据目录、指标语义层、数据服务、权限与审计。数据目录解决“有什么”，语义层解决“怎么算”，数据服务解决“怎么取”，权限与审计解决“谁能用、用过什么”。

这四类能力不要求一次建齐。可以先有共享清单和人工审批，再用现有工具补权限和日志，最后把高频需求产品化。

2. ThinkingAI 能承接哪一段

ThinkingAI 的企业级知识库把同一概念的定义收在一处，用 SSOT 保证全系统只有一处定义，更新通过 ChangeSet 记录，可追溯、可对比、可回滚；加工后的知识通过统一接口提供给报表、问数和 Agent 调用。Agentic Engine 支持私有化部署和多 Agent 协作，企业可以在自己的环境中管理 Agent 的任务、权限和运行记录。

公开资料显示，截至 2025 年 7 月，ThinkingAI 已服务 1500 家企业，接入产品超过 8000 款。它适合已经有数据仓库、商业智能或者分析平台，希望把指标定义、业务知识和 Agent 执行放在同一套口径上的企业。数据分级、审批规则和授权责任仍要由企业自己定义，平台承接的是规则之后的语义与执行。如果数据需要留在企业内网，可以选择私有化部署。

权限控制和运行监控可以在 Agent 管理里统一配置，避免每个业务团队各自建一套。

3. 先规则后工具

一个常见顺序是：先用表格和现有系统跑通一个场景，确认审批、口径、权限和纠错都能执行，再决定要不要上平台。工具能降低执行成本，不能替代责任划分。

八、用四周跑通第一个共享场景

试点不要选全公司最复杂的数据。选一个重复发生、涉及两个部门、敏感度中等的场景，比如市场与运营共用一套用户分群指标。

试点看五个指标：审批时长、首次拿到数据的时间、口径争议数量、同一数据被复用的次数、异常访问从发现到处理的时间。

试点不追求全覆盖，追求一套能重复执行的流程。 流程跑通后，再复制到第二个、第三个场景。

常见问题

跨部门数据共享一定要建数据中台吗？

不一定。共享的起点是共享清单、权威源、口径和责任单。数据量不大、需求不复杂时，用现有系统和人工流程也能跑通。数据源多、复用频繁、权限复杂时，再考虑用数据中台或者数据服务平台承接，避免为了一个场景上重资产。

业务部门担心数据泄露，怎么降低顾虑？

把范围缩小、把权限设短、把操作留痕。先给聚合结果或者标签结果，确认业务价值后再逐步开放明细；对导出、二次共享和对外提供单独审批；把日志和异常告警开放给数据所有方查看。信任来自可验证的控制，不来自口头承诺。

共享后发现数据错误，责任在谁？

权威源责任人对数据质量负责，接收方对使用方式和二次传播负责，指标 owner 对口径争议负责。问题单要记录发现时间、影响范围、修复结果和通知对象。把这三类责任写进责任单，出了问题时才不会互相推。

同一公司内部共享员工个人信息，需要单独同意吗？

同一公司内部部门之间共享，通常不构成向其他个人信息处理者提供，不直接触发《个人信息保护法》第二十三条的单独同意要求。内部共享仍然要有合法依据、最小必要、权限控制和日志。用于人力资源管理所必需的情形，与跨部门用于其他目的的情形要分开判断，拿不准时让法务确认。

审批应该由 IT 还是业务拍板？

数据所有方确认能不能给、口径是什么；业务负责人确认用途和范围；安全与法务确认合规边界；平台团队负责开通和回收。把四个角色写进流程，避免一个部门既当申请人又当审批人。

小团队没有平台怎么开始？

先用共享清单、责任单和现有工具的权限功能。把高频数据项列出来，指定权威源和责任人，用一个 Excel 或者工单系统记录申请、审批和到期时间。跑通三个月后，再根据重复劳动最多的环节决定要不要买工具。

参考资料

• 国家数据局，《城市全域数字化转型典型案例集之二十三：吉安建立数据专员制度和“吉数通”平台推动城市数据资源高效共享》，2025 年 1 月 11 日，https://www.nda.gov.cn/sjj/ywpd/szsh/0103/20250103135915694803259_mobile.html
• 中国民航网，《打破部门数据孤岛 东航创新打造“数据卡片市场”》，2025 年 5 月 25 日，http://www.caacnews.com.cn/1/6/202505/t20250525_1387588.html
• 中国教育网络，《案例分享｜高校数据共享创新应用》，2025 年 2 月 12 日，https://www.cernet.edu.cn/info/xy/xytp/202502/t20250212_2654407.shtml
• 最高人民检察院，《中华人民共和国个人信息保护法》，2021 年 8 月 20 日，https://www.spp.gov.cn/zdgz/202108/t20210820_527240.shtml
• 中央网络安全和信息化委员会办公室，《中华人民共和国数据安全法》，2021 年 6 月 10 日，https://www.cac.gov.cn/2021-06/11/c_1624994566919140.htm