AI development services consist of seven distinct pieces of work, and a scope that names all seven is a scope that can be argued about honestly. Discovery and problem selection — deciding which task is worth automating and what a wrong answer is. Data and retrieval — getting the right context in front of the model, with permissions intact. The model layer — prompts, tools, structured output, routing, fallbacks. The evaluation harness — the golden dataset and the score that gates a release. Integration — writing into the systems of record where the value actually lands. Observability and cost control — traces, spend, latency. Operate — the part that never ends. Most proposals price the third and the fifth, mention the first, and leave the rest to be discovered by the buyer at the worst possible moment.
The vagueness is load-bearing. "AI development" describes anything from a chatbot on a marketing site to an agent with write access to a general ledger, and a proposal that never distinguishes them can be read favourably by both parties right up until delivery. That is exactly when scope arguments happen: not because someone lied, but because two people agreed on a noun. The remedy is to write the scope as seven named workstreams with an owner and an acceptance test each, which is a document a buyer can produce without any vendor's help.
Discovery and problem selection is the cheapest place to change your mind and the one most often skipped for looking unproductive. The work is concrete: inventory the candidate tasks, measure how they are done today, establish a baseline number for each, and score them on value against feasibility. Then write the definition of a wrong answer for the top one or two — which is a business decision, not a technical one. Skipping this is how a team ends up with a technically excellent system for a problem that was never expensive. Our own AI readiness assessment exists as a separate paid two-week engagement for this reason: the output is a prioritised roadmap with baselines, and it is yours whether or not you build the thing with us.
The data layer is where the eventual quality is mostly decided, and it starts before retrieval. NIST's generative-AI profile of its Secure Software Development Framework treats this as a first-class practice: it asks producers to "analyze data for signs of data poisoning, bias, homogeneity, and tampering before using it for AI model training, testing, fine-tuning, or aligning purposes," and to "track the provenance, when known, of all training, testing, fine-tuning, and aligning data used for an AI model, and document which data do not have known provenance" (NIST, SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models, July 2024). Practically, this workstream is extraction and cleaning, chunking and embedding, a retrieval strategy and the evaluation of that strategy on its own, freshness and re-indexing, and — the part that gets missed — carrying source-system permissions into the index so two people with different entitlements get different answers.
The model layer is the smallest of the seven and the one buyers picture when they hear the category. It is prompt design under version control, tool definitions, structured output with validation, model routing where a cheaper model can do the work, retry and fallback behaviour, and guardrails on what may be said or done without a human. Worth naming plainly: this is the layer that improves fastest on its own, and the layer where the vendor adds the least durable value. Everything around it is what still has to exist when the model is replaced.
It is also worth being honest that the category name oversells what most organisations are actually deploying. Eurostat found 19.95% of EU enterprises using any AI technology in 2025, but the spread by sector is enormous — 62.52% in information and communication and 40.43% in professional, scientific and technical activities, against 10.79% in construction and 24.82% in real estate (Eurostat, Use of artificial intelligence in enterprises, data extracted December 2025). The same survey found the leading obstacle among enterprises that considered AI and did not adopt it was a lack of relevant expertise, at 70.89% — ahead of legal uncertainty at 52.52% and data-protection concerns at 48.83%. Cost is not the top barrier. Knowing how to do the other six workstreams is.
The evaluation harness is the workstream most likely to be missing from a proposal and the one that determines whether anything can be improved after launch. It is a golden dataset of real cases with recorded correct answers, a scorer per case type, a run that executes on every change, a threshold that blocks a release, and a schedule that reruns it against production traffic so a regression is found by you rather than reported by a customer. In a generative catalogue pipeline we built, that meant per-category prompts with structured output validation, a human review queue for low-confidence items with automated approval above a threshold, and continuous evaluation against a golden dataset with drift alerts (generative catalog intelligence). The evaluation suite covers how to build one.
Integration into systems of record is where the value is realised and where the cost is systematically underestimated, because connecting is easy and the semantics are hard. The work is a service identity scoped to exactly what the system may touch, an audit trail attributing every change to the run that made it, idempotent writes so a retry cannot issue a second refund, a reconciliation path for half-completed multi-system changes, and a human approval gate on anything irreversible. None of that is model work; all of it is required before an AI system may write to a CRM, an ERP or a ledger. What breaks when AI meets a system of record sets out the five failure modes in detail, and it is the substance behind AI integration services.
Observability and cost control is two jobs in one line item. The observability half is per-request traces, token counts, latency percentiles, error and refusal rates, and a sample of real outputs a human actually reads each week. The tooling for it is mostly conventional: among developers who build agents, Stack Overflow's 2025 survey found Grafana and Prometheus used by 43% and Sentry by 31.8%, well ahead of AI-native options such as LangSmith at 12.5% and Langfuse at 8.8% (Stack Overflow, 2025 Developer Survey: AI). If a vendor proposes an exotic observability stack, ask why the ordinary one will not do.
The cost half is an architecture decision, not a procurement one, and the multipliers are published. Anthropic's documentation states that five-minute cache writes cost 1.25 times the base input token price, one-hour cache writes 2 times, and cache reads 0.1 times — an order of magnitude between a prompt that is structured to be cached and one that is not (Anthropic, Prompt caching, Claude Platform documentation). Anthropic's batch processing documentation adds a second lever: asynchronous batch processing is charged at 50% of standard prices, with most batches completing within an hour and results available within 24 hours. Anything not user-facing — nightly enrichment, backfills, evaluation runs — belongs there. A system designed without either lever can cost several times what the same system costs designed with them, on identical volume.
The seventh workstream is operate, and it does not end. It is model migrations on published retirement dates, prompt and retrieval changes as the business changes, re-running evaluations after every one of those, incident response, cost review, and the quarterly question of whether this is still the right task to automate. The industry has not automated this away for itself: in the same Stack Overflow survey, 76% of developers said they do not plan to use AI for deployment and monitoring — the most resisted task in the whole development workflow. Budget it as staffed work with a named owner. What it costs to run an AI agent in production breaks the recurring side down.
Three of the seven are the ones buyers routinely fail to budget, and they are always the same three. The evaluation harness, because it produces no visible feature and is therefore the easiest thing to defer into a phase two that never arrives. Permissions and audit inside the integration, because the demo worked with a token that could see everything, and nobody re-scoped it. The operate phase, because a launch date feels like an ending. A useful test on any proposal: if the price does not change when you ask for a golden dataset, a per-user permission test and a ninety-day operating plan, then those things were never in it or were never going to be real.
Two clarifications that save arguments later. Not every engagement needs all seven at full depth — an internal drafting assistant with no write access can run a thin integration workstream, and a system that touches a ledger cannot. And the order matters: discovery before data, data before model, evaluation before integration, integration before scale. Teams that invert the last two build something impressive that cannot be released, because there is no agreed measure of whether it is safe to release.
A reader who has followed this far can now write their own scope: seven headings, an owner and an acceptance test under each, and an explicit note where a workstream is deliberately thin. That document is worth more than any vendor's proposal template, because it is the thing you compare proposals against. Our AI development services page lists the capabilities behind each of the seven, and how to evaluate an AI development company turns the same seven into the questions to ask the firms bidding for the work.
Related: AI development services
Find this useful? Tell Google to show you more of it.