Jev for Chatbot PII Checks, Guardrails and Routing

Can Jev check a chatbot message for PII? Yes, it can return a probability for a question about personal information. That result can help an application decide whether to mask, block or review a message. The important qualification is that an external Jev check receives the state you send it, which may already contain the PII you wanted to detect.

TypeSafe AI describes Jev as a System One model for decisions inside software. It takes state and predefined questions, then returns typed answers with probabilities rather than writing a customer reply. Its launch announcement introduced that approach in September 2026. PII detection is one possible question, alongside draft guardrails, product selection, intent routing and human handoff.

How Jev fits into a chatbot

The direct TypeSafe API accepts a POST request at https://api.typesafe.ai/v1/systemone. The request names a model, supplies the content in state, and defines one or more questions. The response identifies the model used and returns an answer under each question's name. The API documents noul for a yes or no probability, choice for a selection from named options, and score for a defined scale. Vercel's gateway interface calls its corresponding yes or no type boolean.

For a PII check, the state might contain a customer's message and the question might ask whether it includes personal data. Jev returns a probability, not a list of characters to erase. Application code must decide what probability requires review and must use a separate extraction or masking step when the message needs redaction.

What the synthetic smoke test showed

HoverBot made seven synthetic test calls on September 25, 2026. The messages were invented and contained no customer data. Every call returned HTTP 200 with the expected answer, taking 0.67 to 0.82 seconds end to end from Singapore, including network time. The response identified model version jev-1.13.0. This was a smoke test of the API shape, not an accuracy benchmark, a latency benchmark or evidence of production performance.

In the positive PII call, the invented message gave a name, Singapore phone number and card ending. The request used jev-latest, placed that message in state, and asked a noul question named has_pii. Jev returned 0.99. For the invented message asking whether a linen shirt came in size M and was machine washable, it returned 0.02. Those values show the two responses in this test, not a validated PII threshold.

A synthetic draft that prescribed 800mg of ibuprofen three times a day while selling a posture cushion returned 0.99 for medical advice and 0.03 for a competitor recommendation. A clean draft about shipping in two to four days and a 30 day return window returned 0.01 for both checks. These checks assess the supplied text; they do not verify that a shipping or return claim is true.

For a shopper seeking road running shoes for a half marathon, with mild overpronation and a budget near 150 dollars, Jev chose sku_road_stability, the 140 dollar stability road shoe, from four retrieved candidates and returned a probability map over their identifiers. For an invented shipping and price question about three blue items, it chose product_question from product question, order status, complaint and other, and returned 0.89 for buying intent. For an invented third request about a missing refund and a bot repeating the same FAQ link, it returned handoff score 2.0, mapped to immediate human handoff, with probabilities for each level.

The privacy tradeoff in an external PII check

A check meant to stop PII from reaching external services can itself send PII to an external decision API. If the raw customer message is the state, the vendor receives it before the application knows whether Jev will flag it. A PII probability does not undo that transfer. Keep the state to the minimum needed for the decision, avoid sending unrelated history or account fields, and consider masking obvious identifiers locally before any external call. The guides to protecting PII and chatbot data privacy cover the wider data flow.

TypeSafe says Jev is not trained on customer requests or responses. It also says customer data may be processed to provide the service, calculate charges, prevent fraud and abuse, and generate telemetry. Retention and deletion depend on the data, applicable agreements, legal requirements and any agreed zero data retention arrangement. Its privacy policy covers API input and does not give every customer a single fixed retention period. Its legal documentation says zero data retention is available for enterprise customers. No training on requests is therefore a narrower claim than no processing or retention.

Before using Jev with customer messages, ask which raw inputs, outputs and logs are retained, for how long, where they are processed, which subprocessors receive them, how deletion works, and which terms apply to the account and any gateway in the route. TypeSafe publishes a data processing addendum and customer agreement; confirm the governing documents and any agreed retention settings rather than inferring them from a model description. If raw messages must stay inside your infrastructure, a local pattern matcher or local PII detector is the better first pass. An external decision check can then evaluate a minimized or masked state if policy allows it.

Availability, versions and price

TypeSafe called Jev early access in its September 15 launch announcement. Its current model documentation lists Jev 1.14, available from October 14, 2026, alongside Jev 1.13. Both are listed at $0.042 per million input tokens, with output tokens free. The same page says jev-latest currently points to jev-1.14.0 and explains that aliases can move. It describes account-specific rate limits in the developer console. Vercel also lists Jev through AI Gateway with its own displayed price. Check access, limits and billing on the route you will use.

A new version can change answers even when request code stays the same. Pin a version when you evaluate thresholds, record the version returned with each decision, and retest before switching. TypeSafe's October release note describes Jev 1.14 as an improvement, with expected gains in multilingual support, but that is not evidence of PII accuracy on a particular chatbot's messages.

Turn probabilities into a tested policy

A possible PII policy could redact or block messages at or above 0.90, pass messages below 0.20, and send the middle band to a stricter detector or human review. Those numbers are illustrations, not universal thresholds. Choose them using properly governed, labelled examples from the intended traffic. Measure missed PII, unnecessary interruptions and review volume separately. Test multilingual messages, indirect references and unusual formatting before relying on any automatic path.

The same discipline applies elsewhere. A guardrail probability can trigger a rewrite or review, a choice can select among retrieved catalog identifiers, and a handoff score can prioritize support. Code must still enforce permissions, retrieve current facts and decide what happens when the API times out. A model choice cannot validate inventory or promise that a customer will purchase. For the surrounding data flow, see knowledge management for AI chatbots and catalog chat progress streaming.

Use Jev where acceptable answers can be defined before the call and where the state can be sent under the applicable data policy. Use ordinary code for fixed rules and authorized actions. Use a language model when the chatbot needs to write or explain a reply, and give uncertain decisions a review path.