Private AI vs Self-Hosted AI vs BYOC: Five Architectures, Scored Honestly
There are five real architectures for deploying AI in an organization — closed API, governed private SaaS, managed BYOC, self-hosted open source, and on-premises/air-gapped — and none of them wins every axis. The honest way to choose is to score them on the six dimensions that actually differ: control, time to deploy, evidence, staffing, egress, and cost predictability, then let your written obligations and your real staffing pick the row. As of 2026-08-28, this page does exactly that, with the reasoning visible in every cell.
The five architectures
01Closed API / public SaaS: You call a frontier model provider's hosted service directly; every plane is theirs.
02Governed private SaaS: A vendor-hosted governed workspace: per-request logging, configurable retention, zero-retention inference through a disclosed subprocessor, contractual no-training.
03Managed BYOC on AWS: The vendor's product, with the data plane deployed into an AWS account you control; the vendor keeps a control plane for provisioning and upgrades.
04Self-hosted open source: You assemble and operate an open-source chat stack and model serving yourself, end to end.
05On-premises / air-gapped: Everything runs on hardware you own, disconnected by design; nothing transits any external network.
The selection matrix
Six axes, five architectures, and a justification in every cell — a bare rating would hide exactly the judgment you came for. Read columns to understand an architecture, rows to compare on the axis your constraint lives on.
| Axis | Closed API / public SaaS | Governed private SaaS | Managed BYOC on AWS | Self-hosted open source | On-premises / air-gapped |
|---|---|---|---|---|---|
| Control | LowTheir planes, their clocks. Your controls are contractual terms and whatever you build in front of the API. | MediumConfigurable retention and access controls in the workspace; the provider planes rest on contract and disclosure. | HighThe data plane sits in your account under your IAM, network, and keys; the control plane and upgrade path remain the vendor's. | HighNo vendor plane to trust at all — and everything is yours, including every default nobody hardened. | HighestTotal control at total cost; even model updates arrive on your schedule, by hand. |
| Time to deploy | HoursAn API key and a first call. This is the axis it wins outright. | Hours to daysWorkspace provisioning plus your own rollout decisions: roles, retention, use policy. | Days to weeksAccount preparation, role review, network design, and a security review that should not be skipped. | Weeks to monthsStanding up the stack is the fast part; logging, identity, and upgrades are where the calendar goes. | MonthsHardware procurement, facility work, and manual delivery of everything — including model weights. |
| Evidence | Thin by defaultYou can prove what your own gateway logged and little else; provider-side visibility is what the contract says it is. | StrongPer-request audit records with attribution and model identity, exportable date-ranged — the evidence layer is the product's job — produced and held by the vendor, so completeness rests on the same disclosure the Control row describes. | Strong, and yoursThe audit stores and CloudTrail live in your account; you can hand an examiner evidence nobody else stores or exports. | BuildableEverything is inspectable and nothing is packaged — attribution, export, and retention controls are a project you own. | Strong but manualComplete custody of every record, with tooling you built and reviews you staff. |
| Staffing | MinimalA developer and a policy owner. | MinimalAn admin for roles and retention; no infrastructure team required. | AWS-capable team requiredSomeone must own the account, the roles, the network, and the pager. Without that team, BYOC is the wrong answer — full stop. | Dedicated platform engineeringPermanently, not for the install week. Patching, upgrades, and log plumbing never finish. | Specialist teamPlatform engineering plus physical operations, on-site. |
| Egress | All content leavesBy design — that is what calling a hosted API is. | Contracted transitContent transits the vendor and its disclosed subprocessors under retention and no-training terms you should get in writing. | Stays in your VPCContent-bearing stores remain in your account; verify the control-plane and telemetry egress inventory — it is never zero. | Whatever you configureNothing ever has to transit a vendor — and whatever does leave is whatever you configured, including accidentally: default routes, update checks, and telemetry you did not know a component shipped with. | NoneBy construction — the property you are paying the isolation tax for. |
| Cost predictability | Usage-based, spikyCheap to start, hard to forecast, and priced per token at someone else's rate card. | Per-seat, predictableA subscription line item finance can plan around. | Predictable once sizedSubscription plus your own AWS bill — knowable after right-sizing, with the compute cost visible in your account. | Deceptively variableThe infrastructure is forecastable; the engineering time is chronically underestimated, and it is the larger number. | High and lumpyHardware, refresh cycles, facilities, and people — capital expenditure rhythms, not SaaS ones. |
Choose it when — and when it is the wrong answer
The matrix says how each architecture behaves; this section says when to pick it. The "wrong when" column is the one to read twice — including for the tiers we sell.
01Closed API / public SaaS
- Choose it when:
- Prototyping, non-sensitive workloads, or anywhere frontier capability matters more than custody. Fastest path to a working feature, and for content that is genuinely non-sensitive, an honest default.
- Wrong when:
- The moment regulated or customer content enters prompts unlogged. If you cannot answer who sent what to whom, the architecture — not the model — is the finding.
02Governed private SaaS
- Choose it when:
- You need attribution, retention control, and exportable evidence without an infrastructure team. For most regulated internal use, this tier satisfies the actual obligation — which is usually about reconstructing use, not about where servers sit.
- Wrong when:
- Policy or contract genuinely requires your-account custody or forbids third-party transit of content. Then no amount of vendor honesty substitutes for the boundary.
03Managed BYOC on AWS
- Choose it when:
- Data-plane custody is a hard requirement — written down, not vibes — and you have an AWS-capable team to own the account. You get direct inspectability of the stores, network, and keys, with the product still built and updated by a vendor.
- Wrong when:
- Three honest disqualifiers. No AWS staffing: an unowned account is worse than a well-run vendor tier. A speed-first pilot: you will spend the pilot's calendar on account preparation. Or a zero-retention SaaS already satisfies the actual obligation: buying BYOC to avoid writing a data map is buying the expensive way to skip homework. And remember what BYOC does at its best — it relocates trust rather than removing it: the control plane, upgrade path, and support access still run on vendor trust.
04Self-hosted open source
- Choose it when:
- You have real platform engineering depth, a customization need the products cannot meet, or a licensing posture that requires it — and the toil (patching, log plumbing, evidence export) has a named, funded owner.
- Wrong when:
- The stack is chosen to save money. The subscription you avoided returns as engineering payroll, and the evidence layer regulated teams need is exactly the part nobody gets around to building.
05On-premises / air-gapped
- Choose it when:
- Disconnection is the requirement itself — classified environments, isolated operational networks, contractual mandates. Nothing else provides the property.
- Wrong when:
- Everything else. The isolation tax — hardware, facilities, manual updates, specialist staff — is only worth paying when a mandate says so, not as a maximalist reading of 'private'.
Going deeper on each fork
Three companion pages carry the depth behind these rows. The BYOC on AWS guide makes "runs in your account" concrete — the IAM role, egress inventory, key policies, upgrade path, and support access that decide whether the BYOC column's scores actually hold for a given vendor. The closed-API comparison is the head-to-head version of column one, including where the closed API wins. And the self-hosted comparison scores the do-it-yourself column row by row, including where self-hosting wins. Whatever you shortlist, the vendor security questionnaire is the instrument to send next.
Where PrivateStack sits
We sell the two middle tiers, and the claims are the site's standing ones: the governed workspace (Solo and Team) logs every request with user identity, timestamp, and model identity, with configurable retention and zero-retention inference through a disclosed subprocessor under contractual no-training terms; the Enterprise deployment runs the data plane inside the customer's own AWS account, deployed through an assumed, least-privilege IAM role — and AWS is the only cloud we support for BYOC today. The honest limits: we do not sell the other three tiers, this page still scores them straight, and the "wrong when" column applies to our own tiers as written — a team without AWS staffing should buy our hosted tier or nobody's BYOC. The Verified Deployment program covers the review posture for Enterprise deployments, and the security page carries the full control set.
Questions people actually ask
- Which AI architecture is the most secure?
- Wrong question — the right one is where you want your trust to sit and what your team can actually operate. Every architecture trusts someone: the closed API trusts the provider entirely; private SaaS moves that trust into contracts plus an evidence layer; BYOC relocates the data plane to your account while trust remains in the control plane and upgrade path; self-hosted and air-gapped trade vendor trust for trust in your own engineering. A well-run governed SaaS beats a badly run BYOC deployment, and an unowned self-hosted stack is the least secure option on this page.
- Is BYOC always the right choice for regulated teams?
- No, and we sell it. BYOC is right when your-account custody is a written requirement and an AWS-capable team exists to own it. It is wrong for small teams without that staffing, wrong for speed-first pilots, and unnecessary where a governed zero-retention workspace already satisfies the obligation — in most programs, recordkeeping and supervision duties turn on reconstructing use, not on which account the servers sit in. Start from the obligation, not the architecture.
- What is the difference between private AI and self-hosted AI?
- Private describes a property — content stays off unauthorized planes, use is logged, retention is controlled. Self-hosted describes an operating model — you run everything yourself. They are independent: a governed vendor workspace can be meaningfully private while vendor-operated, and a self-hosted stack with default settings and no log discipline can be the least private thing in the building. Choose the property first, then the cheapest operating model that credibly delivers it.
- Can we mix architectures?
- Most organizations should. A defensible portfolio often looks like: closed API for non-sensitive engineering experimentation, a governed workspace for everyday internal use with evidence, and BYOC or on-premises for the specific workloads whose obligations demand custody. The prerequisite is the same classification discipline the rest of this cluster teaches — which interactions are records, what data flows where — because a portfolio without a data map is just sprawl.
- Where does PrivateStack sit in these five?
- We sell the two middle tiers: the governed private SaaS workspace (Solo and Team — per-request logging, configurable retention, zero-retention inference through a disclosed subprocessor, contractual no-training), and managed BYOC, where the Enterprise deployment runs the data plane inside the customer's own AWS account — and AWS is the only cloud we support for BYOC today. We do not sell the closed API, self-hosting, or air-gapped tiers, and the honest comparisons on this page include the cases where those — or a smaller tier than the one we would profit from — are the right answer.
Whichever architecture you land on, the evidence questions stay the same: the audit trail requirements checklist covers the ten controls examiners ask about, and the zero data retention vs no training guide maps the planes every column of the matrix is really arguing about. And the claim this page leans on — that in most programs, recordkeeping and supervision duties turn on reconstructing use rather than on where the servers sit — has its sourced treatment in the FINRA generative AI recordkeeping guide.