合规 · SOC 2 · 审计 · 快照 2026-09-28
Jev 有 SOC 2 认证吗？诚实现状与采购评审清单
对「Jev 与 SOC 2」的直接回答——截至 2026 年 10 月没有公开报告——并列出法律文件实际覆盖的内容、信任服务准则映射，以及采购前应执行的供应商评审清单。
TL;DR
没有。截至对 TypeSafe 法律文件的 2026-09-28 快照，Jev 没有公开的 SOC 2（Type I 或 Type II）报告，也没有 ISO 27001 证书。实际存在的是合同层面：带 SCC 的 DPA、72 小时泄露通知条款、带 15 天异议窗口的子处理者清单、年度安全审计、「不训练」承诺，以及可申请的企业级零数据保留。所以：执行下方采购清单，自建单决策审计证据，若数据面控制不可妥协，就自托管线协议兼容的替代品。
事实快照 2026-09-28（与本站数据隐私指南共享）：开发者文档索引中没有任何安全或合规页面；法律索引、DPA 与隐私政策均已直接通读。本页将公开的 AICPA 信任服务准则映射到该记录上——属于工程视角，不构成合规结论，也不构成法律意见。信任页面会变动：依赖前请自行核验 trust.typesafe.ai。
Jev 有 SOC 2 吗？直接回答
采购真正在问的问题，用文件而不是营销话术回答。
已公布——与审计相关的记录
- 有实质内容的 DPA：欧盟 SCC（模块 2，你作为处理者时加模块 3）、英国附录、「72 小时内」泄露通知、安全审计「不超过每 12 个月一次」。
- trust.typesafe.ai/subprocessors 的子处理者清单，带 15 天异议窗口——签约日存档，并把窗口写进日历。
- 隐私政策中的不训练承诺：「我们不会用你的提示词或其他输入训练或微调任何人工智能或机器学习模型。」
- 企业级零数据保留（ZDR），法律索引本身公示，联系 sales@typesafe.ai。
任何官方渠道均未公布
- 没有任何类型的 SOC 2 报告——你的供应商风险档案里没有东西可附。
- 没有 ISO 27001 证书，法律文件中也没有任何认证声明。
- 没有审计范围说明、审计师名称、桥接函——根本没有可桥接的对象。
- 托管端点没有公开的 SLA、加密规格或渗透测试摘要。
采购方应该做什么
- 直接邮件 sales@typesafe.ai 索取当前审计或认证路线图——然后把每一条你打算依赖的答复写进签署的 DPA。
- 自行核验 trust.typesafe.ai 今天展示的内容；我们的快照是 2026-09-28，信任页面会变动。
- 自建证据：记录每一次生产决策（下方的记录 schema），让审计师抽样你的日志，而不是一份你拿不出的供应商 PDF。
- 如果你的监管或客户合同要求认证供应商，把托管 Jev 按「补偿性控制」路径处理——或者自托管数据面。
SOC 2 准则对 Jev 记录的映射
五大信任服务准则族，逐条对照采购方真正能指到的证据——只算公开文件与已公布合同。
| 准则族 | 记录里有什么 | 状态 |
|---|---|---|
| Security (common criteria) | 仅有合同层面的实质承诺：DPA 写明安全审计「不超过每 12 个月一次」、子处理者清单带 15 天异议窗口、数据泄露「72 小时内」通知。审计报告本身并未公开。 | 合同层 |
| Availability | 在我们读到的文档中没有出现：托管端点没有公开的 SLA、可用性目标或状态页承诺。这是官方记录给得最少的一族。 | 沉默 |
| Processing integrity | API 契约本身就是证据：单发请求返回带概率分布、置信度与 token 用量的类型化答案——不存在能在你与决策之间「编造」的生成环节。每个版本的确定性是文档化行为，不是认证过的流程。 | 有文档 |
| Confidentiality | 隐私政策承诺绝不用你的提示与输入训练模型；企业级零数据保留（ZDR）已在法律索引公布。加密细节、密钥管理与访问控制未公开。 | 合同层 |
| Privacy | DPA 载有欧盟 SCC（模块 2，你作为处理者时加模块 3）与英国附录、子处理者清单，保留期为「必要期限内」；隐私政策披露国际访客数据传输至美国。政策中没有 GDPR 数据主体权利章节。 | 合同层 |
工程视角，不构成合规结论：合同条款是流程存在的证据，不证明控制有效运行；「有文档」指 API 参考描述了该行为，不代表审计师测试过。本映射针对 TypeSafe 托管端点；开源替代品各有自己的（通常更弱的）记录——laya.studio 的自有 FAQ 就写明「目前没有任何正式认证（如 ISO 27001）」。
为你的决策日志 schema 落地——清单里要求供应商做到的那件事，先自己做出来为什么决策模型比聊天助手更好审计
在认证问题悬而未决时，你可以向风险委员会陈述的「审计暴露面」论证。
聊天 LLM 把你的提示词变成生成的文本，于是每个审计问题都继承了生成的失败模式：它说了什么、为什么、漏了什么？Jev 调用没有可审计的生成环节——响应是类型化答案，带概率分布、置信度与 token 用量，判定标准是你在请求里亲自定义的 criteria。
请求暴露面小且完全可读：model、state、questions。你命名的 question key 被文档明确为「不发送给底层模型、不用于推理」，内部词表留在你这一侧边界内。没有会话或对话对象——每次调用相互独立，这让单决策日志天然成立，而不是事后补丁。
所以诚实的立场是：架构让证据变得便宜，认证让证据变成别人的工作。第二件事改变之前，先把第一件事做满。
// One record per production decision — the evidence you own
{
"ts": "2026-10-31T09:14:22.481Z",
"decision_id": "dec_01JA8...",
"model": "jev-latest",
"endpoint": "https://api.typesafe.ai/v1/evaluate",
"state_digest": "sha256:9f2c…", // hash of the input, not the input
"question": "route", // your key — not model-facing
"answer": "billing",
"probabilities": { "billing": 0.94, "technical": 0.05, "account": 0.01 },
"confidence": 0.92,
"latency_ms": 147,
"usage": { "input_tokens": 212, "output_tokens": 84 },
"policy": { "threshold": 0.80, "on_low": "human_review" },
"outcome": "auto|escalated" // filled by your gateway afterwards
}每次生产决策写一条 JSON 记录，由你的网关落笔：state 存哈希不存原文，保留当时的门控策略，补记结果路径（自动 vs 升级人工）。半年的这种日志，回答「这个系统如何运作」比任何 Type I 报告都有说服力。完整 schema 与保留策略见决策审计日志 Recipe。
类型化决策的行为为何与生成文本不同供应商评审清单
Jev 接触生产数据前要完成的八项检查——大多数几分钟，其中两项需要发一封邮件。
通读三份法律文件（法律索引、DPA、隐私政策）——它们很短，而且就是全部记录。
邮件 sales@typesafe.ai 询问当前认证状态与路线图；把答复连同日期一起归档。
索取安全白皮书或架构概览；如果没有，这本身就是一条发现。
若你的数据不可被保留，把 ZDR 落成书面——法律索引公示了它，但约束力必须来自签署的 DPA。
在签约日存档 trust.typesafe.ai/subprocessors，并把 15 天异议窗口写进日历。
确认泄露通知时限（「72 小时内」）以及你这一侧的通知接收人。
锁定生产环境的模型版本并写进审计日志——确定性主张按版本成立。
提前决定退路：下个季度采购若否决托管 Jev，这个功能怎么办？（通常的答案是自托管替代品。）
第 1、5、6、7 项今天就能凭公开文件核验；第 2、3、4 项是两封邮件和它们的回复；第 8 项是产品决策，不是合规决策。
在依赖之前，亲手验证 API 契约不必等待、今天就能上线的补偿性控制
四项能把「缺报告」留下的缺口收窄的控制——全部在你手里，不在供应商手里。
数据面自托管
当客户合同要求数据面必须有认证供应商时，线协议兼容的开源替代（Laya、Kev、JevK5 等）保留协议本身，把举证责任移到你可控的基础设施。切换前先了解准确率差距。
顺序有讲究：先脱敏与留痕（任何场景都用得上），再闸门驻留，最后才考虑移动数据面——开源模型在独立基准上仍落后托管模型。
当数据面控制不可妥协时：自托管矩阵采购方真正会问的 SOC 2 问题
Jev 有 SOC 2 认证吗？
截至 TypeSafe 法律文件的 2026-09-28 快照：没有公布。没有 SOC 2 Type I 或 Type II 报告，没有 ISO 27001 证书，法律索引、DPA、隐私政策中也没有任何认证声明。实际存在的审计相关实质在合同层：SCC、72 小时泄露通知、年度安全审计、子处理者清单、企业级 ZDR。向 sales@typesafe.ai 询问最新状态——并亲自核验 trust.typesafe.ai，信任页面会变动。
如果公司供应商政策要求 SOC 2，还能用 Jev 吗？
取决于政策是否有「补偿性控制」通道。多数供应商风险计划接受：合同保障（DPA 给了你真实的条款）、自建审计日志（单决策记录）、数据最小化，以及成文的退路。如果政策直接强制认证，托管 Jev 今天过不了这道门——自托管替代品一节是现实选项，或者等 TypeSafe 路线图的答复。
SOC 2 和 ISO 27001 是一回事吗？
不是。SOC 2 是 AICPA 对服务组织控制的鉴证报告，分期间型（Type II）与时点型（Type I）；ISO 27001 是可认证的信息安全管理体系国际标准。采购方常常两者接受其一——但 Jev 两个都没公布，所以这里的重点不是区别，而是路线图。
Jev 架构让哪些 SOC 2 证据更容易收集？
单决策证据：带概率分布、置信度与 token 用量的类型化答案，判定标准是你自己定义的 criteria。加上你自己的日志（时间戳、state 哈希、question key、答案、置信度、策略阈值、结果路径），几个月后仍可复原任意一次生产决策。无生成响应意味着审计访谈里没有需要解释的自由文本行为。
企业级零数据保留（ZDR）能替代 SOC 2 吗？
不能——两者回答不同的问题。ZDR 约束的是供应商在处理之后保留什么；SOC 2 报告的是控制是否在一段时间内有效运行。两个都想要，而 ZDR 是今天就能通过 sales@typesafe.ai 落成书面的那个。让它写进签署的 DPA，而不是只停在落地页。
开源 Jev 替代品有认证吗？
普遍没有——其中一家自己就说了：laya.studio 的 FAQ 写明「目前没有任何正式认证（如 ISO 27001）」。自托管改变的是责任人（变成你），而不是证书是否存在。团队自托管是为了数据面控制，不是为了合规文书；独立基准上的准确率差距（最佳开源 ≈0.704 对托管 0.966）是你接受的代价。
TypeSafe 会拿认证吗？我该等吗？
我们不知道——我们读到的文件里没有公布任何路线图，这正是清单让你去问并归档答复的原因。我们的观点：本页的控制措施（脱敏、留痕、闸门、退路）无论路线图如何都值得上线，因为 GDPR 第 22 条与 DPIA 义务没有任何证书能替你履行。