What team and skills do you need for AI?

AI strategy needs more than data scientists. Here's the roster and why each role matters.

Beyond the data scientist myth

A finance director hires a data scientist, points them at "the data", and waits for a model. Six months later there's a notebook full of promising charts, no production system, no sign-off from compliance, and nobody in the business who trusted the output enough to act on it. Nothing shipped. This is the most common way we've seen organisations waste a year on AI, and it's rarely the data scientist's fault. One person, however good, cannot own data quality, a business problem, deployment, security review, and adoption at the same time. AI strategy needs a roster, not a hire.

The core roster

An executive sponsor. Holds budget authority and takes the political heat when a project threatens someone's turf. Without this person, priorities get renegotiated every time a department head objects.
A product manager. Owns outcomes, priorities, and trade-offs across initiatives. This is the person who says no to the fifth "nice to have" model and keeps the team pointed at the problem that matters.
Domain experts. People from the business area who know what "good" looks like, and who can tell you when a model's output is technically correct but practically useless.
Data engineers. Because most AI failures are data failures — missing fields, inconsistent formats, access that nobody documented. This work is unglamorous and it is where the majority of project time goes.
ML/AI engineers. Build, evaluate, and monitor models. Distinct from data engineering, and often the smallest team by headcount even though it gets the most attention.
Legal and compliance. Early, not at the end. Retrofitting a data protection review onto a finished system is where good projects die in week 25.
Change and comms. The reason adoption succeeds or fails. This is the role most often cut when budgets tighten, and it's usually the reason the finished system sits unused.
Security and privacy. Especially for anything customer-facing, or anything touching personal or commercially sensitive data.

What you can borrow vs what you must own

You can borrow engineers, data scientists, and delivery capacity from partners and contractors — that expertise is portable and doesn't need to live inside your organisation permanently. You cannot borrow the sponsor, the product manager, or the domain experts. Those three roles carry institutional memory, business context, and accountability that a contractor walks away with at the end of the engagement. If you outsource them, you get a system nobody inside the business understands well enough to run, fix, or extend once the contract ends. Bring in outside capability to build; keep ownership of direction and judgement in-house.

How the roster changes as you scale

At pilot stage — one use case, one team — you can run with a sponsor, a product manager wearing two hats, a domain expert, and a borrowed engineer or two. That's enough to prove or kill an idea cheaply. Once you're running three or four AI initiatives across departments, the shared roles start to strain: one product manager can't hold trade-offs across finance, operations, and customer service at once, and legal review becomes a bottleneck if it's still one person fitting it around other work. At that point you need a small platform team — shared data engineering and MLOps — sitting underneath initiative-specific domain experts and product owners. The mistake we see most is organisations trying to run five initiatives on the team they built for one, then wondering why nothing ships on time.

Common skills gaps to plan for

AI literacy at the leadership level. Most executive teams still can't articulate the difference between a large language model and a classifier, which makes it hard for them to sponsor projects well or ask the right questions in a steering meeting.
MLOps. Getting models into production and keeping them healthy once they're live — monitoring drift, retraining, rollback plans. This is a different discipline from building the model in the first place, and it's frequently missing entirely.
AI product management. Different from feature product management: the roadmap has to account for model uncertainty, data dependencies, and the fact that "done" doesn't mean "finished" the way it does for a UI feature.

The pitfall worth naming directly: when budgets get squeezed, change and comms is usually the first thing cut, on the reasoning that it's "not technical work." It's the reason technically sound projects get built and then ignored. Protect it the same way you'd protect the engineering budget.

What to do next

Map your current roster against the eight roles above. Mark each as covered, partially covered, or missing.
For every gap, decide explicitly whether to hire, train, or borrow — don't leave it unresolved.
Check that your sponsor, product manager, and domain experts are named individuals, not "TBC."
Budget for change and comms as a line item from the start, not as an afterthought if money remains.

Where Florence helps

Florence's learning path covers the leadership AI literacy gap directly, building the shared vocabulary a sponsor and product manager need to make good calls together. As you move through the Assessment and Strategy steps, Florence also prompts you to name the roles behind each initiative — sponsor, domain expert, and the rest — so gaps in your roster surface before they cost you a quarter, not after.