Your AI runs on your infrastructure. Your data never leaves.
Most AI works by sending your information to someone else's computer. Your invoices, your rates, your customer list, your supplier terms, all processed in a data centre you do not control, by a company whose pricing and terms can change. Orchyn works the other way round.
This page is written to be forwarded. It is here so the people responsible for risk in your organisation can read our position directly rather than reconstruct it from a sales conversation. Everything below is a design requirement in every Orchyn build. Where a claim has a limit, the limit is stated.
Seven commitments that shape every build.
The system runs on your infrastructure
The model sits on your servers, inside your network. So does everything that tells it how your business works. Your information is read where it already lives and the answer is produced in the same place. There is no external service in the path, which means there is no connection to sever, no provider whose terms can change and no dependency on anyone staying in business.
Nothing is sent anywhere
Not to Orchyn, not to a model provider, not to a data centre in another country. This is the difference between a promise and an architecture. Most suppliers protect your data in transit to somewhere else; the safest data is the data that never travels at all. Everything is encrypted at rest and in transit within your estate but the encryption is the second line of defence, not the first.
Your model is yours and so are its instructions
You get your own model, tuned to your operation, not a shared service with your name on it. How it works is written in plain, readable files that sit alongside it: your terminology, your rules, your processes, your exceptions. You can open them and read them. It learns nothing from anyone else's business and nobody else's system learns from yours.
AI identifies. Code calculates
A model is used where judgement over messy input is genuinely needed, such as reading an unfamiliar invoice layout or reconciling inconsistent supplier feeds. Every figure that follows is computed by deterministic code against a named source. No number in an Orchyn system is written by a model.
Every output traces to its source
A finding is not useful if you cannot defend it. Each result records the input it came from, the rule applied and the calculation performed so any figure can be reconstructed and put in front of a counterparty, an auditor or a board. Because the instructions are written in plain English rather than buried inside the model, you can see not just what the system concluded but why.
A person holds authority
Systems are assisted, never executed. Where an action carries commercial, legal or reputational consequence, the system prepares and evidences the decision; a named person in your organisation makes it. Automation removes the work, not the accountability.
You own the system outright
The system, the model, the instruction files and the data are yours. There is no licence that expires and no platform you are renting. If you ended the relationship tomorrow, nothing would stop working, because there is nothing of yours held anywhere else. Ownership here is a fact of how it is built, not a clause in a contract.
The questions your risk and IT teams will ask.
Answered as we would answer them in a procurement review, including where the honest answer is a qualified one.
Where is our data processed and stored?
Wherever you already keep it. The system is installed into your environment and reads your information in place. It is not copied to us, not staged in an intermediate service and not moved to another country for processing. The specific placement is agreed in the design phase, before any build begins, then written into the engagement.
Does anything leave our network?
In a standard Orchyn build, no. The model and its instructions run inside your estate so the work happens where your data already is. If a particular build genuinely needs an external service, for example a public data source you have asked us to check against, we name it in the design, explain exactly what would be sent, then you decide before it is built. We will not add an external dependency quietly.
Is our data used to train AI models?
No. Nothing about your operation is pooled, resold or used to train anything, whether ours or a third party's. Because the system is not connected to an external model service, there is no route by which it could be.
What model do you use and did you build it?
We build and maintain the Orchyn model: the tuning, the instruction layer and the surrounding system are ours and that is where the work and the value sit. The underlying foundation is an open weight model rather than something we trained from nothing and we would rather say so than let you assume otherwise. That choice is deliberate and it is the reason the rest of this page is possible. A closed hosted model cannot be run inside your network; an open weight one can, which is what makes genuine sovereignty available to you at all. If you want the specific base model named in your documentation, we will name it.
Can we see how the system makes its decisions?
Yes and this is unusual enough to be worth stating plainly. The instructions that govern the system are plain, readable files, not settings hidden inside a model. Your terminology, your rules, your exceptions and your process are written out in English. You can open them, read them and challenge them. When you ask why the system reached a conclusion, the answer is a document you can inspect rather than an explanation we generate afterwards.
What happens to our data if we stop working with you?
Nothing happens to it and nothing stops working. The system already runs in your environment on hardware you control so ending the relationship removes our access and changes nothing else. There is no export to negotiate, no data to retrieve and no service to wind down, because there was never anything of yours held anywhere else.
How do we verify a figure the system produces?
Every figure carries its working. You can trace any result back to the source document, the rule applied and the arithmetic performed. The model interprets; deterministic code calculates. This is a design requirement in every Orchyn build, not a reporting feature added at the end.
How is the data protected in transit and at rest?
Encrypted in both cases, using current standards, within your own estate. We would rather you weighted the architecture above the encryption though: encryption protects information that is moving or sitting somewhere it could be reached. The stronger control is that your operational data does not travel outside your network in the first place.
Who at Orchyn can access our systems?
Access is limited to the named individuals delivering your engagement, on the least privilege needed to do the work, then removed when the engagement or retainer ends. Orchyn is a two founder consultancy so the list of people is short and we will tell you exactly who is on it. Because the system runs on your infrastructure, that access is yours to revoke at any time without involving us.
What personal data does a build typically involve?
That depends on your operation and is established during design. Where a system processes personal data, we document what is processed, on what lawful basis, how long it is retained and who can see it. We will complete your data protection paperwork rather than asking you to infer it from a brochure. Local processing materially simplifies this: with no transfer to a third party processor, several of the harder questions do not arise.
Can our IT or security team review the build?
Yes and we would prefer it. The design is documented before the build starts, specifically so that the people responsible for risk can read it and object early rather than late. You own the source code and the instruction files, the system runs on your own machines and there is nothing we could hide in it even if we wanted to.
Bring the people who will say no.
If your security, IT or compliance team has a question this page does not answer, put it to us before you commit to anything. We would rather resolve it now than discover it at contract stage.