法律行业采用 AI，难点从来不只是“模型能不能回答问题”。真正进入律所和企业法务后，系统还必须适配既有办案流程、连接内部法律数据，并对客户机密提供足够严格的控制。Astra for Law 所强调的，正是把前沿智能、定制工作流、法律数据源和面向法律业务的控制机制放在同一套工作环境中。
重点不是聊天框，而是可约束的法律工作流
通用对话工具可以起草文本、归纳材料，但法律工作通常是一条包含多个检查点的链路。例如合同审查可能包括：
- 确认客户、事项编号和司法辖区；
- 从获准的数据源提取合同、模板和条款库；
- 识别偏离标准模板的条款；
- 标注引用依据与不确定内容；
- 由负责律师复核后再生成对外版本；
- 保存审批记录和最终输出。
“定制律所工作流”的价值，就在于把这些步骤固化下来，而不是让每名员工临时编写提示词。模型可以承担检索、比较、摘要和初稿生成，但事项权限、数据范围、审批节点与交付规则仍应由组织定义。
这种设计也更容易控制风险。高风险任务不应只返回一段看似完整的答案，而应同时提供来源、缺失信息和待人工确认项。涉及诉讼期限、监管结论、最终法律意见或对外提交文件时，人工复核不能被模型输出替代。
连接法律数据时，权限应跟着事项走
法律 AI 的质量很大程度上取决于它能访问什么数据。公开法律资料、律所知识库、文档管理系统和客户事项文件的权限边界并不相同。连接数据源不应等同于把全部文档建立进一个所有人可搜索的索引。
更稳妥的架构是让每次请求都携带明确的访问上下文：
- 用户身份与所属团队；
- 客户和事项编号；
- 获准访问的数据源；
- 文档保密级别；
- 使用目的和保存策略；
- 是否允许把内容带入后续步骤。
检索层应先执行权限过滤，再把最小必要内容交给模型。输出端还要保留引用关系，使复核者能够回到原始文档，而不是依赖模型对条款或判例的转述。
这里需要特别区分“连接”与“复制”。如果原始系统已经提供精细的事项级权限，集成层最好延续这些规则；若为了 AI 检索另建数据副本，则必须重新处理访问控制、删除同步、保留期限和审计等问题。
一个可改造的机密事项入口
下面是一个可直接运行的 Python 示例，用来演示法律 AI 工作流入口应该如何执行事项校验、数据源白名单、敏感信息遮盖和审计记录。它不是 Astra for Law 的真实 API，也没有调用任何模型；接入实际平台时，可以把 run_model 替换为经过批准的 SDK 或内部网关。
将代码保存为 legal_workflow.py，然后运行 python legal_workflow.py：
from __future__ import annotations
import hashlib
import json
import re
from datetime import datetime, timezone
from pathlib import Path
ALLOWED_MATTERS = {
"M-2025-0042": {
"users": {"lawyer@example.com"},
"sources": {"matter_documents", "approved_precedents"},
}
}
AUDIT_FILE = Path("legal-ai-audit.jsonl")
def redact_for_log(text: str) -> str:
"""仅用于审计日志；不要把原始客户内容写入普通日志。"""
text = re.sub(r"[\w.+-]+@[\w.-]+", "[EMAIL]", text)
text = re.sub(r"\b\d{3}-\d{2}-\d{4}\b", "[ID]", text)
return text[:200]
def authorize(user: str, matter_id: str, source: str) -> None:
matter = ALLOWED_MATTERS.get(matter_id)
if not matter:
raise PermissionError("未知或未获准的事项")
if user not in matter["users"]:
raise PermissionError("用户无权访问该事项")
if source not in matter["sources"]:
raise PermissionError("该事项不允许使用此数据源")
def run_model(instruction: str, context: str) -> dict:
# 示例占位：替换为组织批准的模型网关或 SDK。
# 实际实现还应设置数据保留策略、超时和输出过滤。
return {
"draft": f"待复核分析：根据获准材料处理任务——{instruction}",
"citations": ["approved-source://document/123#section-7"],
"review_required": True,
"context_chars": len(context),
}
def execute(request: dict) -> dict:
authorize(request["user"], request["matter_id"], request["source"])
result = run_model(request["instruction"], request["context"])
event = {
"timestamp": datetime.now(timezone.utc).isoformat(),
"user": request["user"],
"matter_id": request["matter_id"],
"source": request["source"],
"instruction_preview": redact_for_log(request["instruction"]),
"context_sha256": hashlib.sha256(
request["context"].encode("utf-8")
).hexdigest(),
"review_required": result["review_required"],
}
with AUDIT_FILE.open("a", encoding="utf-8") as file:
file.write(json.dumps(event, ensure_ascii=False) + "\n")
return result
if __name__ == "__main__":
request = {
"user": "lawyer@example.com",
"matter_id": "M-2025-0042",
"source": "matter_documents",
"instruction": "比较赔偿责任条款与获批模板，并列出差异。",
"context": "第 7 条：供应商对所有间接损失承担无限责任。",
}
print(json.dumps(execute(request), ensure_ascii=False, indent=2))
这个最小示例刻意体现了几项工程原则：未经事项授权的请求在调用模型前就被拒绝；日志只保存脱敏预览和正文哈希；输出明确要求复核；引用使用可追踪的占位地址。生产环境还需要接入企业身份系统、密钥管理、不可篡改审计存储、细粒度文档授权和删除流程。
不要把示例中的内存白名单当作真正的权限系统，也不要在未经安全与合规评估的情况下把客户文件发送到外部服务。
“法律级控制”最终要落实为可验证的规则
“法律级”不能只停留在产品描述中。采购或上线时，可以把它拆成一组可测试的问题：
- 谁可以访问某个客户和事项的数据？权限撤销多久生效？
- 提示词、检索片段、模型输出和反馈分别保存多久？
- 管理员能否限制可连接的数据源与可执行的工作流？
- 输出能否携带引用、版本和审批状态？
- 是否能区分内部草稿、律师审核版本与客户交付版本？
- 审计人员能否追踪谁在何时使用了哪些数据，而不在日志中暴露全文？
- 数据删除、法律保留和跨地域处理要求如何执行？
- 模型无法确认结论时，工作流是否会升级给人工处理？
这些问题的答案应结合律所政策、客户约定和适用法规验证，而不能仅凭“企业级”或“安全”标签推断。
采用建议：先选边界清晰的任务
Astra for Law 所代表的方向，是让 AI 从孤立的文本生成工具转变为法律业务系统的一部分。落地时不必一开始就覆盖所有业务。更合适的试点通常具有明确输入、固定输出格式和强制人工复核，例如条款差异比较、长文档时间线整理、尽调问题分类或内部知识检索。
上线前可以使用一份简短清单：
- 明确试点事项、数据范围和责任律师；
- 建立一组包含正常、缺失和冲突材料的测试案例；
- 要求输出引用来源，并抽样核对；
- 测试越权访问、提示注入和错误事项编号；
- 规定哪些输出不得直接发送给客户或提交机构；
- 记录质量、耗时、返工率和权限事件；
- 在扩大使用范围前完成安全、隐私和专业责任审查。
前沿模型可以提升法律研究和文档处理效率，但可靠部署依赖的仍是工作流、数据治理与人的判断。把这三部分与模型能力一起设计，才有机会让 AI 真正进入机密客户工作的日常流程。