Governance Without Gatekeeping: How Enterprise AI Teams Should Navigate the Open Source Policy Shift

The policy conversation around foundation models has moved well past theoretical. Proposals circulating across Washington, Brussels, and the UK's AI Safety Institute now combine mandatory independent capability evaluations with potential compute thresholds that would determine which organisations can legally release a model openly. For most enterprises, this reads as a background regulatory story. It should be read as a vendor strategy problem.

Companion piece to our broader work on AI infrastructure dependency risk. See When Your AI Infrastructure Becomes Someone Else's Product for how recent acquisitions in the model distribution layer are reshaping API portability and enterprise architecture decisions.

What the Governance Proposals Actually Say

The emerging regulatory framework rests on two mechanisms that interact in ways most enterprise teams have not modelled. The first is pre-release evaluation: independent bodies would assess frontier models for dangerous capabilities before any public release, open or proprietary. The second is a compute threshold, typically expressed in floating-point operations, above which a model would trigger mandatory evaluation and potentially restricted distribution.

The threshold mechanism is where the enterprise risk concentrates. If compute limits are set at levels only reachable by the largest labs, the practical effect is not safety regulation. It is a structural barrier that prevents open model releases from the organisations most likely to produce capable alternatives to the incumbents.

The evaluation component is more defensible in principle. Independent capability testing, if conducted transparently and with published methodology, could actually benefit enterprise buyers by providing standardised risk signals. The problem is that no such independent infrastructure exists at scale today, and the timeline proposals in most regulatory drafts are aggressive relative to the maturity of evaluation science.

The Vendor Concentration Risk That Is Not Priced In

Enterprise procurement teams have spent the last three years building AI stacks that assume continued competition at the model layer. That assumption is load-bearing. It drives negotiating leverage with API providers, justifies investment in open model fine-tuning pipelines, and underpins the build-versus-buy calculus for any capability that sits close to core business logic.

If governance frameworks effectively restrict open model releases to a small number of approved organisations, that competitive pressure disappears. The organisations left standing with both the compute budgets to clear regulatory thresholds and the legal capacity to navigate pre-release evaluation are, with very few exceptions, the same incumbents already dominating the proprietary API market.

The downstream effect on enterprise buyers is a reduction in substitution options at precisely the moment when switching costs are highest. Infrastructure built around a single API provider is not easily migrated when the model layer beneath it changes, deprecates, or reprices. We have written about how acquisition activity in the model distribution layer is already compressing those substitution options. Regulatory concentration would accelerate that compression significantly.

What the Build-Versus-Buy Calculus Looks Like Under Regulatory Pressure

The standard build-versus-buy framework for AI treats open models as the low-dependency path and proprietary APIs as the high-dependency path. That framing holds under current conditions. Under a constrained open model ecosystem, it partially inverts.

If the pool of openly available capable models shrinks, the cost of maintaining a self-hosted stack rises. Smaller model releases may remain unrestricted, but enterprises that need frontier-level capability for complex reasoning, multimodal tasks, or domain-specific performance will face a choice between accepting API dependency or investing in the evaluation and compliance overhead that restricted models carry.

The implication is not that enterprises should abandon open model strategies. It is that they should build those strategies with explicit assumptions about the regulatory scenario they are planning against, and stress-test procurement decisions against a world where the open model catalogue at frontier capability is materially thinner than it is today.

How to Evaluate Governance Exposure in Your Current Stack

The first step is a dependency audit that maps each production AI workload to its model source, the substitution options available at equivalent capability, and the switching cost if that source becomes unavailable or significantly more expensive. Most enterprises have not done this with regulatory scenarios in mind.

Compute Threshold Exposure

Identify which models in your stack were trained at scales that would likely trigger regulatory thresholds under current proposals. This is not always visible from API documentation, but model cards and technical reports from major labs typically include training compute estimates. Models above the threshold are the ones whose continued open availability is most uncertain.

Evaluation Timeline Risk

Pre-release evaluation requirements create latency between a model's technical completion and its availability for enterprise deployment. For teams planning product roadmaps around model capability improvements, that latency introduces schedule risk that does not exist today. Build buffer into any roadmap that depends on a specific model generation being available within a defined window.

What Technical Leaders Should Do Now

The governance debate will not resolve quickly. The more useful posture is to treat regulatory concentration risk as a scenario to plan against rather than a prediction to make.

Concretely, that means maintaining active relationships with at least two model providers at each capability tier you depend on, including one that operates a self-hosted or on-premise deployment path. It means tracking the compute threshold proposals in the jurisdictions where your operations are regulated, because the thresholds in the EU AI Act technical annexes, the US executive order framework, and the UK's voluntary commitments are not identical and may diverge further.

It also means engaging with independent evaluation frameworks as they develop rather than waiting for them to become mandatory. Organisations that understand how capability evaluations work, what they measure, and where their limitations lie will be better positioned to assess vendor claims and procurement risk than those encountering the methodology for the first time under a compliance deadline.