Who owns it once it's running

A prototype has a project lead. A workflow in operation needs owners for the decisions that keep coming up after delivery, and I'd assign them by name or accountable team before routine use starts.

The business owner decides what work the system does, accepts the risk that's left over and funds the operation. The product or service owner looks after user behaviour, the backlog and service measures. Technical ownership covers code, infrastructure, suppliers and recovery. Data or content owners maintain source authority and access. Risk, privacy and security roles review controls where the workflow needs it.

In a small organisation one person might hold several of these, which is fine, but the decisions still need writing down. "The business owns it" doesn't help much in the middle of an incident.

I'd keep a short operating record that covers:

• the workflow's purpose and boundary
• approved users and uses
• prohibited or unsupported uses
• model, supplier and configuration versions
• source collections and their owners
• the review and escalation policy
• service and quality measures
• cost centre and budget owner
• incident, correction and shutdown procedures
• the next scheduled review

Changes to prompts, models, tools, rules or sources need control in proportion to what they touch. A copy edit might only need ordinary product review. A change that affects which evidence gets selected, or what the system is allowed to do, should rerun the relevant evaluations and need sign-off from the accountable owner. Sort out these categories early, before a rushed update forces the decision on you.

Supplier ownership matters as well. Someone should be tracking contract terms, data handling, availability commitments, usage limits, model retirement notices and the procedure for moving or pausing work. The operating team should know which failures are theirs to fix and which ones get escalated to the provider.