在法律行业，AI 的价值不只取决于模型能力，还取决于组织是否敢于使用、是否知道如何使用，以及谁对最终结果负责。Gilbert + Tobin 的实践将 CEO 级别的推动、严格治理和人的最终问责结合起来，用于在全所范围内扩展 ChatGPT Enterprise 与 Codex 的应用。
这套思路的重点不是“把 AI 发给每个人”，而是把 AI 纳入一套可持续的工作系统：管理层明确方向，治理机制划定边界，员工保留专业判断，工具则服务于具体业务流程。
从高层承诺开始
AI 推广经常卡在两个极端：要么由少数技术爱好者自发试用，难以形成组织能力；要么由 IT 部门单独采购，业务团队缺乏使用意愿。CEO 级别的承诺可以解决一个关键问题：AI 不再只是实验项目，而成为组织需要认真对待的工作方式变化。
高层承诺不等于要求所有人立刻使用 AI。更有效的做法是明确三件事：
- AI 服务于哪些业务目标，例如提高研究、起草、知识检索或软件开发效率。
- 哪些数据、任务和输出受到限制，必须遵循安全与专业规则。
- 哪些决定不能交给模型，必须由具备资质的人复核并承担责任。
当这些原则被公开确认，员工更容易理解为什么可以使用企业版工具，也更容易识别哪些场景需要谨慎处理。
治理不是审批表，而是工作边界
法律服务对保密性、准确性和职业责任有较高要求。治理机制需要覆盖工具接入、数据处理、提示词与输出使用、审查流程以及异常反馈，而不只是签署一份使用政策。
可以把治理设计成四道边界：
- 身份边界：只有经过组织授权的账号和工作区才能处理企业任务。
- 数据边界：明确哪些信息可以输入，哪些敏感、受监管或受保密义务约束的信息不能直接提交。
- 任务边界：区分适合 AI 辅助的整理、检索、草拟任务，以及必须由专业人员独立判断的法律结论。
- 责任边界：任何对客户、法院、监管机构或内部系统产生影响的结果，都需要明确的人工审查人。
Codex 这类开发工具也应遵循同样的原则。它可以帮助工程师理解代码、生成测试或加快重复性开发，但代码进入生产环境前仍需要代码审查、自动化测试和发布权限控制。
“人负责”必须落到流程里
“保持人工监督”如果只停留在口号层面，很难指导日常工作。组织需要把它转化为可检查的动作，例如：
- 在交付前核对事实、引用、计算和格式。
- 对模型生成的法律分析保留审阅记录。
- 不把未经验证的输出直接发送给客户或提交给外部机构。
- 对模型无法确认、信息不足或答案相互矛盾的情况设置升级路径。
- 定期收集失败案例，更新培训材料和使用边界。
这里的人工问责并不意味着每个 AI 输出都要经过同等强度的审批。更实际的做法是按风险分级：低风险的格式整理可以采用抽样检查；涉及客户建议、法律结论或生产代码的任务，则需要更严格的复核。
一个可改造的治理配置示例
下面是一份简化的 YAML 示例，展示如何把 AI 使用规则写成团队可以执行的配置。它不是 Gilbert + Tobin 的内部政策，也不代表任何特定产品的默认配置；可以根据本组织的法律、合规和信息安全要求改造。
ai_governance:
approved_workspaces:
- chatgpt-enterprise
- codex-enterprise
data_classes:
allowed:
- public_information
- internally_approved_templates
- synthetic_test_data
requires_review:
- internal_business_information
- anonymized_client_material
prohibited:
- unredacted_confidential_client_data
- credentials_and_private_keys
- data_subject_to_legal_hold_without_approval
human_review:
required_for:
- client_facing_content
- legal_conclusions
- court_or_regulator_submissions
- production_code_changes
reviewer_must_record:
- source_check
- factual_check
- privacy_check
- final_decision_owner
incident_response:
report_to: ai-governance-team
immediate_actions:
- stop_external_distribution
- preserve_relevant_records
- assess_data_exposure
- notify_owner_and_security
使用这类配置时，重点不在 YAML 文件本身，而在于把规则接入真实流程。例如，提交客户材料前做数据分类，代码合并前要求人工审查，面向外部发送前记录最终责任人。规则只有进入权限系统、审批系统、代码仓库或培训流程，才会真正产生约束力。
规模化时要观察什么
AI 项目从试点走向全所使用后，衡量标准也要变化。单纯统计账号数量或调用次数，无法说明组织是否获得了可靠收益。可以同时关注以下指标：
- 哪些业务流程节省了时间，节省是否稳定可复现。
- AI 输出被人工修改、拒绝或升级的比例。
- 数据或权限相关事件的数量与处理时长。
- 员工是否理解可用工具、禁止事项和复核要求。
- 生成代码的测试覆盖、缺陷率和审查退回情况。
这些指标应服务于改进，而不是鼓励员工盲目增加 AI 使用量。一个低调用量但风险控制清晰、结果质量稳定的流程，可能比高调用量的自由试用更有价值。
落地检查清单
组织可以从一小组高价值、低风险流程开始，再逐步扩大范围：
- 由业务负责人和技术、信息安全、合规人员共同定义目标。
- 只提供经过批准的企业工具和账号体系。
- 建立清晰的数据分类与输入规则。
- 为客户交付、法律结论和生产代码设置人工复核。
- 记录失败案例，并把反馈转化为培训和政策更新。
- 用质量、风险和效率共同评估扩展效果。
Gilbert + Tobin 的案例传递出的核心启发是：AI 的规模化采用并不是技术部署项目，而是责任体系的重新设计。高层承诺提供方向，治理机制建立边界，ChatGPT Enterprise 和 Codex 提供能力，而专业人员保留最终判断。只有这几部分同时运转，AI 才能从个人工具变成可信赖的组织能力。