医院的旧系统接不上 AI，但我也不能把病历整库搬出去。

院内运营人员想知道不同检查项目的等待情况，好安排第二天的人手。数据已经在旧系统里，但每次提问仍要请信息科导出，再由专人整理。直接给助手一个数据库账号看起来省事，却把一个统计需求变成了可以读取大量患者资料的入口。

先看看已有报表能否回答这个问题。如果固定报表已经够用，继续使用它更稳妥；医院已有的集成平台和审计网关也应保留。真正需要补的，是让新的助手在批准范围内使用现有查询，不是为了接 AI 更换临床系统。

例如，信息科可以先实现一个只接收检查类型和日期范围的查询程序，调用获准的旧系统接口，返回经过检查的等待时长汇总。EasyRemote 接入的是这段程序。原始记录仍由院内系统管理，助手拿到的是这次任务允许的结果，而不是可以自由拼接的 SQL 或全库凭证。

要让这件事成立，医院仍需决定谁可以查、为什么查、哪些结果可以离开当前环境。工程上应把人员身份和用途送到查询前的授权检查，固定允许字段，并处理过小样本可能暴露个人的情况。这些规则要由医院确认并由程序执行，不能写一句“注意隐私”交给模型判断。

运行服务应放在经过批准、能访问原接口的环境，由信息科维护。调用记录可以帮助关联一次请求，但旧系统实际读取了什么、结果发往哪个模型、记录保存在哪里，还需分别接通。若输出交给院外服务，原数据没有整库搬走，也不意味着这次输出就没有隐私风险。

最初用合成数据跑通一次正常统计、一次越界日期和一次无权访问，再由相关负责人审查输出与记录。只有这些路径清楚，才讨论真实数据。这样接入的价值是把已有系统中一项明确、可控制的工作交给助手使用，而不是以一个聊天入口代替医院原有的安全与审查流程。