医疗AI产品从研发走向临床应用，最难跨过的一关往往不是算法精度，而是监管审计对运行环境一致性的严苛要求。同一个模型在训练服务器上准确率很高，但部署到医院内网后，因为Python依赖版本不同、系统库更新或CUDA驱动差异，推理结果可能出现微妙偏移。监管机构要求每一份被审评的模型都对应一个可追溯、可复现的软件运行环境，Docker恰好能把这种环境固化成可签名的交付单元。
一、医疗AI监管对运行环境的核心要求
医疗器械软件在国内注册和变更时，通常需要提交软件描述文档、版本命名规则、已知缺陷列表以及完整的部署说明。审评人员关注的是，训练阶段的软件环境和实际部署时是否一致，因为即便是底层库的小版本差异也可能让模型推理结果不一致。肿瘤辅助诊断、影像分割、病理细胞检测等场景对结果稳定性尤其敏感，监管上不能接受一个只在特定机器上才能复现的模型。
Docker的价值在于通过镜像和容器把操作系统用户态、运行时、依赖库、代码和配置一次性打包。与传统的部署文档不同，Dockerfile本身就是环境构建的可执行说明，每一条指令对应一次文件系统变更。镜像构建完成后，无论在医院内网、私有云还是边缘设备上运行，只要容器运行时版本兼容，文件系统层的内容就完全一致。这种不可变基础设施的思路，恰好对应监管中经常出现的可复现性要求。审计人员可以检查Dockerfile中的基础镜像、依赖安装命令和版本锁定方式，而不必去猜测某台服务器上是否手动改过某个库。
当然，Docker本身并不自动保证合规，它需要配合严格的版本管理策略。比如基础镜像不能使用latest标签，所有Python包必须锁定到具体版本，依赖下载来源需要固定在内网镜像仓库。这些做法能减少环境漂移，也让变更历史可以通过镜像标签和构建记录追踪。
二、用Dockerfile固化医疗AI推理环境
医疗AI推理服务通常依赖PyTorch、TensorFlow或ONNX Runtime，同时还需要OpenCV、DICOM解析库等系统组件。下面是一个精简但可落地的Dockerfile示例，它使用python:3.10-slim作为基础镜像，固定安装libgomp1以满足某些数值计算库的运行需求，并通过requirements.txt锁定Python依赖。
FROM python:3.10-slim AS base
RUN apt-get update && apt-get install -y --no-install-recommends \
libgomp1 \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY model/ ./model/
COPY app/ ./app/
EXPOSE 8000
CMD ["python", "-m", "app.main"]
这里有几个细节值得展开。第一，基础镜像使用带版本号的python:3.10-slim而不是python:latest，避免基础镜像升级导致底层系统库变化。第二，apt-get命令拆成多行，并在同一条RUN指令中完成清理，减少镜像层体积，也避免apt缓存被打包进最终镜像。第三，依赖安装和代码拷贝分层进行，这样当代码变化时不会重新安装依赖，构建更快，也更便于审计每次代码变更对应的镜像差异。
requirements.txt也需要锁定版本，例如写成torch==2.2.0、onnxruntime==1.17.1、numpy==1.26.4。如果团队使用pip freeze生成完整依赖树，还可以借助pip-tools或Poetry生成带哈希值的锁文件，进一步增强可复现性。对于需要GPU推理的场景，可以考虑使用NVIDIA官方提供的CUDA基础镜像，并同样固定CUDA版本与驱动要求，避免镜像在运行时与宿主机驱动不匹配。
构建镜像时建议使用docker buildx build，同时生成linux/amd64和linux/arm64两种架构。部分医院边缘设备采用ARM架构，多架构镜像能简化交付流程。构建命令中的--sbom=true和--provenance=true可以生成软件物料清单和构建来源信息，为后续审计提供原始数据。
三、镜像签名与SBOM：构建可审计的交付链
医疗AI软件在交付给医院或提交注册检验时，不仅需要环境可复现，还需要证明镜像从构建到部署期间没有被篡改。Docker镜像本身由多个层组成，每一层都有哈希值，但仅靠哈希无法防止中间人替换整个镜像。此时可以引入镜像签名工具，例如cosign，对镜像摘要进行私钥签名，在部署端用公钥验证。
docker buildx build --platform linux/amd64,linux/arm64 \ -t registry.ipipp.com/medai/inference:v1.2.0 \ --sbom=true --provenance=true \ --push . docker sbom registry.ipipp.com/medai/inference:v1.2.0 cosign sign --key cosign.key registry.ipipp.com/medai/inference:v1.2.0 cosign verify --key cosign.pub registry.ipipp.com/medai/inference:v1.2.0
上述命令中，构建阶段就把软件物料清单和构建来源嵌入镜像，随后用docker sbom命令导出组件列表。比如可以看到镜像中安装了哪些Python包、系统库以及它们的版本。监管审计人员可以对照这份SBOM，确认镜像中没有未声明的组件或存在已知漏洞的依赖。cosign签名则绑定镜像的digest，而不是可变的tag，即使tag被覆盖，签名仍然与原始摘要对应。
在部署侧，可以通过Kubernetes的准入控制器或Docker Content Trust等机制，强制只允许运行带有有效签名的镜像。对于医院内网环境，如果无法访问公共签名服务，可以自建cosign密钥管理体系，并使用硬件安全模块保存私钥。签名验证成功后，再启动容器，这样就能形成从代码提交、镜像构建、签名到运行时的完整证据链。
SBOM在医疗AI中的另一个作用是漏洞管理。医院信息科通常会要求定期扫描镜像漏洞，而SBOM可以直接输入到漏洞扫描工具中，快速定位受影响的组件。相比传统方式逐台服务器检查，容器化方式的漏洞定位更加精确，也便于生成整改报告。
四、医疗数据隐私与容器部署的边界
Docker解决了环境一致性问题，但医疗数据隐私保护不能只靠容器。医学影像、病历文本、检验指标等都属于敏感数据，容器运行时必须配合只读根文件系统、最小权限用户、能力裁剪和网络隔离才能满足数据安全要求。下面的docker run命令给出一个基本示例。
docker run --rm \ --read-only \ --user 10001:10001 \ --cap-drop ALL \ --security-opt no-new-privileges \ -v /data/medai/input:/data:ro \ -v /data/medai/output:/output:rw \ registry.ipipp.com/medai/inference:v1.2.0
这里使用--read-only让容器根文件系统只读，模型和代码在构建时已经写入镜像，运行中不会被修改。--user指定非root用户运行，--cap-drop ALL移除所有Linux能力，no-new-privileges防止进程提权。输入目录以只读方式挂载，输出目录单独授以写权限，避免推理服务对宿主机的其他路径造成影响。医疗数据在容器运行结束后，可以通过挂载的临时卷或外部存储清理，容器本身不保存数据。
需要注意的是，Docker默认网络和存储驱动并不是为医疗合规专门设计的。生产环境通常还需要结合Docker的--network=none或Kubernetes网络策略，限制容器只能访问必要的推理服务端口。对于需要访问PACS系统或医院HIS系统的场景，应通过专用网络和TLS加密通道连接，同时在镜像中避免硬编码数据库密码或API密钥。
另一个常见误区是认为把数据装进容器就完成了匿名化。容器化只解决运行环境隔离，数据脱敏和访问控制必须在应用层和基础设施层分别实现。监管审计中会检查数据流向，因此建议在镜像中内置结构化日志输出，记录每次推理请求的时间、模型版本和数据哈希，而不是原始患者信息。
五、从开发到生产的合规落地建议
要将Docker真正纳入医疗AI监管体系，团队至少需要建立三套配套流程。第一是镜像仓库策略：使用私有镜像仓库并开启镜像签名验证，禁止使用latest标签，每个正式发布版本对应固定的语义化版本号。第二是构建流程自动化：在CI流水线中完成Dockerfile静态检查、镜像构建、漏洞扫描、SBOM导出和签名操作，任何一步失败都阻止镜像推送。第三是部署审计记录：在容器编排平台中记录镜像摘要、启动参数、挂载卷和网络策略，便于向监管机构提供完整的部署证据。
对于已经通过注册检验的医疗AI产品，迁移到Docker部署时应同步更新软件描述文档中的运行环境章节。审评人员通常能理解容器化带来的环境一致性，但需要明确说明容器运行时版本、镜像来源和升级策略。如果之前是以物理机或虚拟机方式提交的注册资料，补充Dockerfile和镜像构建记录可以作为软件版本管理的佐证材料。
医疗AI的监管要求会随着技术发展不断细化，Docker并不能替代质量体系和网络安全体系，但它在可复现性、版本锁定和交付一致性方面提供了非常实用的工程手段。把镜像构建、签名和SBOM纳入日常开发流程，既能让团队在应对检查时更有条理，也能减少因环境漂移导致的现场问题。