Summary
Picture your sales team’s account research workflow six months after launch. One employee checks every source personally before trusting a word of it. Another saves the AI summary straight into the customer record without a second look. A third keeps the research sitting in a private AI account nobody else can see. Your company has a policy that technically covers all three. The workflow itself is running entirely on individual habit.
An artificial intelligence (AI) workflow needs nine documented operating decisions before launch. Who owns it, which tools may participate, and what data can move are the first three. Where people must review, where problems escalate, and where outputs go come next. How long records last, how performance gets measured, and when the workflow comes up for formal review round out the set. A general AI policy cannot answer these questions for every workflow, since each use case involves different data, consequences, and users. Governance becomes real the moment employees can apply it while doing actual work, not before.
The National Institute of Standards and Technology (NIST) organizes AI risk management around four functions: govern, map, measure, and manage. It calls for defined responsibilities, human oversight, and regular review behind each one. McKinsey found that AI high performers were nearly three times more likely to redesign individual workflows, and to define exactly when outputs required human validation. Deloitte’s 2026 research found stronger business value when senior leadership actively shaped AI governance. Results grew weaker wherever that work got delegated to technical teams alone. Governance has to reach the individual workflow before that workflow reaches production. Nine decisions on one working page are what get it there.
Know that a policy sets the boundary, and a launch record sets the instructions
Consider that same account research workflow again. Company policy might permit AI research using approved public sources. That policy will not name the workflow owner, the required sources, the review standard, or the escalation path. Without those answers, your employees quietly write their own rules, the way the three did above. Your company technically has governance. The workflow still runs entirely on individual habit. A launch record closes that gap by converting general policy into instructions for one defined use case. It answers nine questions with enough precision for daily operation.
Decision one: name who owns the workflow
Give every workflow one accountable business owner, remaining responsible for the business result even when a technology team builds and maintains the system. That person needs real authority: approving changes, assigning resources, restricting access, and pausing operation when something is wrong. Technical ownership, data ownership, and review responsibility can sit with different people entirely. One name still has to carry final accountability for the outcome. NIST warns specifically that unclear responsibilities and chains of command weaken risk management. Name the owner, the result they are accountable for, the decisions they can make without further approval, and the backup during absences in the record. Keep a workflow with nobody carrying that complete responsibility in pilot status.
Decision two: name which tools are approved
Most real workflows touch more than one product: a model, an automation platform, a document system, a customer relationship system. Each connection changes data movement, permissions, and reliability. “An approved AI tool” leaves far too much room for employees to substitute their own choice. Name the exact application, model, and account type in the record, along with every sending and receiving system, and the fallback process during an outage. NIST recommends the same discipline for third-party systems specifically, since a vendor update can change model behavior, features, and available controls without warning. Cover version changes directly in your tool approval too. Never let a workflow tested against one model drift onto another without a fresh review.
Decision three: name what data may enter
Translate your company’s public, internal, confidential, and restricted categories into specific instructions for this use case in the workflow record. That means naming which fields, which sources, and which information must stay out entirely. A sales workflow needing customer data should name the required fields, not receive broad access to every record the system holds. The minimum necessary principle is the right starting point, since broad access looks convenient during development and creates exposure and oversight problems later. NIST recommends aligning AI governance directly with your existing data policies rather than building a separate structure. Pause the workflow the moment your team cannot explain where a piece of information came from or why the system needs it.
Decision four: name where human review has to occur
Scale review with consequence. A customer’s financial decision needs stronger protection than an internal first draft. Weigh potential impact, reversibility, available confidence, and the experience needed to catch a real problem in the record. Name the review point, the responsible reviewer, the acceptance criteria, and the expected response time. McKinsey identified defined human validation processes as one of the strongest factors separating high performers from everyone else. Give review capacity direct attention here too, since an unmanaged queue quietly teaches employees to bypass the control entirely. Let human review protect a specific decision. It should never stand in as a vague instruction to “check the AI.”
Decision five: name what the escalation path is
Every workflow will eventually meet a condition it cannot resolve safely: conflicting sources, missing information, a customer dispute, an output crossing an approved boundary. Name the specific triggers and, for each one, the exact destination, response time, and person with authority to approve continued processing. A general email address rarely provides real accountability. NIST recommends policies covering monitoring, incident response, and human override for exactly this reason. A dependable escalation path does double duty. It protects daily operations, and it turns every failure into evidence the workflow can learn from.
Decision six: name where the output goes
An output sitting inside an AI application rarely completes the actual business process, since someone still has to transfer, approve, or distribute it from there. Name the system of record, the required format, and the output’s exact status: draft, recommendation, classification, or approved record. Each one carries different authority, and your employees need to know which they are holding. A generated recommendation without its source attached becomes hard to verify later. Enter manual transfer into the real operating cost the moment the workflow reaches production, even if it was fine during a small pilot.
Decision seven: name how long information gets retained
One business request can create source documents, prompts, outputs, review comments, and system logs, and each needs its own approved retention period. Keeping everything forever raises privacy and discovery exposure. Deleting everything immediately can quietly erode accountability. Name each record type, its retention period, the business or legal reason behind it, and who is responsible for deletion. Give vendor settings their own review here. Your company retention rule offers little real protection if the provider keeps prompts or files under separate terms. NIST recommends deliberate decommissioning policies covering exactly this kind of dependency.
Decision eight: name how performance gets measured
One productivity number cannot tell the complete story. A workflow can cut drafting time while quietly increasing review time, or raise output volume while customer response slows down. Build a real baseline and three kinds of measure into the record. The business result that justified the investment comes first, followed by operating health: completion rate, exception rate, correction rate, and adoption. Risk and quality round it out: major errors, policy violations, and missed escalations. Give every measure an owner, a source, a target, and a real response threshold. An activity count without a response rule is reporting, not control.
Decision nine: name when the workflow gets formal review
“Review periodically” is not a commitment, and daily operations will push an undefined review aside indefinitely. Get a higher-risk workflow its first formal review around 30 days out, moderate risk around 60, and lower risk around 90. Adjust for how much transaction volume the workflow needs to produce meaningful evidence. Put that date in the launch record, the owner’s calendar, and the workflow inventory, not only a good intention. Let a major incident, a model change, or a new data source trigger an earlier review regardless of the calendar. NIST describes AI systems as fundamentally dynamic, with performance that can shift during normal operation.
Fit the nine decisions on one working page
A workflow identification section names the use case, the business problem, and the launch scope. A decision section covers all nine answers above in enough detail to operate from. An approval section records sign-off from the business owner, the technical owner, and the data owner, plus any required risk partners. It also captures the launch conditions and approval date. Keep this record accessible to the people running the workflow day to day. A governance document buried in a project folder cannot guide anyone’s Tuesday afternoon decision.
Run a 60-minute launch review to produce a real decision
Use the first 10 minutes to confirm purpose and scope, with the business owner explaining the problem, the users, and the boundaries. Confirm AI is the right answer here as a group, since technical capability alone never justifies a launch on its own. Use the next 35 minutes to test the nine decisions directly. Spend real time on each one and examine actual evidence rather than accepting verbal reassurance. Turn any missing answer into a named condition with an owner and a due date. Use the next 10 minutes to review operating exposure: the highest-impact possible errors and the exception path. Confirm people genuinely have the time and authority their assigned controls require. Use the final five minutes to record a decision. Choose approval within the documented scope or conditional approval pending named work. Choose hold status requiring more evidence, or rejection that sends the use case back for real redesign.
Let governance follow the workflow through its whole life
The launch meeting does not end the work. Keep reviewing performance and approving changes as the owner. Have your technical teams keep monitoring failures, and your reviewers keep recording corrections. Let a model update trigger a fresh tool decision. Let a new data source trigger a fresh data review. Let a rising correction rate reopen the human review decision. Let a shift in business priorities reopen the measurement decision, or end the workflow outright. The nine decisions create a stable foundation specifically because they make change easy to manage. The original assumptions stay visible enough to revisit on purpose instead of drifting unnoticed.
What you tell them at the end
An AI workflow should launch only after your organization has decided how it will operate, not only whether the technology works. Nine documented decisions turn a general policy into a real operating agreement. Your employees get usable instructions, your leaders get evidence they can act on, and one owner keeps genuine accountability for the result. A launch record that fits on one page is worth more than a governance binder nobody opens.
