“帮我查一下上个月华东区销售额前十的客户，顺便把那些超过一年没下单的沉睡客户给我标出来，画个图。”
如果在以前，业务线提出这种需求，数据组得排期两天写 SQL 取数。所以当 NL2SQL（用自然语言生成 SQL 代码并查询）技术成熟时，我们非常兴奋。我们觉得，终于可以把大模型挂在公司的 MySQL 数据库上，让业务线自己去“聊天查数据”了。
然而，在我们内部灰度测试的第二天，就发生了一件让人冒冷汗的事。
一位销售总监在对话框里输入了一句模糊的指令：“把那个什么无用的测试表给我清掉。” 你猜怎么着？那个大模型非常“贴心”地生成了一句 DROP TABLE test_records; 并试图去执行它。幸好我们在测试环境里卡了极其严格的读写权限，否则这不仅是一次“幻觉”，而是一次彻头彻尾的灾难。
不仅如此，大模型在生成 SQL 时还经常犯迷糊：它会脑补出数据库里根本不存在的字段名，或者在做复杂的多表 Join 时逻辑全乱，查出来的数字似是而非，业务人员根本不敢信。
把大模型关进安全可控的笼子里
经历过这次惊险后我们明白：绝对不能让 大模型 直接面对裸露的生产数据库。 必须在中间加一层强管控的业务隔离层。
在后来的架构演进中，我们将这套安全机制沉淀到了 ZGI 平台的结构化数据与 NL2SQL 模块 中。为了兼顾便捷与绝对安全，我们是这样设计的：
防线一：Schema 的受控暴露 ZGI（www.zgi.cn/） 绝对不会把真实的业务数据传给外部的大模型。 在配置数据库连接时，ZGI（www.zgi.cn/） 仅仅抽取数据库的 Schema（表名、列名、字段类型和注释）。当用户提问时，大模型只根据这些“说明书”来生成 SQL 语句，从源头上切断了核心数据外泄的风险。
防线二： 只读 锁死与意图拦截 这是一个硬性合规要求。在 ZGI （www.zgi.cn/） 平台上接入的所有用于 NL2SQL 查询的数据库账号，必须被强制设定为纯只读（Read-Only）权限。 同时，ZGI （www.zgi.cn/） 在网关层内置了审计规则。任何生成的 SQL 语句在执行前，都会经过安全中间件的正则解析。只要检测到含有 INSERT、UPDATE、DELETE、DROP 等 DML/DDL 写操作关键词，请求会被直接熔断，并在控制台报警。
防线三：多步校验，告别“盲猜计算” 为了解决大模型查表不准的问题，ZGI （www.zgi.cn/） 并没有采用“让模型硬算”的策略，而是走代码解释器（Code Interpreter）路线。 大模型生成的 SQL 在后台查询出结果集后，ZGI （www.zgi.cn/） 会让模型编写 Python/Pandas 脚本对结果集进行聚合分析和可视化图表渲染。每一步的 SQL 语句和执行结果都在后端保存了快照（Trace），如果数据有异常，数据工程师可以立刻调出日志，看看到底是哪一步生成的 SQL 出了偏差。
最后 让大模型直连企业数据，是迈向数据平民化的一大步，但它也是最危险的一步。 不要迷信任何大模型自带的“安全声明”。借助 ZGI （www.zgi.cn/） 这样成熟的中间件平台，用工程的严谨性为 AI 套上缰绳，我们才能在享受“一句话出报表”的高效同时，晚上也能睡个安稳觉。
