一家纸浆厂，5 万人天天为"查个数"等两三天
Suzano 是全球最大的纸浆制造商，员工 5 万。日常里大量人需要查生产、库存、物流数据——传统做法是找 IT 部门写 SQL 报表，一次查询平均等两三天。
IT 被这些临时取数淹没了，业务侧又干等着。典型的"数据在手边，人却够不着"。更糟的是，等 IT 排期排完，那个业务决策的点早就过了。一个采购想比价，等两天拿到表，供应商的报价窗口早关了。
它怎么解决的
Suzano 跟谷歌云、Sauter 合作，用 Gemini Pro 搭了个智能体：员工用自然语言提问，它自动转成 SQL，去 BigQuery 上查 SAP 的物料数据。
关键设计是"只读"——智能体只能查，不能改。这把数据篡改的风险直接掐死，也让合规团队睡得着觉。你问"巴西厂上月木片库存多少"，它直接给你答案，不用懂 SQL，也不用等人。这个"只读"不是偷懒，是刻意的护栏：宁可功能少一点，也不能让 AI 动生产数据。
数字翻译一下
5 万名员工的查询耗时降了 95%。原先两三天才能拿到的数，现在几分钟到手。分析团队从每周 200 多次临时取数里解放出来。自助查询上线一季度采纳率就到 78%。
体感：一个产线班长想看某批原料的库存，不用再开 ticket 等 IT，自己打字问一句就有答案。对 5 万人的组织，这种"随手查"省掉的是海量的等待和转手。TELUS 这类电信巨头也见过类似提升——5.7 万成员定期用 AI，每次交互平均省 40 分钟。
一个具体场景
假设你是 Suzano 的采购，想比对两个供应商上季度的到货准时率。过去你提需求给 IT，两天后拿到表。现在你直接在对话框里问，三分钟出对比。决策从"下周再说"变成"现在就定"，积压的采购优化一口气能做一大波。以前要开会扯半天的决策，现在一个人三分钟搞定。
为什么"只读"这个设计最值得抄
很多公司上 AI 查数据，第一反应就是"让它帮我改数据"，结果出了事故才后悔。Suzano 反着来：智能体只能看、不能动。这看似功能阉割，实则是让项目能过合规那关的关键。没有哪个 CIO 敢让 AI 随便改生产库，但让 AI 只读着回答问题，签字就容易多了。
对大公司，"能上线"比"功能全"重要十倍。一个只读的查询智能体，当天就能批；一个能写数据的智能体，安全评审能拖半年。Suzano 选了能跑的那条路。所以别看它快就全信，关键决策前让它把 SQL 也吐出来，人瞄一眼再动手。多这一步，既不误事也不耽误效率。
再把镜头拉远：5 万人的公司，最贵的不是算力，是"人等数据"累积的时间。Suzano 把每次查询从几天压到几分钟，省下的不是某一个员工的工时，是整条业务链的响应速度。采购快了、排产能调了、库存看得见——这些连锁反应，才是 95% 背后真正的价值。
踩坑与边界，得泼冷水
第一，它只是个单任务专用智能体，不是通用 BI 助手。Suzano 没想造一个"啥都懂的商业智能 copilot"，就盯准"自然语言查 SQL"这一件高量大明确的事。范围窄，才好度量、好验证——这也是它敢说"95%"的底气。
第二，依赖干净的 SAP 数据结构和谷歌云。你的企业数据要是乱的、表关系没理清，这智能体转出来的 SQL 照样错。它放大的是你已有的数据秩序，不是替你重建。先理数据，再谈智能体。
第三，95% 是"耗时"的降幅，不等于"准确率"的保证。查询快了，但答案对不对，还得靠底表质量和后续人工抽检兜底。别因为它快，就免去所有的复核。
三个能直接搬的教训
- 从最高频、最标准的取数场景切，别一上来造全能分析神。
- 只读不写，把数据改动风险挡在门外，合规才睡得着。
- 底表先治理，智能体是放大器，不是重建器。
跟你有啥关系
你公司数据散、查个数得求 IT，Suzano 这案例的范式很值得搬：别一上来追求"全能数据分析师 AI"，先找一个最高频、最标准的取数场景，用大模型接你的数据库，做成只读的自然语言查询。小公司数据量小，落地比 Suzano 还快。记住三条：只读不写保安全、先窄后宽、底表先理干净。这样你省下的不是一个人的力，是整条组织等数据的拖延。IT 也能从"取数工具人"里解放出来，去干真正要判断力的活。先从一个查询场景试水，跑顺了再慢慢加，别贪多。数据秩序没理清前，智能体再强也是空中楼阁。