几乎每个地方的政法系统,办案系统、统计系统、综治平台、信访系统都建了不止一套,但真要做一次跨部门的态势分析、一次类案推送、一次辅助决策,数据却还是要靠人工东拼西凑——口径不一、孤岛林立、重复采集。数字法治政府的底层工程,不是再多建几个系统,而是建一套把数据统一治理、统一复用的「司法数据中台」。本文讲清这套中台该怎么建:四层架构怎么分、政法跨部门数据怎么共享、等保三级和信创怎么过、裁判文书与法规底座怎么接,以及分几期建、采购时该问供应商什么。
一、先厘清:数据中台到底解决什么问题
政法系统信息化建设走到今天,普遍卡在三个老问题上,而这三个问题恰恰是「数据中台」这个概念被提出来要解的:
- 数据孤岛:每个业务系统是一座烟囱,数据躺在各自的库里,法院的、检察的、公安的、司法行政的彼此不通,综合研判时只能人工导表。
- 口径不一:同一个「案件数」「涉案金额」「办结率」,不同系统统计规则不同,汇上来对不齐,领导看到的数字打架。
- 重复采集:一项数据被三个系统各自采一遍、各存一份,既浪费基层填报精力,又因为多份副本而越来越乱。
数据中台的价值,可以用一句话概括:数据一次汇聚、一次治理,以服务的形式被所有上层应用反复复用。它不是给人看的又一个大屏,而是垫在所有应用底下的数据底座与能力底座。大屏、研判、推送、辅助决策,都从这一套治理好的数据上长出来。
一句话辨析:「平台」是给人看的界面,「中台」是给应用复用的底座。如果一个项目建完只多了一块大屏、底层数据照旧各管各的,那它建的是平台,不是中台——半年后下一个应用要数据,照样得重新对接、重新清洗。
二、司法数据中台的四层架构
一套能落地、能迭代的司法数据中台,从下到上分四层,每层职责清晰、上层复用下层:
| 层 | 做什么 | 关键内容 |
|---|---|---|
| 数据汇聚层 | 把分散数据接进来 | 本地办案/统计/综治等业务库的数据接入;外部公共法律数据(全国裁判文书、法律法规、司法解释、地方规章)结构化导入;统一汇聚到政法专网内 |
| 数据治理层 | 把数据洗干净、对齐口径 | 清洗去重、标准化、主数据管理、统一指标口径、数据分类分级、脱敏规则、质量校验;形成可信的标准化数据资产 |
| 数据服务层 | 把数据变成能力,供上层调用 | 统一检索服务、类案匹配服务、要素抽取、统计分析 API、数据共享接口;含权限、审计、调用网关 |
| 应用层 | 面向具体业务场景 | 类案推送、辅助办案、综合研判大屏、量刑参考、文书辅助生成、跨部门协同——都复用同一套服务层能力 |
这套分层的好处是解耦:换一个应用,不动数据;加一类数据,不动应用。第一期可能只接通「数据汇聚 + 治理 + 一个检索服务 + 一个类案推送应用」,但架构留好了,第二期加综合研判、第三期加辅助决策,都是在同一个底座上叠加,而不是从头再建一座烟囱。
三、政法跨部门数据共享:中台的难点也是价值点
司法数据中台真正区别于普通数据中台的地方,在于政法各部门之间的数据共享——这是数字法治政府能不能跑起来的核心,也是最敏感、最难协调的一环。落地时要把三件事说清楚:
- 共享什么、不共享什么:按数据分类分级,明确哪些是可共享的标准化指标数据,哪些是需脱敏后共享的业务数据,哪些是绝不出本部门的核心办案数据。中台在治理层就要把这个边界固化成规则,而不是靠人事后把关。
- 按需授权、最小可见:共享不等于全开。A 部门调 B 部门的数据,只能看到被授权的字段、被授权的范围,且每一次调用都留痕可审计。
- 脱敏与回溯并存:对外共享走脱敏视图,但在授权和安全审查的前提下保留按规则回溯的能力,兼顾保护与办案需要。
这部分往往不是技术难题,而是机制与责任的设计难题。一个有经验的供应商会带着一套成熟的数据分类分级 + 共享授权模板进场,帮政法委把规则先立起来,而不是把治理工作量全甩给信息中心。
四、合规底线:等保三级、信创、数据不出域
司法数据中台的合规要求比一般政务系统更严。这几条建议在立项和招标文件里就写死:
| 合规项 | 要求 |
|---|---|
| 网络安全等级保护 | 中台整体过等保三级;涉及核心办案数据的部分可能要求等保四级。安全建设(边界、主机、应用、数据、审计)按等保要求同步设计 |
| 信创适配 | 基础软硬件适配国产化:国产 CPU(鲲鹏/飞腾等)、国产操作系统、国产数据库与中间件,满足自主可控要求 |
| 数据不出域 | 全套部署在政法专网/政务内网,数据处理与模型推理均在内网完成,无外网调用;外部数据靠离线数据包导入 |
| 数据安全合规 | 符合《数据安全法》《个人信息保护法》的分类分级、最小权限、操作全程审计要求;敏感数据脱敏、可溯源 |
这里有一个常见误区:把合规当成验收前补的材料,而不是架构里长出来的能力。等保三级如果是事后改,几乎一定返工——权限、审计、加密、脱敏这些必须从数据治理层就设计进去。选型时,要让供应商证明它的方案是「合规内生」的,而不是临时贴一层安全产品糊弄过检。
五、数据底座:本地数据之外,还缺一套全国案例与法规
很多司法数据中台项目,把精力全放在「汇聚本地业务数据」上,却忽略了一件事:研判、类案推送、辅助办案这些高价值应用,光有本地数据是不够的,还需要一套全国范围的裁判文书与法规底座做参照。
没有这套底座,类案推送只能在本地为数不多的案子里找相似,样本太薄;量刑参考没有全国同类案件分布做锚,说服力不足;辅助检索查不到外地的裁判口径,做不了横向对比。这正是文书查在司法数据中台里能补上的一块:
- 结构化全国裁判文书:覆盖刑事、民事、行政、执行、国家赔偿,1.5 亿+ 篇,已做要素抽取与结构化,可直接进中台治理层对齐口径。
- 法律法规 + 司法解释 + 地方规章:与案例联动,检索、引用可溯源。
- 离线导入、增量更新:通过加密数据包离线导入政法专网,既补齐全国底座,又不破坏「数据不出域」的合规要求;后续靠增量包定期更新保持时效。
换句话说,本地数据回答「我这儿发生了什么」,全国案例与法规底座回答「全国同类案件是怎么判的、依据是什么」——两者在中台里对齐,上层应用才真正有判断力。
六、建设分期:不要一次性铺大摊子
司法数据中台最容易翻车的方式,就是立项时把所有部门、所有场景一次性全包进去,结果一期建一年还没出可用成果。更稳的路径是分期建设、用场景牵引:
| 阶段 | 目标 | 典型周期 |
|---|---|---|
| 一期 · 打底座 | 数据汇聚 + 治理 + 全国案例法规底座接入 + 一个高价值应用(如统一检索 / 类案推送)端到端跑通 | 约 2-4 个月 |
| 二期 · 扩场景 | 叠加综合研判、量刑参考、文书辅助等应用,复用一期的服务层;接入更多本地数据源 | 约 3-6 个月 |
| 三期 · 通跨部门 | 打通政法各部门数据共享,落地分级授权与审计;形成数字法治政府的协同能力 | 按机制成熟度推进 |
核心原则:每一期都要有能拿出来汇报、能让一线用上的成果。用一个真实场景(类案推送或统一检索)先把「数据汇聚 → 治理 → 服务 → 应用」这条链路打通,既验证了架构,又积累了信任,后面横向扩展才顺。
七、建设方采购清单(照着问供应商)
把这份清单放进技术交流和招标答疑,一轮就能问出谁真有能力交付:
- 方案是真中台(数据一次治理多处复用)还是又一个孤立平台?能展示服务层被多个应用复用的实例吗?
- 数据治理能力:清洗、去重、主数据、统一口径、分类分级怎么做?有没有成熟的司法数据治理模板?
- 合规是否内生?等保三级(必要时四级)、信创适配、数据不出域,是架构自带还是事后补?能否提供过检案例?
- 是否含全国裁判文书与法规底座?多少篇、覆盖哪几类、来源是否合法可溯源、怎么离线更新?
- 政法跨部门共享:有没有数据分类分级 + 分级授权 + 操作审计的成套机制方案?
- 是否支持分期建设?一期能否在 2-4 个月内交付一个端到端可用场景?
- 交付与服务期:含哪些(数据同步、模型/能力升级、运维、定制)?是否先做 POC/演示再签约?
八、常见问题
Q:我们已经建了不少业务系统,数据中台是不是要推倒重来?
A:不是。数据中台恰恰是为了不推倒重来——它把现有系统的数据汇聚、治理、复用起来,业务系统继续用,中台在它们上面建一层统一的数据资产与服务。已有投入不浪费,反而被盘活。
Q:中台建完,基层填报会不会更麻烦?
A:方向相反。中台的目标之一就是消除重复采集——同一项数据采一次,各应用复用,基层反而少填。前提是治理层把口径和主数据理清楚。
Q:全国裁判文书底座进了内网,合规吗?
A:合规。文书均源自人民法院公开渠道,合法可溯源;以结构化数据包离线导入政法专网,不需要中台连外网,完全符合数据不出域的要求,后续靠加密增量包离线更新。
为你的数字法治政府项目评估一套数据中台方案
提供建设范围(涉及哪些部门、优先场景、合规等级),我们反馈中台架构建议、全国案例法规底座接入方案与 POC 邀请。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情
相关阅读:地方法院信息中心 AI 系统采购清单 · 律所 AI 私有化部署完全指南 · 律师工作台:案件胜算量化 · 裁判文书 API / MCP 定价