围绕本地 LLM 与公共 AI API 的争论往往流于表面。
一方认为每家公司都应该在本地运行模型；另一方则认为企业级 AI API 已经足够安全，且操作起来要简便得多。
对于敏感的 Excel 数据，更好的答案其实更具务实性：应根据电子表格的敏感程度、安全流程的成熟度以及用户实际需要的工作流来匹配相应的架构。
公共 API、企业级 AI 服务、本地模型、私有 VPC 部署以及混合脱敏工作流，在不同的场景下都可能是正确的选择。
为什么 Excel 数据需要特殊保护
电子表格的价值往往被低估。
它们通常包含那些尚未进入受控 BI 系统的数据：
- 客户层面的收入
- 薪资与佣金
- 业务预测
- 预算
- 董事会报告数据
- 供应商条款
- 客服导出数据
- 税务记录
- 运营异常
- 个人身份信息 (PII)
当员工将这些文件上传到聊天机器人时，公司可能会失去对数据流向、保留时长、访问权限以及该行为是否合规的控制。
这种风险不仅是技术层面的，更是流程层面的。大多数电子表格的上传行为都发生在正常的常规数据治理路径之外。
五种主要方案
1. 公共聊天机器人
这是最简单的路径。用户打开聊天机器人，上传文件并请求分析。
对于公开数据或合成数据，这种方式没问题。但对于机密文件，除非组织已明确批准该工具和用例，否则风险极高。
其主要优势是速度，主要风险是数据泄露失控。
2. 公共 API
公共 API 为开发人员提供了比消费级聊天机器人更多的控制权。他们可以构建内部应用，限制发送的内容，并更仔细地管理提示词（Prompts）。
但数据仍然会离开公司的环境。供应商的数据使用、保留、日志记录和合规条款至关重要。
对于许多公司来说，在经过供应商审查并签署正确合同后，这种方案是可行的。但不应将其视为自动安全。
3. 企业级 AI 服务
企业级 AI 平台通常提供更强的隐私承诺、管理控制、加密、不用于训练的承诺、数据保留选项以及合规文档。
示例包括 OpenAI 的企业版、Microsoft Azure OpenAI、AWS Bedrock、Google Vertex AI、Anthropic 等提供的企业级服务。
对于既想要强大的模型质量，又不想运营自己的 GPU 基础设施的公司来说，这通常是最佳的折中方案。
权衡之处在于，即使在更强的企业级控制下，处理过程仍然发生在公司自身的服务器之外。
4. 本地 LLM
本地 LLM 运行在笔记本电脑、工作站、服务器或内部 GPU 集群上。
其主要优势是控制力。数据可以留在机器或网络内部。这对于原型设计、隐私敏感型实验或离线用例非常有用。
但其局限性也很明显：
- 模型质量可能低于前沿 API
- 环境搭建可能比较脆弱
- GPU 成本昂贵
- 除非自行构建，否则监控手段有限
- 访问控制和审计日志需自行负责
- “本地”并不自动等同于“合规”
5. 私有 VPC 或本地部署
这是本地 AI 的企业版。
模型运行在受控环境中，通常配备有身份验证、网络隔离、日志记录、存储和安全策略。团队可以开放内部 API 并将其连接到经过批准的应用程序。
对于高度敏感的电子表格工作流，这是最强大的路径，但它需要较高的运维成熟度。
务实的决策框架
首先将数据敏感度作为第一道过滤器。
| 电子表格类型 | 合理的 AI 路径 |
|---|---|
| 公开数据或示例 | 公共聊天机器人或 API |
| 内部但低风险数据 | 经批准的企业级 AI 服务 |
| 机密业务数据 | 具有合同约束的企业级 API、私有 VPC 或经批准的内部应用 |
| 受监管或高度敏感的数据 | 私有 VPC、本地部署、物理隔离或脱敏工作流 |
| 敏感度未知 | 在分类之前禁止上传 |
然后考虑运维问题：谁来维护系统？
如果公司没有能力运营 GPU、修补模型服务器漏洞、监控日志和评估输出，那么完全本地化的部署可能会带来新的风险。在这种情况下，具有强大控制力的企业级 AI 服务可能比无人管理的本地模型更安全。
本地化并不自动等同于安全
如果周边系统薄弱，本地模型仍然可能泄露或误处理数据。
常见的错误包括：
- 将上传的文件存储在未加密的文件夹中
- 在日志中记录包含敏感值的提示词
- 允许每个用户访问所有文件
- 允许生成的代码访问网络
- 未能及时修补宿主机的补丁
- 将输出结果复制到不受管理的工具中
- 使用来自不可信来源的模型或软件包
隐私保护是一种架构属性，而不仅仅取决于模型部署的位置。
公共 API 并不自动等同于不安全
反之亦然。
企业级 AI API 可以提供强大的控制。一些供应商声明，默认情况下不会使用商业或 API 客户的数据来训练模型。云供应商可能提供私有网络、IAM（身份与访问管理）、加密、审计日志和数据保留控制。
正确的提问方式应该是具体的：
- 哪个产品方案？
- 哪份合同？
- 哪种保留设置？
- 哪个区域？
- 哪些日志？
- 哪些用户？
- 哪些电子表格数据？
对于许多工作流来说，具有企业级控制的公共 API 是可以接受的。而随意的聊天机器人上传则可能不行。
理想的敏感 Excel 工作流是怎样的
对于敏感的电子表格分析，一个良好的工作流应该：
- 在分析前对数据进行分类
- 将文件保存在经批准的存储中
- 强制执行用户权限
- 使用确定性工具进行计算
- 仅向模型发送必要的上下文
- 防止工具产生出站泄露
- 引用来源行、工作表、公式或查询
- 记录提示词、工具使用、数据访问和输出
- 允许管理员控制数据保留
- 支持私有或企业批准的模型端点
这为团队提供了一个务实的平衡：既能利用 AI 的效用，又不会产生失控的“复制粘贴”行为。
匡优数言的定位
匡优数言是一个电子表格分析的工作流层。这意味着它可以构建在不同的模型选择之上。
对于风险承受能力较高的团队，模型端点可以是经批准的企业级 API。对于敏感部署，它可以是在客户基础设施中运行的私有 LLM。在这两种情况下，用户体验都应专注于电子表格任务：上传数据、提出问题、生成图表、审查证据，并通过 Excel 转仪表盘工作流 将 Excel 文件转化为仪表盘。
模型是可替换的，而受控的工作流才是持久的核心。这就是为什么这个决策通常属于更广泛的 AI 商业智能规划，而不仅仅是模型选择。
最终检查清单
在为 Excel 分析选择本地 LLM 或公共 API 之前，请回答以下问题：
- 工作簿中最敏感的字段是什么？
- 该工具是否被批准用于该数据类别？
- 供应商是否会利用提示词、文件或输出进行训练？
- 数据在哪里处理和保留？
- 是否可以使用脱敏样本代替？
- 用户是否需要行级或文件级权限？
- 计算是否以确定性的方式执行？
- 答案是否可审计？
- 谁负责维护模型和基础设施？
- 当模型出错时会发生什么？
最好的架构很少是出于意识形态的，而是那些在为用户提供真实分析帮助的同时，能与电子表格风险等级相匹配的架构。如果核心问题是供应商匹配，那么将熟悉的选项（如 Excel 中的 Copilot）与私有工作流工具进行对比也会有所帮助。
来源与延伸阅读
- OpenAI 企业隐私政策: https://openai.com/enterprise-privacy/
- AWS Bedrock 常见问题: https://aws.amazon.com/bedrock/faqs/
- Google Vertex AI 数据治理 / 零数据保留: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/vertex-ai-zero-data-retention
- vLLM OpenAI 兼容服务器: https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
- Ollama 库: https://ollama.com/library
