The staffing plans attached to enterprise AI programmes tend to fail in one of two directions. Either they assume a platform team that the organisation cannot hire in the current market, or they assume a vendor will supply everything and leave no one internally who can operate the result.
Both produce the same outcome a year later: a system nobody owns. What follows is the smaller, more honest version — the roles that actually decide whether an AI transformation ships, and which of them cannot be outsourced.
The five roles that matter
1. The workload owner. Someone who knows what questions the organisation needs answered, and has the standing to say which are worth automating. This is a business role, not a technical one, and it is the single most common gap. Programmes without one build what is technically interesting rather than what is operationally needed.
Cannot be outsourced. A vendor can facilitate the conversation; it cannot hold the judgement.
2. The data-estate owner. Someone who knows where the documents are, which systems hold authoritative versions, and — critically — how access is granted in each.
This role is underestimated more than any other, because the hard part of ingestion is not parsing. It is permissions. An index that does not inherit the source estate's access model will surface documents to people who could not open them in the original system, and the failure is invisible in testing because pilot users usually have broad access.
Whoever holds this role has to be able to answer "who is allowed to see this, and how does the system know?" for each corpus. In most organisations that knowledge is distributed across several people, which is fine — but it has to be someone's job to assemble it.
Cannot be outsourced. The knowledge is institutional.
3. The platform engineer. Serving infrastructure, model lifecycle, retrieval configuration, agent definitions, monitoring.
This is the role organisations assume they must hire a team for, and generally the one that can be shared with a partner most safely — provided the arrangement transfers operational capability rather than creating dependency. The test is simple: after the engagement, can your team stand up a new use case without the vendor? If not, you bought a service, not a platform.
4. The reviewer. Someone who samples outputs, checks citations against sources, and escalates. Part-time, ongoing, unglamorous, and the role most often left unassigned.
The reason it matters is structural. Citation makes error checkable, not impossible — it shows which passage an answer was drawn from, not that the answer follows from that passage. That verification is real work and it needs an owner, or the system's accuracy becomes an assumption rather than a measurement.
5. The accountable executive. Someone with a budget line who answers for the programme at board level. Without this, the project survives until the first difficult question and then quietly stops — not rejected, just unowned.
What you do not need
A data science team. Enterprise AI transformation is systems engineering. Model training is a specialist activity most organisations should not undertake, and open-weight models with good retrieval outperform a badly fine-tuned in-house model on nearly every business task.
A twenty-person platform group. The layer around the model — parsing, retrieval, agent runtime, privacy controls, audit — is a product. Buying it and configuring it is a materially different commitment from building it, and the build path is a multi-year one requiring a team you must then retain.
A dedicated AI centre of excellence, initially. These tend to be created before there is anything to be excellent about. Build one after two or three use cases are running, when there is a real pattern to standardise.
The forward-deployed model
The arrangement that works best in practice is engineers building inside the customer's environment rather than delivering to it from outside.
The reason is specific to this category. Most of the difficulty in an AI deployment is local: the shape of the document estate, the way permissions are granted, the vocabulary people use, the systems agents need to reach. None of that is legible from outside, and a requirements document does not capture it — it is discovered by working in the environment.
For our part, that is how we are set up: ten engineers, more than eighty combined years, organised around forward-deployed delivery rather than remote handover. The relevant point for your planning is not our headcount, though — it is that you should expect a partner's engineers to work inside your environment, and you should staff a counterpart for each of them.
Capability transfer, made concrete
"Knowledge transfer" as a contract clause means nothing. These do:
- Your engineer configures the second use case, with the partner reviewing rather than driving.
- Your team holds the runbook — retraining triggers, escalation paths, what to do when a document is retracted and the index has to forget it.
- Your security team has read the privacy layer. Ours is published as an MIT-licensed library on PyPI precisely so this is possible; whatever partner you choose, ask what they will let your security team read.
- A new use case can be stood up without the original vendor. This is the acceptance test for the whole programme, and it belongs in the contract.
The sequence
- Name the accountable executive before anything else. Everything below is blocked without it.
- Name the workload owner and the data-estate owner. These two determine whether stage two of the programme takes six weeks or six months.
- Decide build, buy or rent — and staff accordingly, not the other way round.
- Assign the reviewer before the first production use case, not after the first bad answer.
- Write capability transfer into the contract as a testable outcome rather than an intention.
Five named people, most of them part-time on this, and a partner arrangement that leaves capability behind. That is a smaller staffing commitment than most AI programme plans assume — and it is the version that still has an owner two years later.
Next: The five-stage roadmap · Build, buy or rent enterprise AI