Security architecture for our AI solutions

What does operating inside your perimeter mean?

Your perimeter is the closed environment of your company: your on-premises servers or your private cloud. The solution is deployed inside that environment—like a safe installed inside your bank, not in someone else’s vault.

Source data, the search engine, knowledge base, and key storage remain on infrastructure you control. They are not sent to us, to a model vendor, or elsewhere. Access to the system and the right to administer it remain with you.

Technically, this means Docker containers that can be deployed on your equipment in hours. You do not send documents outside; you bring the tool into the environment where it works.

Which data can the system see?

It is important to distinguish two spaces: inside the perimeter and outside it.

• Inside the perimeter, the system sees exactly what you grant it access to: email, chats, documents, and exports from business systems. It needs that context to find facts, map processes, and answer questions. This material stays inside and is not transmitted elsewhere.
• Outside the perimeter (to an external LLM), the system sends not a full corpus but a small fragment for a particular query—and only after de-identification.

Before any transfer, personal data—names, tax or registration identifiers, phone numbers, addresses, and passport data—is removed and replaced with placeholder tokens. Instead of a real name, the text contains ‹PERSON_42›; instead of a company number, ‹ORG_17›. The external model sees document structure, logic, and relationships, but not the people or organisations behind them.

The most sensitive material—trade secrets and data with the highest classification—does not leave the perimeter at all. It is processed by a local model inside the environment.

Why is an external LLM still reliable and safe?

An external model is used as a computational engine for difficult reasoning. It receives a de-identified puzzle, not your raw data. Security rests on several independent layers:

• Only tokens leave the perimeter, never real data. The model does not receive names, identifiers, or personal data; it works with placeholders such as ‹PERSON_42›.
• The token-to-value key stays with you. The correspondence table (the token vault) is encrypted and stored only inside the perimeter. Identifying a person is possible only for authorised staff within your environment.
• The endpoint must support zero retention. The external model is used under a no-prompt-retention, no-training-on-your-data arrangement, including a data-processing agreement where applicable. A request is processed and then discarded.
• Fail closed by default. If the system cannot establish that a fragment has been completely cleared of personal data, it is not sent. Security takes priority over convenience.
• The most sensitive data never leaves. Classification-based routing keeps the highest tier local.

Why does this not reduce system effectiveness?

A common concern is that privacy controls will make the system slow or less useful. In practice, they need not do so:

• Answer quality does not depend on real names. A strong frontier model still performs the difficult synthesis. It reasons over structure, relationships, and logic; a token carries the same role in that reasoning as a name.
• Lightweight work stays local and fast. Search, embeddings, and classification run inside the perimeter on modest hardware—a CPU or a single GPU. Only the most resource-intensive generative synthesis may be routed externally.
• De-identification is invisible to the user. It happens automatically in the pipeline in fractions of a second; no one has to perform it manually.
• Authorised users see normal output. At the presentation layer, tokens are restored to real values locally and only for authorised people. They read a usable report, not ‹PERSON_42›.

Every protection layer, end to end

Protection is not a single wall. It is a pipeline of layers. Data passes through them in order, and the privacy boundary separates local handling from the one optional step that uses an external model.

1. Ingestion through connectors

   Sources arrive as they are—email, chats, documents, scans, and exports—without a requirement for pre-cleaning. Each item receives a passport: source, owner, date, channel, and sensitivity tier.

2. Privacy perimeter: the critical layer

   All source material is cleaned before it reaches an index or model:

   • text and scan recognition; documents containing personal data are read by a local model, so the image never leaves the perimeter;
   • noise and duplicate removal, including signatures, disclaimers, and quoted tails;
   • personal-data detection and removal, then replacement with reversible tokens such as ‹PERSON_42› and ‹BIN_8›;
   • an encrypted token vault for token-to-value mapping, stored on premises only;
   • sensitivity tiers (T0/T1/T2) and routing; the highest tier never goes out;
   • a fail-closed PII guard: if cleanliness is uncertain, the fragment stays local.

3. Local indexing

   Embeddings and vector storage operate inside the perimeter. Hybrid search—semantic plus exact matching for numbers and codes—remains on your infrastructure.

   — — — privacy boundary — — —

4. Synthesis on de-identified material

   This is the sole step that can run beyond the perimeter: an external model receives a de-identified fragment for a specific query. Contested facts are not presented as truth; they are flagged for human review and adversarial verification.

5. Presentation and audit

   The result returns inside. Here, re-identification restores tokens to real values locally and only for authorised users. Each outgoing request can be logged, and every fact can be traced to its source.