The Deploy-and-Disappear Model: Eliminating Vendor Lock-In and Data Processor Liability

Every AI vendor in the UK market retains persistent access to the infrastructure they deploy. Microsoft manages your Azure tenant. Google administers your Workspace AI. OpenAI operates the inference endpoint your prompts hit. Harvey and Luminance run their platforms on their servers. In every case, the vendor maintains ongoing administrative control, ongoing data processing capability, and ongoing Data Processor status under UK GDPR Article 4(8). The vendor is permanently inside your perimeter.

Private AI Ltd is not. We build the sovereign AI environment on your firm’s own contracted infrastructure. We configure every component — compute, storage, inference layer, retrieval pipeline, access layer, egress controls. Then we hand over every credential, every key, every administrative token. And we revoke our own access.

After handover, we cannot reach your server. We cannot read your data. We cannot modify your environment. We hold no root passwords, no SSH keys, no API tokens. We are architecturally and contractually absent from your infrastructure. This is Zero-Touch Provisioning — and it is the only deployment model that eliminates vendor lock-in and Data Processor liability simultaneously.

Phase 1: Client Account Provisioning — You Own the Accounts From Day One

The deployment begins with a principle that no cloud AI vendor follows: the client provisions and owns the infrastructure accounts independently.

The firm registers its own account directly with the infrastructure provider. The firm funds the account from its own billing relationship. Private AI Ltd is not a reseller. Private AI Ltd is not an intermediary. The firm’s name is on the contract, the invoice, and the administrative console.

Private AI Ltd is then invited into the account via restricted role-based access — a deployment-scoped permission level, never administrative ownership. This is temporary, delegated access with a deliberately limited scope. Private AI Ltd can provision servers and configure services. Private AI Ltd cannot modify billing, delete accounts, or change ownership.

This matters for two reasons. First, it means the firm can revoke Private AI Ltd’s access at any time — unilaterally, without Private AI Ltd’s cooperation. The off-switch is in the firm’s hand from day one. Second, it means the firm’s infrastructure relationship is direct. Private AI Ltd is not a contractual party. If Private AI Ltd ceased to exist tomorrow, the firm’s accounts, servers, and data would be entirely unaffected.

That is the architectural foundation of zero vendor lock-in.

Phase 2: Deployment — Everything Built, Nothing Retained

With restricted role-based access granted, Private AI Ltd executes the complete deployment:

Bare-metal infrastructure provisioning — dedicated compute in a UK data centre, contracted in the firm’s name
Encrypted persistent block storage configuration — storage decoupled from the application lifecycle, mapped to a client-designated mount point
Application runtime creation — isolated environment for the user interface and vector database, ensuring dependency containment
User interface installation and configuration — chat interface and retrieval pipeline, external self-registration disabled, telemetry disabled, all data paths pointed to the encrypted block storage
Inference layer installation — installed from a cryptographically verified package, model weights loaded onto the encrypted block storage
Vector database configuration — document embeddings store, data directory mapped exclusively to the encrypted block storage
Self-hosted access layer configuration — SSO with two-factor authentication and access policies, entirely within the firm’s own controlled infrastructure
Egress hardening — the environment enforces a sealed network posture; no outbound data path to any external AI service or API
Encrypted DNS configuration — all DNS resolution via an encrypted channel, with unencrypted DNS blocked
System service configuration — the user interface and inference layer managed as native system services with automatic restart and graceful shutdown

Every component is configured to production specifications. Every telemetry endpoint is disabled. Every data path points to the firm’s own encrypted storage. Every security control is applied.

And then comes the step no other vendor takes.

Phase 3: Credential Revocation — We Remove Ourselves

Upon completion of deployment, the client explicitly revokes Private AI Ltd’s role-based access from the infrastructure account and removes all access credentials. The firm’s IT lead performs this action — not Private AI Ltd. The revocation is unilateral and immediate.

After revocation, Private AI Ltd holds:

Zero root passwords
Zero access tokens
Zero API credentials
Zero infrastructure console access
Zero paths to any layer of the client’s infrastructure

This is not a promise of restraint. It is an architectural impossibility of access. Private AI Ltd cannot reach the server because the credentials that would permit access no longer exist in Private AI Ltd’s possession. The firm did not ask Private AI Ltd to refrain from accessing the data. The firm removed the mechanism by which access could occur.

Under UK GDPR, a Data Processor is an entity that processes personal data on behalf of the controller. Private AI Ltd acts as a Standing Data Processor under Article 4(8) UK GDPR — but the Zero Standing Privileges architecture means that in the Default Operating State it holds no credentials, has no network path, and cannot reach the data. Active processing by Private AI Ltd is limited to authorised Just-In-Time Support Sessions, governed by the tiered instruction model in Schedule 2 of the standing DPA. This is not merely a contractual restraint — it is the architecture.

Phase 4: The Deployment Completion Package — Your Compliance Evidence

At the moment of credential revocation, the firm receives the Deployment Completion Package — the complete compliance and operational documentation for the sovereign AI environment.

The dependency manifest (SBOM equivalent). A complete listing of every installed package and version within the application runtime. This is the Software Bill of Materials against which future CVE monitoring is performed. Private AI Ltd monitors vulnerabilities against this offline manifest — not by accessing the client’s server — and delivers cryptographically verified update scripts when critical patches are required.

The model manifest. A listing of every model loaded on the encrypted persistent storage — model identifiers, versions, and file sizes. Confirms which models the firm is running and verifies that no unauthorised models were installed.

The compliance documentation set. This is the artefact that eliminates the compliance administration burden that typically accompanies any new infrastructure deployment:

Pre-filled infrastructure DPA template — domestic Article 28 UK GDPR agreement covering bare-metal compute and encrypted persistent storage, requiring no international transfer addendum
GDPR Article 30 Data Flow Map — identifying the infrastructure provider (UK entity, domestic DPA) as the infrastructure processor, and Private AI Ltd as Standing Data Processor under Article 4(8) UK GDPR operating under a Zero Standing Privileges architecture — with no active access credentials in the Default Operating State. No third-party access gateway or network transit provider in the access path.
Technical Configuration Letter — formal confirmation of Private AI Ltd’s Standing Data Processor status, Zero Standing Privileges architecture, and zero active access credentials in the Default Operating State post-revocation
Law Society of Scotland Technology Compliance Summary — mapping the deployment’s technical controls to the Law Society’s Guide to Generative AI requirements and professional conduct obligations

The firm’s Compliance Officer receives a complete, ready-to-file compliance package. Not a checklist of things to do. A completed set of documents that satisfy the specific regulatory obligations of a Scottish regulated professional services firm deploying AI on client data.

Why This Eliminates Vendor Lock-In

Vendor lock-in exists when a firm cannot migrate away from a provider without incurring disproportionate cost, losing data, or losing functionality. Cloud AI creates lock-in through proprietary APIs, vendor-specific integrations, and data stored on the vendor’s infrastructure under the vendor’s control.

Zero-Touch Provisioning inverts every vector:

The firm owns the accounts. The infrastructure provider is contracted directly by the firm. If the firm wants to change deployment provider, it can invite a different provider via restricted role-based access — the same mechanism it used to invite Private AI Ltd. The account does not change. The data does not move.

The firm owns the software. The user interface, the inference layer, the vector database, and the language models running on the deployment are all open-source or open-weight artefacts. No proprietary licence, no API key, no vendor-specific dependency locks the firm into Private AI Ltd’s ecosystem. The entire stack can be maintained by any competent infrastructure engineer with the SBOM manifest and the architecture documentation.

The firm owns the data. All data — prompts, responses, document embeddings, conversation histories, model weights — resides on the encrypted persistent storage under the firm’s exclusive control. No data is stored on Private AI Ltd’s systems. No migration is required because the data never left.

The firm owns the compliance documentation. The compliance documentation set, the Technical Configuration Letter, the data flow map — all delivered at handover. The firm does not need Private AI Ltd’s ongoing cooperation to satisfy an ICO audit, a Law Society inquiry, or a client due diligence request.

If Private AI Ltd closed its doors tomorrow, the firm’s AI environment would continue to operate. The server runs autonomously. The models are static. The data is local. The only impact would be the loss of ongoing CVE monitoring and guided upgrade support — both of which could be replaced by any qualified infrastructure specialist with access to the SBOM.

That is not vendor lock-in. That is vendor independence achieved by design.

The Compliance Officer’s Summary

Attribute	Cloud AI Vendor	Zero-Touch Provisioning
Who owns the infrastructure accounts?	The vendor or joint.	The firm. Exclusively.
Who holds root credentials post-deployment?	The vendor.	The firm. Private AI Ltd holds zero.
Does the vendor retain active access to your data?	Yes. Persistent credentials.	No. Architecturally prevented (Zero Standing Privileges — no active credentials in Default Operating State).
Can the firm migrate without vendor cooperation?	Typically no. Proprietary dependencies.	Yes. Open-source stack, firm-owned accounts.
What happens if the vendor disappears?	Data on vendor infrastructure. Migration required.	Nothing changes. Server runs autonomously.

What to Do Next

Step 1: Read our detailed breakdown of what is in the Deployment Completion Package and why your Compliance Officer needs every artefact it contains.

Step 2: Read our operational walkthrough of Over-the-Shoulder upgrades and why your IT lead runs the script, not us — the maintenance model that keeps Private AI Ltd outside the processor boundary even during support.

Step 3: Talk to our team to discuss the full deployment lifecycle — from account provisioning through credential revocation — and request a sample compliance documentation set for your Compliance Officer to review.

Private AI Ltd (SC881079) acts as a Standing Data Processor under Article 4(8) UK GDPR, operating a Zero Standing Privileges architecture. We deploy sovereign, zero-egress AI environments for regulated professional services. In the Default Operating State, we hold no active connection and no credentials to client systems.