What is capping the return on your AI-assisted tooling?

Your organization invested in AI-assisted tooling for endpoint and desktop operations. In return, it asked for faster issue resolution, fewer incidents, and lower operating cost. At least that’s what our 2026 survey of IT leaders told us were the top three expected outcomes by more than half of the respondents. (This report is not out yet. I "borrowed” these stats. Don’t tell Marketing. 😁)

By and large, the transformational tooling delivers on the top three. Resolution times have come down. Incident counts have come down. The investment was sound, and the results are real.

What most leaders may not know is that these wins will not scale over time. Too often, the speed comes from engineers approving individual actions one at a time, because the machines never got effectively standardized. Adding more tooling will not raise the ceiling, because the ceiling is set by the condition of your estate rather than by the capability of the software.

We are at a crossroads in estate performance. If organizations do not standardize the OS build, the application set, and the configuration baseline, the tooling cannot reliably infer the state of an endpoint. If we have “good” standardized information, our AI-enabled tools will provide insight, value, and the ability to make effective decisions at scale. If they have bad information, they become unpredictable and untrustworthy. This puts the bulk of the burden of mitigation back on humans that it’s supposed to be helping.

The good, bad, and the ugly of AI-assisted tooling

Your standard machines are producing faster resolution times. Your non-standard machines are producing an approval queue. Same tooling, same team, and the only variable is the condition of the machine.

On a drifted machine, the tooling’s ability to read the situation is unreliable enough that most organizations are not comfortable letting it run unsupervised. What decides the next step is the organization's tolerance for automation risk. On a standardized machine, the telemetry is trustworthy enough that the same actions can run fully autonomously.

Provisioning a desktop or troubleshooting a session depends entirely on what the organization’s tolerance for automation risk is. Some actions may be fully automated while others that could impact the users’ work may require engineer approval.

Why doesn't more AI tooling reduce IT workload further?

A deployment tool pushes to a thousand machines as easily as it pushes to ten. An engineer approving actions handles one at a time.

The share of your estate that requires approval therefore sets a hard limit on how much work the tooling can absorb. Buying better tooling does not move that limit. You can improve the model, expand the automation library, and widen the task coverage. Every one of those improvements still stops at the same machines, the ones where an engineer must check the action first.

Teams have already reached that edge. In our 2026 survey of endpoint and desktop operations managers, 67% had returned at least one AI-assisted task to human handling after implementing it. They did not stop using the tooling. They moved specific tasks back to people because the results on part of the estate were not reliable enough to run unattended.

The limit will continue to get tighter every year as exception lists grow.

Why do desktop standardization exceptions keep growing?

Every standardization program leaves exceptions behind. Your Windows 11 migration reported a high completion percentage, and a smaller group of machines sat outside that number with an approved exception attached to each one. Image consolidation ended the same way. So did application rationalization, and so did your last platform migration.

Every one of those exceptions was approved for a real reason. A vendor had not certified the new build. A business owner needed a specific application version. A compliance requirement predates everyone in the room. The program manager approved the exception and hit the date, which was the correct call at the time, because missing a deadline for machines most of the organization would never notice was the worse outcome.

Then the vendor certifies the build. The application has been upgraded. The compliance requirement is revised. I have walked into environments three years after a migration and found the original exception list still sitting in a shared drive, longer than it was at handoff, with nobody assigned to it. Every exception was granted as a temporary measure, and everyone was still in force, because nothing in the process goes back to check whether the reason still holds.

So, the population grows with every program and shrinks with none of them. Each year a larger share of your estate needs an engineer to check the action first, and the tooling you already bought produces less than it did the year before.

How do you reduce the machines that need manual approval?

Reversing that trend does not require a new tooling investment. It requires more machines running a defined build. Those are the ones the tooling handles without an engineer.

The return arrives immediately. Each machine brought back to a defined build stops generating approval work, and the share of tasks running unattended goes up. The longer-term effect is the more valuable one. Today the limit tightens every year as exceptions accumulate. Reverse it and the limit loosens every year instead, so the tooling you already own handles more work in year three than it did in year one.

Five actions get you there, in rough order of cost:

• Review the standing endpoint standardization exceptions and revoke the ones whose reason have expired. This is the cheapest work available, and it requires no new spend. Someone goes through the exception records and checks whether each vendor has since certified the new build, whether each application has since been upgraded, and whether each compliance requirement still applies. Hardware exceptions will not clear this way, since a machine that failed the requirements still fails them. Many of the rest will.
• Consolidate the separate exception lists into one register with a named owner. Each program tracked its own exceptions, and nothing joins those lists. Until they are joined, nobody can tell you which machines sit outside three standards at once, and those are the machines generating the most approval work. The named owner matters as much as the register, because an unowned list stops being accurate within a quarter.
• Define additional standard builds for the populations that will never fit the primary one. Some exceptions exist for reasons that will not expire. A workstation driving lab equipment or manufacturing hardware is not going to converge on your general build, and forcing it costs more than it returns. Defining a second or third supported build for those populations converts a permanent carve-out into something with a standard attached, which means the tooling has a known configuration to read. This decision also carries forward. Every future migration, patch cycle, and platform change inherits a smaller exception population, because the machines that used to fall outside every build now belong to one.
• Move your highest-approval-load populations to a centrally delivered desktop. This is where delivery model becomes a business decision rather than a technical one. A physical desktop drifts on its own, and nothing re-imposes the standard, so exceptions accumulate quietly for as long as the machine stays in service. A desktop delivered from a controlled image, through DaaS or VDI, rebuilds from that image on a schedule, which corrects drift instead of accruing it. Most estates are still predominantly physical. In our 2026 survey, 68.55% of respondents supported their users primarily on physical desktops or laptops, and that is where the approval work concentrates.

BONUS ACTION: Fund ownership of the standard after the project ends. A controlled image degrades without someone maintaining it. Someone has to own the image lifecycle, the exception review, and the drift correction on a continuing basis. That work is Day 2 operations, and it decides whether standardization holds or decays back to where it started.

Where should IT infrastructure funding go in the next twelve months?

When we asked IT leaders what is most likely to receive funding in the next twelve months, better tooling ranked first. Infrastructure modernization ranked fourth out of six.

That order puts the money on the side that cannot move the limit. Better tooling makes each action smarter, and it does not change how many machines need an engineer to check the action first. The work that does change that number is the work of getting more machines onto a defined build and keeping them there, and today it ranks below three other priorities.

None of the five actions above require replacing what you bought. The first two cost almost nothing, and they will tell you how large your exception population actually is. Start there, because the size of that number determines whether the rest is a cleanup project or a delivery model decision.

Then settle who owns the standard once the current program closes. That question is what separates an estate that gets more automatable each year from one that gets less, and answering it before the next program starts is what keeps the exception list from growing again.