Insights

When international companies decide to enter India, the first question they often ask is: "How do we set up a company here?" It is an understandable instinct. Incorporation feels like progress. It creates a legal presence, opens a bank account, and signals commitment. But for most companies, it is the wrong first question — and acting on it too early creates cost, complexity and distraction before the commercial case has been tested.

What Incorporation Actually Does

Incorporating in India — whether as a Private Limited Company, a Wholly Owned Subsidiary, a Branch Office or a Liaison Office — creates a legal entity. It does not create customers. It does not validate demand. It does not identify the right route to market. It does not tell you whether your product or service needs to be localised, repriced or repackaged for the Indian market.

Incorporation is a compliance and operational step. It is necessary at the right time. But it is not a commercial strategy, and treating it as one leads to a predictable set of problems: an entity that exists but has no revenue pipeline, a registered office with no customers, and a compliance calendar that generates cost before the business generates income.

The Sequence That Works

The companies that enter India most effectively tend to follow a different sequence. They start by validating demand — not through desk research alone, but through structured conversations with potential customers, channel partners and sector participants. They identify which segments are most likely to buy, what the buying process looks like, who the economic decision-maker is, and what objections or dependencies will need to be addressed.

They then design a route to market before committing to a legal structure. Cross-border selling, a distributor or reseller arrangement, a strategic channel partner, a first commercial hire through an Employer of Record, or a wholly owned subsidiary — each has different commercial, tax, legal and operational implications. The right choice depends on the product, the customer, the regulatory environment and the company's risk appetite. It cannot be determined by default.

Only once the commercial model is clear does the incorporation question become answerable. And in many cases, the answer is not "incorporate immediately." It may be "start with EOR and a local commercial hire," or "use a distributor for the first twelve months," or "run a cross-border pilot before committing to a local entity."

When Incorporation Is the Right First Step

There are situations where early incorporation makes sense. If the product or service requires a local entity for regulatory, contractual or customer-confidence reasons, incorporation may need to happen before commercial activity begins. If the company is entering India as part of a broader regional expansion with a clear business case already validated elsewhere, the incorporation timeline can be accelerated. If the company is setting up a delivery or engineering team rather than a sales operation, the entity may be needed from the outset.

But even in these cases, the incorporation decision should be driven by commercial and operational logic — not by the assumption that having a company in India is the same as having a business in India.

The Cost of Getting the Sequence Wrong

Companies that incorporate before validating the market face a specific set of challenges. They incur compliance costs — GST registration, TDS obligations, ROC filings, statutory audit, board meetings — before they have revenue to offset them. They create a governance structure that requires ongoing maintenance. They may find that the entity type they chose is not optimal for the commercial model they eventually adopt. And they often discover that the market opportunity looks different on the ground than it did from headquarters.

None of this is insurmountable. But it adds friction and cost to an already complex process. The companies that avoid it are the ones that treat market validation and commercial design as the first phase of India entry — and incorporation as a consequence of that work, not a precondition for it.

A Practical Starting Point

A structured India market entry assessment — covering demand validation, customer and segment prioritisation, route-to-market options, regulatory dependencies and a recommended entry sequence — typically takes four to eight weeks. It produces a clearer picture of the commercial opportunity, the right operating model, and the appropriate timing and structure for incorporation. It is a more productive use of the first phase of India entry than filing incorporation documents before the commercial case is understood.

This article is a practitioner perspective and does not constitute legal, tax or regulatory advice. Legal, tax and regulatory conclusions require review by appropriately qualified professionals.

One of the most consequential decisions in an India market entry is the route to market. The choice between selling cross-border, appointing a distributor, hiring locally through an Employer of Record, or incorporating a wholly owned subsidiary has significant implications for commercial control, tax exposure, compliance obligations, speed to market and long-term scalability. There is no universally correct answer — the right route depends on the product, the customer, the regulatory environment and the company's strategic intent.

Cross-Border Selling

Selling from outside India to Indian customers is possible for many products and services, particularly software, SaaS, digital services and certain professional services. Cross-border selling avoids the need for an Indian entity and the associated compliance obligations. It can be a useful way to test demand before committing to a local presence.

However, cross-border selling has limitations. It may not be available for all product categories — some sectors require local registration, licensing or a local entity for regulatory reasons. It can create challenges around invoicing, payment collection, GST applicability and customer confidence. And it does not provide the local presence that many Indian enterprise customers expect from a serious long-term partner.

Distributor or Reseller

Appointing an Indian distributor or reseller is a common first step for companies entering India with a physical product or a software solution that benefits from local sales and support. A good distributor brings existing customer relationships, market knowledge, local credibility and a sales infrastructure that would take years to build independently.

The risks are equally well-known. Distributor quality varies significantly. Conflicts of interest are common — a distributor that also represents competing products may not prioritise your offering. Commercial terms, pricing control and brand positioning can be difficult to maintain. And if the distributor relationship does not work, unwinding it and rebuilding a direct sales capability takes time.

Distributor selection requires structured screening — not just a warm introduction. The right distributor has relevant sector relationships, a track record with comparable products, a clear commercial model, and no conflicts that would undermine the partnership. The commercial agreement should address pricing floors, territory, exclusivity, performance milestones and exit provisions.

Strategic Channel Partner

A strategic channel partner is different from a distributor. Rather than simply reselling the product, a channel partner integrates it into a broader solution, adds services around it, or uses it to address a specific customer segment. This model can accelerate market penetration significantly — particularly in enterprise software, industrial technology and professional services — but it requires a partner with genuine complementary capability and a shared commercial interest.

Channel partnerships require more investment in partner enablement, joint go-to-market planning and governance than a standard distributor arrangement. They also require careful management of IP, data and customer relationships.

Local Sales Hire Through EOR

Hiring a local sales or business development professional through an Employer of Record is increasingly the preferred first step for companies that want a direct commercial presence in India without the time and cost of incorporation. An EOR allows the company to hire in India in two to four weeks, with full statutory compliance, without establishing a local entity.

This model works well for companies that want to test the market with a direct sales approach before committing to incorporation. The local hire can build pipeline, develop customer relationships, identify the right route to market and generate the commercial evidence needed to justify a larger India investment. When the company is ready to incorporate, the EOR-to-subsidiary transition is a structured pathway.

The limitation of the EOR model is that it does not provide a local legal entity for contracting, invoicing or regulatory purposes. For some products and customers, this matters. For others, it does not.

Wholly Owned Indian Subsidiary

A wholly owned Indian subsidiary — typically a Private Limited Company — provides full commercial and operational control. It can contract directly with Indian customers, invoice in Indian rupees, hold assets, employ staff and operate as a full legal entity in India. It is the right structure for companies with a validated commercial case and a plan to build a meaningful India presence.

The trade-off is time, cost and compliance. Incorporation takes six to ten weeks. The entity requires ongoing compliance — GST returns, TDS filings, ROC annual returns, statutory audit, board meetings, FEMA reporting. These are manageable with the right support, but they represent a real commitment that should be made with a clear commercial rationale.

Making the Decision

The right route to market is determined by a combination of factors: the product or service and its regulatory requirements, the target customer and their procurement preferences, the company's risk appetite and investment horizon, the availability of suitable partners, and the competitive landscape. In many cases, the answer is not a single route but a phased approach — starting with EOR or a distributor, validating the model, and then transitioning to a direct subsidiary as the business scales.

The decision should be made with qualified legal, tax and regulatory input. The commercial and operational implications of each route are significant, and the right structure for one company may be the wrong structure for another.

This article is a practitioner perspective and does not constitute legal, tax or regulatory advice. Legal, tax and regulatory conclusions require review by appropriately qualified professionals.

Finland has a growing track record of technology, industrial and clean-energy companies entering India. From industrial automation and energy technology to software, SaaS and engineering services, Finnish companies have found India to be a significant market opportunity and an increasingly important operating base. This article covers the practical steps for Finnish companies considering India entry — from market validation to entity setup, employment and compliance.

Why India for Finnish Companies

India is the world's most populous country and one of the fastest-growing major economies. For Finnish companies, India offers several distinct opportunities: a large and growing market for industrial technology, clean energy, software and professional services; a deep talent pool for engineering, AI, data and technology roles; and a cost-effective base for building delivery, engineering and operations teams.

Finnish companies in sectors such as industrial automation, energy technology, maritime, forest industry technology, software and SaaS have established India operations ranging from small commercial teams to scaled GCCs. The bilateral relationship between Finland and India is supported by a Double Taxation Avoidance Agreement (DTAA), which has implications for cross-border payments, royalties and service fees — though the specific application requires qualified tax advice.

Starting with Market Validation

The first step for most Finnish companies is market validation — understanding whether there is a credible commercial opportunity in India for their specific product or service. This is not the same as general market research. It requires structured conversations with potential customers, channel partners and sector participants in India to understand demand, buying behaviour, competitive dynamics and the specific adaptations that may be required.

Finnish companies often underestimate the degree of localisation required — not just in pricing and packaging, but in the sales approach, the support model, the contracting structure and the customer relationship. India is a relationship-driven market. Decision cycles are longer than in Finland. The economic buyer and the technical evaluator are often different people. Understanding these dynamics before committing to a commercial model saves significant time and cost.

Route to Market Options

Finnish companies entering India typically consider one of four initial routes: cross-border selling for digital and software products; a distributor or channel partner for products that benefit from local sales and support; a first commercial hire through an Employer of Record for companies that want a direct presence without immediate incorporation; or a wholly owned subsidiary for companies with a validated commercial case and a plan to build a meaningful India presence.

The EOR model is particularly useful for Finnish companies that want to test the market with a direct sales approach before committing to incorporation. It allows a local hire in two to four weeks, with full statutory compliance, without the time and cost of establishing a local entity. When the company is ready to incorporate, the transition is a structured pathway.

Entity Setup Considerations

When incorporation is the right step, Finnish companies typically establish a Private Limited Company (WOS — Wholly Owned Subsidiary) in India. The process involves obtaining Director Identification Numbers (DIN) and Digital Signature Certificates (DSC) for directors, reserving the company name through MCA21, filing the SPICe+ incorporation form, and obtaining the Certificate of Incorporation. Post-incorporation steps include PAN, TAN, GST registration, bank account opening, and FC-GPR filing with the Reserve Bank of India for FDI compliance.

The process typically takes six to ten weeks with proper preparation. Finnish companies should ensure they have a qualified Indian legal and tax advisor involved from the outset — the regulatory requirements for foreign-owned entities in India are specific and require professional guidance.

Employment and Compliance

Hiring in India requires compliance with Indian labour law, which is a complex and evolving framework. Employment contracts must comply with applicable state and central labour legislation. Statutory contributions — Provident Fund (PF), Employees' State Insurance (ESIC), Professional Tax — must be managed correctly. Payroll processing, payslip generation and statutory filing coordination require either an in-house HR function or a qualified payroll service provider.

Finnish companies should also be aware of the India-Finland DTAA implications for seconded employees, cross-border service fees and royalty payments. These require qualified tax advice and should be addressed before the commercial model is finalised.

Building an India Team

For Finnish companies that want to build a delivery, engineering or operations team in India — rather than just a commercial presence — the Nano GCC and Micro GCC models offer a structured pathway. A Nano GCC (1–20 people) allows a controlled India entry with a dedicated team, transparent governance and a clear route to ownership through a BOT transition. A Micro GCC (20–50 people) is appropriate for companies that have validated the model and want to scale.

India offers a deep talent pool for the functions most relevant to Finnish companies: engineering, software development, AI and data, industrial automation, energy technology and professional services. Hiring quality varies significantly by location, function and seniority — structured hiring processes, competitive compensation benchmarking and a clear employer value proposition are essential.

Practical Next Steps

For Finnish companies at the beginning of their India journey, the most productive first step is a structured market entry assessment — covering demand validation, route-to-market options, regulatory dependencies and a recommended entry sequence. This typically takes four to eight weeks and produces a clearer picture of the commercial opportunity, the right operating model, and the appropriate timing and structure for incorporation and team build-out.

This article is a practitioner perspective and does not constitute legal, tax or regulatory advice. Legal, tax and regulatory conclusions require review by appropriately qualified professionals. Bilateral framework details should be verified at the time of decision.

Most international companies approach India with one of two objectives: sell products or services in India, or build a delivery or engineering team in India. These are often treated as separate strategies, pursued by different parts of the organisation at different times. But the most effective India strategies combine both — and the two objectives reinforce each other in ways that are not always obvious at the outset.

Why the Two Objectives Are Complementary

A company that is selling in India and building a team in India has a structural advantage over one that is doing only one or the other. The commercial team generates market intelligence — customer feedback, competitive dynamics, pricing signals, product gaps — that directly informs the product and delivery team. The delivery team generates capability — engineering, AI, data, operations — that can be deployed to support the commercial operation, improve the product, and reduce the cost of serving Indian customers.

The integrated model also creates a more compelling story for Indian talent. Engineers and data scientists in India are increasingly selective about where they work. A company that is building a real India business — with local customers, a local commercial team and a growing delivery capability — is a more attractive employer than one that is simply offshoring work with no local market presence.

Designing the Integrated Model

The integrated model requires deliberate design. The commercial and capability build-out objectives need to be aligned — not just in strategy documents, but in the operating model, the governance structure, the hiring plan and the budget. The most common failure mode is treating the two objectives as separate workstreams with separate teams, separate budgets and separate accountability — which leads to duplication, misalignment and missed opportunities.

A well-designed integrated model typically has three components: a commercial team responsible for market development, customer acquisition and revenue generation; a delivery or engineering team responsible for product development, service delivery or operations; and a shared operating infrastructure — finance, compliance, HR, payroll, workplace — that supports both.

The Entry Sequence

The integrated model does not require both objectives to be pursued simultaneously from day one. The typical entry sequence starts with market validation — understanding the commercial opportunity and the right route to market. This may involve a first commercial hire through an EOR, a distributor or channel partner arrangement, or a cross-border pilot. In parallel, the company begins to assess the talent market, identify the right India location, and design the team structure for the delivery or engineering function.

Once the commercial model is validated and the first revenue is generated, the company can accelerate the team build-out — using the commercial traction as evidence of the India opportunity and as a recruiting tool for local talent. The entity structure — whether EOR, Nano GCC, Micro GCC or a fully incorporated subsidiary — can be designed to support both the commercial and the delivery function from the outset.

Operating Model Considerations

The integrated model requires a shared operating infrastructure that is designed for both commercial and delivery functions. This means a finance and compliance framework that can handle both customer invoicing and employee payroll; an HR function that can support both sales professionals and engineers; a workplace that can accommodate both customer-facing and delivery roles; and a governance structure that provides visibility across both functions to headquarters.

The Nano GCC and Micro GCC models are well-suited to the integrated approach. They provide a structured framework for building a dedicated India team — with transparent governance, a clear route to ownership and a BOT transition pathway — while remaining flexible enough to accommodate both commercial and delivery functions.

GenAI and Data in the Integrated Model

Companies that are building an integrated India model have an opportunity to embed GenAI and data-driven practices from the outset — rather than retrofitting them later. This means designing data flows between the commercial and delivery functions, using AI-assisted tools for market research, customer analysis and pipeline management, and building a data foundation that supports both commercial decision-making and operational improvement.

The integrated model is also a natural context for AI-enabled GCC development. A team that is supporting both commercial and delivery functions has a broader set of use cases for AI adoption — and a stronger business case for the investment in data infrastructure and governance that AI adoption requires.

This article is a practitioner perspective and does not constitute legal, tax or regulatory advice. Legal, tax and regulatory conclusions require review by appropriately qualified professionals.

Pricing for India is one of the most consistently underestimated challenges in international market entry. Companies that have successfully priced their products and services in Europe, North America or Southeast Asia often assume that India pricing is simply a matter of applying a discount to their global price list. It is not. India has a distinct pricing logic — shaped by purchasing power, competitive dynamics, customer expectations and the structure of the buying process — that requires deliberate design rather than adjustment.

The Discount Trap

The most common mistake is treating India pricing as a percentage reduction from global pricing. This approach fails for several reasons. First, the reference point is wrong — Indian customers do not evaluate your product against your global price; they evaluate it against local alternatives and their own budget constraints. Second, a discount from a global price that was never designed for India may still be too high for the target segment. Third, a blanket discount undermines the pricing architecture — it signals that the global price was arbitrary, and it creates expectations of further discounts in future negotiations.

Effective India pricing starts from the customer's perspective: what value does this product or service deliver, what are the alternatives, and what is the customer willing and able to pay? This is a different exercise from applying a discount, and it often produces a different answer.

Packaging and Tiering

India customers — particularly in the mid-market and SME segments — often prefer modular, tiered or usage-based pricing over comprehensive enterprise packages. A product that is sold as a single enterprise licence in Europe may need to be repackaged as a core module with optional add-ons, or as a usage-based subscription, to be commercially viable in India.

Tiering also allows the company to address multiple segments simultaneously — a starter tier for smaller customers, a professional tier for mid-market, and an enterprise tier for large organisations — without creating a single price point that is either too high for most customers or too low to reflect the value delivered to large ones.

Commercial Terms

Commercial terms in India differ from those in most Western markets. Payment terms are typically longer — 45 to 90 days is common in enterprise sales. Annual upfront payment is less common than in SaaS markets in the US or Europe. Purchase orders, vendor registration processes and procurement approvals add time to the sales cycle. Contracts are often subject to negotiation on terms that would be considered standard elsewhere.

Companies that do not adapt their commercial terms to the India market find that deals take longer to close, cash flow is harder to manage, and the sales cycle is longer than expected. Building India-specific commercial terms — including payment schedules, invoicing formats, GST compliance and contract structures — into the go-to-market plan from the outset reduces friction significantly.

Support Model and Service Delivery

Indian enterprise customers typically expect a higher level of local support than customers in markets where self-service and remote support are the norm. This includes local account management, local technical support, and in some cases on-site implementation or training. The cost of providing this support needs to be factored into the pricing model — and the pricing model needs to be designed to make the support model economically viable.

For software and SaaS companies, this often means building a local customer success function earlier than the revenue base would justify in other markets. The alternative — providing remote support from headquarters — is often insufficient for Indian enterprise customers and creates churn risk.

Contracting and Invoicing

Contracts with Indian customers need to comply with Indian law and address India-specific requirements — including GST invoicing, TDS deduction obligations, dispute resolution mechanisms and governing law. A contract designed for European or US customers will typically need to be adapted for India, and the adaptation requires qualified legal input.

GST compliance is a specific area of complexity. The applicable GST rate, the invoicing format, the place of supply rules and the input tax credit implications vary by product, service and customer type. Getting this wrong creates compliance risk for both the company and the customer.

The Localisation Checklist

Effective India localisation covers: pricing architecture designed from the customer's perspective; packaging and tiering appropriate for the target segments; commercial terms adapted to India buying behaviour; a support model that meets customer expectations; contracts and invoicing that comply with Indian law and GST requirements; and a local currency pricing strategy that manages foreign exchange risk. Each of these requires deliberate design — and most require qualified local input.

This article is a practitioner perspective and does not constitute legal, tax or regulatory advice. Legal, tax and regulatory conclusions require review by appropriately qualified professionals.

The expectation that India GCCs should be AI-enabled is now widespread. Global companies setting up or scaling India capability centres are increasingly asking not just "how do we build the team?" but "how do we build an AI-enabled team?" The question is legitimate. But the answer requires more precision than the question usually receives.

What AI-Enabled Actually Means

An AI-enabled GCC is not one that has deployed a large language model or purchased an AI platform licence. It is one where AI and data-driven practices are embedded in the operating model — in the workflows, the decision processes, the tooling and the governance — in ways that deliver measurable business value. This is a higher bar than it sounds, and most GCCs that describe themselves as AI-enabled are at an earlier stage of the journey than the label implies.

The distinction matters because it shapes the design of the GCC from the outset. A GCC that is designed to be AI-enabled — with the right data foundations, governance framework, tooling and talent — will reach that state faster and more reliably than one that tries to retrofit AI adoption onto an operating model that was not designed for it.

Use-Case Prioritisation

The starting point for an AI-enabled GCC is not technology selection — it is use-case prioritisation. Which processes and decisions in the GCC would benefit most from AI assistance? Where is the data available and of sufficient quality to support AI adoption? Where is the business value clearest and most measurable? Where is the risk of AI error lowest, or where are human-in-the-loop controls most easily implemented?

A structured use-case assessment — covering value, feasibility, data readiness and risk — produces a prioritised roadmap that is grounded in the specific context of the GCC rather than in generic AI hype. The highest-value use cases are typically in areas where the GCC handles large volumes of structured data, repetitive decision processes, or knowledge-intensive work that benefits from AI-assisted search and synthesis.

Data Foundations

AI adoption in a GCC context is constrained by data quality, data access and data governance. A GCC that does not have clean, accessible, well-governed data cannot deploy AI effectively — regardless of the quality of the AI tools available. Data foundation work — data quality assessment, data pipeline design, access control, lineage documentation and governance framework — is a prerequisite for meaningful AI adoption, not a parallel workstream.

This is one of the most common failure modes in GCC AI programmes: the AI tools are procured and the use cases are identified, but the data is not ready. The result is a programme that stalls at the pilot stage and fails to deliver the business value that was promised.

Governance Framework

An AI-enabled GCC requires a governance framework that addresses model risk, responsible AI, human oversight, data privacy, IP and licensing, vendor risk and incident management. This is not a compliance exercise — it is a risk management framework that enables the GCC to adopt AI confidently, with clear accountability and escalation paths.

The governance framework should be proportionate to the risk profile of the use cases being deployed. A GCC using AI for document summarisation and knowledge search has a different risk profile from one using AI for credit decisions or compliance monitoring. The governance framework should reflect this — not apply a uniform level of control to all use cases regardless of risk.

Human-in-the-Loop Workflows

Human-in-the-loop design is a critical component of an AI-enabled GCC operating model. For most GCC use cases, AI should augment human decision-making rather than replace it — particularly in the early stages of adoption, when model performance is being validated and trust is being built. Human-in-the-loop workflows define where AI outputs are reviewed before action is taken, who is responsible for the review, and what the escalation path is when the AI output is uncertain or incorrect.

Well-designed human-in-the-loop workflows also generate the feedback data needed to improve model performance over time — creating a virtuous cycle of adoption, learning and improvement.

Talent and Tooling

An AI-enabled GCC requires talent that can work effectively with AI tools — not just AI specialists, but the broader team. This means investing in AI literacy across the GCC, not just in a dedicated AI team. It also means selecting tooling that is appropriate for the use cases, the data environment and the governance requirements — and that can be adopted by the team without requiring specialist AI expertise for every use case.

Engineering teams in India GCCs are increasingly using AI-assisted development tools — Cursor, GitHub Copilot and similar platforms — to improve coding, testing and documentation productivity. The governance considerations for these tools are addressed in a separate article.

Measuring Adoption and Value

An AI-enabled GCC should have a clear framework for measuring AI adoption and the business value it delivers. This means defining KPIs for each use case — cycle time reduction, error rate improvement, knowledge access speed, decision quality — and tracking them consistently. It also means being honest about what is working and what is not, and adjusting the programme accordingly.

The most common mistake in GCC AI programmes is measuring activity — number of use cases deployed, number of users trained — rather than outcomes. Activity metrics are easy to generate and easy to report. Outcome metrics require more discipline but are the only reliable indicator of whether the AI programme is delivering value.

This article is a practitioner perspective and does not constitute legal, tax or regulatory advice. AI governance requirements may vary by jurisdiction and sector — qualified professional review is recommended.

AI-assisted development tools — Cursor, GitHub Copilot, and similar platforms — are now widely used in India engineering teams. They can improve coding speed, test generation, documentation quality and developer onboarding. But their adoption in a GCC or India engineering team context raises governance questions that many companies have not fully addressed. This article covers the key considerations.

Note: Cursor, GitHub Copilot and other tools mentioned in this article are third-party products. Inaac Advisors does not represent or endorse any of these tools. Tool selection and governance must be determined by the client based on their specific security, legal and operational requirements.

Source-Code Confidentiality

The most significant governance concern with AI-assisted development tools is source-code confidentiality. Most AI coding assistants work by sending code context — including the code being edited and surrounding files — to an external model for completion or suggestion. If the code is proprietary, confidential or subject to IP restrictions, this creates a risk that confidential code is transmitted to and processed by an external service.

Companies should review the data handling policies of any AI coding tool before deployment — specifically: what code is transmitted to the model, how it is stored, whether it is used for model training, and what access controls are in place. Enterprise versions of these tools typically offer stronger data handling commitments than consumer versions, but the specific terms vary and require review.

IP Ownership of AI-Generated Code

The IP ownership of AI-generated code is an evolving legal question. In most jurisdictions, code generated by an AI tool is not automatically owned by the company using the tool — the ownership depends on the terms of the tool licence, the jurisdiction, and the degree of human authorship involved. Companies should review the IP terms of any AI coding tool they deploy and ensure that the terms are consistent with their IP ownership requirements.

This is particularly relevant for GCCs and India engineering teams that are developing code for the parent company or for clients. The IP chain — from the AI tool to the India team to the parent company or client — needs to be clear and documented.

Licensing Compliance

AI coding tools that are trained on open-source code may generate suggestions that include code from open-source repositories. If the generated code includes code that is subject to a copyleft licence (such as GPL), incorporating it into proprietary software without compliance with the licence terms creates legal risk. Companies should have a process for reviewing AI-generated code for potential open-source licence compliance issues — particularly for code that will be incorporated into commercial products.

Access Control and Security Review

AI coding tools should be subject to the same access control and security review processes as other development tools. This includes: approval by the security team before deployment; configuration to limit the scope of code context transmitted to the model; integration with the company's identity and access management framework; and monitoring for unusual usage patterns.

In a GCC context, where the engineering team may be working on code for multiple clients or business units, access control is particularly important. The tool configuration should ensure that code from one client or business unit is not inadvertently included in the context transmitted when working on code for another.

Human Approval and Code Review

AI-generated code suggestions should be subject to human review before being committed to the codebase. This is not just a quality control measure — it is a governance requirement. The developer is responsible for the code they commit, regardless of whether it was generated by an AI tool. Code review processes should be designed to ensure that AI-generated code receives the same level of scrutiny as human-written code.

Companies should also establish clear policies on the use of AI coding tools in security-sensitive areas of the codebase — authentication, authorisation, cryptography, data handling — where AI-generated code errors can have significant consequences.

Establishing a Governance Framework

A practical governance framework for AI coding tools in an India engineering team covers: approved tools and versions; data handling and confidentiality requirements; IP and licensing review process; access control and security configuration; code review requirements for AI-generated code; and incident reporting for suspected IP or security issues. The framework should be documented, communicated to the team, and reviewed periodically as the tools and the regulatory environment evolve.

This article is a practitioner perspective and does not constitute legal advice. IP, licensing and data protection conclusions require review by appropriately qualified legal professionals. Tool-specific terms and capabilities change — verify current documentation before making deployment decisions.

GenAI adoption in India operations — GCCs, delivery teams, shared services centres — is moving faster than data readiness. Companies are deploying AI tools, identifying use cases and building AI teams before they have addressed the foundational data questions that determine whether those tools will actually work. The result is a predictable pattern: promising pilots that fail to scale, AI programmes that deliver less than expected, and frustration on both sides of the organisation.

This article covers the data readiness assessment that should precede any GenAI use-case deployment in an India team context.

Why Data Foundations Matter for GenAI

GenAI tools — large language models, retrieval-augmented generation systems, AI-assisted workflows — are only as good as the data they work with. A language model that is asked to summarise financial reports will produce poor output if the reports are inconsistently formatted, incompletely digitised or stored in systems that the model cannot access. A RAG system that is supposed to answer questions about company policies will fail if the policy documents are outdated, inconsistently named or not indexed correctly.

The data foundation problem is not primarily a technology problem. It is a data management problem — one that requires attention to data quality, data access, data governance, data lineage and data security before the AI layer is added.

Data Quality Assessment

Data quality assessment for GenAI readiness covers four dimensions: completeness (is the data that the AI needs actually present?), accuracy (is the data correct and up to date?), consistency (is the data formatted and structured consistently across sources?), and accessibility (can the AI system access the data in a form it can use?).

In most India GCC and operations contexts, data quality issues are concentrated in a few areas: unstructured documents that have not been digitised or indexed; structured data that exists in multiple systems with inconsistent formats; historical data that was captured for a different purpose and requires transformation; and data that is technically accessible but practically inaccessible because of access control, system integration or format issues.

Data Access and Integration

GenAI use cases in an India team context typically require access to data from multiple sources — ERP systems, document management systems, email and collaboration tools, HR systems, finance systems. Integrating these sources in a way that is secure, governed and maintainable is a significant engineering challenge that is often underestimated in AI programme planning.

Data access design should address: which systems contain the data needed for each use case; what integration approach is appropriate (API, database connection, file export, real-time streaming); what access controls are required; and how data freshness will be maintained. This work typically takes longer than expected and should be started before the AI use cases are deployed, not in parallel with them.

Data Governance

Data governance for GenAI readiness covers: data ownership (who is responsible for each data asset?), data classification (what sensitivity level applies to each data asset?), data retention (how long should data be retained, and when should it be deleted?), and data lineage (where did this data come from, and how has it been transformed?).

In a GCC context, data governance is particularly important because the India team is typically working with data that belongs to the parent company or to clients. The governance framework needs to be clear about what data can be used for AI training or fine-tuning, what data can be transmitted to external AI services, and what data must remain within the company's own infrastructure.

Data Security and Privacy

Data security and privacy requirements for GenAI use cases in India need to address both Indian data protection law (the Digital Personal Data Protection Act 2023 and its implementing rules) and any applicable foreign data protection requirements — GDPR for European companies, equivalent frameworks for US, Australian and other companies. The specific requirements depend on the nature of the data, the use case and the AI tools being used.

Key security considerations include: whether personal data is being processed by the AI system; whether the AI tool transmits data to external servers; what encryption and access controls are in place; and how data breaches or AI errors involving personal data will be detected and reported.

A Practical Data Readiness Assessment

A data readiness assessment for GenAI deployment typically covers: identification of the data assets required for each prioritised use case; assessment of data quality, access and governance for each asset; identification of gaps and the work required to close them; a data security and privacy review; and a prioritised data foundation roadmap that sequences the work required before each use case can be deployed.

This assessment is not a one-time exercise. Data quality, access and governance requirements evolve as the AI programme matures and new use cases are added. Building a data management capability — not just completing a one-time assessment — is the foundation of a sustainable AI-enabled India operation.

This article is a practitioner perspective and does not constitute legal advice. Data protection and privacy conclusions require review by appropriately qualified legal professionals. Regulatory requirements may change — verify current requirements before making decisions.

European companies with India GCCs, delivery teams or shared services centres face a dual governance challenge when deploying AI: obligations under the EU AI Act (which applies to EU-based companies and their operations) and requirements under India's Digital Personal Data Protection Act 2023 (DPDP Act). This article outlines the key considerations for companies designing AI governance frameworks that span both jurisdictions. It does not provide legal conclusions — those require qualified legal advice.

The EU AI Act: Key Principles for India Teams

The EU AI Act establishes a risk-based framework for AI systems used in the EU. It applies to providers and deployers of AI systems — including companies that deploy AI systems in their operations, even if those operations are located outside the EU. For European companies with India GCCs or delivery teams, this means that AI systems used by the India team to support EU-facing operations may be subject to EU AI Act requirements.

The Act categorises AI systems by risk level: unacceptable risk (prohibited), high risk (subject to conformity assessment and ongoing obligations), limited risk (transparency obligations), and minimal risk (no specific obligations). High-risk AI systems include those used in employment and HR management, access to essential services, and certain operational contexts. Companies should assess whether the AI systems used by their India teams fall into the high-risk category under the Act.

Key obligations for high-risk AI systems include: risk management systems, data governance requirements, technical documentation, transparency and information to users, human oversight, accuracy and robustness requirements, and registration in the EU AI database. These obligations apply to the deployer — the company using the AI system — not just the provider.

India's DPDP Act: Key Principles

India's Digital Personal Data Protection Act 2023 establishes a framework for the processing of digital personal data in India. It applies to the processing of personal data collected in India, and to the processing of personal data outside India if it is in connection with offering goods or services to individuals in India. For India GCCs and delivery teams, the DPDP Act is relevant to the processing of employee data, customer data and any other personal data handled by the India team.

Key DPDP Act requirements include: a lawful basis for processing personal data (consent or legitimate use); notice to data principals about the processing of their data; data principal rights (access, correction, erasure, grievance redressal); data fiduciary obligations (security safeguards, breach notification, data retention limits); and restrictions on cross-border data transfers. The implementing rules under the DPDP Act are still being finalised — companies should monitor developments and seek qualified legal advice on compliance requirements as they are clarified.

Designing a Dual-Jurisdiction AI Governance Framework

A governance framework that addresses both EU AI Act and DPDP Act requirements for an India team context should cover: AI system inventory and risk classification; data processing records and lawful basis documentation; human oversight and accountability structures; data subject/principal rights management; cross-border data transfer controls; security safeguards and breach response; and vendor and third-party AI tool assessment.

The governance framework should be designed at the enterprise level — not separately for the EU entity and the India entity — to ensure consistency and to avoid gaps at the jurisdictional boundary. This requires coordination between the legal, compliance, IT and operations functions in both locations.

Cross-Border Data Transfers

Cross-border data transfers between the EU and India are subject to both GDPR (from the EU side) and the DPDP Act (from the India side). GDPR requires an adequacy decision, standard contractual clauses or other appropriate safeguards for transfers to third countries. India has not yet received an EU adequacy decision. The DPDP Act includes provisions on cross-border data transfers, but the implementing rules — including the list of permitted and restricted countries — are still being finalised.

Companies should review their cross-border data transfer arrangements — including data flows between the EU parent and the India GCC — and ensure that appropriate safeguards are in place under both frameworks. This requires qualified legal advice and should be reviewed as the regulatory position evolves.

Practical Steps

For European companies with India teams, the practical steps for AI governance include: conducting an AI system inventory to identify systems used by the India team and their risk classification under the EU AI Act; reviewing data processing activities for DPDP Act compliance; assessing cross-border data transfer arrangements; establishing human oversight and accountability structures for AI use; and implementing a vendor assessment process for AI tools used by the India team.

These steps should be supported by qualified legal advice in both jurisdictions. The regulatory frameworks are evolving, and the specific requirements will become clearer as implementing rules and guidance are published.

This article is a practitioner perspective and does not constitute legal advice. EU AI Act and DPDP Act requirements are evolving — qualified legal advice in both jurisdictions is essential before making compliance decisions. Regulatory positions should be verified at the time of decision.

When international companies ask where to set up their India GCC or delivery team, the default answer is often Bengaluru. It is the largest technology talent market in India, home to the most established GCC ecosystem, and the location that most global companies know best. But Bengaluru is not always the right answer — and for many companies, it is not even the best answer. A structured, data-driven location selection process often points to a different conclusion.

Why Location Selection Matters

The location decision has long-term implications for talent availability, cost structure, operating risk and scalability. A GCC established in the wrong location — wrong for the function, the team size, the talent profile or the company's growth plan — will face structural challenges that are difficult and expensive to correct. Talent attrition is higher in locations where the supply of the required skills is thin relative to demand. Real estate costs are higher in locations where GCC density has driven up prices. Infrastructure quality varies significantly across India's cities and technology parks.

The location decision deserves the same analytical rigour as the entity structure decision or the operating model design. It should not be made by default or by following the crowd.

The Location Scorecard Framework

A structured location selection process uses a scorecard that evaluates candidate locations across multiple dimensions, weighted by the company's specific priorities. The dimensions typically include:

Talent availability: The depth and quality of the talent pool for the specific functions and skills required. This is not just about total headcount — it is about the availability of the specific skills, seniority levels and domain expertise that the GCC needs. Bengaluru has the largest overall technology talent pool, but for specific functions — automotive ER&D, industrial automation, maritime technology, certain AI specialisations — other cities may offer a deeper or more cost-effective pool.

Cost structure: Salary benchmarks, real estate costs, infrastructure costs and operating costs vary significantly across India's cities. Bengaluru and Mumbai are typically the most expensive. Hyderabad, Pune, Chennai and Delhi NCR are competitive alternatives. Tier-2 cities — Nagpur, Nashik, Coimbatore, Kochi, Indore — offer lower costs but smaller talent pools and less established GCC infrastructure.

Infrastructure quality: Technology park availability, office space quality, power reliability, connectivity and transport infrastructure vary by city and by specific location within the city. The quality of the technology park ecosystem — the availability of managed office space, coworking, and purpose-built GCC facilities — is a practical consideration for companies that are not ready to commit to a long-term lease from day one.

Government incentives: Several Indian states have GCC policies that offer incentives — stamp duty waivers, electricity duty exemptions, employment subsidies, single-window clearances — for GCC setup. Maharashtra, Telangana, Karnataka, Tamil Nadu and others have active GCC promotion programmes. The incentives vary by state, by team size and by investment threshold, and require verification from official sources at the time of decision.

Quality of life and talent retention: Quality of life factors — housing, schools, healthcare, commute times, cultural amenities — affect talent retention, particularly for senior professionals. Cities with a strong quality of life profile — Pune, Hyderabad, Bengaluru — tend to have lower attrition for senior roles than cities where quality of life is more constrained.

Operating risk: Operating risk factors include political stability, labour market conditions, natural disaster risk, infrastructure reliability and regulatory environment. These vary by city and by specific location within the city.

City Profiles

Bengaluru: Largest technology talent pool in India. Strongest AI/ML and software engineering ecosystem. Highest cost — both salary and real estate. High attrition in technology roles. Strong GCC infrastructure. Best for: large-scale technology GCCs, AI/ML teams, software engineering at scale.

Hyderabad: Strong technology talent pool, particularly in software, data and cloud. Lower cost than Bengaluru. Strong government support for GCC setup (Telangana GCC policy). Good infrastructure. Best for: technology GCCs, data and analytics teams, companies seeking a Bengaluru alternative.

Pune: Strong engineering and automotive ER&D talent. Lower cost than Bengaluru. Proximity to Mumbai. Strong manufacturing and industrial technology ecosystem. Good quality of life. Best for: engineering services, automotive ER&D, industrial technology, finance and operations GCCs.

Chennai: Strong manufacturing, automotive and engineering talent. Good infrastructure. Lower cost than Bengaluru. Strong Tamil Nadu government support. Best for: manufacturing, automotive, engineering services, finance and operations.

Delhi NCR (Gurugram, Noida): Large talent pool across functions. Strong financial services, consulting and enterprise technology ecosystem. Higher cost than Hyderabad or Pune. Best for: financial services GCCs, consulting and professional services, enterprise technology.

Tier-2 cities (Nagpur, Nashik, Coimbatore, Kochi, Indore): Lower cost, smaller talent pools, less established GCC infrastructure. Suitable for specific functions — back-office, finance, operations — where the talent requirement is less specialised and cost optimisation is a priority.

Making the Decision

The location decision should be made on the basis of a structured scorecard that reflects the company's specific priorities — not on the basis of where other companies have gone or where the company's existing contacts happen to be located. The scorecard should be weighted by the company's priorities, validated with on-the-ground market intelligence, and reviewed against the company's growth plan for the India team.

For Nano GCC and Micro GCC teams, the location decision is particularly important because the team is small enough that the talent pool in the chosen city needs to be deep enough to support the specific roles required — and shallow enough that the company can attract and retain talent without competing with the largest GCCs in the market.

This article is a practitioner perspective. Location data, incentive programmes and talent market conditions change — verify current information before making location decisions. Government incentive details require verification from official sources.