What changes when AI moves into real work?

Jonathan Galis8 min read

AI moves into real work when it becomes part of an owned business process with controlled inputs, explicit permissions, measurable outcomes, exception handling and a tested stop path.

In an experiment, success is an impressive answer. In operations, success is a case that reached the right state, at the right time, with the right authority—and can be explained when it did not.

The unit of value changes

Count completed work, not conversations. A procurement assistant is valuable when an approved request becomes a correct, traceable decision. A support assistant is valuable when a customer issue reaches resolution without avoidable correction or delay. The conversation is an interface; the workflow outcome is the product.

A new operating surface appears

Queue
Work waiting for the system, a person or an external dependency.
Exception
A case that cannot continue safely under the current policy or available evidence.
Approval
A bounded decision by an authorised person, attached to a specific version and action.
Checkpoint
A durable state from which work can be understood and safely resumed.
Stop control
The tested mechanism that prevents new effects while preserving evidence and in-flight state.

Ownership must become explicit

Name a business owner for the outcome, a service owner for availability and incidents, and control owners for shared identity, data and tool policies. Without that split, every unusual case flows back to the person who built the first demo.

Design the exception path before the happy path scales

  • Show why work paused in language the operator can act on.
  • Keep the original case, policy version and attempted action together.
  • Route the exception to a person with authority and enough context.
  • Let the person correct the case without bypassing the control that stopped it.
  • Feed recurring exception categories into workflow and policy improvements.

Evidence becomes part of the user experience

Operators need to see which identity initiated the case, which workflow and policy versions ran, which tools changed external state, who approved consequential actions and where the case stopped. The evidence should be useful without exposing sensitive content in general logs.

A production-readiness checklist

  1. Define the business outcome and an owner.
  2. Classify inputs and scope identity, model and tool permissions.
  3. Test normal cases, denied cases, timeouts and partial external success.
  4. Create queues and service levels for approvals and exceptions.
  5. Instrument outcomes, correction, latency, cost and policy denials.
  6. Exercise the stop, recovery and evidence-export procedures.
  7. Set a review cadence for changes in models, policy, data and process.

Moving AI into operations is an organisational and systems change. The model is one component; the durable product is the controlled flow of work around it.

Common questions

What is the clearest sign that an AI pilot is not production-ready?
No one can say who owns failed or ambiguous cases, how the workflow is stopped, or what state external systems are in after a partial failure.
Which metric should replace number of chats?
Use a workflow outcome such as correctly completed cases, time to resolution, human correction rate, exception rate or reversible actions completed within policy. The metric should reflect the business process the AI changes.
Does more autonomy always create more value?
No. Autonomy is useful when the action is well-scoped, observable and recoverable. Human approval can be the efficient design for rare, consequential or ambiguous decisions.

Related notes