Gartner’s public agenda listed Daryl Plummer and Kristin Moyer as speakers for the September 14, 2026 opening keynote in Australia, titled “Shaping Momentum: Compounding Value and Risk for the Next Success Horizon.” Its description explicitly says AI value is growing while AI risk is compounding. That verified agenda framing makes the case for treating AI adoption as a joint value, risk and operational-change problem.
The distinction matters. Enterprises should neither dismiss the warning nor turn it into a sweeping claim that no provider has enterprise-oriented products. The actionable issue is whether an organisation has made its individual AI use case dependable enough for its own risk tolerance.
Enterprise-ready is not a yes-or-no label
“Enterprise-ready” is often used as a catch-all, but it bundles together several separate questions:
- Can the organisation predict and test changes in model behaviour?
- Is there a contract appropriate to the service being purchased?
- Are ownership, approval and escalation paths defined?
- Can the business identify every material AI system and the data or decisions it affects?
- Is there a credible response when a provider changes, retires or suffers a failure in a dependency?
- Can workers tell when an answer or action needs human review?
A supplier may offer credible answers in some of these areas while an implementation remains unsafe in others. Conversely, a model may be technically impressive but unsuitable for a high-impact workflow if the customer cannot test its outputs, constrain its access or recover from a breaking change.
This is why a categorical verdict on “leading AI labs” is too blunt. OpenAI publishes business terms covering its APIs, ChatGPT Enterprise, ChatGPT Business and other business and developer services. Its published service terms also describe intellectual-property indemnification obligations for API customers facing certain third-party claims tied to use or distribution of output. Anthropic publishes model deprecation information, including notices that affected customers are informed through email and documentation.
Those provisions are meaningful evidence that enterprise-facing mechanisms exist. They do not, however, settle whether a particular customer has the service commitments, data protections, audit rights, support arrangements, performance assurances or liability allocation it requires. Nor does a contract automatically make a fast-moving model dependable inside a business process. Procurement and legal review remain necessary, but they are only one layer of operational readiness.
Model drift is a real engineering problem
The most concrete part of the warning concerns lifecycle management. AI applications can be sensitive to changes that conventional software teams may not expect from a hosted service.
OpenAI states that prompt behaviour can change between model snapshots and recommends using pinned model versions and implementing evaluations to preserve more consistent application behaviour and outputs. Anthropic likewise says that applications using its models may need occasional updates as older models are retired, while noting that it provides notification to affected customers.
These statements do not prove a universal claim that models last only six months. They do establish a narrower and important fact: model choice is a managed dependency, not a one-time configuration choice. A system that works acceptably in testing can behave differently after a model update, and an older model can eventually require migration.
For Windows organisations, that changes how AI features should be shipped. A team integrating an AI API into a line-of-business application, internal support tool or employee workflow should avoid treating the selected model as invisible infrastructure. It should record the exact model version in use, test representative prompts and outputs before changing versions, and retain a way to compare a new version with the prior one.
The tests should be grounded in the task the software actually performs. For a helpdesk-assistance tool, that may mean checking whether answers route users to the right internal process and avoid unsupported claims. For document summarisation, it may mean testing coverage of key points and flagging uncertain material for review. For an application that can trigger downstream actions, testing must include the boundaries around those actions—not merely whether the prose response looks plausible.
Version pinning is not a permanent solution. It can reduce unexpected change while a version is available, but it also makes eventual migration planning unavoidable. The better pattern is to treat model upgrades like any other material service change: assess impact, run evaluations, obtain the right approval and retain a rollback or safe fallback where possible.
The hidden cost is rework, not just subscription fees
AI return-on-investment discussions often start with licence or API costs. They can miss a more basic question: does AI-generated output save time for the person receiving it, or does it shift work downstream?
BetterUp Labs and the Stanford Social Media Lab use the term “workslop” for AI-generated material that creates work for others rather than completing useful work. Their public survey material says 40% of surveyed U.S. desk workers had received workslop in the previous month and that resolving an incident took about two hours on average. The material is based on an online survey of 1,150 full-time U.S. desk workers conducted in September 2025.
Its headline annual estimate—roughly US$9 million—applies to a 10,000-person company, not a 1,000-person company. That denominator is material. Applying the number to a workforce one-tenth the size would exaggerate the estimate by a factor of ten if all else were assumed equal.
The study is still a warning worth considering, but its limits should remain clear. It is survey-based material from its publishers, not a Gartner survey, and it should not be treated as a universal measured loss for every company. The useful lesson is qualitative: a tool can make it quicker to produce an email, a report or a draft while making the next recipient slower because they must verify, rewrite or untangle it.
A Windows team can detect that failure mode with straightforward measurement. Before broad deployment, define what a successful output looks like, sample real work, and measure correction effort as well as initial production time. Ask reviewers whether the tool reduced total cycle time, not just whether the original author finished earlier. Track error categories, escalation rates and cases where a human discarded the output entirely.
This is particularly important for tools that create apparently polished text. Fluent writing can conceal missing context, an inappropriate recommendation or an invented detail. The risk grows when a draft is passed through several people, each assuming someone else checked it.
Governance should be concrete, not theatrical
AI governance can be organised through a more centralized function, with common policy, review and oversight, or through distributed responsibility embedded in business and technical teams. The appropriate structure will depend on an organisation’s scale, risk profile and existing decision-making model. Whichever structure it chooses, the controls need to be specific rather than merely symbolic. NIST’s AI Risk Management Framework offers an implementation-neutral baseline: maintain an inventory of AI systems, define and document roles and responsibilities, monitor systems on an ongoing basis, conduct periodic review, document risks and impacts, and establish contingency processes for high-risk third-party AI failures.
In practice, an AI governance function should answer basic questions quickly:
- Which AI tools are approved, piloted, prohibited or unknown?
- Which business owner accepts the risk for each material deployment?
- What information may enter each system?
- What outputs can the system create, recommend or act upon?
- Who can alter prompts, models, permissions or connected tools?
- What testing is required before a material change?
- What happens when the provider changes a model, withdraws a capability or becomes unavailable?
An inventory is more than an asset list. It should identify purpose, owner, provider, model or service version where relevant, data categories, integrations, user population, impact level, evaluation approach and recovery plan. Without that record, a company cannot reasonably claim it understands where AI is making decisions or influencing work.
Clear accountability does not mean a CIO is automatically personally liable for every AI failure. Legal responsibility depends on jurisdiction, contracts, organisational decisions and the facts of an incident. The available governance guidance supports defined organisational roles and accountability structures; it does not create a universal rule of personal or criminal exposure for CIOs. Organisations should resist fear-based claims while still making ownership unambiguous.
Guardian agents may help, but cannot replace controls
Gartner has separately described “guardian agents” as systems that supervise other AI agents, monitor or block risky actions, and enforce policy across platforms. The concept is sensible where AI agents can take actions rather than merely generate text. A monitoring layer may add checks for disallowed operations, unusual behaviour or breaches of predefined boundaries.
But that description should not be mistaken for proof that guardian agents reliably stop rogue systems in production. An oversight agent is itself a technical system with limitations, configurations and potential blind spots. It must be tested, assigned an owner and given clear authority boundaries. It also cannot repair poor identity controls, undefined business rules or a workflow that gives an AI agent more access than it needs.
For consequential actions, organisations should start with simpler safeguards: least-privilege access, separation between suggestion and execution, approval gates, audit logs, constrained tool access and tested shutdown or fallback procedures. A guardian agent may become an additional layer, not a substitute for those fundamentals.
A practical path for Windows and IT leaders
The measured response to Gartner’s risk-and-value message is neither an AI freeze nor unconditional rollout. It is disciplined adoption.
First, separate experimentation from production. A low-impact pilot can have narrower controls than an AI function that influences customer communications, employee decisions, financial work or system changes. Second, make every production deployment accountable to a named business owner and a technical owner. Third, build evaluation and change management into the application lifecycle from the beginning, rather than adding them after a surprising output or provider change.
Fourth, test the economics end to end. Include review effort, corrections, training, monitoring and incidents alongside apparent productivity gains. Finally, prepare for dependency failure. If a model changes, is retired or cannot be reached, employees need to know whether the process pauses, reverts to a conventional workflow or uses an approved alternative.
The central lesson is not that enterprise AI is impossible or that providers offer nothing useful to business customers. It is that enterprise suitability is earned at the intersection of provider capabilities and customer governance. AI value may indeed be growing, but organisations will only compound that value if they also manage the change, rework and accountability that come with it.