欧盟自托管开源大模型：一份可落地的GDPR合规清单

把提示词发到云端大模型API，本质上就是一次个人数据跨境传输。 GDPR 要求每一次传输都有合法性基础、有书面目的，服务器在 EEA 之外时还要有第五章的传输机制。与其在每次 API 调用上叠合规文件，不如把开源权重模型跑在自己控制的、位于欧盟境内的基础设施上。本文给出一套可运行的部署方案和配套合规清单——也就是你的法务会追问的那些点。

自托管开源大模型GDPR合规

自托管为什么改变了GDPR的等式

调用第三方 AI API 时，服务商是你指令下的处理者：你需要数据处理协议（DPA）、要核查存储位置与再处理者清单，任何流出 EEA 的传输都需要充分性认定或标准合同条款。欧盟-美国数据隐私框架的充分性认定目前仍然有效，2025 年 9 月获欧盟普通法院维持，但向欧洲法院的上诉仍在审理中——此前已有两版框架被推翻。为变化做预案是审慎，不是杞人忧天。

自托管开源权重模型从架构上直接消掉了最难的几个问题：没有外部处理者看到提示词，因此没有 DPA、没有再处理者清单、推理流量也不涉及国际传输；没有厂商训练风险——付费 API 层级本就承诺不用 API 数据训练，而自有模型让这个问题根本不成立；数据驻留天然成立——一台放在 Falkenstein 或 Roubaix 的服务器，数据物理上就在欧盟，不需要合同体操。

诚实的代价是：基础设施的运行与安全由你承担，且你仍然是数据控制者。DPIA、合法性基础、AI Act 分类依然适用。自托管不是合规外挂，它只是把爆炸半径缩小了。

处理者与控制者的区分是GDPR数据治理的起点。控制者决定处理的目的和方式，处理者仅代表控制者处理数据。当您调用第三方API时，服务商是处理者，您需要DPA来约束其行为；而自托管时，您同时扮演控制者和处理者角色，直接承担全部合规责任。这一区分决定了义务分配：控制者负责合法性基础、DPIA和透明度，处理者负责安全保障和协助义务。自托管消掉了外部处理者环节，但并未消掉控制者义务——这正是文章强调“自托管不是合规外挂”的原因。理解这一点，才能正确评估自托管带来的合规收益与剩余风险。

2026年能跑起来的技术栈

当前 Ollama 版本为 v0.40.3，官方镜像支持 NVIDIA CUDA、AMD ROCm 以及内置的 Vulkan 运行时；CLI 能服务的每个模型同时暴露 REST API，并在 /v1 提供 OpenAI 兼容端点。

模型方面，欧盟团队最自然的起点是 Mistral 的开源权重模型——欧盟公司，连权重本身的传输问题都省了。Llama 4、Qwen 3、Gemma 3 也都在 Ollama 模型库中。每个要上线的模型都要核对许可证："开放权重"不等于"开源"，商用条款差异很大。

欧盟境内的硬件，Hetzner（纽伦堡/法尔肯施泰因）、OVHcloud、Scaleway 的独立服务器是常规选择。4-bit 量化模型的粗略配置参考：

模型规模	所需内存/显存	现实硬件
8B (Q4_K_M)	约 6 GB	任意现代 VPS 或笔记本 CPU
32B (Q4_K_M)	约 20 GB	大内存独立服务器
70B (Q4_K_M)	约 40–48 GB	GPU 服务器（如 Hetzner 的 RTX PRO 6000 Blackwell 机型）

从 CPU 上的 8B 模型起步即可——摘要、分类、结构化抽取这些自托管最划算的任务，它足够好用。只有延迟或质量真正卡住时再扩容。

4-bit量化（如Q4_K_M）是一种模型压缩技术，将每个权重参数从16位浮点数降至约4位整数表示，显存占用减少约70%-75%，精度损失通常可控。Q4_K_M中的“K”指k-quants量化方法，“M”代表中等压缩级别。对多数推理任务，4-bit量化模型与全精度版本的输出质量差异很小，但内存需求大幅下降，使70B模型能在单张48GB显存的GPU上运行。部署时需注意：量化模型仍需原始tokenizer和配置文件，Ollama拉取时自动处理这些依赖；不同量化级别（Q2、Q4、Q8）在质量和速度间权衡，生产环境建议从Q4_K_M起步，仅在质量不达标时升级。

十五分钟跑通一套部署

下面的 Docker Compose 把 Ollama 的模型数据放在持久卷上，GPU 段默认注释，仅在 GPU 主机上取消注释：

services:
  ollama:
    image: ollama/ollama:0.40.3
    container_name: ollama
    restart: unless-stopped
    ports:
      - "127.0.0.1:11434:11434"   # 仅绑回环，对外通过反向代理暴露
    volumes:
      - ollama_data:/root/.ollama
    # GPU 变体：在 CUDA 主机上取消注释
    # deploy:
    #   resources:
    #     reservations:
    #       devices:
    #         - driver: nvidia
    #           count: all
    #           capabilities: [gpu]
    environment:
      - OLLAMA_HOST=0.0.0.0
volumes:
  ollama_data:

拉取模型并验证 API：

docker compose up -d
docker exec ollama ollama pull mistral:7b-instruct
curl -s http://localhost:11434/api/tags | head -c 300
curl -s http://localhost:11434/v1/models | head -c 300

第二次调用命中的是 OpenAI 兼容端点，既有应用代码只需改一个 base URL：

from openai import OpenAI

client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
resp = client.chat.completions.create(
    model="mistral:7b-instruct",
    messages=[{"role": "user", "content": "Extract the sender name from this email: ..."}],
    max_tokens=64,
)
print(resp.choices[0].message.content)

在接入真实数据之前：上面的端口绑定在回环地址，任何对外访问都要经过带 TLS 和身份认证的反向代理。一个未鉴权的 LLM 端点就是一次等着发生的数据泄露——而在 GDPR 下，那是你的泄露。

GDPR合规清单，逐条过

1. 合法性基础要有书面记录

多数内部工具适用正当利益，权衡测试要在上线前完成并留档。对面向员工的系统，同意几乎总是不合适的选择；合同履行只覆盖合同真正要求的部分。

正当利益（legitimate interest）是GDPR第6(1)(f)条下的合法性基础之一，适用于处理对实现正当商业目的必要且不压倒数据主体权利的情形。适用时需完成三步权衡测试：识别正当利益（如内部效率提升）、证明处理必要性（无更少侵入的替代方案）、平衡数据主体合理预期与影响。测试结论必须书面留档，并纳入隐私声明。对员工监控类系统，正当利益通常比同意更可靠——因为雇佣关系下同意难以自由给予。注意：正当利益不适用于公共机构行使职权场景，且数据主体有权反对处理，需提供便捷的反对渠道。

2. 数据保护影响评估（DPIA）

上线前跑一次 DPIA，尤其是输出会影响关于人的决策、或大规模处理敏感数据时。先做它——其余大部分条目的答案都在这里落笔。

3. 提示词构造中的数据最小化

在构造提示词之前就删掉模型不需要的东西：一个字段够用就不要传整条客户记录，能脱敏摘要就不要塞原始邮件线程。最小化要实现在拼装提示词的代码里——它是技术控制，不是一句政策声明。

4. 保留与删除——包括你自己的日志

提示词、对话历史和含个人数据的日志，本身就是个人数据。设定保留期并自动执行——一条夜间 cron 比一份政策文档更有价值：

# 清除超过30天的推理日志（按你的策略调整）
0 3 * * * psql "$DATABASE_URL" -c \
  "DELETE FROM inference_logs WHERE created_at < NOW() - INTERVAL '30 days';"

删除请求必须能触达这个存储。用户要求删除时，日志、历史、缓存都要覆盖——"模型权重不记得它"不是答案。

5. 访问控制与加密

传输层 TLS、模型数据卷静态加密、凭证轮换。即便没有厂商可以甩锅，第 32 条的安全义务一点没少。

6. 审计日志——记访问，不记内容

记录谁在何时查询了系统、哪个模型响应。记录完整提示词内容要三思：内容日志是个人数据的第二份副本，自带保留与删除义务。记元数据或哈希往往足够。

7. 事件响应

LLM 主机上的个人数据泄露会触发向监管机构 72 小时通知的时钟。准备好运行手册：谁吊销凭证、谁评估影响范围、谁负责通知。没有别人的安全团队在盯着这台机器。

8. 透明度

隐私声明中必须写明 AI 系统及其处理位置。"数据从未离开我们的欧盟服务器"对这种架构是一句有力且真实的陈述——说出口，并保持它为真。

9. 自动化决策

如果输出会以纯自动化方式影响关于个人的重大决策，GDPR 的自动化决策保障条款适用。多数情况下解法是加一步人工复核——这同时也是模型错误的解法。

10. EU AI Act 部署者义务

AI Act 已全面生效：部署者承担透明度义务——在人们与 AI 生成内容交互时予以告知——以及事件报告和系统技术文档义务。

AI Act部署者义务指高风险AI系统的部署方（即使用该系统的组织）需承担的责任，区别于提供方（开发者）义务。部署者须确保人类监督、监控系统运行、保留自动生成日志至少6个月、在特定情形下进行基本权利影响评估，并向受影响人员告知系统使用情况。对多数自托管LLM的内部工具，若不属于高风险分类（如不用于就业、教育、关键基础设施等场景），义务主要是透明度告知和事件报告。但分类需自行判断：若LLM输出直接影响信贷、招聘或司法决策，则可能触发高风险义务，需在DPIA中一并评估。

自托管解决不了的问题

训练数据风险。 EDPB 将非法处理的训练数据与部署风险挂钩。用抓取的个人数据训练出的模型可能记住这些数据，作为部署者你继承了这份暴露面。要问清模型怎么训练的，并把答案写进 DPIA。
输出风险。 关于真实人物的幻觉个人数据，仍然是你处理过的个人数据。对重要输出做人工复核是合规控制，不只是质量措施。
许可证。 权重许可证各不相同，有些限制商用或再分发。"开放权重"是技术事实，不是法律事实。
成本。 云 API 按 token 计费，自托管按月计费再加你的时间。低流量下 API 通常更便宜。自托管的正当理由在合规与数据控制，不在账单——先拿自己的流量算一遍。

这周可以开始做的事

在欧盟主机上把 CPU 版 compose 跑起来，让一个真实工作流走一遍 8B 模型，然后基于你学到的东西写 DPIA。技术部分一个下午，文档部分一周。这个顺序——先有能跑的系统，再对着真实系统过清单——是让纸面工作保持诚实的关键。自托管本身不会让你合规，但它删掉了你答不上来的问题，只留下你本来就该回答的那些。

多源印证

上述结论在多个独立来源间互有交叉：dev.to 的企业 LLM 指南与 promptquorum.com 的本地 LLM 隐私宣言从架构角度支持"自托管消除第 44 条传输问题"这一判断；januscompliance.co.uk 与 vdf.ai 的合规清单则共同强调自托管不改变控制者身份、DPIA 与合法性基础仍需自行完成——这两点构成文章的核心论点。硬件与部署参数来自 bitdoze.com 的 Ollama 配置指南和 qovery.com 对 Hetzner GPU 机型的实测笔记；关于数据隐私框架上诉未决的时效性判断，则依赖原文所引的单一来源，读者宜以监管机构最新公告为准。