Do not automate a process nobody owns

A process can run for years without a clear owner. Several people know parts of it. A shared inbox keeps requests moving. A spreadsheet records some decisions. When something unusual happens, the team finds whoever remembers what happened last time.

That arrangement may be frustrating, but people can often compensate for it. They ask questions, notice missing context, and make judgment calls. Once AI is added, the missing ownership becomes harder to ignore.

An assistant can classify requests, draft replies, extract fields, or recommend a next step. It cannot decide who is accountable for the work. If nobody owns the process, automation may move ambiguity faster rather than resolve it.

Before we test AI in a workflow, we look for an owner.

Ownership is more than approving the project

A project sponsor can authorize a test without owning the process being tested. The process owner is closer to the daily work. This person understands what a valid input looks like, which decisions matter, where exceptions go, and what should happen when the process changes.

That does not mean one person must perform every task. It means someone can answer practical questions such as:

• What starts this process?
• What information is required before work can continue?
• Which decisions may follow a rule?
• Which decisions need judgment or approval?
• Who handles incomplete, conflicting, or unusual cases?
• What record must remain after the work is complete?
• Who can change the process later?

If the answers are scattered across several people, that is useful evidence. The workflow may have several owners, or it may need to be divided into smaller parts before any test begins.

An unclear process produces an unclear test

Suppose a company wants an AI assistant to read incoming requests and route them to the right person. The technical task sounds contained. Yet the important questions are operational.

Which requests belong in each category? Can one request belong to several? What happens when the customer leaves out a key detail? Is a fast but imperfect route acceptable, or must every request be reviewed first? Who decides when a new category is needed?

Without an owner, a test can still produce output. What it cannot produce is a reliable decision about whether that output is useful.

One reviewer may reward speed. Another may care most about consistent classification. A third may discover that the categories no longer match how the company works. The disagreement is not a model problem. It is a process decision that has not been made.

We would rather find that disagreement in a small test than after the workflow starts acting on live work.

Name four kinds of ownership

For a bounded AI workflow, we usually separate ownership into four practical areas.

Input ownership

Someone must know which sources the workflow may use and whether those sources are fit for the task. That includes access, freshness, missing information, and conflicting records.

A polished answer based on an outdated document is still wrong for the work. The input owner should know how a source is updated and who resolves disagreements between sources.

Decision ownership

Someone must define which outcomes the system may recommend, draft, or carry out. This is where the action boundary becomes concrete.

The owner should be able to say which decisions can follow an approved rule, which need human review, and which should remain outside the system. If nobody has authority to define that boundary, the workflow is not ready to act.

Exception ownership

Normal cases are often the easiest part of a demonstration. Exceptions determine whether the workflow can fit real operations.

Someone must receive cases the system cannot handle. That person needs enough context to understand why the case was routed, what the system already did, and what remains unresolved. An exception queue without a responsible person is only another place for work to accumulate.

Change ownership

Models, instructions, source documents, and business rules change. Someone must decide when a change is needed, how it will be tested, and when it may enter regular use.

This owner also needs a way to compare the changed workflow with the prior version. Otherwise, an improvement in one kind of case can hide a regression in another.

These roles may belong to one person or several. The important point is that each responsibility has a name before the test carries meaningful risk.

The owner helps define the smallest useful test

Once ownership is clear, we can frame a test around a real business decision.

We might collect a limited set of representative cases, including common requests and known exceptions. We can define what the assistant may read, what it may produce, and where a person must intervene. Then the process owner can inspect the results against criteria that matter to the work.

The test might reveal that AI handles routine classification well but lacks enough context for unusual requests. It might show that the source records need cleanup first. It might show that an ordinary form or routing rule solves the problem with less complexity.

Each of those findings is useful. The goal is not to prove that AI belongs in the process. The goal is to learn what the process needs and whether a particular approach supports it.

Ownership should survive the handoff

A workflow is not finished when the first version works. The team needs to know who watches it, who reviews exceptions, who updates its sources, and who can approve changes.

Those responsibilities should appear in the operating notes and handoff, not remain in conversations with the builder. If the named owner leaves or changes roles, the company should be able to assign a replacement without reconstructing the whole project.

This is also why we do not treat governance as a document added at the end. The operating responsibility shapes the design. A workflow that cannot show what it used, what it produced, and where it needs help is difficult for an owner to manage.

Start with the person responsible for the work

When a company asks where AI could help, the first useful conversation is often with the person responsible for the process, not with a list of tools.

We want to understand what valuable work is happening, what information supports it, where judgment enters, and which failures matter. Then we can scope a small, inspectable test and decide what the evidence supports.

If no one can own the inputs, decisions, exceptions, and changes, the next step may be process clarification rather than automation. That is not a delay in the AI work. It is part of deciding whether the work should be automated at all.