当一家拥有十万员工的全球性银行决定把 AI 放到业务核心位置，它面对的不再是"要不要用"的问题，而是"怎么让所有人真正用起来"。BBVA 与 OpenAI 的合作给出了一个可参考的路径：从试点到全员覆盖，从通用工具到垂直场景，从单点实验到体系化运营。
从试点到十万人的节奏控制
BBVA 并非一夜之间把 ChatGPT Enterprise 推给所有人。规模化部署的关键在于节奏——先小范围验证价值，再逐步放开权限、扩展场景。
据公开信息，BBVA 在部署过程中做了几件关键的事：
- 统一平台入口：选择 ChatGPT Enterprise 而非自建模型，省去基础设施运维成本，直接获得企业级合规与数据隔离能力。
- 分层推广：先在技术和产品团队验证，再向业务、合规、运营等职能扩散，每一层都配套培训和使用指南。
- 场景驱动而非工具驱动：不是告诉员工"你们现在有个聊天机器人"，而是针对具体工作流——比如合规文档审查、客户沟通模板生成、内部知识检索——给出明确的使用方式。
这种节奏控制对任何想规模化引入 LLM 的企业都有参考价值：工具本身不产生价值，嵌入工作流才产生价值。
企业级部署的核心决策点
把 LLM 推到十万人的规模，技术选型只是冰山一角。真正决定成败的是几个非技术决策：
数据边界怎么划？ ChatGPT Enterprise 的核心承诺是"企业数据不用于训练"，这对金融行业是硬性要求。BBVA 选择 Enterprise 版本而非个人版，本质上是在数据合规上做了一次前置决策。
权限模型怎么建？ 十万员工不是同一种角色。前台客户经理、中台风控分析师、后台 IT 工程师，对 AI 的使用场景和权限需求完全不同。BBVA 需要建立基于角色的访问策略——谁能用哪些功能、哪些数据可以输入模型、输出需要什么级别的人工审核。
成本模型怎么算？ Enterprise 版本按席位收费，十万人意味着一笔不小的投入。BBVA 的逻辑是：如果 AI 能让每个员工每周节省 2-3 小时的重复性工作，投入就值得。这要求组织先量化"时间节省"，再决定"席位预算"。
实践：用 OpenAI API 构建银行内部合规审查助手
以下示例展示如何基于 OpenAI API 构建一个面向合规团队的文档审查助手。这不是 BBVA 的内部代码，而是根据同类场景设计的可运行参考实现。
"""
合规文档审查助手 —— 基于 OpenAI API
功能：对内部政策文档做合规要点提取与风险标注
运行前需设置环境变量：export OPENAI_API_KEY="sk-..."
依赖：pip install openai pydantic
"""
import os
from openai import OpenAI
from pydantic import BaseModel
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
# 定义结构化输出 schema
class ComplianceFlag(BaseModel):
clause_id: str # 条款编号
risk_level: str # high / medium / low
summary: str # 风险摘要，一句话
suggestion: str # 建议修改方向
class ComplianceReviewResult(BaseModel):
flags: list[ComplianceFlag]
overall_assessment: str # 整体合规评估结论
SYSTEM_PROMPT = """你是一名银行合规审查助手。用户会提交内部政策文档片段，
你需要：
1. 逐条识别可能违反监管要求的条款
2. 对每条风险给出等级（high/medium/low）和修改建议
3. 给出整体合规评估
仅基于文档内容判断，不要臆造外部法规。如果文档无明显问题，如实说明。"""
def review_policy_doc(doc_text: str) -> ComplianceReviewResult:
"""对政策文档做合规审查，返回结构化结果"""
response = client.responses.parse(
model="gpt-4o",
input=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": f"请审查以下政策文档片段：\n\n{doc_text}"}
],
text_format=ComplianceReviewResult,
temperature=0.2, # 低温度保证审查稳定性
)
return response.output_parsed
# ---- 示例运行 ----
sample_doc = """
第3.2条：客户个人信息可在集团内各子公司间自由共享，无需额外授权。
第4.1条：贷款审批流程中，风控团队的建议为参考意见，业务主管拥有最终决定权。
第5.7条：客户投诉应在收到后30个工作日内回应。
"""
result = review_policy_doc(sample_doc)
print(f"整体评估：{result.overall_assessment}\n")
for flag in result.flags:
print(f"[{flag.risk_level.upper()}] {flag.clause_id}: {flag.summary}")
print(f" → 建议：{flag.suggestion}\n")
运行前需要：
pip install openai pydantic- 设置
OPENAI_API_KEY环境变量 - 将
sample_doc替换为真实政策文档片段
这个示例的关键设计决策：
- 结构化输出（Structured Output）：用 Pydantic schema 强制模型返回可解析的 JSON，而非自由文本，方便后续接入审批流程系统。
- 低 temperature：合规审查要求一致性，同一文档多次审查结果应高度稳定，0.2 是合理选择。
- 系统提示词约束：明确"仅基于文档内容判断"，降低模型幻觉风险——这在金融场景是硬约束。
扩展：从单点工具到平台化运营
单个审查助手只是起点。BBVA 的做法指向一个更完整的运营体系：
# 示例：企业 AI 平台的角色-场景映射配置（概念性 YAML）
ai_platform:
roles:
compliance_officer:
allowed_scenarios:
- policy_review # 政策合规审查
- regulatory_monitor # 监管动态追踪
input_guardrails:
- no_customer_pii # 禁止输入客户个人身份信息
output_review:
required: true # 输出必须经人工复核
reviewer: senior_compliance_lead
relationship_manager:
allowed_scenarios:
- email_draft # 客户邮件起草
- meeting_summary # 会议纪要生成
input_guardrails:
- no_internal_strategy_docs # 禁止输入内部战略文档
output_review:
required: false # 低风险场景可自动发出
auto_send_limit: standard_communication
data_engineer:
allowed_scenarios:
- sql_generation # SQL 生成辅助
- data_pipeline_doc # 数据管道文档
input_guardrails:
- no_production_data_direct # 禁止直接输入生产数据
output_review:
required: false
这个配置文件体现了企业 AI 平台的核心思路：不是所有人都能做所有事。每个角色有明确的使用边界、输入限制和输出审核要求。BBVA 推到十万人规模时，必然需要类似的权限与治理框架。
规模化引入 LLM 的决策清单
如果你所在的组织也在考虑类似路径，以下清单可以帮助评估 readiness：
| 决策维度 | 需要回答的问题 |
|---|---|
| 合规底线 | 数据是否可以离开组织？模型提供商的数据训练政策是否满足监管要求？ |
| 场景优先级 | 哪 3-5 个工作流能最快证明 AI 的时间节省价值？ |
| 权限分层 | 不同角色对 AI 的使用范围、输入限制、输出审核要求是什么？ |
| 成本模型 | 每席位成本 vs 预期时间节省，ROI 需要在几个季度内转正？ |
| 培训体系 | 是否有场景化的使用指南，而非只提供工具本身？ |
| 度量体系 | 怎么量化"用起来"——活跃率、场景覆盖率、还是时间节省量？ |
| 失败预案 | 模型输出错误时的回退流程是什么？谁负责审核、谁负责兜底？ |
BBVA 的案例证明，规模化部署 AI 不是技术问题，是组织问题。技术选型（ChatGPT Enterprise）解决的是合规与基础设施，真正的挑战在于：把 AI 从"可选工具"变成"工作流的一部分"，需要场景设计、权限治理、培训体系和度量反馈的完整闭环。
十万人的部署不是终点，是起点。下一步要看的是：这些员工用 AI 做了什么，哪些场景真正改变了产出质量，哪些场景只是表面热闹。这些数据，才是判断"AI 放在核心位置"是否成立的关键证据。