Prediction Guard 是 LLM 输出安全与合规检测平台，提供幻觉检测、有害内容过滤PII 脱敏和合规检查等能力。它作为 LLM 应用的安全层，确保 AI 输出符合企业合规要求，特别适用于金融、医疗和法律等受监管行业。

Prediction Guard

Prediction Guard 的核心参数与统计

Prediction Guard 是一个面向受监管企业的自托管 AI 控制平面（Control Plane），官方定位为"Govern AI Systems"——不是又一层 API 网关，而是将 AI 系统治理、安全策略Agent 编排与合规审计统一到单一平台。核心交付形态为企业级业务端应用（Type D），同时内嵌 Agent Builder（Agent Forge）和 MCP 连接能力。

项目	公开信息
产品定位	自托管 AI 控制平面（AI System Governance）
核心能力	AI 系统治理、安全策略Agent 编排、合规审计、内容安全检测
部署路径	自托管（On-Premises / Cloud / Air-Gapped）
平台形态	Admin Console + API + Agent Forge
API 兼容	OpenAI /chat/completions & /responses、Anthropic /messages
归属地	US（美国）
核心检测端点	/factuality、/toxicity、/pii、/injection、/embeddings
合规框架	NIST、OWASP、OMB 开箱即用
团队经验	累计 126 年 AI 与工程经验
社区渠道	Discord、X（Twitter）、LinkedIn、YouTube、Podcast

一句话简评：Prediction Guard 不是"又一个 AI 防火墙"，而是把 AI 系统治理、安全护栏Agent 构建与合规审计打包进一个自托管控制平面的企业级平台——它管的不是流量，是 AI 系统的"行为合规"。

Prediction Guard 的用户与市场认可

Prediction Guard 面向金融、医疗、国防与政府等受监管行业，其定位更接近"AI 治理基础设施"而非单一安全工具。

企业背书：官网公开的三则客户证言分别来自 SimWerx（国防决策支持）、Noblis（非营利科研机构）和 iBase-t（制造业 SaaS），覆盖国防、科研和工业制造三个高合规要求领域，说明其产品已进入实际生产部署而非 PoC 阶段。

社区与生态：官方运营 Discord 社区X/Twitter、LinkedIn、YouTube 以及 Practical AI FM 播客，表明团队在技术布道和社区反馈闭有上有持续投入。但 GitHub Stars、Forks 等开源社区指标未公开，其 API 的开放性以商业授权为主而非开源生态驱动。

竞争定位：与 Guardrails AI、NeMo Guardrails 等同属 AI 安全赛道，但 Prediction Guard 的差异化在于"自托管控制平面 + 完整 AI 系统治理"而非单点内容过滤。更直接的竞品可能包括 Azure AI Content Safety、AWS Bedrock Guardrails 等云平台内置方案。

Prediction Guard 的成本优势：自托管治理的 TCO 逻辑

Prediction Guard 的成本优势不来自 API 单价最低，而来自"用一个平台替代多个碎片化安全工具"的 TCO 压缩。

C 端/个人：官方首页提供免费体验入口（Get Started），但以 Demo 预约和商务沟通为主要转化路径，无公开自助注册即用的免费层。

API/开发者：API 按量计费，具体单价未在公开页面展示。但从其 API 文档可看出，输入和输出检测（factuality、toxicity、PII、injection）可逐项开关，意味着计费可能按检测维度组合叠加。

企业/私有化：官方宣称"4X TCO 降低"（提供验证白皮书），核心逻辑是用一个控制平面替代多个点状安全工具（内容过滤、幻觉检测PII 脱敏、合规审计Agent 编排等）的集成与运维成本。企业部署需商务确认，包含自托管基础设施成本、年订阅费与专业服务费。

成本维度	自建多工具组合	Prediction Guard 单一平台
工具数量	5-8 个独立安全/合规工具	1 个控制平面
集成开发	多 API 适配与维护	单一 OpenAI 兼容 API
合规对齐	手动跟踪 NIST/OWASP	内置策略模板
运维复杂度	多系统监控、日志聚合	统一审计与告警
隐性成本	跨工具工单流转、人工复核	内置 Agent 编排减少人工介入

隐性成本拆解：自托管意味着企业需承担 Kubernetes 集群或单节点二进制的基础设施费用，以及运维人力。但相比云上 API 按量付费的高并发成本，自托管在规模使用后有边际成本递减优势。官网公开的 4X TCO 降低说法建议在 PoC 阶段用自身流量数据验证，而非直接采信。

Prediction Guard 的主要功能

Prediction Guard 的功能围绕"Manage（管理）→ Govern（治理）→ Deploy（部署）→ Build（构建）"四层展开：

• AI 系统组合与管理（Manage）：将模型（私有多模型、外部云模型如 AWS Bedrock/Azure OpenAI/Anthropic）、MCP 服务器和应用连接组合为"主权 AI 系统"（Sovereign AI System），每个系统拥有独立的访问控制、审计与治理配置。
• 安全策略治理（Govern）：内置 NIST、OWASP、OMB 合规策略模板，支持对 AI 资产进行漏洞分析、生成 AI BOM（物料清单），审计和回滚系统变更，并通过 Webhook 与现有 SIEM 集成。
• 内容安全检测（Guardrails）：通过 API 的 input/output 参数提供事实性检测（/factuality）、有毒内容过滤（/toxicity）、PII 识别与替换（/pii）、提示注入拦截（/injection）、嵌入向量生成（/embeddings）。支持在 chat/completions 请求中通过 input.pii、input.block_prompt_injection、output.factuality、output.toxicity 等参数动态开启。
• Agent 无代码构建（Agent Forge）：提供可视化 Agent 构建器，支持模型选择、系统提示词配置MCP 工具集成、知识库（文档上传 + 向量检索）、权限管理（Admin/Builder/User 三层角色）和主题过滤。
• 多有境部署（Deploy）：支持 Kubernetes 集群部署、单节点二进制部署AWS/Azure/GCP 云部署以及完全离线的 Air-Gapped 部署。Admin Console 生成 scoped 安装命令，一键部署到目标有境。

Prediction Guard 的模型与版本演进

Prediction Guard 的产品迭代以控制平面功能和检测模型能力增强为主线，公开可核验的版本节点如下：

版本	时间	说明
1.0（launch）	~2024-03	产品初始上线，提供基础内容检测 API（factuality、toxicity、PII）
2.0（current）	~2026-01	升级为完整 AI 控制平面，新增 Agent Forge、MCP 集成、自托管 Admin Console、NIST/OWASP 合规策略

版本脉络补充：v1.0 到 v2.0 之间官方未披露中间版本信息。但从官网和文档站可观察到的重要里程碑包括：Agent Forge 的发布OpenAI/Anthropic API 兼容接入MCP Server 原生支持Air-Gapped 部署能力上线。完整的版本节点以官方发布日志为准。

Prediction Guard 的技术优势：控制平面治理 vs 点状检测

Prediction Guard 的技术路线与同类工具的核心差异在于"用控制平面替代碎片化检测"，其技术优势体现在三个层面：

机制 1：策略与运行时分离。治理策略在 Admin Console 中统一配置，模型推理时动态加载，无需修改应用代码。这意味着合规团队可以独立更新检测规则，而不依赖研发团队发布新版本。

机制 2：主权系统隔离。每个 AI System 拥有独立的模型组合API Key 权限、审计日志和策略配置。在需要为不同客户、部门或区域提供差异化合规配置的 MSP/MSSP 场景中，这种多租户粒度是必要的架构选择。

机制 3：检测与生成在同一个 API 调用中完成。通过 chat/completions 请求的 input 和 output 参数，开发者可以在一次调用中同时完成推理和检测，无需额外的后处理步骤。这比"调用 LLM → 获取结果 → 调用另一个安全 API 检测"的串行链路降低了一半的延迟和集成复杂度。

适用场景：这种架构最适合已有或计划建设 Kubernetes 基础设施、合规审计需要统一 dashboard、且不希望敏感数据离开自有网络的受监管企业。不适合只需要单点 API 内容过滤且无自托管需求的简单场景。

与替代方案的对比：

对比维度	Prediction Guard	Guardrails AI	自建正则+关键词
部署方式	自托管控制平面	Python SDK / 开源	应用内嵌
检测粒度	语义级 + 规则级	语义级	仅关键词/正则
合规框架	NIST/OWASP/OMB 内置	无内置	需自行映射
多模型管理	支持（私有多模型+外部云模型）	不涉及	不涉及
Agent 编排	内置 Agent Forge	不涉及	不涉及
审计与回滚	内置审计日志 + 变更回滚	不涉及	需自建

Prediction Guard 的使用方法

Prediction Guard 提供两种主要使用路径——通过 Admin Console 进行系统治理，以及通过 API 进行应用集成。

路径 1：自托管部署（适用于合规团队与平台工程团队）

1. 在 admin.predictionguard.com 创建 AI System（Quick Start 或 Custom 模式）
2. 选择部署有境：On-Premises（Kubernetes/单节点二进制）、Cloud（AWS/Azure/GCP）或 Air-Gapped
3. 在 Admin Console 点击 Deploy 生成 scoped 安装命令，在目标集群执行
4. 连接模型：接入私有模型、外部云模型（Azure Foundry、AWS Bedrock、OpenAI、Anthropic 等）或 Prediction Guard 托管模型
5. 配置治理策略：选择 NIST/OWASP/OMB 模板或自定义规则
6. 创建 API Key，供应用层调用

路径 2：API 集成（适用于开发者）

Prediction Guard 提供 OpenAI 兼容的 chat/completions API。以下是一个启用了完整检测参数的请求示例：

{
  "model": "gpt-oss-120b",
  "messages": [{"role": "user", "content": "请给出投资建议..."}],
  "temperature": 0.7,
  "input": {
    "block_prompt_injection": true,
    "pii": "replace",
    "pii_replace_method": "random"
  },
  "output": {
    "factuality": true,
    "toxicity": true
  }
}

路径 3：Agent Forge（适用于业务团队）

通过 Agent Forge 的可视化界面构建 AI Agent，无需编写代码。支持上传知识库文档、配置 MCP 工具连接、设置角色权限，构建完成后即可通过聊天界面或 API 调用使用。

工程踩坑指南（基于 Agent/MCP 工具实践经验）：

1. 检测阈值调优：factuality 和 toxicity 检测的默认阈值可能不适合所有场景。生产上线前建议用历史数据做小批量对照测试，找到误报率与漏报率的平衡点。过低的阈值会导致正常回答被频繁拦截，影响用户体验。
2. 多模型组合的响应一致性：当系统中混合使用私有模型和外部云模型时，同一检测策略在不同模型上的表现可能不一致（因为基础模型本身的安全对齐程度不同）。建议对高合规场景统一使用同一模型系列，或按模型分别调参。
3. 自托管运维水位：控制平面本身需要 Kubernetes 集群或等效基础设施支撑。在流量高峰时，控制平面的 API 处理能力可能成为瓶颈，建议提前配置 HPA（水平自动扩缩）并监控控制平面的资源使用。Air-Gapped 有境下的离线升级路径需提前规划。

Prediction Guard 的产品定价

Prediction Guard 未在公开页面展示标准化定价表，整体采用"demo → 商务沟通 → 合同"的企业销售模式。

• 免费体验：官网提供 demo 预约入口，无公开自助注册的免费层。PoC 阶段的免费额度与范围需在 demo 中确认。
• API 按量计费：具体单价未公开。推测计费维度包括检测类型（factuality / toxicity / PII / injection）和调用量。建议在 PoC 期间向销售获取详细价目表。
• 企业/私有化订阅：包含控制平面许可、自托管基础设施支持、优先技术支持和合规策略模板定制。价格与部署规模（模型数API 调用量Agent 数）相关，需商务确认。

定价策略以官方实时页面和销售沟通为准。采用前建议重点确认：年度订阅的调用量上限和超额计费方式、自托管的基础设施最低配置要求、以及商业层面是否存在数据审核/审计外部化条款。

Prediction Guard 的应用场景

Prediction Guard 的典型场景集中在"高合规要求 + 多模型混合 + 需要自托管"的交集区域：

• 受监管行业的 AI 客服与顾问系统：金融投顾、医疗预诊、法律咨询等场景中，AI 输出的准确性和合规性直接影响企业责任。Prediction Guard 在推理链路中嵌入 factuality 和 toxicity 检测，将高风险输出的漏报率降至可接受范围。量化推演：假设原来每条 AI 回答需人工审核，平均耗时 2 分钟；部署自动检测后，80% 的常规回答自动放行，仅 20% 标记需人工复核，人效可提升约 4 倍（从每人时 30 条到 150 条）。
• 国防与政府数据隔离部署：需要 Air-Gapped 或完全离线的有境，模型和数据不能离开自有网络。Prediction Guard 的自托管控制平面和离线部署包满足这一需求。落地提示：离线有境的模型更新和策略升级需要预置离线包，部署前应确认更新机制和版本兼容性。
• MSP/MSSP 多租户 AI 治理：为多个客户提供 AI 服务时，每个客户可能要求不同的合规标准（如 HIPAA vs GDPR）。Prediction Guard 的 Sovereign AI System 抽象允许为每个客户创建独立的系统配置，实现细粒度策略隔离。
• 企业内部知识库 Agent：通过 Agent Forge 构建面向 HR、IT 支持、合规查询的内部知识 Agent，利用 RAG 从企业文档中检索答案，并通过 PII 检测和主题过滤防止敏感信息泄露。量化推演：一线支持团队处理内部咨询的平均耗时从每单 15 分钟降至 3 分钟（AI 首答 + 人工确认），80% 的常规问题可完全自动化。

Prediction Guard 的适用人群

• 企业合规与安全团队：需要向监管机构证明 AI 系统的输出可控、可审计、可追溯。Prediction Guard 的预置 NIST/OWASP 合规策略和 AI BOM 生成能力是核心价值点。前置条件：团队需具备合规框架的理解能力和治理策略的定义权。
• 平台工程与 MLOps 团队：负责多模型、多有境的 AI 基础设施运维。控制平面的统一治理、变更回滚和 SIEM 集成降低了跨工具链的运维复杂度。前置条件：需要 Kubernetes 运维能力和自托管基础设施管理经验。
• AI 应用开发者：需要快速集成内容安全检测但又不想在多家安全 API 之间切换。OpenAI 兼容 API 和同一请求内完成检测的机制降低了集成本。前置条件：对检测延迟有容忍度（相比不检测的裸调用增加约 100-500ms）。
• 业务部门 Agent 构建者：非技术背景的业务专家可通过 Agent Forge 无代码构建专用 Agent。前置条件：需要企业已部署 Prediction Guard 控制平面，由 Admin 开通 Agent Forge 访问权限。

不适配边界：Prediction Guard 不适合以下场景——① 只需要单点内容安全 API、不需要自托管的个人开发者或小型团队（此时 Guardrails AI 或 Azure AI Content Safety 更轻量）；② 对端到端延迟有亚 200ms 要求的实时交互场景（控制平面的检测链路增加额外延迟）；③ 尚无 Kubernetes 基础设施或运维能力的企业（自托管成本高于预期收益）。

Prediction Guard 的总结与展望

Prediction Guard 的核心价值在于将 AI 系统治理从"多个碎片化安全工具的拼接"升级为"一个自托管控制平面的统一管理"。对于金融、医疗、国防等受监管行业，这种治理密度是刚需——合规不是可选项，而是业务准入证。其 Agent Forge 和 MCP 集成能力进一步扩展了平台从"检测"到"构建"的覆盖范围，使其在企业 AI 落地的链条中占据了更靠前的位置。

当前限制与不确定项：① 公开定价信息缺失，企业的真实 TCO 验证需要走完完整销售流程；② 检测准确率的具体指标（如 factuality 检测在特定领域上的 F1 分数）未公开，用户需在 PoC 中用自身数据验证；③ Agent Forge 目前仅支持 Admin Console 内使用，不提供独立 SDK 或 embedded 模式；④ 平台与主流 LLM 框架（LangChain、LlamaIndex）的原生集成文档尚不完善。

采购/采用风险评估：企业评估 Prediction Guard 时建议分三步走——先用 Demo 有境验证核心检测能力在实际业务数据上的准确率与延迟，然后在 1-2 条低风险业务链路上做 4-6 周 PoC 对比（有/无检测的漏报率和误报率），最后基于 PoC 数据评估规模化后的 TCO 并与自建方案对比。合同层面需重点确认：年度调用量承诺与超额费率、自托管有境的 SLA 覆盖范围、数据审计与合规报告的自定义能力。

限制与不适配场景

该工具在以下场景中存在使用限制：

场景适配边界 需要高度行业专业知识的任务、对输出格式有严格规范的场景、需要零错误的自动化流程可能效果不达预期。AI 输出应作为初稿或辅助参考，最终结果需人工核验。

技术限制 上下文长度有限、复杂推理准确性可能不足、免费版有使用额度。建议在正式采用前通过试用验证核心场景的可用性。

版本信息

• current ：当前版本。 （~2026-01）
• launch ：产品上线。 （~2024-03）