Your AI Vendor Is Quietly Becoming Your Operating Model

The Question Underneath the Proposal

An executive team sits down with a proposal for a material AI commitment. There's a platform. There's an implementation partner. There's a delivery team that will sit close to the business for a while, a phased timeline, an integration plan, and a set of success criteria that everyone in the room can read. The transition and offboarding section near the back of the SOW gets less time than the pricing page.

The questions that get asked are the technical ones. Which model. Which systems it touches. What the data path looks like. How security review will run. How quickly the first workflow goes live. Every one of those questions is reasonable, and the answers matter.

None of them is the question that decides whether the company is better off in two years.

That question is simpler and harder to ask in front of a vendor: when this delivery team rotates off the account, who inside the business can explain the workflow end to end, review its output, change it, govern it, and stop it?

If nobody can answer, the company isn't buying a capability. It's renting one, and paying for it as though it were an asset.

Delivery Help Is Genuinely Useful

A vendor arrives with delivery experience, platform-native controls, and patterns learned across many deployments. Internal teams are stretched, the technology moves faster than most hiring cycles, and the alternative to outside expertise is often a slower and worse implementation run by people learning on the company's time.

So the argument here isn't that embedded implementation support is a mistake. Used well, it's how a serious organization compresses a learning curve it has no reason to walk alone.

The risk isn't that expertise lives outside the business. The risk is what the business fails to build while that expertise is inside it.

Because the work still has to be run afterward. Every AI-supported workflow that survives its launch becomes part of how the company operates: someone owns the output, someone reviews it, someone decides when it's allowed to change, someone lives with the consequence when it's wrong. Those responsibilities don't disappear because a vendor was competent. They just get quietly deferred, and a deferred operating decision has a way of becoming a default one.

Five Capabilities That Have to Stay Inside the Business

AI failure is usually an operating-model failure, not a technology failure. That case is made at the level of strategy in Anchor's published Logbook article, The Real AI Problem Is Your Operating Model. Here's What to Do About It. Applied to a vendor commitment, it produces a shorter list: five capabilities that a delivery partner can support, accelerate, and inform, but cannot hold on the company's behalf. In practice these responsibilities overlap and the same person may hold more than one; each is still a distinct check against handing the operating model to a vendor.

Accountability for the business consequence

When an AI-supported workflow produces a wrong answer that reaches a customer, a regulator, an auditor, or a board packet, the consequence lands on the company. A contract can allocate remedies between the parties. It doesn't move the consequence to the vendor's side of the table, and it doesn't tell a customer whose pricing was wrong who to call.

So somewhere inside the business there needs to be a named person, not a steering committee and not a vendor engagement lead, who owns what the workflow produces. Governance is a person. If that name isn't assigned at kickoff but only at handover, the organization has spent the entire implementation building a system nobody internal was accountable for.

Workflow design

A vendor configures against the workflow it's given. If nobody inside the business owns the description of how the work actually runs, including the exceptions, the escalations, the informal steps that never made it into a process document, and the reasons a good answer sometimes has to be overridden, then the vendor's reasonable assumptions become the company's process by default.

That's how a business ends up with a workflow it can operate but cannot explain. The design decisions were real decisions. They were just made by people who didn't have to live with them.

Decision rights

Who can change the prompt. Who can add a data source. Who can widen an agent's scope, approve an exception, adjust a threshold, or halt the workflow when something looks wrong. Prompt changes, data additions, and a production halt can sit with different owners; the test isn't whether one person holds all of them, but whether each has a named path.

If those rights sit inside a delivery partner's backlog, the business has handed over its own throttle. The practical test is speed and authority: when output drifts from the business rule it's supposed to hold, can an internal manager get it changed this week, with an internal reviewer signing off before it takes effect? Anchor's published Logbook article, Your AI Agent Worked Last Week. Who Checks Whether It Still Works This Week?, made the case that recurring AI work needs operating controls. Those controls only work if the people who need them can reach them.

Adoption

Adoption is management work, and it's the part vendors are least able to do. A delivery team can train users, document the tool, and run enablement sessions. It can't make a manager retire the old report, redesign the queue the AI output is supposed to change, or hold a team to a new process when the old one still technically works. It's harder than past system rollouts for one AI-specific reason: the old process still produces defensible results while people learn to calibrate the human judgment the new output requires.

An implementation that launches into an unchanged workflow produces a capable system running in parallel with the way people actually do their jobs. The platform works. The operating model didn't move.

Value Capture

Efficiency becomes value only when someone changes something a finance team can see: capacity, cost per transaction, cycle time, service level, or revenue motion. Delivery partners are measured on delivery milestones, and they should be. The business is the only party that can convert a working workflow into a changed number.

This is the capability most often assumed and least often assigned. The business case gets built during procurement, and then nobody owns the translation from a working system into a result on a budget line. The workflow works, but the business case stays unproven because nobody timed the baseline to the go-live date and nobody with budget authority reviewed the numbers. Ownership is necessary but not sufficient: baselines can be wrong, or the metric can move mid-engagement, but without a named owner, the financial conversation about whether the investment worked happens without anyone who can explain what changed or defend the number.

The Absorption Test

The useful moment to run this test is before signing, or before scaling a commitment that's already underway. It doesn't require a procurement overhaul. It requires an hour with honest answers to a small set of questions.

• If the delivery team rotated off the account next quarter, which named person inside the business could explain this workflow end to end?
• Who has the authority to change it, and who reviews the change before it takes effect?
• Where does the evidence live that it's still doing the job it was built to do, and who reads that evidence on a schedule?
• What's the recovery path if the workflow degrades, the platform changes underneath it, or the vendor relationship ends on terms nobody planned for?
• Which internal owner is accountable for the business consequence when the output is wrong?
• What has to change inside the business, in queues, roles, service levels, or reporting, for the projected value to show up on a real budget line?
• Which parts of what the delivery team knows are being written down, where does that documentation live, and who inside the company has read it?

If the honest answer to the evidence question is that no one reads it on a schedule today, that's a useful admission, not a failure. It's a design gap the implementation plan should close.

A leader who can answer these is buying help. A leader who can't is buying dependency, and paying implementation rates for it.

Dependency Is a Design Choice

The organizations that come out of a major implementation stronger tend to treat capability transfer as part of the work rather than a phase at the end of it.

That shows up in specific, unglamorous places. The internal owner is named at kickoff and sits inside the build, not at the handover meeting. Documentation is an acceptance criterion, not a courtesy. There's a period late in the engagement where the internal team runs the workflow while the vendor watches, rather than the vendor running it while the internal team watches. The review cadence, the escalation path, and the stop criteria exist before go-live, because they're harder to negotiate afterward. The recovery path gets the same treatment: a tested fallback for the affected business process, manual or an alternate system as the situation warrants, and a decision and budget path agreed before the fact rather than an emergency procurement scramble after something breaks.

None of this is free: it costs internal time, political capital, and the short-term delivery pressure to just let the vendor drive instead.

None of that is hostile to the vendor. A good delivery partner can support capability transfer, but the customer has to require it, because commercial models don't always reward transfer. It's simply the difference between an implementation plan that ends with a working system and one that ends with a working system the business can run.

The failure mode isn't a vendor acting in bad faith. It's a customer who never decided what it needed to own, and discovered the answer eighteen months later, when the people who understood the workflow were on someone else's account.

Anchor's AI Bearing Assessment helps a leadership team turn this test into named owners, decision paths, evidence, and capability-transfer requirements before a major commitment lands.

Before the Next Commitment

The decision in front of most executives isn't whether to use outside expertise; the delivery experience is real and worth paying to compress. It's whether internal operating capability becomes observable while that expertise is in the building: a named owner, a workflow the business can describe without the vendor in the room, decision rights that reach the people doing the work, and an adoption plan that changes something. It also needs evidence someone reads, and a recovery path that exists on paper before it's needed.

If the help left next quarter, what would this business still be able to do?