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
