GCC Build & Run: Why Governance Wired at Phase 2 Prevents a Phase 4 Crisis

Why GCC Setup in Indian BFSI Keeps Failing at the Same Stage

The decision to stand up a Global Capability Centre for AI and data engineering is, in the Indian BFSI context, as much a regulatory decision as an operational one. A Head of Technology Risk at a mid-size private bank or NBFC owns both sides of that equation: the delivery velocity the business demands and the outsourcing compliance obligations the Reserve Bank of India enforces. When GCC engagements fail — and a meaningful proportion do fail to deliver sustained value — the failure almost always surfaces in the Run stage. But it was caused much earlier, in the Build phase, when governance was treated as a post-go-live concern rather than a contractual requirement.

This article walks through the four named phases of a GCC Build & Run engagement — Scoping, Build, Transition, Run — with a governance checkpoint for each phase, and a practical frame for connecting AI assurance obligations to the phase where they can still be controlled.

Phase 1: Scoping — Define the Regulatory Perimeter Before the Commercial Structure

Scoping is where most enterprises underinvest. The commercial negotiation — headcount, location, SLA structure, pricing model — moves faster than the compliance scoping, and the compliance gaps get deferred to a legal review that happens after term sheets are signed. For BFSI entities regulated under RBI's 2023 outsourcing master directions, that sequencing is dangerous.

RBI's outsourcing guidelines require the regulated entity to maintain comprehensive oversight of all outsourced functions, retain the right to audit, and ensure that outsourced arrangements do not impede supervisory access. These obligations apply regardless of whether the GCC is a captive entity or a third-party-managed centre. They cannot be waived in a vendor contract. Scoping must therefore begin with a regulatory perimeter document that identifies which AI and data functions are in scope, which data sets will cross the perimeter, and which RBI and DPDP Act obligations attach to each.

Governance checkpoint for Phase 1: The risk committee should require a signed regulatory perimeter document before commercial terms are finalised. That document must map every AI function in scope to its applicable regulatory obligation — RBI outsourcing directions, DPDP Act data localisation and consent requirements, SEBI algorithmic trading circulars where relevant. No perimeter document, no board sign-off.

Qapitol AI assurance touchpoint: At the Scoping phase, an independent assurance partner should validate that the perimeter document is complete and that the proposed contractual structure does not create supervisory blind spots. This is a pre-build obligation, not a post-deployment audit.

Phase 2: Build — Wire Assurance In or Pay to Retrofit It Later

The Build phase is where GCC engagements are won or lost in regulatory terms, even though the audit exposure does not become visible until Phase 4. The core mistake is treating AI model governance — monitoring thresholds, bias evaluation frameworks, explainability requirements, audit trail architecture — as a future-state concern to be addressed once models are in production. Under RBI's model risk guidance and the DPDP Act's accountability principles, the obligation runs from the point of deployment, not from the point of first audit.

A vendor that cannot produce, in Phase 2, a written assurance plan covering model monitoring cadence, bias testing methodology, drift detection thresholds, and audit trail retention meets only part of the delivery requirement. The other part — the part that protects the regulated entity at examination — is assurance architecture. If that architecture is not specified in the Build phase contract as a deliverable with acceptance criteria, it will not exist at go-live in a form that satisfies a regulator.

Governance checkpoint for Phase 2: The risk committee should require that the Build phase statement of work includes, as named deliverables: a model risk framework aligned to RBI guidance, a bias and fairness testing protocol, an audit trail specification with retention periods and access controls, and a data processing agreement addressing DPDP Act obligations. These are not nice-to-have annexures. They are the difference between a GCC that passes regulatory scrutiny and one that triggers a remediation directive.

Qapitol AI assurance touchpoint: Phase 2 is where independent red-teaming of model behaviour, synthetic test data generation for edge cases, and assurance of the audit trail architecture should be contracted. An assurance partner brought in at Phase 4 cannot reconstruct the evidentiary record that should have been created during Build.

Phase 3: Transition — Compliance Continuity Across the Handover

Transition is the phase that receives the least attention in GCC governance frameworks and generates the most audit exposure in practice. The handover from the implementation team to the steady-state operations team — whether internal or vendor-managed — creates a window where governance controls that existed on paper in Phase 2 are not yet embedded in operational practice. Model monitoring dashboards exist but are not yet reviewed by anyone with authority to act. Audit trails are being generated but are not yet mapped to the escalation paths the regulator expects.

For a BFSI entity, the Transition phase coincides with the period when AI systems first encounter real production traffic at scale. This is precisely when model behaviour is most likely to diverge from UAT performance — and when the absence of embedded governance becomes observable risk.

Governance checkpoint for Phase 3: The risk committee should require a transition readiness certificate, signed by both the outgoing implementation lead and the incoming operations lead, confirming that all Phase 2 assurance deliverables are operational — not merely documented. The certificate should confirm that monitoring dashboards have live data, that escalation paths have been tested with a table-top exercise, and that DPDP Act data subject request workflows are functional.

Qapitol AI assurance touchpoint: Transition is the right moment for a structured red-team exercise against the production environment, using adversarial prompts and synthetic edge cases that the UAT data set did not cover. If the models break under adversarial conditions before the operations team is fully embedded, that is a recoverable situation. If they break six months into Run, it is a supervisory incident.

Phase 4: Run — Continuous Assurance or Continuous Exposure

The Run stage is where GCC value is realised — and where the governance debt accumulated in Phases 1 through 3 becomes due. For regulated BFSI entities, Run is not a steady state. Model behaviour drifts. Regulatory expectations evolve. The RBI's supervisory technology agenda and the DPDP Act's accountability framework both imply ongoing obligations that do not diminish after go-live. AI systems that were compliant at deployment can become non-compliant through drift, through changes in the underlying data distribution, or through changes in regulatory interpretation.

Governance checkpoint for Phase 4: The risk committee should require a quarterly assurance attestation covering model performance against defined fairness and accuracy thresholds, audit trail completeness, and any material changes to model behaviour since the previous attestation. The attestation should be produced by a function independent of the team operating the models — whether an internal second line or an external assurance partner.

Qapitol AI assurance touchpoint: Continuous model monitoring, periodic bias testing, and structured audit trail review — covering the full lifecycle from training data provenance to inference-time decision logging — are the Run-stage obligations that the Scoping phase must budget for and the Build phase must architect. An assurance practice that is not funded and specified before Phase 2 closes is one that will be improvised under regulatory pressure in Phase 4.

The Build-vs-Buy Frame Your Risk Committee Actually Needs

The GCC build-vs-buy decision for Indian BFSI is not primarily a cost decision or a talent decision. It is a governance decision. The regulated entity retains the regulatory obligation regardless of which model it chooses. What changes is where the accountability for discharging that obligation sits, and whether the contractual structure makes that accountability visible and enforceable.

A GCC vendor that can demonstrate, phase by phase, that AI assurance obligations are embedded as contractual deliverables with defined acceptance criteria is offering a materially different proposition from one that treats governance as a post-go-live service. The difference is not visible in a proposal deck. It becomes visible when a regulator asks for the audit trail — and the trail either exists or it does not.