AI changes the economics of the identity governance iceberg

At a glance

What this is: This blog explains why the GSI tax dominates many identity governance programmes and why AI changes the economics of integration-heavy IGA work.

Why it matters: It matters because IAM and IGA teams need to distinguish strategic governance work from repetitive connector maintenance when planning budgets, renewals, and operating models.

By the numbers:

• Implementation services account for 30 to 60 percent of year-one spend in verified IGA purchases, according to Opnova.

Context

Identity governance programmes often fail to separate the cost of buying a platform from the cost of making it work across the real application estate. The article calls that gap the GSI tax, and argues that the long tail of disconnected applications is what turns IGA into a services-heavy programme.

The core governance problem is not the license itself but the continuous operational burden underneath it. AI is changing that burden by taking on integration and workflow work that previously required bespoke connector development and ongoing maintenance.

Key questions

Q: What breaks in identity governance when integration is treated as a one-time project?

A: The programme starts to accumulate connector debt, because applications keep changing after go-live while the operating model assumes stability. That creates repeated rebuilds, manual workarounds, and slower onboarding. When integration is not designed as a permanent operating condition, the identity platform becomes a budget sink instead of a governance control.

Q: Why do IGA programmes become so expensive to operate over time?

A: They become expensive when most of the work is custom integration, exception handling, and connector maintenance rather than durable governance architecture. If the application estate is fragmented and standards like SCIM are rare, teams keep paying for the same operational problem in every renewal cycle. Cost rises because work is repeated, not because the licence alone is large.

Q: How can security teams tell whether their identity budget is stuck on the connector treadmill?

A: Look for a growing onboarding queue, older items that never clear, and a rising share of budget spent on maintaining existing integrations. Those are signs that the programme is preserving yesterday’s work instead of expanding coverage. When maintenance consumes most of the budget, the backlog is no longer a temporary delay.

Q: Should organisations use AI for identity governance before they clean up data and policies?

A: No. AI should not be asked to decide access when identity records, entitlement labels, and policy rules are inconsistent. The better sequence is to normalise data, standardise approval criteria, and then apply AI to assist with scale, because automation amplifies the quality of the inputs it receives.

Technical breakdown

Why identity governance becomes a services programme

Identity governance is rarely limited to configuration and policy design. In practice, the hardest work is integrating the platform with heterogeneous applications, many of which lack native connectors, stable APIs, or standardised provisioning interfaces. That is why implementation services often dominate year-one spend. The article’s key point is that the program’s cost profile is driven less by software purchase and more by how much human labour is needed to reconcile the identity platform with the application estate.

Practical implication: Treat integration effort as an operating model issue, not just a project estimate.

The connector treadmill in IGA

The connector treadmill is the cycle where new applications enter the queue faster than old integrations are completed, while existing connectors break as applications change. This creates a permanent maintenance burden that consumes budget long after go-live. SCIM helps only where applications support it natively; the article says fewer than 7 percent do, which leaves most environments dependent on custom work. That means IGA programmes are often paying repeatedly for the same class of work rather than building durable coverage.

Practical implication: Measure the age and size of the onboarding queue alongside the connector breakage rate.

How AI changes integration economics

The article’s central technical claim is that AI agents can increasingly complete integration and workflow tasks while adapting to target application changes. That does not eliminate governance design, role modelling, or compliance architecture. It does, however, reduce dependence on hand-built connectors and the maintenance loop that follows them. In effect, AI shifts identity governance from code-heavy integration toward more adaptive automation, especially in the disconnected long tail where bespoke engineering has been the default.

Practical implication: Separate strategic governance tasks from repetitive integration toil when deciding where AI can safely absorb work.

NHI Mgmt Group analysis

AI is changing the economics of identity governance, not the need for governance. The article is right to draw a line between strategic architecture and repetitive connector toil. Program design, compliance mapping, and lifecycle governance still require human judgment, but the cost structure underneath them can now be reduced materially when integration work is no longer hand-built for every disconnected application. The implication is that IAM leaders should reprice the programme around work type, not software category.

The connector treadmill is a budget failure mode, not a technology inconvenience. When application onboarding queues stretch into years and maintenance consumes new-program budget, the organisation is funding inertia instead of coverage. That dynamic explains why many IGA programmes become distressed: the operating model assumes finite implementation, but the environment demands permanent integration work. Practitioners should treat queue depth and connector decay as governance health indicators.

Identity governance still has an iceberg problem. Visible license cost is only the tip; the hidden mass is maintenance, exception handling, and integration churn. The article correctly notes that many enterprises keep paying for the same underlying toil because the long tail of applications resists standardisation. The practical conclusion is that renewal decisions should test how much of the programme is strategic coverage versus connector preservation.

Runtime integration work has become the new GSI tax: AI can compress the labour spent on disconnected applications, but it also exposes which parts of the programme were really manual workaround in disguise. That assumption was designed for a world where integration was a one-time project. It fails when the application estate changes continuously and the operating model depends on perpetual rebuilds. The implication is that organisations must rethink what they buy, what they automate, and what they still need specialists to govern.

The market signal is a shift from project-based IGA to adaptive governance operations. AI-assisted integration changes the economics of the long tail, which means vendors, GSIs, and internal teams will be judged less on implementation breadth and more on how much recurring toil they remove. That does not eliminate service demand, but it does narrow it to the work that genuinely requires architecture and oversight. Practitioners should expect procurement criteria to move toward operating efficiency and sustained maintainability.

What this signals

AI-assisted governance will not erase identity architecture work, but it will expose which parts of the programme were labour-intensive workaround all along. That changes how leaders should think about renewal, because the real question is no longer whether the platform can be installed. The question is how much of the operating cost comes from maintainable governance and how much comes from keeping custom integrations alive.

Disconnected applications are where governance economics still break down. When most applications lack native standards-based connectivity, every new onboarding decision carries future maintenance cost. AI can reduce that burden, but only if teams are willing to distinguish strategic control design from connector preservation and measure them separately.

For practitioners

• Budget separately for strategic design and connector maintenance Split identity governance spend into architecture, compliance mapping, and integration upkeep so the programme does not hide recurring toil inside implementation line items.
• Measure the onboarding queue as an operating risk Track the number of applications waiting for integration, the age of the oldest item, and the pace at which old connectors break versus new ones are delivered.
• Audit where custom connectors are carrying the programme Identify integrations built for applications without SCIM or stable APIs, then classify which ones are strategic and which are pure maintenance drag.
• Reprice renewals around maintenance intensity Before renewal, compare last year’s spend on keeping existing integrations alive with spend on new coverage, because maintenance-heavy programmes are already on the treadmill.

Key takeaways

• Identity governance programmes often spend more on implementation labour than on the software itself, which is why the GSI tax persists.
• The operational problem is not just initial onboarding. It is the repeated maintenance of custom integrations across a fragmented application estate.
• AI changes the cost curve by absorbing repetitive integration work, but it does not remove the need for architecture, compliance mapping, and governance oversight.

Key terms

• GSI tax: The GSI tax is the gap between software licence cost and the much larger amount spent making identity governance work in the real world. It includes implementation services, connector rebuilds, manual processes, and ongoing operational support that appear only after procurement.
• Connector treadmill: The connector treadmill is the repeating cycle in which new application integrations are added more slowly than existing ones need maintenance. In identity governance, this creates a permanent backlog and shifts budget from expanding coverage to preserving fragile integrations.
• Identity Governance Distress: Identity governance distress describes a programme that misses its functional, budget, or timing commitments. It is usually a sign that the operating model cannot keep up with application complexity, integration churn, and the maintenance load needed to keep governance coverage alive.
• Disconnected Application: An application that is not integrated with the organisation's central identity and access stack. Access is often managed through shared passwords, manual approval, or local admins, which makes revocation, evidence, and ownership harder to enforce consistently across the application lifecycle.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.