AI stops being just another workplace tool when it begins participating in the work.
If an employee uses AI to draft an email, the company’s operating model can stay mostly intact. The person still gathers the information, makes the decision, and owns the result.
But suppose the system retrieves customer history, evaluates the situation, updates a record, routes the next step, and sends the response. Now it’s doing more than helping an employee. It’s taking on part of a role.
That raises a different set of questions. What can the system decide? What information can it access? When does a person need to step in? Who is responsible if the action is wrong?
Those aren’t primarily technology questions. They’re questions about how the company is designed to operate.
Buying the tool is the familiar part
Most companies know how to adopt software. They choose a vendor, create accounts, set security rules, train employees, and track usage.
That approach works reasonably well when AI acts as a personal assistant. The organization stays in place, and people perform much the same work with better tools.
Operational AI is different.
A system that participates in a workflow needs access to company information. It may need permission to change other systems. It needs rules for what it can handle, what requires approval, and where the result should be recorded.
The difficult questions often appear after the technology works.
If the system recommends an action for a customer, who approves it? If it updates the CRM, which information can it change? If it resolves a support case and the customer disagrees, who owns the recovery? If it spots a contract discrepancy, where does the exception go?
A company can’t answer those questions with an acceptable-use policy. The answers have to be built into the work itself.
Workflows contain more than steps
A workflow may look like a sequence of tasks, but it also contains the organization’s accumulated decisions about authority, knowledge, and responsibility.
A sales process reflects who owns the customer relationship. A support escalation shows where expertise sits. A finance approval reveals how much risk the company is willing to accept. A product handoff determines whether customer information reaches the people building the product.
These arrangements usually exist for a reason, even when the resulting process is slow or frustrating. Information may be scattered across systems. One team may have the context while another has permission to act. An employee may be carrying knowledge that was never documented because the company grew faster than the process did.
AI can change those arrangements because it can move information and perform work that previously required a person. But giving a system access to a messy workflow doesn’t resolve the decisions hidden inside it.
At a company where I mapped more than 100 go-to-market tasks and hundreds of subtasks, the work wasn’t simply a list of activities waiting to be automated. Ownership overlapped. Teams performed the same process differently. Important judgment lived in people’s heads. Handoffs changed what the next person knew.
Before a system could execute that work, someone still had to decide which process should become standard, which source of information could be trusted, who owned the outcome, and how much authority the system should have.
The technology could carry out those choices. It couldn’t make the organization agree on them.
When work moves, authority moves with it
Consider a support workflow.
The system begins by gathering customer history, finding relevant knowledge, and drafting a response. A support agent reviews the draft before anything goes to the customer. The system assists, but the employee still owns the decision.
Later, the company allows the system to send responses automatically for common cases. That may sound like a small increase in automation, but the employee’s role has changed. They’re no longer approving every action. They may monitor performance, investigate failures, improve the knowledge the system uses, and handle the sensitive cases it can’t resolve.
Management has changed too.
Someone has to define which cases qualify for automatic handling. The team needs a standard for acceptable performance, a way to review mistakes, and a person with the authority to stop the system. The company also has to decide who is accountable when the workflow fails.
The same pattern applies in sales, finance, operations, legal, and product. Each time a system takes on more of the work, decision rights move with it.
If the company doesn’t decide where those rights go, responsibility doesn’t disappear. It just becomes harder to see.
Automation changes the handoffs that remain
Many handoffs exist because information and authority are held in different places.
One employee gathers context and sends it to another team. Someone there makes a decision. The first employee updates a system, then notifies the next person. The process may involve more coordination than anyone would design from scratch, but it reflects how the company has divided responsibility.
AI can remove some of that coordination. It can assemble context, route predictable cases, prepare a recommendation, and carry the state of the work from one system to another.
That can eliminate steps that once required several people. It also makes the handoffs that remain more important.
If the system handles routine cases, employees receive a higher concentration of exceptions. Those cases are likely to be ambiguous, unusual, or consequential. A generic escalation queue isn’t enough. The person receiving the case needs the relevant context, the authority to act, and a clear understanding of why the system stopped.
Otherwise, automation removes the easy work and leaves a team with unexplained edge cases it was never set up to handle.
“Human in the loop” isn’t a job design
Companies often say they’ll keep a human in the loop. I understand why. It signals caution and continued oversight.
But it’s too vague to design a workflow.
Which person is involved? What are they reviewing? At what point do they enter the process? Are they approving a recommendation, monitoring a system, or taking over an exception? What information will they have, and what can they do if they disagree?
Human involvement needs a specific purpose.
A person may remain responsible because the decision affects a customer relationship. Review may be necessary because an error would be costly or difficult to reverse. The work may require judgment the organization hasn’t captured well enough to automate.
In another workflow, review may be temporary. The company may need more evidence before it trusts the system to act independently.
Those situations call for different controls and different roles. A permanent approval step isn’t the same as temporary supervision, and neither is the same as exception handling.
The boundary between the system’s responsibility and a person’s responsibility has to be designed as carefully as the automation itself.
Design the operating model at the same time
An AI workflow needs more than a technical plan. It needs a clear outcome, an accountable owner, reliable information, defined permissions, known exceptions, and a way to tell whether the work has improved.
It also needs an honest decision about what happens to the people currently performing the process.
If automation saves ten hours a week, where will that capacity go? If employees stop handling routine cases, how will they develop the judgment needed for difficult ones? If a team becomes responsible for monitoring automated work, does it have the time, skills, and authority to do that well?
These decisions shouldn’t be left for change management after the system has been built. They affect whether the workflow should be automated, which parts should remain with people, and how the system needs to behave.
This is also where employee concern becomes useful information. Resistance may point to customer risk, undocumented expertise, unclear ownership, or a step that looks inefficient but protects the company from a real problem.
The goal isn’t to automate around those concerns. It’s to understand what they reveal about the work and design from there.
Make transformation specific
It’s easy to agree that a company should use more AI while the idea remains abstract.
The real work begins with a particular process.
Should this approval still exist? Can the system make this decision? Which information may it access? Who owns the result? Which role changes if the automation succeeds? Who responds when it fails?
Those questions can create tension, but that tension is useful. It means the company has reached the decisions that could actually change how it operates.
AI can reduce coordination, preserve context across handoffs, and move predictable work into the background. Capturing that value requires more than deploying a capable system.
The company has to redesign authority, ownership, handoffs, and human responsibility around what the system can now do.
That’s organizational design.