By NHI Mgmt Group Editorial TeamBased on Lumenova AI: “The AI Center of Excellence Bottleneck, and How Financial Institutions Can Avoid It” (September 24, 2026)

TL;DR: Bank AI centres of excellence often become bottlenecks as GenAI adoption outpaces oversight, leaving inconsistent guardrails, limited production visibility, and shadow AI risks across the portfolio, according to Lumenova AI. The durable fix is central observability and evaluation with self-service, use-case-specific controls.


At a glance

What this is: This is an analysis of why bank AI centres of excellence stall at scale, with the key finding that central review models create bottlenecks while missing production visibility.

Why it matters: It matters because identity and governance teams need operating models that can control AI use cases without forcing every launch through a manual gate, especially where shadow AI and accountability are in scope.

By the numbers:

  • While roughly 32% had deployed AI/ML into production, only 12% described their AI/ML strategy as well-defined and resourced.
  • Agentic AI was already active among 52% of financial services respondents.
  • Only 5% of community and regional banks had launched a scaled, governed AI program.

Context

An AI centre of excellence is meant to standardise GenAI governance, monitoring, and launch controls across the institution. In practice, the governance gap appears when adoption grows faster than central review, leaving teams with inconsistent guardrails and weak visibility into what is running in production.

For banks, this is not just an AI operating model issue. It affects accountability, evidence collection, and oversight of shadow AI where applications move ahead of the central team, creating the same kind of control fragmentation that identity and access programmes try to avoid.

The article frames the typical failure mode as structural rather than technical: the organisation has controls, but not a scalable way to apply them across many use cases.


Key questions

Q: What breaks when AI centres of excellence are forced to review every launch?

A: They stop scaling. Every launch becomes dependent on a small approval group, which slows delivery, encourages workarounds, and leaves the institution with fragmented visibility once teams bypass the process. The control failure is not the absence of policy. It is a review model that cannot keep pace with application growth.

Q: Why do central AI guardrails fail in production if they are not paired with observability?

A: Because guardrails only tell you what should happen, while observability tells you what actually happened. Without a live inventory and monitoring view, the organisation cannot prove which models are running, whether they were evaluated, or when they drift outside approved bounds. That leaves governance reactive instead of evidence-based.

Q: How can banks tell whether an AI CoE is working properly?

A: Look for short time-to-onboard, near-complete production inventory, active monitoring across applications, and a declining shadow AI footprint. If standard use cases still need repeated manual review, the CoE is functioning as a queue rather than a control layer. Working governance should be visible in evidence, not in escalation volume.

Q: What is the difference between an AI governance committee and an AI CoE?

A: A governance committee usually sets policy and approves material risks at decision points. An AI CoE is operational. It maintains the tooling, standards, onboarding, observability, and evaluation mechanisms that let teams apply policy continuously across production use cases.


Technical breakdown

Why AI centres of excellence become bottlenecks

An AI centre of excellence sits between business demand and governance, but it becomes a bottleneck when every use case must pass through the same small review group. The underlying failure is not lack of policy. It is an operating model that cannot scale control distribution as application count grows. Once that happens, teams either wait, bypass the process, or ship with uneven protections. In regulated environments, that creates a visibility problem as well as a compliance problem because the institution can no longer prove what is in production, what was evaluated, or which baselines apply across use cases.

Practical implication: move from gatekeeping every launch to standardised controls that apply automatically and consistently.

Central observability and evaluation standards

Central observability means the institution can see every production GenAI application, its behaviour, and its evaluation status from one place. Evaluation standards define how the organisation judges whether a model is operating within approved bounds, including safety, quality, and reliability thresholds. Together, they create evidence that can be shared with risk, compliance, and auditors without reconstructing the picture from multiple teams. This is especially important where the AI system changes frequently or where agentic behaviour introduces dynamic decision paths that need to be measured rather than merely approved at launch.

Practical implication: require an inventory, monitoring layer, and shared evaluation criteria before scaling new AI use cases.

Self-service guardrails with use-case-specific control

The article’s core architecture point is that protection should be centralised, but not identical everywhere. A customer-facing assistant and an internal drafting tool need different control settings, yet both should inherit the same baseline guardrails and monitoring. That model preserves governance while avoiding a manual approval queue for standard use cases. The identity and access parallel is clear: central policy with delegated configuration is more sustainable than a process where every exception becomes a bespoke review. This is how control stays usable as adoption widens across business lines.

Practical implication: define baseline protections centrally, then let teams configure only the use-case-specific differences.


NHI Mgmt Group analysis

AI governance bottlenecks are an operating model failure, not a control shortage. The article shows that banks can have guardrails on paper and still fail in practice when those controls depend on a central team reviewing every launch. That pattern mirrors identity governance programmes that look complete until volume makes the manual path unworkable. The practitioner lesson is that control design has to scale with adoption, not chase it.

Shadow AI is the visible symptom of governance that cannot keep pace. When teams route around the process to avoid delays, the institution loses inventory, accountability, and monitoring fidelity at the same time. The issue is not simply non-compliance. It is that the bank no longer knows which AI systems exist well enough to govern them. The practitioner conclusion is to make visibility and baseline protection the default state.

AI oversight now sits at the intersection of model risk, operational resilience, and identity-style lifecycle control. Once GenAI and agentic systems are in production, governance has to answer who approved them, how they are monitored, and when their behaviour changes enough to require re-evaluation. The named concept here is governance visibility debt: the accumulation of untracked AI use cases that central teams cannot reliably account for. The practitioner implication is to reduce that debt before scale makes it harder to unwind.

A mature AI CoE should act like a standards platform, not a bottleneck tribunal. The most durable pattern is central ownership of observability and evaluation, with distributed configuration for use cases that remain within policy. That structure preserves accountability while allowing business teams to move at the speed adoption demands. The practitioner takeaway is to separate baseline control from discretionary review.

In financial institutions, AI governance is becoming a board-level evidence problem. Examiners and internal audit care less about the existence of a committee than about the quality of inventory, monitoring, and decision records. That makes operating model design part of compliance architecture, not an implementation detail. The practitioner conclusion is to measure governance by evidence availability, not meeting cadence.

From our research library:

What this signals

Governance visibility debt: when AI adoption outpaces inventory and monitoring, the organisation accrues blind spots that cannot be managed through committee review alone. Banks should treat this as a control-plane problem and reduce the gap between approved AI and actual AI in production.

The operational test is whether baseline protection is inherited automatically or requested case by case. Where every launch needs a manual gate, control is already too centralised to scale.

This is the point at which AI governance starts to resemble identity lifecycle management: if ownership, inventory, and review are not continuous, accountability becomes reconstructive instead of preventive.


For practitioners

  • Centralise AI application inventory and observability Create a single, authoritative view of all production GenAI and agentic AI applications, including owners, last evaluation date, and monitoring status.
  • Apply baseline guardrails automatically Use one governed baseline for safety, quality, and reliability controls, then allow per use case configuration only where the business need genuinely differs.
  • Replace mandatory review gates for standard use cases Remove manual approval from low-risk launches once baseline controls and evaluation are in place, so the AI CoE can focus on higher-risk exceptions.
  • Set evaluation SLAs for production models Define measurable SLAs for evaluation frequency, drift review, and incident escalation so model governance is time-bound rather than ad hoc.
  • Track and reduce shadow AI Compare approved inventory against actual usage to identify tools deployed outside the AI CoE visibility boundary and assign remediation ownership.

Key takeaways

  • The central risk is not the existence of AI CoEs, but the tendency for them to become queues that the business routes around when adoption accelerates.
  • The article shows that scalable AI governance depends on inventory, observability, and evaluation evidence, not on a larger approval committee.
  • Banks that want to avoid shadow AI need baseline controls that apply automatically and use-case-specific settings that do not require a manual gate for every launch.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF, NIST AI 600-1 and NIST CSF 2.0 set the technical controls, while ISO/IEC 42001:2023 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article is primarily about AI governance operating models and accountability in banks.
MEASURE — AI Measurement and EvaluationThe article stresses evaluation standards and production monitoring as the control backbone.
Recommendation — Use GOVERN to formalise ownership, evidence, and oversight for GenAI programmes. Use MEASURE to define evaluation SLAs and production monitoring criteria for AI systems.
ISO/IEC 42001:2023clause 5 — LeadershipThe AI CoE role is fundamentally about leadership, accountability, and governance structure.
Recommendation — Assign leadership accountability for AI governance and operational oversight.
NIST AI 600-1GenAI risk management and profileThe article concerns generative AI oversight, monitoring, and controlled deployment in production.
Recommendation — Apply the GenAI profile to standardise monitoring and evaluation for production use cases.
NIST CSF 2.0GV.RM-01 — Risk Management StrategyThe piece focuses on how risk management should scale across a portfolio of AI use cases.
Recommendation — Embed AI governance into the enterprise risk strategy and evidence model.

Key terms

  • AI Center of Excellence: An AI Center of Excellence is the operational team that sets standards, tooling, and governance for AI across an organisation. In regulated environments, it bridges business delivery, risk, and compliance so AI use cases can be monitored consistently rather than reviewed as isolated exceptions.
  • Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
  • Centralized Observability: Centralized Observability is the ability to see usage, access, and policy activity from one control point rather than many isolated systems. In MCP environments, it helps security and IT teams detect misuse, support audits, and understand how servers are actually being used across the enterprise.
  • Governance Debt: The accumulation of unresolved identity control weaknesses created when teams prioritise speed over lifecycle design. In NHI environments, it shows up as accounts with unclear ownership, undocumented purpose, stale credentials, and no reliable retirement path, all of which make later security work harder.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and identity lifecycle management. It helps security and identity practitioners build governance models that scale beyond manual review.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org