Building an MLOps and LLMOps team in India: roles, seniority mix and tooling
How to build an MLOps team in India: the roles in a first pod, the right seniority mix, tooling by layer, and sourced demand and pay data for 2026.
By Onfocus editorial team. Published . 9 min read.
An MLOps team in India usually starts as a pod of six to ten people: a lead who owns the platform design, two or three ML platform engineers, an LLMOps or evaluation engineer, a data engineer, and site reliability and security support. The seniority mix should lean experienced, because the scarcest skill in India's AI market is getting models into production and keeping them there, not building them.
The numbers point the same way. Quess, a staffing firm, estimates a 68% supply gap for MLOps and an 82.9% gap for GenAI deployment, and says GCCs account for 55% of MLOps demand (Quess via StartupFeed, Jun 2026). CIEL HR reports demand for MLOps engineers up 82.2% and for LLM engineers up 86.5% (CIEL HR via Outlook Business, Sep 2026). Both are vendor figures that measure demand, and the Quess report could not be checked against its primary document, so treat them as directional.
Why production skills are the bottleneck
Most enterprises in India have moved past the question of whether to use AI. EY's 2025 survey of India GCCs found 83% investing in GenAI and 58% in agentic AI, with GenAI pilots rising from 37% to 43% (EY, Nov 2025). Pilots become products only when someone can deploy, monitor, evaluate and roll back the models behind them. That is the MLOps job.
Employers say so directly. In a Nasscom and Indeed study, MLOps and deployment ranked among the top cross-industry AI skills, alongside cloud integration, GenAI and data analytics (Nasscom and Indeed via CXOToday, May 2026). Quess also reports that demand for applied data science and model operations roles in GCCs rose about 19% quarter on quarter in July to September 2026 (Quess via CXOToday, Nov 2026).
Quess summarizes India's AI market as weighted toward production work rather than model building (Quess via Free Press Journal, Jun 2026). For a buyer, that is useful: the people you need are platform and reliability engineers with ML literacy, a different profile from the research-heavy data scientist many job descriptions still ask for.
MLOps and LLMOps: what changes
MLOps grew up around models you train yourself. LLMOps covers systems built on large language models, which you mostly call, prompt, retrieve for and evaluate rather than train. The two share infrastructure and habits, but the daily work differs.
| Concern | Classical MLOps | LLMOps |
|---|---|---|
| What gets versioned | Training code, data snapshots, features, model artifacts | Prompts, system instructions, model and provider choice, retrieval settings, tool definitions |
| Testing before release | Offline metrics on a holdout set | Eval suites of graded examples, regression checks on prompts, red-team cases |
| Serving | Batch scoring or online endpoints you host | A gateway that routes to hosted or self-served models, with fallbacks and rate limits |
| Monitoring | Data drift, prediction drift, latency | Answer quality, groundedness, refusal and failure rates, token cost per request |
| Data pipelines | Feature pipelines and training sets | Document ingestion, chunking, embeddings and index refresh |
| Risk controls | Access to training data, model approval | Guardrails on inputs and outputs, human review queues, logs of agent actions |
For agentic systems the risk controls column grows. Kilpatrick Townsend notes that agentic AI needs defined autonomous actions, human approval points and logging (Kilpatrick Townsend, Jul 2026). Someone on the team has to own that in production, which is why we fold agent operations into LLMOps rather than leaving it with the application developers. Our post on agentic AI engineers in India covers the build side.
Roles in a first pod
The table below is a starting shape for an eight-person pod that serves several model-backed products. It reflects how we would staff the work, not a market benchmark.
| Role | Owns | Typical background | Count |
|---|---|---|---|
| MLOps or ML platform lead | Architecture, standards, release gates, roadmap | Platform or ML engineer who has run models in production | 1 |
| ML platform engineer | Training and deployment pipelines, model registry, serving, CI/CD | Backend or DevOps engineer with ML exposure | 2 |
| LLMOps and evaluation engineer | Eval harness, prompt and config versioning, model gateway, guardrails | Backend engineer who has shipped an LLM feature | 1 to 2 |
| Data engineer | Feature and retrieval pipelines, data quality, lineage | Data engineer with streaming or lakehouse experience | 1 |
| Site reliability or cloud platform engineer | Infrastructure as code, observability, on-call, cost | SRE or cloud engineer | 1 |
| AI security and governance | Threat models, access reviews, audit trails, privacy controls | Security engineer, often shared with another team at first | Shared |
| Graduate engineer | Runbooks, tests, dashboards, supervised changes | Graduate program hire | Added later |
Quess lists several reskilling paths that GCCs use to fill these seats from inside: data scientist to model operations, cloud engineer to platform engineer, and backend developer to applied AI engineer (Quess via Business Today, Jul 2026). If you already have backend or cloud engineers in India, the platform engineer seats are often the easiest to fill this way. The evaluation seat is the hardest, because few engineers have built eval suites against real business outcomes.
For the data engineer seat, the skills to test are set out in how to hire data engineers in India.
Seniority mix
GCC demand in India has shifted toward experience. Quess puts the 4 to 12 years band at 56% of GCC hiring demand (Quess via Business Today, Jul 2026), and TeamLease Digital reportedly found mid-to-senior talent rising from 60% of GCC hiring in 2023 to over 77% in FY26 (TeamLease Digital via TechRepublic, 2026).
For an MLOps pod we would go further toward seniority than for an application team. A reasonable mix for eight people is one lead with more than 12 years, three senior engineers, three mid-level engineers and one early-career engineer. The reasons are practical:
- The pod carries production on-call from the first release, and junior engineers should not be the first responder for a model serving customers.
- Many decisions are architectural and expensive to reverse, such as the choice of registry, gateway and evaluation approach.
- Early-career depth is uneven. Nasscom found about 70% of early-career tech talent "AI-proficient" but only about 23% "AI-native" (Nasscom via YourStory, Jul 2026).
Graduates fit well once runbooks, tests and dashboards exist, because that is where they learn the system safely. A graduate training program can then become a steady source of platform engineers.
Tooling, layer by layer
Choose tools your team can hire for and operate, and test candidates on concepts rather than brand names. The list below shows common open-source and managed options; your cloud provider and data platform will narrow it.
| Layer | What it needs to do | Common choices |
|---|---|---|
| Orchestration | Schedule and retry training, evaluation and batch jobs | Airflow, Dagster, Kubeflow Pipelines, managed cloud pipelines |
| Experiment tracking and registry | Record runs, promote approved models, keep lineage | MLflow, Weights and Biases, cloud model registries |
| Features | Serve consistent features for training and inference | Feast, the feature store in your data platform |
| Model serving | Host models with autoscaling and safe rollout | KServe, BentoML, vLLM for open-weight LLMs, managed endpoints |
| LLM gateway | Route requests across providers, apply limits, track cost | Open-source gateways or your cloud provider's gateway |
| Evaluation | Run graded test sets before every release | promptfoo, Ragas, or an in-house harness |
| Retrieval | Store and refresh embeddings and indexes | pgvector, OpenSearch, managed vector databases |
| Observability | Metrics, traces, logs, and LLM call tracing | Prometheus and Grafana, OpenTelemetry, Langfuse, Arize Phoenix |
| Infrastructure and delivery | Reproducible environments and gated releases | Terraform, GitHub Actions or GitLab CI |
Two choices deserve early attention. The evaluation harness should exist before the first LLM feature ships, because every later prompt or model change needs it as a regression test. And cost tracking per request should be on from day one, since token spend grows quietly with usage.
On-call, release gates and the weekly rhythm
An MLOps team is judged by what happens after release. Before the first launch, agree the following with product owners:
- Service level objectives for latency, error rate and data freshness, plus a minimum eval score for each LLM feature.
- A release gate: no model, prompt or retrieval change goes live without passing the eval suite and a rollback plan.
- An on-call rotation with runbooks for the failures you can predict, such as provider outages, index staleness and sudden cost spikes.
- A weekly review of quality, drift and cost, and a monthly review of which models and providers to keep.
Time zones work in your favor if you plan for them. An India team can run releases and evaluation jobs during its day and hand a clean state to US or European colleagues, provided ownership of each incident is unambiguous.
Security and governance seats
AI security and governance are the hardest seats to fill. In the DSCI skilling study, 78% of organizations reported high demand for AI security engineers, and AI and ML security specialists were the hardest domain to recruit for, cited by 57% of providers and 48% of enterprises (DSCI, May 2026). Quess estimates a 70 to 80% shortage of AI governance specialists and AI architects, or about two to three qualified candidates for every ten roles (Quess via Business Today, Jul 2026).
The privacy deadline adds pressure. India's DPDP Rules apply their core obligations from about 13 to 14 May 2027 (Storyboard18, Nov 2025). A shared security engineer with clear ownership of model access, audit logs and data handling is a sensible start; dedicate the seat once you run several production systems. See our DPDP guide for India GCCs and our approach to AI governance.
What the team costs
There is no reliable, primary-sourced salary band for MLOps engineers alone in India. The published figures that come closest are from staffing firms and should be read as indicative.
- GenAI engineers with 0 to 2 years of experience in GCCs earn a median fixed salary of ₹13.2 lakh a year, and AI architects with more than 15 years reach up to ₹108.6 lakh. AI, ML, cyber and cloud skills carry a 30 to 40% pay premium (TeamLease Digital via Telangana Today, Oct 2026).
- AI and ML engineers in GCCs ranged from ₹8.2 lakh at entry to ₹43 lakh at 8 or more years in TeamLease Digital's FY25 data (TeamLease Digital via YourStory, Oct 2025).
- Salaries in AI, MLOps and cloud grew at a three-year CAGR above 18% (TeamLease Digital via ThePrint, Aug 2025).
- Aon puts 2026 GCC increments at 9.3%, with AI, ML and data science premiums up about 10% on 2025 (Aon, Oct 2026).
For a fuller breakdown by role, see what AI and data engineers cost in India in 2026.
Building the pod yourself or through BOT
If you already run an Indian entity with a strong platform leader, hiring directly is straightforward. If not, the first year goes on setting up the entity, recruiting the lead and agreeing standards before any model ships. A Build-Operate-Transfer (BOT) arrangement lets a partner recruit and run the pod, then transfer the team and its platform to you. For an AI team, the contract should also say who owns models, eval suites and platform accounts; we cover that in Build-Operate-Transfer for an AI centre of excellence, and the general mechanics in how BOT works for GCCs in India.
How Onfocus can help
Onfocus designs and builds MLOps and generative AI systems, and recruits and runs engineering teams for clients in fintech, banking and Web3. Our AI pilot program ends in a working MVP and a prioritized roadmap, which gives a new pod a concrete first system to operate. If you are planning an MLOps team in India, talk to us about building it.
Frequently asked questions
- What roles does an MLOps team in India need?
- A first pod of six to ten people usually has a platform lead, ML platform engineers, an LLMOps and evaluation engineer, a data engineer and site reliability support, with security shared at first. Graduate engineers join once runbooks, tests and dashboards exist.
- How is LLMOps different from MLOps?
- Classical MLOps centers on training pipelines, feature stores, model registries and drift monitoring. LLMOps versions prompts, model choices and retrieval settings, gates releases on eval suites, and monitors answer quality and token cost per request.
- What seniority mix works for an MLOps pod?
- Lean experienced. For eight people, a reasonable mix is one lead with more than 12 years, three senior engineers, three mid-level engineers and one early-career engineer, because the pod carries production on-call from the first release.
- Why is MLOps talent hard to find in India?
- Staffing firm Quess estimates a 68% supply gap for MLOps and says GCCs account for 55% of MLOps demand. Most AI demand in India is for production and deployment skills rather than model building.
- Which tools should an MLOps team set up first?
- Choose tools your team can hire for and operate, covering orchestration, a model registry, serving, evaluation and observability. Build the evaluation harness before the first LLM feature ships, and track cost per request from day one.