直面AI Coding，中小医院守好四道“门禁”

来源：HIT专家网 作者：陆婷娟

对中小医院而言，过去真正由自己产出的代码并不多，从写代码、审代码到测试、上线，信息部门工程师对自己写的代码负全责。如今，AI Coding将写代码的门槛降至接近零，由此带来的不稳定、不安全后果，该由谁来承担？医院信息部门应该怎么办？

作为在中小型医院工作二十余年的医信人，笔者想从工程师的角度谈一谈AI Coding给医院带来的变化与风险，以及几道不赶时髦、够得着的“门禁”办法。

变化：AI Coding改变代码生产方式

1.写代码的，从少数人变成了“人人”

如今，在AI编程助手或低代码平台的帮助下，不管是信息部门还是临床科室、护理部、药剂科、财务科，都能自行搭起一些IT小工具。但是，在这些自建工具的生产过程中，提出需求的人往往既缺乏安全判断能力，也缺乏合规意识，大多数医院也未形成“谁审批、谁负责”的规范制度。如果编程工具的使用，缺乏立项、评审、安全审核、上线批复的正式流程，就是典型的“影子IT”，借助AI 生成代码时，这种风险等级更上一层。

AI Coding改变了代码生产方式，核心不在于“谁在写代码”，而在“写代码与审代码的剪刀差”：“写代码”的边际成本已接近于零，“审代码”的成本却几乎没变。大医院有安全团队和流程来消化这个剪刀差，中小医院则没有，信息部门工程师白天处理故障、应付报表和检查，晚上还要对源源不断的新增代码逐行把关，这不现实。何况AI生成的代码常常“功能可用、工程失范”：界面能跑通，但边界没人测、异常没人处理、权限校验可能整个漏掉。中小医院缺乏代码评审与测试环节，这类代码上线最快，出事也最直接。

2.AI工具链本身成为新的攻击面

过去谈代码安全，盯的是代码内容；如今，安全边界已经延伸到代码生成工具链。AI编程工具的自身漏洞，正在成为软件供应链的高频攻击入口。

2026年披露的“Clinejection”攻击很典型：攻击者只需构造一个恶意的GitHub issue标题，就能触发Cline AI编程工具的自动审核漏洞，实现提示注入，进而窃取NPM发布令牌、污染CI构建缓存、发布恶意版本包。该恶意包上线8小时内被4000余名开发者下载使用。同年9月披露的“GitSpawn”漏洞影响面更广：某主流AI编程工具启动时会默认执行Git命令抓取项目上下文，恶意仓库通过篡改.git/config配置文件里的一个参数，即可实现任意命令执行，完全绕过工具沙箱与人工审批。

对中小医院，这意味着三件事。首先，买来的AI工具、搭建的自动化流水线，可能因为一个issue标题、一个配置文件就被攻破，而我们没有安全团队来发现这些问题。其次，信息部门和各科室用的是同一批工具、同一个模型，一旦有漏洞，从工程师的笔记本到科室的自建小工具会一起暴露。第三，这类漏洞的修复要等工具更新，多数时候我们甚至不确定自己用的工具是不是正暴露在漏洞之下。

最实际的动作，是先把家底摸清：使用什么AI编程工具、谁在用、连着什么服务、日志留在哪里。家底摸不清，后面什么都谈不上。

风险：数据安全边界与代码安全审核

1.数据安全边界：患者数据，可能夹在代码里“出院”

并非所有源代码都是敏感数据，真正危险的是源码中夹带的内容：患者数据字典与字段定义、接口返回结构、脱敏之前的示例数据与测试数据、写死在配置里的账号口令、调试日志中的真实请求样本等。

这里要分清两层风险。第一层是“人贴出去”：工程师把带患者数据的代码贴进对话框，数据跟着代码一起出院，这一层风险还能靠后面的脱敏门禁去拦。第二层是“工具收上来”：AI编程工具可能主动、静默地把本地数据打包带走，人从头到尾没有粘贴动作。

2026年9月的“ZCode风波”就是典型。有开发者发现本地被生成了一份313MB的加密快照，装的是整个工作区的完整内容，包括完整的Git历史、早已删除文件的残留、配置里的数据库口令与云服务凭证，这份快照曾尝试上传564次。更值得警惕的是，即使用户在设置里关掉了上传开关，后台进程仍在继续尝试上传；解密密钥由服务端下发、私钥只在云端，用户在本地既无法解密，也无法核查数据被收走了什么。厂商事后将原因归为“代码库索引”功能默认开启。

对医院来说，风险的性质已经变了。哪怕一个文件从未在对话里被提及，甚至早已删除，只要它还留在Git历史里，就会被原样打包；被收走的也不是“当前这段代码”，而是整个工作区。换句话说，即使我们严守“不把真数据贴给AI”的规则红线，只要本地还存着真实患者样本、测试库账号和内网口令，AI工具本身就可能在后台完成一次“数据出院”，而这一次工程师全程没有动作，日志上也留不下痕迹。

这些数据一旦被提交到院外的公共大模型服务，就可能构成《个人信息保护法》提及的“向第三方提供或委托处理敏感个人信息”，超出患者授权范围；若服务节点在境外，还会触发数据出境的合规义务。大医院可以自建本地推理能力、自建规则库，中小医院怎么办？

2.代码安全审核：没人审代码，出了问题由谁负责？

《个人信息保护法》《数据安全法》、等级保护2.0等法规政策，均对身份鉴别、访问控制、重要数据加密存储与传输均有硬性规定。测评检查往往要求“拿出证据”：制度文件、审批记录、代码台账、整改记录。这些“纸面功夫”最容易欠账。欠账的代价，往往要到出事时才被想起来。

我们还要看到AI Coding的特殊性：数百万开发者共用同一底层大模型，一个安全缺陷会随模型输出批量复刻。佐治亚理工学院的溯源分析已确认74例AI编程工具引入的代码漏洞，其中严重级14例、高危级25例；IEEE 2026年发布的测试显示，主流AI编程模型生成的代码中40.8%存在可利用漏洞。如果这类漏洞进入医院系统，直接击穿的就是患者数据防线。更麻烦的是，它会把同一个安全缺陷原样写进多套代码，一处漏洞牵动的可能是全院多个系统。

立足自身，中小医院AI Coding的四道“简易门禁”

中小医院信息部门人少事多，与其事后审核、分身乏术，不如通过“门禁”将审核前置，尽量弥补安全缺口。

如何在不额外增加预算、不新增人手、不依赖大平台的前提下，帮助中小医院信息部门改善AI Coding带来的安全问题？笔者建议按代码从生成到上线的顺序，设立四道“门禁”（如图1所示）：先立规矩，再控入口，上线前把关，全程留痕。

第一道，红线门禁，管“写什么”。有四类代码绝不能让AI碰：生产库直连、认证与权限核心逻辑、密钥管理、患者数据批量导出。这四类代码的共同点是，一旦出错，将直接撬开系统大门或患者数据的闸门，因此只允许人写、人审、人改。确有必要调整的，要走需求变更审批流程，谁改的、谁批的，台账上记一笔。

红线的另一面，是给“能用”的地方松绑。代码注释、接口文档、运维脚本、报表草稿、教学示例等，这些不碰生产数据、不碰权限核心的活儿，放心让AI干，这正是它提效的地方。

第二道，脱敏门禁，管“问什么”。往公共AI工具贴代码之前，先过一遍脱敏：患者数据字典和字段名，能泛化的要泛化（如将patient_id改成field_a等）；测试数据一律不用真实数据；配置里的账号口令、内网地址和域名，去掉以后再贴；接口文档可以留结构、抹掉内容。原则就是不把真数据展示给AI。

第三道，自检门禁，管“上线前查什么”。一查：日志、错误提示和调试输出里，有没有夹带患者标识字段。二查：新接口、新功能有没有漏加登录与权限校验。最直接的土办法，是换个低权限账号实际点一遍，看能不能看见不该看的。三查：配置文件和代码里有没有写死的账号、口令和内网地址。四查：敏感数据的存储与传输是否走了加密。四条全过，才准上线。

第四道，台账门禁，管“留什么”。用Excel建一张简单的表格，包含：日期、系统或工具名、开发者、AI参与比例（全部生成／部分生成／未使用）、“四查”结果、上线人、备注等，作为事后复盘的资料留档。

四道门禁看似简单，立规矩（红线）、控入口（脱敏）、把关口（自检）、留痕迹（台账），但合起来就是一个缩微版的闭环，可以屏蔽大部分AI Coding带来的不确定因素，且可操作性很强，主动性掌握在工程师自己手上。从最简单的事情做起，往往最为有效。

【作者简介】

陆婷娟，第九〇三医院数智中心主任。

【责任编辑：陈曦 版式：蒙辉】