面向律所、政府与法律科技团队的法律 AI 私有化部署、司法大数据应用、裁判文书 API/MCP 接入实战干货。
法律 AI 私有化上了生产,就成了律师庭前检索、文书生成、法官类案推送的日常依赖,一旦宕机就是业务停摆——可私有化在内网,没有公有云的自动故障转移,冗余都得自己建。更难的是法律 AI 的高可用要同时保三件相互独立、缺一不可的事都活着:推理靠昂贵稀缺的 GPU、检索靠向量库和全量文书、数据本身还不能丢。很多单位当普通 Web 系统做,多开几个副本就以为万事大吉,结果 GPU 一挂全线瘫痪,或检索库坏了 AI 还在一本正经地编(最危险的一种故障:不报错、还在答、只是没了依据)。本文讲清楚:RTO/RPO 对法律 AI 到底意味什么、为什么要按数据变化速度分层定;按推理层(GPU 重点在降级而非热备)/ 检索层(别让它静默失败)/ 数据层(不丢+可恢复+演练过)分层做冗余;灾备四个等级(备份可恢复→冷备→热备→双活)怎么按业务和预算选、不是越高越好;六个常见单点与坑;以及一份九项高可用与灾备自查清单。面向政法信息中心运维负责人与大所信息化总监。
法律 AI 私有化落地,选型、采购、验收都过了,系统也跑起来了,可对政法机关和大所来说还有最后一道、也常常最硬的一道关:数据安全审计与等保测评能不能过。麻烦在于法律 AI 有一批普通信息系统没有的安全风险——训练数据来源合规、检索层权限越界、提示注入、模型投毒、答案里带出隐私,这些在传统等保 checklist 上没有对应条目,却恰恰最容易出事、最容易被追问。本文讲清楚:先分清「数据安全审计」与「等保测评」是两件事;法律 AI 特有的六类风险(数据来源合规 / 权限隔离 / 隐私脱敏 / 提示注入 / 审计留痕 / 数据外带)怎么自查、要准备什么证据;等保三级测评的完整流程(定级备案→差距分析→整改→测评→复评)与六个高频扣分项;以及一份可直接照用的九项过审自查清单。重点提醒两个最易被忽略又最易被追问的点:提示注入必须做专门红队测试、脱敏必须覆盖 RAG 召回与最终输出而不只是入库。面向政法信息中心安全负责人与大所信息化 / 合规官。
很多律所和政法机关以为私有化法律 AI 最难的是上线那一天,可真正的考验从上线之后才开始:这是一套跑在你自己机房、离线、没有厂商云端替你 7×24 盯着的系统,接下来三年它活得好不好只能靠你自己的监控。更麻烦的是,法律 AI 有个别的系统没有的隐患——就算进程一直活着、接口一直返回 200,它的回答质量也可能在你毫不知情的情况下悄悄变差。本文给出一套可直接照搭的私有化法律 AI 运维监控体系:四层监控指标(基础设施 / 模型服务 / 检索质量 / 业务与安全),重点讲最容易被跳过的检索质量层(回归评测集 + 空检索/无引证泄漏指标,把「答得对不对」变成可告警的曲线)和业务与安全层(权限越界、审计日志、异常导出);离线环境特有的三个坑(数据回流断链、许可证证书到期、GPU 显存泄漏,共同点都是「静默恶化」);告警怎么分级降噪才不会变成没人看的「狼来了」;以及一份运维负责人可贴墙的八项巡检清单。面向律所信息化主任与政法信息中心运维负责人。
私有化法律 AI 的选型评标有一个反复出现的盲区:大家把注意力全给了产品,却几乎没人认真评估"供应商这家公司"本身。演示那天系统跑得漂亮就签了合同,可这是三五百万、服务期三年起步的长期关系,真正决定成败的往往不是产品此刻好不好用,而是这家公司能不能交付到位、会不会活到服务期结束、数据来源合不合法、断供了有没有退路。产品可以 demo,公司靠不靠谱只能靠尽职调查查出来。本文给出一份可直接照用的法律 AI 供应商尽调八维度清单:主体与资质、财务与持续经营、团队与交付能力、数据来源合法性、客户案例可核验、服务与续约、退出与锁定、知识产权与源码托管——每个维度都配上"具体问什么、要什么证据",并把数据来源合法性(政企不能让步的底线)、退出与锁定(签约时就要谈好的数据可导出 + 源代码托管)、财务持续经营(别让系统变成没人维护的孤儿)三项风险最大的维度展开,末尾附一页纸的采购委员会尽调清单。面向律所信息化主任、政法信息中心与采购委员会。
私有化法律 AI 的立项预算,几乎都栽在同一个地方:把供应商报的采购价当成了总成本。系统第一年跑得挺好,到第二年电费、运维人力、数据同步费、集成返工一笔笔冒出来,预算悄悄超了两三成。真正该拿去过合伙人会、过财务的,不是一次采购价,而是三年总拥有成本(TCO)——把硬件、软件、部署、运维、逐年服务费按三年周期加总的完整账本。本文把这本账一项项拆开:TCO 与采购价、与 ROI 的区别;五大成本科目(硬件与折旧 / 软件授权与数据 / 部署集成 / 运维人力 / 数据同步与模型迭代,前三项落在首年、后两项年年发生);一张可照着填的三年逐年现金流测算表,以及买断 vs 年费如何决定 TCO 的形状;六项最常被漏算的隐性成本(机房电力、集成人天、数据同步费、迭代后重新评测、内部运维机会成本、三年后硬件更新);自建 vs 采购 vs SaaS 三条路的三年账对比;以及一份给采购/预算负责人的八问立项清单。面向信息化主任、政法信息中心与采购/预算负责人。
律所和政法机关上法律 AI,选完供应商谈完预算,很快会撞上第一个绕不开的技术岔路口:到底该做检索增强(RAG)、还是微调一个专属法律大模型?供应商 A 说要微调懂本所的大模型,供应商 B 说 RAG 就够、微调是烧钱——选错方向轻则多花几十万、上线拖长半年,重则做出一个答得流畅却引用不可核验、法规一更新就悄悄失效的系统。本文用律所听得懂的话讲清:两条路解决的根本不是同一个问题(微调改「怎么说」、RAG 改「说什么、依据什么说」);法律场景的三条硬约束——来源可核、更新可跟、幻觉可控——为何天然偏向 RAG;成本、周期、维护三本账对比(为何微调是反复投入而非一次性);微调真正的用武之地在风格/术语/格式而非注入知识;以及以 RAG 为主、微调为辅、先补数据底座再调检索再改提示最后才动模型的务实分步路线。附信息化负责人技术路线选型自查清单与 FAQ。面向律所信息化负责人、政法机关信息中心、法律科技团队。
很多单位把法律 AI 项目的终点画在了验收签字那一刻:系统跑通、指标达标、剪彩、项目组解散。可半年后再看常常尴尬——它悄悄变笨了:新司法解释它不知道还按旧规则答、去年没人问的新案由今年答不好、律师用得深了问法变刁它跟不上。系统一行代码没改,信任却在一点点流失。根子在于法律 AI 是会随时间贬值的活系统,不是买回来就一劳永逸的固定资产:上线表现只是当时语料、法规、用户问法下的一个快照,而这三样都在变,系统不动、世界在动,相对而言它就是在退化。本文写给要对法律 AI 长期负责的人:讲清上线不是终点、静态系统为何贬值;持续运营的四条生命线(语料与法规更新 / badcase 收集治理 / 效果监控 / 模型与检索迭代);让系统越用越准的数据回流闭环,以及"回流不等于拿客户数据训练"的合规红线;从归集→归因(检索没召回/幻觉/语料缺/权限错)→对症修→进评测集回归的 badcase 治理流程;把引用错误率、回链可核率、检索命中做成持续盯的效果仪表盘、别靠用户投诉;以及小步快跑、动不动就换模型是大忌的迭代节奏。附信息化负责人持续运营自查清单。面向律所信息化负责人、政法机关信息中心、知识管理总监。
一个反复出现又没人愿意面对的场景:律所几十万上百万买回来的法律 AI,上线热闹两周,三个月后一看后台日活律师不到两成。系统没坏、模型也不差,钱花了价值却没出来——问题几乎从来不在技术,而在落地之后没人管 adoption。系统能跑,不等于律师会用、愿意用、持续用。本文写给已经或即将把 AI 落地、并真想让它产生回报的人:讲清 ROI 不在采购那一刻兑现、而在律师用起来那一刻(使用率 20% 的强系统远不如 80% 的够用系统);律师不用的四个真因(不信任/不顺手/不会用/没动力),及为什么没一个能靠"换个更强模型"解决;把使用率做起来的落地运营五步法(选一条高频业务线试点→场景化培训→把 AI 嵌进流程→建反馈闭环→盯指标树标杆给激励);按角色分层的落地打法(资深合伙人/青年律师/实习助理/信息化各有各的打法);以及怎么用活跃度、渗透深度、价值感知三层指标衡量真正的 adoption、别被"开了多少账号"这种虚荣指标骗。附信息化负责人落地自查清单。面向律所信息化负责人、知识管理总监、合伙人。
很多单位上法律 AI,是从"选哪个大模型、买多少张卡"开始的,却把最该先做的一步跳了过去——数据分类分级。结果往往是等保测评时被问"你的分级台账呢"答不上来,涉密文件和当事人身份信息不加区分地灌进向量库、被模型召回给不该看的人,想上公有云省成本又拿不准这批数据到底能不能出内网。数据分类分级不是一张交差用的表格,而是决定哪些数据能上云、哪些必须离线、怎么脱敏、检索时给谁看的合规起点。本文写给要在律所或政法机关真正把 AI 落地、并且要过合规这一关的人:讲清分类(按来源/主体/业务)和分级(核心/重要/一般三级 + 单独识别敏感个人信息)是先后衔接的两件事;法律数据的三个分类维度怎么交叉打标;三级怎么定、最容易漏的是"单看不起眼、聚合有分量"的重要数据;分级结果如何直接决定 AI 系统能不能上云、要不要脱敏、检索权限怎么隔离、能不能用于训练;以及分类分级落地五步法。附信息中心与合规官落地自查清单。面向政法机关信息中心、律所合规官、信息化负责人。
不少律所花大价钱买了法律大模型,用了一阵却泄了气:它不懂本所办过的案子,答得像个只读过公开教科书的实习生。问题几乎从来不在模型本身,而在知识没进去——真正的杠杆不是"换个更强的模型",而是把本所卷宗、合同和外部类案变成一个能被检索、能回链核对、能按权限隔离的知识库(RAG)。本文写给要真正落地律所知识库的人:讲清模型是大脑、知识库才是它读过的案卷这一根本区别;三库一体(卷宗/合同/类案)各管一摊、为什么不能一锅烩;RAG 的五层架构(接入解析 / 切分脱敏 / 向量索引 / 检索重排 / 生成回链)及律所场景最容易低估的两层;最难的权限、保密与利益冲突墙(为什么权限必须落在检索层、为什么几乎必然私有化离线);检索质量怎么保证;以及"别一上来就全灌进去"的分阶段落地路线图。附知识管理总监落地自查清单。面向大律所知识管理总监、信息化负责人、合伙人。
采购法律 AI,最容易踩空的不是招标、不是谈判,而是验收。前面的采购清单、技术参数都做对了,到了验收却又退回"看厂商演示、对着参数表勾满足"的老路——于是一套会编案例、数据来路不明、断网就趴窝的系统,就这样被签字收下了。本文写给要组织验收、要在验收报告上签字的人:把法律大模型的验收从"信不信厂商"这个话术问题,变成用本单位真题现场测、逐项算指标、可对账的工程问题。怎么建盲测集(常见/生僻/陷阱三类真题)、要测哪四类量化指标(引用错误率/回链可核率/结果一致性/离线可用性)、怎么组织红队诱导测试专门去"钓"它编、怎么设一票否决 + 加权评分表、POC 与试用怎么做提前预演。附信息中心主任验收自查清单。面向法院/检察院信息中心、司法局、大律所信息化。
一套法律 AI 项目的成败,一半在评标会上就已经决定了——决定它的不是哪家厂商讲得好,而是招标文件里的技术参数怎么写。参数写虚了招来一堆套壳 demo,写死了又被质疑指向性废标。本文写给真正起草采购需求书、技术规格书的人:把法律 AI 招标的技术参数拆成六大模块(数据底座、模型与推理、检索与引证核验、私有化与等保信创合规、集成与权限、服务 SLA),逐块给可直接套用的指标清单并标出哪些该设为实质性条款/一票否决;再讲清参数怎么写既硬又不锁定单一厂商(写能力不写品牌、每条过"三家测试"、下限式写法)、怎么用"我方真题现场实测"的验收条款堵死参数虚标(引用错误率、回链可核、离线断网实测)。附采购委员会招标参数自查清单。面向法院/检察院信息中心、政府采购、大律所采购委员会。
律所和法院的法律 AI 项目,大多卡在同一道坎:试用答得头头是道,真办案却发现它引用的案号查无此案、把判决结果说反、把法条记错。在法律场景里,一条假引用就足以让意见书报废、让律师担责。本文写给在评估、采购、验收法律 AI 的人:讲清法律大模型为什么会"一本正经地编案例"(概率生成的固有机制)、幻觉的四种典型形态(凭空编造/张冠李戴/结果说反/法条数字错)、治理它真正的根——不是换更大的模型,而是在真实可核验的裁判文书语料上做 RAG grounding + 引证核验(案号校验、原文回链、结果一致性比对、查不到就如实说没有)、以及验收时怎么用你自己的真题盲测把"引用错误率"实测出来,附一份给信息中心主任的引证核验清单。
越来越多的法律 AI 招标里写着"须适配信创环境"——这对政府、法院、检察院和很多国企不是加分项,而是入围资格本身。本文把信创栈一层层拆开,讲清国产 CPU(鲲鹏/飞腾/海光)、国产操作系统(麒麟/统信 UOS)、国产数据库(达梦/人大金仓/openGauss)、国产算力卡(昇腾)各自对一套"法律大模型 + 1.7 亿裁判文书库"私有化部署意味着什么;最难的一层(大模型推理迁到国产算力卡的模型转换与压测)难在哪;信创和等保三级两套合规怎么一起过;裁判文书库落国产数据库的检索调优坑在哪;最后给一份能直接对照招标文件的信创适配选型清单。面向政府/法院/国企/大律所信息中心主任。
要在裁判文书数据上盖产品,最先打通的不是模型,而是把一份干净、可过滤、可回链的判决稳定地拉进你的服务。这篇写给后端工程师:鉴权怎么放(Key 进环境变量、前端不持 Key)、检索怎么调、分页和按案由/法院/年份过滤怎么写、原文怎么回链、429/5xx 怎么退避重试,Python(requests)与 Node.js(fetch)两套可直接改的骨架,外加"接 REST API 还是 MCP"的选型表和一份上生产前检查清单。接口路径与字段全用占位、以接口文档为准——讲的是接入模式不是固定端点。
卡住一个实证课题的,往往不是回归模型选 OLS 还是 logit,而是更前面那步:你手里那批裁判文书数据,到底干不干净、全不全、能不能复现?本文面向法学院教授与博士生,只讲数据这一关:实证研究要的不是几个判例而是可统计的结构化大样本、手工从裁判文书网下载会埋下的三个雷(在网文书≠全部判决的样本偏差、大规模字段抽取的结构化成本、集合不可固定的可复现性问题)、人读型商业库为什么不适合做实证、研究级数据集的四个硬指标(覆盖可表征/字段可溯源/可固定快照+稳定ID/合规可署名),以及一条典型的实证数据管线和选数据源必问的 6 条。核心提醒:把数据可信度当成研究设计的一部分,而不是开题后补的脚注。面向高校法学院实证研究者。
每个法律 AI 创业团队在写第一行产品代码前都要先答一题:数据从哪来?答错了,后面再好的模型和界面都救不回来。本文站在创业 CTO 角度拆这道 build-vs-buy:先分清「按席位卖给律师人读的库」和「按授权卖给开发者机器吃的语料」为什么不是一回事、北大法宝威科这类库为什么不能直接当产品底座;再把自建爬库藏起来的四笔账(覆盖不可表征、合规风险、结构化成本、永续维护)逐一摊开;给出自建 vs 授权逐项对比、一张按团队阶段(验证 MVP / 产品打磨 / 规模化 / 涉密政企)选型的决策表,以及选供应商必问的 6 条。核心结论:把「要不要自建数据团队」这种重决策,推迟到你确认数据真是你的差异化之后再做。面向法律 AI 创业团队 CTO 与技术合伙人。
「这官司我能赢吗、能拿多少?」——多数时候律师靠的是脑子里十几年的经验:准,但说不清依据、传不给年轻人、也经不起当事人追问。律师工作台要解决的正是这件事:把研判固定成一条结构化、可回溯的流水线(案件要素录入→类案检索→裁判要素抽取→量化研判→可解释留痕),给出有样本数与置信度的胜诉率区间、赔偿区间,每个结论都回链到能点开核对的真实判决。本文讲清它到底是什么、为什么必须给区间不给点值、底层靠什么数据与类案算法撑、为什么敏感案件要本地化部署,以及中小律所怎么从一个高频条线小步落地,附选型必问清单。面向中小律所主任与办案律师。
做类案检索的团队都在同一个路口纠结过:用关键词(BM25)还是语义向量(embedding)?纯关键词漏掉换了说法的类案,纯向量又把"看着像、判得反"的伪类案排到前排。这道题的正确答案不是二选一。本文从法律文本三条特性(关键差异藏在数字与法条号里、术语高度专属、案由是结构)讲起,拆清两种召回各自的命中与翻车场景,再给出生产级类案检索 API 的完整链路:结构化预过滤 + 双路召回 + 重排 + 引用回链,以及评测指标(Recall@K/nDCG/伪类案率)、自建 vs 接 API 的取舍和选型必问。面向法律 AI 工程师与法律科技团队。
通用大模型最致命的法律短板,是它会一本正经地编判例——案号像模像样、法条对不上,根本不敢拿去办案。解法不是换更大的模型,而是接一个能查真实判决的数据源。手把手演示:用 MCP(Model Context Protocol)把 1.7 亿+ 裁判文书接进 Claude Desktop,改一个 claude_desktop_config.json、填试用 key、重启验证、第一次类案检索拿到带原文链接的真实判例,全程不到 5 分钟;再讲清 MCP 与 REST API 怎么选、接进自己产品的 Python 示例、三个立竿见影的用法,以及数据不出域时如何转私有化离线部署。面向法律 AI 开发者与法律科技团队。
招标文件里一句"须满足等保三级",到测评那天才发现权限是事后加的、审计日志缺、存储没加密——于是整改返工。等保三级从来不是验收前补的材料,而是从架构第一层就要长出来的能力。本文不重复中台怎么建,专门下钻安全合规架构:等保三级五大技术要求(物理/通信/边界/计算环境/管理中心)怎么落到中台每一层、定级备案三同步流程、数据分类分级到字段级、最小权限与脱敏统一做在服务层、全程不可篡改审计、信创适配与数据不出域怎么兼顾全国底座离线导入,以及测评 7 大常见失分项和照着问供应商的采购清单。面向政法委、司法局信息中心与法院技术处。
智慧检务真正落到办案现场,价值集中在"找类案、提建议、写文书"三件事。讲清检察院 AI 系统的三大核心能力(类案推送/量刑建议辅助/文书辅助生成)、认罪认罚从宽下量刑建议为什么要给区间不给点值、起诉书与审查报告如何用检索增强防住大模型编法条的幻觉、为什么必须在检察专线本地化部署、以及检察机关技术部门可直接照问供应商的 8 条采购清单。面向检察机关技术部门与智慧检务建设决策者。
选型会上最先吵起来的不是模型,而是数据底座用谁的。问题是这几个名字常被放一起比,却根本不在同一个货架上:综合数据库(北大法宝)、检索/社区(无讼)、办案 SaaS(Alpha)解决的是「人去查」,文书查解决的是「让你自己的系统和模型去用」。本文用五个维度(买到什么/能否批量调用/能否本地私有化/能否当 AI 底座/有无结构化字段)把四者放在同一张表上逐项对比,给出按场景的选型建议与 6 条供应商必问清单。面向律所信息化负责人与法律科技选型者。
「拿我们所的卷宗训一个懂本所打法的模型」——期待很实在,但多数人把微调、RAG、继续预训练混成一团,用错了既烧钱又没效果。讲清三者各解决什么(律所 80% 痛点是 RAG 问题不是微调)、为什么微调离不开私有库底座、本所卷宗怎么加工成指令样本(脱敏/抽取/把关/配比占 70% 工作量)、为什么 LoRA 起步而非全参数、以及微调效果怎么用评测集实测而非凭感觉。面向律所知识管理总监与法律科技团队。
智能审判辅助不是替法官判案,而是把"找类案、定量刑、写文书"做进办案系统。讲清三大核心能力(类案推送/量刑参考/文书辅助生成)、量刑参考为什么要给区间不给点值、文书辅助生成如何用检索增强防住大模型编法条的幻觉、为什么必须本地化部署与可解释留痕,以及法院技术处可直接照问供应商的 8 条采购清单。面向法院技术处与智慧法院建设决策者。
把 1.5 亿+ 篇判决搬进自己机房,不是「拷一份数据」那么简单。按可落地的六层架构讲清裁判文书私有库的本地化部署:存储与结构化、全文+向量混合检索、离线增量更新、权限与审计、与法律大模型的 RAG 对接,并给 1.5 亿条规模的资源测算(存储/内存/GPU)与 8 条部署自评清单。面向律所 IT、法院信息处与法律科技团队。
各家方案说辞雷同,水分签约前看不出来、上线后才疼。逐个拆开律所采购法律 AI 最容易踩的 5 个坑:把 SaaS 当私有化买、数据只看条数不看口径、模型分不清自研微调与套壳、只买数据没有工具链、只看签约价不看服务期,并给一份能在一轮会上问出谁有真货的六组采购对照清单。面向律所采购委员会与信息化主任。
类案同判落地,靠的是一套能在办案系统里自动把相似已决案件推到法官面前的系统。讲清类案"检索"与"推送"的区别、四层技术架构(数据底座/语义召回/相似度排序/法官界面)、为什么必须用语义向量而非关键词、强制类案检索如何自动留痕合规、为什么必须本地化部署,以及法院信息处可直接照问供应商的 9 条采购清单。面向法院信息处与智慧法院建设决策者。
当事人材料喂给 AI,会不会违反保密义务?从合规视角讲清律所保密义务的三层来源(执业规范/委托合同/数安法个保法)、SaaS 触碰的合规红线、私有化部署如何逐条接住保密与数据出域要求、权限分级与利益冲突隔离、可审计留痕,以及合规官向管委会汇报的五条论证清单。面向律所合规官与信息化负责人。
合伙人拍板上内网,IT 负责人怎么落地?讲清按并发反推 GPU 的测算口径、7B/32B/72B 三档显存与配置清单、四区内网部署架构、过等保三级的采购需求逐条、按"组织架构+案件归属"做权限分级与利益冲突隔离,以及一份照着问供应商的落地清单。面向律所 IT 负责人与信息化主任。
政法各部门数据孤岛、口径不一、重复采集怎么破?讲清司法数据中台的四层架构、政法跨部门数据共享机制、等保三级与信创合规、全国裁判文书与法规底座接入、分期建设路径与 7 条采购清单。面向政法委、司法局信息中心与法院技术处的建设决策参考。
一套私有化法律 AI 多久回本?把这笔账拆开算:完整 TCO 成本结构、四类收益来源(工时节省/人力杠杆/案件预判/合规大单)、一个百人律所的实测算例、回本周期速查表与测算避坑清单。面向律所合伙人与管委会的预算决策参考。
类案推送、文书辅助、审判管理三大场景怎么落地?讲清智慧法院 AI 的技术四层、等保与信创合规、可直接照问供应商的 12 条采购清单、预算分档与建设周期。面向法院信息中心主任与政法委决策者。
大型律所为什么不能用 SaaS 法律 AI?讲清数据底座、法律大模型、工具链、硬件配置、等保合规、采购清单与部署周期。面向律所信息化主任与合伙人的决策参考。