kvrun vs Azure OpenAI: AI governance and security compared

· 6 min read · kvrun team

Azure OpenAI is the default choice for many enterprises, and it is a strong one. kvrun is an alternative for teams that need open models on dedicated GPUs, a KV cache they can prove is isolated and erased, and UK-only processing. This page compares the two on the controls that matter for AI governance and security, and says where Azure wins.

This comparison describes Azure's publicly documented behaviour at the time of writing. Azure's terms, regions and approval processes change, so check Microsoft's current documentation and your account team before you decide.

Summary

AreaAzure OpenAIkvrun
ModelsOpenAI and partner models hosted by MicrosoftOpen models (Qwen, Gemma, Mistral, DeepSeek) on your own deployment
Default retentionAbuse-monitoring logs kept up to 30 days unless you are approved for an exceptionKV cache held for the session; erasure on request by key destruction
Zero-retention pathModified abuse monitoring or zero data retention, subject to Microsoft approvalGoverned KV cache by default, with no provider-side logging of your content
ResidencyChoice of regional, data zone or global deployment; global may process outside your regionLondon region by default, with policy that pins compute and storage
KV cache isolationManaged by the service; isolation is Microsoft's responsibility to describeSeparate key hierarchies per tenant; prefix caching never crosses tenants
Erasure evidenceDeletion of stored data per Microsoft's documented processErasure certificate per session, and an append-only audit log
EcosystemEntra ID, Microsoft 365, Azure AI Search, broad enterprise integrationsOpenAI-compatible API, scoped workspace keys, no seats

Retention and abuse-monitoring defaults

Azure OpenAI stores prompts and completions for abuse monitoring by default. Microsoft's documentation describes these logs as retained for up to 30 days, after which they are deleted. Customers with a qualifying use case can apply for modified abuse monitoring, which removes customer content from those logs, or for zero data retention, which also changes how the store parameter behaves. Both are subject to approval and to the Enterprise Agreement or Microsoft Customer Agreement route, so they are not a switch you can flip in the portal.

kvrun's position is different by design. The KV cache is held for the session, and erasure does not wait for a retention window to expire: it is done on request by destroying the session's keys. Confirm your retention terms for application logs in your contract. The erasure process is covered below.

Zero-retention approval path

  1. Azure: confirm whether your agreement and use case qualify, then apply for modified abuse monitoring or zero data retention. Approval is in Microsoft's hands and can take time.
  2. kvrun: the governed KV cache and session erasure are on by default for every deployment. There is no request to file and no waiting period before your data is handled this way.

If your contract requires zero retention from day one and you cannot wait for an approval decision, that is a point in kvrun's favour. If you already hold an approved exception with Microsoft, Azure's position is strong and the comparison narrows.

Regional vs global deployment

Azure offers several deployment types. Standard (regional) processes inference in the deployment region. Data zone limits processing to a Microsoft-defined zone such as the EU. Global Standard routes requests to any available region, so inference data may be processed outside the region of your resource, even though data at rest stays in its geography. Global is usually the default because it gets new models first and has broad capacity.

If UK residency is a contract term, the deployment type matters as much as the region name. Choose regional, and check the documentation for which features are available in that mode. kvrun runs in London by default, and every deployment stays there unless your policy says otherwise.

KV cache isolation

The KV cache is the working copy of every prompt in GPU memory, and it is the part of inference most buyers never ask about. On shared serving stacks, prefix caching can reuse cached blocks across users, which is a cross-tenant risk. Azure runs its own serving infrastructure, and Microsoft documents the security boundary for the service as a whole. The customer-facing question is whether a cached block from one tenant can ever be read by another, and the answer should be written into your contract.

kvrun's answer is structural. Each block is sealed with AES-256-GCM under a key unique to the workspace and session, separate key hierarchies apply per tenant, and cached blocks are never shared across tenants. Early internal benchmarks show under 3% added time to first token for this, so the isolation does not cost you the throughput that made you pick GPUs in the first place.

Erasure proof

Under UK GDPR Article 17, you need to erase personal data when a valid request applies, and to be able to show that you did. Azure's documented process deletes stored data, and abuse-monitoring logs are removed within their retention window. What you cannot easily get from a managed service is a per-session record that ties a specific deletion to the copies it covered.

kvrun erases by destroying the session key. Every copy of a block on every storage tier becomes unreadable at once, and a certificate records the erasure. Erasing a session takes under a minute. The GDPR Article 17 guide explains why this is stronger than overwriting, and what a certificate does and does not prove.

Cost model

Azure OpenAI bills per token for the models you call, with separate charges for provisioned capacity and other features. kvrun bills per hour of accelerator time plus storage, with no seats. The right comparison depends on volume:

  • Spiky or low volume: per-token pricing usually wins, because you pay only for what you use.
  • Steady, high volume on one model: dedicated GPUs often win, because the marginal cost per token falls as utilisation rises.
  • Sensitive data at any volume: compare the price of the governance controls, not just the tokens. Some of Azure's controls sit behind approvals, and some sit in your own engineering time.

Run both on your own prompt set and your own volume before you decide. Token counts vary a lot by workload, and the cheapest option on a benchmark is not always the cheapest in your environment.

Where Azure wins

  • Microsoft estate. If you run on Entra ID, Microsoft 365, Azure AI Search and Azure networking, the integration work is already done.
  • Model breadth. Azure gives access to OpenAI's frontier models, which kvrun does not host. If you need those specific models, Azure is the choice.
  • Procurement. If you already buy through an Enterprise Agreement, adding Azure OpenAI is a familiar purchase, with existing SLAs and terms.
  • Scale and certifications. Azure has a long compliance record and capacity that a smaller provider cannot match.

Where kvrun is the better fit

  • You want open models on dedicated GPUs, with control over the model and its serving.
  • You need UK-only processing with no global routing, and a clear answer to residency in your contract.
  • You need zero retention from day one, without waiting for an exception.
  • You need an erasure certificate per session for Article 17 requests.

Questions

Is kvrun a drop-in replacement for Azure OpenAI?
For many applications, yes. kvrun exposes an OpenAI-compatible API, so changing the base URL and key is often the main change. Check model names and any Azure-specific features you rely on.
Does kvrun train on my data?
No. Your prompts and the KV cache built from them are not used to train any model.
Can I use both?
Yes. Many teams keep Azure for workloads that need frontier models and move sensitive workloads to governed inference.