支付公司最初禁止AI碰数据，15个月后主动索要AI方案

客户告诉我们，人工智能绝不允许靠近他们的支付数据。15 个月后，他们的 DevOps 主管要求我们把平台上的人工智能设置移交给他们。来看看这中间发生了什么。

一家美国支付处理和金融科技公司的数据分散在 30 多个数据库和文件源中。一些定期报告需要经验丰富的数据工程师针对每个系统逐一运行 Lambda 函数。他们雇我们来建数据仓库。
8 个人用了 15 个月，从来没有同时全员到场：项目经理、数据架构师、三名数据工程师、业务分析师、AWS 顾问，还有一名开发人员做了两个月。

支付数据、PCI 要求，还有团队要求人工智能绝不允许靠近他们的系统。所以我们没有争辩。人工智能从来没碰过生产环境。它只在我们这边，在 Cursor 里，在我们自己的分支上工作。在我们设计访问层之前，它就已经映射好了他们遗留计费代码库。它帮助编写了中间件，成为数据唯一可控入口。它通过带验证脚本的工作流记录了每张生产表，验证脚本必须通过才能发布任何内容。

它并非完美无缺。人工智能草拟的第一份索引计划引用的表名和生产环境不匹配。我们发现了问题，按规则规定生产环境是唯一信息来源。

他们最终得到的成果：
→ 一个仓库里约 15 亿条记录
→ 交易数据每 5 分钟更新一次，原定目标是 24 小时
→ 检查了 1369 个字段，第一次匹配率就达到 96%
→ 关键交易查询从 68 秒缩短到 3 秒
→ 统一交易处理成本降低约 97%
→ 业务分析师可以用纯 SQL 运行报告

之后我们测试了文档。他们的一名数据工程师仅使用人工智能生成的操作指南，就独自把一张表迁移到了仓库里。就在这时，情况发生了转变。他们的 DevOps 主管看到了文档是如何生成的，也想要在他们这边用上同样的东西。我们把相关技能、智能体连同平台一起移交给了他们。

当初我们靠幻灯片演示都没能说服他们。现在他们亲眼看到它在自己的系统里，在他们划定的范围内正常工作。而真正的回报还没开始显现。

约 15 亿条记录，一个受管控的仓库。401 个交易属性被解码为干净的脱敏列。每张表都有文档。他们的数据终于准备好迎接人工智能了。

大多数公司想要先上人工智能，之后再整理数据。但其实应该反过来做。

预订一次探索性通话，推出原生人工智能产品：