银行把生成式AI接到客服入口，已经不算新鲜事。真正难的是让它在看账单、问信用卡、处理保险和转接人工时仍保持一致、可控，而且成本不能失控。10月16日，OpenAI发布巴西伊塔乌银行的客户案例，披露其对话式服务ia.i和内部治理平台IARA的阶段性进展：ia.i第一阶段触达约30万客户，覆盖全体客户则是银行希望在2026年底实现的目标。两者不能写成同一件事。这个案例最值得看的，并非“银行用了某个大模型”，而是一个大型金融机构如何把模型、客户数据、业务流程与人工服务接在一起。

伊塔乌从2024年起为特定金融需求加入智能能力，ia.i是下一阶段的统一入口。客户可以用文字或语音询问账户、信贷、银行卡和保险问题，必要时转给专门人员。银行还希望把点击、图像和对话放进同一体验中，让用户不必先弄明白业务在组织架构里属于哪个部门，再去找对应菜单。OpenAI案例提到的“约7000万客户的财务情境”，指的是银行用于理解客户需求与习惯的Customer DNA背景层，不等于7000万人已经在使用ia.i。对大型金融产品而言，把潜在覆盖、已有试点和真实活跃使用量分开，是衡量落地程度的第一步。

30万人的第一阶段，验证的是流程而非全自动顾问

银行服务不是通用问答。客户问“这笔扣款从哪里来”，系统要先识别交易、确认权限，再用人能听懂的话解释；若问到投资建议，适用的风险提示、适当性和人工复核又完全不同。一个聊天框可以收拢入口，却不能替代背后的授权、记录和责任分配。伊塔乌案例把文本、语音和操作结合，并保留向专业人员交接的路径，这意味着其目标是缩短客户抵达正确服务的距离，而非宣布AI独立完成所有金融决定。

首批约30万客户也给银行一个观察真实行为的窗口。用户是否愿意把复杂问题交给对话入口？一次提问能否在权限内得到可执行的下一步？错误答案出现时，系统能否快速定位来源并转给人工？这些问题无法从演示视频里回答。尤其在信用和投资场景中，语言流畅很容易造成“系统已经理解全部上下文”的错觉，实际决定仍取决于账户数据是否新鲜、规则是否有效、以及客户是否同意对应使用。试点更适合积累这些边界证据，而不是将覆盖目标当成既成规模。

伊塔乌选择的不只是一个模型。OpenAI案例称，银行按延迟、成本和推理需求选用不同模型，GPT模型是其中一部分。日常余额查询希望快且便宜，含有合规判断的复杂任务则需要更强的推理和依据。若把所有请求都送往最昂贵模型，运营成本可能先于客户价值膨胀；若全部交给轻量模型，难题又可能落在安全与准确率的薄弱处。分层路由、权限校验和人工升级，在这里比单次回答的惊艳程度更重要。

IARA真正要解决的，是规模化后的治理账

银行内部的IARA平台承担模型接入、编排、观察和政策约束。案例披露，其法务解决方案面对超过9000万份文件的资料库，每月处理超过200万项任务；某些流程环节的效率提升幅度被报告为20%到80%。这个区间只对应具体部门流程，不代表整家银行员工效率提高同样幅度，也不是独立审计的行业基准。法务文档一旦涉及客户权益和合同解释，保留来源、版本和人类签核甚至比节约几分钟更关键。

治理平台还决定银行能否看清每次模型调用花了多少钱、用了哪些数据、是否越过授权范围。金融行业的隐私与责任不是靠在提示词里写一句“请谨慎”就能解决。需要把敏感信息在进入模型前做权限控制，把输出接入业务校验，把异常和偏差纳入持续监测。OpenAI作为供给方在案例中强调多模型和责任AI，但这仍是合作伙伴发布的客户案例；对外部观察者而言，缺少可比较的错误率、申诉率和留存数据，就不能把它读成该模式已经经过所有金融场景验证。

未来计划包括更广的客户覆盖、产品模拟和周期性财务分析。每扩一步，系统从“说明信息”接近“建议和执行”，风险就会上升一级。向客户解释支出趋势，与建议其更换金融产品，所需的事实基础和监管边界不同；自动完成申请，则又要处理同意、撤销和申诉。伊塔乌案例的现实价值，是把这些阶段放在同一张产品路线图上，同时告诉市场：真正的竞争不在于哪个银行先装上聊天入口，而在于谁能在大规模使用后依旧说清每个答案从哪里来、下一步由谁负责。

来源：OpenAI，2026年10月16日客户案例《How Itaú is building generative AI for its entire customer base》：https://openai.com/index/itau-generative-ai/