You can delegate the work. You cannot delegate accountability.

In the last issue, the point was simple: an AI pilot needs protected time, capacity, and priority or normal work will swallow it.

Protection is necessary. It still does not answer who is accountable for what the work is doing to the business. A pilot can have time on the calendar, a budget line, and a team assigned to it, then drift because nobody can answer for a customer promise, a price, a data-handling decision, or a change in how people do their jobs.

The owner or CEO does not need to operate the tools or approve every draft. Day-to-day work should be delegated. Ultimate accountability stays with the person who can set the business purpose, accept the risk, commit resources, and decide whether the work continues.

Issue #7 dealt with ownership inside a process: when an AI-assisted process produces a result, who responds? Issue #8 dealt with whether leadership protects the time and capacity for that work. This issue is about the company-level layer above both: who remains accountable for the intent, accepted risk, resources, and decision to continue, change, or stop the work.

Consider a manufacturer using AI to help with incoming RFQs.

The assistant reads an RFQ package, extracts requirements, flags missing information, and prepares a draft quote package for an estimator. It might pull together drawings, material notes, requested quantities, lead-time questions, and a first-pass customer response. That can save time sorting attachments and chasing obvious gaps.

That convenience creates a tempting misconception: because estimators use the assistant, estimating owns every decision around it. It does not. An estimator can judge a draft and surface a risk; they cannot alone decide the company’s data boundary, pricing posture, or acceptable customer exposure.

Now put it under real pressure. The draft assumes the company’s standard lead time, while a special material in the RFQ will be difficult to source. It misses a drawing note that changes the inspection requirement. Its customer-facing language sounds as if the company has committed to price, delivery, or capability before anyone approves it.

Those are not narrow software glitches. They touch customer promises, margin, capacity, reputation, and the rules for handling customer files. One estimating desk cannot carry every consequence alone. The consequences split across four jobs.

Titles change with company size. The responsibilities should not disappear.

The owner or CEO sets the business intent. For an RFQ assistant, that might mean faster, clean quotes without careless customer promises. They approve the resources and boundaries: which customer files the system can use, where human review is mandatory, and which commitments must never go out automatically.

If testing shows the source data is too messy or the review step takes more time than expected, the owner decides whether the business will fund the cleanup and give the team room to do it.

They also remain accountable for whether the work serves the company. If polished drafts lead people to skip review, the problem is not solved by saying the tool belongs to estimating. Leadership is accountable for the boundary that an unapproved promise does not leave the company, and for providing enough time and support to make that boundary real.

Every company does not need a formal chief AI officer. In a 40-person shop, this role may sit with an operations leader, IT manager, commercial leader, or trusted project lead who can coordinate the work.

The capability lead keeps AI use connected across the business. They manage access, vendors, and the review cadence; maintain the rules for use; and bring recurring risks or decisions to the owner or CEO. For the quote assistant, they confirm who can see RFQ data, document the human-review rule, and investigate whether a system setting or vendor behavior contributes to repeated misses.

This person coordinates. They do not take the owner’s accountability or the estimating leader’s authority over the process.

For RFQs, this is often the sales or estimating leader. The process owner defines what good looks like: complete, accurate quotes; reasonable turnaround; margin protection; clean handoffs to operations; and a customer response that reflects what the company can actually deliver.

They decide how the assistant fits into the process. It may prepare an internal package, flag missing information, or draft language that still requires review. They decide what requires escalation. When the team starts skipping a required review step because the draft looks polished, that is a process problem, not simply a training issue.

Estimators, sales coordinators, customer-service staff, and others doing the work are not an adoption problem to manage around. They know where the process breaks: the RFQ that looks standard until page seven, the supplier exception that never reaches the ERP notes, or the shortcut that saves time today and creates a mess later.

Their responsibility is to help shape the process, identify missing context and unsafe outputs, and report whether the system is useful. An estimator may find that the assistant regularly misses a special plating requirement because customers describe it differently across drawings. That observation should reach the process owner for a process change, the capability lead for system or vendor review, and leadership when the risk changes the company’s boundary.

Employees do not set the company’s risk posture. The company cannot set a sensible one without their operating knowledge.

The four layers should not become four approval gates for every quote. That would slow the work and teach people to route around the system.

Return to the lead-time failure. The estimator catches the unusual material requirement before the customer receives a promise. The estimating leader decides whether the review step, source material, or handoff needs to change. The capability lead checks whether the assistant’s configuration, access to information, or vendor behavior contributed to the mistake. The owner or CEO remains accountable for the business rule underneath it: no customer commitment leaves without the right human approval, and the company will invest enough to keep that rule credible.

That gives people a path from the work back to the person accountable for the business outcome, without pretending the owner must run the tool.

A professional-services firm may use AI to assemble a proposal from discovery notes. A construction company may organize an estimate package. A service business may prepare a recommendation and follow-up after a visit. An insurance or financial-services office may organize documents before a licensed or authorized person reviews them.

The process changes, but the questions remain familiar: Who accepts the customer and business risk? Who coordinates the tool and access? Who owns the result inside the process? Who hears the exceptions first? You do not need a hierarchy for every small use case. You need clear names when a tool begins touching customer promises, documents, pricing, or operating decisions.

Pick one AI-assisted process you are considering or already using. Keep it narrow: RFQ review, quote follow-up, customer intake, scheduling, proposal preparation, service recommendations, or document preparation.

Write one name beside each line:

A blank line does not kill the idea. It tells you where the next conversation belongs: the missing role, decision right, or handoff. Map the four roles for one AI-assisted process. If one line is blank—or two people disagree about who owns it—reply and tell me where the gap is.

In the next issue, we will stay with the people doing the work. Clear accountability gives a business somewhere to take a problem; it does not tell leaders or vendors how the process works on an ordinary Tuesday. The people who live with its exceptions, workarounds, and customer consequences need to be involved before AI is designed around them.