privacy · data flow & compliance · verified 2026-09-28

Jev data privacy: what the official record says, and how to send less

One Jev call sends your state and returns typed decisions. What TypeSafe documents about retention and residency — and what it leaves to contracts — plus PII minimization middleware you can ship today.

TL;DR

Jev's developer docs publish no privacy or data-residency page; the real record is legal: a DPA (SCCs, subprocessor list, 72-hour breach notice), a privacy policy that commits to never training on your prompts, and enterprise zero data retention on request. Retention is "as long as necessary" — no number. So: minimize before you send (the PII middleware below), get retention written into the signed DPA, and treat compliance as your process — Jev answers are assistance behind a human path, not an automated ruling.

Fact snapshot 2026-09-28: the developer-documentation index (docs.typesafe.ai/llms.txt) contains no privacy, security, or data-residency page; the API reference, the System One concept page, and the three legal documents (DPA, Privacy Policy, Master Customer Agreement) were read directly. laya.studio claims are that company's own marketing, unverified by this site. Nothing on this page is legal advice.

What one Jev call actually sends

The privacy surface of the API is the request body — and the request body is entirely yours to compose.

Request fieldWhat it carriesThe privacy read
statestring | object | array — the content to evaluate: text, chat logs, or app state.The entire privacy surface of the call. Whatever you put here leaves your boundary, and the docs describe no automatic field stripping — minimization happens on your side, before the request.
modelThe model id, e.g. "jev-latest".Not personal data.
questionsA map you name. Each question declares a type (noul / choice / score), instructions, and criteria — up to 255 options per Choice question.Question text is your copy — and criteria labels are content too. A label like "Billing — sarah.miller@acmecorp.com" would leak inside the request, so write categories there, never case details.
question keysThe keys of the questions map (e.g. "route") — the answers come back under the same keys.Documented as not model-facing: a key "is not sent to the underlying model and is not used in inference."
Authorization headerBearer API key.A credential, not content. It authenticates the call — keep it server-side and rotate on leak, the same rule every API key follows.

Per the HTTP reference. The response adds answers keyed by your question names — choice or score with a probability distribution and a confidence value, a 0–1 noul value — plus a usage object reporting input_tokens and output_tokens. Everything model-facing is in the two content fields above; the key names are documented as not model-facing.

One Jev call vs a chat LLM turn: the structural differences

AspectOne Jev callA chat LLM turn
RequestOne self-contained call: state + questions. The documented request carries no session or conversation object — context lives entirely in what you send.A conversation: turns accumulate in a session, and every turn re-sends prior context to the provider.
ResponseA typed answer per question: the chosen option or score, its probability distribution, and a confidence value derived from it — "typed decisions and probabilities rather than generated text".Generated text, token by token, until a stop condition — new prose written from your prompt.
What that means for privacyThe request is the whole surface: shrink the state and you have shrunk the exposure. No answer text is generated from your data, and nothing needs to accumulate to keep a conversation going.The provider sees your context and returns derived prose; conversation features may retain session context provider-side under each product's own data controls.
See exactly what a request sends — working examples for every endpoint

The official record: what exists, what does not

The honest baseline for a procurement conversation: the developer docs are silent, the legal documents are not.

Documented — and quotable

  • A legal index — docs.typesafe.ai/legal.md — linking three documents: the Data Processing Agreement (described there as "how we process customer data on your behalf, including data retention"), the Privacy Policy, and the Master Customer Agreement.
  • A no-training commitment in the privacy policy: "We will not train or fine tune any artificial intelligence or machine learning models on your prompts or other Input."
  • A DPA with substance: EU SCCs (Module 2, plus Module 3 when you act as a processor) and the UK Addendum for transfers, a subprocessor list at trust.typesafe.ai/subprocessors with a 15-day objection window, breach notice "within 72 hours", security audits "no more than once every 12 months", and Irish governing law — Swiss disputes go to the Swiss courts.
  • An enterprise zero-data-retention (ZDR) option, announced on the legal index itself, with sales@typesafe.ai as the contact.

Not documented anywhere official

  • No privacy, security, or data-residency page exists anywhere in the developer-documentation index — checked against docs.typesafe.ai/llms.txt on 2026-09-28.
  • No retention number: the DPA keeps data "for as long as necessary taking into account the purpose of the Processing" — a principle, not a period.
  • No region list, residency toggle, or data-flow diagram; the privacy policy states that for international visitors, data is transferred "to the U.S. for storage and processing."
  • No published certifications (SOC 2, ISO 27001) in these documents, and no GDPR data-subject-rights section in the privacy policy. The DPA points at trust.typesafe.ai for detail — verify what it currently shows before you rely on it.

What a buyer should actually do

  • Read the three legal documents end to end before procurement — they are short, and they are the actual record.
  • Email sales@typesafe.ai for the ZDR engagement and a security whitepaper, and get every answer you rely on into the signed DPA.
  • Snapshot trust.typesafe.ai/subprocessors at signature date, and diarize the 15-day objection window for new subprocessors.
  • Until retention is contractual, assume the request body can be retained and design accordingly — which is exactly what the middleware in the next section is for.
Open the TypeSafe legal index (docs.typesafe.ai/legal.md)
The endpoints and protocol this data-flow section summarizes

PII minimization: shrink the payload before it leaves

The one lever you control completely, and the core engineering pattern of this page.

The state string is the only surface that matters, and it is under your control. Classification-style questions — route this ticket, score this reply, flag this transaction — key off what the text says, not who said it: the billing queue is decided by "duplicate charge", not by sarah.miller@acmecorp.com. That gap is where minimization lives: strip direct identifiers before the call, and the decision has nothing personal to leak.

Two details make this rigorous rather than cosmetic. First, pseudonymize instead of deleting where correlation matters: a salted hash of the customer id keeps your own analytics joinable while the identifier itself never leaves. Second, remember the documented split from the API reference — your question keys are not model-facing, but your state and your criteria wording are. Categories in criteria; case content in state; nothing else.

Before — identifiers in flight
// 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, less exposure
// 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"
      }
    }
  }
}

The route decision cannot tell the difference: both payloads ask the same question about the same semantics. The email, card number and ticket id added nothing the decision used — they only added liability.

Minimize the state in TypeScript

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 });

These are illustrative regexes, not a compliance control: they catch the obvious direct identifiers and will miss contextual PII — addresses written as prose, free-text health details. For regulated traffic, run a real detector (for example Microsoft Presidio) or restrict the state to structured, allow-listed fields before trusting the output.

Minimize the state in Python

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)

Keep PSEUDONYM_SALT secret and stable: rotating it breaks the correlation between old and new tokens for the same customer. The same caveat as the TypeScript twin applies — regexes are a starting point, not a compliance control.

The PII-heavy flagship use case: support-ticket routing

Data residency: the documented reality and four levers

Where Jev processing happens, what the contracts say about it, and what to do when that is not enough.

Ask the developer docs for regions and you find nothing: there is no region list, no residency toggle, no data-location page. What exists is legal rather than architectural — the DPA covers transfers with EU SCCs (Module 2, plus Module 3 when you act as a processor) and the UK Addendum, names Irish law with Swiss disputes in the Swiss courts, and the privacy policy states that for visitors from those regions "you are transferring your personal data outside of those regions to the U.S. for storage and processing." Read together: a US-based processing footprint, contractually scaffolded for international transfers.

If that does not satisfy a residency requirement, four levers exist today — one official and contractual, one third-party and hosted, two architectural. All four compose with the minimization middleware from the previous section; shrinking the payload first makes every downstream option cheaper.

Enterprise zero data retention (official)

The legal index states TypeSafe "offer[s] zero data retention (ZDR) for enterprise customers" — the official lever for "nothing is kept". It is a sales-managed engagement: contact sales@typesafe.ai, and get the commitment into the signed DPA rather than trusting a web page.

Third-party wire-compatible hosting (laya.studio)

An independent service hosting the open Laya model markets exactly this angle: "Answered on GPUs in Switzerland. Nothing you send is stored.", a Swiss-only mode, account data in AWS Zurich (eu-central-2), an x-laya-region response header, and zero content retention with 30-day metadata. All of it is that company's own marketing — unverified by this site — and its own pages disclose "no formal certification (such as ISO 27001) today" and that "accuracy and confidence semantics differ" from Jev. A candidate, not a verdict: verify before you route personal data through it.

Self-host an open decision model

Jev itself cannot be hosted — it is closed-weight with no public weights. The open alternatives can: Laya (Apache-2.0) installs with pip and serves the same /v1/systemone shape via laya-serve, so an existing SDK call survives a base-URL swap. The price is accuracy: on the independent 49-task benchmark the best open model scores about 0.704 against Jev's 0.966. Full matrix on /self-hosted-jev.

A minimization gateway at your boundary

Keep TypeSafe, shrink what crosses: run the middleware from the previous section at your egress so only the semantic minimum of each state leaves — no names, no emails, salted pseudonyms where correlation matters. This composes with every option above, and unlike them it costs one function, not a procurement cycle.

None of the four levers removes your duties as controller. Whichever you pick, the DPIA in the next section should compare them — the comparison itself is assessable documentation.

The full self-host matrix — ten routes with minimum hardware

The GDPR / DSGVO angle

Compliance is a process that attaches to your processing — not a property of a model or a vendor.

No model is "GDPR compliant" in the abstract, and this page will not pretend Jev is or is not. What the GDPR actually asks is whether YOUR use has a lawful basis, minimizes data, respects rights, and keeps consequential decisions reviewable. For a typed-decision API that shape is encouraging: the decision is assistive, the input is yours to minimize, and the human-review path is a routing rule, not a research project.

Where Jev specifically is concerned, the honest statements are the ones already made above: a controller-to-processor DPA with SCCs exists; certifications are not published in these documents; retention has no number until your contract gives it one. Fill your half of the equation with the four checkpoints below.

Four checkpoints for a decision system

Art. 6 — lawful basis

Deciding which queue a ticket goes to is processing. Name your basis — contract or legitimate interests are the usual candidates — and document it before the first call, not after the audit.

Art. 5 — data minimization

The middleware above is this principle in code: if the decision does not need the name, the name is not "adequate, relevant [or] limited to what is necessary". Send the semantic minimum.

Art. 22 — automated decisions

Solely automated decisions with legal or similarly significant effects carry extra duties. The working pattern: treat Jev answers as assistance behind a confidence gate — route low-confidence cases to a human, and keep that path visible in your product.

Art. 35 — DPIA

Systematic evaluation of personal data by automated means is a classic DPIA trigger. Run the checklist below before rollout, and re-run it when scope changes.

A DPIA checklist for this exact kind of system

  • Purpose: write down the single decision the API makes for you (route / score / approve) — and nothing broader.
  • Data: list every field that reaches the state string after minimization, and justify each one.
  • Necessity: could the decision run on pseudonymized input? After the middleware above, the answer is usually yes — record it.
  • Alternatives: compare hosted Jev against the four residency levers — the comparison itself is DPIA material.
  • Human path: define the confidence threshold that escalates to a person, and test it on real cases, not hypotheticals.
  • Vendor record: keep the signed DPA, the subprocessor-list snapshot, and your ZDR correspondence in one folder.
  • Re-review: schedule the next review — the official record changes; this page was written against a 2026-09-28 snapshot.

This section maps publicly known GDPR concepts onto decision systems. It is engineering orientation, not legal advice, and it is not affiliated with or endorsed by TypeSafe. For a binding answer, involve your DPO or counsel — and put what they say into the contract.

Typed decisions vs generated text — the behavior behind the privacy surface

Jev data privacy: FAQ

Does Jev store my data?

The developer docs answer nothing — there is no retention page — so the binding record is the legal set: the DPA keeps customer personal data "for as long as necessary taking into account the purpose of the Processing", and the privacy policy says "as long as reasonably necessary to provide you with the Services", with deletion on request unless the law requires longer. Neither publishes a number. TypeSafe also offers zero data retention (ZDR) for enterprise customers — contact sales@typesafe.ai and get the commitment into your signed DPA before you rely on it.

Is Jev GDPR compliant?

No vendor is "GDPR compliant" in the abstract — compliance attaches to your processing, not to a model. What exists on the vendor side: a controller-to-processor DPA with EU SCCs (plus the UK Addendum), a subprocessor list with a 15-day objection window, 72-hour breach notice and annual-audit clauses, under Irish law. What does not: any published certification, or a data-subject-rights section in the privacy policy. You remain the controller: name your lawful basis, minimize, keep a human path for consequential decisions — then have your DPO confirm the whole picture.

Can I self-host Jev?

No — Jev itself is a hosted, closed-weight API with no public weights and no offline mode, and its Master Customer Agreement restricts building lookalikes from its outputs. What you can host is the open ecosystem around it: models like Laya (Apache-2.0) serve the same /v1/systemone request shape via laya-serve, so an existing SDK call survives a base-URL swap. The tradeoff is accuracy — on the independent 49-task benchmark the best open model scores about 0.704 against Jev's 0.966. The full matrix is on the self-hosted Jev page.

Does Jev train on my prompts?

The privacy policy commits: "We will not train or fine tune any artificial intelligence or machine learning models on your prompts or other Input." That is the vendor's own published commitment — cite it, and also pin it contractually: enterprise agreements and the ZDR engagement are where such promises become enforceable rather than merely stated. If your procurement needs more than a policy sentence, that is precisely what the DPA negotiation is for.

What about PII in my Jev calls?

You control the only surface that matters: the state string. The documented request has no session or conversation object, and your question keys are explicitly not sent to the underlying model — so the exposure is the state and the criteria wording you write. Redact direct identifiers, pseudonymize customer ids with a salted hash, and keep categories in criteria rather than case details; the middleware above does this in one line before the call.

Who is the data processor?

When you call the API to decide things for your own customers, you are the controller and TypeSafe acts as your processor — the published DPA is a controller-to-processor agreement (SCC Module 2, with Module 3 for when you yourself act as a processor). Its subprocessors are listed at trust.typesafe.ai/subprocessors, new ones carry a 15-day objection window, and TypeSafe remains responsible for their acts. Roles can flip with usage patterns — have the allocation confirmed in your own contract rather than inferred from a web page.