AWS 上构建多租户 LLM 分析系统：行级安全三层架构实践
PAR Technology 在 AWS 上构建了支持行级安全的多租户 LLM 分析系统，通过加密请求签名、语义验证和 Split-Plane SQL 三层架构，确保跨租户数据隔离。本文详解其设计思路与实现细节，对国内 SaaS 厂商构建安全 AI 分析工具有重要参考价值。
一句话看懂
PAR Technology 在 AWS 上构建了一个多租户 LLM 分析系统，通过三层安全架构（SigV4 签名、Bedrock 语义验证、Split-Plane SQL）强制行级数据隔离，即使 LLM 被攻破也能防止跨租户数据泄露。
详细发生了什么
PAR Technology 为餐饮行业提供技术方案，服务超过 300 家餐厅企业。他们构建了一个自然语言 text-to-SQL 分析 agent，让业务用户用英文提问即可获得数据答案。但核心挑战在于：不同用户（如加盟商 vs 品牌经理）对同一问题（如“上周总销售额”）需要返回不同数据范围，且必须严格隔离。
最初版本直接让 LLM 在 prompt 中加入用户业务 ID 来过滤数据，但 LLM 是非确定性的——即使连续正确一万次，也可能在下一秒遗漏过滤条件。为此，PAR 设计了三层安全架构：
- 加密请求签名：使用 AWS SigV4 对每个 API 请求签名，携带 Tenant ID、Business ID、Admin ID。
- 语义验证：在 Amazon Bedrock 上对 LLM 生成的 SQL 进行语义检查，确保查询范围不超出用户权限。
- 程序化数据隔离：通过 Split-Plane SQL 在数据库层面强制行级过滤，即使前两层被绕过，数据库仍会拒绝越权查询。
这三层独立运作，任何一层都能阻止数据泄露。系统基于 Amazon Bedrock（使用 Anthropic Claude Sonnet 4）和 Databricks 数据仓库构建。
中文圈视角
国内 SaaS 厂商（如餐饮、零售、金融行业）同样面临多租户数据隔离难题。许多团队依赖 LLM prompt 来限制数据范围，这存在根本性风险。PAR 的方案提供了可复用的架构参考：
- 平替方案：国内可用阿里云通义千问或百度文心作为 LLM，搭配 MaxCompute 或 ClickHouse 实现类似 Split-Plane SQL。
- 合规启示：数据出境和《个人信息保护法》要求严格的数据隔离，三层架构比纯 LLM 方案更易通过审计。
- 盲点：中文圈讨论 LLM 应用时多关注生成质量，较少深入安全架构。PAR 的“LLM 不可靠”论点值得国内团队重视。
不过，国内用户需注意：SigV4 签名依赖 AWS IAM，若迁移至国内云需替换为阿里云 RAM 签名或自建 token 系统。
几条值得记住的细节
- 系统服务超 300 家餐厅企业，租户层级为：租户（品牌集团）→ 业务（连锁品牌）→ 管理员（个人用户）。
- 每个 API 请求携带 Tenant ID、Business ID、Admin ID 三个标识，用于行级过滤。
- 三层架构独立运作：加密签名防篡改、语义验证防越权、Split-Plane SQL 防数据库层泄露。
- 使用 Amazon Bedrock 上的 Claude Sonnet 4（模型 ID: anthropic.claude-sonnet-4-20250514-v1:0）。
- 数据仓库采用 Databricks，加密存储和传输。
一句话总结
多租户 LLM 分析系统不能依赖 LLM 自身保证数据安全，必须从架构层面强制行级隔离。