Technical overview

Three ways to deploy

Whichever you pick, the running instance belongs to one customer. There is no shared tenancy.

On your own hardware

In your building, on your network. Can run with no outbound connection at all. Backup and physical security stay with you.

On a dedicated server

One machine allocated to you, in a region you choose. Encrypted disk, management interface open only to your IP range.

We arrange the hosting

Procured on your behalf and passed through at cost. Still single tenant, still your policy.

How you prove it

We say above that your data does not leave. These are the three things you show an auditor when they ask. All of them are produced by every deployment.

Example — the data is invented

One line per request

Who asked, from which team, which model answered, which document it came from, what personal data was masked, and what left the building. The second line is a request that was blocked.

{"ts":"2026-10-21T09:14:22Z","user":"a.yilmaz@firm.example","team":"litigation",
 "assistant":"contracts-tr","model":"qwen3.8-27b","prompt_chars":1842,
 "documents_cited":["contracts/2024/ACME-SLA.pdf#p3"],
 "pii_detected":["national_id","iban"],"pii_masked":2,
 "egress":"none","blocked":null,"latency_ms":1240}

{"ts":"2026-10-21T09:31:07Z","user":"m.demir@firm.example","team":"litigation",
 "assistant":"contracts-tr","model":"qwen3.8-27b","prompt_chars":640,
 "documents_cited":[],"pii_detected":["national_id"],"pii_masked":1,
 "egress":"blocked",
 "blocked":{"reason":"destination not in allowlist","host":"api.translate.example"},
 "latency_ms":38}

The question text is not stored — only its length. Keeping the content as well is your choice.
documents_cited is what makes an answer checkable: it names the file the answer came from.
egress says what went outside. "none" means nothing did.

Who may reach what, in one file

For each team: which model, which documents, the monthly spending limit, which categories of personal data get masked, and which addresses it may reach. This file is yours, and changing it does not need our approval.

teams:
  litigation:
    models:    [qwen3.8-27b]
    documents: [contracts/**, case-files/**]
    monthly_budget_usd: 400
    masking:
      enabled: true
      types: [national_id, iban, card, phone, email]
    egress:
      mode: allowlist
      allow:
        - mevzuat.gov.tr
        - resmigazete.gov.tr

  hr:
    models:    [gemma4-9b]
    documents: [policies/**]
    monthly_budget_usd: 120
    masking:
      enabled: true
      types: [national_id, phone, email, address]
    egress:
      mode: none          # no internet access at all

retention:
  audit_log_days:    365
  conversation_days: 90

With egress.mode "none" that assistant has no internet access at all.
The allowlist is enforced at the network layer, not in application config.
You set the retention periods, and the records belong to you.

What masking catches, and what it does not

Measured on your own sample text during deployment and given to you in writing. We do not invent the numbers.

Data type	Detection	Why
National ID number	Very strong	Structured, fixed format
IBAN / account number	Very strong	Structured, has a checksum
Card number	Very strong	Structured, Luhn-checkable
Phone and email	Strong	Predictable shape
Personal names	Partial	Can be missed in free text
Addresses	Partial	Can be missed in free text

Read the last two rows in particular. Masking is not perfect and we do not say that it is. If you meet a vendor who claims 100%, ask them for this table.

What it is built from

Every layer runs in place, and all of them are established, audited open-source projects. What we write is the policy layer and the configuration that generates it; the rest is proven parts — because in this business new code means new attack surface.

Layer	What it does
Model serving	Uses GPU memory efficiently, queues concurrent requests, serves the model.
Policy gateway	Keys, teams, spending limits and model routing. The single point every request passes through.
User interface	The chat window your staff see. It resembles the tools they know because it does the same job.
Document index	The vector index over your documents. This is what lets an answer cite the file it came from.
Masking engine	Personal data detection and masking. Which types get masked is declared in the policy.
Observability and audit	Every request, latency, cost and block. This is the record you show an auditor.
Egress control	The allowlist is enforced here, at the network layer — not in application config.
TLS and identity	Encrypted transport and the corporate sign-in front door.

The full list of components, their versions and their licences is given in writing before contract. All of them are widely used open-source projects; we do not write our own model or our own database.

What happens to one request

1
The employee authenticates. Corporate SSO can be connected.
2
The request reaches the gateway, where team policy, model permission and spending limit are applied.
3
The text passes the masking layer; the types declared in the policy are replaced.
4
If needed, relevant passages are pulled from the document index and attached.
5
The model produces an answer. The model runs on the same network; the request does not go outside.
6
The answer comes back with references to the source documents.
7
The audit record is written: who, when, which model, which document, what was masked, what was blocked.

The question text is not stored by default — only its length is recorded. Storing the content as well is a policy setting, and it is your decision, not ours.

Where egress is actually controlled

The allowlist is enforced at the network layer: the model container sits on an internal-only network and its single route outward is a proxy that applies the list. Doing this in application configuration is not enough — a misconfigured or compromised application can ignore its own rule, but it cannot ignore the network.

An honest warning: give a model both web access and write permissions, and an instruction inside a page it reads can make it act. This is called prompt injection and it is not a solved problem. That is why write permissions are kept separate and the default allowlist is narrow.

What we can see

The weakest link in this architecture is usually the vendor keeping standing access. We do not have it.

No standing credentials

We hold no account inside your environment. Configuration is pulled from your repository and applied there; we do not push into it.

Metrics-only telemetry

What reaches us is uptime, latency and error counts. Not prompts, not answers, not document content.

Time-boxed break-glass

If a fault needs our access, you open it, it expires, and it is recorded.

The exit is yours

Model weights and configuration belong to you. If you leave, the deployment keeps running.

What it needs

The GPU classes below map to the plans. The monthly ranges are an October 2026 market survey and are passed through at cost.

Class	Typical model	Infrastructure / month
24 GB class	`8B`	$120 – $400
48 GB class	`32B`	$280 – $700
80 GB class or multi	`70B / MoE`	$950 – $3,600

If it runs on hardware you already own, that cost is zero. CPU, RAM and disk requirements are given in writing along with the scope.

Technical limits

Masking is not perfect. It is strong on structured identifiers and can miss names and addresses in free text.
Prompt injection is an open problem. Do not grant web access and write permissions together.
Model licences differ and are confirmed in writing before deployment.
A local model does not replace the largest commercial models on the same hardware. We measure where it is equal and where it is behind, and tell you.
We cannot give you a compliance conclusion. We supply the technical safeguards and document them; the legal conclusion is your adviser's.

What runs where, what it can reach, and what we can see.