Use cases
Run AI-assisted development on-prem
For organizations where even private cloud is a step too far: AI-assisted engineering on your own hardware, with own-LLM options, under separate terms.
On-prem AI app development means running AI-assisted engineering and the applications it produces on infrastructure your organization physically controls. Ciao supports on-prem deployment under separate terms, with own-LLM options and a multi-provider model ladder. Unlike cloud-only AI builders, Ciao pairs the full delivery loop — governed branches, human approvals, QA, live security testing, append-only audit trail — with deployment that never requires your workloads to leave your environment.
Published 2026-07-03 · Last updated 2026-07-03
When the answer to which cloud is none
Some organizations end every SaaS evaluation the same way: the workload cannot leave the building. Manufacturing plants that keep operational systems on site, government agencies with mandated infrastructure, banks whose control frameworks predate the cloud, utilities and telecoms running critical operations — for them, which cloud region is the wrong question. The infrastructure is theirs, physically, and the software must come to it.
That stance has priced these organizations out of most of the AI development wave. The tools that turn plain language into working software are overwhelmingly cloud-first, and the usual compromise — let the AI tooling run in the vendor's cloud while production stays on-prem — splits the lifecycle exactly where governance needs it whole.
Ciao's on-prem path, offered under separate terms, brings the AI software development lifecycle to your infrastructure rather than the reverse. The delivery loop is the same one that defines the platform: an AI software organization doing the work, Guardrails mapping business areas and enforcing plain-English policies, human approvals recorded on governed branches, QA and security gates, and an append-only audit trail. Model strategy is part of the conversation: own-LLM options exist for organizations that require them, and the multi-provider model ladder with fallback reduces dependency on any single model vendor. Customer code is never used to train models, and inference runs under zero-retention contracts.
What on-prem AI development requires
Organizations that mandate on-prem tend to arrive with the same list:
- Deployment on owned infrastructure — The platform and the applications it produces running on hardware your organization controls, under separate terms that name responsibilities precisely.
- Model control — Own-LLM options for organizations that must dictate where inference happens, and a multi-provider model ladder with fallback to avoid single-vendor dependency.
- Data and code protection — No training on customer code, zero-retention model contracts, and SOC 2 Type II reports under NDA for the assessment file.
- Identity and access — SSO via SAML or OIDC against your directory, optional MFA, and role-based access control mapped to your existing roles.
- Complete audit evidence — An append-only audit trail across prompts, merges, deploys and admin actions — the lifecycle evidence strict control frameworks demand.
- Support for the real stack — Custom sandbox images wrapping Rails, Java, Go, Python, Node and multi-process backends, because on-prem estates are rarely greenfield.
How an on-prem program runs
1. Scope the environment with sales
On-prem deployment runs under separate terms. The first step defines your infrastructure, model requirements and security constraints — including own-LLM options where mandated.
2. Stand up the platform inside
The delivery environment is established on your infrastructure, with identity wired to your SSO via SAML or OIDC and access mapped through RBAC.
3. Wrap existing systems where needed
Custom sandbox images bring your Rails, Java, Go, Python, Node or multi-process backends into the AI-assisted lifecycle — modernization and new builds share one loop.
4. Define the governance
Guardrails maps business areas, protected zones are identified, and plain-English policies encode who must approve what.
5. Build and change on governed branches
Plain-language requests become branches carrying risk assessments; flagged changes wait for recorded human approval before merging.
6. Gate every release
QA runs deterministic replays and smoke gates; Security runs scanning, dependency checks and access-control probes confirmed against the live app.
7. Operate inside the boundary
Doctor diagnoses read-only, SysOps handles drift and rollback, Conductor shows the portfolio — all within your walls.
Security and governance checklist
- ✓ On-prem deployment under separate, explicitly scoped terms
- ✓ Own-LLM options and a multi-provider model ladder with fallback
- ✓ No training on customer code; zero-retention model contracts
- ✓ SSO via SAML or OIDC, optional MFA, role-based access control
- ✓ Recorded human approvals on governed branches before merge
- ✓ Append-only audit trail across prompts, merges, deploys and admin actions
- ✓ SOC 2 Type II reports available under NDA for your assessment file
Where on-prem programs land
On-prem programs concentrate in sectors where infrastructure control is policy, not preference. These are the environments where AI-assisted development on owned hardware most often lands, and the kinds of applications it produces there:
Manufacturing plant systems
Production tracking, quality workflows and maintenance tools running beside the machines they serve, on plant infrastructure.
Government internal workflows
Case handling, approvals and records tooling on agency-controlled infrastructure, with the audit evidence oversight requires.
Bank operations tools
Reconciliation, exception handling and internal workflow applications inside a control framework that never assumed the cloud.
Utility field and asset apps
Asset registries, inspection workflows and crew tools for operators whose systems are classified as critical infrastructure.
Telecom operations consoles
Provisioning, incident and network-adjacent workflow tools that must live inside the operator's own environment.
Research and lab environments
Data-handling and workflow applications for institutions whose agreements keep every byte on site.
Requirements and how Ciao covers them
Strict-control organizations arrive with requirement lists refined over years of vendor assessments. This table maps the requirements that define on-prem programs to how Ciao meets each one — from model control to the audit evidence a control framework demands.
| Requirement | How Ciao covers it |
|---|---|
| Nothing leaves our infrastructure | On-prem deployment under separate terms |
| Control over models | Own-LLM options; multi-provider ladder with fallback |
| Code and data protection | No training on customer code; zero-retention contracts |
| Existing systems included | Custom sandboxes wrap Rails, Java, Go, Python, Node, multi-process |
| Human control of changes | Governed branches with recorded approvals via Guardrails |
| Audit and assessment evidence | Append-only trail; SOC 2 Type II reports under NDA |
| Scale within our walls | Kubernetes-based infrastructure with isolated pods, hibernation and wake |
Frequently asked questions
Is on-prem a standard Ciao plan?
No — on-prem deployment runs under separate terms, scoped against your infrastructure, model requirements and security constraints. It is an enterprise engagement that starts with a sales conversation, not a checkout page.
Can we use our own language models?
Own-LLM options exist for organizations that must control where inference happens. Alongside that, Ciao's multi-provider model ladder with fallback reduces dependency on any single model vendor — a resilience property strict environments tend to value.
Is our code or data used to train models?
No. Customer code is never used to train models, and inference runs under zero-retention model contracts. SOC 2 Type II reports are available under NDA to support your internal assessment.
Can this work with the systems we already run on-prem?
Yes. Custom sandbox images wrap AI-assisted engineering around Rails, Java, Go, Python, Node and multi-process backends, so the estate you already operate joins the same governed lifecycle as new applications.
How do humans stay in control of what the AI changes?
Guardrails maps the code into business areas, detects risky changes and applies plain-English policies; flagged changes wait on governed branches for recorded human approval. The append-only audit trail across prompts, merges, deploys and admin actions makes that control demonstrable.
What does an on-prem engagement cost?
Development programs start at USD 10,000 per year, and on-prem terms are scoped on top of that against your environment. Bring your infrastructure constraints and model requirements to sales for a concrete proposal.