Building the Team That Carries an AI Transformation

Behind every stalled AI transformation is a team-shape decision that was never made deliberately. Central lab, embedded experts, or hub-and-spoke; hire, borrow, or train, here is how to decide, and in what order.

Elena Voss·Head of AI Delivery, Aiporate··9 min read·Share on XLinkedIn

Key takeaways

  • There are three basic team shapes, central AI team, embedded-in-business-units, and hub-and-spoke, and for most mid-sized companies hub-and-spoke wins: a small central core for standards and platform, plus champions and use-case owners inside the functions.
  • Hire, borrow, train is a per-role decision: hire the durable core (AI lead, data engineering), borrow scarce build-phase expertise through embedded external experts or fractional leadership, and train the domain experts you already employ, they hold the context nobody can hire.
  • Sequencing beats headcount: do not hire a large AI team before the first use case is proven. Prove value with a minimal team plus borrowed expertise, then let hiring follow evidence.
  • The internal champion is a real role, not a vibe: named per function, given time and a mandate, connecting the central core to the daily reality of the business unit.
  • Every external engagement should be structured for skill transfer: embedded experts who work alongside internal staff leave capability behind; black-box deliveries leave dependency behind.

Ask why an AI transformation stalled and you will usually hear about models, vendors or budgets. Look closer and the root cause is almost always organizational: a central AI lab that built impressive demos no business unit asked for, or scattered enthusiasts who automated their own corner while the organization learned nothing. The team question, what shape, which roles, hired or borrowed or trained, and in what sequence, is the load-bearing decision of a transformation, and most companies make it by accident.

The three team shapes, and who each one fits

ShapeHow it worksStrengthFailure modeBest fit
Central AI teamOne dedicated unit owns AI: platform, models, deliveryConcentrated expertise, consistent standards, critical massIvory tower: builds what impresses peers, not what the business asked for; every project queues behind one teamLarge organizations with many parallel initiatives and real platform needs
Embedded in business unitsEach function hires or develops its own AI capabilityMaximum business proximity, solutions fit real workflowsFragmentation: three chatbots, no shared standards, no learning across units, duplicated vendor spendCompanies with a few strong units and genuinely divergent domains
Hub-and-spokeSmall central core (platform, standards, vetting, reuse) plus champions and use-case owners in the functionsBusiness proximity and consistency; knowledge flows through the hubUnderpowered hub becomes a bottleneck or a formality if not resourced and mandatedMost mid-sized companies, and the default recommendation for a first transformation
AI team shapes compared

Hire, borrow, or train: a per-role decision

  • Hire (durable core): the AI/data lead who owns the roadmap, and data engineering, the foundation every use case stands on. These roles compound over years and should sit on your payroll and hold your context.
  • Borrow (scarce, phase-bound): senior applied-AI engineers for the build phase of your first use cases, and fractional leadership (a part-time Head of AI) when you need strategy and vendor judgment before a full-time hire is justified. Embedded external experts close the gap between ambition and proof without a nine-month search, on the explicit condition that they work alongside your people, not in a separate room.
  • Train (context holders): the domain experts you already employ, the service lead who knows every escalation pattern, the production planner who knows why the schedule breaks. Their context cannot be hired at any price; AI fluency can be trained in months. These people become your use-case owners and champions.
  • The classic mistakes are symmetric: hiring what should be borrowed (a permanent team ahead of proven value, burning runway on idle salaries) and borrowing what should be hired (renting your data foundation forever, so no capability accumulates).

Sequencing: the team follows the proof, not the other way around

The most expensive team-building mistake is hiring for the transformation you announced rather than the one you have proven. A big-bang AI team hired before the first use case works creates a machine that must justify itself, which is how organizations end up with impressive infrastructure, restless engineers and no shipped value, and eighteen months later, a quiet round of departures. The sober sequence: phase one, one accountable internal owner plus borrowed build expertise proves the first use case end to end. Phase two, once value is measured, hire the durable core, the data engineer, then the first applied engineer, and name champions in the two functions with the strongest proven cases. Phase three, as use cases multiply, grow the hub deliberately and let each hire map to a pipeline of real work. Senior AI talent evaluates employers on exactly this: they join where something already shipped, which means proving value first also lowers the cost and risk of every subsequent hire.

The internal champion: the role that decides adoption

Between the central core and each business function stands the role that most transformations leave to chance: the internal champion. This is a respected practitioner inside the function, not necessarily technical, who translates in both directions: what the AI team builds into what the team on the floor actually does, and what the floor actually needs into requirements the builders can act on. Done properly it is a named role with protected time (a day a week is a realistic floor), direct access to the hub, and a mandate to say "this tool is not ready" without career risk. Champions are chosen for credibility with their peers, the person colleagues already ask for help, because adoption spreads along trust lines, not org charts. Companies that skip this role discover that deployment is not adoption: licenses get bought, tools get mandated, and usage quietly collapses after the launch week.

Using external partners without building permanent dependency

  • Contract for transfer, not just delivery: every embedded engagement should name the internal people who will co-build, and define what they must be able to run alone at the end.
  • Keep architecture and data ownership internal from day one, external experts advise on it, but the accountable owner has your email domain.
  • Prefer embedded collaboration over black-box delivery: a finished system nobody internally understands is a liability with a warranty, not a capability.
  • Time-box and review: borrowed roles should have an explicit end state, converted into a hire, handed to a trained internal owner, or consciously renewed, never an indefinite drift.
  • This is the model Aiporate is built around: vetted AI engineers and fractional leaders embedded into your team for the phase where they are needed, with skill transfer as an explicit part of the engagement rather than an afterthought.

Frequently asked questions

Should we build a central AI team or embed AI people in business units?

For most mid-sized companies, neither extreme: hub-and-spoke wins. A small central core owns platform, standards and reuse, while named champions and use-case owners inside the functions keep the work anchored in real business problems.

Which roles should we hire first?

After the first use case is proven: a data engineer (the foundation every use case shares), then an applied AI engineer, then, as the portfolio grows, an AI lead if you have not already covered that via fractional leadership. Before the first proof, keep the permanent footprint minimal and borrow the build expertise.

What exactly is an internal AI champion?

A respected practitioner inside a business function with protected time and a mandate: they translate between builders and users, surface real requirements, pilot tools with their team and have standing to say a tool is not ready. Champions are the difference between deployment and adoption.

How do we use external AI experts without becoming dependent on them?

Structure every engagement for transfer: internal co-builders named in the contract, architecture and data ownership kept internal, an explicit end state for the borrowed role, and joint working rather than black-box delivery. External experts should leave capability behind, not a system only they can operate.

Head of AI Delivery, Aiporate

Elena has spent 12 years building and embedding AI and data teams inside B2B SaaS companies, from first pilot to enterprise-wide platform. At Aiporate she leads how forward-deployed talent is matched, onboarded and shipped to production.

Need the team to make this real?

Describe your need in plain English, get the exact hire, forward-deployed talent or a fractional leader, vetted and matched in 72 hours.

Scope your need →

Keep reading

The Weekly Brief

Intelligence for building AI-native organizations.

One email a week: the sharpest thinking on AI hiring, infrastructure, teams and strategy, for the people building the future of work.

Join operators, founders and CTOs. No spam, unsubscribe anytime.