When can an Indian GCC rely on parent's AI controls

Consider a hypothetical rollout at an Indian global capability centre (GCC). The parent company wants a shared AI agent to access and fetch local customer records, assess service requests and update a case-management system. The parent company manages the IT platform and has commissioned an independent audit from a third party. The India GCC team must determine whether this arrangement is acceptable.

My baseline condition is that the parent controls and policies should be implemented as a default if they meet the requirements applicable to the Indian operation and relevant assurance supports their effectiveness. Rebuilding the same controls locally needs a specific justification and precise rationale. Separate approval processes, duplicate resources, overlapping tests and competing control owners can consume time and resources without addressing any additional risk.

Start with the applicable requirement

In the hypothetical case, suppose the legal assessment establishes that a specific category or type of customer records must be stored locally in India and that the proposed cross-border copy to the parent company’s cloud is prohibited. Strong encryption, restricted access and a favourable security audit do not resolve the localisation requirements.

The above assumption may not be applicable to every Indian citizen’s data or all cross-border data flows. The Reserve Bank of India’s payment-data FAQs, for example, permits overseas processing of payment transactions, provided that data is brought back to India and deleted from foreign systems within one business day or 24 hours of processing, whichever is earlier. They also specify separate storage provisions and controls for data related to cross-border transactions. Understanding the exact scope and its exceptions is vital before choosing a quick fix.

Management should therefore establish the requirement before choosing the remedy. For an AI service, that means reviewing where covered information appears throughout the workflow of the service, including any prompts, retrieved records, outputs, logs and backups that contain it. A localised datastore in India for a global application does not resolve the issue if a restricted copy of the data is quietly retained overseas in any form either online or an offline backup.

The countermeasures might require rearchitecting the data paths, storage setup, retention, lifecycle policies and system rules. Where a compensating control is proposed, management must establish that the applicable requirements allow it and that it meets the requirements. Calling a measure compensating does not establish either point.

A robust risk framework provides the blueprint for triaging and scaling the right remediation. Governance assigns responsibility, resources and escalation paths. Governance controls may fulfil compliance requirements regarding managerial oversight, tracking and accountability.

However, management must not mistake formal oversight or signoffs for operational compliance. When a regulation mandates a specific technical outcome such as data localisation, a board approval does not fulfil the regulatory obligation if the data continues to flow overseas.

Aligning third-party assurance with operational realities and deployment context

Once the arrangement is compatible with the local requirements, existing third-party audit & assurance functions can help validate the decision to rely on parent controls. The useful question is what the auditor examined and how it relates to the GCC’s specific operational environment and service architecture deployed by the local entity. One must look closely at the scope, criteria, testing timelines, and exceptions, alongside the specific compliance burdens retained by the local team.

An independent review of the parent infrastructure and the global framework may provide useful evidence about shared identity management or infrastructure security. Management should establish separately whether it covers the relevant Indian system configuration, architecture, data handling and AI permissions. If the global audit report provides sufficient coverage, and findings prove compliance, it should be adopted immediately; if material gaps remain or reveal any blind spots, the local team should do a targeted review.

Consider a hypothetical scenario where the case summarising AI agent is upgraded to an active agent capable of altering customer databases. The original third party report may not cover the new additional permissions or affect data integrity. The GCC team must assess the gap, verify the specific controls and get sufficient evidences covering this expanded privilege footprint. Rather than commissioning another round of full scale system audit, the team should conduct a targeted delta review for isolating the new functionalities while using the audit evidence already verified by the parent company.

NIST’s discussion of agent identity and authorisation supports this focus on delegated permissions and existing identity foundations. The practical implication for a GCC is to examine the authorisation granted to the AI agent. Don’t assume the risk is the same just because the AI agent name hasn’t changed.

Independent audits can also help establish whether local requirements have been met when those requirements are included in their scope. Indian GCCs need evidences to check for two distinct boxes: compliance with the local regulations and effectiveness of the parent’s controls. Ultimately, any audit report is only useful if it answers the specific question you are asking.

Keep local tailoring precise and target-driven

A local requirement does not automatically justify a separate control framework. Suppose the parent can retain ownership of the common AI platform while configuring the Indian workflow so that the prohibited data copy is no longer created. If the changed arrangement meets the requirement and is verified, there may be no reason to duplicate the remaining controls.

Any request for local customisation must outline the unmet requirement, the affected activity, the change needed and who will verify it. The parent should provide a practically doable route to implement that change. This gives both teams a clear way to decide whether an exception is necessary and whether the proposed remedy or countermeasure is proportionate.

In the same hypothetical scenario, an interim option could be to keep the affected data records out of the AI agent’s scope and handle those cases through an alternative compliant existing process. That alternative option needs its own assessment, including if keeping the data separate is practically possible and the extra operational workload it creates. This interim step shouldn’t become a convenient loophole to keep using a noncompliant system.

For the board overseeing the Indian entity, management should make the paths forward and key trade-offs clear: the scope that can proceed, the restrictions needed and the impact to the business. Technical teams will implement and validate if the fix works. Directors can challenge the decision to rely on global infrastructure, question the reasons for trusting global controls and if unresolved matters have received the necessary attention.

Choose intentionally, not as a default

There are clear practical advantages to accepting parent controls if local compliance rules are satisfied and the existing audit evidence applies to the Indian operation. There are equally strong cases for stepping in with a local fix where a local obligation remains unmet. If no compliant arrangement or countermeasure is available for an activity, the recommendation is to restrict that activity rather than assume group approval resolves it.

Meeting the legal rules is only the first step; commercial decisions remain, including whether the AI agent produces satisfactory business outcomes, real operational value and whether its residual operational risks are tolerable. Never assume that a compliant system is automatically an effective one. NIST’s voluntary AI Risk Management Framework separately addresses legal requirements, business workflows, real world operating environments and assessment of control effectiveness.

The logic behind using parent controls should be reviewed again when any material changes affect it, such as a new data path, wider AI agent permissions or a different supplier. Existing audit assurance can be used where it’s relevant and applicable for the parts that have not changed. The reassessment should focus on the changes, their dependencies and target the new risk profile without reopening a full audit.

Ultimately, the board only needs to ask one specific question: does this parent company’s global platform and arrangement meet our applicable requirements, and what evidence or documentation supports that claim for our operation? A satisfactory answer should allow the Indian business to use the group's capabilities confidently, leave room for necessary local changes and spend its compliance resources and audit budget on compliance gaps or unresolved risks that need closing.

(The author is Founder and CTO, Move78 International and EU AI Compass, and works across cybersecurity, cloud risk, technology risk and AI governance. Views are personal.)