The Future of AI May Be Open Even If the Models Aren’t

The debate over open AI usually starts and ends with model weights. One side says the only models that are considered open are those with published weights, code, and training data. The opposition says the best production models are proprietary, so the openness argument is already lost. 

Both camps miss where most enterprises live. According to Menlo Ventures, closed models powered 87% of enterprise LLM workloads by mid-2025. Yet those same enterprises increasingly store data in open table formats, register it in catalogs with open APIs, and connect agents to tools through open protocols. So, their AI stack is mostly open with a proprietary model in the middle. However, this  is not a contradiction. The most useful measure of openness within an enterprise is portability and interoperability. Can the organization move its data, definitions, tools, and agents to a different model or platform without starting over? Model licensing is one factor but not the whole answer. 

Openness Was Defined Too Narrowly 

The Open Source AI Definition, published by The Open Source Initiative in October 2024, is a serious standard for judging models. It requires  model weights, the code to train and run the model, and enough information about training data so it can build a substantially equivalent system. . 

However, it says nothing about the systems built around them. A company running an open-source model on a proprietary data platform with proprietary tool integrations and agent runtime, has an open model and a closed system. A company calling a proprietary model through a standard interface, with data in open formats and tools behind open protocols, has the reverse. The second company can switch models in weeks, but the first cannot leave its platform without rebuilding everything else. 

Where Lock-In Actually Lives 

An enterprise AI system has several layers that  can trap an organization. For example, storage in a proprietary format can only be read by the engine that wrote it. A catalog with a proprietary API ties every consuming engine to one vendor. Business definitions locked inside one BI tool passes along that tool’s lock-in to every agent that needs them. Tool integrations written for one vendor’s function-calling format need rewriting for the next, and proprietary agent coordination forces every agent onto the same platform. 

The model is one more layer, and often the easiest to replace, because model APIs look alike and change frequently. Where openness pays off is within the other layers that hold the organization’s accumulated work. . 

Open Layers Are Already Forming and Here’s How Apache Iceberg is now supported in some form by Snowflake, Google BigQuery, AWS services, and Databricks, plus open engines such as Trino, Apache Spark, and DuckDB. Its version 3 specification adds deletion vectors, row lineage, and a variant type. Snowflake made v3 support generally available in May 2026. 

The Iceberg REST catalog specification defines one OpenAPI-based interface between any engine and any catalog, including credential vending for short-lived, scoped access. Apache Polaris implements it as open source and became an Apache top-level project on February 18, 2026. 

Apache Ossie began as the Open Semantic Interchange, launched by Snowflake with a broad partner group in September 2025. It uses YAML to describe datasets, metrics, dimensions, and relationships so BI tools, engines, and agents share one set of definitions. It entered the Apache Incubator in July 2026 under its new name. 

MCP and A2A now share a home. The Linux Foundation formed the Agentic AI Foundation (AAIF) in December 2025 with MCP, Block’s goose, and OpenAI’s AGENTS.md as founding projects. Google’s A2A protocol moved into the AAIF on August 17, 2026. 

More specifically, it looks like this: 

Governance Matters as Much as the License 

An open license allows anyone to use the code and does not stop one company from steering a project toward its own products, as neutral governance handles that risk. For example, the Apache Software Foundation enables committers to earn their roles through contribution, and specification changes go through public votes. A standard controlled by one company can change direction after an acquisition which means that a foundation-governed standard with diverse contributors is much harder to redirect. When two standards solve the same problem, that difference should weigh heavily. 

A Portability Test for AI Openness 

Instead of asking whether each component is open source, ask these questions. 

1. Can a second engine read our data without an export? 
2. Can a new engine discover our tables through a standard catalog API? 
3. Do our metric definitions exist outside any single tool? 
4. Can a different agent runtime call our tools without code changes? 
5. Can agents from two vendors hand work to each other? 
6. Can we run our evaluation suite against a different model this week? 
7. Can we export our traces and evaluation history in a standard format? 

An organization that answers “yes” to all seven has an open AI system, regardless of the  model license. A model running an open-weight model that answers “no” to most of the questions does not. 

Open Models Still Matter 

Open-weight models solve real problems. They run inside an organization’s own network, which helps with data residency, and  allow fine-tuning with full control. A study by OpenRouter and Andreessen Horowitz covering more than 100 trillion tokens found that open-weight models made up roughly a third of all token volume on that platform by late 2025. 

It makes sense that open models work best inside an open system. When data, catalog, semantics, and tools follow open standards, an organization can send hard reasoning tasks to a proprietary frontier model and sensitive or high-volume work to a self-hosted open-weight model. Both read the same governed data and call the same tools. 

Four Things  Open Standards Don’t Solve 

1. Authorization is still fragmented. MCP and A2A define how agents reach tools and each other. Neither defines which agent is allowed to read which data. Organizations still need their own policy layer. 
2. Proprietary extensions creep in. Every vendor extension a team adopts adds a little lock-in. That is often a fine trade, but it should be a conscious one. 
3. Implementation depth varies. Two products that both claim support for a specification can behave very differently. Test real workflows, not checkboxes. 
4. Young standards change. Ossie is incubating, A2A reached 1.0 in 2026, and MCP keeps adding features. Plan for revisions. 

Most enterprises will keep using proprietary models for years, because those models often perform best on the work that matters. That choice fits an open strategy just fine. The openness that protects an organization lives around the model: open data formats, open catalog APIs, portable semantics, standard tool and agent protocols, and exportable observability. Judged by portability, the future of enterprise AI looks far more open than the licensing debate suggests.