Build-Operate-Transfer for an AI centre of excellence in India: what transfers, and when
Build-Operate-Transfer for an AI CoE in India: which AI assets transfer, when they should vest, IP clauses, eval-based handover tests and DPDP points.
By Onfocus editorial team. Published . 9 min read.
In a Build-Operate-Transfer (BOT) arrangement for an AI centre of excellence (CoE) in India, more transfers than the entity, people and leases of an ordinary GCC. The AI assets the team creates also have to move: trained and fine-tuned models, prompts, datasets, eval suites, pipelines, and the cloud and model-provider accounts they run on. Kilpatrick Townsend notes that these assets need explicit IP assignment and that BOT transfer terms should be fixed at the outset (Kilpatrick Townsend, Jul 2026).
When things transfer matters as much as what. The safest pattern is for AI work product to belong to the client as it is created during the operate phase, for accounts and contracts to sit in the client's name or be assignable from day one, and for the formal transfer to move the entity and employees once the CoE passes agreed readiness tests. Leaving AI assets to be sorted out at the end is how valuation disputes start.
Why an AI CoE needs its own BOT terms
AI CoEs are now common inside India's GCCs. According to an Analytics India Magazine write-up of the Nasscom and Zinnov 2026 GCC report, over 1,200 GCCs have AI and ML capabilities and over 250 have dedicated AI and ML CoEs, while only 13% influence enterprise AI strategy beyond execution (Analytics India Magazine, May 2026). These figures have not been checked against the full report.
Providers have noticed. Infosys offers BOT among the options in its AI-first GCC model (Business Standard, Nov 2025), and IBM Consulting and Quintes Global have announced structured BOT and "Build-Operate-Transform-Transfer" offerings for India GCCs (IBM India, Jun 2026).
The legal point is the one buyers tend to miss. Kilpatrick Townsend frames the GCC as the structure and the AI CoE as its mandate (Kilpatrick Townsend, Jul 2026). A standard BOT contract handles the structure well: entity, shares, employees, leases. It often says little about the mandate's output. In a conventional engineering centre most of the value sits in people and code. In an AI CoE a large share sits in artifacts that are easy to copy and hard to value, such as a fine-tuned model, a labeled dataset, or an eval suite that encodes years of domain judgment. Many of those artifacts also depend on third-party licences and accounts that may not be assignable.
What transfers: an inventory
The table below is how we would list the assets in an AI CoE run through a provider-owned Indian entity. It is a planning aid, not a legal template.
| Asset | Owner during operate | How it moves at transfer | Watch for |
|---|---|---|---|
| Entity and shares | Provider, with a call option for the client | Share purchase | FEMA reporting and fair-value pricing |
| Employees | Provider's entity as employer | Continue automatically in a share purchase, because the employer does not change; a business transfer raises transfer-of-undertaking questions | Gratuity continuity, notice and consent questions |
| Source code, pipelines, infrastructure as code | Client, assigned as created | Already in client-controlled repositories | Provider tools embedded without a licence |
| Trained models, fine-tuned weights, adapters | Client, assigned as created | Already in a client-owned registry or storage | Weights stored only in provider accounts |
| Prompts, system instructions, agent workflows, tool definitions | Client, assigned as created | Versioned in client repositories | Undocumented changes made in consoles |
| Training and fine-tuning datasets, labels | Client, subject to the rights in the source data | Stays in client storage; provider deletes its copies | Data used under consents or licences that do not cover the client's later use |
| Eval suites and graded test sets | Client, assigned as created | Versioned with the models they test | Suites built inside a provider's proprietary tooling |
| Cloud, data platform and model-provider accounts | Client-named, or provider-named and assignable | Assignment or novation | Committed spend, credits or rate limits tied to the provider |
| Third-party licences, including model licences | Client where possible | Novation | Licence terms that prohibit assignment |
| Office lease | Provider or client | Assignment | The lease must be assignable |
| Provider's pre-existing tools and accelerators | Provider | Licence to the client | Scope and duration of that licence |
Morgan Lewis makes the lease and gratuity points for GCC transfers generally: if the customer will take over the facility the lease must be assignable, and gratuity alignment should be planned in the design phase (Morgan Lewis, Mar 2025). The share purchase versus business transfer choice is covered in the BOT transfer: share purchase vs slump sale, and the employment side in moving employees at transfer under India's new labour codes.
When things transfer: a timeline
Durations below are vendor claims and indicative only. Providers commonly cite 8 to 16 weeks to first hires, and an operate phase of 18 to 36 months or two to three years (eCorpIT, Aug 2026; Wisemonk, Oct 2026).
| Phase | What should happen to AI assets |
|---|---|
| Design and build | Sign the IP assignment and background-IP licence. Create client-owned repositories, registries and cloud accounts, or make provider accounts assignable. Agree data access approvals and privacy roles. |
| Early operate | Assets vest in the client as they are created. Keep an asset register covering models, datasets, prompts, eval suites, accounts and licences, and review it every quarter. |
| Mid-operate | Start knowledge transfer and handover planning. Wisemonk advises that transfer preparation should begin mid-operate (Wisemonk, Oct 2026). Move any remaining provider-named accounts. |
| Pre-transfer readiness | Run the readiness tests described below, audit the asset register against reality, and confirm deletion plans for provider copies of data. |
| Transfer | Follow the usual sequence: share transfer or equity issuance, then contract assignment, then IP migration, then employee onboarding under the parent's governance (IMC via Legal 500, May 2026). |
| Transitional services | The provider supports specific services for a fixed period, then certifies deletion of client data and models it no longer needs. |
If IP vests in the client throughout, the IP migration step at transfer becomes a check rather than a negotiation. That is the outcome to aim for.
IP clauses to agree at signing
Kilpatrick Townsend lists models, fine-tunes, prompts, datasets, evals and workflows as AI assets that need explicit IP assignment, and says price, employee and contract transfer and transition support should be fixed at the outset (Kilpatrick Townsend, Jul 2026). In practice, we would expect the contract to cover:
- A present assignment of all AI work product, defined to include model weights, adapters, prompts, datasets, labels, eval suites, agent workflows and their documentation.
- A carve-out for the provider's pre-existing tools, with a perpetual licence for anything embedded in the deliverables.
- A register of every third-party model, dataset and software licence used, with a note on whether each can be assigned.
- Limits on the provider reusing client data, or models derived from it, for other clients.
- Client administrator access to every repository, registry and cloud account from day one.
- The transfer price formula, agreed at signing.
- Return and deletion obligations for the transitional period and after it.
On price, Morgan Lewis describes common BOT structures: fixed fees for design and build, FTE-based pricing during operate, and employee transfer or facility usage fees at transfer (Morgan Lewis, Mar 2025). For an AI CoE, state whether models and datasets are included in the transfer price or have already been paid for through operate fees. If that is left open, both sides will value the same model differently at the end.
Eval suites as the handover test
An eval suite is a set of graded examples that shows whether a model or an LLM system still does its job. In an AI CoE it doubles as the most objective handover test available. We suggest writing readiness criteria like these into the contract:
- The client's own staff can rebuild a production model from versioned code and data and reproduce its eval scores within an agreed tolerance.
- Every production LLM feature passes its eval suite when run by client staff, without provider help.
- Runbooks exist for the predictable failures, and the client's on-call team has handled real incidents during operate.
- The asset register matches what actually sits in the client's accounts.
These tests also address dependency lock-in, which IMC lists among the main BOT risks alongside compliance divergence and valuation disputes (IMC via Legal 500, May 2026). An AI team that only the provider's engineers can retrain has not really been transferred.
DPDP and data access across the BOT
The Consent Manager rule under India's DPDP Rules applies from about 13 to 14 November 2026, and the core obligations, including notice, consent, security safeguards, breach notification and retention, apply from about 13 to 14 May 2027 (Storyboard18, Nov 2025). As of November 2026, a BOT signed now will almost certainly still be in operate when the core obligations start.
In our analysis, a GCC is usually a processor for the parent's customer data and a fiduciary for its own employee data. AI work can blur that line. A CoE that decides which customer records to use for training, or builds a model for its own initiative, may be doing more than processing on instructions. Have counsel review each training data flow, and write a role schedule for each phase into the BOT contract. Monitoring of third-party data access is already rising: EY found it grew from 44% to 60% of India GCCs (EY, Nov 2025). Our DPDP guide for India GCCs covers the phase-by-phase roles in more detail.
Agentic systems need written limits
EY's survey found 58% of India GCCs investing in agentic AI (EY, Nov 2025). Kilpatrick Townsend says agentic AI requires defined autonomous actions, human approval points and logging (Kilpatrick Townsend, Jul 2026). In a BOT, add three things to the contract: a register of the actions each agent may take, a rule on who can approve changes to that register during operate, and a requirement that action logs stay in client-controlled storage and move with the system. The build side of this work is covered in agentic AI engineers in India.
Commercial and tax points
AI does not change the basic tax structure of a BOT, but a few points deserve attention early.
- The provider's capital gains on transfer should be priced into the BOT fee from the start (Bar and Bench, Jun 2026).
- A transfer of a going concern is likely exempt from GST (Bar and Bench, Jun 2026).
- A BOT partner that negotiates or concludes contracts for the investor can create permanent establishment risk (Sagus Legal via Legal 500, Oct 2026).
- If the group controls the provider too closely, the arrangement may be recharacterized for transfer pricing, so the provider's independence should be maintained and documented (Bar and Bench, Jun 2026).
For the full mechanics, see how BOT works for GCCs in India and the Onfocus Build-Operate-Transfer page.
How Onfocus can help
Onfocus designs and builds data engineering, machine learning, generative and agentic AI, and MLOps systems (see our AI and data work), 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 CoE its first production system and a clear asset register from the start. If you are planning an AI CoE in India, talk to us about a Build-Operate-Transfer plan.
This article is general information, not legal or tax advice. Confirm the details for your situation with Indian counsel and a chartered accountant.
Frequently asked questions
- What transfers in a Build-Operate-Transfer for an AI centre of excellence?
- Besides the entity, employees, contracts and lease, the AI assets transfer: trained and fine-tuned models, prompts, datasets, eval suites, pipelines, and cloud and model-provider accounts. Each of these needs explicit IP assignment in the contract.
- When should AI IP pass to the client in a BOT?
- Ideally as it is created during the operate phase, through a present assignment in the contract and client-owned repositories and accounts from day one. The formal transfer then moves the entity and people once the CoE passes agreed readiness tests.
- How do you know an AI CoE is ready for transfer?
- Use readiness tests written into the contract: client staff can rebuild a production model and reproduce its eval scores, LLM features pass their eval suites without provider help, and the asset register matches what sits in the client's accounts.
- How does the DPDP Act affect an AI CoE run under BOT?
- The core DPDP obligations apply from about May 2027, so a BOT signed now will almost certainly still be in operate then. The contract should set fiduciary and processor roles for each phase, and counsel should review training data flows.
- What should a BOT contract say about agentic AI systems?
- It should include a register of the actions each agent may take, a rule on who approves changes to that register during operate, and a requirement that action logs stay in client-controlled storage and move with the system.
