本地AI智能体业务工作流：GDPR与EU AI Act合规指南 2026

速查事实

• 架构： Ollama或vLLM + 工具调用模型 + 智能体运行时（Cline或Goose+MCP）+ 审计日志 + RAG存储，全部在控制者的基础设施上运行。
• 覆盖工作流： 文档摄入、邮件分流、会议摘要、合规报告、发票处理。
• 5个模板的EU AI Act分布： 4个有限风险，1个高风险（用于HR筛选时），0个禁止类。
• DPIA阈值： 高风险类必须；其余按第35条标准触发。涉及特殊类别数据的工作流，多数团队都应执行一次DPIA。
• 硬件配置： Gemma 4 27B和Qwen3 32B在Q4_K_M下需24 GB显存；GLM-5.1 32B和Llama 3.3 70B在完整上下文下推荐48 GB+。
• 审计日志保留： GDPR第30条处理记录要求是下限；行业规则（金融服务、医疗）会延长。多数企业环境的安全默认值为6年。
• 成本： API开支为零；硬件在20+用户团队中6–12个月即可与企业SaaS AI订阅成本持平。

本地AI智能体为业务团队提供什么

• 定义： 模型 + 工具表面（文件系统、数据库、邮件、日历、内部API）+ 每次写入的审批门 = 智能体。模型提议；智能体运行时执行；人工批准任何更改状态或离开网络的动作。
• 与自动化工具的区别。 n8n、Zapier和Make.com是确定性工作流——显式触发器、显式分支、显式动作。智能体是非确定性的：模型根据输入和会话状态决定调用哪个工具、用什么参数。路径固定时用自动化；路径因输入而变时用智能体。
• 与聊天助手的区别。 聊天助手回答问题；智能体执行动作。ChatGPT式的"总结这封邮件"返回文本；智能体读取收件箱、分类邮件、起草回复并排队等待批准。表面不同，风险画像不同。
• 为什么"本地"对业务工作流尤其重要： 数据驻留可证明（字节永不离开网络）、审计跟踪端到端（同一日志记录模型调用、工具调用和结果）、链中无第三方处理者。当架构本身消除了整类风险时，合规论证不言自明。
• 本地智能体在组织中的位置： 任何处理个人数据（GDPR）、员工数据（员工代表会）、第三方机密数据（保密协议、§203 StGB）或受监管业务数据（金融、医疗、法律）的工作流。本地智能体不会改善仅涉及公开数据的工作流——那里云智能体通常更快更便宜。
• 使其实际可行的协议层，请参阅通过MCP将Ollama连接到数据库和API：本地智能体设置2026。

5个业务工作流模板

• 1. 文档摄入与分类。 触发器：PDF或扫描件落入监控文件夹或邮箱。工具：文件系统（读）、OCR（必要时）、分类模型、数据库（写）。模型：Gemma 4 27B或Qwen3 32B用于工具调用和结构化输出。审批模式：读取和分类自动，文档涉及个人时路由步骤手动。AI Act等级：有限风险。DPIA：按触发条件。
• 2. 带回复草稿的邮件分流。 触发器：监控收件箱有新邮件。工具：IMAP/Graph API（只读）、分类模型、草稿存储（写）、通知。模型：分流用Llama 3.2 3B足够；草稿生成用Gemma 4 27B。审批模式：分类和草稿自动，发送（始终）手动。AI Act等级：有限风险。DPIA：按触发条件；如收件箱处理员工数据则强制。
• 3. 会议摘要与行动项提取。 触发器：转录文件落入存储（Whisper或供应商）。工具：文件系统（读）、摘要模型、提取模型、输出目标（通过API的Notion/Jira/内部wiki）。模型：Qwen3 32B用于一小时长转录的长上下文（128K）。审批模式：摘要自动，发布到外部系统的行动项手动。AI Act等级：有限风险；验证每个转录文件都有同意记录。
• 4. 合规报告生成。 触发器：定时（月度、季度）。工具：数据库（读）、报告模板存储、报告渲染器、审阅者通知。模型：GLM-5.1 32B或Llama 3.3 70B——长上下文、结构化输出、低幻觉。审批模式：数据提取自动，发布报告手动。AI Act等级：有限风险；验证底层数据源有文档化的合法依据。配合结构化输出与JSON模式以保持报告结构稳定。
• 5. 发票处理与校验。 触发器：发票落入财务收件箱或AP文件夹。工具：文件系统（读）、OCR、ERP集成（读取采购单和供应商）、异常队列（写）。模型：Gemma 4 27B用于工具调用；非标准布局发票用Qwen3 32B。审批模式：提取和采购单匹配自动，任何异常（不匹配、新供应商、大额）手动。AI Act等级：有限风险。DPIA：通常不触发。
• 5个模板的共同模式： 读取步骤自动批准；影响外部系统或个人权利的写入步骤手动批准。审计日志记录每个决策。

业务智能体的EU AI Act分类

• 有限风险（多数模板）： 透明度义务。收到AI生成邮件或摘要的用户必须知道AI参与了。消息中的明确标识 + 系统终端用户文档中的一行说明，通常即可满足。无需合规评估。
• 高风险（特定用例）： 完整合规评估、欧盟数据库注册、上市后监控，部分子类别还需公告机构。在业务团队中触及高风险的模式是HR筛选（CV排序、候选人评分）、信贷决策、福利资格判定和公共服务访问。法案附件III是操作清单。
• 禁止（不得部署）： 公共空间实时生物识别（执法有狭窄例外）、对自然人的社会信用评分、利用脆弱性的操纵技术、工作场所情绪识别（医疗/安全有有限例外）、基于画像的预测性警务。
• 5个模板的工作流→等级实用映射： 文档摄入（有限风险）、邮件分流（有限风险）、会议摘要（有限风险；验证同意）、合规报告（有限风险）、发票处理（有限风险）。5个基础模板均为有限风险；同一模板被改用于HR筛选或信贷决策，则因用途继承高风险义务。
• 提供者vs部署者区分很重要。 如果您把模型构建到出售给他人的产品中，您是提供者（义务更多）。如果您为自己运营该系统，您是部署者（义务较少，但仍真实）。仅内部的本地智能体通常使您成为部署者。
• 任何新工作流的行动项： 部署批准前进行分类。分类是单一决定（有限/高/禁止），附书面理由，由DPO或合规负责人签字，保存在AI系统的技术档案中。

智能体工作流的GDPR控制

• 1. 合法依据（第6条）。 部署前文档化适用的依据——同意、合同、法律义务、合法利益、生命利益或公共任务。多数业务智能体工作流以合同（员工/客户关系）或合法利益（附文档化的权衡测试）运行。特殊类别数据（健康、生物识别、政治观点）需要在第6条依据上叠加第9条条件。
• 2. 数据最小化（第5(1)(c)条）。 智能体只能看到工作流所需的个人数据。实际含义：在RAG层而非模型层进行分块和过滤。仅相关一节时，避免把整份文档流式输入对话。任务完成后，避免保留含个人数据的中间提示词。
• 3. 目的限制（第5(1)(b)条）。 未经重新评估，智能体不得跨任务被重新利用。批准用于发票处理的工作流不能悄悄吸收员工绩效评审职能——那是新目的、新合法依据、新DPIA决定。
• 4. 处理安全性（第32条）。 静态加密、工作空间访问控制、不可变审计日志，以及包含"模型产生了不该产生的输出"的事件响应计划。本地架构覆盖了很多，但不要假设它覆盖一切。
• 5. 审计日志。 每个智能体动作的最小日志字段：时间戳、用户/发起者、模型标识与版本、输入哈希、工具调用与参数、输出哈希、审批者（手动批准时）。Append-only存储；完整性保护（哈希链或签名日志行）。
• 6. DPIA（第35条）。 工作流涉及对个人数据的系统性处理且具有重大影响、大规模特殊类别数据，或在AI Act下属高风险时为强制。其余按触发条件。DPIA记录控制、剩余风险和DPO签字。
• 本架构所基于的数据侧架构，请参阅本地RAG用于私密业务数据——RAG控制供给同一审计管道。
• 叠加在其上的提示词与输出控制，请参阅生产环境的提示词治理和提示词注入与安全。

德国特性：员工代表会共同决定与§203 StGB

• 员工代表会共同决定（BetrVG §87(1) Nr. 6）。 任何监督员工行为或绩效的技术系统都触发共同决定。德国劳动法院对"监督"的解释很宽泛——分类员工邮件或总结员工会议的智能体即属此类。员工代表会必须在设计阶段参与，而非部署后。漏掉这一步使智能体落地在事后被法庭撤销过。
• 实际含义： 部署任何处理员工数据的工作流——即便被动、即便直接输出对员工本人有利——之前先与员工代表会接触。共识（Betriebsvereinbarung）成为系统技术档案的一部分。多数员工代表会在早期参与时表现建设性；几乎没有在晚期参与时仍然建设性的。
• §203 StGB职业保密。 律师、医生、审计师、税务顾问及若干其他职业对客户信息的未经授权披露承担刑事责任。"助手"例外（§203(3)）覆盖内部员工，但不自动覆盖外部服务提供商。云LLM是外部服务提供商；这是受§203约束的事务所转向本地技术栈的法律核心。
• 实际含义： 对受§203约束的任何职业，纯本地架构不是偏好而是工作流被允许存在的前提。与智能体供应商（若有）的合同必须包含§203合规条款；技术档案必须记录无任何客户数据离开事务所基础设施。
• 奥地利与瑞士： 奥地利紧密镜像§203（StGB §121）；瑞士保密义务（StGB CH第321条）甚至更宽泛。架构结论一致——纯本地，敏感职业数据零例外。
• 同一控制者下的数据侧合规图景，请参阅本地RAG用于私密业务数据——RAG与智能体技术栈共享审计日志和访问控制层。

为业务智能体选择合适的模型

• **Gemma 4 27B（gemma4:27b）。** 2026年5月最佳通用工具调用模型。在16 GB统一内存或24 GB显存（Q4_K_M）下运行。在文档摄入、邮件分流和发票处理上可靠。链式工具调用略保守——很适合业务工作流，因为每步本就有显式批准。
• **GLM-5.1 32B（glm5:32b）。** 默认128K上下文。工具调用可靠性强。输入较长时（合规报告、一小时会议转录）的最佳选择。完整上下文需24 GB+显存（Q4_K_M）。
• **Qwen3 32B（qwen3:32b）。** 各方面均衡，多步规划下非常可靠。Gemma 4过于保守时的良好回退。默认32K上下文；适合多数业务任务。
• **Llama 3.3 70B（llama3.3:70b）。** 最高上限，最重硬件。Q4_K_M需48 GB+显存或64 GB统一内存。可靠性比速度更重要的合规报告和异常处理使用。
• **Llama 3.2 3B（llama3.2:3b）。** 大批量分流的轻量选择。8 GB显存即可舒适运行。"是客户支持/销售/垃圾邮件"够用；起草回复不够。起草步骤需配合27B+模型。
• Mistral Large。 适合纯本地过度而美国云不可行的混合配置的欧盟托管替代。通过Mistral的欧盟端点+签订DPA运行；数据仍在欧盟司法管辖。
• 工具调用应避免： 生产工作中的7B以下模型、未经显式工具调用训练的通用模型，以及小尺寸端比Q4_K_M更激进的量化。症状是工具调用畸形、参数幻觉、智能体循环停滞。
• 正面对比数据请参阅2026年最佳本地工具调用模型。同一组模型的显存与硬件配置请参阅2026本地LLM硬件指南。

业务用智能体技术栈对比

• 选择Cline + Ollama 如果团队以开发者为主，工作流落在VS Code内。安装阻力最小，到工作智能体最快。
• 选择Goose + MCP 如果工作流在无界面服务器（计划合规报告、文件夹监听摄入器）上运行，没有IDE。
• 选择n8n + Ollama 如果工作流是确定性形态，含一两个模型步骤。n8n的人工介入节点提供审批门，无需自定义UI。
• 仅在工作流形态确实与上述不兼容时选择自定义LangGraph。 构建工作量真实；审计跟踪和审批门代码归您。
• 这些技术栈的诚实可靠性对比，请参阅2026本地AI智能体：实际有效的（与仍会失败的）。

欧盟业务工作流部署本地智能体的常见错误

• 错误1：未做DPIA即部署。 任何涉及特殊类别数据或对人作出决定的工作流都需要DPIA。DPIA很短——多数智能体工作流4–8页——但强制，且是监管机构最先要求的。部署之前写，不是之后。
• 错误2：机密文档使用云连接的智能体。 如果智能体运行时、审计日志或嵌入存储位于他人云中，本地模型不够。架构是端到端的；链中一个云依赖就破坏纯本地论证。
• 错误3：写入或发送动作没有审批门。 智能体读取、分类、起草、发送。发送步骤是人类必须每次批准的步骤，不论模型过去多可靠。自动发送智能体是监管机构得知您的方式。
• 错误4：个人数据与业务数据混入同一工作空间。 智能体的工作目录和向量存储应按工作流划分作用域，而非共享。交叉污染违反目的限制；恢复成本高。
• 错误5：跳过审计日志。 "我们可以从模型对话历史重建"不是审计日志。Append-only、哈希链、按相关保留期保存、可被DSAR处理者查询——这是基线。

参考资料

• EU AI Act合并文本（artificialintelligenceact.eu） — 法规的官方导向聚合；附件III是操作的高风险清单。
• GDPR完整文本（gdpr-info.eu） — 第5、6、25、32、35条对智能体设计具有操作意义。
• NIST AI风险管理框架 — 非欧盟、不强制，但GOVERN / MAP / MEASURE / MANAGE的结构是有用的审计准备清单。
• EDPB 03/2018指南：自动化个体决策 — 对任何对个人作出决定的工作流具有操作意义；GDPR第22条与AI Act下均关键。
• 全国人大《数据安全法》（2021） — 中国数据分类分级、本地化与跨境传输的核心规则；与本地AI智能体架构高度契合。

常见问题

相关阅读

• 本地RAG用于私密业务数据 — 供给同一审计管道的GDPR合规数据侧架构。
• 通过MCP将Ollama连接到数据库和API：本地智能体设置2026 — 文件系统、数据库、浏览器和GitHub工具的协议层。
• 2026本地AI智能体：实际有效的（与仍会失败的） — 上述4个推荐运行时的诚实可靠性对比。
• 用本地AI智能体替代Zapier — 智能体光谱确定性形态端的n8n + Ollama工作流模板。
• 2026年最佳本地工具调用模型 — 本指南推荐模型的对比基准。
• 本地LLM安全与隐私清单 — 运行这些工作流的相同硬件的控制层。