Private AI and research systems
Controlled AI around your own information, with the boundary written down.
The value is not the model. It is knowing exactly what it can see, what it can do, and what it can never touch unless a person says so.
The problem can appear after a demonstration: something impressive happens, but nobody can say exactly what the system had access to while it happened.
The question this practice answers
What can this thing actually see, and what can it do without asking me first?
- People holding material they will not put into a service they cannot inspect.
- Teams who need the permissions written down before anything is switched on.
- Principals who want the arrangement explained in words they can check, not in a demonstration.
What arrives
The questions this practice is brought.
Three common questions. The wording differs every time; the worry rarely does.
-
A tool answered well, but nobody could say which documents it had read. Every answer sounded equally certain, and nobody could say where it came from.
-
Confidential material cannot sit in a service hosted somewhere nobody can inspect.
-
A written permission boundary is needed before the system touches the work. It is not defined what the system may do, or who has authority to ask it to act.
What is returned
Written documentation of the whole arrangement.
-
The arrangement, written down
What runs, in which environment, holding what material, in plain words rather than a diagram nobody can check.
-
The permission statement
Every action the system may take, every action it may not, and which of them need a person to allow them each time.
-
What the material is and where it sits
Which files are in the project, how they got there and what happens to them when the work ends.
-
How to read an answer
How the source labelling works, what it does and does not prove, and where it will not help you.
-
What was not done
The parts that were considered and left unbuilt, and what building them would actually involve.
The boundary
What it can reach, and what it cannot.
This is the permission boundary for a controlled research and document system, drawn as what it can reach and what it cannot. Each row carries the state role it holds. The roles are written out, never signalled by colour alone.
Inside the boundary
- The model A chosen model or model layer, selected for the material and the operating needs, and held inside the controlled environment. CONTROLLED
- Where it runs A local, cloud or mixed controlled environment, chosen for the material, the access boundary and the operating needs. Access is explicit and limited to agreed people and systems. There is no public exposure by default. CONTROLLED
- Project material Only the files placed in the project are visible to it. Nothing else is in view, and material is put there deliberately rather than swept up. SELECTED
- Project state and sources The project state keeps track of where an answer came from, so each answer can name the material behind it rather than asserting itself. SELECTED
- Modes Working modes are written as system prompts. They are text you can read, change or delete, not behaviour hidden inside a product. READ-ONLY
Outside the boundary
- The web and current information No browser and no search. It has no live or current information of any kind, and it cannot fetch any. NO ACCESS
- Email and messages It cannot read them and it cannot send them. There is no mailbox, no messaging account and no route to one. NO ACCESS
- Payments and publishing It cannot spend money, buy anything, publish anything or put text anywhere a reader outside the agreed access boundary would see it. NO ACCESS
- Writing to files Nothing is written back by the system itself. Anything kept is saved by the person reviewing the work. OFF BY DEFAULT
- Anything that acts A step that would do something rather than answer something is off until a person turns it on, and it stays off between sessions. OFF BY DEFAULT
- Every gate Where an action is allowed at all, it runs only when a person allows that specific action at that moment. Consent is per action, never standing. APPROVAL REQUIRED
The permission boundary, written out. Nothing here describes a client system or names a particular model.
That is the whole of it. Reading the diagram should leave you able to say what the arrangement can reach without having to trust a description of it.
The arrangement written out: chosen model, environment, access and limits
- The environment
A local, cloud or mixed controlled environment, chosen for the material, the access boundary and the operating needs.
- The model
A chosen model or model layer, selected for the material and the operating needs, and held inside the controlled environment.
- Who can reach it
Access is explicit and limited to agreed people and systems. There is no public exposure by default.
- Project state
The work is organised as projects, and the state keeps track of where an answer came from.
- Source labelling
An answer names the material it drew on, so a person can review it against that material rather than believe it.
- Modes
Working modes are written as system prompts: text you can read, change or delete.
- Permission gates
Anything beyond answering is gated. A person reviews and allows that specific action, at that moment, or it does not happen.
- What it cannot do on its own
No browser, no search and no current information. It cannot read or send email, write files by itself, spend money or publish anything.
One action
One arrangement, with its limits written down.
Starting is an enquiry, not a payment. Describe what you are holding and what you would want it to answer, and I will tell you honestly what is built, what is not, and whether it is worth doing at all. It is scoped as a special project, so the enquiry goes on the project form.