Enterprise ai team

• 02 Jun, 2026
• • AI Strategy

How to Structure an AI Team That Can Actually Deliver

The team structure that gets proposed for most enterprise AI programs looks roughly like this: two or three data scientists, a data engineer, an ML engineer, a product manager, and maybe a business analyst. Sometimes there's a director of AI or a head of data science above them. It looks reasonable. It's often wrong. Not because those roles are wrong, but because the configuration doesn't match the actual work of delivering AI in enterprise settings — and because the roles most critical to production success are frequently the ones hired last, or not at all. The build vs run mismatch The most consistent structural mistake I see is treating AI delivery as a single phase when it's two distinct phases with different skill requirements. Building a model — running experiments, selecting features, iterating on architecture, evaluating performance — requires people who are comfortable with uncertainty, who can work through failures without losing momentum, and who have the technical depth to make good modeling decisions. These are data scientists and ML engineers with research instincts. Running a model in production — monitoring performance, managing retraining pipelines, diagnosing inference latency issues, responding to alerts — requires reliability engineering instincts. Discipline around operational procedures, comfort with incident response, a preference for stable and observable systems over novel approaches. These are different jobs. They attract different people. Training a great data scientist to be a great MLOps engineer is possible but slow and frequently frustrating for both the person and the organization. The right approach is to hire for both functions, with deliberate thought about when each is needed. In most programs, MLOps is understaffed at the start because the instinct is to hire modeling capability first and figure out production later. This works during the build phase and creates a bottleneck at the production transition that extends timelines by months and degrades output quality. The roles that actually determine delivery The model quality matters. Whether the program succeeds depends on other things. The ML engineer or MLOps engineer. This role is consistently underhired relative to its impact. The person who owns the pipeline from raw data to trained model to deployed endpoint to monitored output is carrying the weight of the whole production system. Without someone genuinely owning this, models get trained but not deployed, or deployed but not monitored, or monitored but not retrained when performance drifts. The data science team gets blamed for production problems that are actually infrastructure and operations problems. The data engineer. Not a data scientist who also knows SQL — a specialist whose job is to build, maintain, and improve the data pipelines that feed the models. Data engineers are frequently absent from AI team design, with the assumption that data infrastructure will come from somewhere else in the organization. When it doesn't — and in most enterprises it doesn't, because the data engineering capacity is already allocated to other programs — model training becomes ad hoc, feature engineering gets rebuilt from scratch for every use case, and the first retraining cycle reveals that nobody documented what the original training data looked like. The domain expert. Not always a formal hire, but always a critical relationship. Every enterprise AI use case operates in a domain — fraud, logistics, finance, clinical care — and the model's outputs have to make sense in that domain. A domain expert who can validate model behavior against operational knowledge, who can identify when outputs are technically correct but operationally nonsensical, is the difference between a model the business trusts and one it doesn't. The product owner. Not a traditional product manager — someone who can hold the operational specification of the AI system: what it needs to do, what the performance thresholds are, what business rules govern its use, how success is measured. In many AI programs this role gets rolled into the data science lead or left undefined. When it's undefined, requirements drift, scope expands, and the model ends up solving a subtly different problem from the one the business originally described. The accountability model The organizational question that matters most isn't team structure — it's accountability. Who owns what, and what happens when it's unclear? In a well-structured AI team, accountability maps cleanly to the phases of the system's life: someone owns the model's technical performance, someone owns its operational behavior in production, someone owns the business outcome it's driving, and someone owns the cost of running it. These may be the same person in a small program or different people in a large one. The important thing is that each accountability is named and unambiguous. The failure mode is when accountability is assumed to be shared. A model that's jointly "owned" by the data science team, the business unit, and IT is owned by nobody. When performance drifts, each team has an explanation for why it's the other team's problem. By the time accountability is resolved, the drift has already cost the business something. The team size trap When AI programs are under pressure, the instinct is often to add headcount. More data scientists, more engineers, the problem gets solved faster. This is sometimes true and usually not. Headcount helps when the constraint is capacity — there's more work than the team can do. It doesn't help when the constraint is clarity — nobody is sure what the right thing to build is, who owns the decision, or what the requirements actually are. Adding people to a clarity problem makes the problem worse: more people, more interpretations, more work produced in directions that don't align. Before adding headcount, the question should be: what is the actual constraint? If it's capacity, add people with the specific skills the bottleneck requires. If it's clarity, add process — requirements definition, decision rights, explicit ownership — before adding people. I've seen programs double their team size and slow down because the new people inherited the same unclear mandate the original team was operating under. The hiring sequence Starting from zero, with a defined use case and a twelve-month production timeline, the hiring sequence I'd follow: Hire the data engineer and the ML engineer before the data scientists. Get the infrastructure in place first. A data science team without working pipelines produces notebooks that never get to production — and hiring in the wrong order means the data scientists spend the first three months doing their own infrastructure work while the models wait. Hire the data scientists once there's something to hand off to. At that point, the infrastructure exists to take model artifacts and push them toward deployment. Identify and contract the domain expert in parallel with the early hiring. This can be an internal secondment or an external advisor — the important thing is access, not full-time headcount. The product ownership function needs to be filled at day one. This is frequently someone who already exists in the organization: a business analyst with the right domain knowledge, a senior person from the business function sponsoring the use case. Whatever form it takes, the role needs to exist before the team starts building anything — because without it, the team will eventually build the wrong thing efficiently, and efficiency at the wrong thing is its own kind of expensive.

Read full article