The demo takes ten minutes. A support agent pastes a customer ticket into a chat window, a hosted model drafts a reply, and everyone in the room nods because it reads better than what the agent would have written unprompted. Three weeks later, legal asks where that ticket text actually goes once it leaves the browser, who else can see it, and how long it sits there. Nobody from the pilot can answer with any confidence. The rollout stalls, not because the model was bad, but because nobody asked what they were actually buying before they started sending it customer data.
AI as a service, usually shortened to AIaaS, means consuming AI capability from a provider rather than training, hosting or maintaining the model yourself. You call an API, or click through a vendor's console, and somewhere behind that a foundation model runs on infrastructure you will never see, owned by a company you have a contract with rather than a codebase you control. Chat completion endpoints, hosted transcription, off-the-shelf document extraction, a vendor's recommendation engine bolted onto your storefront: all of it is AIaaS, and most organisations doing anything with AI in 2026 are doing some version of this rather than training models from scratch.
We build data and AI systems at Shipshape Data, and the pattern above is one we see constantly: a team moves fast on the model itself and slow, or not at all, on the questions around it. Cost, data handling, what happens if the vendor changes terms or shuts a feature down. This guide covers what an AIaaS provider actually gives you and what it leaves for you to build, how the cost structure differs from the pricing page, the residency and privacy questions worth asking before data leaves your walls, how lock-in creeps in without anyone deciding to accept it, and a practical way to decide what to buy against what to build.
Why buying AI capability became the default
Ten years ago, doing anything with machine learning meant hiring people who could build models, finding the data to train them on, and standing up the infrastructure to run them. That is still true for a narrow set of problems. It stopped being true for most of them once foundation models arrived that were already good at language, images and reasoning across almost any domain you could point them at. Renting access to a model that already works is now, for most use cases, faster and cheaper than building a worse one from nothing.
The pull is real
You get a capable model on day one instead of after a year of data collection. You are not hiring a research team to keep pace with a field that moves month to month. And the provider absorbs the infrastructure headache: GPU capacity, scaling, the constant retraining that keeping a model current requires. For a lot of organisations, none of that is a capability worth owning. It is a cost centre with no strategic upside, and outsourcing it is sensible.
The part that gets skipped
What tends to get skipped is the second half of the decision: what you are agreeing to when you buy it. Terms of service that change with two weeks' notice. Data handling clauses written for a worst case that becomes your actual case the day a regulator asks a question. A pricing page that describes the cheapest possible use of the product rather than yours. None of this shows up in the pilot, because the pilot is designed to sell you the capability, not the contract.
What the model actually covers, and what it doesn't
"AI as a service" sounds like one thing. It is at least three, stacked on top of each other, and knowing which layer you are buying tells you what you are still responsible for.
The three layers
At the bottom is the model itself: the weights, the training, the raw capability to complete text, transcribe audio, classify an image. This is what most people mean when they say "the AI", and it is the part the provider guards most closely. You rarely get to see inside it, and you should not expect to.
Above that sits the serving layer: the API, the rate limits, the uptime guarantees, the regions the request gets routed through. This is the part with a service level agreement attached, and it is worth reading the actual SLA rather than assuming "enterprise-grade" means anything specific.
Above that again is everything you have to build: the prompt or workflow that turns a raw model into a feature that does your job, the guardrails that stop it doing something embarrassing, and the plumbing that gets your data to the model and the response back to your user. Vendors are getting better at packaging pieces of this layer as paid add-ons, which blurs the line, but the underlying split does not go away. A hosted retrieval product built on the model still needs someone on your side deciding what gets retrieved and why.
Where responsibility actually sits
The failure mode we see most often is a team assuming the provider owns more of the stack than it does. The model provider is not responsible for whether your prompt leaks a system instruction, whether a tool you wired the model into can be tricked into doing something it shouldn't, or whether the output is fit for the regulatory context you put it in. That is squarely your problem, contract or no contract, and it is the part of an AIaaS rollout that most resembles building rather than buying.
The cost structure, and why the invoice never looks like the demo
The pricing page usually shows a cost per thousand tokens, or per API call, or per document processed. It is a real number and it is also, on its own, close to useless for predicting what you will actually pay, because usage at scale does not look like usage in a demo.
Volume is not the variable that surprises people
Most teams correctly anticipate that more usage costs more money. What catches them out is that cost per interaction is not fixed. A support bot that starts with short single-turn questions and grows a memory of the whole conversation gets more expensive per exchange as the conversation lengthens, because you are usually paying for the tokens the model has to reread each turn, not just the new ones. A document pipeline that worked cleanly on short reports starts choking, cost-wise, the day someone feeds it a 200-page contract. None of this appears on the pricing page, because the pricing page describes a unit cost, not your actual usage shape.
The costs that sit outside the API bill entirely
Then there is everything the invoice does not capture. Engineering time spent handling the provider's rate limits gracefully. The evaluation work needed to catch a quality regression after a silent model update, because providers reserve the right to change the model behind an endpoint without asking. Retry logic for when the service degrades, which every hosted service eventually does. And the discovery, usually made in month three rather than month one, that the feature which seemed cheap at ten users costs something entirely different at ten thousand, because the pricing tier that looked generous in the sales call has a cliff nobody mentioned.
The number on the pricing page describes what the product costs when nobody is really using it yet. What you actually pay is decided by the shape of your real usage, and you do not know that shape until you are already committed to the vendor who is now billing you for it.
None of this is an argument against buying. It is an argument for modelling cost against your actual usage pattern, with real conversation lengths and real document sizes, before you sign anything longer than a month.
Where your data actually goes
This is the question the opening scene of this guide turns on, and it deserves a straight answer rather than a reflexive one. When you send data to an AIaaS provider, three things need answering separately: where the data is processed, whether it is used to improve the provider's models, and how long it persists after the request completes.
Residency is a contractual fact, not an assumption
"The data stays in the EU" is either a clause in your contract naming actual regions, or it is not true, regardless of what a sales deck implies. Many providers offer regional processing as a paid tier or an enterprise-only option, which means the default account, the one your team probably signed up for during the pilot, may not have it. If you are handling anything covered by GDPR, this is not a nice-to-have. Our guide to GDPR compliance covers the wider obligations, but the AIaaS-specific question is narrower: does the contract name the region, or does it just say the provider takes data protection seriously?
Training on your data is an opt-out, usually, not an opt-in
A meaningful share of consumer and lower-tier AI products retain the right to use submitted data to improve their models unless you actively turn that setting off, and the setting is not always where you would expect to find it. Enterprise tiers of the same product frequently offer a genuine no-training guarantee, in writing, which is one of the clearer signals that you are paying for something real. If a vendor cannot point you to the clause, or the toggle, the honest assumption is that your data is training material.
What a DPIA actually forces you to answer
Anyone processing personal data through a new AI tool in a way that could carry risk should run a data protection impact assessment before the tool goes live, not after a customer complains. The exercise earns its keep beyond compliance box-ticking: it forces someone to trace where a piece of customer data goes once it leaves your system, which is exactly the trace missing from the opening scene of this guide. If you have not done one, our piece on data protection impact assessments walks through what it covers.
Vendor lock-in: the exit that never gets built
Lock-in with AIaaS rarely arrives as a single decision. It accumulates, the same way the customer duplication in a messy CRM accumulates: a series of individually sensible choices that add up to a business unable to leave.
Three kinds of lock-in, and they are not equally serious
The mildest is API-shape lock-in. Your code calls a specific vendor's endpoint with their specific request format, and switching means rewriting that integration layer. Real work, but bounded, and a reasonable abstraction layer written early keeps it small.
The harder one is prompt and behaviour lock-in. Months of tuning a prompt against one model's particular quirks, its tendency to be verbose here or terse there, its specific way of following instructions, produces something that does not transfer cleanly to a different model. Switch providers and the same prompt often gets worse answers, not because the new model is worse, but because you spent months adapting to the old one's personality rather than the task.
The most serious is data gravity. Once months or years of interaction history, embeddings, fine-tuning data or a vendor-specific knowledge base sit inside a provider's platform, moving it is a migration project with its own budget and its own risk of data loss. This is the one that actually changes your negotiating position, because the provider knows leaving costs you more than staying does.
The renewal conversation nobody prepares for
None of this is hypothetical when the contract comes up for renewal and the price has moved. A team with a thin abstraction layer and no proprietary data trapped in the platform has a real choice. A team three years into a deeply tuned integration, full history sitting in the vendor's system, is negotiating from a position everyone in the room can see, including the vendor.
Buy versus build: how to actually decide
The honest answer is that most organisations should buy most of the time, and the interesting question is which slice they should not.
Buy when the capability is not your edge
If the AI capability you need is broadly available, general language understanding, transcription, standard document extraction, and your value to customers has nothing to do with how that capability works internally, buying is close to a default. You are not going to out-engineer a foundation model lab with an internal team of five, and trying to is a good way to spend a year rebuilding something you could have rented on day one. Plenty of solid enterprise AI deployments are, correctly, thin layers built on top of a rented model.
Build, or at least own more of the stack, when three things are true together
First, when the model behaviour is the product, and a competitor buying the same underlying capability would erode whatever you are selling. Second, when the data involved cannot leave your environment for regulatory or contractual reasons, and no vendor tier actually solves that, only reduces the risk. Third, when you are already at a scale where the unit economics of a rented API stop making sense against the fixed cost of running something yourself. Any one of these alone rarely justifies building. All three together usually does.
The middle ground most people actually land in
Most real decisions are not a clean buy-or-build split. They are buy the model, build the governance around it. Rent the foundation model, own the evaluation harness that checks its output, own the data pipeline that decides what it sees, own the guardrails that decide what it is allowed to do. That governance layer is where AI governance earns its keep in an AIaaS setup: the provider will not write your policy on what the model can be trusted to decide unsupervised, because that policy is specific to your business, your regulator and your customers, not to the model.
The questions worth asking before you sign
A short, unglamorous list, and worth working through before a pilot becomes a production dependency rather than after.
On the model itself
Ask what happens when the provider updates the underlying model. Do you get advance notice, a way to pin a version, or does behaviour just change under you one Tuesday.
On cost
Ask for the pricing tier boundaries in writing, not just the headline number, and model your actual expected usage against them, including conversations and documents longer than the ones in the demo.
On data
Ask, specifically, whether your data trains the provider's models by default, where processing physically happens, and how long data persists after a request. If the answer is vague, that vagueness is itself the answer.
On the exit
Ask what leaving looks like on day one, before you are three years in and the answer has got expensive. Can you export your data in a usable format? Is your integration a thin wrapper or a dependency? Cheap questions to ask now, expensive ones to discover the answer to later.
Where to start
Start with the use case, not the vendor. Write down what the AI actually needs to do, what data it needs to see to do it, and how sensitive that data is. That short exercise usually answers most of the buy-or-build question on its own, before a single sales call happens.
Then treat the contract as seriously as the capability. Read the data processing terms, not the marketing page. Model the cost against your real usage, not the demo's. Decide, on paper, what an exit would look like before you need one. None of this slows a rollout down much, and all of it is cheaper to do before the data starts flowing than after.
If you are weighing up a hosted AI product, wondering what the contract commits you to, or working out which parts of an AI feature are worth building yourselves, talk to us. We would rather help you ask the awkward questions before the pilot becomes a dependency than unpick one afterwards.