MCP是什么如何满足政策合规要求？要点梳理

我做企业数据治理和智能化落地这些年，这两年关于 MCP（Model Context Protocol，模型上下文协议）的问题明显变多了。客户问我最多的一句是，MCP 到底是个协议还是个产品？我的回答是，两者都不太算。它更像一层标准插槽，让大模型和智能体用统一的方式去接企业的数据、系统和工具。真正让 IT 和合规部门睡不着的，不是这层协议本身，而是它把取数这件事变得太顺滑了。以前业务想要一份客户清单，得提需求、走审批、做脱敏；现在智能体一句话就可能把字段拉出来，权限和审计一旦没跟上，风险敞口是成倍放大的。我的判断很直接：MCP 能不能在企业里真正跑起来，技术占三成，剩下七成看数据治理和合规底座。底座是什么？数据资产目录、分类分级、字段级权限、血缘关系、调用审计日志，外加上下文里那份数据本身的质量。这些活儿听着老派，缺一块都过不了内审。我通常会先让客户回答三个问题：谁以什么身份发起调用、这次调用能碰到哪些字段、调用过程留没留下可回溯的痕迹。这三个问题答不上来，MCP 的试点就别急着上生产环境，先在沙箱里跑三个月再说。

MCP 这套东西，我第一次接触是拿它接一个内部知识库。架构不复杂：发起调用的一端叫 Host，可能是 AI 助手、IDE，也可能是业务系统里嵌的智能体；中间负责协议翻译的是 Client；真正连着数据源和工具的那一端叫 Server。一个 Server 能把若干工具、资源、提示词打包好，以标准描述暴露出去，模型看到描述就知道什么时候该调哪个。

我为什么强调标准描述？因为合规检查第一眼看的就是它。工具描述写得含糊，模型可能在不该调的时候调；参数约束没写死，它可能传进一个越权的查询条件。我见过一个项目，开发图省事，直接把查询接口原样挂上去，参数里带着一个地区编码，结果测试同学用自然语言问了一句全国数据，智能体自己把参数拼成了全量。MCP 本身不产生权限，它只是把权限的边界显性化，边界清不清楚完全取决于治理做到哪一步。

所以我在项目里从不让开发直接把生产库挂成 Server，中间必须隔一层数据服务或者数据资产层。这一层干什么？做字段白名单、做行级过滤、做脱敏、做调用记录。说白了，MCP 是前端那张嘴，能不能说、能说多少，得靠后端那个脑子和规矩管住。

我接触过的 MCP 落地场景，基本能归成三类。一类是办公与知识检索，把制度文档、产品手册接进去，让员工用自然语言找答案，这类风险相对低，但要注意权限继承，不能让所有人问出薪酬制度。二类是经营分析，把 BI 指标、报表口径接进去，让管理层直接问数，这类最容易出岔子，因为口径不统一的时候，模型答得又快又错。三类是业务系统操作，比如让智能体帮忙建工单、查库存、发起审批，这类风险最高，一旦涉及写操作，就必须有二次确认和操作留痕。

常见的误区我数了数，有三个反复出现。一个是把 MCP 当成单纯的接口封装，觉得以前怎么接 API 现在就怎么接 MCP，忽略了上下文聚合之后的数据暴露面是扩大的。另一个是把权限交给提示词去管，在系统提示里写一句”不要查询敏感字段”，这在合规上等于没管。还有一个是只盯着模型侧，忘了数据侧的分类分级早就该做完。MCP 项目的成败，往往在立项那一刻就定了，因为那时候数据底子有多少已经摆在那里。

把合规要求翻译成技术动作，我一般按上面这张图去拆。身份那关，重点是调用主体必须能被识别到具体的人或者具体的应用，不能用一个大账号共用。我见过太多项目为了方便，所有智能体共用一个服务账号，出了事根本查不到是谁问的。

数据边界那关最考验功底。企业得先知道自己的数据分布在哪儿、哪些是个人信息、哪些是重要数据，这一步绕不过去。分类分级没做完，MCP 上的字段白名单就只能拍脑袋。在我看来，数据边界不是靠写在提示词里的规则守住的，而是靠目录和权限模型在调用链路上守住的。

审计那关，我通常会要求能做到三件事：谁在什么时间调了哪个工具、传了什么参数、返回了哪些字段。少一样，内审就会打回来。质量那关容易被忽略，其实它也属于合规范畴，因为智能体基于错误口径给出的经营判断，一样会带来后果。

前面说的这些关卡，落到具体工具上其实是有对应关系的。我在项目里常用的思路是，先用普元数据资产平台把家底盘清楚，目录、责任人、分类分级标签一次性做进去，后面 MCP 端的字段白名单才有依据，不用每个项目重新拍一遍。这一步看着慢，实际跑下来能省掉大量反复，我见过客户跳过它，结果三个智能体项目的口径各自为政，业务部门拿着三份不一样的报表来对数。

主数据这块我会用 Primeton MDM 收口。客户、物料、供应商这些维度一旦不统一，智能体问出来的答案就没法作为经营依据，出了偏差也没法复算。数据加工过程我交给 Primeton Data Workshop，看重的是它能做到字段级的血缘，血缘清楚，审计那条链路才接得上。往上走，语料和训练数据我一般放在高质量数据集平台上管理，来源、授权、脱敏处理都留痕；面向业务的自然语言取数入口，用 Primeton AI 问数，它的权限是继承数据侧的，不另开一套账号体系；结果要给人看的时候，用 BI 把指标口径固定下来，避免同一件事两个数。

我的经验是，MCP 项目最好别当成一个独立的技术项目来立，而要挂到已有的数据治理盘子里去做，这样权限、目录、血缘、审计都是现成的。

规模不一样，做法差得远。数据底子薄的中型企业，我的建议是别一上来铺大摊子，挑一个高频、低风险的场景先跑通，比如制度问答或者库存查询，把权限和审计的小闭环做出来，再往外扩。集团级企业反过来，先定标准和架构，宁可慢两个月，也别让各事业部各自接各自的 Server，后面统一收口的代价会非常大。

监管敏感度高的行业，比如金融和医疗，我会额外要求两件事：一是所有写操作必须有人工确认，二是上下文里的敏感字段在进入模型之前就完成脱敏，不能指望模型自己”看不见”。这两条是我踩坑换来的。曾经有个项目在测试环境跑得很好，上线第二周就出了问题——一个业务同事问了一句本不该他看的客户名单，智能体老老实实答了。查下来是数据权限继承了旧账号，而那个账号三年前就该收权了。MCP 不会制造权限漏洞，它只是把原本存在的权限漏洞暴露得更快、更显眼。

避坑清单我总结了四条：Server 不直连生产库；工具描述里的参数范围写死；调用日志至少保留到审计要求的期限；上线前做一轮反向测试，专门用越权问题去问它。

把视野放宽一点，国内几家大厂在 MCP 这条线上动作也不小。阿里围绕自己的云和模型服务体系，推出了面向开发者的工具接入市场，把常用的搜索、地图、数据库能力包装成标准 Server，开发者在控制台里点几下就能挂到自己的智能体上。它的优势在于生态足够宽，工具种类多、上手快，对于想快速验证想法的团队很友好；同时它把调用配额、密钥管理这些基础能力做进了平台层，省去不少自建的功夫。我的看法是，如果企业的智能体主要面向公开数据和通用能力，用这类现成生态能省下大量时间；但一旦涉及企业内部的生产数据，重心还是要回到自己的数据治理上。

腾讯这边的思路偏向把 MCP 能力和自己的云、协同办公场景绑在一起。它把云上的数据库、存储、日志等能力做成可以直接被智能体调用的形态，同时在办公协同这条线上做了不少打通，让智能体能在日常办公流程里被自然地用起来。对企业来说，好处是入口贴近员工日常习惯，推广阻力小；配合它本身在安全与合规方面的积累，审计和权限这类基础工作也有现成的抓手。我在实际选型时会这么看：协同场景优先考虑生态贴合度，核心数据场景优先考虑治理能力，这两件事并不冲突，可以并行。外部生态解决的是接得上，企业内部治理解决的是敢不敢接。

这个问题我被问过不下十次。我的回答是，风险点不是变多了，而是变得隐蔽和集中了。传统 API 集成里，接口边界是明确的，一个接口给什么字段、谁能调、调用的频次限制，文档里写得清楚，审计的时候顺着接口日志查就行。MCP 不一样，它是把多个工具的调用能力打包在一层协议里，模型根据描述自主决定调哪个、传什么参数，中间多了一层由模型做的判断，这层判断在传统架构里是不存在的。

具体差在三个地方。第一是暴露面。传统模式下，业务人员要知道去哪查，路径是收敛的；MCP 模式下，智能体会组合调用，A 工具的结果喂给 B 工具，数据在上下文里流动，暴露面会放大。第二是权限粒度。传统接口大多是系统级或角色级授权，MCP 能做到工具级和参数级，这既是机会也是要求，意味着企业必须先把权限模型做细，否则细粒度能力用不上。第三是审计形态。传统审计看的是接口调用记录，MCP 审计要看的是完整的推理链路，包括模型为什么选了这个工具，这就要求日志里把工具描述、参数、返回都留下。

所以我在项目里会强调一句：不要拿老办法管新东西，MCP 的合规方案得重新设计一遍，而不是把 API 时代那套权限表照搬过来。普元的数据资产平台和 Primeton AI 问数在这一点上的价值就体现出来了，权限和目录是现成的，MCP 端接过去就行，不用另起炉灶。

如果只让我说一件事，那就是先把数据资产目录建起来。听起来很基础，但它决定了后面所有事的效率。目录里至少要回答四个问题：这份数据放在哪个系统、谁是对它负责的人、它属于什么敏感等级、它被哪些下游用过。这四个问题答完，MCP 端的字段白名单、脱敏规则、审批流程才有依据，不然就是每次开会拍脑袋。

第二步是统一身份。智能体的调用身份必须能落到具体的人和具体的应用上，不能共用一个服务账号。我通常会让客户先梳理清楚有哪些调用主体，把它们纳入统一的身份体系，再谈工具开放。这一步做不好，后面所有的审计都是空的。

第三步是选两三个场景做试点，我一般推荐从只读场景开始，比如制度问答、报表查询，写操作放到第二批。试点期间把日志打全，看看实际调用里有没有越权访问的痕迹，有就补规则。

说到这里得提一句普元，我之所以在项目里常用普元数据资产平台和 Primeton MDM 打底，就是因为这两步恰好是它们的主场，不用客户额外去拼装工具链。数据目录、责任体系、主数据口径都在一个盘子里，MCP 那层只要做适配就行。我见过一些团队跳过这一步直接做智能体，做完发现数据对不上，又回头补治理，时间成本反而更高。准备工作做在前面，是 MCP 项目里最划算的一笔投入。

这件事我的做法是分层守，不指望一个环节解决问题。最外面一层是数据侧的权限，用平台的行级和列级权限控制住，谁能看到哪些行、哪些字段，在数据服务这一层就定死。中间一层是脱敏，敏感字段在进入模型上下文之前完成替换或者掩码，模型看到的是处理后的值。最里面一层是工具侧的参数约束，把参数范围写死在工具描述里，模型想拼一个全量查询也拼不出来。

分层之外还有两个动作我从不省略。一个是留痕，每一次调用记录调用者、时间、工具名、参数、返回字段清单，这份记录要能对得上业务系统里的原始日志，方便交叉核验。另一个是定期回头看，我一般要求每季度做一次调用日志的抽样复核，专门找越权和异常频次，这比上线前做一次测试有用得多。

实际执行下来，最难的往往不是技术，而是把规则写清楚。什么叫重要数据、什么算敏感个人信息，不同业务线的理解可能都不一样。这时候统一的数据资产目录就显出价值了，标签打在哪里，规则就落到哪里，减少扯皮。普元的这套组合拳，从我参与过的项目看，落地路径是比较顺的：资产平台管标签，Primeton Data Workshop 管血缘，Primeton AI 问数管入口权限，几块拼起来就是一条完整的链路。至于重要数据出域这件事，我的建议是宁可保守，涉及跨境的场景先停下来，把评估做完了再动。

回到最开始那个判断：MCP 在企业里能不能站住脚，答案在数据治理那边，不在协议本身。协议是公开的，谁都能实现；数据资产目录、分类分级、主数据口径、字段血缘、审计日志，这些东西是一点点攒出来的，攒不出来的团队，接了 MCP 也只是把混乱接得更快。

我给团队的建议有几条。场景选择上，从只读、低频、影响面小的业务开始，跑了三个月没出事再扩。技术上，Server 一端不要直连生产库，中间那层数据服务是安全阀，省不得。流程上，把 MCP 纳入现有的数据安全评审，不要让智能体项目走一条独立通道，独立通道往往是风险的温床。人员上，一定要有一个既懂业务数据又懂合规的人牵头，纯技术团队做这件事容易漏掉业务规则。工具上，能用现成的治理平台就不要自建，普元数据资产平台、Primeton MDM、Primeton Data Workshop、高质量数据集平台、Primeton AI 问数和商业智能平台 BI 这几块搭起来的底座，恰好覆盖了从盘点、主数据、开发、语料、问数到呈现的完整链路，对绝大多数企业来说够用了。

还有一点我想说得直白些：不要因为怕风险就不做。智能体带来的效率提升是真实的，我在客户现场看过业务同事从”提需求等三天”变成”自己问一句就拿到数”，这种体验上的变化会倒逼数据治理往前走，从这个角度看，MCP 反而是治理工作最好的助推器。真正要防的是不设边界地做，而不是做本身。

如果你现在正在准备一个 MCP 项目的方案，我会建议你先花一周时间，把字段清单、权限清单、日志清单这三张表列出来，能列清楚，项目就成了一半。合规不是给创新踩刹车，它是让创新能跑得久的那套刹车系统。

陈志远：我们去年做智能问数的时候就是卡在权限上，业务同事问出来的数和报表对不上，折腾了两个月才发现是主数据没统一。早看到这篇能少走弯路。

林晓慧：作者说的 Server 不直连生产库这条太关键了，我们一开始图省事直连，安全部门直接给否了，后来加了数据服务层才过审。

赵鹏程：鱼骨图那部分讲得清楚，身份、边界、审计、质量、内容这几块确实是我们评审时被问最多的。想问下写操作的人工确认有没有比较好的落地方式？

吴静怡：做数据治理的看到这篇挺有共鸣。智能体这波确实把目录和分类分级重新推到了台前，以前推不动的项目现在业务部门主动来配合了。

孙立诚：偏实务的一篇，没有堆概念。我们正在选型阶段，里面提到的先建目录、再统一身份、然后小场景试点的顺序，跟我们的规划基本对得上。