AI Agent律师行业智能体的实践步骤
AI Agent进入法律行业，真正有价值的方向并不是做一个“会回答法律问题的聊天机器人”，而是把法律人的实际工作流程拆解成可执行、可验证、可追溯的任务链，再让智能体承担其中重复性高、信息密集、规则相对明确的环节。
法律行业与普通企业知识库问答有一个根本区别：法律智能体输出的错误可能直接影响诉讼策略、合同义务、交易风险乃至当事人的重大利益。
因此，律师行业的Agent建设不能简单理解为“LLM + RAG + Tools”。真正可落地的系统应该同时解决四个问题：
法律知识是否准确、推理过程是否可控、结果是否能够验证、整个过程是否满足律师执业与数据合规要求。
美国律师协会（ABA）2024年发布的 Formal Opinion 512 已明确指出，律师使用生成式AI时，需要考虑胜任义务、客户信息保密、与客户沟通、监督人员和代理人、向法院保持诚实以及合理收费等职业伦理义务。([美国律师协会][1])
这意味着，律师Agent从第一天开始就不能按照普通客服机器人设计，而应该按照一个**“受控的法律工作流执行系统”**来建设。
一、先明确：律师Agent到底解决什么问题
法律服务的一个典型流程是：
客户咨询
↓
事实收集
↓
法律问题识别
↓
法律检索
↓
法规/案例分析
↓
风险判断
↓
文书起草
↓
律师审核
↓
交付客户
传统AI产品通常只覆盖其中一个环节，例如：
用户问题
↓
LLM
↓
答案
这种架构对于法律场景存在明显缺陷。
例如用户询问：
“公司准备解除一名工作8年的员工，需要支付多少经济补偿？”
如果直接交给大模型，模型可能回答得非常流畅，但实际上至少还需要知道：
适用哪个法域；
劳动合同签订时间；
是否存在连续工龄；
月工资标准；
是否属于特殊情形；
解除原因；
是否存在违法解除；
是否已经履行通知程序；
是否存在竞业限制；
当前法律法规是否已经变化。
因此，律师Agent首先要解决的不是“回答得像不像律师”，而是：
能否发现自己缺少哪些事实。
这也是法律Agent与普通问答Agent最重要的区别之一。
二、第一步：选择一个边界明确的法律场景
不要一开始就做：
“AI律师，可以回答所有法律问题。”
这是最容易失败的产品定义。
法律领域知识高度专业化，而且不同法域、不同程序、不同案件类型之间差异巨大。
更合理的方法是先选择一个垂直场景。
例如：
场景 | Agent适合程度 | 主要任务 |
|---|---|---|
合同审查 | ★★★★★ | 条款识别、风险定位、修改建议 |
法律检索 | ★★★★★ | 法条、案例、司法解释检索 |
尽调 | ★★★★★ | 批量文件分析、风险归类 |
劳动争议 | ★★★★☆ | 事实整理、法规检索、风险分析 |
知识产权 | ★★★★☆ | 权利状态、案例、侵权风险分析 |
诉讼文书 | ★★★★☆ | 起诉状、答辩状、法律意见书辅助生成 |
复杂刑事案件 | ★★☆☆☆ | 风险高、事实复杂，需要强人工控制 |
如果是企业内部建设，推荐从：
合同审查Agent → 法律研究Agent → 尽调Agent → 综合法律Agent
逐步演进。
三、第二步：把律师工作拆成Agent任务
一个成熟的法律Agent不是一个“大模型”，而是一组任务能力。
例如合同审查Agent可以拆成：
Contract Review Agent
│
├── Document Parser
│ ├── PDF
│ ├── DOCX
│ └── OCR
│
├── Contract Understanding
│ ├── Parties
│ ├── Obligations
│ ├── Rights
│ └── Termination
│
├── Legal Retrieval
│ ├── Laws
│ ├── Regulations
│ ├── Cases
│ └── Internal Rules
│
├── Risk Analysis
│ ├── Missing Clause
│ ├── Unreasonable Clause
│ ├── Compliance Risk
│ └── Litigation Risk
│
├── Drafting
│ ├── Modification
│ ├── Legal Opinion
│ └── Review Report
│
└── Human Review
这时候Agent才真正具有“工作能力”。
例如用户上传一份采购合同，系统不是简单让LLM总结合同，而是执行：
上传合同
↓
文档解析
↓
章节切分
↓
条款识别
↓
实体抽取
↓
风险规则匹配
↓
法律检索
↓
案例/法规验证
↓
LLM综合分析
↓
风险等级
↓
修改建议
↓
律师审核
这才是法律行业真正有价值的Agent。
四、第三步：建立法律知识库，而不是简单堆PDF
法律Agent最核心的基础设施之一是知识库。
但“把法律法规全部丢进向量数据库”并不能得到可靠的法律RAG。
法律知识具有明显的结构化特征。
例如：
法律
├── 章节
│ ├── 条
│ │ ├── 款
│ │ └── 项
案例则可能具有：
案件
├── 法院
├── 案号
├── 裁判日期
├── 案由
├── 当事人
├── 事实
├── 争议焦点
├── 法院观点
├── 裁判结果
└── 引用法律
因此法律知识库应该采用：
结构化元数据 + 全文索引 + 向量检索 + 关系检索
的混合模式。
例如：
{
"document_type": "law",
"title": "劳动合同法",
"article": "第四十七条",
"jurisdiction": "CN",
"effective_date": "2008-01-01",
"status": "effective",
"source": "official",
"content": "……"
}
这样检索时才能实现：
关键词检索
+
语义向量检索
+
法域过滤
+
生效状态过滤
+
时间过滤
+
法律层级过滤
而不是单纯：
query → embedding → topK
五、第四步：法律RAG必须解决“有效性”
普通RAG最容易忽视的问题，在法律领域却是核心问题：
这条法律现在还有效吗？
例如用户问：
“2026年某种情况下企业是否可以这样解除合同？”
系统不能只找到一条历史上相关的法律条文。
必须判断：
法规
↓
发布日期
↓
施行日期
↓
修订记录
↓
废止状态
↓
当前有效版本
因此法律知识库应该保存版本信息。
推荐数据模型：
CREATE TABLE legal_documents (
id BIGINT PRIMARY KEY,
title VARCHAR(255) NOT NULL,
document_type VARCHAR(50),
jurisdiction VARCHAR(100),
issuing_authority VARCHAR(255),
effective_date DATE,
expiry_date DATE,
status VARCHAR(30),
version VARCHAR(50),
source_url TEXT,
content TEXT,
created_at TIMESTAMP,
updated_at TIMESTAMP
);
检索时：
SELECT *
FROM legal_documents
WHERE jurisdiction = ?
AND status = 'effective'
AND effective_date <= CURRENT_DATE
AND (expiry_date IS NULL OR expiry_date >= CURRENT_DATE);
这一步看起来普通，但对于法律Agent来说非常重要。
法律知识库首先应该是一个版本化知识系统，其次才是向量数据库。
六、第五步：采用“检索 + 规则 + LLM”的混合推理
法律问题不能完全依赖LLM自由生成。
更可靠的架构应该是：
┌──────────────┐
│ 用户问题 │
└──────┬───────┘
↓
┌─────────────────┐
│ Intent Analyzer │
└────────┬────────┘
↓
┌────────────────────┐
│ Legal Query Planner│
└─────────┬──────────┘
↓
┌───────────────┼───────────────┐
↓ ↓ ↓
法律法规检索 案例检索 内部知识检索
↓ ↓ ↓
└───────────────┼───────────────┘
↓
Evidence Builder
↓
Rule Engine
↓
LLM Reasoning
↓
Citation Validator
↓
Human Review
其中LLM主要负责：
理解问题；
整理事实；
解释法律规则；
比较不同法律规定；
综合证据；
生成自然语言结论。
而以下内容最好交给确定性程序：
日期计算；
金额计算；
法律状态判断；
文档权限；
用户权限；
引用编号；
风险阈值；
工作流审批。
例如赔偿金额计算不应该让模型直接算：
LLM：
“根据情况，大约需要支付10万元。”
而应该：
LLM
↓
提取：
工作年限 = 8年
月工资 = 15000
↓
Rule Engine
↓
8 × 15000
↓
120000
↓
LLM解释计算依据
这就是法律Agent非常重要的设计原则：
让模型负责理解，让规则负责确定性。
七、第六步：给Agent设计法律工具，而不是只提供一个搜索接口
Agent真正“智能”的地方来自工具调用。
可以设计：
class LegalTools:
def search_law(
self,
query: str,
jurisdiction: str,
effective_at: str
):
...
def search_cases(
self,
issue: str,
court_level: str | None = None
):
...
def get_article(
self,
law_id: str,
article_no: str
):
...
def calculate_compensation(
self,
salary: float,
years: float
):
...
def check_contract_clause(
self,
clause: str,
clause_type: str
):
...
def create_review_report(
self,
findings: list
):
...
然后Agent根据任务自主选择工具：
用户：
“帮我审查这份劳动合同”
Agent
↓
解析合同
↓
发现竞业限制条款
↓
search_law()
↓
search_cases()
↓
get_article()
↓
check_contract_clause()
↓
生成风险报告
这比简单的Prompt：
“你是一名专业律师，请分析以下合同……”
可靠得多。
八、第七步：引入Planner，让复杂任务分步骤执行
复杂法律任务通常不能一次完成。
例如：
“帮我判断这个劳动争议案件企业败诉风险。”
Agent应该先规划任务：
{
"goal": "评估劳动争议败诉风险",
"steps": [
"extract_case_facts",
"identify_legal_issues",
"retrieve_applicable_laws",
"retrieve_similar_cases",
"compare_facts",
"identify_adverse_factors",
"calculate_possible_liability",
"generate_risk_report"
]
}
执行过程：
Case Analysis
│
┌─────────▼─────────┐
│ Extract Facts │
└─────────┬─────────┘
↓
┌────────────────────┐
│ Issue Identification│
└─────────┬──────────┘
↓
┌──────────────┼──────────────┐
↓ ↓ ↓
Statutes Cases Evidence
↓ ↓ ↓
└──────────────┼──────────────┘
↓
Risk Assessment
↓
Lawyer Review
这样做还有一个好处：
任何一步失败都可以单独重试，而不需要整个任务重新执行。
九、第八步：法律Agent必须具备“证据链”
法律Agent最危险的输出之一，就是：
“根据相关法律规定……”
但是没有告诉律师：
到底是哪条法律？
因此法律Agent的回答应该尽可能形成：
结论
↓
法律依据
↓
具体条款
↓
事实依据
↓
案例依据
↓
推理过程
例如：
{
"conclusion": "存在较高的违法解除风险",
"legal_basis": [
{
"source": "劳动合同法",
"article": "第四十七条",
"citation": "……"
}
],
"facts": [
"员工工作年限8年",
"企业未提供充分证据证明严重违纪"
],
"risk": "HIGH",
"confidence": 0.87
}
这比单纯输出一段自然语言更加适合律师工作。
十、第九步：建立Citation Validator
法律Agent最值得单独开发的模块之一，就是引用验证器。
模型生成：
根据《XX法》第三十八条……
系统应该自动检查：
法律名称是否存在？
↓
第三十八条是否存在？
↓
当前是否有效？
↓
条文内容是否真的支持该结论？
↓
引用是否与当前法域一致？
可以进一步设计一个简单的引用评分：
CitationScore =
SourceValid
× ArticleValid
× EffectiveValid
× SemanticSupport
其中：
SourceValid = 法律来源是否可信
ArticleValid = 条款是否真实存在
EffectiveValid = 当前是否有效
SemanticSupport = 条款是否真正支持结论
最终只有达到阈值的引用才能进入最终回答。
这实际上比单纯提升模型参数规模更重要。
十一、第十步：建立律师Human-in-the-Loop
法律Agent不应该设计成：
AI → 自动给客户最终法律意见
更加合理的是：
AI
↓
Draft
↓
Evidence
↓
Risk
↓
Lawyer Review
↓
Approval
↓
Client
尤其是以下情况：
高金额案件；
刑事案件；
复杂诉讼；
涉及未成年人；
涉及重大商业秘密；
涉及跨境法律；
Agent置信度低；
法律依据冲突；
检索结果不足。
应该强制进入人工审核。
可以定义：
if risk_level == "HIGH":
require_human_review()
if citation_score < 0.90:
require_human_review()
if legal_sources < 2:
require_human_review()
if jurisdiction_uncertain:
require_human_review()
这比让Agent“自己决定自己是否正确”靠谱得多。
十二、第十一步：建立权限与客户隔离
律师事务所的数据安全要求远高于普通企业知识库。
一个Agent系统至少应该具备：
Tenant
↓
Law Firm
↓
Department
↓
Lawyer
↓
Matter
↓
Document
例如：
律师A
├── 案件001
│ ├── 起诉状
│ └── 证据
│
└── 案件002
律师B
└── 案件003
律师B绝对不能因为向量相似度搜索而检索到案件001。
因此RAG过滤必须发生在检索层，而不是只依赖Prompt。
错误方式：
Vector Search
↓
TopK
↓
LLM判断“这个文件能不能看”
正确方式：
User Identity
↓
Authorization
↓
Metadata Filter
↓
Vector Search
↓
TopK
例如：
filters = {
"tenant_id": user.tenant_id,
"matter_id": user.matter_id,
"access_level": {"$lte": user.level}
}
docs = vector_db.search(
query_embedding,
filters=filters,
top_k=10
)
权限控制必须在数据访问层完成，不能把安全责任交给大模型。
十三、第十二步：客户数据不能直接裸奔给外部模型
如果律师将客户的合同、身份证明、商业秘密、诉讼材料直接发送到第三方模型API，可能产生严重的数据治理问题。
因此生产环境建议建立：
Client Data
↓
DLP
↓
Sensitive Data Detection
↓
Policy Engine
↓
Anonymization / Masking
↓
LLM Gateway
↓
Model
例如：
张三，身份证号：110101xxxxxxxxxxxx
进入模型前可以处理为：
[PERSON_001]，身份证号：[ID_CARD_001]
内部保存：
PERSON_001 → 张三
ID_CARD_001 → ********
模型只处理业务语义，不直接接触不必要的原始身份信息。
十四、第十三步：Agent架构应该从一开始就支持审计
一个生产级律师Agent应该记录：
谁
↓
什么时候
↓
访问了什么案件
↓
输入了什么问题
↓
调用了什么工具
↓
检索了什么资料
↓
模型使用了什么版本
↓
生成了什么结果
↓
律师是否修改
↓
最终交付什么内容
因此建议设计：
CREATE TABLE agent_audit_logs (
id BIGINT PRIMARY KEY,
tenant_id BIGINT,
user_id BIGINT,
matter_id BIGINT,
session_id VARCHAR(64),
model VARCHAR(100),
tool_name VARCHAR(100),
action VARCHAR(100),
input_hash VARCHAR(128),
output_hash VARCHAR(128),
risk_level VARCHAR(20),
created_at TIMESTAMP
);
不一定要保存所有原始内容，但至少应该能够恢复：
一次法律结论是怎么产生的。
这对于纠错、内部审计和责任追踪都非常重要。
十五、第十四步：建立完整的Agent技术架构
一个实际可部署的系统，可以采用下面的架构：
┌───────────────────────────────────────────┐
│ Web / Mobile │
└───────────────────┬───────────────────────┘
↓
┌───────────────────────────────────────────┐
│ API Gateway / SSO │
└───────────────────┬───────────────────────┘
↓
┌───────────────────────────────────────────┐
│ Legal Agent Service │
│ │
│ Planner → Executor → Validator │
│ ↓ ↓ ↓ │
│ Memory Tools Guardrail │
└──────┬─────────┬──────────┬───────────────┘
│ │ │
↓ ↓ ↓
┌──────────┐ ┌──────────┐ ┌──────────────┐
│ Vector DB│ │ Legal DB │ │ Case Search │
└──────────┘ └──────────┘ └──────────────┘
│ │ │
└─────────┼──────────┘
↓
┌─────────────┐
│ LLM Gateway │
└──────┬──────┘
↓
┌─────────────────┐
│ Model Provider │
└─────────────────┘
Cross-cutting
┌──────────────────────────────────────┐
│ IAM / Audit / DLP / Monitoring / KMS│
└──────────────────────────────────────┘
如果使用Go构建后端，可以进一步拆成：
cmd/
└── server/
internal/
├── agent/
│ ├── planner/
│ ├── executor/
│ ├── memory/
│ └── guardrail/
│
├── legal/
│ ├── law/
│ ├── case/
│ ├── contract/
│ └── citation/
│
├── retrieval/
│ ├── vector/
│ ├── keyword/
│ └── reranker/
│
├── tools/
│ ├── search_law.go
│ ├── search_case.go
│ └── calculate.go
│
├── security/
│ ├── iam/
│ ├── dlp/
│ └── audit/
│
└── workflow/
十六、第十五步：不要忽视法律Agent的评测体系
普通LLM评测：
答案像不像？
法律Agent必须增加：
法律是否真实？
引用是否准确？
法律是否有效？
事实是否遗漏？
推理是否成立？
是否出现幻觉？
是否越权访问？
因此可以建立五层评测。
1. Retrieval评测
Recall@K
Precision@K
MRR
NDCG
判断：
正确法律依据有没有被检索出来。
2. Citation评测
Citation Accuracy
Citation Completeness
Citation Entailment
判断：
引用的法律是否真的支持答案。
3. Reasoning评测
检查：
事实 → 法律规则 → 涵摄 → 结论
是否逻辑一致。
4. Safety评测
测试：
越权访问
恶意Prompt
敏感数据泄漏
错误法律引用
过度确定性回答
5. End-to-End评测
最终由律师评价：
是否节省时间？
是否降低漏检？
是否减少重复劳动？
是否提高法律研究效率？
十七、第十六步：建立“拒答机制”
这是法律Agent与普通聊天机器人非常不同的一点。
Agent应该知道什么时候不能回答。
例如：
无法确定适用法域
↓
拒绝直接结论
↓
要求补充信息
或者：
检索不到权威法律来源
↓
禁止生成确定性法律结论
↓
进入人工审核
Prompt可以要求：
如果缺乏足够事实，不得自行补全关键事实。
如果无法找到权威法律依据，不得生成确定性的法律结论。
如果发现法律来源之间存在冲突，应明确指出冲突，
而不是自行选择其中一个作为确定答案。
所有涉及具体法律结论的输出必须提供可验证依据。
但需要强调：
Prompt不是安全边界。
真正的安全控制应该由：
Prompt
+
Tool权限
+
Policy Engine
+
Citation Validator
+
Human Review
共同完成。
十八、第十七步：用NIST方法建立Agent风险管理体系
NIST的AI RMF以及生成式AI Profile提供了一套适合企业AI系统风险治理的框架，强调在AI生命周期中持续识别、评估和管理风险。([NIST][2])
放到律师Agent中，可以映射为：
Govern
↓
Map
↓
Measure
↓
Manage
具体可以落成：
阶段 | 律师Agent实践 |
|---|---|
Govern | AI使用政策、责任边界 |
Map | 梳理案件、客户、数据、模型风险 |
Measure | 准确率、引用率、幻觉率 |
Manage | 人工审核、拒答、权限、审计 |
尤其要建立模型版本管理。
例如：
Agent Version
Model Version
Prompt Version
RAG Version
Knowledge Base Version
Tool Version
Policy Version
最终形成：
Answer
=
Model
+
Prompt
+
Knowledge
+
Tools
+
Policy
这样出现问题时才能定位：
到底是模型错了、知识库错了、Prompt错了，还是检索错了。
十九、第十八步：欧盟等跨境业务必须考虑AI监管
如果律师事务所或者法律科技产品涉及欧盟市场，还需要根据具体应用场景判断《EU AI Act》的适用要求。
EU AI Act对高风险AI系统提出了包括风险管理、技术文档、日志、人类监督等要求；其中高风险AI系统的部署者需要采取适当技术和组织措施，并安排具有能力、培训和权限的人进行人类监督。([EUR-Lex][3])
因此跨境法律Agent最好从架构层就保留：
Risk Classification
↓
Human Oversight
↓
Logging
↓
Documentation
↓
Accuracy / Robustness
↓
Incident Management
而不是等产品上线以后再补合规。
二十、第十九步：真正适合落地的开发路线
如果从零开始建设律师Agent，不建议一次性做完整平台。
可以按照四个阶段推进。
Phase 1：Copilot
目标：
帮律师，而不是替律师。
实现：
法律搜索
+
合同总结
+
条款分析
+
文书初稿
这一阶段主要验证：
律师是否真的愿意使用。
Phase 2：Legal RAG
加入：
法规库
案例库
内部知识库
引用系统
版本控制
重点解决：
答案是否可靠。
Phase 3：Workflow Agent
加入：
Planner
+
Tools
+
Workflow
+
Approval
+
Audit
例如：
合同上传
↓
自动解析
↓
风险扫描
↓
法律检索
↓
生成修改建议
↓
律师审核
↓
生成最终报告
这一阶段才真正进入Agent。
Phase 4：Multi-Agent
当单Agent复杂度明显上升后，再考虑多Agent：
Supervisor
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Research Agent Contract Agent Case Agent
│ │ │
└──────────────┼──────────────┘
↓
Review Agent
↓
Lawyer Review
但不要为了“多Agent”而多Agent。
如果一个Agent + 工具 + 工作流能够完成任务，就没有必要人为拆成五六个Agent。
二十一、律师Agent最终应该是什么样
一个成熟的法律智能体，不应该表现成：
“我是AI律师，请问您有什么问题？”
而应该更像一个数字化法律助理：
律师：
审查这份供应商合同，重点看违约责任和付款风险。
Agent：
已完成合同解析。
发现：
1. 付款节点存在歧义
2. 逾期付款责任不对称
3. 供应商违约责任上限过低
4. 未发现明确的数据保护条款
我检索了当前有效的相关法律规定及内部合同模板。
其中第2、3项存在较高风险。
依据：
- 法律条款 A
- 司法案例 B
- 本所合同模板 C
建议修改：
……
其中第3项涉及较高金额责任，
建议律师人工确认后再形成最终意见。
这种交互方式才符合律师真正的工作习惯。
二十二、结语：法律Agent的核心不是“像律师”，而是“可验证”
AI Agent进入律师行业，最大的误区就是追求：
更大的模型、更像人的表达、更长的推理过程。
实际上，法律行业最需要的是另一套能力：
准确
↓
有依据
↓
可追溯
↓
可验证
↓
权限可控
↓
风险可控
↓
人工可接管
律师不会因为一个模型回答得很像律师，就把案件交给它。
真正能够进入生产环境的法律Agent，需要把大模型放进一个严格受控的系统：
┌─────────────┐
│ Lawyer │
└──────┬──────┘
↓
┌──────────────┐
│ Legal Agent │
└──────┬───────┘
↓
┌────────────────────────────────┐
│ Planner / RAG / Tools / Rules │
└────────────────┬───────────────┘
↓
┌──────────────────┐
│ Evidence & Legal │
│ Verification │
└────────┬─────────┘
↓
┌──────────────────┐
│ Human Validation │
└────────┬─────────┘
↓
Final Output
归根到底，律师Agent不是“AI替代律师”的工程，而是一次法律工作流数字化重构。
模型负责语言理解和复杂信息综合，RAG负责寻找依据，规则引擎负责确定性判断，工具负责执行专业任务，权限系统负责数据边界，审计系统负责追踪过程，律师负责最终专业判断。
这套架构的价值也恰恰在这里：不是让AI拥有律师的最终决策权，而是让律师拥有一个能够检索、分析、执行和验证大量工作的智能协作者。
在法律这种高风险专业领域，这可能比单纯追求“全自动AI律师”更加现实，也更加接近真正能够规模化落地的技术路线。
参考资料
American Bar Association — Formal Opinion 512: Generative Artificial Intelligence Tools ([美国律师协会][1])
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile ([NIST][2])
EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act) ([EUR-Lex][4])
[1]: https://www.americanbar.org/content/dam/aba/administrative/professional_responsibility/ethics-opinions/aba-formal-opinion-512.pdf?utm_source=chatgpt.com "AMERICAN BAR ASSOCIATION"
[2]: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence?utm_source=chatgpt.com "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile | NIST"
[3]: https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng?utm_source=chatgpt.com "EUR-Lex - 02024R1689-20260727 - PT - EUR-Lex"
[4]: https://eur-lex.europa.eu/eli/reg/2024/1689?utm_source=chatgpt.com "EUR-Lex - 02024R1689-20260727 - EN - EUR-Lex"