Compliance

Data protection impact assessment

Version 1.0 · Last updated 6 November 2026 · Next review 6 November 2027

A data protection impact assessment for AI inference on kvrun, covering what the platform does with personal data, the risks to the people it is about, and the measures that address them. Published by KVRUN LTD, a company registered in England and Wales under company number 17504024, with its registered office at 150 Fulmar Lane, Wellingborough, England, NN8 4AY. Questions and DPIA requests go to [email protected].

How to use this document

Under Article 35 of the UK GDPR, a data protection impact assessment is the controller's obligation. If you process personal data through kvrun, you are the controller of that data and we are your processor, so the DPIA is yours to complete and sign. We cannot do it for you, because only you know your purposes, your data subjects and your lawful basis.

What we can do is give you every processor-side fact the assessment needs, which is our duty under Article 28(3)(f). That is what this pack is. It sets out what the platform does with personal data, the risks we have identified in doing it, the measures that address them, and the residual risk we believe remains. Sections 1 to 7 are our own assessment of the processing we perform. Section 8 lists what you have to add.

This pack covers the platform. Processing on the kvrun website itself, where we are the controller rather than a processor, is a separate matter: website analytics and advertising measurement are described in the cookie policy, and the rest in the privacy policy.

1. Why a DPIA is needed

A DPIA is required where processing is likely to result in a high risk to individuals. Running an open model on personal data will usually meet at least one of the ICO's screening criteria, and often several. The ones that typically apply are:

• Innovative technology. Large language model inference is expressly called out by regulators as novel processing whose risks are not yet well understood.
• Large-scale processing. Production inference over a customer base, a document corpus or a support queue is rarely small-scale.
• Special category or criminal offence data, Article 9 or 10, where prompts carry health, biometric, legal or similar material.
• Evaluation or scoring, where model output informs a decision about someone, such as triage, eligibility or risk ranking.
• Matching or combining datasets, where retrieval pulls together records that were collected separately.
• Vulnerable data subjects, including patients, claimants, employees and children.

If none of those apply to your use, you may not need a DPIA at all, and a record of that screening decision is enough. If any do, you need one, and the rest of this pack feeds it.

2. Description of the processing

Nature of the processing

A kvrun deployment is one open-weight model running on an accelerator reserved for a single workspace, reachable only at its own OpenAI-compatible endpoint. The customer sends a prompt; the model computes attention keys and values for every token, which is the KV cache; the model generates a response; the response is returned. Optionally, the customer trains a LoRA or QLoRA adapter on a dataset they upload, and serves that adapter on the same governed stack.

Personal data reaches us only because the customer puts it there, in a prompt, in a retrieved document, or in a training dataset. We do not collect it from data subjects ourselves, we do not enrich it, and we do not use it to train any model of ours or anyone else's.

Categories of data and where each one lives

The audit log records *that* a cached block was allocated, moved, read or erased, not what it contained. It is the evidence trail, not a copy of the data.

Scope

• Volume is whatever the customer sends. A deployment is sized from peak concurrency rather than from a quota, so there is no architectural ceiling on how many data subjects may appear in prompts.
• Geography. Compute is provisioned in the United Kingdom by default, in London. Object storage for personal data originating in the UK or EEA is configured to a UK or EU region.
• Duration. Processing lasts as long as the deployment exists. Context lasts as long as the session.
• Data subjects are whoever the customer's prompts are about: their customers, patients, claimants, employees or counterparties. We have no direct relationship with any of them.

Context

Customers are businesses, typically in financial services, legal, healthcare and the public sector or their suppliers, who have chosen dedicated infrastructure precisely because shared inference APIs did not meet their obligations. Data subjects have no relationship with kvrun and will generally not know we exist, which is why transparency sits with the controller and why our role must be disclosed in the controller's own privacy information.

Where the workload runs changes who controls the infrastructure, and the four placements are described in Where your workloads run. In a connected cloud account the instance is in the customer's own tenancy. In a self-hosted installation, no prompt, completion, weight or log reaches us at all: the only traffic back to us is a licence check carrying the licence key, a machine identifier, the version, the hostname and a count of running models and GPUs. For that deployment model, kvrun is not a processor of customer content at all.

Purposes

Ours are narrow, and limited to providing the service: serving inference, holding context so that it can be served efficiently, training an adapter when asked, producing compliance evidence, billing, security and support. We have no secondary purpose. We do not train on customer content, we do not profile data subjects, and we do not sell or share anything.

3. Consultation

In carrying out this assessment we have taken into account the published positions of the ICO and the European Data Protection Board on AI and large language models, the security questionnaires and DPIA requests sent to us by prospective customers in regulated sectors, and published security research on inference infrastructure, including the KV cache and prefix cache attacks described in Is prefix caching safe?.

We have not consulted data subjects directly, because we have no relationship with them. That consultation, where it is appropriate, belongs to the controller. If your DPIA concludes that a residual high risk remains after your measures and ours, Article 36 requires you to consult the ICO before processing, and we will support that with whatever detail they ask for.

4. Necessity and proportionality

This section is about whether the processing is justified, not whether it is secure.

Proportionality is where most AI DPIAs are weakest. The question is not whether the model is useful, but whether putting this personal data through a model is a proportionate way to achieve your purpose, and whether a narrower input would do. We can make the processing safe; we cannot make it necessary.

5. Risks to individuals, and the measures that address them

Each risk below is rated for inherent risk, which is the risk if nothing were done about it, and residual risk, which is what we believe remains once the measures listed are in place. Ratings are our own assessment and you should form your own.

R1. One customer's data reaching another through the cache

Inherent risk: high. Prefix caching makes serving faster by reusing cached attention blocks when two requests begin with the same tokens. If those blocks are shared across tenants, one customer's request can reuse state created by another, and published research shows timing differences alone can be enough to recover another user's prompt.

• Each deployment is a dedicated accelerator for one workspace, so no other customer shares the serving engine.
• Within a deployment, each cached block is sealed with AES-256-GCM under a key unique to the workspace and session, with separate key hierarchies per tenant.
• Cached blocks are never shared across tenants, so the prefix cache cannot be probed across a tenant boundary.
• Sending an X-KV-Tenant header extends the same separation to each of the customer's own end users, so two of your users sending byte-identical prompts do not share a block.

Residual risk: low. It is not nil: a customer who serves many end users from one deployment and does not send the tenant header leaves those users sharing a cache partition, which is an acceptable design for an internal tool and not for a multi-customer product.

R2. Context readable by anyone with access to memory or storage

Inherent risk: high. In a conventional serving stack the KV cache sits in plain form in GPU memory, host memory and, once offloaded, on disk. It is usually the least protected copy of the data, and tiering multiplies the number of copies.

• Blocks are sealed with authenticated encryption before they leave the accelerator and stay sealed through host memory, local NVMe and object storage.
• Keys are held per workspace and session, and a self-hosted installation generates its sealing key on the customer's own machine, where it stays.
• Encryption, policy checks and audit writes add under 3% to time to first token and under 2% to throughput on our internal benchmarks, so the protection does not create pressure to switch it off.

Residual risk: low. Data in active use on the accelerator must be processed in the clear by the model, which is inherent to inference rather than specific to kvrun.

R3. Erasure that cannot be proved, Article 17

Inherent risk: high. "The cache will be overwritten eventually" is not an answer a controller can give a regulator or a data subject. Copies in offload tiers can outlive the request that created them, and no amount of searching reliably finds every one.

• Erasure is performed by destroying the session's key, which makes every copy of every block on every tier unreadable at once rather than hunting for them.
• Each erasure produces a certificate recording what was erased and when, which is the artefact you hand to a data subject or an auditor.
• Erasing a session completes in under a minute.
• The append-only, hash-chained audit log records the erasure alongside the allocation and access events for the same session.

Residual risk: low. Two caveats belong in your own DPIA. A certificate evidences destruction of the key that protected the data, which is a strong technical control and not the same statement as proof that no plaintext ever existed anywhere. And erasure of context does not reach personal data you have separately stored in a dataset, an adapter or your own application logs: those you must delete yourself.

R4. Personal data persisting in a fine-tuned adapter

Inherent risk: medium. An adapter trained on personal data is derived from it. Small adapters trained for many epochs on small datasets can memorise examples, and a model can sometimes be prompted into reproducing them.

• The base model is frozen; only the adapter is trained, and it stays in the customer's own workspace storage.
• Training runs on an accelerator that shuts down when the job finishes, and the dataset is not retained beyond the customer's own storage.
• Adapters are cheap to retrain, so honouring an erasure request by retraining without the affected records is realistic rather than theoretical.

Residual risk: medium. This one does not reduce to low through infrastructure, and we are not going to pretend otherwise. It is managed by minimising the training set, limiting epochs, testing the tuned model for verbatim recall, and treating the adapter as containing personal data for access, storage and erasure. See LoRA vs QLoRA.

R5. Data leaving the United Kingdom

Inherent risk: medium. Inference platforms commonly route requests to whichever region has capacity, and a control plane in another jurisdiction can reach the data even when compute is local.

• Compute is provisioned in London by default, and placement is pinned by policy rather than chosen opportunistically. There is no cross-region overflow to disable.
• Object storage for UK and EEA personal data is configured to a UK or EU region.
• kvrun is a UK company, KVRUN LTD, registered in England and Wales, so there is no group-level transfer of customer content to another jurisdiction by default.
• Where any transfer outside the UK or EEA does occur, it relies on the Standard Contractual Clauses with the UK Addendum, or an adequacy decision, with supplementary measures where needed.
• Processing locations and the transfer safeguard for each sub-processor are provided at contracting.

Residual risk: low, for the managed UK placement. Confirm the region configuration before uploading personal data if you carry a UK-only clause, and record the answer.

R6. Output that is wrong, unfair, or acted on without review

Inherent risk: high, and it is the risk most often missing from AI DPIAs, which tend to stop at security. Model output is generated rather than retrieved. It can be fabricated, out of date, or skewed by bias in the base model's training data, and a decision taken on it can affect someone's access to a service, their money or their treatment.

• The customer chooses the model and pins the exact weights, so behaviour does not change underneath a validated process without their action.
• Every response from a self-hosted installation, and from the managed platform, passes through a marking proxy that marks it as AI-generated in line with Article 50 of the EU AI Act, signed under a key held by the installation.
• Open weights can be evaluated, red-teamed and archived before deployment, which closed models cannot.

Residual risk: medium, and controller-owned. Infrastructure cannot make a model correct. This risk is reduced by human review before any decision about a person takes effect, by evaluating the model on your own cases rather than public benchmarks, by not using inference for Article 22 solely automated decisions without the required safeguards, and by telling data subjects that AI is involved.

R7. Disclosure through prompt injection or over-broad retrieval

Inherent risk: medium. If the application puts retrieved documents or untrusted text into the prompt, content in them can steer the model into disclosing material the current user should not see. The infrastructure cannot tell a legitimate instruction from an injected one.

• The endpoint is reachable only from the source addresses on the deployment's allowlist, and every request also needs the deployment's API key.
• Per-end-user cache separation via X-KV-Tenant stops one user's context being reused for another.
• Keys are rotated from the deployment page rather than by redeploying, so a suspected exposure is closed quickly.

Residual risk: medium, and controller-owned. Authorisation must be enforced at retrieval time, in your application, so that a prompt only ever contains what the requesting user is entitled to see. No inference platform can fix an over-broad retrieval query.

R8. Excessive access by our staff, or by a sub-processor

Inherent risk: medium. Support and operations work can become a route to customer content, and a sub-processor failure can expose data the controller never chose to share with that party.

• Access to cached context is logged in the append-only audit log, and the log is exportable, so access is evidenced rather than asserted.
• Workspace roles separate what members can do, and are described in Workspace and access.
• Each sub-processor is security-reviewed before onboarding and bound by an Article 28 contract, with the current list published on the trust centre.
• Material additions or replacements are announced to workspace owners with 30 days' notice, and customers may object on reasonable data protection grounds.
• Our information security management system is being built towards ISO/IEC 27001 certification with the British Assessment Bureau.

Residual risk: low to medium. ISO 27001 certification is in progress rather than held, and we say so on the trust centre rather than implying otherwise. Treat the certification as a roadmap item in your supplier assessment, not a completed control.

R9. Loss of availability or integrity

Inherent risk: medium. Article 32 covers availability and resilience as well as confidentiality, and a model that is part of a service pathway becomes a dependency for the people using it.

• Deployments are dedicated instances, so another customer's load cannot displace yours.
• Object storage is encrypted and backed up.
• A deployment pinned to a customer's own cloud account fails rather than silently relocating to our fleet, so data never moves to a tenancy the customer chose to avoid.
• A self-hosted installation keeps serving for 30 days with no contact with us, and a lapsed commercial licence never stops a model that is already serving.

Residual risk: medium. We are a young company and we are not going to claim hyperscaler resilience. If the processing is critical to a service that people depend on, assess our resilience against that, keep a fallback, and read the availability terms in the Terms of service.

R10. Special category data arriving without an Article 9 condition

Inherent risk: high in healthcare, legal and claims work. Free-text prompts attract health, biometric and criminal offence data whether or not the design anticipated it, and the platform cannot detect or refuse it.

• The controls in R1 to R3 apply to all content regardless of category, so special category data is sealed, isolated and erasable on the same terms.
• The Acceptable use policy sets out what the service may not be used for.

Residual risk: controller-owned. You need an Article 9 condition and, in the UK, a Schedule 1 condition and an appropriate policy document where one is required. Decide deliberately whether special category data may enter prompts at all, and if it may not, enforce that in the application rather than in a guideline.

6. Risk register

A summary of the above, for the register in your own DPIA. "Owner" says who is positioned to reduce the risk further, not who is liable.

7. Outcome and sign-off

Our conclusion, for the processing we perform as processor, is that the identified risks are reduced to a level that supports lawful processing by a controller who completes the controller-side measures in section 8, and that no residual high risk remains that would require us to stop. The residual risks we have rated medium, R4, R6, R7 and R9, are disclosed above rather than minimised, because a DPIA that reports no remaining risk is not a credible one.

Where a customer's own DPIA identifies a risk we have not covered here, tell us. If the measure belongs on our side, we would rather build it than argue about the boundary.

8. What you must complete as controller

This is the part we cannot write. Taking this pack as the processor-side input, your own DPIA still needs:

1. Your purpose, stated specifically enough to test proportionality against. "Improving efficiency" is not a purpose.
2. Your lawful basis, and for special category data your Article 9 condition and UK Schedule 1 condition.
3. The categories of personal data and data subjects that will actually appear in prompts, retrieved context and training data, including what will arrive in free text whether you intended it or not.
4. Your minimisation decisions: which fields are removed, masked or tokenised before a prompt is built, and what you deliberately chose not to send.
5. Your transparency measures: how data subjects are told that AI inference is used and that a processor is involved.
6. Your rights procedures, including how an access or erasure request reaches our session erasure and your own datasets, adapters and application logs.
7. Your retention periods for prompts, outputs and logs that you store in your own systems, which are outside our control.
8. Human oversight: who reviews output before it affects anyone, and the Article 22 position if a decision is solely automated.
9. Your consultation, with data subjects or their representatives where appropriate, and with the ICO under Article 36 if a residual high risk remains.
10. Sign-off by your own accountable owner and, where you have one, your DPO's advice, which Article 35(2) requires you to seek and record.

If it would help, send us the draft and we will complete the processor-side sections against your template and flag anything we think you have understated. Ask at our contact page.

Supporting evidence

Documents and pages that a reviewer of this pack usually wants next:

• Trust centre, including the sub-processor list and the answers to the security questionnaire buyers send, downloadable as a PDF.
• Privacy policy, covering our controller and processor roles, retention and transfers.
• Governed KV cache, the technical detail of sealing, tiering, isolation and the audit log.
• Where your workloads run, for the placement options and what changes with each.
• Terms of service and the Acceptable use policy.
• The Data Processing Addendum, which contains the Article 28 terms and is available on request.