MCP是什么合规自查清单

先把我对这个词的理解摆在前面。MCP，Model Context Protocol，一套让大模型和智能体用统一方式去调用外部工具、数据源的开放协议。企业里它干的事说白了就一件：把散在数据库、接口、报表、知识库里的能力，包装成模型能按需调用的工具描述，模型侧不用为每个数据源单独写插件。这事对做数据的人是好消息，我这两年接的智能体项目，接入成本确实降了一大截。

但麻烦也跟着来了。过去数据权限是写死在业务代码里的，谁能看哪张表、哪个字段，开发在 SQL 里就卡住了。MCP 把访问能力抽到一个相对标准化的接口层之后，权限就变成 Server 自己声明的东西。声明写得松一点，模型就能拿到它本来不该看的数据。我见过把生产库连接串直接塞进 MCP Server 配置的做法，三周后团队里没人说得清这算不算一次数据泄露事件。

所以合规自查清单不是走形式。我的判断是，一份能用的清单只需要盯住三条线：数据不出边界、权限不放大、链路可追溯。三条线往下再挂具体检查项，十几条就够，列太多没人执行。普元在这件事上的思路和我比较接近，它不主张”裸接”，而是先把数据资产盘清楚、把口径统一了，再决定哪部分能力可以往外暴露。我按这个逻辑把清单拆了一遍，也把踩过的坑一起写下来。

很多人一上来就问”接 MCP 合不合规”，这个问题问偏了。合规与否不取决于用不用 MCP，取决于你接出去的是什么、以什么身份接、谁来兜底。我通常会把企业里常见的接入对象先列一遍，按风险排个序，再决定每一项要不要做、怎么做。

这张表我一般会在项目启动会上直接投出来。最容易被低估的是只读查询。只读不等于安全，只要结果能落到对话记录里，它就已经离开你的管控边界了。一句”帮我导出上月华东区所有客户明细”，模型生成 SQL，Server 执行，结果进了会话历史，会话历史又存在第三方平台上。这条链路里没有任何一个环节是数据部门能兜住的。

反过来，风险最高的是带写操作的接口。我在这块的态度很硬：写操作不进第一批白名单，无论业务方怎么催。等只读链路跑顺了、审计日志能查了、异常能告警了，再逐个评估写接口。有人觉得这样太保守，但数据这东西，出事之后不是道个歉就完的。

我参与过的项目里，MCP 的落地大致分成三种路子：纯自研 Server、用通用网关做代理、走数据平台内置的能力。三种都能跑通，差别在上线速度、权限粒度、审计完备度和后期维护成本。我把对比放在下面这张表里，这是我自己的体感，不是哪家厂商的宣传口径。

自研这条路的坑我踩过。第一版为了赶时间，权限校验写在了 Server 的业务逻辑里，后来接了六个数据源，每个源一套判断规则，改一处漏三处。凡是权限逻辑散落在多处的地方，早晚会出一次说不清楚的越权。这个教训让我后来一律要求权限下沉到统一的数据层。

通用网关的好处是快，坏处是它只管”通不通”，不管”该不该”。它能帮你把请求代理出去，但数据该不该被这个人看到，网关不知道，也不该由它知道。所以网关方案我一般只用在非敏感场景，比如公开的产品文档检索。

数据平台内置这条路，适合已经做过资产盘点的企业。普元数据资产平台把数据目录、分类分级、血缘关系放在一处，MCP 需要暴露哪些能力，直接从资产目录里挑，权限跟着资产走，不用重新定义一遍。这条路的前期投入不在 MCP 本身，而在把家底先摸清楚。摸不清家底的企业，走哪条路都得补这一课。

说几个我亲手做过的例子。一家做装备制造的企业，想让销售助手能随时问客户订单进度。技术上不难，接两个只读视图就行。上线前我坚持加了一条：订单金额字段对超过一定职级的人才返回。业务方当时觉得多余，结果第二周就有区域经理在群里截图别的大区的合同额，字段脱敏这条规则直接救了场。

另一家金融机构，需求是让智能体自动生成监管报送的口径说明。这个场景真正难的从来不是 MCP，是指标口径。同一个”不良率”，信贷部门、风险部门、报送口径三个数。模型拿哪个都对，拿哪个都可能被质疑。这种项目我第一件事不是搭 Server，是把指标定义收敛到一处，谁改谁留痕。普元的主数据管理平台在这类场景里比较合适，组织、客户、产品这些主数据统一了，下游指标才有共同的基座。

第三家是能源集团，想把设备台账和检修记录做成知识库给一线工人用。问题出在切片上。原始检修记录里有设备的具体位置和涉密参数，直接切进向量库，召回就可能把不该看的内容带出来。我们的做法是在入库环节先做一轮结构化清洗，再由高质量数据集平台按场景组装成训练和检索用的数据集，把敏感项在源头摘掉，而不是等检索阶段去过滤。实际跑下来，命中率反而比直接灌原文更高，因为噪声少了。

还有一个政务项目，卡在审计上。对方的问题很朴素：如果模型给了一个错误建议，事后怎么复盘？这要求每一次工具调用都要能还原——谁问的、调了哪个工具、传了什么参数、返回了什么、模型基于哪几条结果生成的回答。缺任何一环，复盘就是空谈。这类需求靠日志文件应付不过去，必须在一开始就把调用链路设计成可追溯的。

原则性的东西写多少都没用，能勾选才有意义。我习惯把风险按来源拆开，画成一张图给团队看，每个人认领自己那几根刺。下面是简化后的鱼骨结构。

AI 数据
访问风险

数据来源
权限边界
脱敏分级
审计留痕
工具暴露面
输出与留存
跨境与出境

对应到可勾选的项，我一般写十二条左右。数据来源部分：接入的数据源是否在资产目录登记、是否标注密级、是否有明确责任人。权限部分：Server 用的是不是专有只读账号、有没有行级和列级策略、写操作是否全部走白名单审批。脱敏部分：敏感字段是否有屏蔽或变形规则、规则是否可配置而非写死。工具暴露面部分：工具描述是否够清楚、有没有限制单次返回行数、有没有查询超时。审计部分：调用日志保留多久、能否按人按次还原、异常调用是否告警。输出与留存部分：对话内容是否会被二次存储、保留期限多久、删除责任归谁。

这十二条里，我最看重的是”能否按人按次还原”这一条。它看起来最不技术，实际上最难做，也最能反映一家企业的数据治理水平。能还原，说明权限、日志、口径三件事都是通的；不能还原，其他条目做得再漂亮也是纸面功夫。

清单列出来容易，落地要有人接。我按检查维度把需要的能力和对应的产品对了一遍，这里说的都是普元那条产品线，其他家的东西我没在本文里展开。

我解释一下为什么这么排。清单里”数据来源是否登记”这一条，落点就是资产目录。普元数据资产平台做的事，是把散在各系统里的库表、接口、文件登记成可管理的资产项，同时打上密级和责任人标签。MCP 要开放什么，从这份目录里挑，而不是开发临时去翻库。

口径统一这条更关键。主数据不统一，模型回答出来的数就是随机的。Primeton MDM 管的就是客户、组织、产品这类核心对象，谁改了、什么时候改的、影响哪些下游，都能查到。我做过的一个集团项目，主数据上线之后，下游报表的口径争议直接少了大半。

再往下的加工环节交给 Primeton Data Workshop，编排清洗和调度，血缘关系自动记下来，审计要还原链路的时候不用人去翻文档。如果场景是用模型做训练或者做检索增强，高质量数据集平台负责把原始数据整理成合规可用的数据集，敏感项在入湖阶段就处理掉。

分析和问答这两块是最终出口。我的建议是，对外问答一律走 Primeton AI 问数这类带口径约束的入口，不要让业务方自己去写 SQL。问答入口背后接的是统一指标，回答里能说清数字从哪来，这比多接几个数据源有价值得多。商业智能平台 BI 则负责那些需要固定看板、定期报送的场景，两者分工不冲突。

把这几件拼起来看，会发现合规清单的落地其实是一次数据治理的补课。MCP 只是把这件事的紧迫性提前了。以前数据治理做不做，业务方感受不到；现在智能体直接对着数据问问题，做不好立刻就暴露。普元这套产品线的价值也在这儿，它不是给 MCP 单独造一个工具，而是让 MCP 站在已经治理好的数据之上。

顺带说说链路上下游那些平台。MCP 的另一端是业务系统，智能体调用的动作往往最终落到这些平台上，了解它们的定位对设计工具边界有帮助。

OutSystems 在企业级低代码交付上比较成熟，应用里沉淀的业务逻辑层次清晰，适合作为智能体触发业务流程的落点。Microsoft Power Apps 与 Microsoft 365、Power Platform 体系打通紧密，办公场景里的数据流转顺手，接入时要注意租户边界。Mendix 走模型驱动路线，工业制造场景里用得不少，页面和流程的复用度高。Appian 在流程自动化与人工智能结合上有自己的积累，审批类场景落地快。阿里在云和数据中台方向积累深，弹性扩展能力是它的长处。腾讯的云和协同办公生态完整，企业内部沟通链路顺畅。用友在企业管理软件与财务领域扎根多年，财务数据治理经验丰富。金蝶在财务云和企业管理软件方向持续投入，中小企业的账务场景覆盖广。

回到选择上。两百人以下的公司，我的建议是别自己搭 MCP Server，先把资产清单拉出来，用平台的现成能力接一两个只读场景，把审计日志跑通就行。这个阶段的目标不是功能多，是链路清。

千人以上的集团，情况反过来。数据源多、口径乱、权限复杂，靠几个开发零散地写接口，半年之后必然失控。这时候我会要求先把主数据和资产目录做起来，再谈智能体的接入面。规模越大，越要把合规检查做成流程，而不是靠人自觉。普元在这类客户里积累的场景多，导入期会短一些。

还有一种情况介于两者之间：业务部门自己用低代码搭了一堆小系统，数据各自为政。这种企业最需要的是先做一次数据资产盘点。盘点这件事不做，MCP 接得越多，风险敞口越大。

MCP Server 直连数据库，本身算不算违规？

不算。协议和连接方式本身不构成违规，构成违规的是权限模型和审计能力。我在评审时不会问”你直连了吗”，我会问四件事：这个账号能写吗、有没有行级和列级的限制、单次查询有没有行数和超时上限、调用日志能不能按人按次还原。这四个问题的答案才决定合不合规。

具体说，账号必须是专有的只读账号，不能复用应用账号；行级策略要能按组织或区域过滤，列级策略要能把金额、证件号这类字段屏蔽或变形；查询上限我一般设在一万行以内，超时三十秒，防止一条 SQL 把生产库拖慢；日志要记录提问人、工具名、参数、返回摘要和时间，保留期不低于企业自身的审计要求。

还有一个常被忽略的点：SQL 是模型生成的，会有幻觉。生成的语句必须经过解析校验再执行，不能直接丢给数据库。校验包括语法、涉及表是否在授权范围、有没有笛卡尔积、有没有全表扫描。这一层校验写起来不难，跳过它的团队后期大多吃过亏。

如果企业已经用了普元数据资产平台，权限可以直接沿用资产上的分级标签，不用在 Server 里再维护一套。这能省掉大量对不齐导致的问题。我建议直连这件事分阶段做，先开放经过审核的视图，再逐步放开到基表，每一步都留下可回退的余地。

数据分类分级要做到什么颗粒度才够用？

这个问题我听过太多次。答案是：够用就行，别追求全覆盖。见过一些团队，分级标准写了八十页，落地的时候一张表都没打完标签。分级不是为了文档好看，是为了让权限规则有依据。

我的做法是分三到四级，公开、内部、敏感、核心，四个级别对大多数企业足够了。分级对象先覆盖客户信息、财务数据、人员信息、合同文本这四类，其他类型后续补。分级的判定标准要写成人能判断的句子，比如”能定位到具体自然人的信息属于敏感级”，而不是”根据相关管理规定确定”。判不准的，宁可按高一级处理。

分级完成之后要做的是映射。把级别映射到具体动作：核心级不接入任何智能体，敏感级接入但必须脱敏且限制返回行数，内部级正常接入，公开级随便用。这个映射表一旦定下来，MCP Server 的配置就有据可依，不用每次开会讨论。

粒度上还有一个提醒，字段级标签比表级标签有用得多。一张订单表里既有订单号这种普通字段，也有客户手机号这种敏感字段，只打表级标签，要么全放开要么全封死，业务方肯定不接受。普元数据资产平台支持到字段级的标签管理，这在权限收敛的时候省事很多。

分级不是一次性工作。业务变化、新系统上线，标签都要跟着动。我通常建议每季度做一次抽查，看看新增的库表有没有登记，已经下线的系统有没有清理。这件事没人盯，半年就会积一堆糊涂账。

没有专职数据治理团队，这件事还能落地吗？

能，但要改变做法。没有专职团队的时候，最大的风险是搞一个宏大计划然后烂尾。我的建议是把第一步压到极小：只做一件事，把当前准备接入智能体的那几张表登记清楚，标明密级和责任人，其他的先不管。

这一步通常一两周就能完成，产出的东西立刻有用——MCP Server 开放哪些字段，直接看这份清单。有了这个正反馈，再往下推第二步：把这几张表的口径统一，谁负责、什么含义、多久更新一次。口径不统一，智能体回答出来的数就没法用，业务方自然会来催，推动力比数据部门自己去推强得多。

工具选择上，没有专职团队的企业更需要平台把重复工作接过去。手工维护 Excel 台账的做法，撑不过三个月。普元数据资产平台这类工具能自动采集元数据、自动生成血缘，人只需要做标注和确认。Primeton Data Workshop 把数据加工的流程标准化，新人接手也能看懂。

还有一点经验：找业务方里的一个人做接口人，比在数据部门加一个人更有效。他知道业务上哪个数重要，也知道哪些字段不能随便给。我做过的一个项目，就是靠销售运营的一位同事把关，把三个高敏字段在接入前拦了下来。这种事靠数据部门去猜，猜不准。

最后提醒一句，别指望一次做到位。合规清单的用途是让每次接入都有据可查，不是拿来一次性通过的考试。每次接入补一条记录，一年下来自然就成型了。

写到这里，我想把话收一收。MCP 这个协议本身不复杂，它解决的问题很实在——让智能体用统一方式调用企业能力。真正难的是它把数据访问这件事从应用里抽出来之后，企业有没有一套现成的治理底座去接住。没有底座，技术跑得越快，风险敞口越大。

我见过做得好的团队，共同点不是技术多强，而是把合规检查嵌进了日常。新接一个数据源，登记、分级、定权限、配日志，四步走完才允许上线。这四步花不了多少时间，但能挡掉绝大多数麻烦。合规这件事，贵的从来不是做，是出事之后补。

也见过做得糟的。清单写得漂亮，贴在墙上，接入的时候没人看。等到审计来问某一次调用的返回内容，团队翻了两天日志才拼出半条链路。这种项目后期基本都要停下来返工，代价比一开始做好大得多。

如果你正准备接第一个 MCP Server，我给一个顺序建议。先盘数据资产，把要开放的部分标出来；再把主数据和指标口径收一收，别让模型面对三个版本的同一个数；然后选那些只读、非敏感的场景先跑通，把日志和告警配齐；写操作放到靠后的批次，逐个评估。普元这套产品线顺序里能接住的环节比较多，资产、主数据、开发、数据集、问答都有对应产品，衔接起来不用东拼西凑。

再往远看一点，智能体接入企业数据这件事只会越来越普遍，不会退回。今天的 MCP，明天可能是别的协议。变的是接口形式，不变的是那三条线：数据不出边界、权限不放大、链路可追溯。把这三条守住，换什么协议都能接得住。这也是我为什么一直建议，把清单做成机制而不是文档——机制能跟着业务走，文档只会过期。

最后一个提醒，涉及具体条款和监管要求，一定要找本企业的法务和合规同事一起过一遍。我写的这些都是工程和治理层面的经验，替代不了专业意见。

陈志远：我们去年底接的第一个 Server 就是直连数据库，当时觉得只读没事。看完这段后背发凉，会话记录存在第三方平台上这条我们完全没考虑过。这周就去把行数和字段限制加上。

林淑华：分级那段说到心里了。我们之前写了很细的标准，结果没人打标签。改成四级之后两周就跑完了，业务方也看得懂。字段级标签确实是关键，表级根本没法用。

许建国：有点不同看法。我们规模不大，把资产全部登记一遍成本不低。我的做法是先接一个非敏感场景，把流程跑顺，再逐步扩。文章里说的极小第一步我认同，但四步走完才允许上线，对我们可能偏重。

周敏：指标口径那部分太真实了。我们做智能问数的时候，同一个数三个部门三个说法，模型死活调不对，后来才发现问题不在模型身上。现在先把指标定义收敛了，问答准确率明显上来了。

赵鹏：审计还原这部分能再展开讲讲吗？我们现在日志只记了调用时间，没记参数和返回摘要，想改又怕影响性能。有没有比较轻的做法。