What changes when you outsource AI development instead of traditional software?
Outsourcing AI development changes four things about the contract: acceptance criteria become statistical rather than binary, a significant share of the cost arrives after launch instead of before it, delivery quality depends on data access more than on engineering skill, and regulatory obligations attach to the system's behaviour rather than only to the personal data it holds. A procurement process designed for traditional software will get all four wrong, and the failure usually surfaces at the point of acceptance, when nobody can agree whether the thing works.
The engineering itself is not exotic. What breaks is the commercial framing around it — and that is fixable, provided you write the contract for a system that is right most of the time rather than one that is either correct or defective.
How do AI projects differ from traditional software projects?
| Dimension | Traditional software project | AI or LLM project |
|---|---|---|
| Acceptance criteria | Test suite passes; feature matches specification | Evaluation set scores above an agreed threshold on defined metrics |
| Main cost driver | Engineering hours during build | Engineering hours plus ongoing inference, evaluation and monitoring |
| Biggest delivery risk | Scope creep | Data access delays and unclear success definition |
| Cost after go-live | Low — hosting and maintenance | Substantial and usage-linked |
| Team shape | Backend, frontend, QA | Backend and data engineering, plus evaluation and prompt or model work |
| Regulatory surface | GDPR for personal data | GDPR plus EU AI Act obligations and model or data residency questions |
Why does fixed-price pricing fail for AI work?
Fixed price assumes the vendor can estimate the work from the specification. In AI projects the decisive variable — how well a model performs on your actual data — is unknown until someone runs the experiment. A vendor who quotes fixed price for "an agent that handles customer refund requests" is either padding heavily for that risk or planning to declare success at a quality level you would not accept.
The structure that works is a two-phase engagement. Phase one is a short, fixed-price discovery: build the evaluation set, run baseline experiments, and produce a feasibility report with measured numbers. Phase two prices the build against what phase one learned. This keeps your exposure small while the uncertainty is largest, and it gives both sides a factual basis for the second contract instead of a negotiation about optimism.
How do you write acceptance criteria for an AI system?
Acceptance for an AI feature is a threshold on an evaluation set, agreed before development starts. That evaluation set — a few hundred representative cases with known correct outcomes, drawn from your real data — is the single most valuable artefact in the whole project, and it should be built jointly and owned by you, not by the vendor.
- Define the metrics that matter for your use case: accuracy on the labelled set, escalation or refusal rate, latency at the 95th percentile, and cost per request.
- Agree thresholds per metric, and agree separately what happens between the pilot threshold and the production threshold.
- Specify behaviour on failure — when the system should refuse, escalate to a human, or degrade to a deterministic fallback. This is frequently more important commercially than raw accuracy.
- Freeze the evaluation set before the build and hold back a portion the vendor never sees, so the final measurement is honest.
Without this, acceptance becomes a subjective argument, and subjective arguments at the end of an AI project are how engagements end badly.
What does an outsourced AI project actually cost?
Two cost lines exist where traditional software has one. Build cost behaves like normal engineering and scales with team size and duration. Run cost is new: inference charges that scale with usage, vector storage, evaluation runs on every model change, and observability. A system that is cheap to build can be expensive to operate, and a vendor quoting only the build is quoting half the number.
Require any AI proposal to include a modelled monthly run cost at your expected volume, with the assumptions visible — model choice, average tokens per request, requests per day, caching strategy. Then ask what changes if volume triples. The cost drivers and typical ranges are broken down in our analysis of the cost to build an AI agent. Also confirm who pays for the inference: a vendor billing your usage through their account at a margin is a recurring cost that never appears in the build quote.
Which compliance obligations apply to European buyers?
Two regimes matter, and they interact. GDPR governs personal data as it always did, including any personal data in prompts, retrieval corpora and logs — and prompt logs are the most frequently forgotten processing activity in an AI system. The EU AI Act adds obligations that depend on what the system does rather than what data it holds, with the heaviest requirements falling on high-risk applications such as employment, credit and access to essential services.
Practically, that means your outsourcing contract needs three things it would not otherwise need: a documented classification of the system's risk category with the reasoning behind it, a technical documentation obligation on the vendor that produces the records a regulator would ask for, and a defined position on where inference happens and what the model provider may retain. The classification and timelines are set out in our guide to EU AI Act obligations and the high-risk timeline, and the hosting options in our piece on EU-hosted LLMs and data residency.
How do you evaluate an AI outsourcing partner?
Standard vendor evaluation under-tests the things that distinguish a competent AI team from a team that has read the documentation. Add these to the assessment.
- Ask how they measure quality. A team that answers with an evaluation methodology, a labelled dataset and regression testing is credible. A team that answers with a demo is not.
- Ask what they do when the model is wrong in production — the answer should involve monitoring, human escalation paths and a rollback procedure, not prompt tweaking.
- Ask them to show a cost model from a previous system, with the levers they used to bring it down.
- Test their data engineering, since most AI project delay is data plumbing rather than model work.
- Check they will hand over prompts, evaluation sets and fine-tuning data as your IP — some vendors treat prompts as their toolkit, which leaves you unable to change vendors later.
Should you outsource AI development at all?
Outsource when AI is a capability inside your product rather than the product itself, when you need to move faster than you can hire, or when you need experience with failure modes your team has not encountered. Keep it in-house when the model is the core differentiator, when the data cannot leave your environment under any arrangement, or when the domain expertise required takes longer to transfer than to build. Many European companies run a hybrid: an outsourced pod builds the platform and evaluation harness while in-house engineers own the domain logic and take over operations. Our framework for the underlying decision is in build versus buy for AI agents.
Whichever route you choose, insist on the evaluation set, the run-cost model and the IP position before the first line of code. If you want a partner who works this way by default, our AI application and agent development service starts every engagement with a measured feasibility phase and hands over evaluation harnesses and prompts as client-owned artefacts.
