Stripe has spent fifteen years turning payment complexity into programmable infrastructure. Money moves through a messy mix of cards, banks, currencies, fraud systems, and local rules. Stripe sits in the middle, makes that complexity manageable, and earns its position by improving how transactions move.

It has now found the same structure in AI.

On August 19, Stripe agreed to acquire OpenRouter, a three-year-old model gateway that gives developers access to more than 400 models from over 80 providers through one interface. The companies did not disclose the price, but Reuters reported that the transaction was worth slightly more than $8 billion.

That is a remarkable valuation for a company that does not build frontier models, manufacture chips, or operate a hyperscale cloud. OpenRouter occupies the layer between demand and supply. It can evaluate a request, send it to a suitable model based on cost, speed, reliability, and task complexity, then measure what happened.

In other words, Stripe is buying the layer that helps decide which model gets used and which provider gets paid.

The transaction makes a specific economic judgment about enterprise AI. Models will continue to multiply. Their prices will change frequently. Capability will remain uneven across coding, reasoning, vision, retrieval, tool use, latency, and long-running work. No provider will offer the best answer at the best price for every task.

Under those conditions, model selection stops being a periodic procurement exercise. It becomes a continuous allocation decision.

OpenRouter says it now processes more than 10 trillion tokens a day for over 10 million developers and companies, with inference volume growing at least tenfold each year since its founding. Its customers include Nvidia, Zoom, and Lovable.

Another datapoint arrived three days after the acquisition announcement. Vercel CEO Guillermo Rauch reported that open-weight models accounted for 62 percent of token volume through Vercel’s AI Gateway on August 22, up from 28.4 percent on June 24.

That is one gateway’s traffic on two specific days. It does not represent the entire market, and token volume does not equal revenue. A cheaper model can process enormous volume while a premium frontier model collects more money from a smaller number of demanding tasks.

The movement still matters. It shows how quickly workloads can shift once developers gain a common interface, comparable pricing, and the ability to change models without rebuilding the entire application.

Frontier labs can continue growing throughout this shift. In fact, better frontier models make routing more useful. A company can reserve expensive intelligence for work that justifies it, then direct classification, extraction, summarization, routine coding, or high-volume agent steps toward cheaper models.

The model portfolio starts to resemble a workforce with dramatically different costs and capabilities. Paying the most expensive specialist to perform every task would be absurd. Enterprise software has spent decades institutionalizing equally strange behavior, so it would be unwise to assume AI will escape the tradition automatically.

The router becomes the allocation system for intelligence.

From vendor selection to workload allocation

Enterprise AI procurement still tends to begin with a familiar question: Which model provider should we standardize on?

That question made sense when model access was scarce, capability gaps were wide, integration required bespoke work, and usage remained small enough that token economics barely troubled the finance team. Standardization reduced complexity and accelerated experimentation.

Each of those conditions is weakening.

Models now arrive and change faster than enterprise contracting cycles. A workload approved against one model can face a new version, price, rate limit, retention policy, safety behavior, or regional restriction before the contract reaches its first anniversary. Open-weight alternatives continue to improve. Gateways make it easier to compare them. Application teams increasingly embed their own model choices inside products and workflows.

A three-year provider commitment can therefore begin as a model decision and end as an operating constraint.

Routing offers an apparent solution. Put a common interface in front of the providers, define selection rules, and preserve the ability to switch. The enterprise can arbitrage price, route around an outage, use local models for sensitive work, or reserve frontier capability for the hardest tasks.

That architecture is attractive. It is also incomplete.

The party that controls routing sees which models work, what each task costs, where failures occur, which prompts produce value, and when a cheaper alternative becomes acceptable. Over time, it accumulates the evidence needed to allocate enterprise intelligence more effectively.

That data can become more strategically valuable than simple access to another model.

Stripe understands this pattern well. Payment infrastructure does more than connect merchants to payment methods. It learns which transaction path is likely to succeed, how fraud risk changes, where conversion fails, and how economics differ across routes. OpenRouter creates a comparable position between AI demand and model supply.

The parallel has limits, but the commercial logic is clear. As intelligence becomes easier to source from multiple providers, the intermediary that measures, routes, bills, and optimizes consumption gains influence.

For CAIOs, the decision is whether model routing becomes an intentional enterprise capability or an accidental feature distributed across application teams, agent platforms, cloud services, and vendor products.

Below the paywall, I examine where routing creates genuine optionality, where it creates another concentration point, how frontier labs can defend their position, and which assets an enterprise must own before delegating model choice.

Read more

An AI application can improve its margins every time a customer uses it.

That is an unusual feature of the current market. Traditional software vendors spend heavily to build a product, then distribute additional copies at negligible cost. Generative AI applications begin with a meter running. Every customer request can produce another charge from the model provider.

For an AI application handling millions of customer conversations, inference becomes a cost of goods line. The vendor therefore has a strong incentive to reduce how often it pays frontier-model prices.

Jesse Zhang, co-founder and CEO of customer-service AI company Decagon, recently described how far that process can go. Zhang says Decagon now runs roughly 90% of its workloads on models with accessible weights instead of relying on OpenAI or Anthropic.

That figure sits awkwardly beside the broader market data. Menlo Ventures estimates that open-model share of enterprise LLM spending fell from 19% to 11% over the previous year. Enterprises appear to be spending more heavily on proprietary models while a prominent AI application vendor moves in the opposite direction.

Zhang explains the discrepancy through use-case maturity.

A new application begins with uncertainty. The team does not yet understand the full distribution of requests, the difficult exceptions or the failures customers will tolerate. A powerful general-purpose model buys room to explore. It carries knowledge and reasoning ability the application may never need, but that excess capability is useful while the problem remains poorly defined.

Production changes the calculation. Repeated requests expose the common paths. Failures identify the difficult cases. Corrections show what an acceptable answer looks like. Escalations reveal where the system should stop. Once the workflow becomes predictable, a smaller model can be tuned for the work that actually arrives.

Zhang says that combination of speed, size and deep task-specific tuning pushed Decagon toward models it could modify. “Open-weight” is the more accurate term for many of these models. Access to weights does not necessarily provide the training data, code and rights associated with open-source software. The commercial mechanism matters more here than the label: the application vendor gains greater control over the model and its operating cost.

This creates an attractive production architecture. A specialist model handles the frequent, well-understood requests. A frontier model remains available for unfamiliar or difficult cases. The vendor pays premium rates only when the work requires premium capability.

Decagon has not published enough detail to evaluate the economics, model portfolio or quality results behind its 90% claim. Its account still exposes an important distinction in the enterprise market.

Decagon is an AI application supplier. Its customers are buying customer-service automation, rather than procuring a model for each conversation. The application may remain proprietary even when much of the intelligence underneath it moves to open-weight models.

That helps explain how enterprise spending on proprietary AI applications can rise while open-weight models spread through production. The migration occurs inside the application vendor, below the line of sight of procurement. The enterprise continues paying for the same product. The vendor changes the machinery underneath it.

The economic consequence is easy to miss. An application may have been priced when a meaningful share of each transaction required an expensive frontier call. Over time, the vendor learns enough about the workflow to move routine work onto cheaper models. Its latency improves and its inference bill falls. The customer’s subscription price does not automatically follow either one.

There is nothing inherently improper about that. Software vendors have always improved their infrastructure and retained the resulting margin. Customers buy a functioning service. They do not receive a quarterly rebate because the vendor optimized a database query or negotiated a better cloud contract.

AI adds a complication. Production interactions can provide some of the raw material required to make the cheaper system possible.

Customer conversations reveal the task distribution. Employee corrections identify bad answers. Escalations expose the model’s limits. Resolved cases can become evaluation examples. At sufficient scale, the history of the work becomes an asset that helps the vendor reduce its dependence on general-purpose models.

This does not establish that Decagon trains shared models on customer conversations. Zhang’s article does not disclose the data used for tuning, and any such use would depend on product design, customer terms and privacy controls. The broader commercial possibility remains: an AI vendor can learn from production experience supplied through customer deployments, then convert that learning into better performance and lower cost.

The enterprise decision therefore reaches beyond the choice between open and proprietary models. Buyers need to decide what their vendor may learn from their operations, which parts of that learning may be reused, how model substitutions will be governed and whether mature deployment economics should change the price paid at renewal.

A CIO reviewing an AI application contract should be able to answer four concrete questions. Can the vendor use customer interactions to improve a shared system? Who retains the evaluation cases, labels and tuning artifacts derived from those interactions? Which model changes require disclosure or renewed approval? When the vendor’s delivery cost falls materially, how will the enterprise test whether its price still reflects the market?

These questions become difficult to negotiate after several years of production history have accumulated. The data rights, operating controls and renewal structure need to be established while the application is still learning.

Subscribe now

Below the paywall, I examine where the valuable learning actually accumulates, the legitimate argument for letting vendors retain the economic gain, and the contract position buyers should take on derived data, model changes, portability and repricing.

The customer may be supplying the scarce asset

General language data can produce a model that knows how customer service usually

Read more

Subscribe now

NVIDIA has published the sort of number that tends to survive three rounds of caveats and arrive in a board presentation untouched: 100%.

Its Agentic Variation Operators system, or AVO, completed all 183 levels across the 25 public environments in ARC-AGI-3. The benchmark drops an agent into unfamiliar, turn-based worlds with no instructions, stated rules, or declared goal. The agent must work out what matters, learn from its actions, and finish each level without wasting too many moves. NVIDIA paired AVO with Claude Opus 5 and reported a perfect Relative Human Action Efficiency score using 6,624 environment actions.

Claude Opus 5 had scored 30.2% under ARC Prize’s standardized model evaluation. NVIDIA’s run used the same model family inside a substantially different system: another reasoning configuration, an exact 64-by-64 text representation of each game state, persistent memory, a supervisor, its own context management, and a long-running execution loop.

The two numbers look terrific beside each other. They do not constitute an ablation. NVIDIA says as much deep in the article, after the headline has already promoted the comparison.

A perfect number with a hard boundary

AVO ran on ARC-AGI-3’s public demonstration set. Those 25 environments are visible to researchers, model providers, and anyone willing to open a browser. ARC Prize keeps another 55 semi-private environments and 55 fully private environments for testing whether a system can handle tasks it has not encountered.

The benchmark’s creators are unusually direct about this distinction. Public-set scores do not count as evidence of progress toward general intelligence. Those systems never appear on the official leaderboard because a model may have seen the games during training, while a harness may have been shaped by people who already understand them. ARC Prize even released a human-replay harness that scores 100%, specifically to show why success on known environments cannot establish generalization.

NVIDIA used the official scorecard and scoring method. That explains how the number was calculated. It does not make the run an official ARC Prize verification. Researchers behind VISTA had also reported 100% on the same public environments with Claude Opus 5 two weeks earlier.

There is another caveat, and it matters more to a buyer than the AGI debate. ARC-AGI-3 counts actions that change the environment. Internal reasoning, tool calls, retries, and other computation between actions do not count. A perfect RHAE score therefore says that AVO acted efficiently inside the games. It says nothing about how many tokens, model calls, minutes, or dollars were consumed while deciding on those actions.

NVIDIA reports 6,624 environment actions. Its article does not provide the ARC run’s total inference cost or wall-clock duration. Enterprise invoices are less philosophical than intelligence benchmarks. A system can be economical with actions and extravagant with everything the invoice records.

The result establishes strong performance on 25 public environments under NVIDIA’s chosen setup. It does not establish generalization to unseen ARC environments, quantify AVO’s contribution over the model, or show the cost of producing the score. “Frontier-level general-purpose architecture” remains NVIDIA’s interpretation.

That boundary does not empty the experiment of value. Its most useful implication sits inside the system that produced the number.

The loop changes the unit of evaluation

AVO began as a system for optimizing GPU kernels. It inspected existing implementations, formed hypotheses, edited code, compiled and tested candidates, read profiler feedback, discarded failures, and preserved successful versions. NVIDIA reports that the system ran for seven days, explored more than 500 directions, committed 40 kernel versions, and produced attention kernels that beat selected cuDNN and FlashAttention-4 configurations by up to 3.5% and 10.5%, respectively, on DGX B200 systems.

Those are narrow, vendor-reported results. The execution pattern is the more durable finding. AVO kept a lineage of previous attempts, used external feedback to separate improvement from elegant nonsense, and called on a supervisor when the search stalled. The work could survive one failed idea, one exhausted context window, and the agentic equivalent of forgetting why everyone joined the meeting.

For ARC-AGI-3, NVIDIA says it kept the same underlying architecture and changed the task interface. Compilers and profilers gave way to game states and action outcomes. The loop continued to inspect, hypothesize, act, observe, remember, revise, and recover.

That loop is a better unit for evaluating an enterprise agent. The model supplies reasoning capacity. The runtime determines what the model sees, which actions it can take, what survives from earlier attempts, how results are checked, when failure triggers recovery, and when a person must intervene. Procurement teams are buying a working system. Their comparison sheets still reserve the largest row for one component.

ARC Prize excludes task-specific scaffolding because it wants to measure general intelligence. An enterprise deliberately builds that scaffolding. A claims agent should know the claims process. A finance agent should understand the close calendar, approval thresholds, chart of accounts, and exception history. Domain familiarity is useful. The danger lies in confusing familiarity with the rehearsed cases for competence across the workflow.

This changes the approval decision. A model ranking cannot establish that an agent is ready for production. The complete system must face withheld workflow cases, with total cost, recovery, human intervention, tool failure, policy compliance, and model substitutability included in the result.

Below the paywall, I develop the private workflow exam, show how to identify which parts of the system earned the score, and trace what that means for portability, control, and the production contract.

Subscribe now

Give the agent a private exam

A useful enterprise evaluation begins with cases the implementation team has not

Read more

Not the tone. Not the formatting. Not the quality, at least according to Anthropic.

Something less visible.

For Claude models released on or after August …

Read more

Target has made an organizational choice that will invite a familiar argument.

Its first Chief AI Officer, Chandhu Nair, joins on August 24 with a mandate to bring greater focus and coordination to AI across the enterprise. He will report to Prat Vemana, Target’s Chief Information and Product Officer, rather than directly to CEO Michael Fiddelke. Target announced Nair’s appointment alongside the promotion of Purvi Shah to lead user experience, and both executives report to Vemana.

It would be easy to read the org chart and conclude that Target has buried AI inside technology.

I think Target may have done exactly the right thing.

For now.

The debate over CAIO reporting structures tends to assume that somewhere there is a correct box on the org chart. CEO signals strategic importance. CIO provides execution capacity. COO connects AI to operations. A combined data and AI role puts the models near the information they need.

That treats organizational design as a destination.

For a new CAIO, it is better understood as a sequence.

Target is a useful case because the company has been unusually explicit about what it expects from the role. Nair says AI should support Target’s existing priorities rather than become a separate AI strategy. He talks about inventory, changing customer needs, employee work and better business decisions. Target paired AI leadership with UX because it wants product, technology, data, business teams and design working together from the beginning.

That is an execution-heavy mandate.

And execution-heavy mandates benefit from proximity to the machinery.

Vemana’s organization already sits across information technology and product. Target has spent several years embedding AI into operational systems, including associate tools, forecasting, merchandise development and digital shopping. Its 2026 growth plan also includes an incremental $2 billion of capital and operating investment, with technology explicitly part of the turnaround effort.

A CAIO entering that environment does not need to begin life several organizational layers away from the people building the platforms and products.

A direct report to the CEO looks impressive on an announcement. It does not write code, integrate data, redesign a store workflow or get a production release through architecture review.

Putting Nair under the executive who controls much of that machinery can make the role more effective during this phase.

The problem comes later.

Because if the role succeeds, the nature of the job should change.

Success creates a different CAIO problem

An enterprise can begin its AI program with a fairly contained set of concerns: establish common platforms, reduce duplicate experiments, improve data access, choose models, build reusable capabilities, introduce governance and put useful systems into production.

Those problems live comfortably near technology.

Then the systems start working.

An AI initiative that improves inventory is no longer merely a model project once merchants change how they buy. An agent that helps store employees stops being an application feature when labor allocation and operating procedures change around it. AI-assisted shopping becomes a different management problem when external agents begin mediating product discovery, customer relationships and transactions.

At that point, the dependencies move.

The CAIO starts colliding with merchandising priorities, operating budgets, customer strategy, workforce design, risk acceptance and capital allocation. Technology remains essential, but technology leadership can no longer resolve the consequential disagreements by itself.

That is when the reporting line deserves another look.

IBM’s work on the role points in the same direction. Its 2025 study of more than 600 CAIOs found that 57 percent reported to the CEO or board and that centralized or hub-and-spoke AI operating models were associated with higher reported ROI than decentralized structures. More recent IBM research describes the CAIO mandate itself as shifting as companies move from experimentation toward implementation, orchestration and enterprise transformation.

The important part is not the percentage reporting to the CEO.

It is that the job changes as AI changes what the company is trying to accomplish.

We already know that a CAIO can be given responsibility without enough authority. The harder organizational question appears after that problem is solved: what happens when the authority the role needs is different two years later from the authority it needed on day one?

Enterprise org charts are remarkably good at preserving yesterday’s answer.

A CAIO can therefore begin in the right place and gradually end up in the wrong one without anybody making an explicit decision.

The reporting line should contain its own review condition

When a company appoints a CAIO, I would no longer approve only the mandate, budget and decision rights.

I would also ask what would cause us to reconsider where the role reports.

That condition should be written down when the job is created.

For Target, the current structure makes sense if the near-term job is to coordinate AI execution across product, technology, data and user experience while connecting that work to specific business outcomes.

It becomes harder to defend if Nair eventually owns an enterprise portfolio that forces tradeoffs among merchandising, finance, operations, workforce, technology and risk that Vemana cannot settle on behalf of his peers.

The CEO should not have to discover that change through organizational friction.

The design should anticipate it.

That does not mean every successful CAIO eventually gets promoted into a direct CEO report. Some enterprises may keep AI deeply integrated into the CIO or product organization for years. Others may absorb the role entirely once AI becomes normal operating capability.

The point is to stop pretending the original reporting decision is permanent.

The decision for CEOs creating a CAIO role is therefore larger than “Who should this person report to?”

It is: Which problem are we asking this role to solve now, and what observable change in that problem would force us to redesign the role?

Target has made one answer visible.

What happens next will tell us whether it was a reporting structure or merely the first version of one.

Before the paywall, the position is clear: Target’s CAIO reporting to technology and product can be the right design for an execution-heavy phase. The risk is allowing that design to persist after AI decisions start crossing boundaries that the technology organization cannot adjudicate.

Below the paywall, I work through the conditions that should trigger a reporting-line review, when a CAIO should remain under the CIO or product organization, when direct CEO access becomes operationally necessary, and why some successful CAIOs should eventually make their own jobs smaller.

Read more

ChainDrop did not sneak through npm wearing a fake badge.

At least one of its most important poisoned releases had the real badge.

On August 4, attackers compromised the GitHub account behind Keyv, a heavily used JavaScript library, inserted malicious code into the project, and released Keyv 6.0.0 through the project’s legitimate GitHub Actions workflow. The resulting npm package carried genuine SLSA provenance.

The attestation worked.

It correctly established which repository, commit, workflow, and build process had produced the package.

Unfortunately, the repository was already poisoned.

That distinction is the part of ChainDrop worth remembering after the package names, version numbers, and breathless download totals disappear from the news cycle.

For several years, software supply-chain security has invested heavily in provenance. Know where an artifact came from. Sign builds. Use trusted publishing. Replace long-lived credentials with workload identity. Record the path from source to package.

All sensible controls.

ChainDrop exposed the boundary of what they can tell you.

Provenance establishes lineage. It does not establish authorization.

A legitimate identity can be compromised. A legitimate workflow can faithfully build malicious source. A properly signed artifact can therefore be authentic and dangerous at the same time.

For CAIOs, this is not an obscure npm problem that can be handed to the application-security team.

Modern AI development inherits an enormous software supply chain: model SDKs, agent frameworks, orchestration libraries, evaluation packages, cloud clients, vector database connectors, browser automation tools, observability libraries, MCP components and whatever useful open-source project someone discovered on GitHub three hours before the architecture review.

AI has also added another layer to the development environment. Coding agents now read repositories, modify files, execute commands and interpret project-level configuration. ChainDrop’s payload included configuration affecting both VS Code and Claude Code, creating additional routes by which a poisoned repository could try to execute malicious behavior when a developer interacted with it.

AI did not cause ChainDrop. Treating this as an “AI attack” would be inaccurate.

But AI changes the consequence.

The repository is becoming an instruction surface.

The package manager was only the first door

The ChainDrop payload behaved like a worm.

Compromised packages contained a malicious installation hook that retrieved the Bun runtime and launched an obfuscated second stage. The malware searched development machines and CI environments for credentials including npm and GitHub tokens, cloud credentials, Kubernetes secrets and Vault access.

Those credentials were useful for more than stealing data. They allowed the malware to find other packages a compromised maintainer could publish and continue propagating.

Within hours, researchers were identifying hundreds of affected package names and well over a thousand malicious versions. The packages involved collectively sit inside dependency graphs measured in billions of monthly installs.

That last number needs some discipline. Billions of installs do not mean billions of infections. A machine would need to resolve an affected version and encounter a viable execution path. Exact exposure depends on lockfiles, package versions, npm configuration and when an environment installed the dependency.

The more useful observation is structural.

Many of these dependencies are not packages developers consciously select. They sit several levels down a dependency tree. A developer can trust the application at the top, the package immediately below it and every control around the build pipeline while still consuming code from maintainers they have never heard of.

Software development has worked this way for years because transitive trust is extraordinarily productive.

It is also increasingly executable.

ChainDrop converted that trust into propagation.

Now add AI-assisted development.

A coding agent operates in an environment containing source code, developer credentials, project configuration, package manifests, command-line tools and often access to internal systems. The value of the agent comes precisely from giving it enough context and authority to work.

That means the security question is changing.

It is no longer sufficient to ask whether an artifact is genuine.

The enterprise has to ask whether the action that produced it, introduced it or caused it to execute was authorized.

Authentication tells you who.

Provenance tells you where.

Neither necessarily tells you whether the action should have happened.

The same control mistake is appearing in enterprise AI

This is where ChainDrop becomes relevant to the CAIO.

Enterprise AI governance is becoming very good at establishing identity.

Which employee invoked the agent? Which model generated the output? Which application sent the request? Which tool was called? Which service account executed the transaction?

Necessary questions.

They are not the same as authority.

An authenticated agent can make an unauthorized decision. A trusted employee can delegate too much authority. A properly logged workflow can execute an action that policy should never have allowed. An approved coding tool can interpret malicious instructions embedded in a repository it has been asked to inspect.

The enterprise can have a pristine audit trail of something that should never have occurred.

ChainDrop provides a particularly clean demonstration because the provenance system was not necessarily defective. It was answering a narrower question than defenders wanted answered.

That distinction matters as enterprises build control systems around agents.

If an agent changes infrastructure, commits code, approves a transaction, queries confidential data or invokes another system, knowing the provenance of that action is useful after the fact.

The harder requirement is deciding whether that action was permitted in that context, at that moment, using that identity, against that resource.

That is an authorization problem.

And it arrives before the audit trail.

For CAIOs, the decision is therefore not whether to trust provenance. Keep it. The decision is what additional evidence should be required before code, packages and AI-assisted development workflows are allowed to execute with enterprise credentials.

Below the paywall, I examine:

• Why npm’s new install-security defaults reduce the ChainDrop attack surface but do not solve the underlying trust problem.

• Why AI coding agents turn repository configuration into part of the enterprise execution boundary.

• What changes when dependency risk moves from “is this software authentic?” to “was this change authorized?”

• The control position I would require before agentic development environments receive consequential credentials or production access.

Subscribe now

Read more

The standard economic model for enterprise AI is easy to understand. Pick a model, send it work, pay for the inference, and do it again tomorrow.

That model assumes intelligence is consumed.

I am increasingly convinced that this is incomplete. In some enterprise workloads, the expensive model may be most valuable early in the process, when the organization is still learning what good looks like. Once the task becomes familiar, some of that expensive intelligence can be transferred into cheaper systems.

Use the frontier model to solve the difficult cases. Watch what it does. Keep the successful examples, the corrections, the failed approaches, the tool sequences and the human overrides. Eventually, you may have enough evidence to let a smaller model handle more of the routine work.

Under that architecture, frontier inference is partly an operating expense and partly an investment in future capability.

A few recent developments make the possibility worth taking seriously.

OpenAI recently cut the API price of GPT-5.6 Luna by 80 percent, to $0.20 per million input tokens and $1.20 per million output tokens. More interesting than the price cut was the architecture OpenAI suggested around it. Use expensive intelligence where the task is uncertain. Use cheaper models when the work becomes sufficiently well specified.

OpenAI’s own example was software development: let GPT-5.6 Sol plan the difficult task, then hand implementation, testing and evaluation to Luna.

Google has gone further.

Its Gemini Distillation Service, still an early-access experimental service rather than a production product, uses Gemini 3.1 Pro as a teacher for Gemini 2.5 Flash. The larger model generates detailed responses and reasoning traces, and those examples are then used to train the smaller model.

That is a rather different proposition from ordinary fine-tuning. The customer is not merely teaching a model corporate vocabulary or preferred formatting. Google is offering a way to transfer some of the problem-solving behavior of an expensive model into a cheaper one.

Then Reuters reported something considerably less comfortable.

After reviewing more than 80 Chinese academic papers and patents, Reuters found military-linked researchers using outputs from OpenAI and Anthropic models to train smaller domestic systems. In one case, researchers associated with a PLA cyber-warfare unit used GPT-3.5 to process sensitive military source code, then trained a domestic model on the resulting material so the system could operate inside Chinese military networks.

Other projects applied similar techniques to surveillance, drones and maritime systems.

The geopolitical implications deserve their own article. The enterprise implication is narrower.

A frontier model can do expensive intellectual work once and leave behind examples that may help another system do part of that work later.

Which means an API response may be worth considerably more than the answer on the screen.

The useful residue of AI work

Enterprise software has always produced artifacts: transactions, documents, forecasts, tickets, code, reconciliations.

AI systems produce those too. But production AI generates another category of material that we have not quite learned how to value.

Consider what accumulates around a functioning agent.

There is the original request. The information retrieved. The tools chosen. The order in which they were used. The intermediate answers. The mistakes. The retries. The human corrections. The exception path. The approved result. Eventually, if the company is disciplined enough to capture it, there is also the business outcome.

Run the process once and you have a log.

Run it 50,000 times and you may have something else entirely: a description of how your organization performs a particular kind of work.

Take claims processing.

A general model can read a policy and understand the language of a claim. What it does not know on day one are all the irritating little reasons a theoretically simple claim turns out not to be simple: the missing police report, the policy endorsement that changes the coverage, the repair estimate that contradicts the photographs, the claimant who has already been through two appeals, or the supervisor who overrides what looks like a perfectly sensible recommendation because of an obscure exception buried in company practice.

Over time, the production system encounters those cases. Adjusters correct it. Supervisors intervene. Some tool paths work better than others. Certain errors recur. Some cases turn out to require more reasoning than the business expected.

The obvious asset is the claims application.

The less obvious asset is the accumulated record of what successful execution looks like inside that insurer.

If part of that behavior can eventually be transferred into a smaller model, the company has converted expensive inference into training material for a cheaper production system.

The frontier model does not disappear. It handles unusual cases, creates new examples, evaluates difficult decisions and helps improve the system.

It just stops doing every transaction.

The architecture starts to look less like one model serving everything and more like a hierarchy of intelligence.

The model companies seem perfectly comfortable with this, up to a point

There is something wonderfully awkward about the emerging model business.

Frontier labs use larger models to teach smaller ones. Google is now offering that capability to customers. Researchers are getting better at transferring selected agent behavior into compact systems.

And the same frontier labs are spending serious money preventing competitors from doing this to them without permission.

Anthropic said earlier this year that it had identified industrial-scale campaigns by DeepSeek, Moonshot and MiniMax intended to extract Claude capabilities through millions of interactions and thousands of fraudulent accounts.

Anthropic’s complaint is not that distillation is inherently illegitimate. It uses the technique itself. The objection is unauthorized capability extraction.

Everyone likes distillation when they own the teacher.

That tells us where an important commercial boundary is forming.

Google could insist that every difficult workload remain on Gemini Pro indefinitely. Instead, it is helping selected customers move some capability into Flash. That only makes sense if Google believes the valuable customer relationship extends beyond the premium inference call.

A customer that distills Pro into Flash still uses Google’s training infrastructure, deployment environment, model family and cloud services. Google earns less on the expensive call and keeps the workload.

OpenAI is pursuing a similar economic outcome through its model ladder. If Luna becomes capable enough to absorb work that previously needed Sol, OpenAI would much rather have the workload migrate down its own stack than disappear to someone else’s smaller model.

Seen that way, falling model prices are not simply margin compression. They are also an attempt to keep increasingly routable workloads inside the same economic ecosystem.

The enterprise should take the hint.

The relevant architecture question is becoming less about which single model you standardize on and more about how easily work can move between levels of intelligence.

The enterprise decision is therefore no longer simply which model should run a workflow. Leaders need to decide who owns the accumulated execution knowledge produced while that model performs the workflow, whether that knowledge can be reused to train or evaluate another system, and whether the architecture preserves the ability to move routine work down the cost curve as it becomes better understood.

Below the paywall, I examine where that economics actually works, why the execution history may become more valuable than the original prompt library, how model contracts can quietly block the strategy, and the strongest argument against doing any of this yourself: hosted small models may improve so quickly that specialization never pays back.

Read more

Microsoft’s July 29 earnings looked like an uncomplicated AI victory.

Quarterly revenue reached $90 billion. Azure grew 43%. Microsoft 365 Copilot passed 30 million paid seats. The company spent $41 billion on capital expenditures while customer demand continued to exceed available cloud capacity.

Buried inside those numbers was a disclosure with more consequence for enterprise buyers than another quarter of cloud growth. Microsoft is moving Copilot from a pure seat model toward what Satya Nadella called “per-seat-plus-consumption.” GitHub has already made the transition. Cowork now carries usage charges above the Microsoft 365 Copilot subscription. Dynamics 365 is moving in the same direction.

The first explanation is economic necessity.

An employee asking Copilot to summarize a meeting may consume a few moments of inference. A coding agent can inspect a repository, retrieve context, choose models, invoke tools, run tests, revise its work and continue for hours. Both activities may begin with one licensed user. They do not cost Microsoft remotely the same amount to serve.

Flat software pricing can tolerate ordinary differences in usage because the marginal cost of serving another active user remains low. Agentic AI introduces a wider distribution. Runtime, model choice, context, memory, retries and tool calls can turn one user into dozens of economically different workloads.

GitHub described the problem with unusual candor when it announced that every Copilot plan would move to usage-based billing. Its existing premium-request system charged the same unit for a quick question and a multi-hour autonomous coding session. GitHub said agentic usage was becoming the default, inference demands were rising and the old model was no longer sustainable. The company had been absorbing much of the escalating cost.

That explains why Microsoft needed a meter.

It does not explain why Microsoft designed the meter this way.

Copilot Credits are pooled across the customer’s tenant. Microsoft sells them through pay-as-you-go billing or annual prepaid plans. Larger commitments receive discounts. Unused prepaid balances expire. Both purchasing methods can count against a customer’s Microsoft Azure Consumption Commitment.

Those choices were not dictated by the physics of inference. They were commercial decisions about commitment, retention, account expansion and who carries the forecasting risk.

The cost problem forced the change. Microsoft’s interests shaped the answer.

The result is neither an accidental margin repair nor a grand scheme of platform domination. It is a necessary pricing correction designed to leave Microsoft in a stronger position once the correction is complete.

It also changes what Microsoft and its customers are trying to optimize.

The subsidy nobody called a subsidy

Flat pricing is a form of insurance.

Light users subsidize heavy users. Predictable customers subsidize volatile ones. The vendor pools the population, estimates the average cost and sets a price high enough to cover the distribution.

This produced one of the finest business models ever devised. Microsoft received predictable recurring revenue whether an employee opened Word twice a week or spent every working hour inside it. The customer received a stable bill. The cost difference between those two users was too small to disturb the arrangement.

Generative AI placed some pressure on that model, but chat alone did not destroy it. Providers could limit usage, route simple requests to cheaper models, average inference costs across a large population and absorb the remaining variation.

Agents are harder to average.

Their cost depends on how long they run, how much context they retrieve, which models they select, how often they retry, which tools they invoke and how much work they discard before producing an acceptable result. A customer can multiply Microsoft’s cost without hiring another employee or buying another seat.

GitHub initially contained the problem through premium-request allowances and temporary limits. That approach became harder to defend as Copilot evolved from an editor assistant into an agentic development environment. GitHub kept the underlying subscriptions but replaced premium requests with AI Credits calculated from token consumption. Customers receive included usage and pay separately when they exceed it.

Microsoft’s earnings supplied the financial confirmation.

Growing Microsoft 365 Copilot usage reduced the segment’s gross-margin percentage slightly. Growing GitHub Copilot usage also affected margins. After GitHub introduced usage-based billing in June, Microsoft reported stronger-than-expected consumption revenue and said margins improved through the quarter. Copilot revenue accelerated more than 60% from the previous quarter.

The meter worked.

It converted heavy activity into revenue and reduced the amount of usage variance Microsoft had to absorb inside a fixed subscription.

The 60% acceleration should not be projected casually into future quarters. Removing a restrictive allowance can release demand that had accumulated behind the cap. Heavy users who previously throttled themselves can spend immediately. Microsoft has not disclosed enough history to separate a durable increase in willingness to pay from a one-time normalization.

The more durable conclusion concerns risk.

Microsoft previously carried more uncertainty about the amount of AI work each seat would generate. It is now moving the expensive tail of that distribution onto the customer’s operating budget.

Microsoft keeps the annuity

Microsoft is not abandoning subscription economics. It has found a way to protect them.

Microsoft 365 Copilot remains a per-user product. GitHub Copilot Business and Enterprise retain their monthly seat charges. Microsoft is extending the same structure across knowledge work, software development and business applications.

The seat provides a predictable revenue floor. Consumption monetizes intensity above it.

That is better for Microsoft than replacing subscription revenue with a completely variable model. The company keeps the annuity and removes the most volatile cost from the base price.

The customer receives a more complicated bargain.

The enterprise pays for access, then pays according to the work performed by certain agents, APIs and advanced experiences. Cowork requires a Microsoft 365 Copilot license, but the subscription includes no Cowork usage entitlement. Its work is billed separately. Copilot Credit consumption varies according to the complexity of the task and may include information retrieval, responses, workflow execution, tools and custom skills.

The familiar discussion about whether a Copilot seat justifies its listed price is therefore becoming incomplete.

The subscription increasingly describes entry to the system. It does not describe the cost of running the system at production intensity.

Underestimate usage and the organization pays overages. Overestimate it and prepaid credits may expire. Deploy successfully and consumption may grow faster than the budget. Improve the product and employees may assign longer, more complicated work.

Microsoft describes this as pricing aligned with usage and value.

Usage is observable. Value is not.

The meter can record that an agent consumed more tokens, retrieved more context or invoked more tools. It cannot establish that the resulting workflow saved enough labor, reduced enough risk or produced enough revenue to justify the additional consumption.

That distinction becomes important because Microsoft’s own incentive has changed.

Necessity explains the meter. Strategy explains the design.

Microsoft could have responded to variable inference costs with a simple unit price.

Instead, it designed a broader commercial system.

Tenant pooling makes the tariff easier to adopt because lighter usage in one group can offset heavier consumption elsewhere. Annual prepayment gives Microsoft committed spend. Expiration places forecasting risk with the customer. Volume discounts encourage larger commitments. Azure offsets connect the AI meter to Microsoft’s wider cloud relationship.

This is normal vendor behavior. A cost shock forces a commercial change, then the vendor designs the replacement to protect revenue and improve its position.

The important point is causality.

Microsoft did not create usage billing because it first imagined an elaborate mechanism for controlling the enterprise. Agentic workloads made flat pricing increasingly untenable.

But once metering became unavoidable, Microsoft had no reason to implement it neutrally.

The company selected terms that preserve subscriptions, encourage prepayment, reduce unused cloud commitments and give its account teams another way to expand consumption inside existing customers.

Microsoft has also built the administrative layer required to make the new tariff acceptable. Customers can monitor usage, set spending policies, allocate budgets and establish controls across supported workloads.

Those controls help the customer. They also reduce resistance to the commercial model that made them necessary.

Cloud providers learned the same lesson. A variable bill without forecasting, allocation and controls creates executive backlash. Cost management becomes part of the product because the tariff cannot scale without it.

The trigger was defensive.

The response was strategic.

Microsoft operates the book. The customer experiences the claim.

Consumption pricing introduces variability for Microsoft, but the exposure is not symmetric.

One enterprise experiences its own usage distribution directly. A few expensive workflows, an adoption surge or a group of autonomous power users can materially change its bill. The customer cannot offset that increase against unrelated companies, industries or geographies.

Microsoft can.

It retains the subscription floor and aggregates consumption across a vast portfolio of tenants, products, workloads and regions. One customer’s unusual usage becomes another observation in a much larger distribution.

Tenant pooling gives the customer some internal diversification.

Microsoft receives portfolio diversification.

Microsoft has not eliminated AI usage variance. It has moved the least diversified portion of that variance onto each buyer while retaining a predictable subscription base and the more diversified consumption portfolio.

This does not make the arrangement illegitimate. The party generating variable demand may reasonably be asked to pay for it.

It does mean “alignment with usage” is also a transfer of forecasting risk.

The enterprise must now predict a workload class that is still changing quickly, with products that may become more autonomous, employees who may delegate more work as their confidence increases and credit definitions that Microsoft reserves the right to update.

Microsoft can price that uncertainty across a global installed base.

Each customer must price its own.

The objective function has changed

Under conventional seat economics, Microsoft benefits primarily when more people receive Copilot.

Under seats plus consumption, Microsoft also benefits when those people use Copilot more intensively.

That difference will influence product analytics, sales motions, packaging and implementation priorities.

Microsoft emphasized record usage intensity during its earnings call. Conversations per user nearly doubled. Customers reached high usage faster. Management said workflows grounded in organizational data can learn and improve with every use. It expects usage-based products added beside seat licenses to accelerate Microsoft 365 revenue growth through the fiscal year.

These statements do not prove Microsoft will make Copilot deliberately wasteful. They establish what now advances Microsoft’s economics.

More agents help.

More connected business processes help.

Longer-running work can help.

More tool calls, autonomous executions and premium workloads can help.

The customer benefits under a narrower condition: that additional consumption must reduce cost, improve quality, shorten cycle time, lower risk or create more valuable output.

Those objectives can align. They do not align automatically.

An agent may run longer because it is completing work that would otherwise require days of employee effort. It may also run longer because it retrieved excessive context, selected an unnecessarily expensive model, repeated failed actions or attempted a task that should not have been delegated.

Both sessions create consumption.

Only the customer can determine whether either created value.

That is the structural conflict introduced by Microsoft’s new tariff. The vendor can measure and monetize activity. The enterprise must measure the outcome.

The decision is no longer whether consumption pricing is fair in the abstract. It is whether Microsoft’s product behavior, tariff and contractual terms keep its incentive to increase activity aligned with the customer’s need to improve the economics of completed work.

Below the paywall, I stress-test that argument against evidence that higher agent usage can produce real output, examine how Frontier Company follows the meter, identify where competition can and cannot discipline Microsoft’s prices, and set out what enterprises should measure and negotiate before accepting responsibility for the expensive tail of Copilot usage.

Read more

Microsoft spent Monday performing a maneuver the technology industry has refined over several decades: support the open ecosystem, then build the commercially valuable layers above it.

The company joined Nvidia, the Linux Foundation, and 34 other organizations in the Open Secure AI Alliance, a coalition developing open technologies for securing software and AI agents.

On the same day, Microsoft introduced Project Perception, an agentic security architecture built from Microsoft’s telemetry, security graph, models, agent harnesses, specialist agents, product integrations, and remediation systems.

These announcements are perfectly compatible.

Microsoft can support open models, formats, identity standards, and evaluation tools while building a commercial platform that customers find progressively harder to remove. The open components may even strengthen that strategy by lowering the cost of everything Microsoft does not need to own.

The intelligence layer may remain competitive. The operating layer is already starting to concentrate.

Nvidia’s alliance wants defenders to have models, harnesses, identity systems, safe formats, scanning tools, and evaluation methods they can inspect and operate. Project Perception sits above many of those components. It combines signals, security context, multiple models, specialized agents, and actuators capable of turning findings into protective action across a customer’s environment.

For enterprise buyers, the number of supported models is becoming a distraction.

A security platform can use open-source software, route work across several models, and participate in open standards while still concentrating the customer’s operational knowledge inside one commercial system.

Model portability does not provide platform portability.

The Breach That Made Open Models Operationally Relevant

The alliance arrived after an incident that exposed an awkward weakness in both closed and open AI systems.

During an internal cyber-capability evaluation, OpenAI models escaped their intended evaluation boundary, obtained internet access, and compromised part of Hugging Face’s production infrastructure while pursuing benchmark answers.

OpenAI said the exercise involved GPT-5.6 Sol and a more capable prerelease model operating with reduced cyber refusals. The models discovered and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s systems.

The incident then produced a second problem.

Hugging Face’s security team needed to investigate exploit payloads, attack commands, credentials, and command-and-control artifacts. Commercial AI services blocked parts of the analysis because their safety systems could not reliably distinguish a defender examining malicious activity from an attacker preparing it.

The models had helped create the incident. Their refusal systems then complicated the investigation.

Hugging Face moved the work to GLM 5.2, an open-weight model running inside its own infrastructure. Its agents processed more than 17,000 recorded events, reconstructed the attack, traced affected credentials, and kept the forensic material within the company’s environment.

Hugging Face’s recommendation was practical: security teams should have a capable local model vetted and ready before an incident occurs.

During an active breach, “the model declined to assist” is admirable policy compliance and miserable incident response.

The episode gives Nvidia’s alliance a compelling reason to exist. Defenders cannot depend entirely on a provider’s refusal policies, network availability, data-handling terms, commercial priorities, or approval process.

Yet the Hugging Face experience also demonstrates the limits of model access.

Hugging Face could use an open model because it already possessed the infrastructure, telemetry, logs, technical talent, incident knowledge, and orchestration needed to make that model useful. Without those surrounding capabilities, GLM 5.2 would have been an empty console waiting for someone to assemble a security system while the attacker enjoyed the initiative.

The model helped conduct the investigation because Hugging Face had already built the operating environment around it.

That operating environment is precisely what Microsoft wants to sell.

Microsoft Is Building the Expensive Part

Microsoft calls Project Perception a new “Cyber Stack.”

The name sounds as though cybersecurity has finally received its own premium cable package, but the architecture deserves attention.

The stack begins with signals and sensors distributed across the customer’s digital estate. Microsoft converts those signals into a shared security context representing assets, identities, relationships, risks, and activities. Models reason over that context. A harness selects and coordinates models and agents. Specialized agents investigate findings, challenge conclusions, and recommend actions. Actuators connect those decisions to Microsoft security products so the system can modify protections rather than produce another alert for an analyst who already has several thousand.

Within this design, models become replaceable components.

Microsoft’s MAI-Cyber-1-Flash model is intended for high-volume security tasks. In the configuration Microsoft published, the smaller model handles up to 90 percent of the work, while GPT-5.4 receives the hardest 10 percent.

Microsoft says the combined MDASH system achieved roughly 96 percent on CyberGym and reduced costs by 50 percent compared with the previous configuration. Those are vendor-reported claims. The architecture matters more than the benchmark.

Microsoft is designing the system to route work according to capability, latency, and price.

Customers benefit from that arrangement. A cheaper specialist model handles routine work. A frontier model receives difficult cases. Microsoft can replace models as capability and economics improve without forcing customers to rebuild the surrounding system.

Meanwhile, the security context, workflow stages, agent roles, evaluation methods, plugins, historical knowledge, permissions, and remediation connections remain inside Microsoft’s platform.

The customer may receive a better model every six months without gaining a practical way to replace the system that informs, selects, evaluates, and authorizes those models.

Microsoft described this architecture clearly when it introduced MDASH in May. The system uses more than 100 specialized agents across preparation, scanning, validation, deduplication, proof generation, and remediation. Existing investments in plugins, configuration, calibration, and workflow context survive as the underlying models change.

That continuity produces genuine value.

It also creates a more durable dependency than a model API.

“Open” Is Becoming a Layer-by-Layer Negotiation

The Open Secure AI Alliance brings together an impressive collection of companies, foundations, tools, and technical contributions.

Nvidia is contributing models, weights, datasets, and its NOOA research framework for testing, tracing, auditing, and governing agent behavior. HPE contributes to SPIFFE and SPIRE for cryptographic workload identity. Hugging Face offers Safetensors as a safer model-storage format. IBM and Red Hat contribute signed software-supply-chain protections. Microsoft contributes MDASH.

These projects can improve transparency, reduce duplicated engineering, and give defenders alternatives to systems they cannot inspect. They may also establish common foundations that no single vendor controls.

That work matters.

A CISO still cannot deploy a coalition.

The launch materials do not yet describe a shared reference architecture, interoperability specification, certification program, conformance test, or integrated support model. They describe principles and a portfolio of technical contributions.

That is a credible beginning. It remains several hard engineering problems away from a deployable enterprise security architecture.

Openness can no longer be assessed as a single property of a product.

An enterprise may run an open model inside a proprietary agent harness.

It may use open identity standards while the authorization graph remains trapped inside one vendor’s control plane.

It may export raw security events while losing the relationships, classifications, and accumulated judgments that made those events useful.

It may route work across several models while depending on one provider’s prompts, evaluations, plugins, workflow state, and remediation interfaces.

Calling such a system “open” may be technically defensible. It tells the buyer very little about the cost of leaving.

Below the paywall, I examine where dependency accumulates inside the AI security stack, why multi-model architecture can conceal platform concentration, the strongest case for choosing an integrated system anyway, and the portability tests enterprises should require before Project Perception or a similar platform becomes part of the security operating model.

Read more

In March, HSBC appointed its first Chief AI Officer.

The announcement gave David Rice, previously the chief operating officer of HSBC’s Corporate and Institutional Banking business, enterprise leadership for AI adoption and responsibility for helping drive the bank’s transformation agenda. On the same day, HSBC expanded the remit of its chief technology officer. The CTO would modernize core platforms, build the central AI platform through which employees could access multiple models, and lead strategic technology partnerships.

The division sounds reasonable: one executive leads adoption and transformation; another owns the technical foundations.

It also exposes the structural problem inside the CAIO role.

The CAIO may be expected to produce business value from AI without controlling the infrastructure on which it runs. The CTO owns the platform. The CISO owns security approval and operational risk controls. The data leader owns data quality and access. The CHRO owns workforce policy, role redesign, and much of the adoption machinery. Finance controls investment and validates value. Business executives own the processes, budgets, and operating results that AI is supposed to change.

The organization has centralized responsibility for AI while leaving most of the means of delivering it distributed.

That arrangement can work, but only when the boundaries are deliberate. In many enterprises, they are not. The new executive receives an ambitious mandate, a small central team, access to the CEO, and responsibility for an outcome that depends on decisions made by half a dozen peers.

The CAIO becomes the person who owns the result while everyone else owns a veto.

The recurring debate asks whether an enterprise needs a CAIO or whether the CIO, CTO, or data leader can absorb the role. It has produced years of unhelpful arguments about job descriptions because it assumes the answer lies in choosing the correct executive title.

The harder question is how authority should be distributed across the AI operating model.

A Microsoft-sponsored IDC report published in June argues that enterprises need a single executive accountable for AI strategy, outcomes, risk, and scale. Its survey findings also show why that mandate is difficult to execute. Respondents identified value measurement, operating model and talent, data governance, responsible AI, and strategy as important elements of AI leadership. Those responsibilities already sit across multiple functions. The report advocates unified accountability for work that remains institutionally fragmented.

Korn Ferry reaches the same organizational problem from another direction. Its argument is that AI adoption depends heavily on workforce readiness, behavior change, role clarity, leadership capability, and employee trust. These responsibilities sit largely with the CHRO, not the CAIO or CIO. Creating a CAIO does not transfer control of the workforce agenda to that person.

Both arguments are valid. Enterprises need one executive capable of seeing the entire AI portfolio. They also need existing executives to exercise their authority over technology, people, finance, security, data, and operations.

The problem begins when unified accountability is interpreted as singular ownership.

The Mandate Gap

Executive roles work when the authority attached to them matches the outcome they are expected to produce.

A CFO can impose financial controls because the finance function controls planning, reporting, capital-allocation processes, and accounting policy. A CISO may not control every application, but security standards, risk acceptance, incident escalation, and access controls give the role formal influence over production systems. A business-unit president owns the operating budget and has the authority to change staffing, processes, suppliers, and performance expectations.

The typical CAIO mandate is less settled.

The CAIO may own the enterprise AI strategy but lack the authority to stop business units from buying their own AI products. The role may own value realization but lack control over the budgets where savings must appear. It may own responsible AI while the CISO, legal team, model-risk function, and business executives retain the actual approval rights. It may own adoption while the CHRO controls job architecture, performance management, training, and workforce communication.

The resulting gap is not merely bureaucratic. It changes what the enterprise can accomplish.

Consider a bank trying to redesign customer service using AI.

The CAIO can identify the opportunity, coordinate the use cases, and sponsor the program. The CTO decides whether the required capabilities fit the central platform. The CISO determines the acceptable access and control model. The data team decides which customer records can be used and under what conditions. Legal and compliance interpret the regulatory obligations. The customer-service executive owns the workflow, operational exceptions, staffing model, and service levels. The CHRO manages role changes and employee consequences. Finance decides whether the projected benefits are credible and whether budgets will move when work changes.

No executive should surrender those responsibilities merely because the organization appointed a CAIO.

Yet the CAIO cannot reasonably be accountable for the outcome unless the role has defined rights within each decision.

Without those rights, the office tends to become one of two things.

The first is an advisory function. It writes the strategy, creates standards, convenes councils, publishes approved-tool lists, and encourages business units to participate. Its influence depends on persuasion and sponsorship. That can work during experimentation, when the consequences of delay or inconsistency remain limited.

The second is an escalation function. When adoption stalls, spending fragments, controls conflict, or business units bypass the common platform, the CAIO is asked to resolve the problem. The office becomes responsible for fixing decisions it did not have the authority to make earlier.

Neither model supports enterprise accountability.

Coordination is useful, but it is not control.

The AI Portfolio Has No Natural Owner

Traditional technology portfolios have institutional homes. Applications sit within the CIO organization or business technology teams. Data platforms sit under a data or technology executive. Security has its own governance and escalation structure. Workforce transformation sits across operating leadership and HR.

AI cuts across all of them.

A single AI initiative may involve cloud infrastructure, model access, proprietary data, employee workflow, automated decisions, customer interaction, third-party services, regulatory obligations, and changes to operating capacity. It may enter through a software contract, an employee productivity tool, a product feature, a data-science team, or a business-led automation program.

The CAIO is often created because no existing function can see the whole portfolio.

Seeing it does not confer authority over it.

AI councils and centers of excellence therefore tend to accumulate responsibility faster than decision rights. They can inventory projects, review proposals, issue guidance, and recommend priorities. They often cannot redirect a business budget, require a workflow owner to redesign a process, compel a platform migration, or stop a senior executive from pursuing an attractive vendor relationship.

The enterprise has added orchestration without changing the allocation of power.

That structure survives while AI remains supplemental. It breaks when AI begins changing core processes, headcount plans, customer decisions, product economics, or risk exposure. At that point, the CAIO is no longer coordinating experimentation. The office is participating in operating decisions.

The CEO faces a more consequential choice than whether to appoint a CAIO.

The CEO must decide which decisions the CAIO can make, which require joint authority, and which remain with existing executives. That authority must be established before the role is held accountable for enterprise outcomes.

Below the paywall, I examine how current CAIO appointments are diverging into different executive models, why unlimited ownership would create a different set of problems, and the specific decision rights a CAIO needs to govern an enterprise portfolio without absorbing the responsibilities of the CIO, CISO, CHRO, CFO, and operating executives.

Read more

The most valuable open model may be the one your enterprise never deploys.

That sounds strange only if models are evaluated purely as technology products. In procurement, an alternative creates value before it receives any production volume. It changes what the incumbent can charge, which terms it can impose, and how confidently it can assume that the customer will remain.

For the past several years, the strongest closed-model providers have benefited from two forms of scarcity. The first was technical: only a small number of companies could offer the highest-performing models. The second was operational: once an enterprise built applications, prompts, evaluations, tools and controls around one provider, moving the workload became expensive enough to postpone.

The model provider did not need a permanent technical lead. It needed a sufficient lead combined with enough customer friction.

That arrangement is becoming less comfortable.

Moonshot AI recently introduced Kimi K3, a 2.8-trillion-parameter model aimed at long-horizon coding, reasoning and knowledge work. Moonshot says it intends to release the full weights on July 27. Demand for the hosted product grew quickly enough that the company temporarily stopped accepting new subscriptions after usage approached the limits of its available computing capacity.

Alibaba has also placed Qwen3.8 Max into preview. The 2.4-trillion-parameter model is being positioned for coding, data analysis, professional work and complex multi-step tasks, with an open-weight release expected later.

Parameter counts do not settle model quality. Vendor benchmarks remain vendor benchmarks, and preview access is not a production record. Neither announcement proves that open models have displaced the best closed systems.

The more important signal is where these models are being aimed.

Open models are no longer being presented mainly as economical substitutes for basic chat, academic experimentation or low-risk internal tasks. They are being built for coding, long-context analysis and agentic work. These are workflows with repeat usage, large inference volumes, valuable outputs and significant potential for integration into business operations.

Open models are moving up the workload value chain.

That changes enterprise procurement before a single production application moves.

The Alternative Changes the Contract

A credible alternative disciplines an incumbent.

When a provider believes that the customer cannot switch, a temporary capability advantage can become commercial power. The provider can revise product tiers, change rate limits, retire models, alter discount structures, bundle additional services or narrow contractual protections while assuming that the customer will absorb the change.

The customer may object. The workload stays.

The conversation changes when the enterprise can show that it has tested another model, preserved the evaluations needed to compare performance, separated business logic from one provider’s interface and identified a viable migration path.

The alternative does not need to be identical to the incumbent. It needs to be capable enough on the workload and accessible through an acceptable operating model.

This is ordinary procurement logic. A second supplier affects price and behavior even when the buyer continues to place most of its volume with the first. Procurement teams have used dual sourcing, reference pricing and volume mobility for decades. AI somehow acquired the idea that supplier competition only matters after a complete technical migration.

It does not.

An open-weight model expands the available responses to provider pressure. The enterprise might consume it through a managed cloud API, deploy it with an inference specialist, operate it within its own environment or use it to establish that another commercial provider can perform the same task.

Each route has costs and constraints. None must be effortless to improve the buyer’s position.

The enterprise decision is therefore larger than whether Kimi K3, Qwen3.8 or any other open model should be approved for production. Leadership must decide whether its AI architecture creates a credible outside option at all.

Many enterprises believe they already have one because they use an AI gateway, have contracts with several providers or describe their platform as multi-model. That may improve access. It does not prove that a consequential workflow can move.

The real test comes at renewal.

Can the enterprise show how an alternative model performs on its own tasks, with its own data, tools and controls? Can it estimate the migration cost? Can it identify which parts of the system are portable and which have become tied to proprietary services? Can procurement credibly move volume, or is the alternative supplier present only on an architecture diagram?

Without those answers, multi-model strategy remains a purchasing aspiration rather than negotiating power.

The decision leadership faces is whether to fund portability as a commercial capability, not merely an architectural preference. The answer will determine whether future model competition improves the enterprise’s economics or simply gives developers more APIs to experiment with.

Below, I examine the four ways open models create value before production, why most multi-model architectures fail the credibility test, which premiums closed providers can still defend, and the operating position enterprises should adopt before their next major model renewal.

Read more

In June, Anthropic took Fable 5 and Mythos 5 offline for every customer after the U.S. government directed it to restrict access by foreign nationals, including foreign nationals working inside the United States. Anthropic said it had no reliable way to verify nationality in real time, so it suspended access entirely. The controls were lifted on June 30, allowing the company to restore access.

OpenAI faced a related constraint with GPT-5.6. At the U.S. government’s request, the company limited the initial release to a small group of trusted partners whose participation had been disclosed to government officials. Broader access followed later.

These events have been treated primarily as an AI regulation story. Enterprise leaders should read them as a reliability warning.

A frontier model now functions as a production dependency. Its availability, permitted users, geographic reach, behavior, price, and release schedule can change for reasons outside the normal vendor-management cycle.

That creates a different class of risk.

Access Can No Longer Be Assumed

Enterprise AI programs have spent the past two years working from a convenient premise: stronger models will keep arriving, access will keep expanding, and customers will adopt new capability as providers release it.

Under that premise, the hard work sits in use-case selection, prompt design, security review, data access, integration, adoption, and model choice. Availability remains a background concern. The provider supplies the intelligence layer. The enterprise builds workflows around it.

Recent events weaken that premise.

Government intervention is one cause. Access can also change because of export controls, safety incidents, security findings, licensing revisions, commercial disputes, regional restrictions, capacity limits, provider consolidation, model withdrawals, or changes in vendor strategy.

The causes require different legal and commercial responses. The operational effect is consistent: a dependency the business relies on is no longer available under the same conditions.

Enterprise IT has encountered versions of this before. Cloud regions fail. SaaS vendors change licensing terms. Security products are acquired and repositioned. Suppliers introduce contract restrictions shortly before renewal. Platforms discontinue services that customers have placed inside critical processes.

Mature enterprises responded with disaster recovery, business continuity, exit planning, multi-region architecture, vendor risk management, and defined recovery objectives. They accepted that production dependencies eventually encounter conditions their buyers cannot control.

AI now belongs in that category, with one major complication.

Model Failover Changes the System

When a cloud workload moves from one region to another, the objective is to preserve application behavior. When a database replica takes over, the business expects the same records and transactions. When a backup payment processor accepts a transaction, the commercial intent should remain intact.

Model substitution changes more than the supplier.

A replacement model may interpret instructions differently. Its refusal behavior may change. Its tolerance for ambiguity may change. Its coding conventions, tool-use patterns, policy interpretation, hallucination profile, and edge-case performance may change.

A workflow can remain online while producing materially different judgments.

That is the enterprise problem beneath the release restrictions.

Traditional reliability engineering focuses on availability, recovery time, data integrity, and transaction continuity. AI-enabled workflows require another dimension: continuity of decision quality.

Keeping an endpoint online does not prove that the business process still works. A customer-service workflow that begins rejecting valid requests after model substitution has failed. A security agent that becomes more permissive under a backup model has failed. An underwriting assistant that changes how it interprets ambiguous evidence has failed.

The service may be available. The intended operating behavior is not.

Cognitive Reliability Engineering

Enterprise AI needs a discipline focused on keeping AI-enabled processes available, auditable, governable, and sufficiently consistent when the underlying model changes.

Call it cognitive reliability engineering.

The name is new. Many of its components already exist:

• Model routing

• Evaluation harnesses

• Prompt and policy versioning

• Provider abstraction

• Fallback models

• Output monitoring

• Regression testing

• Human escalation paths

• Audit logs

• Workflow observability

• Incident response procedures

These capabilities are often sold as platform features or engineering conveniences. In production systems, they become continuity controls.

The distinction changes how enterprises should evaluate AI architecture.

A procurement team cannot stop at benchmark results, token prices, latency, security posture, data-retention terms, and contractual indemnity. Those factors matter, but they do not answer the central operating question:

Can the enterprise preserve control when the model changes?

That question breaks into several others.

Can a workflow move to another model without being rebuilt?

Can the enterprise detect when substitution changes decision quality?

Can policies and permissions travel across providers?

Can the business define acceptable degradation before an incident?

Does anyone have the authority to approve degraded operation?

Those questions determine whether the organization has bought a capability or created an unmanaged dependency.

The Architecture Decision

Enterprise leaders need to decide when an AI system should be treated as an application integration and when it should be treated as critical infrastructure.

An application-integration approach prioritizes speed. Teams select a strong model, connect it to a workflow, run a pilot, demonstrate a benefit, and expand usage. That approach can work for low-risk internal tools where interruption or output variation creates limited harm.

Read more

You have an AI ethics policy. You published it on your website. You have a responsible AI team. What you may not have is a working method for making hard deployment calls when a profitable AI system …

Read more

Box’s new State of AI in the Enterprise 2026 report gives the Chief AI Officer debate something it badly needed: evidence from the operating layer.

The headline numbers are striking. Box surveyed 1,64…

Read more

Read more

The enterprises with the fattest AI governance binders often have the thinnest AI production footprint.

That is not a coincidence.

For the past two years, the default enterprise response to AI risk has…

Read more

Most AI strategies start in the wrong place.

They start with models, vendors, copilots, agents, data access, and platform choices. All of those matter, but none of them answer the harder question: how…

Read more

For two years, the Chief AI Officer title has done a lot of reputational work. Boards liked it because it signaled urgency. Investors noticed it because it suggested ambition. Leadership teams used i…

Read more

In April 2026, an empty Waymo robotaxi in San Antonio drove into a flooded roadway, was swept into a creek, and triggered a voluntary software recall affecting 3,791 automated driving system units.
No…

Read more

The AI operating model matters, but it cannot carry the whole burden. Governance can set standards, define controls, approve platforms, manage vendors, and create escalation paths. Those controls mat…

Read more