Cloud & on-premises
Aprentiz is being developed for two complete delivery profiles: Sovereign Cloud and Sovereign On-Premises. The workflows, private intelligence and evidence requirements carry across both.
What “sovereign” means hereAn explicit agreement about control of data, processing, models, identity, keys, administration, updates, recovery and exit.
Two delivery profiles
The choice starts with your data, operating model and responsibilities. The platform design preserves the same business workflows and evidence across both environments.
In an agreed cloud environment
The complete Aprentiz platform in an approved cloud account, region and operating boundary. Private models, knowledge and evidence stay within the agreed processing routes.
On your approved infrastructure
The same platform on customer-approved hardware, with locally governed data, inference and administration. Ordinary private work is designed to continue without a central model service.
Both complete profiles require destination-specific qualification. A UK region, private network or encryption setting alone does not establish sovereignty or complete security.
Shared platform scope
On-premises is a complete platform profile. Cloud implementation does not remove local inference, governance or recovery from its scope.
The Workflow and Implementation Proving Grounds, controlled APIs and durable work records.
Self-hosted inference, private embeddings, governed sources and bounded persistent context.
Enterprise GRC, Aprentiz Guard, named human decisions and inspectable evidence.
Defined identities, administration, release/update controls, retained records and whole-system recovery.
Make control concrete
Implementation needs evidence of how the complete system behaves: during ordinary work, when access changes, when something fails and when recovery is needed.
Specify the account, location, private network, processing routes and provider responsibilities. Agree key custody, support access, retained evidence and the recovery/exit path. AWS and Azure are implementation paths with separate qualification needs.
Agree hardware, storage, private models, access and administration. Test installation, workload, controlled updates and clean recovery on that environment. Ordinary private work must remain usable without optional central model services.
Start with the workflow, permitted data, processing location, access responsibilities, resilience needs and existing infrastructure. The choice should follow those constraints and measured workloads.
The complete operating model: model serving, active workload, storage, evidence retention, supporting services, security, recovery and support. Pricing and hardware require a scoped assessment; an award or compute allocation is not a customer service price.
Agree the workflow and acceptance criteria, establish the permitted data and model boundary, qualify the destination, test the human journey and recovery, then make the authorised release decision. The product is in development; those steps must be evidenced for the actual installation.
