Briefing paper
How a private platform stays in your control
What stays inside your estate, what may cross its boundary and on whose decision, and what your security team receives. Written to be forwarded.
Last reviewed
To keep a copy, print this page or save it as a PDF from your browser.
tlgsolutions.co.uk/assurance.html
Illustrative architecture
A private AI platform is only private if every route in and out of it is known. This page describes how we design one, section by section: what we propose, which is confirmed or changed in your scope, the decisions that are yours, and the evidence your reviewers can check. Where something depends on a choice you make, we say so. If anything here does not match what your security team needs, that is the conversation to have before anything is built.
Teal lines run inside your estate. Dashed lines lead outside it. Each numbered gate is a crossing you decide.
Key to the diagram
- Your people People reach the platform over your network, through your identity provider and your conditional access rules.
- Identity and access Every person and every service signs in through your identity provider; nothing is reachable anonymously.
- Data Documents, extracted text, embeddings and the vector index are stored in your tenancy or data centre, encrypted at rest.
- Model An open weight model runs on GPU compute you control. If you choose a managed model instead, the provider runs it in your own subscription and UK region, through gate 2.
- Logs and backups Logs go to your monitoring tools and backups to your storage, kept for the periods your policies set.
- Admin access Administrators use named accounts with time limited elevation, and every session is logged.
- 1. Updates and model weights Patches, images and model versions come in through one checked route, then through your change process.
- 2. Managed model service Only if chosen: a managed model deployed in your own subscription, with prompts and answers processed in your UK region under your agreement. Global or Data Zone types process prompts in other regions, so they are used only if your security team allows it.
- 3. Vendor telemetry Switched off where it can be, blocked by the allow list, and anything left is listed for your decision.
- 4. Supplier support Accounts you issue, sessions you agree, every one logged in your tools.
- 5. Your document sources Each connector is listed with its direction, the data it reads and the identity it uses.
Data boundary
The estate boundary is the line round the infrastructure you control: your cloud subscriptions, your data centre and the networks between them. The design starts by drawing that line and listing everything that crosses it.
What we propose
- Documents, the text extracted from them, embeddings and the vector index are stored in your cloud tenancy or data centre, in the region or site you choose.
- Prompts, answers and any conversation history are processed and stored there too, when the model runs on compute you control.
- Stores are encrypted at rest. Where your platform supports it, the keys are held in your own key vault or hardware, under your control.
- Components talk to each other over private networking. There are no public endpoints unless one is agreed and recorded in the design.
- Outbound traffic is blocked unless its destination is on an allow list that your team approves.
You decide
- Model hosting. With an open weight model on compute you control, prompts and answers are processed only on infrastructure you run. With a managed model, such as an Azure OpenAI model deployed in your own subscription as a regional pay as you go or provisioned deployment, prompts and answers are processed in the UK region you chose and your data stays in your tenancy, under your agreement with the provider. Global and Data Zone deployment types can process prompts in other regions, such as the EU or the US, so we use them only if your security team chooses to allow it. Any retention for abuse monitoring is also a decision we set out for you.
- Telemetry. Operating systems, GPU drivers, inference servers and databases often send usage or diagnostic data to their vendors by default. We switch off what can be switched off, block the rest at the allow list, and list anything that remains so you can accept or refuse it.
- Updates. Security patches, container images and new model versions come from outside the estate. They arrive through one defined route, such as a registry or mirror inside your estate, are checked against the publisher's signatures or hashes where they are published, and are deployed through your change process.
- Support access. If we support the platform, we sign in through your identity provider with accounts you issue, for sessions you agree, and every session is logged in your tools. There is no standing access and no route that bypasses your controls.
- Integrations. Every connection to another system, such as a document store or a ticketing tool, is listed with its direction, the data it reads or writes and the identity it uses. If your documents already live in a cloud service such as Microsoft 365, that service sits inside your boundary on the terms you already have with its provider, and the design says so in writing.
You can check
- A data flow diagram with every store and every crossing labelled.
- A data inventory: each store, what it holds, where it is, who owns it and how long it is kept.
- The egress register: every allowed outbound destination, its purpose and who approved it.
Identity and access
Nobody reaches the platform anonymously, and the platform never becomes a way round the permissions you already have.
What we propose
- People sign in through your identity provider, such as Microsoft Entra ID, using single sign on, so your existing multifactor and conditional access rules apply.
- Access is granted to groups you already manage, not to individual accounts created on the platform.
- The access rule: people only get answers drawn from documents they are already allowed to open. Where a source system exposes its permissions, they are carried through to retrieval. Where it does not, documents are split into separate collections, one for each audience.
- Services use managed identities or certificates rather than shared passwords, and any secrets are held in your key vault, never in code.
- Administration uses separate named accounts, with elevation that is time limited where your identity platform supports it. Break glass accounts are documented, monitored and tested.
You decide
- Who may use the platform, and which groups may see which collections.
- Whether conversation history is kept, for how long, and who may read it.
- Whether people outside your organisation, such as research collaborators or partners, are given access, and on what terms.
You can check
- A role and permission matrix: each role, its group in your directory, what it can see and what it can change.
- Acceptance tests with accounts that should be refused, showing each one cannot retrieve a document it could not otherwise open.
- The list of every service identity and what it is allowed to reach.
Logging and change
Everything that matters is recorded where your team already looks, and nothing changes outside your change process.
What we propose
- Sign ins, administrative actions, configuration changes and document ingestion are logged to your own monitoring tools, such as Microsoft Sentinel or the logging platform you already run.
- Logs are kept for the periods your policies set, in storage you control.
- Infrastructure, configuration and pipelines are defined in code, held in your source control, and changed only through reviewed pull requests and your change process.
- A new model version is treated as a change. The agreed test questions are run against it, and the results are recorded before it is promoted.
- Emergency changes use break glass access and are recorded and reviewed afterwards.
You decide
- Whether prompts and answers are logged in full. Full logging helps audit and quality review, but it creates a new store of sensitive text. The alternatives are logging metadata only (who, when, which collection) or keeping full text for a short period. We set out the trade off; your data protection and security teams choose.
- Which events raise an alert, and who receives it.
You can check
- The logging specification: each event, where it goes and how long it is kept.
- The repository history and pipeline runs for every change.
- The test results recorded for each model version.
Operating model
A private platform is a service, not a project. Who runs which part is written down before it goes live. If you are starting from a prototype, the prototype to operated platform map puts these decisions in order.
What we propose
- A named owner in your organisation for every control, with TLG named only where we have agreed to carry it.
- Monitoring of capacity, availability and answer quality, reported into your existing tools.
- Patching and model updates on a cycle agreed with your team, through the updates route described above.
- Incidents follow your incident process. If we support the platform, we join it; we do not run a separate one.
- Backups cover what cannot be rebuilt from code: configuration not held in code, conversation history if kept, and logs. The vector index can be rebuilt from the source documents, and the design records how long that takes. A restore is tested before handover.
You decide
- Who runs it: your own engineers, TLG alongside them, or TLG for an agreed period before a full handover.
- How answer quality is reviewed after go live, and by whom.
You can check
- The control owner table, in the architecture pack.
- Runbooks for routine operation, restore and incident response.
- The record of the restore test.
Handover
You should be able to run, change or rebuild the platform without us.
What we propose
- The code, configuration and documentation we write are yours, in your source control.
- Software and model licences are taken out in your organisation's name, so nothing depends on an account held by TLG.
- Runbooks and the architecture pack are updated to match what was actually built.
- Your engineers rebuild an environment from the repository, with us present, before handover is signed off.
- At handover, our accounts are removed or disabled and any credentials we used are rotated. Your logs show both.
You decide
- Whether to keep architecture oversight afterwards through our AI Solution Architect retainer. Nothing in the platform requires it.
You can check
- The handover checklist, signed by both sides.
- The rebuild record.
- Your own sign in logs, showing our access ended.
The architecture pack
Every platform build comes with an architecture pack. These are the headings it is written under.
Architecture pack
Private AI platform ยท Sample structure
TLG Solutions
- 01
Assumptions
What we took as given, such as the identity provider in use, the expected number of users and the document stores in scope, so your team can challenge each one.
- 02
Trust boundaries
Where the estate boundary runs, the zones inside it, and what is allowed between them. Drawn and described.
- 03
Egress
Every crossing of the boundary, in or out: its direction, source, destination, the data it carries and who approved it. Anything not listed is blocked.
- 04
Failure modes
What happens when a component fails, a model gives a wrong answer or a source is unavailable, and how each is detected.
- 05
Control owners
Each control, the person accountable for it, and whether it sits with your team or with us.
- 06
Acceptance checks
The tests the platform must pass before it is accepted, including access tests with real accounts and a restore.
- 07
Open decisions
What is still undecided, the options, a recommendation, the owner of the decision and the date it is needed by.
03 Egress: crossing register, sample entries
Illustrative entries. A real pack lists your own crossings.
| Direction | Source | Destination | Data | Decision |
|---|---|---|---|---|
| DirectionIn | SourceVendor update and model repositories | DestinationMirror inside the estate | DataPatches, container images, model weights | DecisionAllowed after checks |
| DirectionOut and back | SourceRetrieval service | DestinationManaged model endpoint, private | DataPrompts with passages; answers | DecisionOpen decision |
| DirectionOut | SourceInference servers, GPU drivers | DestinationVendor telemetry services | DataUsage and diagnostics | DecisionBlocked |
| DirectionIn | SourceSupplier support | DestinationAdmin access, through your identity provider | DataSupport sessions | DecisionAgreed, logged sessions only |
The pack is written for your environment during the build. The sample above shows its structure, not a client document.
Security and procurement
The facts a security or procurement colleague will ask for, in one place.
- Company
- TLG Solutions Ltd, registered in England and Wales
- Company number
- 09700159
- VAT number
- GB 462 2707 01
- Registered office
- 90c Worcester Road, Hagley, Stourbridge, England, DY9 0NJ. This is our registered office for statutory mail; we work from Oxford.
- Contact
- info@tlgsolutions.co.uk
- Data protection
- Our privacy notice covers enquiries made through this site. Enquiries from the request form are delivered to our Microsoft 365 mailbox, and Microsoft processes them on our behalf.
- Security questionnaires
- We complete supplier security questionnaires.
- Confidentiality
- We sign mutual NDAs on request.
- Standards
- We design to the CIS Benchmarks and Critical Security Controls, the NCSC Cloud Security Principles and the Microsoft cloud security benchmark.
Need something not listed? Email info@tlgsolutions.co.uk.
Terms used on this page
- Estate boundary
- The line round the infrastructure you control: your cloud subscriptions, your data centre and the private networks between them.
- Public AI service
- A consumer chat tool or shared AI service used over the public internet on the provider's terms. We do not use one.
- Open weight model
- A language model whose trained weights are published, so it can run on your own compute.
- Managed model
- A model the provider runs for you, deployed in your own cloud subscription and region, such as an Azure OpenAI deployment in a UK data centre.
- Embeddings and vector index
- Numerical representations of passages from your documents, and the database that searches them.
- Egress
- Any traffic leaving the estate boundary.
- Allow list
- The approved list of outbound destinations. Anything not on it is blocked.
- Control owner
- The named person accountable for a control working, such as access reviews or backups.
Changes to this page
- 15 October 2026: First published.
Ask the questions your security team will ask.
Send us their questions, and we will show you how a design would answer them.
Thank you. Your request is on its way. We will reply from info@tlgsolutions.co.uk to arrange a first discussion.
That did not send. Please email info@tlgsolutions.co.uk instead, and we will reply from there.