AI and machine learning: from use case to production

What it covers

A complete chain, from the first use case selected to a monitored model in production. This page describes engineering work, quoted per project: if what you need is for your own teams to know how to work with these tools, that is the fixed-price AI training catalogue.

• Use-case framing and prioritization
• Machine learning on AWS (SageMaker, Bedrock)
• Data and analytics pipelines
• Evaluation and guardrails before go-live
• MLOps: model industrialization and monitoring
• Cost tracking per use case

How we work

Two principles, in this order: build nothing before measuring what it returns, and put nothing live that is not monitored.

Managed model or trained model: the first decision

The first question is not which model, it is whether you need to train one at all. Three answers, by increasing cost.

A managed service that already answers. Transcription, document extraction, translation, semantic search: building blocks billed per use, with no dataset to assemble and no model to maintain. When an existing block covers most of the need, it is almost always the right answer.

A foundation model, steered by your data. Amazon Bedrock gives access to models you do not train but do contextualise: instructions, retrieval over your own documents, guardrails. The effort goes into the data and the evaluation, not into training.

A model trained on your data. Amazon SageMaker, when the task is specific to your business and no generic model covers it. It is the most expensive option: it assumes a labelled dataset, a retraining chain and someone to hold it.

We start at the top of that list. Going one step down is justified by a measurement, not by a technical preference.

What “in production” actually means

A model in production is not a model that answers: it is a model where you know, at any moment, what it answered and why. Four things separate it from a demo.

A reproducible data chain. Inputs arrive through a versioned pipeline, not as a file dropped in by hand.

An evaluation before go-live. A reference set of cases, replayed on every version or model change. Without it, a provider update becomes a regression nobody sees before the user does.

Monitoring. Latency, cost per call, error rate and input drift, in the same place as the rest of the platform.

Human review of what comes out. That is a usage rule, not a technical option, and it is written down before go-live.

Cost is steered like the rest of the cloud

A model call is billed per token, training per compute hour, a vector index per storage and per query. These are ordinary cloud bill lines, with the same drift: a test environment left running overnight, a model oversized for the task, a job that recomputes everything instead of the increment. Cost per use case is instrumented from go-live, with the same levers as the rest of the bill.

Engineering or training: which of the two

Engineering when something has to run without your teams: the chain is built, monitored and held, and it is quoted per project. Training when it is your teams who need the skill: three fixed-price tracks, on your own files.

The tracks have a page each: leadership team, technical teams, management and business teams. The two are often combined, in that order: training puts the method into the teams, engineering holds what has to keep running without them.

Frequently asked questions

Where we operate

We operate your platforms worldwide, in every cloud region, with no geographic limit.