模型直连数据库，看似省去了接口开发和数据封装，实际上是把一个不稳定的生成系统直接放到了企业数据与业务控制面的边界上。危险不只来自模型“答错”，更来自错误查询、越权读取、误写数据和缺乏追责机制。一旦模型能够自由访问底层数据库，数据权限、业务规则和操作责任就可能被绕开。
直连会放大三类风险
第一类是数据暴露。数据库通常同时包含客户信息、经营数据、研发资料和财务信息，而模型未必能够准确理解字段的敏感等级与人员的数据范围。即使用户只提出一个普通问题，模型生成的查询也可能触及不应访问的表、字段或记录。
第二类是结果失真。自然语言转查询并不等于业务语义理解。销售额、客户、订单、利润等对象往往存在口径、时间范围和统计规则差异。模型生成的查询语法可能正确，结果却不符合企业定义；如果没有数据目录、指标标准和血缘信息，错误结论很难被发现和追溯。
第三类是系统破坏。若模型拥有写入、更新或删除权限，生成错误操作就可能影响订单、库存、财务记录或流程状态。即使只允许查询，过量请求也可能带来性能压力。更严重的是，数据库层通常缺少业务审批、幂等控制、回滚机制和人工接管入口，出了问题难以判断责任归属。
正确做法是隔离能力
模型不应直接执行任意 SQL，也不应拥有数据库的通用账号。更稳妥的架构是增加业务服务层：将“查询订单状态”“获取客户信息”等能力封装成边界清晰的业务接口，由接口负责参数校验、权限判断、数据脱敏和审计记录。
对于可能改变业务状态的操作，还应设置操作白名单、审批机制、幂等控制、超时与降级策略，并保留原始输入、处理时间、模型版本、操作者和审核记录。涉及资金、客户权益、生产安全或人事处置的流程，应优先采用人工复核，而不是追求全自动执行。
安全边界必须前置
模型接入数据库前，企业至少要明确数据分级、访问范围、责任人和异常处理流程。模型只能获得完成任务所需的最小权限，查询结果也应经过过滤和脱敏。只有当数据口径统一、接口边界清晰、日志可追溯且具备回滚能力时，模型才适合进入业务流程。直连数据库不是集成捷径，而是把本应由治理体系承担的风险，直接暴露给了模型。