Skip to content

Controlling AI in Google Ads: automation with guardrails

maitiq · Published

What kinds of automation are there?

Smart Bidding

Google Smart Bidding uses Google AI to align bids in individual auctions with conversions or conversion value. This includes target CPA, target ROAS, “Maximise conversions” and “Maximise conversion value”. Smart Bidding sets bids within the campaign and goal configuration. It assumes that the selected conversion is substantively meaningful and technically reliable.

Automatically applied recommendations (auto-apply)

Google can apply selected recommendation types automatically at account level. They can affect bids, keywords, targeting, ads, assets or measurement. The available types can change.

External tools and agents

Third-party providers can read data, generate proposals or, with the appropriate permission, make changes. A marketing label does not say which rights exist. Check API permissions, user role, change path and audit trail.

maitiq is an AI-supported managed service for Google Ads: workflows use evidence to produce proposals with the action, the rationale and the supporting data. A person or an explicitly enabled, bounded policy carries the decision; every implementation is a separate, explicitly authorised and logged step, and the AI-generated text remains advisory. The audit itself is read-only.

So classify systems by permission, not by marketing term:

  • read: retrieve data, no proposal and no change;
  • propose: formulate an action, no approval;
  • decide: record a decision – by a person or an explicitly authorised, bounded policy – with no technical execution;
  • change: carry out the separately authorised change exactly;
  • verify: check the resulting technical state and later observation.

A product can call itself “AI” and only read. A simple rule can change things directly. The risk lies in scope and permission, not in the label. Which strategic role AI can play in operations is covered in AI in Google Ads management; here the focus is on the register, review and stop.

Why is the conversion the most important guardrail?

A bidding automation optimises towards the signal it is given. If a page view is primary, the campaign can generate more page views without delivering valid enquiries. If form start, browser confirmation and the same server-side lead are all counted as primary, the system trains on an inflated target volume.

Check the conversion action that represents the business goal, whether primary or secondary, the campaign goal, counting method, deduplication, value, consent, data freshness, reconciliation with the source system and qualification. The primary flag alone does not decide this: secondary actions included in a custom goal that the campaign actually uses also serve bidding. Several legitimate goals and actions can coexist and do not have to be forced into a single main conversion. A verified website conversion can be the right goal; what matters is that the signal matches the actual business outcome and is not inflated by duplicate or weak events. Conversion-based bidding needs a robust, deduplicated signal; a CRM import is not required for every account. At maitiq, preparing and reconciling offline and CRM conversions is agreed work: consent flags are checked, identifying data is hashed and records are deduplicated. The production upload through Google’s data interface is currently unavailable through this path and is not unlocked by a separate agreement alone. The read-only audit performs no upload and makes no change to the account.

Which fields belong in an automation register?

Before you fill it in, you need a discovery list. Automations sit in at least four places: in the account’s auto-apply settings, in the bidding strategies of individual campaigns, in connected access (user roles, linked accounts, third-party API access), and in scripts and automated rules. Check all four before you call a register complete. The register is a template for your own working file: you fill it in for your account; it does not populate itself from account data.

FieldContent
Automationexact name and provider
Purposespecific business problem
Inputsdata and conversion actions
Levelaccount, campaign or entity level
Scopeaccounts, campaigns and entities
Permissionsread, propose, decide or change
Limitsbudget, bid, target, keyword match type and frequency
Responsibilitythe person responsible on the business side
Approvalstanding rule or individual decision
Evidencesource, change history and place of verification in the account
Monitoringcadence and main signal
Stop ruletechnical or business trigger
Rollback (reversal)recovery path
Review datenext date

For each entry, the register also records status (active, paused, test, unknown), activation source, last change, last review and next due date. Unknown must not be treated as disabled; it triggers a clarification with a date. The change history is partial and time-limited, so the activation source and date may be missing. Account-wide and campaign-specific permissions are recorded separately; access through a manager account alone does not prove an active automation, but its absence does not prove that none exists either.

An entry is good when a second person can review it without further questions: for auto-apply the named recommendation type, otherwise the system and level, the activation source and date as far as the history shows them, affected campaigns, the protected main conversion, the person with the right to stop it, and the next review date. If the activation source or date is missing, record unknown and open a clarification with a date instead of rejecting the entry on that ground alone. “AI optimises the account” is not a register entry, because neither a scope nor a stop rule follows from it. This is what the entry looks like for maitiq: permissions “analyse and propose”, “record the decision” and – where explicitly enabled – “separately authorised execution”; a read-only audit only reads and changes nothing. Approval “individual decision” or an explicitly enabled, bounded policy that approves eligible proposals and triggers the separate authorised execution; checks restrict execution to the authorised account, action and entities, and an exact, recorded decision – for example to exclude precisely named keywords – already authorises the associated protected implementation, with no additional second approval. Evidence “proposal with the action, the rationale and, where a value comparison exists, the old and new value”; implementation “separately authorised, logged step”; responsibility “a named person on your side plus a Client Success Manager”.

How do you review auto-apply per recommendation type?

Google allows automatic application only at account level. There is no campaign-level approval: whoever switches a type on switches it on for the whole account. Review type by type, therefore, not bundle by bundle.

  1. Open the auto-apply settings at account level.
  2. Break bundles down into their individual recommendation types and record each type separately.
  3. Assign each type to its category – ads and assets, bids, keywords and targeting, or measurement. The category determines which business risk to review; a measurement type can change exactly the signal your bidding strategy optimises towards.
  4. Read from the “History” tab for each type: current opt-in status, number of recent applications, time of the last application and date of first activation.
  5. Check the account’s change history for who enrolled the account and when; the history is partial and time-limited.
  6. Review the queue of recommendations scheduled for the day and dismiss unsuitable recommendations before they run.
  7. Read the affected entities of the recent applications and check them against the main conversion, budget limits and documented business rules.
  8. Record the decision with its reason: keep, disable, limited test, unclear or escalate.
  9. When disabling, document the route chosen – clearing the selection and saving in the “Manage” tab, or disabling from the “History” tab.
  10. Save the next review date.

The optimisation score is not a company KPI. A recommendation can fit the platform logic and still contradict the documented business framework.

Two points explicitly belong in the record. First, the official management documentation describes switching a type off, not reversing changes that have already been applied. A stop ends the further operations it names and limits exposure; changes already applied can be traced in the change history and, where the change history offers it, updated or reversed – not every applied recommendation can be reversed. Second, the type catalogue changes. Google explicitly notes that recommendations are adjusted over time; re-check the catalogue of automatically applicable types at every review. A register without a fixed review date therefore goes stale without any visible error.

How do you control Smart Bidding?

Before activation:

  • verify the main conversion;
  • check conversion value and counting;
  • define the affected campaigns;
  • understand the data and the delay;
  • approve budget and target limits;
  • avoid parallel structural changes;
  • define the observation window and stop rule.

After activation, status and learning phase are documented, search terms and traffic mix are reviewed, conversion quality is observed, target or budget changes are versioned, and results are assessed only once the evidence has matured. There is no universal conversion minimum; how much data a strategy needs depends on the campaign, the objective and the specific requirement of the system.

How should external AI generate proposals?

A controlled architecture:

  1. Deterministic code collects permitted evidence.
  2. Identifying or unnecessary data is removed.
  3. The model receives a limited, cleaned extract, not a raw file.
  4. The response schema allows only known references and status values.
  5. Numeric values are calculated outside the model.
  6. Validation rejects incomplete or fabricated responses.
  7. The result remains advisory.
  8. A person decides; alternatively, an explicitly enabled, bounded policy can approve eligible proposals and trigger the separate authorised execution – it is off by default.
  9. A separate, authorised write operation implements exactly what was approved.
  10. The outcome of every executed write operation is logged.

maitiq works on this principle: numbers are calculated deterministically, AI supports formulation and classification in an advisory capacity and under schema validation, and it approves no proposals.

How do numbers stay deterministic and AI output advisory?

The numeric path and the language path are kept separate. Costs, clicks, conversions, time windows, currencies, thresholds and formulas come from validated source data and deterministic code. A model may explain or prioritise these values, or classify them into predefined fields, but it must not introduce a new number as an observation.

A schema-validated response references only known entities, permitted status values and existing evidence. A missing reference, an invalid status value, incomplete coverage or a contradictory number leads to a visible error, not to an apparently successful response with missing information. The output remains advisory and can neither set a human decision nor authorise a change.

Which stop rules make sense?

Stop or escalate on a broken or double-counted conversion signal, an unexpected scope, budget or exposure limits, a leak in click IDs or consent data, more imported conversions than eligible source transactions, a sharply changed search-term mix, changes that cannot be attributed, a missing responsible person, or a decision that cannot be reproduced.

A stop rule needs a person with access, not just a dashboard alert. In maitiq’s managed service, your contact is named: a Client Success Manager receives stop signals and escalates them; the technical rights to stop automations in the account rest with the person you name or with a named provider operator. Actionable recommendations state the action, the rationale and the supporting data; diagnostic alerts and findings about missing data remain visible as such.

What belongs on a stop and rollback card?

Stop and rollback are two actions, not one. A stop ends the further operations it names and limits exposure. A rollback restores an earlier state. A card that mixes the two costs exactly the time it should save in an incident. One card per automation belongs in the register:

FieldContent
Automation IDreference to the register entry
Scopeaffected accounts, campaigns and entities
Triggerobservable signal with data source and review interval
Alert pathrecipient and secondary recipient in case of absence
Stop authorityperson with technical access and authority – on your side or at the provider
Immediate actionfirst action that limits further effect
Exposure limitmaximum tolerated effect until the next review
Prior statetechnical starting value, read before the change
Rollback pathpermitted reversal, where technically supported, and the person who authorises it
Residual effectwhat a stop demonstrably does not end
Verificationwho reads the resulting state and when

Where technical support allows, the prior state is read and saved before the change; anyone who only looks for it during an incident often cannot find it any more. Not every action can be reversed through a product function, and the resulting state cannot be read back automatically everywhere; where that is not possible, manual verification remains the reliable choice. A rollback counts as complete only once the restored state has been read, not when the reversal was submitted. At maitiq, every proposal names the exact action with the old and new value where such a value comparison exists, and otherwise the specific action with its evidence; every implementation – including a reversal – is a separately authorised, logged step.

A stop does not end every effect. Clicks already delivered, costs reported late and conversion data already imported continue to have an effect. The card therefore explicitly records what a stop ends and what it does not.

Who decides, who implements and who verifies belongs in the approval process for Google Ads changes. A stop can mean disabling auto-apply for a type, escalating a bidding automation, or revoking external write access. These are three different rights, and which action is permitted depends on the specific permission. Limits come from the account and the authorisation, not from blanket CHF, percentage or conversion targets. Failed or blocked steps remain visible as such.

How maitiq runs automation with guardrails

maitiq combines regular account analysis with a managed service: workflows read evidence and prepare proposals with the action, the rationale and – where a value comparison exists – the old and new value. A person or an explicitly enabled, bounded policy carries the decision; the policy approves eligible proposals and triggers the separate authorised execution, and it is off by default. Checks restrict execution to the authorised account, action and entities. An unsupervised change outside these limits never happens. This covers the automations in the agreed scope of service, not every external Google recommendation in the account automatically. Ask your current provider the same question: who reviews auto-apply per type, and where is that logged?

Frequently asked questions

Is Smart Bidding the same as auto-apply?

No. Smart Bidding sets auction bids within a strategy. Auto-apply can apply selected Google recommendations automatically at account level.

Should you disable every Google recommendation?

No. Decide by purpose, scope, evidence and risk. Blanket activation or rejection is not governance. At maitiq, every change is covered by a recorded authorisation: either an individual decision or the limits of an explicitly enabled, bounded policy; implementation runs through the separately authorised, logged step. The AI-generated text remains advisory.

Does switching off auto-apply reverse earlier changes?

The official management documentation describes switching a type off, not reversing changes that have already been applied. A stop ends the further operations it names and limits exposure; changes already applied can be traced in the change history and, where the change history offers it, updated or reversed – not every applied recommendation can be reversed. Keep the two clearly separate.

May external AI change things directly?

Technically this depends on permission and integration. Organisationally, every consequential change needs clear limits for approval, scope, audit and reversal. At maitiq, the AI never changes anything directly: the AI-generated text remains advisory and schema-validated; a person or an explicitly enabled, bounded policy carries the decision, and implementation is a separately authorised, logged step.

Does maitiq work fully autonomously?

No. maitiq is a managed service under human control: workflows do the preparation, and an explicitly enabled, bounded policy can approve eligible proposals within your limits and trigger the separate authorised execution. Checks restrict execution to the authorised account, action and entities; every implementation is a separately authorised, logged step.

Sources and how to read them

The five Google Ads help pages below document Smart Bidding, the management of automatically applied recommendations, and applying or dismissing recommendations. They are Google platform documentation – not legal, association or provider-pricing evidence – and must be read accordingly, not as a general market price or proof of success. Information about how maitiq works is available at maitiq.com.

Have maitiq review your specific case.