AI Glossary / AI and machine learning / Beginner
Machine learning as a service
Definition
Machine learning as a service is the delivery of ML capability over the internet as a metered product: instead of building models in-house, you call a provider's trained models or training platform through an API and pay for what you use.
What it means
The pattern follows cloud computing's: the capability lives in someone else's data center, maintained by someone else's specialists, and you consume it like electricity, by the call, by the token, by the hour.
The menu splits in two: ready-made models for standard tasks, vision, speech, translation, language, and platforms that train custom models on your data without you owning the infrastructure.
The trade is capability for dependency. You skip hiring a research team and buying hardware, but your data travels to the provider, your costs scale with usage, and your roadmap inherits theirs, including their price changes and deprecations.
The build-versus-buy line has moved steadily: tasks that required in-house teams five years ago are commodity API calls today, and the sensible default for standard tasks has flipped from build to rent.
For a business, the decision framework is stable: rent for standard capabilities and speed, build where the model is the differentiator or the data cannot leave, and always price the dependency, not just the API.
How it works
Map the need: standard capability or differentiating advantage, and what data would leave your control.
Compare providers on accuracy measured on your data, price at your volumes, and data-handling terms.
Pilot against a baseline: the service should beat your current approach on your real cases, not on a demo.
Wrap the dependency: abstract the provider behind your own interface, so switching costs stay low.
Review usage economics quarterly: metered pricing that was cheap at pilot volume can dominate the budget at scale.
Three practical examples
- A retailer calling a vision API for shelf photos instead of building an in-house recognition team.
- A bank training fraud models on a managed platform, keeping its scarce engineers on features rather than infrastructure.
- A startup whose translation costs, negligible in the pilot, became its third-largest cloud line at scale, triggering a renegotiation.
Think of it this way
Think of power from the grid versus a generator in the basement. The grid gives you electricity without an electrician, billed by the unit, and the generator gives you control at the price of maintenance. Most businesses buy from the grid for standard loads and generate only what is strategic.
The limit: the grid sets the terms. A provider's price rise, deprecation or outage lands in your product on their schedule, so the abstraction layer and the exit plan are part of the purchase, not afterthoughts.
Worked example
the pilot that scaled
Suppose a logistics firm pilots a document-reading API for delivery notes. The figures are illustrative.
The pilot costs almost nothing and lifts processing speed tenfold, so it rolls out nationally within a quarter.
At national volume the metered bill reaches a visible share of margin, and the usage review finds half the calls are re-processing unchanged documents.
Caching and deduplication cut the bill by 40 per cent, and the lesson generalizes: at scale, the architecture of the calls matters as much as the quality of the model.
Illustrative case study
A fictional media company built its product directly on one provider's proprietary API, with no abstraction layer, and woke one morning to a deprecation notice and a ninety-day migration deadline.
The rewrite consumed the roadmap for two quarters, and the board instituted a rule it should have had from the start: every external capability sits behind an internal interface.
The invented lesson: renting the capability is smart; renting it without an exit door is a lease on your roadmap signed by somebody else.
Common misconceptions and mistakes
- It is always cheaper than building. At pilot scale, usually; at scale, the meter runs hot, and the honest comparison includes engineering, dependency and switching costs.
- Using a service means your model improves itself. The provider improves their models on their schedule, which may or may not match your needs, and your data arrangements decide what they learn from you.
- The API quality is the decision. Data terms, pricing at volume, deprecation policy and exit costs decide as much as accuracy.
Business use
Default to renting for standard capabilities, and reserve building for genuine differentiators.
Measure candidate services on your own data before committing, and negotiate data-handling terms explicitly.
Put every external capability behind an internal interface, and review usage economics quarterly as volumes grow.
People also ask
What is the difference from building in-house?
Renting trades an upfront team and infrastructure for metered costs and dependency on the provider's roadmap and terms.
When should I build instead?
When the model is the product's differentiator, when data cannot leave your control, or when metered costs at scale exceed the cost of owning.
What is the hidden cost?
Dependency: price changes, deprecations and outages arrive on the provider's schedule, and switching costs grow the deeper the integration.
Is using a foundation model API machine learning as a service?
Yes; calling a hosted language or vision model by API is the current mainstream form of it.
Check your understanding
Why does the build-versus-rent decision depend on whether the capability is a differentiator?
Answer: Because renting standard capabilities buys speed and avoids fixed costs, while a differentiating model is the product itself, where control, data ownership and roadmap independence are worth the build.
Related terms
- Machine learning
- Cloud computing
- Guardrails
- API
- total cost of ownership
- vendor evaluation
Learn next
AI for Business Owners covers the build-versus-rent decision and how to price the dependency, not just the API: https://aiforbusinessandlife.com/academy/ai-for-business-owners. [C2]
More in AI and machine learning
- Lost-in-the-middle effect - The lost-in-the-middle effect is the tendency of language models to use information at the beginning and end of a long input well, but to miss or garble...
- M-separation - M-separation is a graphical criterion for reading conditional-independence implications from mixed graphs, including ancestral graphs.
- M-theory (learning framework)
- Machine learning control - Machine learning control is the use of machine-learning methods to develop or improve control laws that determine a system's actions from observations.
- Machine Learning Pipeline - A machine learning pipeline is the ordered chain of steps that turns raw data into predictions: collection, cleaning, features, training, evaluation and...
- Machine learning system - A machine learning system is the whole working arrangement around a trained model: data, pipeline, model, serving, monitoring and the people and processes...
Sources
[S12] Aalto University, Dictionary of Machine Learning. Full URLs are in the source ledger. Verified 11 October 2026.
Previous: Machine learning Next: Machine learning control