Blog
Key takeaways:
Ten years ago, using machine learning in a product meant hiring people who could train models and buying hardware to run them. Now it means signing up for an account and reading an API reference.
That shift has a name, and it is a slightly awkward one. AI as a service covers everything from a raw model endpoint to a finished application with AI inside, which makes the phrase useful for vendors and confusing for buyers. Two products described with the same three words can differ by two orders of magnitude in price and in what you are responsible for.
The phrase stretches across four very different products.
This guide separates them. It covers what AI as a service actually is, the layers it comes in, real examples, what it costs, where the bill surprises you, and an honest answer on when building beats buying.
AI as a service is the delivery of AI capability over the internet on a subscription or usage basis, so the buyer does not own the models, the training pipeline or the hardware.
The shift shows up in adoption data rather than in vendor claims. OECD figures put firm-level AI use at 20.2% in 2025, against 14.2% in 2024 and 8.7% in 2023, so adoption more than doubled in two years. Almost none of that came from companies learning to train their own models.
Three years of the same measure, drawn to scale.
The parallel with software as a service is exact and worth holding onto. SaaS meant you stopped installing software on servers you maintained. AI as a service means you stop training and hosting models on infrastructure you maintain. In both cases you trade control and unit economics for speed and for somebody else's operations team.
What makes it different from SaaS is where the uncertainty sits. With SaaS, the software does what the documentation says. With AI, output quality varies by input, changes when the provider updates a model, and cannot be fully specified in advance. That single difference drives most of the buying advice in this article.
Vendors sell at four different altitudes, and knowing which one you are being sold decides who is responsible when the output is wrong.
| Layer | What you rent | What you still have to build | Who it suits |
|---|---|---|---|
| Infrastructure | GPUs and training capacity | Everything: models, pipeline, serving, evaluation | Teams training their own models |
| Model API | A hosted model behind an endpoint | Prompting, retrieval, evaluation, the product around it | Product teams with engineers |
| Platform | Models plus retrieval, orchestration, monitoring and guardrails | The workflow and the integrations | Teams shipping several AI features |
| Application | A finished product with AI inside | Configuration and adoption | Business buyers with a specific job |
Most companies think they are buying at the application layer and end up building at the model layer, because the finished product does 80% of the job and the last 20% is the part their business actually runs on.
Underneath the layers, pricing and packaging fall into a handful of shapes, and each one fails differently.
Usage-based pricing charges per token, per request or per minute of compute. It is the honest default at the model layer and the hardest to forecast, because a small change in prompt design can double consumption without changing anything a user sees.
Seat-based pricing charges per user per month and is common at the application layer. It is predictable, which finance likes, and it decouples price from value in both directions: a heavy user costs you the same as someone who logs in twice a month.
Outcome-based pricing charges per resolved ticket, per qualified lead, per document processed. It is the fastest-growing shape in customer support and marketing AI as a service, and it aligns incentives well right up until you disagree about what counts as resolved.
Hybrid pricing, a platform fee plus usage, is now the most common enterprise shape. Read the overage terms before the discount, because that is where the second-year bill lives.
Abstract categories are less useful than the jobs these things actually take over, so here are the patterns that show up most in real deployments.
Customer support deflection is the most mature. A model sits in front of a help center, answers what it can and escalates the rest. The economics work because the baseline cost per ticket is easy to measure, which is why it was the first pattern we wrote up when ChatGPT reached support desks.
Document processing is the least glamorous and often the highest return. Invoices, claims, contracts and intake forms get read, extracted and routed. The measurable unit is minutes of human handling per document, which makes the business case unusually clean.
Content and marketing AI as a service covers drafting, variant generation and personalization at volume. The value is real and the quality ceiling is set by how much of your own material the system can retrieve.
Coding assistance has moved from novelty to default in three years. Sales and research assistants sit alongside it, summarizing calls and enriching records.
The pattern across all of them is the same: AI as a service works best where there is a countable task with a known cost per unit, and worst where the job is ambiguous and the definition of "done" is contested.
Agents are the fastest-moving corner of this market and the one where the marketing has drifted furthest from what ships.
An agent, properly, is a system that takes a goal, plans a sequence of steps, calls tools to carry them out, and adapts when a step fails. Agents as a service means renting that loop rather than writing it. The genuine version is valuable, particularly for multi-step back-office work where the steps are known but the order varies.
The slippage is that a great deal of what is sold as agentic is a scripted workflow with a model at one step. That is not a criticism of the product, which may be exactly what you need, but it changes what you should pay and how you should evaluate it.
One test cuts through it quickly. Ask what the system does when a tool call fails halfway through a task. A real agent has a retry and recovery story you can inspect. A workflow with a model in it usually just stops, and the answer you get will tell you which one you are buying.
One failed step, and the two products stop looking alike.
The reason the distinction is worth money is that agents are usually bought to run unattended, and 24/7 access is only an asset if the thing running overnight can recover from its own failures.
The two coexist, and conflating them leads people to buy the wrong thing for the job.
Traditional machine learning services do prediction on your data: churn scoring, demand forecasting, fraud detection, recommendation. They need your historical data, they produce a number or a class, and their accuracy is measurable against a holdout set. They have been available as a service for a decade.
Generative AI as a service produces text, code, images or structured output from a prompt and some context. It needs much less of your data to start and much more of your judgment to evaluate, because there is no single correct answer to compare against.
A lot of the current excitement sits in the generative half, where AI-powered conversations let a company answer questions when nobody is at a desk.
The practical rule is that if your problem has a right answer sitting in historical data, traditional ML is usually cheaper, more predictable and easier to defend. If your problem is producing or transforming language, generative is the only realistic option.
Plenty of good systems use both, with a cheap classifier deciding which requests are worth sending to an expensive generative model at all.
Sticker prices are easy to find and misleading on their own. The table below is the shape of a real annual cost for a mid-sized company deploying one workflow, not a vendor price list.
| Cost line | Typical share of year-one spend | Why it gets underestimated |
|---|---|---|
| Model or subscription fees | 20% to 35% | The only number anyone quotes |
| Integration engineering | 25% to 40% | Connecting to systems that were never designed for it |
| Data preparation | 10% to 25% | Retrieval quality is a data problem, not a model problem |
| Evaluation and testing | 5% to 15% | Nobody budgets for measuring whether output is correct |
| Change management and training | 10% to 20% | The workflow only pays off if people use it |
Three specific line items catch buyers out. Retries and failures still cost money at usage-based pricing, and a badly-tuned pipeline can retry a lot. Long context is priced per token and grows silently as you add retrieved material to prompts. And evaluation runs, where you replay hundreds of cases against a new model version, are a recurring cost that appears only once you are running the thing responsibly.
None of that makes it a bad deal. It does mean the model line is the smallest part of the budget, which is the opposite of how most business cases are written. Judged properly, this is one of the more reliable ways tech saves money, just not for the reason the vendor deck gives.
Understanding how these companies make money tells you which ones will still be there in three years and which will change their pricing.
Almost every application-layer vendor is reselling inference bought from a handful of model providers, with its own margin on top. That gives it a real cost of goods sold, which traditional software did not have, and it is why pricing in this market changes more often than buyers expect.
Stanford's AI Index puts the concentration in context: nearly 90% of notable AI models in 2024 came from industry, up from 60% in 2023, while training compute for frontier models doubles roughly every five months. The frontier is being built by a very small number of organizations at a scale nobody else can match.
The whole application layer narrows to the same few suppliers underneath.
For a buyer, that is the single most important structural fact in this article. The models are a commodity produced by a few suppliers, everyone builds on the same handful, and the differentiation you are paying for at the application layer is workflow, data and integration rather than intelligence.
This is the question the whole category turns on, and the honest answer has a shape rather than a side.
Buy the model. There is no realistic case for a company outside the top tier of AI labs training a foundation model, and the compute doubling figure above is why. Buy the platform too, in most cases, unless you are running enough AI features that the platform fee exceeds what a small team would cost.
Build the workflow. The sequence of steps, the rules about what gets escalated, the retrieval over your own material, and the definition of a good answer in your business: that is the part nobody can sell you, and it is the part that keeps working when you swap models underneath.
Practitioners land in roughly the same place. In a Reddit discussion among experienced engineers about build versus buy, the highest-rated answer pointed out that even $1,000 a month is trivial next to a full-time developer's salary to maintain a custom equivalent, and that engineers lean toward building partly because they are engineers. Another added a rule of thumb worth stealing: cost it as the build plus 30% to 40% annually for maintenance, or a rebuild every five years.
That is one thread and it is anecdotal, but the maintenance multiplier matches what we see on real systems. Most build-versus-buy spreadsheets compare a build cost against a subscription and quietly omit the years afterward, which is a bad way to get the tech your idea deserves.
The case for buying is strong enough that the risks deserve stating plainly rather than being waved away.
The same engineering thread surfaced the counterargument well. People who prefer building have usually been burned: a vendor shut down and forced a migration on short notice, a licensing change made the product unaffordable, support stopped being responsive, or the product they depended on became abandonware after a pivot. One reply described being price-hiked hard once the vendor worked out the business could not survive without them.
Three defenses cover most of that exposure, and none requires you to build. Keep your prompts, your evaluation set and your retrieved data in your own systems rather than inside the vendor's. Design the integration so the model provider sits behind an interface you control, which turns a migration into a configuration change. And check the vendor's funding and gross margin story before you make them load-bearing.
Two of those three defenses are one line on a diagram.
The deeper point is that dependence is a design decision, not a vendor property. A system built so a model can be swapped in an afternoon has bought speed without buying lock-in, and that is achievable at almost every layer above raw infrastructure.
A newer category sells governance instead of capability: model monitoring, bias testing, audit trails, policy enforcement and documentation for regulators.
Whether you need it depends almost entirely on your exposure. If AI touches hiring, lending, healthcare, insurance or anything covered by sector regulation, you need documented oversight, and buying it is often cheaper than building it. If you are using AI to draft marketing copy, a written policy and a named reviewer will do.
The honest caution is that this market is young and some of what is sold as AI governance as a service is a dashboard. Ask what it would actually produce if a regulator asked how a specific decision was made, and judge it on that answer rather than on the feature list.
The clearest returns come from replacing a manual process that somebody is currently doing by hand at volume, and the value is usually easier to see afterward than to model in advance.
When we built the platform for Honest Game, an edtech company mapping high school transcripts against NCAA eligibility rules, the outcome was that manual report production stopped. Staff moved from producing reports to spot-checking them. That was automation rather than a large language model, and it is the same economic pattern every good AI as a service deployment follows: a countable task, a measured baseline, and humans moved to the exceptions.
What does not work is buying a capability and looking for a use for it afterward. That order produces pilots that demo well and never reach production, and it is the most common way money gets spent in this category with nothing to show.
Most bad AI purchases come from evaluating on a demo instead of on your own work. This sequence costs very little and prevents most of it.
Step three is the one people skip and the one that matters most, because writing down the correct answer after seeing the output is not evaluation. Companies that follow that sequence buy less software and get more out of what they buy, which is the same reason we give away templates and forecasting models in our startup resources rather than gating them.
AI as a service is a good deal for almost everyone, provided you are clear about which layer you are renting and which part of the job stays yours. The models are getting cheaper and better on a schedule you do not control, which is an argument for renting them and against building anything whose value depends on owning one.
Spend your engineering where it compounds: the workflow, the data, the evaluation set, and the interface that lets you swap a provider without a rebuild. Those four assets survive every model release, and they are what still belongs to you in three years.
If you are weighing a build against a subscription and want a read from people who have shipped both, contact us. We build AI into working systems for operating companies, and about half those conversations end with us telling a client to buy something instead.
It is renting AI capability over the internet instead of owning it. A provider hosts the models and the infrastructure, and you consume them through an API or a finished application, paying by usage, by seat or by outcome. You give up control over the underlying models and get speed, lower upfront cost, and somebody else running the hardware.
The clearest ones are a support tool that answers routine tickets and escalates the rest, a document processor that reads invoices and routes them, and a coding assistant inside a developer's editor. Each replaces a countable task with a measurable cost per unit, which is the pattern where this model consistently pays off.
They overlap heavily, and the useful distinction is the layer. AI software as a service usually means a finished application with AI features inside, bought by a business user. AI as a service more broadly includes the raw model endpoints and platforms that engineering teams build on. The price, and who is responsible when the output is wrong, differ sharply between the two.
Most application-layer providers resell inference bought from a small number of model companies, adding workflow, data and integration on top. That gives them structurally lower gross margins than classic software, which is why pricing in this market changes more often than buyers expect, and why checking a vendor's margin story matters before you depend on them.
Buy the model in essentially all cases, since frontier training compute doubles roughly every five months and almost no company can follow that curve. Build the workflow around it: the escalation rules, the retrieval over your own material, and your definition of a good answer. If a vendor's product does 80% of your job and the remaining 20% is what your business actually competes on, buy the 80% and build the 20%.
Pick the single process you would automate first, price it with the full-cost table above rather than the vendor's per-unit figure, and put fifty of your own cases through whatever you are considering.
If the answer comes back ambiguous, or you want a read from a team that has built at both the model and the application layer, contact us.
