一句话简介医院AI工具越买越多、接口各说各话把二十个大模型收进一个统一入口是最值的一次架构收口。作为医疗云原生架构师最近在给一家三甲医院做AI应用治理的收尾。信息科主任给我看了一张表全院上线和试用的AI工具已经17个来自9家厂商光“大模型调用”就有5种不同的接入方式模型悄悄换了3个版本没人留过记录有个科室的科研助手还在调去年就停服的接口。他问了一句很实在的话能不能像管HIS一样把AI也管起来这个问题的本质不是“AI太多”而是缺一层统一入口。我按云原生的思路做了一版收口复盘出3个取舍。一、先认清“烟囱”的真实成本不是应用多是入口散三个典型症状。接入方式不统一有的走HTTP、有的塞SDK、有的自定义私有协议模型与版本漂移同一能力并存多个版本、切换无记录调用无账哪个科室用了多少Token、调的是哪个模型没人说得清。烟囱的代价落在三件事上。安全上没法统一做脱敏与审计成本上没法分摊和优化运维上一旦某个模型停服受影响的是业务科室而不是厂商。一个简单的判断标准如果换一个模型需要改N个应用说明缺的就是这一层统一入口。二、取舍一网关先做“协议收口”不要一上来就做中台网关的最小职责边界要收窄。统一入口一个域名、一套鉴权、协议转换把各厂商API差异吃掉、路由与灰度按科室、业务或能力路由、配额与限流、审计日志先把这五件事做扎实。踩过的坑一开始按“AI中台”立项把知识库、标注、训练、评测全塞进来工期排了半年上线时业务侧已经自己接了三个新模型平台成了摆设。改成先只做网关两个月上线其他能力后置。云原生落点很直接全容器化、无状态、多副本、健康检查与故障自动转移模型路由走配置中心切换版本不重启应用。行业里的公开实践也印证了这条路某三甲医院的AI网关就是采用全容器化部署与可视化管理通过统一API接口与协议转换实现多模型统一纳管、弹性扩容和高可用故障自动转移目前已纳管20个大模型。三、取舍二权限与审计要落到“人场景数据”三元组不要按IP放行医疗场景的特殊性在于AI请求里可能夹带患者信息。网关需要能回答三个问题谁发起的、在什么业务场景下、把哪一类数据发给了哪个模型。落地方法分三层。鉴权在网关侧统一做管到科室、角色和来源业务系统数据分级也在网关侧强制执行区分哪些字段可出、哪些要脱敏、哪些只能走院内模型审计全程留痕记下请求ID、模型与版本、Token量、数据分类和响应状态。踩过的坑只在应用层做脱敏结果一个新上线的助手绕过了那套逻辑。改成一律经网关出站应用层脱敏降为第二道网关侧再按数据分级强制校验。行业侧的同类方案也把“全程追溯”列为中台的基本能力原因就在这里出站口唯一审计才完整。四、取舍三把模型当成“可替换的运行时资源”而不是固定资产先建一张模型注册表。每个模型登记版本、能力标签推理生成向量嵌入重排检索、上下文长度、计费口径和可用状态路由按能力来选不按厂商名来选。灰度与回退要成为常态操作。新模型先切10%流量看时延、失败率和人工采纳率达标再放量始终保留一键回退到上一版本的能力。成本治理要能落到科室。按Token计量到科室与业务系统设配额与告警让“哪个场景在烧算力”变成随时可看的数据而不是月底一张总账单。踩过的坑早期直接按厂商名硬编码路由换模型要改代码、要发版。改成“能力标签路由策略”之后业务侧只声明需要什么能力换模型对应用透明。公开实践里还有另一种形态把大模型底座、平台层与应用层分成三层医院不自建算力和模型、按Token调用即可也可院内部署做到数据不出院本质上是一回事把模型从固定资产变成可调度资源。五、落地顺序与验收怎么证明AI真的被管住了顺序建议先盘点把在用AI工具、模型、接入方式列全再收口网关上马后新接入一律走网关后治理配额、审计、灰度逐项补齐最后才谈平台化。验收看四件事能否在不改应用的前提下切换模型能否还原一次AI请求的完整链路也就是谁、什么场景、哪类数据、哪个模型能否按科室出Token账单模型停服时是否有兜底路由。组织上的一个提醒AI网关天然是信息中心牵头的活儿但数据分级标准需要医务、病案、法务一起定否则网关会把业务挡在门外最后被绕过。亮点与结论医院AI的治理起点不是买平台而是承认“入口散”这件事先收口再谈能力。网关的最小职责就五件事统一入口、协议转换、路由灰度、配额限流、审计日志。先做窄才做得成。权限与审计按“人场景数据”三元组设计出站口唯一审计才完整。模型是可替换的运行时资源注册表加能力标签配灰度回退和Token计量换模型不用改应用。一句话收尾AI进医院真正的门槛从来不是模型够不够聪明而是这套东西能不能被信息科像管HIS一样管起来。能被管住的能力才敢用在临床。