Where your data goes

This page answers the question we are asked before any other: what happens to a document once it enters a system we build. The answer depends on what you are protecting, so it is given once per deployment option, followed by how we choose models, what is settled before anything goes live, and which European rules apply to whom.

Four ways to run it — and the hybrid most organisations end up with

  • inside your network or the EU, under your contract
  • at a third party, outside the EU or on its terms
  • crosses your network boundary
Your network
European UnionOutside the EU
Your documentsAll your material
Own hardware
Hardened European cloud, your dedicated tenant
European model provider, under contract
Non-European frontier model
Your network
European UnionOutside the EU
Your documentsAll your material
Own hardware
Hardened European cloud, your tenant
European model provider, under contract
Non-European frontier model

On your own hardware

Models run on servers you own, inside your network; nothing crosses the network boundary. For material that may not leave the premises under any policy. The trade-off is that only smaller, local models are available, and you run the hardware.

Where the model runs
On servers you own, inside your network
What leaves your network
Nothing
What is retained
On your servers only, under your own retention rules
What trains on what
Nothing; no third party is involved

In a hardened European cloud

A dedicated tenant in the EU, hardened and operated with you — inference, storage and compute inside the EU, encrypted in transit and at rest, access-controlled and logged. For organisations whose customers or auditors check their security, and who need stronger models than local hardware allows.

Where the model runs
In a dedicated EU tenant, hardened and operated with you
What leaves your network
Encrypted documents, to your EU tenant only
What is retained
In the tenant, encrypted at rest, under your contract
What trains on what
Nothing; excluded by contract

With a European model provider

Prompts and the documents you choose to send go to a European-hosted model under a contract that excludes training on your data and limits retention. For lower-sensitivity drafting and research, with the least setup.

Where the model runs
At a European-hosted model provider
What leaves your network
Prompts and the documents you choose to send
What is retained
Limited by contract
What trains on what
Nothing; excluded by contract

With a non-European frontier model

For non-sensitive material where the strongest available model matters more than jurisdiction. Data leaves the EU; confidentiality rests on the provider's business terms. We say so plainly, and we help you decide whether that is acceptable for the material in question.

Where the model runs
At a US or other non-EU provider
What leaves your network
Prompts and documents, outside the EU
What is retained
Per the provider's business terms
What trains on what
Not on business tiers; depends on the contract and its jurisdiction

The hybrid

In practice most organisations combine them: sensitive material on the first two, everything else on the last two, with one verification layer and one set of rules across all of it. We design the split with you and document which material goes where.

Sensitive material
Own hardware · hardened European cloud
Everything else
European provider · non-European frontier model

One verification layer and one set of rules across all of it; the split documented, material by material.

How we choose models

We recommend European-hosted models by default, open- or closed-weight, and local or private inference where confidentiality requires it. In practice we help each client pick what works for their constraints: model quality for the task, data residency, contract terms on retention and training, and the cost of running it. The choice is documented and stays with the client; nothing is locked to a vendor. Our own development work runs in Europe, in the US or locally, depending on the client's situation, and never on client documents without that client's arrangement.


What is settled before anything goes live

Where the documents go, under whose contract, and what is retained. Who can access the system and how that is enforced. What checks the answer — sources cited, assessments labelled. Who owns the system after we leave, and what the maintenance routine is. What is logged and for how long. What happens when the system is unsure or unavailable. These are the twelve items of the pilot-to-production checklist, and we do not skip them for a pilot.

Which of these rules applies, and to whom

Three European regimes come up in every rail conversation about AI. They bind different parties, and being precise about that is usually worth more than a compliance promise.

The Cyber Resilience Act

A system we build for you is a product with digital elements. Whose name it carries decides who the manufacturer is: where you take delivery under your own name, the obligations are yours, and our job is to hand over a system that meets them — secure development, an SBOM, a vulnerability-handling process, the technical documentation, and a reporting path your team can actually run. For genuinely tailor-made systems the Regulation allows a narrow deviation from two of the essential requirements, and only where the contract says so, which is a question for the contract rather than the build.

The AI Act

Most of what we build is not high-risk: reading tenders, drafting documents, answering from your own archive. What makes a system high-risk is the use it is put to, not the tool it is built with, and a general-purpose model composed into an agent for a high-risk purpose makes whoever did that the provider of a high-risk system. So we write down, before the build, which role each side holds and what the system is for. In rail, the classification usually runs through the products the system touches rather than through the AI itself.

The Data Act

This one rarely binds a supplier of systems; it binds cloud providers and the manufacturers of connected products. It works in your favour: your cloud contract may not lock you in, and switching charges disappear at the start of 2027. It is a good reason to keep an architecture portable, which is how we build in any case.


Where the dates stand. The Cyber Resilience Act's reporting obligations for actively exploited vulnerabilities and severe incidents have applied since 11 September 2026; the remaining obligations apply from 11 December 2027. The AI Act's prohibitions and its AI-literacy duty have applied since February 2025, its transparency rules since August 2026, and — after the amendment that took effect in July 2026 — the high-risk obligations under Annex III from 2 December 2027 and those for AI in other regulated products from 2 August 2028, while for rail the requirements are to come through the rules on rail interoperability. The Data Act has applied since 12 September 2025. These regimes are still being amended; we check the dates in each engagement rather than relying on a page.

Our own side. The AI Act's literacy duty applies to us as well, both as a provider and as a user of these tools, and we keep a record of how we meet it. This website is a static site, so it is not a product with digital elements, and it has no chatbot. The one AI-generated image on the site, the portrait on /about, is labelled as such. If we ever add a chatbot, it will say that it is an AI.

Book a call — if your security team has questions, they are welcome on the call.