Permission test
Retrieval must preserve the source boundary
Indexing material from several systems can flatten permissions unless access is carried into retrieval and kept current.
- Approved access The person can open the original item
- Permission-aware record Collection or filter retains the authorised group
- Identity applied Retrieval checks the current user and permission state
- Removal propagates Leavers, revoked access and deletion update the index
Test both allowed and denied cases. A relevant answer is still a failure if it reveals a passage the user could not access at source.
Running an AI workload on infrastructure your organisation controls can reduce the number of external processors and give you more control over data routes. It does not make the activity lawful, secure, accurate or transparent by default.
This page is practical information, not legal advice. Use the ICO’s current AI guidance and involve the organisation’s data-protection lead.
Map the whole data route
Document what enters the system and every place it can go:
- prompts, uploaded files and retrieved passages;
- embeddings and vector stores;
- chat history, application logs and audit logs;
- model or interface telemetry;
- backups, snapshots and exports;
- support access;
- any hosted fallback or external connector.
“The server is on our premises” does not answer whether a plugin, model downloader, monitoring tool or fallback API sends data elsewhere.
Establish purpose and lawful basis
State the business purpose and the personal data genuinely needed. Identify the lawful basis and any Article 9 condition for special-category data where relevant.
Do not reuse a broad model deployment as permission to process every accessible document. Scope the corpus and user population to the agreed purpose.
Decide whether a DPIA is required
AI can introduce systematic evaluation, novel technology, sensitive data, large-scale processing or effects on people. Consider the ICO’s DPIA screening guidance early. A DPIA is most useful before architecture and procurement choices become expensive to change.
Record necessity, proportionality, risks, controls, residual risk, consultation and review triggers.
Preserve access permissions
A retrieval system can accidentally flatten permissions by placing material from many sources into one index. Users must not retrieve a passage they could not access in the source system.
Use separate collections, group-aware filters or another tested control. Include permission changes, leavers and index deletion in the operating process.
Minimise and retain deliberately
Choose what is stored:
- whether prompts and responses persist;
- whether uploaded documents are copied;
- how long embeddings and logs remain;
- when backups expire;
- how test and production data differ;
- who can export conversations.
Set the minimum useful retention and test deletion. Embeddings can still relate to personal data and should not be treated as automatically anonymous.
Support transparency and rights
Users and affected people may need clear information about purpose, data use, recipients, retention, rights and significant automated decision-making.
Design routes to find, correct, restrict or delete relevant material where required. This can involve source data, indexes, logs, conversation histories and backups. A local box without an operating process does not make rights handling simple.
Treat output accuracy separately
Generative output can be fluent and wrong. Grounded retrieval and citations can help, but do not eliminate error.
Define where human review is mandatory. Avoid unsupervised material decisions about employment, credit, legal rights, health or safety without specialist review and appropriate safeguards.
Apply a security baseline
The initial configuration should address:
- named identity and least privilege;
- network restriction and remote administration;
- secret storage and credential handover;
- encryption where appropriate;
- secure configuration and patch ownership;
- logs, alerts and retention;
- backup, restore and incident response;
- model and container provenance;
- physical security.
Security after handover is shared responsibility. The customer usually owns its network, identity lifecycle, business continuity, use policy and ongoing operational decisions.
Keep hosted fallback explicit
A hybrid route may be sensible, but users need to know which tasks and data may leave the local boundary. Do not silently route a failed local request to a cloud model.
Use policy, technical controls and visible user cues. Record provider terms and data-processing arrangements at the decision date.
Evidence to retain
Maintain:
- data-flow record;
- purpose and lawful-basis decision;
- DPIA or screening outcome;
- approved data sources;
- model and software register;
- user and administrator access records;
- retention and deletion tests;
- quality and refusal evaluation;
- security and recovery evidence;
- incident and change records.
Local hosting can support a strong control case. The case comes from the designed system and operating evidence - not the location label alone.
Technical context
See the physical and operating boundary
Use these views to connect the guide to the machine, its airflow and its operating environment. Captions state the limits of what each image shows.
Evidence register
Make the control case inspectable
Policies become credible when they connect to dated technical and operational evidence.
- Decision record Purpose, lawful basis, scope and DPIA or screening outcome
- Technical proof Access tests, retention tests, recovery and security evidence
- Use safeguards Evaluation, citations, refusals and mandatory human review
- Living register Models, software, incidents, owners and review triggers
Local hosting can support the control case. It does not prove compliance without the operating evidence around it.
Primary sources
Sources are checked at the review date. Platform terms, prices and public guidance can change; verify them at the point of decision.