All services

The model never sees the real record.

Plenty of AI work stalls at legal review, because the honest answer to what leaves our network is everything. A data boundary fixes that: sensitive fields are encoded before the request and restored after the response, so the provider processes structure without ever holding a name, an account number or an address. It adds single-digit milliseconds and it changes the conversation with compliance.

Dayshours
Month-end reconciliation
55%80%
Plans completed without a human
On-device
Live-meeting detection

Built for production, not the demo.

01 / DATA_BOUNDARY

A data boundary in front of the model, for teams who cannot send raw records to a provider.

For teams who cannot send raw records to a provider. Encode on the way out, decode on the way back, so sensitive fields never leave your side.

Usually shipped with

  • Production AI engineering
  • Guardrails and safety layers
  • On-device and edge inference

Not a bundle to buy. Whichever you start from, the engagement covers what the build actually needs.

02 / Scope

What we build.

  • Detection and encoding of personal data before a request leaves
  • Decoding on return, so the answer is complete for your users
  • Reversible tokenization rather than lossy masking where structure matters
  • Configurable field policies per data class and per jurisdiction
  • A record of what was redacted, for the review that follows

03 / Outcomes

What you can ship.

  • AI approved by legal and compliance
  • Third-party models used without third-party data exposure
  • A defensible answer to what leaves your network

04 / Deliverables

Artefacts, not activities.

  • The boundary layerDetection, encoding and decoding in front of every provider call.
  • Field policiesPer-data-class and per-jurisdiction rules, configurable without a deploy.
  • A leakage test suiteTests that fail if a raw value can reach a provider, runnable in CI.

05 / Stack

What it is built on.

Detection
Named entity recognition / Pattern rules
Encoding
Reversible tokenization / Format-preserving
Policy
Per-class rules / Jurisdiction config
Assurance
Leakage tests / Per-request records

06 / Why us

Reversible tokenization, not masking

Masking destroys the structure a model needs to reason. Tokenization preserves it, so the answer is as good as it would have been on raw data, and the raw data still never leaves.

Single-digit milliseconds

The encode and decode cost is small enough that it is never the reason a request is slow. That matters, because a boundary teams disable under load is not a boundary.

Built for the review, not just the risk

On FinSight the anonymization work existed so the audit could be passed, not only so the data was safe. The per-request record is what makes that conversation short.

A path from your problem to production.

  1. Week 1

    Classify what is actually sensitive

    Not every field is PII and over-redaction destroys the answer. We work through your data with whoever owns the risk.

  2. Week 1-2

    Encode before the boundary

    Detection and reversible tokenization in front of the provider call, so structure survives and identity does not cross.

  3. Week 2-3

    Decode on return

    The answer is restored for your users, complete, with the original values your systems already hold.

  4. Week 3-5

    Prove it

    A record of what was redacted per request, and the test suite that shows nothing leaked, for the review that follows.

Dark ink blooming and dispersing through clear liquid

Production-proven

Built by engineers who've already shipped this in production.

The questions buyers actually ask.

Does redaction hurt answer quality?

Barely, when tokenization is reversible and format-preserving. The model reasons over structure, and structure survives. Lossy masking is what degrades answers.

Which fields get redacted?

The ones you and your risk owner decide. We bring a default set for common regimes and then work through your actual data, because over-redaction is its own failure.

Can we prove nothing leaked?

Yes, and that is the deliverable that matters. A per-request record of what was encoded, plus a CI suite that fails if a raw value can reach a provider.

What about data already sent?

Out of scope for this layer, and worth saying plainly. This stops the next request, not the last one; historical exposure is a separate conversation.

Let's scope your pii redaction and data boundaries build.

Tell us where you are and what you're trying to ship. We'll come back with a concrete plan, the right engineers, and a path to production, not a generic pitch.