为什么 Dify 选择 On-Premise：数据主权、日本企业合规性和混合云战略

简介

在考虑企业人工智能平台的实施格式时，经常会用“SaaS 或 On-Premise”的二分法来讨论。然而，Dify 的设计理念两者都不是。 Dify 的最大特点是它保持了 SaaS 的便利性，同时提供本地/自托管作为“一流的实施路径”。

在本文中，我们从数据主权、日本特定法规、网络分离要求和混合云策略等角度探讨了 Dify 为何将本地部署置于其产品架构的核心。

1. Dify 的本地交付格式：公开事实

1.1 使用 Docker Compose 进行即时部署

Dify 的官方文档提供了 Docker Compose 作为 Self-Host 的第一步。单个 docker-compose.yml 将运行 API 服务器、worker、Web 前端、PostgreSQL、Redis 和 Weaviate（矢量 DB）。

# Dify Self-Host の最小構成イメージ
services:
  api:
    image: langgenius/dify-api:latest
    environment:
      - DB_HOST=db
      - REDIS_HOST=redis
      - VECTOR_STORE=weaviate
  web:
    image: langgenius/dify-web:latest
  worker:
    image: langgenius/dify-api:latest
    command: celery worker
  db:
    image: postgres:15
  redis:
    image: redis:7
  weaviate:
    image: semitechnologies/weaviate:latest

此配置表明 Dify 正在有意设计一个“不依赖于云供应商托管服务的独立架构”。

1.2 企业 Kubernetes/Helm 部署

企业版提供 Helm Chart 并将以下基础设施控制留给企业：

这种设计体现了清晰的分离理念：Dify 提供应用层，公司保留对基础设施的控制。

1.3 资源清单的含义

Enterprise Docs 上发布了资源清单，按照 Workspace 数量和并发用户数量列出了 CPU、内存和存储的推荐规格。这是 SaaS 供应商通常不会披露的信息，表明该设计是基于公司基础设施团队将自主执行容量规划的假设。

2. 数据主权：为什么“数据驻留在哪里”至关重要

2.1 企业人工智能处理的数据的性质

AI平台处理的数据与传统SaaS有着根本的不同：

• 输入知识库的内部文档：工作规则、合同模板、产品规格、客户响应手册
• Workflow处理的业务数据：客户信息、交易历史、财务数据
• LLM 提示和响应：包含敏感信息及其响应日志的问题。
• 嵌入向量：允许恢复原始文档的数字表示

graph TB
    subgraph "データ主権の境界"
        A[社内文書] --> B[Embedding 処理]
        B --> C[ベクトルDB]
        A --> D[全文インデックス]
        E[ユーザークエリ] --> F[LLM API]
        F --> G[レスポンスログ]
    end
    
    subgraph "SaaS モデルの場合"
        H[外部クラウド上に全データ]
        style H fill:#f99,stroke:#333
    end
    
    subgraph "On-Premise モデルの場合"
        I[企業ネットワーク内に全データ]
        style I fill:#9f9,stroke:#333
    end

2.2 数据主权问题的典型场景

3. 日本企业合规性和 On-Premise 的必要性

3.1 遵守个人信息保护法 (APPI)

令和 2 年（2020 年）改正の個人情報保護法（2022 年 4 月施行）将对企业人工智能产生以下直接影响：

• 第27条（第三者提供の制限）：向第三者（含 AI 平台运营者）提供个人数据时，原则上需事前取得本人同意。
• 第28条（外国にある第三者への提供の制限）：在海外存储或处理数据时的附加要求（包括对该外国数据保护制度的事前情報提供義務）。
• 第23条（安全管理措置）：对个人数据实施组织的・人的・物理的・技术的安全管理措施的义务。

⚠️ 诚实补充：选择 On-Premise 不必然意味着规避了第 27 条的“第三者提供“问题——只要 LLM API 调用仍发往外部（OpenAI / Anthropic 等），其本身就构成“第三者提供“，与 Dify 部署形态无关。On-Premise 真正解决的是 (a) 数据落地（不进入云端 SaaS 数据库 / 备份）+ (b) 第 28 条“外国にある第三者“风险（如选用日本国内 region 的 LLM 或本地模型）+ (c) 第 23 条物理 / 网络隔离要求。要彻底规避 LLM API 这条第 27 条路径，需配合本地推理（self-hosted Llama / DeepSeek 等）或国内 region 的 Provider（Azure OpenAI 日本东 / 西、Bedrock 东京 region 等）。

3.2 行业特定法规

3.3 与日本企业的决策过程保持一致

日本大型企业的IT实施具有独特的组织特征：

1. Ringi系统：需要信息系统部门、法务部门、合规部门依次批准。
2. 部门间权限划分：明确划分各部门可以访问的数据范围
3. 供应商管理：有义务审核分包商的安全管理措施
4. 长期稳定性要求：架构必须能够承受3-5年的运营计划。

On-Premise 降低了审批流程中的最大障碍，因为数据由公司控制。这是因为SaaS所需的“数据处理合同”、“安全管理措施的确认”和“第三方条款适用性的法律安排”将大大简化。

4.网络分离和封闭网络支持

4.1 日本企业典型网络配置

graph LR
    subgraph "社内ネットワーク"
        A[業務端末] --> B[社内プロキシ]
        B --> C[Dify On-Premise]
        C --> D[社内DB / ファイルサーバー]
        C --> E[社内ベクトルDB]
    end
    
    subgraph "DMZ"
        F[リバースプロキシ]
    end
    
    subgraph "外部"
        G[LLM API<br/>OpenAI / Azure / Anthropic]
    end
    
    C -->|"制御されたAPI通信のみ"| F
    F --> G
    
    style C fill:#69b,stroke:#333,color:#fff

许多日本公司认为内部系统不直接连接到互联网，并且仅允许通过代理进行有限通信的外部 API 调用。 Dify 的 On-Premise 允许您配置：

• 知识库/矢量数据库完全位于公司的封闭网络内
• 仅LLM API调用通过代理进行外部通信（也可以使用Azure OpenAI服务的私人端点）
• 用户访问日志和查询日志可以集成到内部 SIEM 中

4.2 支持完全封闭的网络（气隙）

制造设计部门和国防公司可能需要在没有任何互联网连接的情况下运行。 Dify的On-Premise+本地LLM（Ollama/vLLM等）组合也可以满足这个要求：

graph TB
    subgraph "完全閉域網"
        A[Dify On-Premise] --> B[Ollama / vLLM<br/>ローカル LLM]
        A --> C[Weaviate / pgvector<br/>ローカル Vector DB]
        A --> D[PostgreSQL<br/>ローカル DB]
        E[ユーザー端末] --> A
    end
    
    F[インターネット]
    F -.->|"接続なし"| A
    
    style F fill:#f99,stroke:#333

5. 混合云策略：SaaS 与 On-Premise 共存

5.1 分阶段部署模型

日本公司的实际 Dify 实施通常涉及以下步骤：

5.2 为什么 Dify 的架构能够实现混合性

Dify 的设计具有多项自然支持混合配置的功能：

1. 基于环境变量的配置管理：可以使用环境变量完成数据库连接目的地、存储后端、LLM提供者的切换。
2. 无状态API/Worker：可设计云与本地之间的水平扩展和负载平衡
3. Provider抽象层：同一个应用程序可以根据环境在Azure OpenAI（封闭网络）和OpenAI API（公共）之间切换
4. 知识库独立性：只需更改矢量DB的连接目的地即可控制知识的放置位置。

6. 本地操作的设计注意事项

6.1 运行负载和权衡

On-Premise 承担“责任”以换取“自由”：

6.2 推荐的架构模式

graph TB
    subgraph "本番環境 (Kubernetes)"
        direction TB
        LB[Ingress Controller / ALB]
        
        subgraph "Application Layer"
            API1[Dify API Pod x3]
            WEB1[Dify Web Pod x2]
            WK1[Dify Worker Pod x3]
        end
        
        subgraph "Data Layer"
            PG[(PostgreSQL<br/>Primary + Replica)]
            RD[(Redis Sentinel)]
            VDB[(Vector DB<br/>Weaviate Cluster)]
            S3[(Object Storage<br/>MinIO / S3)]
        end
    end
    
    LB --> API1
    LB --> WEB1
    API1 --> PG
    API1 --> RD
    API1 --> VDB
    WK1 --> PG
    WK1 --> RD
    WK1 --> S3

6.3 监控/可观察性

在On-Premise环境中，您需要自行设计以下监控项：

• 应用程序指标：API 延迟、工作队列长度、错误率
• 基础设施指标：CPU/内存使用情况、磁盘 I/O、网络带宽
• 业务指标：活跃用户数量、查询数量、知识库命中率
• 安全监控：身份验证失败、异常访问模式、数据导出操作

7. 与竞争产品的比较：本地支持的深度

Dify 的差异化在于“虽然是 OSS，但也提供 Enterprise Helm，并且包含基于 GUI 的管理界面”。框架类型（LangChain）很灵活，但没有 GUI，云原生类型（Bedrock/Azure）不支持本地部署。

8. 日本市场 On-Premise 的未来展望

8.1 将人工智能治理制度化

从2024年起，日本政府正在加速人工智能治理的讨论。未来，可能会形成以下法规：

• 澄清人工智能使用的数据位置要求
• AI输出的可解释性要求
• 保存人工智能系统审计追踪的义务

这些更严格的法规将鼓励人工智能平台在本地或私有云中运行。

8.2 本地LLM成熟

随着兼容日语的本地LLM（Llama系列、Qwen系列、国产LLM）性能的提高，在完全封闭的网络中运行Dify正在成为一种实用的选择。 Dify 的 Provider 抽象层旨在以低成本实现这些模型之间的切换。

总结

Dify 将 On-Premise 设计为“一流的部署路径”而不是“附加功能”，原因有以下三个：

1. 确保数据主权：企业人工智能处理的数据是敏感的，必须保留在公司的管理边界内。
2. 符合日本企业的合规要求：与个人信息保护法、行业法规、Ringi系统的一致性
3. 混合云策略的灵活性：提供从 PoC 到生产的分阶段部署路径

内部部署并不是一个“沉重”的选择。相反，它将企业人工智能纳入正式业务流程的先决条件。 Dify 可以说是一个将这个前提融入到其产品架构中的平台。

参考资料

-Deploy Dify with Docker Compose -Kubernetes - Dify Enterprise Docs -Resources Checklist - Dify Enterprise Docs -個人情報保護委員会 - 改正個人情報保護法 -FISC 安全対策基準