A decision guide for consultants, IT directors, and executives weighing on-premises AI against a frontier-lab enterprise agreement — with the privacy, regulatory, and total-cost details that vendor decks tend to skip.

Enterprise AI can be a tough decision — Image by Gemini

Enterprise AI can be a tough decision — Image by Gemini

The fork in the road

If you run engineering or IT at a mid-sized firm, you have probably had some version of this conversation in the last quarter. The team adopted a tool like Cursor because it was the fastest way to put frontier and near-frontier models in front of developers. Then the bill arrived. Usage-based billing tied to model API rates is wonderful until a handful of power users start running multi-file agents in “max” mode all day, and suddenly the line item that was supposed to be predictable is anything but. Finance asks the obvious question: can we make this a flat, knowable number?

That question forces a strategic decision that is much bigger than a software renewal. Broadly, you are choosing between two philosophies, with a third that most decks ignore:

  1. Rent the frontier. Sign an enterprise agreement with OpenAI or Anthropic and standardize your people on ChatGPT/Codex or Claude/Claude Code.
  2. Own the stack. Stand up an on-premises or private-cloud deployment — increasingly via a managed consumption model like HPE GreenLake — running open-weight models behind your own firewall.
  3. The bridge most people miss. Keep using frontier models, but consume them through a compliant cloud (AWS Bedrock, Google Vertex AI, Azure AI Foundry) under a Business Associate Agreement and zero-data-retention terms, so the data-governance posture looks a lot more like on-prem than like a consumer SaaS seat.

This piece walks through the real 2026 numbers for a 500-person organization — total cost of ownership at year one, year three, and year five, plus the return-on-investment logic — and then spends most of its energy where the decision actually gets decided for regulated firms: privacy, security, and compliance. If you are in healthcare, financial services, defense, or law, the financial model is necessary but not sufficient. The binding constraint is whether your data is allowed to be where the model is.

A note on the figures throughout: every unit price below is drawn from current published or widely reported 2026 pricing, but the multi-year totals are planning estimates built to show the shape of the decision, not quotes. Your BOM, your usage intensity, and your negotiated rate will move them. Treat them as a model to populate with your own numbers, and validate tax, entity, and certification specifics with your accountant and a compliance lab.

Myth number one: a flat plan eliminates overages

Before any spreadsheet, kill the assumption that quietly drives most of these decisions. The belief goes: “If we just buy everyone a flat $200-per-month ‘max’ plan, our usage problem disappears.” In 2026 that is no longer true on either side of the frontier-lab aisle, and building a strategy on it will burn you.

On the OpenAI side, Codex moved to usage-based pricing in April 2026. Enterprise accounts include a baseline of Codex usage in the seat, but heavy agentic coding bills separately through workspace credits. OpenAI also began restricting new Codex seats on ChatGPT Business plans as of June 24, 2026, pushing serious coding usage toward Enterprise and the metered API. The flat ChatGPT subscription covers usage inside OpenAI’s own surfaces up to per-seat limits; the moment your developers exceed those limits, or call the API from a third-party IDE, you are back to per-token billing.

On the Anthropic side, the change is even more explicit. During 2025–2026, Anthropic unbundled tokens from the Enterprise seat. The headline seat fee dropped to roughly $20 per user per month, but every token your team consumes in chat, Claude Code, or Cowork now bills at standard API rates on top of the seat. The seat buys you access, SSO, audit logs, and admin controls; it does not buy you inference. Anthropic’s own usage data puts a typical Claude Code developer around $6–$13 per active day, or roughly $100–$250 per developer per month, with heavy users well above that.

The practical implication is that the “rent the frontier” option is itself a usage-based model for any coding-heavy org — exactly the thing management was trying to escape by leaving Cursor. You are not choosing between “predictable flat cost” and “scary metered cost.” You are choosing which vendor’s meter runs, and whether the marginal cost of an extra million tokens is paid to a frontier lab, to a hyperscaler, or to your own amortized hardware. That reframing changes the whole analysis.

The only genuinely flat options are (a) consumer “max”-tier individual subscriptions priced at $200/seat, which are not built or licensed for org-wide deployment and carry no enterprise compliance posture, and (b) owning the hardware, where the marginal cost of a token approaches the cost of the electricity to compute it. Everything in between meters.

The 2026 pricing landscape, briefly

To ground the model, here are the unit prices as they stand in mid-2026.

Frontier SaaS seats. ChatGPT Enterprise has no public list price; negotiated deals land roughly $40–$60 per seat per month with a 150-seat minimum and annual commitment, falling toward $40 at very large seat counts. ChatGPT Business sits at about $20/seat but is not eligible for a Business Associate Agreement. Claude Enterprise runs about $20/seat plus metered token consumption at standard API rates. Claude for Government is a separate $60/seat product with usage included and — importantly — FedRAMP High authorization.

Token rates. As of mid-2026, Claude Opus 4.8 is around $5 per million input tokens and $25 per million output; Sonnet 4.6 about $3/$15; Haiku 4.5 about $1/$5. OpenAI’s GPT-5.5 is roughly $5 input and $30 output per million — about double its predecessor — though OpenAI argues better token efficiency narrows the real-world gap. Batch and cached-input discounts (often 50% and ~90% respectively) materially change heavy-workload economics and should be modeled, not ignored.

Cursor, the incumbent you’re likely leaving. Cursor Teams runs $40/seat (Standard) or $120/seat (Premium, ~5x usage), each with two included usage pools — first-party models like Composer 2.5 and a separate third-party API pool — plus on-demand overages billed in arrears. The June 2026 Teams update added the Premium seat and separate pools specifically to tame the overage problem, and Composer 2.5 is positioned as frontier-class coding at a fraction of third-party model cost. If your pain is purely overage volatility, it is worth pricing Cursor’s own Premium/Enterprise tiers before assuming a frontier-lab agreement is cheaper — the answer is often that it is not.

Open weights for self-hosting. The open-weight field has closed much of the gap. DeepSeek V4 (Pro and Flash, MIT license, million-token context), Qwen 3.6 / 3.5 (Apache 2.0), GLM-5.x (MIT), Kimi K2.x (Modified MIT), Gemma 4 (Apache 2.0), MiniMax M3, and Llama 4 are all viable. On some agentic-coding benchmarks, GLM-5.2 reportedly edges out leading proprietary models; independent assessments still place models like DeepSeek V4 several months behind the absolute frontier on the hardest tasks. Permissive licensing (Apache 2.0, MIT) matters more than leaderboard position for a commercial deployment — read the license for user caps, geographic limits, and derivative-training restrictions before you build on anything. Production serving is typically vLLM or SGLang.

Managed on-prem. HPE GreenLake’s Private Cloud AI is the most visible managed-consumption path: a co-engineered HPE/NVIDIA stack delivered as a pay-as-you-go service inside your own data center, with no egress or per-token fees, a single control plane, multi-node inference scaling (up to 256 GPUs in the 2026 roadmap), and air-gapped and FedRAMP-aligned configurations available. HPE does not publish per-unit pricing; it is quoted to the deployment. The strategic point is that it converts the big upfront GPU capital expense into an operating expense and absorbs much of the hardware-management labor.

The total-cost model: 500 users, years one, three, and five

Let’s model a 500-person firm with a realistic mix: about 150 heavy technical users (engineers, data scientists running agents) and about 350 lighter knowledge-worker users (drafting, summarizing, research, document Q&A). Again — illustrative planning estimates, not quotes.

Option A — Rent the frontier (negotiated enterprise seats + metered usage)

  • Seats: 500 × ~$45/mo × 12 ≈ $270K/yr
  • Metered usage: 150 heavy users × ~$180/mo + 350 light users × ~$35/mo, annualized ≈ $470K/yr
  • Year 1 all-in ≈ $740K. Roughly flat year over year, with upside risk as model prices rise (recall GPT-5.5 roughly doubled per-token cost over its predecessor).

Option A′ — The naive “max plan” version

500 × $200/mo individual “max” seats = $1.2M/yr, or $6M over five years — with no enterprise compliance posture and licensing not intended for org deployment. This is the version to argue against in the boardroom.

Option B — Frontier models via compliant cloud (Bedrock / Vertex / Azure)

Pure usage-based consumption through your own cloud tenant, under a BAA with zero data retention:

  • Token consumption (similar order to A’s usage component): ≈ $500K/yr
  • Platform/governance staffing (~0.5–1 FTE) + cloud overhead: ≈ $180K/yr
  • Year 1 all-in ≈ $680K, comparable to Option A but with a materially stronger data-governance posture and no per-seat “sprawl” waste from dormant licenses.

Option C — Own the stack via HPE GreenLake (open weights)

  • Consumption lease (hardware-as-a-service) + power/cooling: ≈ $250K/yr
  • Reduced platform/MLOps staffing (HPE manages the hardware layer; you run the model runtime): ≈ $120K/yr
  • Year 1 all-in ≈ $370K, with $0 upfront capital.

Option C‘— Own the stack — DIY

  • Traditional CapEx alternative:
  • ~$700K upfront for GPU nodes, networking, and storage
  • ~$370K/yr in power and ~1.5 MLOps FTEs — higher in the early years
  • exposed to a brutal 18–24-month silicon obsolescence cycle.

What the model actually tells you

Read past the totals to the shape:

Against the naive max-plan plan, owning wins decisively and fast — break-even inside the first year, and roughly a $4M five-year saving. If that is genuinely the alternative on the table, the on-prem case writes itself.

Against a competently negotiated frontier agreement, the gap narrows and the deciding variable is usage intensity, not seat count. The managed on-prem path (≈$0.37M/yr) beats the negotiated frontier path (≈$0.74M/yr) from year one in this model — but that result is entirely driven by the assumption that your team consumes a lot of tokens. Flip the assumption to a light-usage org with a lean seat-only enterprise deal (say $300K/yr all-in), and the cloud quietly wins, because your fixed human cost to run any on-prem stack — even a managed one — is hard to push below a few hundred thousand dollars a year. The honest one-liner: heavy, automated, around-the-clock agentic token pipelines favor owning; bursty, interactive, human-in-the-loop usage favors renting.

The traditional-CapEx column is a trap for mid-sized firms. A 500-person org rarely has the volume to amortize a $700K GPU purchase before the hardware is a generation behind. The GreenLake-style consumption model exists precisely to defuse that — it is the reason “on-prem” is a viable financial choice in 2026 at all, rather than a capital chasm. You pay a management premium for HPE to carry, refresh, and operate the silicon; in exchange you delete the obsolescence risk and most of the hardware-babysitting payroll.

One more honest caveat the totals hide: Option C runs open-weight models, which sit somewhere between “at parity” and “a couple of quarters behind” the absolute frontier depending on the task. If your developers are doing the hardest agentic software engineering, that gap is real and has a productivity cost that won’t show up in the infrastructure line. If your workloads are summarization, RAG over your own documents, classification, drafting, and mainstream coding, the gap is largely irrelevant and the open models are more than good enough.

ROI: the number that actually matters is adoption, not sticker price

Executives anchor on cost per seat. The far larger lever is whether the seat gets used.

The math is not subtle. If a tool saves a professional even one to two hours a week, it pays for itself several times over at any plausible billing rate — a five-developer team on a $20 plan saving four hours a month is generating something like a 10x return. Enterprise teams report 30–50% reductions in cycle time on complex full-stack work. The value side of the ROI equation is almost always larger than the cost side for active users.

The destroyer of ROI is the dormant seat. Provision 500 seats, achieve 10% weekly active usage, and your real cost per active user is ten times the sticker price — and a frontier lab bills you for provisioned seats, not active ones. Industry deal data suggests first-year activation rates frequently sit in the 20–35% range. That means the single highest-ROI move available to most organizations is not negotiating the per-seat rate down by 15%; it is dragging activation from 10% up to 40% through enablement, templates, and removing the friction between “account provisioned” and “workflow actually running.”

This reframes the buy-versus-build decision in a useful way. Owning the stack has near-zero marginal cost per token, which means it rewards heavy use — once the cluster is paid for, you want developers running it constantly, and there is no overage anxiety to suppress adoption. Renting frontier seats penalizes the heaviest users through metered usage, which can create a perverse incentive to ration exactly the people getting the most value. For an organization confident it can drive high, sustained, automated usage, the owned model’s economics and its psychology both point the same direction. For an organization still fighting the adoption battle, paying only for what gets used (compliant cloud, Option B) is the lower-regret bet.

A negotiation note worth carrying into any frontier-lab conversation: tie the per-seat rate to activated seats with a quarterly true-down right, and pre-negotiate prepaid token blocks at a discount at signing — both are far harder to win at renewal.

Privacy and security: what owning actually buys you

For regulated firms this is the heart of the decision, so be precise about what changes when data stays inside your perimeter — and what doesn’t.

What on-prem genuinely buys you. When the model runs on hardware you control, your prompts and outputs never cross your network boundary. There is no third-party multi-tenant environment processing your source code, patient records, deal documents, or privileged communications. Your data-residency story becomes trivially simple: the data is here, full stop. You get immutable model stability — you freeze a known-good model version and run it indefinitely, insulated from silent vendor model updates that can cause regression in a framework your codebase depends on. And you get a natural, physical spend ceiling: a cluster can only process so much, which is its own form of cost governance. HPE markets exactly this — bringing compute to the data for HIPAA, GDPR, and PCI reasons, with a hard physical stop on runaway consumption.

What on-prem does not buy you. Owning the hardware is not the same as being secure or compliant. You inherit the entire disaster-recovery and high-availability problem: if a node fails and you didn’t buy N+1 redundancy, your AI tooling can be down for days waiting on enterprise parts. You inherit patching, access control, key management, network segmentation, and audit logging — all the unglamorous controls that a SOC 2 or HIPAA auditor will actually test. “On-prem” answers where the data is; it does not answer whether you’ve implemented the safeguards. A managed-consumption model offloads the hardware and availability layer to a vendor like HPE, but the compliance controls around your runtime and your data remain yours to own and evidence.

The threat-model reframe. The right question is not “is the cloud insecure?” The frontier labs and hyperscalers run security programs most mid-sized firms cannot match. The right question is “what does my regulatory regime require, and can I evidence it?” Sometimes the answer is genuinely that data cannot transit a third party under any contractual terms — classified work, certain defense data, some sovereignty regimes. Often the answer is that data can transit a third party if the right agreement and configuration are in place — which is exactly what the compliant-cloud bridge provides.

Regulated industries: what each regime actually demands

The acronyms get thrown around loosely. Here is what each one concretely requires of an AI deployment, and where the deployment models land.

HIPAA (healthcare, and any business associate touching PHI). The operative rule is simple and unforgiving: any service that creates, receives, maintains, or transmits protected health information is a business associate and needs a signed Business Associate Agreement, and that obligation flows down to every subcontractor. The instant a real patient name enters a prompt to a service with no BAA in scope, the data flow is non-compliant. Consumer ChatGPT, ChatGPT Plus, ChatGPT Business, and consumer Claude are not BAA-eligible. BAA coverage exists on OpenAI’s API platform, ChatGPT Enterprise, and the dedicated ChatGPT for Healthcare workspace; and on Anthropic’s Enterprise and direct API products. Both typically require a zero-data-retention configuration, and the BAA does not cover every feature — web search, for example, is commonly excluded, as are several agentic features on the Anthropic side. On-prem sidesteps the BAA-scope question for the model itself but does not exempt you from the rest of the Security Rule.

SOX (public-company financial reporting). SOX is less about where the model runs and more about controls, change management, and auditability over systems that touch financial reporting. The questions an auditor asks: who can access the system, is access logged, are changes to the model and its configuration controlled and recorded, can you produce an audit trail. Both frontier Enterprise tiers offer the SSO, role-based access control, audit logs, and compliance APIs that map to these expectations. On-prem gives you maximal control over change management — you decide when the model version changes — at the cost of having to build and evidence those controls yourself. A silent vendor model update is a change-management event under SOX logic; immutable on-prem versioning is genuinely attractive here.

PCI-DSS (payment card data). Cardholder data has strict handling, segmentation, and logging requirements. The pragmatic answer is usually to keep cardholder data out of prompts entirely via tokenization and scrubbing, regardless of deployment model. Where that isn’t possible, the same BAA-style logic applies: the processing environment must be in scope for your PCI controls, which is easier to assert for an on-prem or VPC-isolated deployment than for a multi-tenant SaaS seat.

GDPR / CPRA (EU and California data protection). The decisive features are data residency and data-subject rights. ChatGPT Enterprise offers multi-region data residency (US, Europe, UK, Japan); that capability is a primary reason regulated EU-facing firms choose Enterprise over Business. Note a real-world gotcha: on some platforms, zero data retention cannot be fully achieved if you use grounding features like web search or maps, which carry mandatory retention. The EU AI Act adds a further wrinkle — if you build a high-risk system on a frontier model, you remain the responsible provider/deployer; the vendor’s compliance does not transfer to your system. The EU Cyber Resilience Act’s lifecycle-security-update mandate (vulnerability-reporting obligations beginning September 2026, full compliance December 2027) is another reason a signed, managed update pipeline matters.

CMMC / CUI / ITAR (defense and controlled government data). This is where deployment model is most constrained. Controlled Unclassified Information generally requires alignment to NIST 800–171; Claude Enterprise carries a third-party NIST 800–171 attestation for CUI, and CUI can also be processed in a FedRAMP High environment. FedRAMP High itself is available through Claude for Government, AWS Bedrock in GovCloud, and Google Vertex with Assured Workloads — note that the standard commercial Claude Enterprise product on the marketplace is not itself FedRAMP-authorized, so FedRAMP-bound customers must use one of those authorized paths. ITAR data is more restrictive still — processable via AWS Bedrock at IL5, with availability extending to the AWS Secret region at IL6. For the most sensitive classified work, fully air-gapped on-prem (which HPE explicitly offers as a Private Cloud AI configuration) is often the only acceptable answer.

The bridge: how regulated firms use frontier models legally

Here is the option that resolves most of the tension, and the one your management may not have on the table: you do not have to choose between frontier capability and compliance. For the large majority of regulated use cases short of classified work, you can run the actual frontier models — Claude, GPT, Gemini — through a hyperscaler under terms that look far more like on-prem than like a consumer seat.

The mechanics:

  • AWS Bedrock. AWS signs a BAA self-service through AWS Artifact at no additional cost, covering Bedrock and its eligible services. Models run inside your AWS account; the model providers have no access to it. Bedrock provides GovCloud (FedRAMP High) and DoD IL4/IL5 paths, with IL6 in the AWS Secret region. This is the most common route for HIPAA-eligible frontier usage and the only path for ITAR-adjacent data.
  • Google Vertex AI. Google Cloud signs an organization-level BAA covering Vertex; you enable the regulated-data project flag and wrap PHI workloads in VPC Service Controls. Vertex holds FedRAMP High via Assured Workloads.
  • Azure AI Foundry. For Microsoft-shop customers, the HIPAA BAA is provided by Azure itself through the Microsoft Products and Services Data Protection Addendum and applies automatically under an Enterprise Agreement, MCA, or CSP — no separate per-model BAA. Azure offers Global, Data-Zone, and Regional residency, network isolation via private endpoints, and a deep compliance certification stack including FedRAMP High.

What this buys a regulated firm is the best of both worlds for everything except the most sensitive tiers: frontier-class model quality, no GPU capital expense, no MLOps team, your data confined to your own cloud tenant under a BAA with zero retention, and an authorization path (FedRAMP, IL4/5/6) for government work. The operational gotchas are real and worth a checklist: a BAA only covers eligible services, so using a non-eligible service for regulated data is a breach even with the BAA signed; eligibility lists shift as services launch, so re-confirm quarterly; enable zero-data-retention on every endpoint that supports it; and log the provider, model, and BAA reference on every inference call so an auditor can verify coverage in seconds.

This is the answer to “we want frontier capability but our compliance team says no cloud.” The honest response is that consumer and Business-tier cloud is usually a no — but BAA-covered, ZDR-configured, VPC-isolated frontier access through a hyperscaler is a well-trodden, auditable yes that organizations like large hospital systems already run at scale.

The open-weights reality, without the hype

If you do go the owned route, be clear-eyed about what you are signing up for beyond the hardware.

The capability question is real but shrinking. On mainstream tasks — drafting, summarization, RAG over your corpus, classification, everyday coding — the best open-weight models are at or near parity. On the hardest agentic software engineering, the picture is genuinely competitive: GLM-5.2 has posted agentic-coding results that beat leading proprietary models on some benchmarks, while independent assessments still place models like DeepSeek V4 a few months behind the absolute frontier. The right move is to benchmark the specific open models against your workload, not to argue from leaderboards.

Licensing is where “open” gets complicated. Apache 2.0 (Qwen, Gemma, Mistral’s latest) and MIT (GLM, DeepSeek) are the clean choices for commercial deployment — download, fine-tune, deploy, no royalties. Others carry caps and restrictions: Llama 4’s license includes a 700M-monthly-active-user ceiling and EU-related restrictions; some licenses prohibit using the weights to train other models. For a regulated commercial product, a permissive license is not a nicety — it is a procurement requirement. Build a legal-review gate into your model-selection process.

The MLOps tax is the hidden cost. Running open weights at production scale means owning vLLM or SGLang orchestration, quantization tuning, KV-cache management, tensor parallelism, and continuous vector indexing for RAG. Even with a managed-hardware vendor handling the silicon, you need real platform engineering to keep the model layer healthy, fast, and secure. And open-weight stacks lag frontier ecosystems on out-of-the-box cross-app context — the slick “read my Slack, my tickets, and my repo and just do it” integrations that the frontier platforms ship natively require custom middleware to replicate on-prem. Budget for that, both in dollars and in calendar time.

A decision framework

Strip away the spreadsheets and the choice comes down to a few honest questions.

Start with your regulatory floor. If you handle classified or ITAR-restricted data with no acceptable cloud path, the question is answered: air-gapped on-prem, frontier models off the table. If you handle PHI, CUI, or EU personal data, you are not blocked from frontier models — but you must route them through a BAA-covered, ZDR-configured hyperscaler path, never a consumer or Business-tier seat. If you are an unregulated commercial firm, you have full latitude and the decision is pure cost-and-capability.

Then characterize your usage. Heavy, sustained, automated agentic pipelines — continuous test generation, background refactoring, large-scale document processing — push hard toward owning, where marginal token cost approaches zero and there is no overage to ration. Bursty, interactive, human-in-the-loop usage pushes toward renting, where you pay only for what you use and avoid a fixed infrastructure-and-staffing base.

Then be honest about your team. Owning anything — even managed on-prem — requires platform/MLOps capability you must hire and retain. If you don’t have it and can’t justify it, the compliant-cloud bridge gives you most of the data-governance benefit with none of the operational burden.

Finally, weigh the capability gap against the workload. If your hardest tasks need the bleeding edge, the frontier (rented directly or via compliant cloud) is worth the premium and the metering. If your workloads are well-served by models a quarter or two behind the frontier, open weights on owned infrastructure deliver enormous cost leverage and the cleanest possible privacy story.

The bottom line

The instinct that sent you here — make the AI bill predictable — is sound, but the simple fix management usually reaches for (swap a metered tool for a “flat” frontier plan) doesn’t deliver predictability in 2026, because the frontier plans now meter too. Once you accept that you are choosing which meter runs, the decision clarifies.

For most regulated mid-sized firms, the under-appreciated winner is the compliant-cloud bridge: frontier models through AWS Bedrock, Google Vertex, or Azure AI Foundry, under a BAA with zero data retention, data confined to your own tenant, with a FedRAMP path when you need one. It gives you the capability of renting and most of the governance of owning, without a GPU purchase order or an MLOps team.

Owning the stack — increasingly via a managed-consumption model like HPE GreenLake — becomes the right answer when two things are true at once: your data genuinely cannot leave your perimeter, and your usage is heavy and sustained enough that near-zero marginal token cost outweighs the fixed cost of running infrastructure. When both hold, the five-year math is compelling and the privacy story is unbeatable. When only one holds, the cloud usually wins on total cost or on capability.

And the naive $200-per-seat “max plan for everyone” approach? Useful mainly as the strawman that makes every other option look disciplined by comparison.

Whatever you choose, do the two things that matter most regardless of architecture: negotiate against activated seats, not provisioned ones, and invest more in adoption than in shaving the per-seat rate. The biggest number in your AI budget is not the price of the tool — it’s the value left on the table by the seats nobody uses.

The pricing and compliance details in this piece reflect publicly reported figures as of mid-2026 and will change; the multi-year cost figures are illustrative planning models, not vendor quotes. Validate current pricing, BAA scope, and certification status directly with each vendor, and confirm tax, entity, and regulatory specifics with your own advisors before committing.