Why Does an AI Services Project Create a Working Demo but No Owner?

A vendor can put a working AI demo in front of you and still leave you with no owner. The demo answers, “Can this happen?” The handoff must answer, “Who can keep it useful when the input changes, the model drifts, or the vendor leaves?”

That gap is easy to miss because a demo compresses the work into one visible moment. Ownership is spread across business outcomes, daily operation, maintenance, review, change, and recovery.

A working demo proves possibility, not transferable ownership

Treat a working demo as possibility evidence. Treat internal ownership as transfer evidence. Transfer is present only when an internal role can run the normal path, inspect a failure, make an authorized change, and stop or recover the system.

This is an analysis from the audit in this post, not a claim that NIST, OECD, or ISO uses this exact phrase. It fits the shape of their guidance. NIST describes Govern as a cross-cutting function with clear roles, periodic review, monitoring, and safe decommissioning. Its lifecycle appendix separates development, operations and monitoring, evaluation, governance, procurement, and third-party actors. (NIST AI RMF Core, NIST AI RMF 1.0)

The OECD's accountability guidance makes the same handoff problem visible from another angle: AI actors are accountable according to their role, context, and ability to act, across planning, design, validation, deployment, operation, and monitoring. That is more demanding than showing that a prompt and integration work once.

Evidence in the room	What it proves	What it does not prove
A demo produces a useful output on prepared inputs	The proposed system can produce a useful output in that demonstration context	An internal team can operate it under normal variation
A vendor explains the architecture	The buyer has received information about the design	An internal maintainer has access, authority, and practice
A handoff deck lists “the business team”	Someone has named a broad group	A person or team owns the outcome and can make a decision
A pilot has passed a test set	The tested cases met the chosen criterion	Someone will review incidents, approve changes, or roll back the system

The ownership audit closes the last column.

The six-field ownership audit

Use one row for each responsibility. Score every field from 0 to 2: 0 means absent, 1 means named or claimed but not evidenced, and 2 means explicit, accessible, scheduled, and evidenced. The score is a decision aid, not a certification test.

Responsibility	Named person or team	Authority	Access	Operating cadence	Evidence of competence	Fallback path	Score
Business outcome owner	Who owns the intended result and its trade-offs?	Can this owner accept risk or pause the work?	Can they see the outcome, exceptions, and relevant records?	When is the result reviewed?	Have they judged a real or rehearsed case?	Who acts when this owner is unavailable?	/12
Workflow operator	Who runs the normal workflow?	Can they reject, escalate, or hold an output?	Can they access the input, output, queue, and runbook?	How often is the queue or workflow operated?	Can they run, correct, and escalate a case alone?	What is the manual path?	/12
Technical maintainer	Who maintains integrations, prompts, models, data, and deployment?	Can they make approved technical changes?	Do they have code, configuration, logs, credentials, and vendor access?	When are health and changes reviewed?	Have they diagnosed and repaired a failure?	Who covers leave, outage, or vendor exit?	/12
Review and escalation owner	Who reviews exceptions and risk signals?	Can they override or escalate an output?	Can they inspect evidence and incident history?	What triggers routine and urgent review?	Have they practiced a disputed or unsafe case?	What happens outside their working hours?	/12
Change authority	Who approves a prompt, model, policy, data, or workflow change?	Can they authorize the change and its risk?	Can they see the proposed change and its test evidence?	When are changes reviewed?	Have they made or rejected a change using evidence?	Who can block an unapproved change?	/12
Stop or rollback owner	Who can suspend, disable, or roll back the system?	Can they make the stop decision without waiting for the vendor?	Do they have the controls and recovery artifacts?	When is rollback rehearsed?	Have they completed a safe rehearsal?	What is the manual fallback if rollback fails?	/12

The six rows reflect a lifecycle, not an org-chart preference. NIST's Govern outcomes call for documented roles and responsibilities, training, periodic review, and procedures for phasing out or deactivating systems. NIST's lifecycle actors also include operators, evaluators, auditors, management, and third-party entities. (NIST AI RMF Core, NIST AI RMF 1.0, NIST AI RMF Playbook)

How the audit maps to NIST, OECD, and ISO guidance

The audit is a practical crosswalk, not a claim that six rows replace a governance program. It translates primary-source guidance into questions a buyer can ask at the end of a services project.

Audit field	Primary-source crosswalk	What to verify in the handoff
Named person or team	NIST Govern 2.1 requires clear roles and responsibilities. OECD describes suppliers, developers, deployers, users, and affected stakeholders.	The name is specific enough that the person or team can be contacted and held to a decision.
Authority	NIST Govern 2.3 places risk decisions with executive leadership and Govern 2.1 with documented lines of communication. OECD limits accountability to actors with the role, context, and ability to act.	The named owner can approve, reject, escalate, or pause the relevant work. A name without decision rights is a contact, not an owner.
Access	NIST identifies operational, monitoring, evaluator, governance, and third-party actors across the lifecycle. OECD says documentation and logs should follow the system across developer, vendor, and deployer.	The internal role can reach the inputs, outputs, logs, configuration, controls, and records needed to perform its job.
Operating cadence	NIST Govern 1.5 calls for planned periodic review and clearly defined review frequency. OECD describes monitoring and review as continual.	The handoff contains a recurring review, incident trigger, and change review, not only a final meeting.
Evidence of competence	NIST Map 3.4 and Map 3.5 call for operator proficiency and human oversight processes to be defined, assessed, and documented.	The role can demonstrate the normal run, a correction, an escalation, and the relevant review or change action.
Fallback path	NIST Govern 1.7 and Manage 2.4 address safe phasing out, superseding, disengaging, or deactivating systems. OECD describes treatment options that include ceasing, preventing, or mitigating risk.	The team can continue the business process or safely stop the AI workflow when the owner, vendor, model, or integration is unavailable.

ISO/IEC 42001 adds a management-system lens. ISO's public description says the standard specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system. That supports checking policies, responsibilities, operations, review, and improvement around the workflow. It does not mean this small audit establishes conformity or certification.

Worked example: remediate, not accept

The following is explicitly hypothetical. It is a draft-only support workflow that reads incoming support emails, proposes a triage label and suggested reply, and leaves a human to approve the response. It is not a client case, a reported engagement, or a measured outcome.

Responsibility	Named owner	Named	Authority	Access	Cadence	Competence	Fallback	Total / 12	Finding
Business outcome	Revenue Operations lead	2	1	1	0	1	0	5	Owns the intended value, but cannot pause or review the workflow alone.
Workflow operation	Support Operations team	2	1	2	1	1	1	8	Can run the normal path, but escalation practice is informal.
Technical maintenance	Internal Platform team plus vendor	1	0	0	0	0	1	2	The internal maintainer is not empowered or provisioned.
Review and escalation	Support lead plus Compliance	2	1	1	0	1	1	6	Review exists in principle, not as a scheduled path.
Change authority	Product and IT steering group	2	1	0	0	0	0	3	No recorded owner can approve a prompt, model, or policy change.
Stop or rollback	Platform on-call	2	1	1	0	0	1	5	A team is named, but rollback has not been rehearsed.
Total								29 / 72	Remediate

The decision is remediate, not accept. The draft-only boundary makes remediation plausible because the workflow does not automatically write a reply to a customer. But the handoff is not transferable yet. The buyer should not ask the vendor to “explain it one more time.” The buyer should close the missing fields:

1. Give one internal role authority to accept the business risk, pause the workflow, and escalate a material incident.
2. Provision the maintainer with the code or configuration, logs, deployment path, vendor account, and change history needed for the role.
3. Put normal review, incident review, and change review on a named cadence.
4. Rehearse a normal run, a corrected output, an escalation, and a rollback with the internal roles performing the actions.
5. Record the manual fallback and the person who can invoke it.

The score is useful because it shows where confidence should come from. It should come from observable control, not from how polished the demonstration looked.

When should you accept, remediate, or stop?

Use these thresholds as operating rules for the audit. They are not requirements stated by NIST, OECD, or ISO.

Accept when every row scores at least 10/12, the total is at least 60/72, and no row scores 0 for authority, access, or fallback. The internal team must be able to run the workflow and make the relevant stop or change decision without waiting for the vendor.

Remediate when the workflow is bounded and reversible, but one or more rows score 4 to 9 or a cadence, competence, or backup is missing. Set a named remediation owner and rerun the audit. Do not call the handoff complete while the score is open.

Stop when nobody has authority to pause or change the system, nobody has access to the controls needed to recover it, or the workflow can take an irreversible or high-impact action without a rehearsed review and fallback. A working demo does not override that veto.

The principal exception is a managed service. Internal ownership does not require internal technical implementation. A vendor may remain the maintainer if the buyer names an internal service owner with contract authority, access to evidence, a review cadence, an escalation path, and a tested exit or replacement path. “The vendor owns it” is not a fallback by itself.

Why confidence disappears when the vendor leaves

When I taught product managers who went from writing specifications to building and shipping, the shift happened when the outcome and definition of done became explicit. That is a bounded teaching observation, not a failure rate. It matters here because “the demo works” is an output, not a definition of done.

The internal team becomes confident when it can answer concrete questions:

• What business result are we responsible for?
• Which outputs can we approve, correct, or reject?
• Who can change the system, and what evidence do they need first?
• Where do we look when performance or inputs change?
• Who pauses it, and what do we do next?

If the answers live only in the services team's memory, the project has transferred a demonstration. It has not transferred an operating capability. For the broader choice between buying delivery and building internal capability, see AI consulting and tutoring decisions. For the adjacent handoff checklist, see what should an AI pilot handoff include. For the buyer-side ownership milestone, see what an AI consulting buyer should own before the engagement ends.

What to require before the vendor exits

Make the audit a decision meeting, not a document request. Ask the vendor and internal team to fill every row together, attach evidence to each score, and run the workflow with the internal roles performing the work.

The exit packet should contain:

1. the completed six-field audit and the open remediation items;
2. a role-specific runbook for normal work, correction, escalation, change, and stop;
3. access confirmation for data, logs, configuration, deployment, and relevant vendor controls;
4. the next review date, incident trigger, and change approval path;
5. the manual fallback and rollback rehearsal record;
6. a written accept, remediate, or stop decision with a named signatory.

This is consistent with the primary guidance without pretending to be the guidance itself. NIST calls for documented responsibilities, training, monitoring, and deactivation processes. OECD says accountability and documentation travel across the lifecycle and across actors. ISO/IEC 42001 frames responsible AI work as an organizational management system that must be maintained and improved. (NIST AI RMF Core, OECD primary PDF, ISO/IEC 42001)

The useful next step is simple: run the six rows before you approve the handoff. If the project needs a clearer outcome, owner, or definition of done, Marius Manolachi's AI consulting and tutoring work is designed around making existing people capable of building and operating AI products on their own work.