Why companies put the brakes on AI and what your SME should measure

In 60 seconds: Several large companies are limiting AI initiatives or putting ceilings on spending. For an SME, these cases suggest a concrete task: measure outcomes, cost, and behavior before expanding adoption. Pick a bounded process, reconstruct its baseline, and agree on what improvement would justify continuing. Give someone ownership of the budget and check how spending stops. Keep a record of each run and human decision. The pilot should end with a decision supported by data, including a decision to shut it down.

On October 15, 2026, 404 Media reported that Accenture limits its Claude funding to USD 29 per person per month. According to memo details also covered by The Next Web, the policy started October 1; overages go to a project or team through a WBS code. It caps central funding for affected employees; additional consumption needs another budget.

Reuters reported on August 26, 2026, as covered by Ars Technica, that Meta canceled part of Project OT; the cause was undetermined. Cited internal posts, which Meta declined to discuss: code changes +220%, changes delivering user features +36%, major incidents +40% year over year.

These are specific spending and internal restructuring cases, insufficient to establish that the entire market is abandoning AI. Our operational reading for a B2B SME in LATAM: before commissioning another implementation, be able to explain the outcome you expect, what you are willing to pay, and what evidence you will require when something fails.

Three blind spots in an AI project

Outcomes: more activity may leave the process unchanged

An agent can send more messages, generate more proposals, or write more code without doing the work better. Choose a KPI with a verifiable definition: complete and accepted requests, time to a valid first contact, or payment receipts reconciled without correction.

Record the eligible population and exclusions too. If the pilot gets only easy cases while the historical baseline includes every exception, the comparison will favor it even without an improvement. Keep review time and errors alongside the main KPI; otherwise you may shift work to a person and count it as automation.

Cost: consumption needs a budget and an owner

A ceiling requires deciding who pays above it. In an SME, have that conversation before connecting an agent to a channel carrying real traffic. Budget for tokens, tools, channels, infrastructure, supervision, and maintenance in the same currency and period.

The useful indicator is cost per correct, accepted outcome. A cheap attempt that repeats or needs repair can make the full process expensive. The guide to the real cost of an AI agent explains how to build that budget.

Behavior: a failure needs a reconstructable run

In its September 2026 survey, quality tooling vendor SmartBear surveyed 1,436 US and UK leaders and practitioners. It found that 46% of teams had shipped AI code that later failed in production; 47% of organizations could not explain how AI contributed to a bug or incident.

The 2026 Lightrun survey, from another vendor, draws on 200 enterprise SRE and DevOps leaders: 43% of AI-generated code changes require manual production debugging despite passing QA and staging.

One measures teams with failures; the other measures changes needing debugging. Neither says half of developers fail or estimates your SME’s probability of failure. They support asking for evidence from live operation. If the project includes code, also review repository access limits and human review.

“We tried another agency and it didn’t work”

That sentence opens a review of the previous project. Ask for the agreed objective, available records, and full bill. Look for four patterns: a demo approved without a metric, the whole process automated at once, runs without logs, and costs the customer discovers at billing time. These are diagnostic questions, without attributing them to a particular provider or customer.

Without a baseline, it may never have been possible to distinguish an improvement from an impression. If nobody kept the steps of a run, switching models leaves the evidence gap intact. And if the scope combined sales, support, and collections, separate one segment before budgeting another implementation.

A pilot that supports a decision

1. Pick a process and reconstruct its baseline

For example, completing quote requests before handing them to sales. As a working proposal, use two to four recent weeks before activating the agent. Record eligible volume, accepted outcomes, delay, and minutes of human intervention. Extend observation if volume is low or seasonal; this window is a starting point, not a statistical guarantee.

2. Measure the segment the agent controls

If it gathers information and hands over a complete request, evaluate that handoff. The eventual sale also depends on pricing, availability, and negotiation. Use the same definitions before and during the pilot, and keep counts alongside rates. The article on measuring a sales agent within its controllable funnel develops that boundary.

3. Set a budget, a cap, and a path when it runs out

Assign a spending owner and limits per run and period. Include retries, tool calls, and maximum elapsed time. An alert notifies; stopping requires controls that prevent further work. Before exhausting the budget, save state and pass the task to a queue or a person. Test that the process remains serviceable when the agent stops.

4. Keep traces for each run

Require an identifier connecting the request, tool calls, outcome, cost, and human approval. Store only necessary data, with access and retention defined. A trace reconstructs recorded actions; it does not reveal the model’s private reasoning or guarantee a correct answer.

As a technical example, the official Claude Code documentation describes cost and token metrics, tool events, and OpenTelemetry traces in beta. These connect interactions, requests, and tools; redact prompt and tool content by default; and require configuration and a backend. Cost metrics are estimates to reconcile with billing.

Correlated records may be enough to start. Ask the implementer to demonstrate opening a failed case and reconstructing its steps.

5. Agree on autonomy and human review

Write down what the agent may read, propose, and execute, and what needs approval. Include who receives an exception and how they acknowledge ownership. The copilot or autopilot guide helps set that authority. If stable rules can handle part of the workflow, also consider when a deterministic chatbot with human fallback is sufficient.

6. Decide in advance when to expand, revise, or stop

Write down the date and thresholds: minimum KPI improvement against baseline, maximum cost per accepted outcome, and errors that require a pause. Agree on enough volume to evaluate and who signs off on the decision. An insufficient sample requires acknowledging uncertainty, not declaring success. If the pilot misses its quality threshold or exceeds budget, stop it or revise a specific hypothesis before repeating it.

Before signing with any AI provider, including Kiia

• Which KPI will change, and which event proves a valid outcome?
• What baseline are we using, and which cases are excluded?
• Who pays for tokens, with what cap, and what happens when it is reached?
• Can I inspect a case’s traces, exceptions, and approvals?
• What happens if it does not work, and who decides to stop?

Put those answers into the pilot scope and budget. If they are missing today, reconstructing them can be the first deliverable before granting the agent more permissions.

Let’s run a bounded pilot with KPIs, a cost cap, and traces from day one. If it does not move your metric, you will know from the data. Book a conversation with Kiia and bring one concrete process to scope together.

Sources checked on October 16, 2026. The proposed windows and controls are a working method, not promised outcomes.