Most AI agencies fail at delivery, not at sales. They close clients, start projects, and then improvise the production process every single time. Each project runs differently. Quality is inconsistent. Timelines slip because no one documented how long each step actually takes. Client expectations are managed through heroic individual effort rather than a repeatable system.
A delivery system is what turns an agency from a freelancer with multiple clients into a business. It defines exactly how a project moves from client intake to final delivery — what happens at each step, who is responsible, what quality checks occur, and what happens when something goes wrong. For an AI agency, the delivery system also defines where AI is in the process, where human judgment takes over, and how outputs are reviewed before they reach the client.
The NIST AI RMF MANAGE function exists specifically for this: managing AI risk in operational deployment. Delivery SOPs are how that management happens in practice. Without them, governance is aspirational. With them, it's operational.
An AI content agency grows from two clients to twelve in eight months. The founder handles all client work personally for the first six months. Projects run smoothly — because the founder knows every client's preferences, checks every output intuitively, and escalates to themselves when something seems off.
At twelve clients, the founder brings on a part-time contractor. The contractor is competent. But they don't know what "good" looks like for each client. They don't know when to flag an AI output for human review versus when to send it directly. They don't know what the founder checks before delivery. Within thirty days, two clients flag quality issues that the founder would have caught. One client cancels.
The founder realizes the problem: the delivery system exists only in their head. The quality checks are intuitive. The escalation path is "text the founder." There's no documentation of what AI handles, what the contractor reviews, or what the founder approves. Every new person on the team has to learn by watching, and learning by watching doesn't scale.
The fix is a delivery SOP — a documented workflow that any trained contractor can execute, with defined checkpoints, explicit quality criteria, and a named escalation path. When built correctly, the SOP also becomes the agency's governance document: proof that AI outputs are reviewed, that human judgment is applied at defined points, and that there is accountability for what reaches the client.
Without the SOP, growth creates chaos. With it, growth creates capacity.
A delivery SOP built around five gates ensures that every project passes through the same checkpoints, in the same order, with the same accountability at each step. The gates are not bureaucracy — they are the minimum viable structure that prevents quality failures from reaching clients.
Client brief is collected, clarified, and confirmed before any AI work begins. The intake gate prevents the most common failure mode in AI content work: garbage-in garbage-out. If the brief is vague, the AI output will be vague. The intake gate is where scope is confirmed and ambiguities are resolved.
The AI workflow runs. Prompts are standardized for the niche. Outputs are generated. This gate is fully AI-executed — no human judgment required except to run the workflow correctly. The output of this gate is a draft, not a deliverable.
A human reviews the AI draft against specific quality criteria. Not "does this look good?" — that's not a criterion. The criteria are defined per service type: factual accuracy, brand voice compliance, structural completeness, regulatory language if applicable. This is where governance happens. The reviewer either approves the draft or sends it back to Gate 2 with specific revision instructions.
The approved output is packaged and delivered. The handoff includes any required documentation — version number, review timestamp, the reviewer's name. For regulated industries, handoff documentation is part of the compliance record.
Client feedback is captured and used to improve the intake brief and AI prompts for the next cycle. The feedback gate prevents the same quality issues from recurring.
The MANAGE function requires that identified AI risks be treated through ongoing monitoring, response plans, and documentation. A five-gate delivery SOP is the operational implementation of MANAGE: Gate 3 (human review) is the monitoring checkpoint, the escalation path is the response plan, and handoff documentation is the audit trail. An agency that can show a client their delivery SOP has operationalized NIST MANAGE — not just described it.
Article 14 requires that high-risk AI systems are designed to enable appropriate human oversight during deployment. For AI agencies, Gate 3 is the human oversight mechanism. It must be real — not a rubber stamp. The quality criteria must be specific enough that a reviewer would catch the failures the AI is likely to produce in this niche. If Gate 3 is "skim it and send," Article 14's requirement for effective human oversight is not met.
A delivery SOP that doesn't specify these three things will fail under operational pressure. When a contractor is tired or rushed, vague SOPs get skipped. Specific SOPs get followed.
Not a role category — a specific role or name. "Someone reviews this" is not a SOP. "The lead reviewer approves Gate 3 before any output leaves the system" is a SOP. Accountability requires specificity. When something goes wrong, the first question is: who was responsible at the gate where the failure occurred? If your SOP can't answer that, the accountability structure doesn't exist.
The human review gate needs explicit pass criteria, not a general quality standard. For a B2B content agency: "All facts verified against source. Brand voice checklist complete. No claims not in the client brief. No competitor references." A reviewer applying these criteria will catch the failures that matter. A reviewer applying "looks good" will not. The criteria are derived from your NIST MAP analysis — the failure modes you identified in Module 2.
What happens when a reviewer finds a Gate 3 failure? Back to Gate 2 with revision instructions — who writes those instructions, and what format do they use? Does the failure get logged? Does the client get notified of a delay? Is there a threshold (e.g., three Gate 3 failures on the same project) that triggers a different response? The escalation path is what separates a governance document from a checklist.
You'll apply all three in the lab — building a complete delivery SOP for your core service tier with named accountability, specific Gate 3 criteria, and a documented escalation path.