隐私专题 · 数据流与合规 · 2026-09-28 核对

Jev 数据隐私:官方记录说了什么,以及如何少发数据

一次 Jev 调用发送你的 state、返回类型化决策。TypeSafe 到底写明了哪些保留与数据驻留条款、又把什么留给了合同——外加今天就能上线的 PII 脱敏中间件。

速查直答

Jev 的开发者文档没有发布任何隐私或数据驻留页面;真正管事的是法律文件:一份 DPA(SCCs、子处理者清单、72 小时泄露通报)、一份承诺从不用你的提示词训练的隐私政策,以及可申请的企业版零数据保留。保留期限是「必要时」——没有数字。所以:发送前先脱敏(见下文 PII 中间件),把保留承诺写进签署的 DPA,并把合规当作你自己的流程——Jev 的答案是人工路径后面的辅助,不是自动化裁决。

事实快照 2026-09-28:开发者文档索引(docs.typesafe.ai/llms.txt)中没有任何隐私、安全或数据驻留页面;HTTP 参考、System One 概念页与三份法律文件(DPA、隐私政策、主客户协议)均直接核对过原文。laya.studio 的说法均为该公司自己的营销口径,本站未验证。本页内容不构成法律意见。

一次 Jev 调用到底发送了什么

这个 API 的隐私暴露面就是请求体——而请求体完全由你来组装。

请求字段承载什么隐私解读
statestring | object | array——待评测的内容:文本、聊天记录或应用状态。整个调用的隐私暴露面就在这里。放进去什么,什么就离开你的边界;文档没有描述任何自动字段剥离——最小化必须在请求之前、由你自己完成。
model模型 ID,如 "jev-latest"。不属于个人数据。
questions由你命名的映射。每个 question 声明类型(noul / choice / score)、instructions 与 criteria——choice 单题最多 255 个选项。问题文案是你写的——criteria 标签同样是内容。写成「账单——sarah.miller@acmecorp.com」这种标签,泄漏就发生在请求里;那里只放类别,绝不放个案细节。
question keysquestions 映射的键名(如 "route")——答案会以相同的键返回。文档明确:键名不进模型——"is not sent to the underlying model and is not used in inference."
Authorization headerBearer API 密钥。是凭证,不是内容。它只为调用鉴权——放服务端、泄漏即轮换,与所有 API 密钥的规矩相同。

依据 HTTP 参考。响应会按你的问题键名返回答案——choice 或 score 附概率分布与置信度、noul 为 0–1 数值——外加一个上报 input_tokens 与 output_tokens 的 usage 对象。面向模型的内容全在上面的两个字段里;键名则被文档明确为不进模型。

一次 Jev 调用 vs 一轮对话式 LLM:结构性差异

维度一次 Jev 调用一轮对话式 LLM
Request一次自包含的调用:state + questions。文档化的请求里没有会话或对话对象——上下文完全由你发送的内容构成。一场对话:轮次在会话里累积,每一轮都把先前的上下文重新发送给服务商。
Response每个 question 一个类型化答案:选中的选项或分值、它的概率分布,以及由此导出的置信度——"typed decisions and probabilities rather than generated text"。逐个 token 生成文本,直到触发停止条件——从你的提示词里写出的新散文。
What that means for privacy请求即全部暴露面:缩小 state,就缩小了暴露。没有任何答案文本从你的数据里生成,也没有为了让对话延续而必须累积的东西。服务商看到你的上下文并返回衍生的散文;会话特性可能按各产品自己的数据控制条款在服务商侧保留会话上下文。
看清一次请求到底发了什么——每个端点的可运行示例

官方记录:有什么,没什么

采购对话的诚实基线:开发者文档只字未提,法律文件并不沉默。

已文档化——可直接引用

  • 一份法律索引——docs.typesafe.ai/legal.md——链接三份文件:数据处理协议(DPA,索引描述为 "how we process customer data on your behalf, including data retention")、隐私政策与主客户协议(MCA)。
  • 隐私政策中的不训练承诺:"We will not train or fine tune any artificial intelligence or machine learning models on your prompts or other Input."
  • 一份有实质内容的 DPA:跨境传输适用欧盟 SCCs(Module 2,你作为处理者时另加 Module 3)与英国附录;子处理者清单在 trust.typesafe.ai/subprocessors,新子处理者有 15 天异议窗口;泄露通报 "within 72 hours";安全审计 "no more than once every 12 months";管辖法为爱尔兰法——瑞士争议交瑞士法院。
  • 企业版零数据保留(ZDR)选项,就写在法律索引上,联系邮箱 sales@typesafe.ai。

官方任何地方都没写

  • 开发者文档索引里不存在任何隐私、安全或数据驻留页面——2026-09-28 对照 docs.typesafe.ai/llms.txt 核查。
  • 没有保留期限数字:DPA 只说数据保留 "for as long as necessary taking into account the purpose of the Processing"——是原则,不是期限。
  • 没有区域清单、没有驻留开关、没有数据流图;隐私政策写明国际访客的数据会 "to the U.S. for storage and processing"。
  • 这些文件里没有公布的认证(SOC 2、ISO 27001),隐私政策也没有 GDPR 数据主体权利章节。DPA 把细节指向 trust.typesafe.ai——依赖之前先核实它现在展示了什么。

采购方实际该做的

  • 采购前把三份法律文件从头到尾读完——它们不长,而且它们才是真正的记录。
  • 给 sales@typesafe.ai 发邮件谈 ZDR 与安全白皮书,并把你依赖的每一个答案写进签署的 DPA。
  • 在签约日给 trust.typesafe.ai/subprocessors 存快照,并把新子处理者的 15 天异议窗口记进日历。
  • 在保留期限写进合同之前,按「请求体可能被保留」来设计——这正是下一节中间件的用途。
打开 TypeSafe 法律索引(docs.typesafe.ai/legal.md)
数据流一节所概括的端点与协议全貌

PII 最小化:让载荷出门之前先瘦身

你完全可控的那一个抓手,也是本页的核心工程模式。

state 字符串是唯一要紧的暴露面,而它完全由你控制。分类式问题——这张工单进哪个队列、这条回复打几分、这笔交易要不要标记——依据的是文本说了什么,而不是谁说的:账单队列由「重复扣费」决定,与 sarah.miller@acmecorp.com 无关。脱敏空间就在这道缝隙里:调用前剥掉直接标识符,决策就没有任何个人信息可泄漏。

两个细节让它严谨而非装样子。第一,需要关联的地方用假名化而不是删除:客户 ID 的加盐哈希让你自己的分析仍然可连,标识符本身却从未出门。第二,记住 API 参考里那个文档化的分工——你的问题键名不进模型,但 state 和你写的 criteria 文案会。类别放 criteria,个案内容放 state,其余什么都别放。

脱敏前——标识符在途
// BEFORE — the whole ticket, identifiers included
{
  "model": "jev-latest",
  "state": "Ticket #4821 from sarah.miller@acmecorp.com
    (card on file 4024 0071 1748 2930):
    'I was charged twice for my September subscription
    and I want a refund now.'",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Route this support ticket to the right queue",
      "criteria": {
        "billing": "Payment, refunds, duplicate charges",
        "technical": "Bugs, errors, outages",
        "account": "Login, access, account changes"
      }
    }
  }
}
脱敏后——同样的决策,更少的暴露
// AFTER — same decision surface, zero direct identifiers
{
  "model": "jev-latest",
  "state": "Support ticket: customer reports a duplicate
    charge for the September subscription and requests
    a refund.",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Route this support ticket to the right queue",
      "criteria": {
        "billing": "Payment, refunds, duplicate charges",
        "technical": "Bugs, errors, outages",
        "account": "Login, access, account changes"
      }
    }
  }
}

路由决策分辨不出区别:两个载荷在问同一个语义问题。邮箱、卡号、工单号没有为决策贡献任何东西——它们只是白白增加了你的合规负担。

TypeScript 里最小化 state

typescript
typescript
// lib/pii-minimize.ts — redact direct identifiers before the Jev call.
// A routing decision keys off what the ticket SAYS, not who said it:
// queue "billing" does not need a name, an email, or a card number.

const PATTERNS: [RegExp, string][] = [
  [/[\w.+-]+@[\w-]+\.[\w.]+/g, '[email]'],
  [/\b(?:\d[ -]*?){13,16}\b/g, '[card]'],
  [/\+?\d[\d\s().-]{7,}\d/g, '[phone]'],
];

// Salted FNV-1a: the same customer id maps to the same stable token, so
// decisions stay correlatable in YOUR logs while the identifier itself
// never leaves your system.
function pseudonym(value: string): string {
  const input = value + (process.env.PSEUDONYM_SALT ?? '');
  let h = 2166136261;
  for (let i = 0; i < input.length; i++) {
    h ^= input.charCodeAt(i);
    h = Math.imul(h, 16777619);
  }
  return 'cust_' + (h >>> 0).toString(36);
}

export function minimizeState(state: string): string {
  let out = state.replace(/customer[ _#]?\d+/gi, (m) => pseudonym(m));
  for (const [pattern, tag] of PATTERNS) out = out.replace(pattern, tag);
  return out;
}

// Usage — one line before the existing call:
//   const state = minimizeState(rawTicketBody);
//   await evaluate({ model: 'jev-latest', state, questions });

这些正则只是示意,不是合规控制项:它们能抓住明显的直接标识符,但会漏掉上下文型 PII——写成自然语言的地址、自由文本里的健康信息。受监管的流量请上真正的检测器(如 Microsoft Presidio),或把 state 限制为结构化白名单字段,再谈信任输出。

Python 里最小化 state

python
python
# pii_minimize.py — redact direct identifiers before the Jev call.
import hashlib
import hmac
import os
import re

PATTERNS = [
    (re.compile(r"[\w.+-]+@[\w-]+\.[\w.]+"), "[email]"),
    (re.compile(r"\b(?:\d[ -]*?){13,16}\b"), "[card]"),
    (re.compile(r"\+?\d[\d\s().-]{7,}\d"), "[phone]"),
]
CUSTOMER = re.compile(r"customer[ _#]?\d+", re.IGNORECASE)
_SALT = os.environ.get("PSEUDONYM_SALT", "").encode()


def _pseudonym(match: re.Match) -> str:
    # Salted HMAC: the same customer id maps to the same stable token in
    # YOUR logs; the identifier itself never leaves your system.
    digest = hmac.new(_SALT, match.group(0).encode(), hashlib.sha256).hexdigest()
    return "cust_" + digest[:10]


def minimize_state(state: str) -> str:
    state = CUSTOMER.sub(_pseudonym, state)
    for pattern, tag in PATTERNS:
        state = pattern.sub(tag, state)
    return state


# Usage — one line before the existing call:
#   state = minimize_state(raw_ticket_body)
#   client.evaluate(model="jev-latest", state=state, questions=questions)

PSEUDONYM_SALT 要保密且保持稳定:轮换它会让同一客户的新旧 token 之间失去关联。与 TypeScript 版同样的警告也适用——正则是起点,不是合规控制项。

PII 重灾区旗舰用例:工单智能路由

数据驻留:文档化的现实与四个抓手

Jev 的处理发生在哪里、合同怎么说,以及不够用时怎么办。

去开发者文档找区域,你什么都找不到:没有区域清单、没有驻留开关、没有数据位置页面。存在的是法律层面的安排而非架构层面的——DPA 用欧盟 SCCs(Module 2,你作为处理者时另加 Module 3)与英国附录覆盖跨境传输,管辖法为爱尔兰、瑞士争议交瑞士法院;隐私政策写明来自这些地区的访客 "you are transferring your personal data outside of those regions to the U.S. for storage and processing"。合起来读:处理足迹以美国为基地,国际传输全靠合同安排来支撑。

如果这满足不了驻留要求,今天有四个抓手——一个官方且属合同层,一个第三方托管,两个架构层。四个都能与上一节的脱敏中间件叠加;先把载荷缩小,下游每个选项都会更便宜。

企业版零数据保留(官方)

法律索引写明 TypeSafe "offer[s] zero data retention (ZDR) for enterprise customers"——这是「什么都不保留」的官方抓手。它是销售对接的商务安排:联系 sales@typesafe.ai,把承诺写进签署的 DPA,而不是相信网页。

第三方协议兼容托管(laya.studio)

一个托管开源 Laya 模型的独立服务商,卖的正是这个角度:"Answered on GPUs in Switzerland. Nothing you send is stored.",提供 Swiss-only 模式、AWS 苏黎世(eu-central-2)的账户数据、x-laya-region 响应头,以及零内容保留(元数据 30 天)。以上全部是该公司的自述——本站未验证——而且它自己的页面披露「今日无任何正式认证(如 ISO 27001)」、与 Jev 的「准确率与置信度语义有差异」。把它当候选,不是结论:让个人数据过它之前,先自己验。

自托管开源决策模型

Jev 本体无法自托管——闭源权重、没有公开权重。开源替代品可以:Laya(Apache-2.0)pip 一装,laya-serve 就说同一套 /v1/systemone,现有 SDK 调用换个 base URL 就活下来。代价是准确率:独立 49 任务基准上,最强开源模型约 0.704,Jev 为 0.966。完整矩阵见 /self-hosted-jev。

你自己边界上的脱敏网关

留住 TypeSafe,缩小过界的东西:在出口跑上一节的中间件,让每个 state 只带语义最小集出门——没有姓名、没有邮箱,需要关联的地方用加盐假名。它与上面所有选项可叠加,而且不像它们,代价只是一个函数,不是一轮采购。

四个抓手没有任何一个能免除你作为控制者的义务。无论选哪个,下一节的 DPIA 都应当把它们比较一遍——这份比较本身就是可审查的文档。

完整的自托管矩阵——十条路线与各自的最低硬件

GDPR / DSGVO 视角

合规是附着在你处理行为上的流程——不是模型或厂商的属性。

没有任何模型在抽象意义上「符合 GDPR」,本页也不会假装 Jev 符合或不符合。GDPR 真正问的是:你的使用有没有合法性基础、有没有最小化数据、有没有尊重权利、重大决策是否可复核。对类型化决策 API 来说,这套要求其实是个好消息:决策是辅助性的,输入由你做最小化,人工复核路径是一条路由规则,不是一个研究课题。

至于 Jev 本身,诚实的表述就是上面已经说过的那些:存在一份控制者-处理者 DPA 与 SCCs;这些文件里没有公布认证;保留期限在你的合同给出数字之前没有数字。用下面四个检查点补齐你这半个方程。

决策系统的四个检查点

Art. 6 — lawful basis

决定工单进哪个队列就是处理个人信息。写明你的合法性基础——合同必需或正当利益是常见候选——并且赶在第一次调用之前记录在案,而不是审计之后补。

Art. 5 — data minimization

上一节的中间件就是这条原则的代码形态:如果决策不需要姓名,姓名就不「适当、相关、限于必要」。发送语义最小集。

Art. 22 — automated decisions

产生法律效果或类似重大影响的纯自动化决策负有额外义务。可行模式:把 Jev 的答案当作置信度门控之后的辅助——低置信度转人工,并在产品里让这条人工路径看得见。

Art. 35 — DPIA

以自动化手段系统性评估个人数据是典型的 DPIA 触发情形。上线前跑一遍下面的清单,范围变更后再跑一遍。

给这类系统的 DPIA 检查清单

  • 目的:写下这个 API 替你做的唯一一个决策(路由 / 打分 / 批准)——不写更宽的。
  • 数据:列出脱敏之后仍会进入 state 字符串的每个字段,并逐个给出理由。
  • 必要性:决策能不能跑在假名化输入上?装了上面的中间件之后答案通常是能——把结论记录下来。
  • 替代方案:把托管 Jev 与四个驻留抓手比较一遍——这份比较本身就是 DPIA 材料。
  • 人工路径:定义升级到人工的置信度阈值,并在真实案例而不是假设案例上测试它。
  • 供应商档案:把签署的 DPA、子处理者清单快照、ZDR 往来函件放进同一个文件夹。
  • 复审:排期下一次评审——官方记录会变;本页写作依据的是 2026-09-28 快照。

本节把公开已知的 GDPR 概念映射到决策系统上。它是工程视角的梳理,不是法律意见,也与 TypeSafe 无隶属或背书关系。要有约束力的答案,请找你的 DPO 或法律顾问——并把他们说的话写进合同。

类型化决策对生成文本——隐私暴露面背后的模型行为

Jev 数据隐私:常见问题

Jev 会存储我的数据吗?

开发者文档对此没有回答——没有保留页面——所以有约束力的记录是法律文件那一套:DPA 规定客户个人数据保留 "for as long as necessary taking into account the purpose of the Processing",隐私政策说 "as long as reasonably necessary to provide you with the Services",且除非法律要求更久,可应请求删除。两者都没有给出数字。TypeSafe 还为企业客户提供零数据保留(ZDR)——联系 sales@typesafe.ai,并在依赖它之前把承诺写进签署的 DPA。

Jev 符合 GDPR 吗?

没有哪家厂商在抽象意义上「符合 GDPR」——合规附着在你的处理行为上,不在模型身上。厂商侧已有的:一份控制者-处理者 DPA,含欧盟 SCCs(另有英国附录)、带 15 天异议窗口的子处理者清单、72 小时泄露通报与年度审计条款,管辖法为爱尔兰。没有的:任何公布的认证,隐私政策中也没有数据主体权利章节。你仍是控制者:写明合法性基础、做最小化、给重大决策留人工路径——然后让 DPO 确认整体图景。

Jev 能自托管吗?

不能——Jev 本体是托管、闭源权重的 API,没有公开权重,也没有离线模式,其主客户协议还限制用它的输出开发同类产品。能托管的是它周围的开源生态:Laya(Apache-2.0)这类模型经 laya-serve 说同一套 /v1/systemone 请求形状,现有 SDK 调用换个 base URL 就能活下来。代价是准确率——独立 49 任务基准上,最强开源模型约 0.704,Jev 为 0.966。完整矩阵见自托管 Jev 页。

Jev 会拿我的提示词训练吗?

隐私政策承诺:"We will not train or fine tune any artificial intelligence or machine learning models on your prompts or other Input." 这是厂商自己公布的承诺——引用它,同时也要把它钉进合同:企业协议与 ZDR 才是这类承诺变得可执行而不只是被声明的地方。如果你的采购流程需要比政策句子更多的东西,DPA 谈判正是为此而设。

调用里的 PII 怎么办?

唯一要紧的暴露面由你控制:state 字符串。文档化的请求没有会话或对话对象,你的问题键名也被明确为不发送给底层模型——所以暴露的就是你写的 state 和 criteria 文案。剥掉直接标识符、客户 ID 用加盐哈希假名化、类别放 criteria 而不是个案细节;上面的中间件在调用前一行代码完成这些。

谁是数据处理者?

当你调用这个 API 为自己的客户做决策时,你是控制者,TypeSafe 是你的处理者——公布的 DPA 就是一份控制者-处理者协议(SCC Module 2,你自身作为处理者时适用 Module 3)。其子处理者清单在 trust.typesafe.ai/subprocessors,新子处理者有 15 天异议窗口,TypeSafe 对其行为承担责任。角色会随使用方式翻转——让分配在你的合同里得到确认,而不是从网页推断。