AI proposes, humans approve: safe ad automation

Every marketing platform now ships an AI that wants to act for you. Build the campaign, write the copy, assemble the variants, push the button. The pitch is always speed, and the reassurance is always the same sentence: a human reviews everything.

2026 is the year that sentence stopped being enough. Human in the loop AI advertising has gone from a talking point to a procurement question, and most vendors answer it with a policy: we recommend review, we default to review, our team reviews. This essay is about a different kind of answer, the one we built into Nubu's AI Campaign Builder: the assistant proposes, humans approve, and the software makes any other path impossible. The assistant cannot act on your workspace, because the tools to act were never given to it. Everything it wants to change arrives as a card with evidence attached, and your click is the only thing that makes it real.

The distinction between a promise of review and an architecture of review sounds subtle. It is the whole difference between AI you can audit and AI you have to hope about. Here is how the mechanism works, in enough detail that you can hold any vendor, including us, to the same standard.

The year marketers stopped taking AI on trust#

The backlash is not hypothetical any more. CNN has suggested 2026 could be the year of anti-AI marketing. Forbes has documented brands discovering that audiences turn on advertising that feels machine made. McDonald's Netherlands publicly pulled a Christmas advert its own audience dismissed as AI slop. And the IAB has reported that more than seven in ten marketers have already been through an AI incident of some kind: hallucinated facts, biased outputs, off-brand content.

Set beside that, one widely shared industry study found the share of organisations requiring human review before high-risk AI actions had fallen from 40 to 25 per cent in six months, while full autonomy with no review at all more than doubled. Read the two findings together and the situation is plain: most teams have already been burned, and most organisations no longer require a human check before the machine acts. Those two facts are not in tension. They are cause and effect.

The lesson from the incidents is not that models are bad at marketing. Most of the public embarrassments were not caused by a model being unusually wrong; they were caused by nobody standing between the model and the audience. A wrong draft is a Tuesday. A wrong publish is an apology. Automation does not create mistakes so much as it multiplies the blast radius of the ones nobody caught, because the same pipeline that produces five hundred good creatives overnight will produce five hundred bad ones just as cheerfully.

Regulators have reached the same conclusion from the other direction. Oversight and accountability obligations for AI in advertising are hardening, particularly in Europe, and we cover what that means for ad teams in our piece on the EU AI Act and AI-generated ads. Between audiences that punish slop, procurement teams that ask harder questions, and rules that expect a named human accountable for the output, "the AI did it" has stopped being an explanation anyone accepts.

So the market question has changed. It is no longer whether AI can build campaigns; it plainly can. The question is what stands between an AI's mistake and your audience, your budget and your brand.

Policy is a promise, architecture is a guarantee#

"A human reviews everything" can be built two ways, and they look identical in a sales deck.

The policy version: the AI has the power to act, and your process says a person checks first. This is a sign on a door saying please knock. It works until the quarter gets busy, until a new joiner does not know the rule, until an agent chains three tool calls at two in the morning because its instructions were ambiguous. Policies degrade silently, and agentic systems are exactly the kind of software that finds the gaps. That collapse in review rates is what policy-grade oversight erodes into at scale.

The architecture version: the AI does not have the power to act. There is nothing to forget, no busy week that wears it down, no cleverly poisoned spreadsheet that talks the model around it. A capability that does not exist cannot be misused, by the model or by anything puppeting the model.

Nubu's assistant is the second kind. An assistant, mechanically, is a language model plus a set of tools it is allowed to use, and it can do nothing that is not in the set. Nubu's assistant cannot render, publish, spend or delete. Those tools do not exist. The toolset simply contains nothing that starts a render, publishes to an ad platform, spends money or removes a record, and that absence is a deliberate commitment, not an accident of the current version. The boundary is not a behaviour we trained in; it is an absence built into the software itself.

This is worth pausing on, because it changes what a bad day looks like. The safety property does not depend on the model behaving well. On its worst day, confused by a hostile file or a badly worded request, the assistant still cannot publish an ad, because there is no lever in the room marked publish.

The same absence covers the sensitive corners of the workspace. The assistant cannot see or touch Settings, members, billing or API keys: nothing in its toolset reads them at all. And it can delete nothing, anywhere: no delete tool exists, and no approval card deletes a record.

Everything consequential that remains goes through one mechanism, and that mechanism is the interesting part.

The proposal card: human in the loop, enforced#

When the assistant wants to change something that matters, whether that is creating a flow, editing a graph, renaming fifty assets, adding glossary claims for a market, or sending finished creatives to an ad account, it cannot simply make the change. What it produces instead is an offer: a card in the conversation describing exactly what would change. The card has exactly two doors: Approve and Reject. There is no third path, no timeout that auto-accepts, no bulk setting that waives review.

Approving is not a rubber stamp on something the AI already did. Approval is the doing. Your click applies the change exactly as if you had made it by hand in the app: the same permission checks (your role, not some elevated AI role), the same validation, the same protection against clashing edits, so a flow a teammate edited mid-review is caught rather than clobbered. At the moment of application the assistant has no privileged side door into your data. The change is indistinguishable from you making it by hand, because mechanically that is what it is.

What makes this reviewable rather than ritual is the evidence on the card. Before you click, a proposed flow shows the exact number of creatives the build would produce. It shows a matrix of the actual rows, each one a creative the build would make, with the real resolved copy on it rather than placeholders. The sample is capped at 200 rows and says so, alongside the exact total, so a cap can never masquerade as a complete list. If the flow localises copy, the matrix shows the resolved lines in any language your connected model can write, so the reviewer reads the words, not a description of the words. And when a proposal edits an existing flow, the card states precisely which market, language and version combinations are added and which are removed.

The detail is the point. You are not approving "the AI's plan" in the abstract, the way you might wave through a summary. You are approving this list of rows, these lines of copy, this exact delta. Review at that resolution takes seconds, and it is review of the thing itself.

Frozen at offer: approval cannot sweep in surprises#

There is a subtler failure mode in approval systems, and most automation gets it wrong: the approval that executes a query rather than a list.

Imagine a card that says "archive every asset tagged Q3". You approve it on Friday. The job runs against the tag. Over the weekend a colleague tagged forty new files Q3, so your Friday approval quietly acted on records you never saw.

Nubu's proposals cannot do this, structurally. The records are frozen at offer: the card carries the specific records the assistant found and showed you, never a filter to re-run later. Approving a card can never sweep in something you did not see. When you approve, each record is re-checked individually; one that was deleted, moved, or entered a state that makes the change unsafe is skipped and reported, never forced. Partial application is treated as a normal outcome and reported honestly, with a reason for every skipped record.

Proposals cannot go stale in your blind spot either. When the assistant corrects an offer, the corrected card supersedes its predecessor and the old card goes inert. An out-of-date approval cannot fire, so there is never a moment where two versions of the same intent are both live and waiting for a click.

Every flow is test-built before you see a card#

Every flow the assistant offers has already been test-built.

That sentence carries a lot of the system's weight, so here it is in slow motion. Before a flow card is even offered, three things happen to the proposed graph, and all three write nothing to your workspace.

First, it is rehearsed: assembled against the current state of your workspace, exactly as it would exist if you approved it, without your real workspace being touched.

Second, the result runs through the same live diagnostics the flow editor canvas runs while you drag nodes around: unwired inputs, missing assets, colliding rows, presets that do not fit the template.

Third, it is test-built by the same build engine the real Build button runs, end to end, producing every row and resolving the copy, while creating nothing.

If that pipeline reports errors, no card appears. The assistant has to repair the graph and propose again; you never see, and therefore can never approve, a flow known to be broken. Warnings block the offer too, which is the strict choice: warnings exist for humans to weigh, and an assistant that waives them on your behalf has quietly become the reviewer. The one exception is explicit. If a warning can only be cleared by changing something you specifically asked for, the assistant must surface the exact warning, ask you, and only then offer the card with your decision attached. It cannot decide for itself that a warning does not matter.

Notice the design decision underneath: there is no separate, assistant-only version of these checks. The diagnostics are the canvas's diagnostics; the build engine is the Build button's. A validator built specially for the assistant would drift from the real one, and its verdicts would slowly become fiction. Because the assistant answers to the product's own checks, the card's central claim, that this graph builds and produces exactly these creatives, is guaranteed by the only opinion that counts: the engine that runs the real build.

It also answers a fair objection: will a human genuinely scrutinise every proposal at five o'clock on a Friday? Perhaps not every row. But approval here is the last line of defence, not the only one. By the time a card reaches you it has survived the same scrutiny your own manual work gets, and what your click confirms is intent: yes, these markets, these versions, this copy. Go.

What the assistant does without asking#

Structural safety is not the same as uselessness, and it would be misleading to present the assistant as a caged thing. Its freedom is split by consequence.

It reads everything, freely. It searches and inspects assets, templates, finished renders and their delivery outcomes, glossaries and claims, and workspace reports. In practice this is where much of the day-to-day value lives: why did Tuesday's build fail, which templates produced the most creatives this quarter, which of these renders actually went out. Reading cannot hurt you, so reading has no ceremony.

It writes directly in exactly two cases: tagging assets and templates, and creating folders. Both are additive, both are immediately visible, both are trivially reversible, and neither can overwrite or destroy anything. That line, additive and reversible, is the boundary for acting without a card. Everything on the other side of it is a proposal.

Two absences complete the picture. The assistant cannot upload files: it can open the upload dialog for you and suggest a destination folder, but the files pass through your hands and the same checks as any other upload. And it cannot delete, as covered above; where something deserves removal it will say so, and you remove it on the page with the permissions your role actually holds.

None of this limits how capable the approved work can be. The flows it proposes can be as sophisticated as anything you would build yourself, including AI nodes that generate or localise copy at build time. The assistant's restraint is about who commits changes, never about how much the machinery can do once you have said yes.

Delivery lands paused, every time#

Follow the chain to its end. Suppose the assistant proposes sending a batch of finished creatives to Google Ads or Meta, and you approve the card.

What arrives on the platform is paused. Always. This is not a default that a hurried teammate can forget to tick: Nubu enforces paused status itself, on every ad, ad group and asset group it creates, on every platform it delivers to. Turning the campaign on happens inside the ad platform, by a person with platform access, after the platform's own review has had its say.

Count the gates between a model's idea and a pound of media spend: the proposal card a human approved; the test build it survived before the card existed; the rendering that produced real files; the upload that landed paused; the human who activates it in the ad account. A model's confidence appears nowhere on that list. The paused landing matters because it extends the human in the loop beyond Nubu's walls: even a change you approved inside our product cannot start spending your budget by itself.

The honest limits#

A piece like this earns its argument by listing what the assistant is not, so here is the list.

It is a paid capability, available on the Business+ plan; see pricing for the current shape.

It runs on your organisation's own AI provider key: connect OpenAI, Anthropic or Gemini and the assistant uses your account. That is also the cost model, and it is deliberately boring: usage is billed by the provider at the provider's raw prices, with no Nubu margin on top. Weekly budgets cap what the assistant may consume, and any build step that would spend on your key asks for a pre-spend confirmation before it starts, so cost surprises are designed out along with content surprises. The reasoning behind that model has its own piece.

It cannot upload files, as above. It cannot author or repair templates: templates are After Effects craft, made and validated by people, and the assistant works with the ones your team has installed. It cannot see or change Settings, members, billing or API keys. It can delete nothing. And it operates within your role: an approval from someone whose role cannot make a change does not make it.

None of this is small print to us. A marketing AI whose vendor lists no limits is describing a demo, not a system.

Can you trust AI to build ad campaigns? Ask these questions#

So, can you trust AI to build ad campaigns? Put that way it is the wrong question, because trust is not a property of a model. It is a property of the structure around the model. The useful questions are architectural, and you can put them to any vendor, including us:

1. Can the AI act without a human click? If review is claimed, is it enforced in code or described in a policy document? Ask what happens when the review step is skipped; in a structural system there is nothing to skip.
2. Do tools for publishing, spending and deleting exist at all? Absence is a stronger guarantee than permission. "It would never" is a prediction; "it cannot" is a fact.
3. Is the thing you approve exactly the thing that executes? Are the affected records fixed when the proposal is made, or does approval re-run a query that may now match more?
4. Does an AI-made change pass through the same validation, permissions and conflict protection as a change made by hand, or does it take a separate route that can drift from the real one?
5. What evidence accompanies an approval: exact counts, the actual copy, a precise added-and-removed diff? Or a summary written by the same model you are meant to be checking?
6. What happens to a stale proposal when the workspace changes underneath it, and can two versions of one intent be approvable at once?
7. Where does platform delivery land: live, or paused until a person with platform access activates it?
8. Whose model key is it, who gets billed, and can spend be capped and confirmed before it happens rather than reported after?
9. Can the AI reach members, billing or credentials at all?

A vendor with structural answers will enjoy this list. A vendor with policy answers will change the subject to model quality, which was never where the risk lived. This is what human in the loop AI marketing has to mean if it is to mean anything: not a value on a slide, but a shape you can find in the software.

Prompts to try#

Three asks that show the contract at work:

• "Rename every asset tagged autumn-sale with the AUT26 prefix and move them into Campaigns / Autumn": the assistant searches to the last page, says how many records matched, and offers one approval card listing the change per record. The records are frozen at offer, so the card can only ever touch the files you saw, and anything that moved in the meantime is skipped and reported.
• "Take the French route out of the Winter flow and add a German-language route for Switzerland": a flow edit card, drafted against the flow's current graph and test-built before you see it, with the combination diff spelling out exactly which market, language and version combinations are added and which are removed.
• "What would splitting the UK route into England and Scotland actually change?": no card at all. The assistant reads the flow, works through what the edit would add and remove, and reports the totals and combinations. A proposal only appears when you ask for one, and approving it is still yours.

The takeaway#

The industry spent two years asking how much marketing work AI can do. 2026 is forcing a better question: how much of that work can be verified before it touches an audience. Our answer is a mechanism rather than a mission statement. The assistant reads everything, drafts anything, and commits nothing. Every consequential change is a card with evidence, applied by your click through the same doors you walk through yourself, and even then delivery lands paused at the far end.

If you are weighing this category for your team, the sister pieces cover the ground around this one: what the AI Campaign Builder actually does day to day, and a primer on creative advertising automation as a whole. You can see the wider product on the features page.

And if you would rather test the claim than read about it, create a workspace, connect a key, and ask the assistant to propose something. The first card it offers, with its row count, its resolved copy and its two buttons, will tell you more about trusting AI with your advertising than any promise we could print.