Who Owns an AI Marketing Decision?

Giving AI access to your ad account does not tell it who can approve moving the budget.

Consider a campaign where a marketer asks for a recommendation, an analyst checks the numbers, and an administrator connects the account. If the software then applies the change, whose approval allowed it to move the money?

I want that answered before the account gets write access. After a bad call, the team needs to know who approved what. After a good one, they need enough of a record to repeat it.

Who owns an AI-assisted marketing decision?

A named business owner owns an AI-assisted marketing decision. The software can recommend, draft, or act within approved limits. The team records the evidence, the approval and its scope, the action taken, and the later outcome. The tool or vendor cannot accept the budget risk on the business owner's behalf.

The owner should have authority over the outcome. That might be a demand generation leader for a channel test, a content leader for a published claim, or a CMO for a change that crosses channels. Assign a backup so a routine absence does not turn into permission to bypass the review.

That assigns responsibility for running the workflow. Providers still have responsibilities for their products; legal liability is a separate question.

This is spoke four in my AI Marketing Operating Model series. The data layer article dealt with which evidence wins when systems disagree. This one deals with who is allowed to act on that evidence. It uses the same access, review, logging, and audit scope covered in AI Governance for Commercial Teams.

NIST's AI Risk Management Framework Playbook calls for documented roles, clear communication, defined human oversight, and executive responsibility for AI risk decisions. For a marketing team, I would name the owner of each decision that can change spend or put a claim in public.

Give the software one of three authority levels

Permission to read a report and permission to change a campaign are separate decisions. I would start with the smallest useful authority and expand it only after reviewed results support the change.

A budget rule needs more than a limit on each move. Several small moves can add up to a change the owner never intended. Define the campaigns in scope, the total allowed change over a stated period, the data the rule depends on, and what makes it pause. Keep publication and audience changes outside that rule unless the owner separately approves them.

Use the account permissions and application controls to enforce those limits. A prompt saying "do not exceed the approved budget" is not an access control. OWASP's 2025 guidance on excessive agency recommends limiting tools and permissions, requiring approval for high-impact actions, and enforcing authorization outside the model.

The administrator can configure access. The reviewer can check evidence. The business owner decides what authority is appropriate. One person may hold more than one role on a small team, but the roles still need to be explicit.

Put the review before the consequence

When an action requires individual approval, review the proposed budget move, email, or page change before the software executes it. After an action that required approval has happened, the review is too late to authorize it.

The reviewer needs the exact proposed action, the evidence behind it, relevant conflicting evidence, and the limit it would consume. For a page change, show the current passage beside the proposed passage and the source for any new claim. For a media change, show the affected campaigns, current settings, proposed settings, and measurement period.

The reviewer must be able to reject the action or send it back with a reason. "Approved" should identify the version approved. If the wording, audience, destination, budget, or supporting evidence changes afterward, the workflow needs another review unless that change is already inside the recorded authority.

Silence is not approval. If an approval expires, hold the action and notify the backup. Hold it when required evidence is missing or too old, too. Set the acceptable age of the evidence for that decision rather than applying one freshness rule to every marketing report.

My human-in-the-loop AI review guide covers the reviewer's context and authority in more detail. Adding an approval button does not solve a queue that nobody has time to inspect. Give the reviewer time, show the material needed to decide, and stop asking them to approve work that does not need their judgment.

Keep a decision log that explains the call

The record should show what the team believed before the result arrived. Otherwise, people can reinterpret the original plan to fit whatever happened.

For each consequential decision, record:

• What you expected and what result would change your mind.
• The exact proposed change, affected systems, and conditions that must stay fixed.
• The evidence used, its source and date, and anything unresolved at approval.
• The software's authority, the named owner, and the approver's decision, time, and scope.
• The action that actually happened, including a failed, skipped, or reversed action.
• The later outcome, the observation period, and any correction to the original assumption.

For an action within standing limits, record who approved the rule and which version was in force. The system should log each execution against that rule. Do not describe the owner as personally reviewing every action if they approved the conditions once.

Use the same reference for the recommendation, approval, and actual action. Save the executed model and workflow versions where they help explain the result. A recommendation log that ends before the campaign update cannot show whether the approved action happened.

The AI Audit Log covers that technical record. Keep the decision log small enough to use. Source references and controlled versions can be more useful than copying every private document into another database. Limit access to the log and set a retention rule for the information it contains.

An approval proves permission. It does not prove the recommendation was correct or that the action caused the later result. Use the test and measurement rules established before launch. The Test Before the A/B Test covers that preparation.

Make stopping the workflow somebody's job

Name who can pause the automation, who investigates, and who can authorize a restart. The person watching the system needs permission to stop it without waiting for the same workflow to explain why it should continue.

For a marketing workflow, I would test the stop control before granting write access. Confirm that it blocks new changes, identifies work already queued, and shows what has already happened. An email already sent cannot be recalled by pausing the next model call. A campaign change may need a separate reversal in the ad account.

Escalation should say where the issue goes and what the team does while waiting. A missing source can return a recommendation for review. A breached spending limit should block execution. An unexpected public claim should pause publication and reach the person responsible for that claim.

NIST's Manage Playbook includes mechanisms to disengage or deactivate systems whose performance no longer fits their intended use. In a marketing workflow, the stop control and restart authority need to work in the connected systems, not only in the AI dashboard.

A Chief AI Officer can help set these rules across workflows. That does not make that person the approver for every headline or bid change. The marketing owner still answers for the decision. The people who configure access and keep the system running still answer for their work.

Before giving a workflow permission to act, write the owner's name beside the decision and test whether that person can stop it.

Frequently asked questions

Who is accountable when an AI marketing recommendation is wrong?

The named business owner is accountable for accepting the marketing decision and responding to its outcome. Reviewers, administrators, and providers remain responsible for their own work. Keep the evidence and approval record so the team can identify whether the failure came from the recommendation, review, permissions, or execution. This operating rule does not determine legal liability.

What authority should marketing AI have?

Give marketing AI permission to recommend, draft, or act within explicitly approved limits. Start with the smallest useful authority. Define the systems, actions, cumulative limits, evidence requirements, and stop conditions before allowing execution. Require a new approval when an action falls outside that scope.

What is a human-in-the-loop review for marketing?

A human-in-the-loop marketing review is a decision made before a consequential action. An authorized person inspects the exact proposal and supporting evidence, then approves, rejects, or requests changes. The review must control whether the action proceeds and preserve which version the person approved.

What should an AI decision log record?

An AI decision log should record the prior belief, proposed change, source evidence and dates, authority limits, owner, approver, approval scope, actual action, and later outcome. For automatic actions, link each execution to the approved rule. Retain relevant model and workflow versions, corrections, and source references without copying unnecessary sensitive data.

Should agencies or vendors own AI decisions for a client?

The client should name the business owner and approve what the agency or vendor may do. An external team can research, draft, review, or execute within that authority. It should not silently decide which business risks the client accepts. Both teams need to know who approves exceptions and who can stop the work.

Sources

Primary documentation reviewed October 6, 2026. The three authority levels and marketing examples are my operating recommendations. They are not presented as a NIST standard or vendor capability.

• NIST AI Risk Management Framework Playbook: Govern, particularly GOVERN 2.1, 2.3, and 3.2, for responsibilities and human oversight.
• OWASP LLM06:2025, Excessive Agency, for limited permissions, authorization, and approval before high-impact actions.
• NIST AI Risk Management Framework Playbook: Manage, particularly MANAGE 2.4, for disengagement and deactivation.

About the author

Jeff Brokaw is a CMO and Certified Chief AI Officer who builds the commercial systems around AI, including workflow design, measurement, access, and human approval for consequential actions.