AI as a service: what you're actually buying

The demonstration lasts ten minutes. A support agent enters a customer ticket into a chat window, and a hosted model generates a draft response. The observers agree that the output is of higher quality than a manual draft. Three weeks later, the legal department asks about the destination of the ticket data after it leaves the browser. They also ask who has access to the information and the duration of its storage. No one involved in the pilot programme can provide a definitive answer. The model itself functioned correctly. The issue was that no one investigated the terms of the service before they began transmitting customer data.

AI as a service, usually shortened to AIaaS, means using AI capability from a provider. You use an API, or click through a vendor's console, and a foundation model runs on infrastructure you do not see. This infrastructure is owned by a company you have a contract with, rather than a codebase you control. Chat completion endpoints, hosted transcription, ready-made document extraction, and a vendor's recommendation engine added to your storefront are all examples of AIaaS. Most organisations using AI in 2026 will be using some form of this service.

Shipshape Data builds data and AI systems. We frequently observe a specific pattern where teams develop models quickly but fail to address the surrounding operational questions.

You should consider the costs, how the vendor handles data, and the consequences if the vendor alters their terms or discontinues a feature.

This guide explains the division of responsibility between an AIaaS provider and your own development team. It describes how actual cost structures vary from advertised pricing and lists specific residency and privacy questions to address before transferring data. It also explains how vendor lock-in occurs unintentionally. Finally, it provides a practical method for choosing between purchasing a service or building a custom solution.

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's 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 receive a functional model from the start, rather than waiting a year for data collection. You avoid the need to employ a research team to stay current with rapidly changing developments in the field. The provider manages infrastructure issues such as GPU capacity, scaling, and the ongoing retraining necessary to maintain a current model. For many organisations, these are not capabilities that provide a benefit from being owned internally. They represent a cost without strategic advantages, and outsourcing them is a practical solution.

The section that people omit

People often overlook the long-term consequences of a purchase. You are agreeing to terms of service that the provider can change with fourteen days of notice. You are accepting data handling clauses designed for legal emergencies that apply to you as soon as a regulator begins an enquiry. You are also agreeing to a pricing structure that reflects the lowest possible cost rather than the actual cost of your specific usage.

The pilot does not include these features because its purpose is to demonstrate the capability rather than the final contract.

What the model covers, and what it doesn't

"AI as a service" covers several different types of products. At least three distinct layers exist within this category. You need to determine which layer you are buying in order to know your specific responsibilities.

The three layers

The lowest level is the model itself: the weights, the training, the raw ability to generate text, transcribe audio, classify an image. This is what most people refer to when they say "the AI", and it is the portion the provider protects most closely. You seldom get to view its interior, and you should not expect to.

Above that lies the serving layer: the API, the rate limits, the uptime guarantees, the regions through which the request is routed. This is the component that includes a service level agreement. Review the actual SLA.

Don't assume "enterprise-grade" means anything specific.

The layer above the model comprises the components you must construct. It includes the prompt or workflow that turns a raw model into a functional feature. It also contains the guardrails that prevent errors and the infrastructure that transfers data between the model and the user. Vendors are increasingly offering parts of this layer as paid services, which blurs the distinction, but the fundamental division stays. Even when you use a hosted retrieval product, your team must still decide what information is retrieved and why it is retrieved.

Where responsibility sits

The most common failure happens when a team assumes the provider handles more of the technology stack than it actually does. The model provider is not accountable for system instruction leaks or for vulnerabilities in the tools you connect to the model. They are also not responsible for ensuring the output complies with the regulatory requirements of your specific industry. These responsibilities belong to you regardless of your contract. This portion of an AIaaS implementation is equivalent to building your own software.

The cost structure, and why the invoice never looks like the demo

Pricing pages usually list costs per thousand tokens, per API call, or per document processed. These figures are accurate, yet they do not help you predict your actual expenses. This is because your usage at scale will differ from your usage during a demo.

Volume isn't the variable that surprises people

Most teams expect increased usage to lead to higher costs. However, many are surprised to discover that the cost per interaction is not constant. A support bot may start with brief, single-turn questions. As it builds a memory of the full conversation, it becomes more expensive for each exchange. This occurs because you typically pay for the tokens the model rereads each turn in addition to the newly generated tokens. Similarly, a document pipeline that processes short reports efficiently will become far more expensive when used for a 200-page contract. These details are not shown on pricing pages. Those pages list unit costs instead of the specific patterns of your actual usage.

Costs that are not included in the API bill

Invoices do not include several hidden costs. Engineers must spend time writing code to manage provider rate limits. Teams must perform evaluation work to identify quality regressions after silent model updates, since providers often change models without notice. Developers must also build retry logic for service degradations, which occur with all hosted services. Additionally, companies often discover by the third month that features which were affordable for ten users become expensive for ten thousand. The pricing tiers that appear generous during sales calls often contain cost increases that were not previously disclosed.

The price shown on the website reflects the product cost before it is used at scale. Your actual expenses depend on your particular usage patterns. You cannot reliably forecast these costs until you have integrated the service and the vendor starts billing you.

These statements do not imply that you should refrain from purchasing.

You ought to model costs based on your actual usage patterns before agreeing to a contract that exceeds one month. Apply genuine conversation lengths and document dimensions to compute these numbers.

Where your data goes

This guide starts by addressing this question. You are required to give a direct answer. When you transmit data to an AIaaS provider, you need to evaluate three distinct factors. You must determine where the data is processed. You must verify whether the provider employs it to train its models. You also have to find out how long the data stays on their systems after the request completes.

Residency is a contractual fact, not an assumption

The statement "The data stays in the EU" is either a clause in your contract that names specific regions, or it is false, regardless of any sales presentation. Many providers provide regional processing as a paid service or as an option limited to enterprise customers. Consequently, the standard account-the one your team probably signed up for during the trial period-might not contain this feature. If you handle data subject to GDPR, this feature is mandatory. Our guide to GDPR compliance addresses the broader requirements, yet the AIaaS-specific question is narrower: does the contract specify the region, or does it merely claim that the provider prioritises data protection?

Training on your data is an opt-out, usually, not an opt-in

Many consumer-grade and lower-tier AI products employ submitted data to train their models by default. You often need to manually disable this feature, and the required setting is often hard to find. Enterprise versions of these products typically offer a written guarantee that data will not be used for training. Such a guarantee reliably indicates a professional service level. If a provider cannot present the specific contract clause or the software toggle that blocks data usage, you should assume they are using your information to train their models.

What a DPIA requires you to explain

You should conduct a data protection impact assessment before deploying any new AI tool that processes personal data and poses potential risks. You should not wait for a customer complaint before carrying out this review. This process serves purposes beyond merely meeting regulatory requirements. It obliges you to track the movement of customer data after it exits your system, addressing the gap mentioned at the start of this guide. If you have not yet performed this assessment, our article on data protection impact assessments outlines the required steps.

Vendor lock-in: the exit that never gets built

Lock-in with AIaaS typically occurs gradually.

The problem expands similarly to how duplicate customer records pile up in a disorganised CRM. Each individual decision appears reasonable at the moment, yet the aggregate outcome is a business unable to alter its systems.

Three kinds of lock-in, and they aren't equally serious

API shape lock-in represents the least severe form. Your code uses a particular vendor's endpoint and request format. Switching demands that you rewrite that integration layer. This entails actual labour, yet the scope remains limited. You can reduce this work by creating a reasonable abstraction layer early in the process.

Prompt and behaviour lock-in presents a more challenging issue. You might spend months tweaking a prompt to match the specific habits of a model, such as its tendency to be wordy or brief and its unique method of following directions. This process yields a prompt that performs poorly with a different model. If you switch providers, the same prompt often yields lower-quality results. This outcome rarely occurs because the new model is inferior. It usually occurs because you spent months adapting to the previous model's personality rather than concentrating on the task itself.

Data gravity represents the most serious issue. When a provider's platform holds years of interaction history, embeddings, fine-tuning data, or a specific knowledge base, transferring that information demands a dedicated migration project. These projects carry their own budgets and risks of data loss. This situation weakens your negotiating position. The provider recognises that the cost of leaving their service exceeds the cost of staying.

The renewal conversation nobody prepares for

These situations are practical realities when a contract ends and the price rises. A team that employs a thin abstraction layer and keeps its data independent can switch providers. A team that has invested three years in a deep integration and stored its entire history in the vendor's system possesses very little bargaining power. Both the team and the vendor recognise that the customer cannot easily depart.

Buy versus build: how to decide

Most organisations ought to purchase software in most cases. The decision to build should be confined to specific areas.

Buy when the capability isn't your edge

If you need common AI capabilities such as general language understanding, transcription, or standard document extraction, and your business value does not rely on the internal mechanics of those tools, you should generally purchase them. A small internal team cannot develop better technology than a foundation model lab. Attempting this often leads to spending a year recreating a service that was already available for rent. Many effective enterprise AI systems are designed as simple layers built atop external models.

Build, or at least own more of the stack, when three things are true together

The model's behaviour constitutes your product. If a rival acquired the identical underlying capability, it would diminish the value of your offering. Regulations or contracts prevent your data from leaving your environment. No vendor tier removes this problem; it merely reduces the risk. You have arrived at a scale where the unit economics of a rented API exceed the fixed cost of operating your own system. A single factor by itself seldom justifies constructing your own model. When all three conditions exist, building is typically the right decision.

The position that most people choose

Most practical decisions do not present a clear buy-or-build dichotomy. They involve buying the model and constructing the governance surrounding it. Rent the foundation model, retain ownership of the evaluation harness that validates its output, retain ownership of the data pipeline that determines what it observes, and retain ownership of the guardrails that dictate what it may do. That governance layer is where AI governance makes its value in an AIaaS arrangement: the provider will not craft your policy on what the model may be trusted to decide without supervision, since that policy is tailored to your business, your regulator, and your customers, not to the model.

The questions worth asking before you sign

Examine this list before converting a pilot project into a production dependency.

On the model itself

Enquire with the provider about their procedure for updating the underlying model. Find out whether they provide advance notice or permit you to lock a particular version, or if the model's behaviour may change without warning.

On cost

Ask for the exact pricing tier limits in writing together with the base price. Apply your anticipated volume to model costs across these tiers. Add calculations for conversations and documents that exceed the length of the examples shown in the demonstration.

On data

Request precise information on whether the provider defaults to using your data to train their models. Determine the physical location of data processing and the retention period for the data after a request. If the provider responds vaguely, consider that lack of clarity as the answer.

On the exit

Enquire about the exit process on the first day of a project. It is preferable to obtain this information before you have invested three years in a system and the cost of exiting has risen. Find out whether you can export your data in a usable format. Verify whether your integration is a simple connection or a deep dependency. These questions are straightforward to answer now but will become difficult to resolve later.

Where to start

Start by pinpointing the specific use case rather than concentrating on the vendor. Record the tasks the AI must carry out, the data needed for those tasks, and the sensitivity level of that information. Finishing this process usually clarifies whether to buy or build a solution before you approach any sales representatives.

You should give the contract as much priority as the technical capability. Examine the data processing terms rather than the marketing materials. Compute the costs based on your actual usage instead of the demonstration figures. Record your exit strategy before starting the implementation. These steps do not considerably delay a rollout. Finishing this work before data transmission starts is cheaper than doing it later.

If you are assessing a hosted AI product, reviewing contract terms, or choosing which AI components to build internally, talk to us. We prefer to assist you with difficult questions during the pilot phase instead of fixing issues after you have become dependent on the service.

Are you figuring out how this applies to your organisation? Our AI strategy service assists you in identifying an initial profitable use case and the order for subsequent projects.

Frequently asked questions