Key takeaway: Building an AI team in a GCC can take two very different paths. Arranged one way, they deliver HQ’s AI projects well enough, on time, forever. Arranged another way, they become the team that takes an idea, turns it into something that runs, and proves it works. BUT: only one of these arrangements helps your GCC lead initiatives that scale. And no, it isn’t the headcount or the budget. How to build that team? It’s precisely what this article answers.
—
Imagine this: you are a CTO or a CIO who’s walking into a newly established GCC.
Everything’s finalized. Office space. Legal entities.
But a line item says “AI team” somewhere in a steering committee deck.
You think, “I have built teams before, but how do I build an AI team that can deliver business value within the first year without creating unnecessary complexity?”
“How large does it have to be?”
“Who do I hire first?”
But none of these are the right questions to ask (immediately). There’s one that comes before that.
Prior art, 1865
“That depends a good deal on where you want to get to.”
The Cheshire Cat, on being asked which way one ought to go — Alice’s Adventures in Wonderland, Chapter 6
Question one of five. The Cat charged nothing for this consulting engagement.
Some context first:
Why Some AI Teams Don’t Succeed Inside New GCCs
Start with the numbers, because they’re worse than you’d guess. MIT looked at over 300 enterprise AI deployments and found only about 5% made any measurable difference to the bottom line.
S&P Global found that the average company drops 46% of its AI proofs of concept (PoCs) before they ever reach production.
The model is almost never the reason.
The reason:
Look at who owned those pilots. Some VP at HQ, usually. A steering committee. A quarterly review. On paper, everything had an owner.
But nobody owned the actual work.
The underwriter who opens forty documents every morning.
The claims queue.
The process the model was supposed to fit into.
The sponsor was three levels up and eight thousand miles away.
New GCCs inherit this on day one. HQ picks the projects. The center builds them.
And the person who actually knows the work (what would genuinely help and what would quietly break) isn’t in the room for either decision.
The centers that do well flip it around.
They get close to the work first.
Then they pick their own use cases, because they can see what HQ can’t: which processes AI would actually help and which ones just sound good in a deck.
Do that once, and HQ stops seeing a delivery office in India.
It starts seeing the place the good ideas come from.
So foundations go wonky in two places:
– Nobody owns the work.
– Or prove the thing works once it leaves the demo.
So, what do the best GCC AI teams have in common?
The pre-hiring gate
Before hiring anyone, answer these five questions.
Open each one to see what a real answer looks like. Mark the ones you can answer today — honestly, not aspirationally.
A real answer sounds like
“Claims triage takes our ops team 11 minutes per case; we want it under 3 with equal accuracy.” Named process, current cost, target number. “Improve efficiency with AI” is not an answer — it’s the absence of one wearing a suit.
A real answer sounds like
One name. A person with roadmap authority and the right to say no — sitting where the work happens, not two timezones away. If the answer is a committee, the answer is nobody. MIT’s autopsy of failed pilots found the missing piece wasn’t model quality; it was a single accountable owner steering the workflow end to end.
A real answer sounds like
Named systems, known owners, honest quality assessment. “The CRM, owned by sales ops, dirty but reachable” beats “we have lots of data.” And per Andrew Ng: dirty-but-reachable is enough to start. Waiting for perfect data means losing the feedback loop that tells you which data is worth fixing.
A real answer sounds like
The actual workflow, named: which screen, which step, whose day. The financial-services classic — a technically excellent document model that sat unused because nobody mapped it into the underwriter’s morning — is what happens when this question gets skipped. A model without a workflow is a demo.
A real answer sounds like
A business number, a baseline, and a date. Minutes saved per case, conversion lift, cost per resolution. “Number of models deployed” measures activity, not impact — and it’s the metric teams reach for when the real one was never defined. This question is also your evaluation team’s job description in disguise.
0 / 5 answered
Every unanswered question is a conversation to have before a hire to make. Recruiters can wait a week. Bad foundations can’t be un-hired.
7 Proven Lessons For GCC Leaders Building AI Teams
1. AI teams come in twos
Everyone hires the first team. AI engineers, a data lead, someone who can talk to the model companies.
The people who build the thing.
Almost nobody hires the second team. The people who prove the thing works.
Evaluation, monitoring, governance. The ones who catch the AI being confidently wrong before a customer does.
Google’s own CTO office, after a year of watching enterprise deployments, put it in nine words:
“every GenAI project rapidly becomes an evaluation project.”
That’s Google. Telling you that the hard part isn’t building. It’s checking.
And checking is real work, already done partly by machines. DoorDash runs a validation pipeline on its internal AI platform: it lints, checks queries against the actual warehouse, and flags suspicious results before anything ships.
A machine whose whole job is catching the other machine’s mistakes.
Now think about the pilot at your last company. The one that demoed well and went nowhere. It probably didn’t lack engineers. It lacked one person with the standing to say “the outputs are wrong” and be heard.
Melville wrote that team 175 years ago. One obsessed builder running the ship, a crew that can see the whale-sized problem, and nobody with the standing to turn it around.
The Pequod didn’t lack talent. It lacked a second team with veto power.
Prior art, 1851
“…all my means are sane, my motive and my object mad.”
Captain Ahab — Moby-Dick, Chapter 41
A delivery team with no evaluation function.
Patrick Lencioni’s old line holds up well here: “Not finance. Not strategy. Not technology.”
Teamwork wins, he argued, because it’s rare.
In 2026, anyone with a credit card gets a frontier AI model.
The two-team setup around it is the part nobody can copy.
The two-team structure
One team builds. One team proves it works.
Tap any role to see what it owns — and what quietly breaks when nobody holds it.
Delivery team — makes the thing
Reliability team — proves the thing
Pick a role
Most enterprises staff the left column fully and the right column not at all. That gap is why pilots don’t make it.
Google’s Office of the CTO, after a year of enterprise deployments: every GenAI project rapidly becomes an evaluation project.
Thinking of hiring for AI?
Hire AI engineers from India for AI teams in the US, UAE, and India through BEEU TECH
Built for enterprise hiring. Vetted AI engineers on remote basis from India, working in your timezone. A one-week paid trial comes first, you expand or scale down as the roadmap moves, and offboarding runs on 15 days notice.
- One-week paid trial
- Your timezone
- Transparent management
- 15 days notice to offboard
Deployment in as fast as 72 hours. Over six years placing tech talent with enterprise teams and GCCs.
2. AI-native means AI is part of the org chart
AI teams are now part human, part software.
The first big study of AI agents in production, 306 practitioners across 26 industries, found that 74% of deployed agents still answer to human review, and 68% get stopped after ten steps or fewer.
Does that mean:
“Agents replace teams”?
No. Humans still check everything.
“Agents are just demos”?
Also no.
These are in production, doing real jobs, kept on a short leash on purpose.
That’s what AI-native actually means.
AI systems with actual jobs: a scope, a supervisor, and a review when they get things wrong. Like any other hire.
| Traditional AI team | AI-native team | |
| Where AI sits | Supports selected projects | Embedded across workflows |
| How it operates | Separate function | Cross-functional |
| Division of labor | Humans lead, AI assists | Humans and AI hold distinct jobs |
| What gets measured | Model performance | Business outcomes |
The question changes too.
AI teams used to ask, “How can AI help us?”
AI-native teams ask, “Which jobs go to people, and which go to agents?”
Prior art, 1818
“You are my creator, but I am your master.”
The creature — Frankenstein, Chapter 20
An ungoverned agent renegotiating the org chart. Keep the leash short; Victor didn’t.
One honest caveat, because you’ve seen the headlines.
Klarna automated the work of 700 support agents, then brought humans back for the complicated, emotional cases, because the mix worked better than full automation.
They didn’t back out of agents. They resized the job.
That’s what it looks like when the evaluation team is allowed to change the answer.
Hiring AI Engineers For Your GCC? Compare the costs first.
Select your hiring region, choose your team size and compare the true cost of building an in-house engineering team against hiring remotely through BEEU TECH. Includes recruitment costs, employment overheads and projected annual savings.
3. Don’t wait for perfect data
The most common first move for a new GCC AI leader is also the most expensive one: “give me two years to clean the data, then we’ll do AI.”
Andrew Ng has heard this from enough CEOs to have a stock reply:
“That’s a mistake. Don’t do that.”
His logic is simple.
Nobody’s data is clean. Nobody’s.
And if you spend two years on pipelines before the AI team exists, you lose the only thing that tells you which pipelines are worth building: feedback from AI work actually running.
The team and the data teach each other.
Do them in sequence, and you learn nothing, twice. 🙂
One more Ng point, aimed at you specifically.
In his conversation with Bain on the agentic era, he was clear that the companies moving fastest are the ones where the top management engages directly instead of delegating down.
For a GCC, that cuts both ways.
You can’t hand this to an engineering manager and check in quarterly.
And HQ can’t hand it to you while keeping every decision in another timezone.
A center that needs permission to fix its own model doesn’t actually have a capability.
4. Hire people in sync with capabilities (in phases)
Every GCC needs these 5 essential capabilities. And every single hire must map to these:
| Capability | What it owns |
| AI product management | The roadmap, and the right to say no to use cases |
| Data engineering | Pipelines, and the feedback loop with the AI team |
| AI engineering | LLM and ML applications |
| Evaluation and MLOps | Proof it works, in production, repeatedly |
| Platform engineering | The infrastructure everything else stands on |
Hiring order, in phases rather than months, because months are a fiction the first candidate withdrawal will expose. The one-liners are the hiring bar.
Phase 1, the spine.
Four people who can take one use case from idea to something running.
- AI engineering lead. Owns architecture and technical judgment.
- Senior data engineer. Structures whatever data exists today.
- Platform engineer. Environments, compute, deployment paths.
- Product owner. Holds the roadmap and the right to say no.
Phase 2, the builders.
Capacity behind a proven spine.
- AI engineers, two or three. The LLM applications users actually touch.
- ML engineer. The models behind them, for where off-the-shelf stops being enough.
- Backend engineer. The critical plumbing between AI features and the systems they live in.
Phase 3, the proof layer.
Same quarter as Phase 2, not later.
- Evaluation engineer. QA, but think: quality thresholds, test sets, and the power to say the outputs are wrong before a customer does.
- MLOps engineer. Deployment automation, monitoring, drift.
- Governance, fractional to start. Risk tiers, human-in-the-loop checkpoints. Goes full-time once anything touches customers or regulators.
And in our experience, here are the roles you don’t need yet, even though every one of them shows up in someone’s template:
- a separate AI architect (that’s the lead)
- a prompt engineer (that’s a skill every AI engineer needs, not a seat)
- a DevOps hire (that’s your platform engineer)
- an analytics engineer (worth it at the expansion stage, not before)
Structure picker
Centralized, hub-and-spoke, or embedded?
Three questions. The answer follows from your situation, not from a preference.
1. How many AI use cases will run at once in year one?
2. Does AI touch anything regulated or customer-facing?
3. Has this org shipped an AI feature to production before?
The honest footnote: most enterprises land on hub-and-spoke by year two regardless of where they start. Centralized teams hit a scaling wall; embedded teams hit a duplication wall. The picker tells you where to start, not where you’ll end.
5. Your AI team doesn’t need more than 13 people in the first year
Thirteen people. Small enough to sit at two tables at lunch.
Large enough to ship AI features into existing products.
A working first-year snapshot for the CFO conversation:
| Role | Headcount |
| AI engineering lead | 1 |
| AI engineers | 4 |
| Data engineers | 3 |
| Platform engineers | 2 |
| MLOps engineer | 1 |
| Evaluation engineer | 1 |
| Product owner | 1 |
What stays with HQ in year one: legal, compliance, finance, the architecture board, security policy.
Copying all of that to India on day one burns money and gives you two versions of the truth.
What has to be local: the lead, the builders, the data engineers, evaluation, and delivery ownership. People who work together daily should share a room.
And the room should get to decide things without a 9 pm call.
One more thing about that room, because it decides whether your second team works at all.
Amy Edmondson’s research on psychological safety, the same work Google’s Project Aristotle later confirmed at scale, found that teams where people don’t feel safe raising problems don’t have fewer problems. They have quieter ones.
Here’s what that means for you: an evaluation engineer who’s junior to the people she’s checking will stop checking. She’ll start going along. That’s how the second team goes quiet. Not budget cuts. Politeness.
Reporting structure
Two org charts. Only one works in production.
Same thirteen people. The difference is who evaluation answers to.
6. Avoid looking at degrees
One note on judging candidates, because the usual signals won’t help you.
Half of these roles didn’t exist three years ago.
Nobody has a degree in LLM evaluation, and the certification bodies haven’t caught up either, so filtering on credentials filters for nothing.
The interview process that works: “show us.”
The eval set they built. The RAG pipeline that’s still running.
The agent they had to rein in.
What you’re listening for:
Evidence that someone has taken AI past the demo: LLMs, vector databases, model evaluation, agentic workflows, deployment.
Things they’ve done to something real that broke and something they had to fix.
7. Maturity beats headcount
The oldest habit in the GCC playbook is counting badges. Five hundred people, a thousand, five thousand. That’s how centers used to prove they mattered. That muscle memory built the industry. It will also quietly hold your AI work back, because AI doesn’t scale with headcount. It scales with maturity.
Microsoft’s MLOps maturity model is the clean reference. Translated for a first-year GCC:
| Stage | The goal | Minimum team | The expensive mistake |
| Inception | One working AI feature | AI lead + data + platform | Hiring twenty people first |
| Foundation | Reliable production | Add evaluation + MLOps | Skipping this row entirely |
| Expansion | Multiple products | Add governance + platform depth | Duplicating teams per product |
| AI-native | Agents and humans co-own workflows | Specialized squads | Measuring success in headcount |
If you want proof that small and mature beats big, the field you’re hiring for is the proof. Everything modern AI runs on came out of one 2017 paper written by eight people.
Google employed all eight. Google had every advantage that headcount can buy.
And a much smaller company turned that paper into the product that made everyone else react. The researchers were Goliath’s. The win was David’s.
Maturity check
Which stage is your AI capability actually at?
Check what’s true today. Not what’s on the roadmap — what’s true.
Inception
Where you are
Pre-production. The goal is one working AI feature, shipped by a spine of four: AI lead, data engineer, platform engineer, product owner.
The mistake to avoid next
Hiring twenty people before the first feature works. Headcount is not progress at this stage — a running feature is.
Reference: Microsoft’s MLOps maturity model, translated for a first-year GCC. Stages are sequential — skipping one doesn’t advance you, it just moves the problem downstream.
The last call: build it, buy it, or bring in help
Everything above assumes you’re building this team yourself.
Fair, since that’s the article you clicked.
But it’s worth being honest: building by yourself isn’t always the right answer, and the decision isn’t a preference.
It comes down to four questions.
Build, buy, or partner
Four questions before you sign anything.
Outsource everything and you’re renting capability. Build everything and you’re two years from shipping. The line sits somewhere in these four questions.
Q1 / 4
Is this AI capability core to how you’ll win — or supporting infrastructure?
Core means: it encodes institutional knowledge competitors can’t buy. A bank’s risk models are core. Its meeting summarizer is not.
Q2 / 4
Do you have AI leadership in-house today — someone who’s shipped to production?
Not someone enthusiastic. Someone with scar tissue.
Q3 / 4
Does the first production milestone need to land inside two quarters?
Be honest about what HQ’s patience actually looks like, not what the charter says.
Q4 / 4
Can you hire that leadership within a quarter in your market?
Senior AI leads with production experience are the scarcest role in the Indian market right now. A quarter is optimistic in most cities.
Build
Why
Core capability, leadership in place (or reachable), and enough runway that the team can learn by shipping. This is where the Ng logic pays off — the AI work and the data infrastructure teach each other, and all of that learning stays inside your walls.
Watch for
Build doesn’t mean build alone. Buy the commodity layers — models, vector stores, observability tooling. Building what you can rent is how the two-year infrastructure project starts.
Buy
Why
Supporting infrastructure doesn’t deserve your scarce engineering hours. Vendor tools for the meeting summarizers and ticket triage; save the team for what compounds.
Watch for
Even bought tools need the second team. Someone still has to evaluate whether the vendor’s outputs are right in your context. “We bought it” is not a quality strategy.
Partner — with a transfer clause
Why
Core capability but no leadership and no fast path to hiring it. A partner or embedded team gets you moving now, while your own hires ramp alongside.
Watch for
The Nadella trap lives here. If institutional knowledge accumulates in the partner’s heads instead of your systems, you’ve rented a capability, not built one. Contract for knowledge transfer, pair partner engineers with your hires, and set a date where ownership flips. Partnership is a bridge, not a destination.
Hybrid — build the core, augment for speed
Why
Core capability, real leadership, brutal timeline. Your lead owns architecture and evaluation standards; augmented engineers add the delivery capacity the deadline demands. Speed without surrendering the parts that compound.
Watch for
Keep evaluation in-house from day one. Augmented builders are fine; outsourced proof is not. The team that grades the work defines what your capability actually is.
Wherever the questions land you, one pattern holds. If it’s the reason you win, own it. If everyone buys the same thing from the same three vendors, so should you.
For what it’s worth, that’s the work we do at BEEU TECH: AI teams for GCCs, sometimes all thirteen seats, sometimes just the one evaluation engineer nobody can find. We know enterprise and GCC governance well enough to know where we’re useful — and where to stay out of the way.
Building the team to run this? See how BEEU TECH works with enterprises on AI staffing and deployment ⇗.
