Open models are narrowing the AI gap, but data remains the moat

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Open models are becoming more competitive, and enterprise data, not model architecture, is framed as the lasting differentiator.

Why it matters: It matters because IAM and NHI teams now have to govern the access paths that feed model differentiation, not just the models themselves.

Context

Open models are reducing the practical gap with frontier systems, which shifts attention away from raw model selection and toward the data estate that shapes outcomes. In identity terms, the decisive control plane moves to who can reach proprietary data, code repositories, and downstream training or fine-tuning workflows.

The article frames data as the moat because companies can only build durable model advantage if they can govern access to the enterprise data behind their walls. That makes identity, entitlements, and lifecycle controls part of AI differentiation, not just security hygiene.

Key questions

Q: How should security teams govern data access for open model programmes

A: Security teams should govern open model programmes by treating training and retrieval data as a privileged asset class. That means tying access to named business use cases, limiting service accounts to the minimum necessary sources, and reviewing any identity that can move data into model workflows. Without that discipline, model ownership can outpace data governance.

Q: What happens when enterprise data access is too broad for AI models

A: Broad data access increases the blast radius of AI systems and weakens the moat the organisation is trying to build. If model-connected identities can reach too many sources, sensitive material can leak into training, retrieval, or downstream outputs, and the model may absorb low-value or irrelevant data that dilutes performance rather than improving it.

Q: Why do open source models increase identity governance pressure?

A: Open source models increase identity governance pressure because they make it easier to bring AI execution inside the enterprise boundary. Once that happens, the organisation owns the permissions, credentials, and operational changes that keep the workload running. The governance challenge shifts from vendor reliance to managing internal access paths and accountability.

Q: What should teams do when model performance converges across vendors

A: Teams should stop treating model selection as the main strategic variable and focus on who can safely access proprietary data. When model quality converges, the differentiator becomes the precision of access control, data segmentation, and lifecycle management around the identities that feed AI workloads.

Technical breakdown

Why enterprise data access becomes the control point for open model differentiation

When model capabilities converge, advantage comes from the data a company can lawfully and safely apply to those models. That means access to firewalled applications, internal documents, and code repositories becomes a governance issue, because those sources can be used to fine-tune or contextualise models that are meant to reflect the business. The real mechanism is not model ownership alone, but control over the identity paths that unlock proprietary data for training and inference. Practical implication: treat high-value enterprise datasets as governed identity assets, not just storage locations.

Practical implication: map and restrict the identities that can access data used to differentiate AI systems.

How open models change the identity risk of AI programmes

Open models lower dependency on a single frontier vendor, but they increase the importance of internal access governance because the organisation now owns more of the AI stack. That shifts risk from external model dependency to internal data exposure, overbroad service access, and weak lifecycle management around the systems that move data into model workflows. The key technical issue is not whether a model can be downloaded, but whether the surrounding identities can be trusted to move sensitive data into the right place for the right purpose. Practical implication: align AI programme controls with NHI and workload identity governance.

Practical implication: extend NHI governance to the services, tokens, and pipelines that feed model training and retrieval.

Why model parity makes least-privilege for data a strategic control

If open models can reach near-parity on many tasks, then the quality of the dataset and the fidelity of access controls determine how much of the enterprise’s advantage survives. Excessive permissions widen the set of data a model can absorb, which raises both confidentiality risk and the chance of contaminating training or retrieval with irrelevant content. Least privilege therefore becomes a quality control for model differentiation as much as a security control. Practical implication: scope AI data access to the minimum set of sources that materially improve the model outcome.

Practical implication: limit model-connected identities to the smallest data set that still supports the intended use case.

NHI Mgmt Group analysis

Data access, not model ownership, is now the primary identity control plane. The article’s core claim is that open models are catching up fast enough that proprietary data becomes the durable source of differentiation. That changes the identity problem: the important question is no longer only which model a team selects, but which identities can reach the enterprise systems that feed those models. Practitioners should treat data access governance as part of AI governance, not as an adjacent control domain.

Open model adoption reduces vendor dependency but increases internal governance pressure. Owning the model weights sounds like independence, yet the enterprise still depends on service accounts, pipelines, and application identities to move data into the model lifecycle. If those identities are too broad, the organisation may gain model control while losing control over the information that makes the model valuable. The implication is that AI programmes need the same discipline applied to NHI estates: inventory, scope, lifecycle, and review.

Enterprise data behind firewalls is a governance asset only if identity can segment it. The article’s 95% claim about data hidden behind enterprise firewalls is a reminder that value concentrates where access is hardest to normalise. That hidden data is only an edge if access is intentionally limited to specific use cases, because broad access turns moat data into shared fuel. Practitioners should think in terms of identity blast radius for AI, where each connected workload expands or contains the competitive advantage.

Model convergence makes access governance the differentiator that survives commoditised architecture. When performance gaps narrow, architecture stops being the main decision variable and control over context becomes more important. That is why AI programmes increasingly depend on the same IAM and NHI primitives that govern any high-value workload. The field should read this as a shift from model scarcity to governed data abundance, with access policy deciding whether enterprise knowledge remains proprietary or becomes portable.

What this signals

Data moat governance: when model architecture becomes easier to replicate, the control surface shifts to the identities that can touch proprietary data. That means AI programme risk now sits at the intersection of access scope, service account governance, and dataset segmentation.

Enterprises that want differentiated AI outputs will need to think more like identity architects than model shoppers. The deciding question is which workloads can reach which data, for what purpose, and under what lifecycle controls.

The governance gap is not access to an LLM, but access to the information that makes the LLM useful. Once that access is broad, the moat weakens even if the model itself remains under organisational control.

For practitioners

• Inventory AI-connected data paths Map every service account, token, and workload identity that can move enterprise data into model training, retrieval, or fine-tuning flows. Identify where those paths intersect with firewalled applications and code repositories.
• Scope model data access by use case Grant AI workloads access only to the smallest set of datasets that materially support the intended output. Separate experimental, production, and sensitive data sources so model-connected identities cannot drift across boundaries.
• Apply lifecycle controls to AI workload identities Review creation, rotation, and revocation for the identities that feed AI pipelines. Offboard dormant connectors and remove credentials that no longer correspond to an active training or retrieval workflow.
• Review blast radius around proprietary datasets Test what a compromised model pipeline could reach if one connected identity were abused. Reduce shared access and separate high-value data domains so one workflow cannot expose the whole moat.

Key takeaways

• Open models are reducing the strategic value of model exclusivity, while enterprise data access becomes the real source of differentiation.
• The identity problem moves inward when AI capability converges, because service accounts and pipelines decide which data shapes model outcomes.
• Practitioners should govern AI data paths with the same rigour they apply to sensitive workload access, or the moat becomes porous.

Key terms

• AI data moat: The proprietary data advantage that makes one organisation's model outputs more useful than another's. In practice, it is not a storage concept but a governance one, because the moat only exists when identity controls keep the right data available to the right workloads and keep everyone else out.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Model-connected identity: Any service account, token, or credential that lets an AI workflow reach training data, retrieval sources, or downstream systems. The security question is not simply whether it exists, but whether its permissions are tightly scoped to the intended model task and lifecycle.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.