Who owns the outcome when AI work crosses departments?

An AI application can make one department’s work easier while making the overall process harder. This can happen when documents forwarded earlier generate more questions, or when a technical improvement reaches a downstream team that is already overloaded. Leadership then faces a specific task: someone needs to own the outcome across handovers and be able to bring about the necessary decisions.

This interests me as a physician and founder because a technical output acquires significance through its use. An accountable person should be able to explain whose process is supposed to improve, whose work changes and how the organisation resolves conflicts between these objectives. That requires a clear remit and sufficient authority to act.

A fictional case with three reasonable perspectives

Imagine a hospital group that wants to simplify incoming internal procurement requests. Specialist departments submit approved product documentation. A central team creates a structured summary. Procurement then checks the information and open questions before the authorised manager decides how to proceed with purchasing. The example contains no patient data or clinical decision.

The central team wants to spend less time transcribing. IT wants an application that can be operated reliably. Procurement needs complete, traceable information so that further questions do not delay its work. All three objectives are reasonable. Achieving them does not yet establish a common criterion for when a request has been handled better.

In the constructed pilot, AI creates the summary faster. The central team therefore forwards it sooner. Some discrepancies previously resolved there now reach procurement, which sends additional questions to the specialist departments. Whether this is better or worse overall remains unclear without examining the whole process. This story reports no observed result; it illustrates a possible mechanism for shifting work.

Define the outcome at the next decision boundary

I would define the process from receipt of the approved request to a professionally usable decision brief. The next authorised decision maker must be able to distinguish confirmed information from unresolved questions. An open question can be a legitimate part of that brief when its status and responsible function are clear.

This gives “finished” a testable meaning. The status requires neither perfect completeness nor a procurement decision already made by AI. It describes which work must be completed to prepare the next decision responsibly. The functions involved should use ordinary, contradictory and incomplete examples to check whether they apply this definition consistently.

The 2021 MRC framework considers complex interventions in relation to their organisational context and affected stakeholders. It is methodological guidance for research. The allocation of work below is my organisational inference, with no claim that the framework tested its effectiveness. [1]

Connect outcome ownership to decision rights

Leadership could assign outcome ownership to the manager already responsible for the overall procurement process. This person would assess benefits, effort and side effects across the participating departments. They need access to relevant information and an agreed way to resolve conflicting requirements. Putting a name in a table without these capabilities does not resolve the conflict.

The remit should explicitly say which changes that person can decide. These might include sequence, handover format and bounded use of a shared improvement budget. Changes to professional approvals, permitted data or fundamental procurement rules remain with the functions responsible for them. This is an organisational agreement; it does not replace existing legal or professional responsibilities.

The voluntary NIST framework calls for clear roles, communication paths and leadership responsibility for decisions about AI risks. It specifies no particular organisational position. My proposal adds a person who brings together the effects on the complete workflow. [2]

Keep each function’s rights concrete

In the example, specialist departments own the meaning of information they provide and answer questions within their expertise. The central team owns the agreed preparation. IT owns operation within the defined technical conditions. Procurement agrees with the other participants what information it needs for its work. Approval of each output remains assigned to a named, qualified function.

Any of these functions can have a justified objection. The important step is to make it actionable: which requirement is affected, which example demonstrates the problem and what decision is needed next? A general statement such as “quality is still inadequate” leaves unclear whether information is missing, an error exists or two departments hold different expectations.

A decision can require several approvals. The outcome owner should account for these in planning, including a deputy and a response deadline. Under this proposal, a missing response remains an open issue. It is neither treated as agreement nor silently replaced by the judgement of the technical lead.

Show shifted work in the same record

For every handover, I suggest a simple record: what is transferred, who accepts it, what work remains and where questions go. Record active working time separately from waiting time. Active time can fall while new queues make the case take longer overall. These measures concern different interests among the participants.

Alongside outcome and process measures, IHI recommends balancing measures to reveal potential disadvantages elsewhere. [3] In the fictional case, I would therefore examine central-team handling alongside procurement questions and additional clarification work in specialist departments. A department can achieve a valuable local improvement whose overall benefit still requires assessment.

The shared record should retain differences between case types. A short standard request may behave differently from a request containing contradictory documents. Looking only at totals can allow a greater volume of easy cases to conceal a problem with difficult ones. The evaluation should therefore also explain which work was omitted and which participants provided feedback.

Decide the resource conflict explicitly

Suppose an additional check at intake would create work for the central team and spare procurement later questions. The team then needs a decision about this distribution. The outcome owner can present expected total effort, the burden on participants and uncertainty in the estimate together. The responsible leadership decides whether this redistribution is desirable and which resources it will receive.

Continuing to judge every department only by its existing local measure offers little help. Someone measured solely on fast forwarding has a different instruction from someone expected to prepare a usable decision brief. In this example, the objectives conflict. Leadership should resolve that conflict visibly before blaming the technical application for the resulting behaviour.

Even a redistribution that looks favourable in the calculation can be inappropriate. It may consume particularly scarce specialist time or make it harder to train new colleagues. Qualitative feedback therefore belongs in the decision. The organisation should identify which disadvantage it consciously accepts, how it will limit it and when it will reconsider.

Start with one handover and review the remit

For an initial walkthrough, I would choose one frequent handover. Participants work through an ordinary, an incomplete and a contradictory fictional request together. For each, they describe the expected input, acceptable output and route for questions. Differences become specific open decisions. This exercise tests shared understanding; it provides no evidence of successful subsequent operation.

After an agreed period of use, the outcome owner reviews the questions and work allocations actually recorded. Has work shifted? Could the responsible function resolve objections in time? Did a technical change affect the shared evaluation criteria? If the person cannot address these questions because they lack authority, their remit must change or be placed elsewhere in the organisation.

For me, this connection between outcomes and the ability to make decisions is central. The organisation continues to need professional specialisation. It also needs someone explicitly responsible for following what happens between those specialised contributions. AI adoption then becomes a shared change to the workflow, with clear responsibility for what ultimately reaches the people relying on it.