When AI stops answering and starts configuring

Letting AI read your data is one decision. Letting it create a conversion integration, touch an audience or delete a report is a much bigger one — and it needs four specific locks.

The first phase of AI on business data is comfortable: it reads, joins, answers. If it is wrong, the cost is a wrong answer someone checks.

The second phase is where the value is and where the fear lives: the AI creates the conversion integration, adjusts the filter, publishes the report, deletes what was orphaned. Now an error is not a sentence — it is a configuration producing effects in the world, on campaigns spending money.

That transition should not be a matter of courage. It is four locks, and they are specific.

1. A dry run before it counts

Every write action needs a mode that does everything except write: it validates the input, assembles the result, shows what would exist — and persists nothing.

This is not a convenience detail. It is what turns "create an approved-sale integration to Meta" into something reviewable: you read the filter it built, the field mapping and the generated code, and only then authorise.

The dry run has to be guaranteed in the server, not promised in the text. A dry run that depends on the model behaving is not a dry run.

2. Confirm before destroying

Destructive actions deserve their own treatment: a call without explicit confirmation does not delete, it returns what would be deleted. The second call, with the confirmation, executes.

The detail that matters is what the first call returns. It is not enough to say "I will delete report X": it has to say what else depends on it — which queries would be orphaned, which are shared with other reports and therefore should not be touched.

3. Write scope cannot be a promise

It is common for a connector to declare which tools read and which write. Declaring is not enforcing: if the server does not refuse the write when the token only has read, the declaration is documentation.

We saw this in an audit: the newer tools checked scope, and the older ones, registered through a different path, executed without checking anything. A read-only token could create and delete datasets.

The fix was not to list the old tools by hand. It was to derive scope from each tool's own annotation — a hand-written list ages in silence, and the next tool is born outside it.

4. Proof against real data before publishing

This one prevents the most damage, and it is the most marketing-specific. When AI assembles a conversion filter, that filter can be syntactically perfect and match nothing — or match everything.

The lock is running the filter over the account's most recent real events before publishing, and returning the result: of these thirty events, this many would pass, this many would be dropped, and here are examples of each. Zero passing is a loud warning.

Without it, the first news that the filter was wrong arrives days later, through the ad platform's report — and what happened in between was a campaign learning from the wrong signal.

What stays out, on purpose

Not everything should be within reach. Changing who has access, deleting people's data and touching billing are owner decisions, and convenience is not sufficient reason to automate them.

The rule we use is simple: if the mistake cannot be undone by whoever authorised it, the action does not go on the AI's menu.

In CrazyLeads, creating an integration has a server-guaranteed dry run, deletion requires confirmation and returns what depends on the item, write scope is derived from each tool's annotation, and the filter is tested against the account's real events before anything is published.