When Should Enterprises Reopen an AI Project That Failed the ROI Test?

Six months ago, an enterprise may have evaluated an AI workflow and decided the economics did not work.

The model was too expensive. Copilot licenses added another layer of software spending. Integration costs were high. Existing SaaS products still had to stay in place.

The project was rejected.

Should that decision still stand today?

That question matters more than another comparison of which AI model is cheapest.

OpenAI has lowered API pricing for its newer models. Anthropic has reduced the list price of Claude Opus 5.5 relative to its predecessor and says typical workload costs can fall further under its own usage assumptions. The Information has also reported that Microsoft is preparing larger discounts for high-volume Copilot purchases, potentially reaching about 30% for commitments above 1,000 seats and as much as 50% at very large volumes.

Those figures are not directly comparable.

OpenAI's numbers refer to model API pricing. Anthropic's claim of roughly 40% lower workload cost is not the same as a 40% reduction in list price. Microsoft's reported discounts concern negotiated enterprise purchasing terms, not a public 50% price cut available to every customer.

But taken together, they create a practical decision problem:

A rejected AI project is usually a rejection under specific conditions

Enterprises often record AI investment decisions in binary terms: Approve or reject.

But what was actually rejected was often not the workflow itself. It was the economics of that workflow under a particular set of assumptions.

Consider a company evaluating AI to help customer-service teams search internal knowledge, summarize conversations, and draft responses.

The project may have failed because Copilot licenses were too expensive, model usage costs were high, integration required additional spending, and the company still needed to retain its existing service software.

That decision could have been entirely rational.

But if six months later model costs have fallen, negotiated enterprise pricing has changed, usage-based pricing is more favorable, the AI system can cover more of the workflow, or some existing software costs can be reduced, then the company is no longer evaluating the same economic proposition.

The relevant change is not simply that AI became cheaper.

That creates an important distinction between two types of rejected projects.

One was rejected because the economics did not work.

The other was rejected because the operating conditions did not work.

If the problem was price, the decision may deserve another look when pricing conditions change.

If the problem was unusable data, unreliable output quality, regulatory constraints, unacceptable security risk, or lack of adoption, lower model prices may change very little.

A cheaper model does not solve a data-quality problem.

List price may no longer be the right number

Microsoft currently lists Microsoft 365 Copilot at $30 per user per month for enterprise customers.

But The Information has reported that Microsoft is preparing significantly larger discounts for high-volume purchases. If those terms are available under specific commitment levels, the actual price paid by a large enterprise could differ materially from the public list price.

That does not mean Copilot is now “half price.”

The highest reported discount may apply only to very large commitments, specific contract structures, or other negotiated conditions.

The more useful implication is narrower:

This increasingly resembles conventional enterprise software procurement.

The effective cost of AI can depend on seat commitments, contract duration, bundling, usage volume, and annual negotiation rather than a single price displayed on a website.

A simple calculation such as:

may therefore be a weak basis for deciding whether a workflow makes economic sense.

Lower model prices do not automatically improve ROI

There is an equal risk of making the opposite mistake.

Model or token cost is only one component of the economics of an enterprise workflow.

A more complete view may include:

• AI usage
• existing software
• human labor
• integration
• security and control
• error and rework

Suppose monthly model cost falls from $100,000 to $50,000.

That matters.

But if integration still costs $2 million, human review remains unchanged, no existing software can be removed, and the system introduces additional governance requirements, the business case may still fail.

The better question is not:

How much cheaper is the model?

It is:

For the same process, an enterprise might compare:

• people plus existing SaaS

• AI assisting existing SaaS

• AI reducing some manual work

• AI allowing fewer software seats

• AI taking over selected software functions

• or a redesigned end-to-end workflow

This changes the unit of comparison.

Instead of evaluating the price of one AI product, the enterprise evaluates the total cost of completing the work.

Let the findings determine the next decision

The same test can produce three materially different outcomes.

1. Existing controls cover the task. The agent's access matches the assignment, sensitive actions remain subject to effective approval, relevant activity can be traced, and cancellation prevents unauthorized subsequent steps.

In that case, a new vendor initiative is not, by itself, a reason to replace the current architecture. The enterprise can retain its controls and repeat the test when the agent gains new tools, permissions, or responsibilities.

2. A gap exists, but existing systems can close it. Supplier-data access may be too broad, or the purchasing workflow may allow submission without the required approval.

The appropriate next step is to examine whether permissions can be narrowed, approval conditions strengthened, or the workflow redesigned using existing capabilities. A configuration or process gap does not automatically justify a new platform.

3. Individual systems enforce their rules, but the complete task cannot be adequately traced or stopped. The enterprise may see each API call without being able to connect the sequence to its authorizing assignment. Or it may be unable to halt subsequent actions across systems after the task is canceled.

This finding provides a specific basis for evaluating additional integration or control capabilities. The requirement should identify the demonstrated gap: task traceability, coordinated authorization, execution controls, or another capability that the existing arrangement cannot adequately provide.

A vendor's claim that its product understands an agent's “intent” is not a substitute for testing whether the relevant function is available, works with the enterprise’s systems, and meets the requirements of its workflow.

The decision before deployment

The Okta and Proofpoint announcements show vendors developing approaches that connect agent identity, data access, and execution behavior. They do not establish that existing identity infrastructure has broadly failed.

For an enterprise preparing to give an agent cross-system responsibilities, the immediate task is to define one real assignment and test whether existing controls keep its execution within the approved scope.

If they do, retaining those controls may be appropriate. If they do not, the enterprise should establish whether the gap lies in permissions, workflow design, or coordination across systems before deciding how to address it.

Turning Global AI Signals into Business Decisions

InfoAI helps decision-makers identify what is changing in AI, evaluate the evidence behind those changes, understand what they mean, and determine which business assumptions or decisions may need to be reconsidered.

www.InfoAI.com.tw