AI in Marketing: How to Select, Test and Govern Use Cases

Artificial intelligence in marketing is not one product or one method. It is a broad set of systems that infer how to produce an output, such as a prediction, recommendation, classification, generated asset or decision, from a set of inputs and objectives. The useful question is therefore not whether a business should adopt AI. It is whether a particular system is a suitable way to change a defined marketing decision.

That distinction matters. Many valuable marketing processes are ordinary automation: a scheduled email, a fixed suppression rule, a dashboard calculation or a workflow triggered by a known event. These can be reliable and economical without a learned model. AI becomes relevant when the task involves inference that cannot be specified adequately through a simple fixed procedure, or when a model can be shown to improve a decision at acceptable cost and risk. (1)

This guide explains what qualifies as AI in marketing, where the different capabilities fit, how to select a use case and what evidence is needed before scaling it.

What This Article Delivers

What Counts as AI in Marketing?

A practical definition is a machine-based system that infers from its inputs how to generate outputs such as predictions, content, recommendations or decisions. (1) In marketing, those outputs may support a human decision or directly affect what a customer sees.

Examples include:

• estimating the probability that an account will renew;
• ranking products for a customer or content for a reader;
• classifying a support message by topic;
• generating a first draft of advertising copy;
• selecting a treatment subject to eligibility and safety rules;
• answering a customer question through a conversational interface.

Not every automated process is AI. The following distinctions prevent inflated claims and help teams choose the simplest sufficient method.

The categories overlap in practice. A marketing system may combine fixed eligibility rules, a statistical forecast, a machine-learning ranker and a human approval step. The presence of a model does not make the whole process autonomous, and the surrounding controls may matter more than the model itself.

I spent a decade on the account side of an enterprise marketing platform, and I want to be blunt about what the AI in that category usually was. The capability that moved client numbers was predictive segmentation. A client picked a segment and the platform did the rest in the back end. The measurable value then appeared somewhere else entirely, in the return on ad spend once those segments reached the large advertising platforms. That is a useful decoder when you read a vendor’s AI claims. I should disclose that I now run a company in this market, so weigh my scepticism accordingly: this is a commercial observation from my own accounts, not a technical audit of any product.

The Main AI Capabilities Used in Marketing

A capability map is more useful than a list of tools, because it starts with the output and the evidence needed to trust it.

The specialist pages named in the final column are AI-driven personalisation systems for recommendation and ranking, AI content generation for produced assets, conversational AI in marketing for natural-language interaction, and dynamic creative optimisation where optimisation involves creative assembly.

A capability is not a business case. “Use recommendation” is not yet a defined proposal. A valid proposal identifies the decision that changes, the available alternatives, the people affected and the outcome against which the change will be tested.

Start With the Problem, Not the Model

A sound AI marketing strategy begins with an operational decision. For example:

• Which enquiries need urgent human review?
• Which products should be considered for a recommendation slot?
• Which accounts should receive a retention offer?
• Which content claims require factual review?
• How much stock should be allocated to a region?

This is more precise than objectives such as increasing engagement or creating one-to-one experiences. It also makes a non-AI baseline possible. Without a baseline, a team cannot tell whether the model adds value or merely adds cost.

The baseline may be:

• the current human process;
• a fixed rule;
• a popularity ranking;
• a simple forecast;
• random assignment among eligible options;
• no intervention.

Practical machine-learning guidance recommends establishing metrics and a simple baseline before increasing model complexity. (2) A basic approach can be easier to validate, cheaper to operate and more reversible. Machine learning is not inherently preferable to a rule. It has to earn its place through evidence.

A Use-Case Selection Framework

Assess every proposed AI use case against the same questions. This prevents highly visible ideas from bypassing ordinary investment and risk discipline.

A use case is stronger when the decision recurs often enough to justify investment, when feedback arrives within a useful period, when the outcome can be measured and when mistakes can be detected and corrected. A rare, ambiguous or irreversible decision may require a very different method and a higher level of assurance.

Task Suitability: When AI May Help

AI is more plausible when several conditions hold.

1. There is a repeatable decision. The task occurs often enough for a system to be tested and improved.
2. Relevant examples exist. Historical or experimental data contain inputs and outcomes that relate to the proposed task.
3. The output can be evaluated. Teams can define what counts as a useful prediction, recommendation, answer or asset.
4. The operating context is sufficiently stable. Patterns learned from the past have some relevance to deployment conditions.
5. The organisation can act on the output. A score is not useful if there is no feasible treatment, workflow or owner.
6. Errors are manageable. The system can abstain, escalate, suppress or revert where confidence or eligibility is inadequate.
7. A simpler method is insufficient. The expected improvement justifies the added complexity.

AI may be a poor choice when the objective is unclear, the labels represent a weak proxy, the intervention is unavailable, the expected volume is low, outcomes take years to observe, or the organisation cannot monitor downstream effects. NIST’s implementation material explicitly notes that AI may not be the right solution for a business task and recommends weighing it against non-AI alternatives. (3)

Data Requirements: Useful, Permitted and Representative

Data quantity alone does not create a valid system. A team needs data that are relevant to the decision and collected in a way that supports the intended inference.

Before development, document:

• the unit of prediction or decision;
• the time at which a decision is made;
• which information is genuinely available at that time;
• the outcome or label and how it is produced;
• missingness, delay and measurement error;
• whether historical actions influenced the outcome;
• population coverage and exclusions;
• permitted uses, retention and access controls;
• how deletion, correction and consent changes will reach the system.

A common failure is information leakage: training a model with information that would not have existed when the live decision was made. Another is selective logging, where a team records only the items that were shown, accepted or completed and loses the alternatives. Both can make a historical model look more capable than it is.

Real-time data are not automatically better data. A recent signal may be incomplete, noisy, misidentified or irrelevant. A slower batch process may be sufficient for a weekly decision and much easier to test and control.

Where personal data are involved, legal and fairness questions begin at problem formulation, not after the model is trained. The ICO distinguishes data-protection fairness from narrower algorithmic measures and highlights the importance of target variables, proxies, assumptions and lifecycle effects. (4) Its AI guidance was updated on 15 March 2023 and, as at 28 July 2026, carries a notice that it is under review following the Data (Use and Access) Act.

For detailed treatment, see ethical consumer-data use and responsible AI practice in marketing.

Prediction Is Not Causal Effect

A prediction estimates an outcome under the conditions represented in the data. It does not necessarily estimate what will happen because the marketer takes an action.

A customer with a high probability of renewal may renew without an offer. A customer with a high probability of purchase may be easy to predict but unaffected by a message, or even deterred by one. Propensity and treatment responsiveness are different questions.

This distinction affects budget allocation. Ranking people by likely purchase can direct spend towards customers who would have bought anyway. To estimate incremental effect, an organisation usually needs randomised or otherwise credible causal evidence. Large advertising field experiments show why observational attribution can mislead when targeting creates selection bias, and why even randomised estimates can require very large samples when customer outcomes are volatile. (5)

The practical rule is:

• use predictive validation to test whether the score estimates the stated outcome;
• use experiments to test whether acting on the score changes outcomes;
• compare incremental value with intervention and system costs.

What Evidence Is Required Before Scale?

Different capabilities need different forms of evidence.

Prediction and Classification

Check discrimination, error rates, calibration, later-cohort performance and subgroup results. A well-calibrated model attaches probabilities that correspond reasonably to observed frequencies in relevant evaluation data. Accuracy alone can hide severe errors in probability estimates or in minority groups.

Recommendation and Optimisation

Offline ranking metrics can help compare candidate models, but final business claims require online testing. A published account of a large video platform’s production recommendation system describes using offline precision, recall and ranking loss for iteration while relying on live A/B tests for final decisions, because offline and online results do not always agree. (6)

Generative Systems

Evaluate the actual work product: factual correctness, support for claims, brand fit, harmful content, intellectual-property risk, disclosure requirements and editorial effort. Output volume is not a benefit if review and correction costs grow at the same rate.

Conversational Systems

Measure task completion, answer correctness, safe refusal, hand-off success, containment only where it benefits the customer, and the consequences of failed or delayed escalation.

Any Deployed System

Measure customer outcomes and harms, not only model outputs. A lower prediction error is not itself proof that customers receive a better service or that the business creates incremental value.

Designing an AI Pilot

A pilot is an evidence-generating stage, not a smaller launch without controls.

A defensible pilot includes:

1. A written hypothesis. State the decision, population, intervention and expected outcome.
2. A baseline. Measure the current method before comparing a new one.
3. A limited population and channel. Choose a scope representative enough to learn from but reversible if the system fails.
4. Predefined primary metrics. Avoid declaring success from whichever metric happens to improve.
5. Guardrails. Include complaints, opt-outs, service contacts, exclusions, inappropriate outputs and subgroup disparities where relevant.
6. A valid comparator. Use a randomised control where practical, or explain the limitations of another design.
7. Exposure logging. Record what was available, what was selected, what the customer received and the model or rule version.
8. Operational observation. Measure latency, failure rates, manual workload, override behaviour and integration defects.
9. A minimum test period and sample rationale. Account for seasonality, novelty and delayed outcomes.
10. Stop and rollback criteria. Pause when guardrails breach or the system cannot be diagnosed safely.

Do not scale because a prototype produces plausible examples. A prototype shows that a system can run. A pilot has to show that it changes the intended outcome under realistic conditions.

Implementation Stages

1. Frame the Decision

Define the customer or business problem, the decision owner and the non-AI baseline. Reject proposals that cannot state the action being changed.

2. Map Data and Risk

Document inputs, labels, affected groups, permitted uses, error costs and potential downstream effects. Decide whether the use is proportionate before building.

3. Build the Simplest Credible Approach

Start with a rule, a statistical model or a basic model that creates a clear baseline. Practical machine-learning guidance emphasises simple first models and reliable infrastructure. (2)

4. Validate Technically

Use held-out and later-period data. Test calibration, errors, subgroup performance, robustness and training-serving consistency.

5. Integrate With Controls

Add eligibility, suppression, customer choices, human review, monitoring, rollback and versioning. Test the surrounding pipeline independently of the model.

6. Run a Controlled Pilot

Compare with the baseline and measure customer, commercial, operational and guardrail outcomes.

7. Make an Explicit Scale Decision

Choose to scale, revise, restrict or stop. Record the evidence and the unresolved limitations.

8. Monitor and Retire

Track drift, incidents, costs, overrides and changing legal or business conditions. A system that once added value may later need retraining, redesign or decommissioning. (3)

Build Versus Buy

The decision is rarely binary. An organisation may buy a platform, use a hosted model, licence data, develop a decision layer internally and retain human workflows.

Consider Buying When

• the capability is standard rather than differentiating;
• the provider offers mature integration, monitoring and support;
• internal model-development capacity is limited;
• time to a controlled pilot matters;
• the organisation can obtain sufficient documentation and contractual rights.

Consider Building When

• the decision logic or the data is strategically distinctive;
• required constraints cannot be expressed in a product;
• the organisation needs direct control over objectives, experiments and monitoring;
• expected scale justifies long-term engineering and operational investment;
• the team can support the system throughout its life.

Ask Any Supplier

• What exactly is learned, generated or optimised?
• Which customer data enter the system, for what purpose, and where are they processed?
• Can the organisation define eligibility, suppressions, guardrails and fallback behaviour?
• Which offline and online metrics are available?
• Can decisions, inputs, versions and exposures be logged?
• How are models updated, and can updates be tested before production?
• What documentation exists for training data, limitations, security and subprocessors?
• Can the service be paused, exported or replaced?
• Who owns generated assets, derived data and evaluation results?
• Which costs grow with decisions, tokens, storage, channels or support?

Treat vendor benchmark claims as evidence about the vendor’s test, not as proof of performance in your population. Third-party systems still require contextual evaluation and monitoring. (3)

The Full Cost of an AI Marketing System

Licence or model-use fees are only one category. Include:

• data collection, cleaning, labelling and governance;
• integration with customer, content, product and channel systems;
• experimentation and analytics infrastructure;
• model development or configuration;
• security, privacy and legal review;
• human review and exception handling;
• monitoring, incident response and retraining;
• content, inventory or treatment management;
• supplier management and audit;
• change management and staff training;
• fallback operations and eventual migration or retirement.

Machine-learning systems can accumulate hidden technical debt through data dependencies, feedback loops, configuration, monitoring and changes in connected systems. (7) A business case should therefore include whole-life operating cost, and the cost of being unable to explain or reverse a decision.

Benefit and Risk Assessment

Evaluate benefits and risks in the same unit of decision.

Potential Benefits

• fewer manual decisions or shorter handling time;
• improved relevance or discovery;
• better allocation of limited inventory or budget;
• earlier identification of service needs;
• more consistent classification or review;
• faster production with controlled editorial effort.

Potential Risks

• incorrect, inappropriate or exclusionary outputs;
• over-contacting or over-targeting customers;
• amplifying historical patterns or popularity;
• using weak proxies for customer need;
• reducing choice or diversity;
• misleading generated claims;
• privacy, security or data-rights failures;
• operational dependence on a supplier or a fragile pipeline;
• optimising an easy metric at the expense of customer value.

A portfolio should not rank projects only by expected revenue. Add affected population, error severity, reversibility, evidence quality, legal sensitivity, operational dependence and monitoring burden.

Human Responsibility

“Human in the loop” is not a complete control. Responsibility has to sit with people who have authority, time, information and a realistic ability to intervene.

For each use case, identify:

• the business owner of the objective;
• the technical owner of the system;
• the data owner;
• the person or team monitoring outcomes;
• the route for customer challenge or correction;
• who can pause the system;
• who approves material changes;
• who decides that the system should be retired.

A nominal reviewer who approves hundreds of outputs without context does not provide meaningful oversight. Human review should be designed around identifiable failure modes and supported by logging, explanation and escalation.

Portfolio Governance: Scale Evidence, Not Enthusiasm

Manage AI use cases as a portfolio with consistent stage gates.

NIST organises AI risk work around governing, mapping, measuring and managing, with governance operating across the other functions. (3) Marketing teams can apply that logic without turning every low-risk experiment into a bureaucracy. Assurance should be proportionate to potential impact.

The campaigns brands asked me for most often were the ones that looked most impressive internally. Tab title changes. Social proof widgets. Homepage slider personalisation. One tab title test came back at around a forty-five per cent conversion uplift, changing the title for people who had switched tabs, with a message too long for the tab to display. I was entitled to claim that number and I never believed it. The slider work was not broken, but the hours two teams poured into it left it at or below an ordinary campaign on cost and benefit. These things get requested because they market well inside the company. That is a commercial observation about internal incentives.

Questions to Ask Before Approving an AI Marketing Use Case

• What decision changes?
• Why is the current method inadequate?
• What is the simplest credible baseline?
• Which output is inferred, and from what inputs?
• What does the score, label or generated asset not tell us?
• Who may be helped, excluded or harmed?
• How will we know whether the intervention caused an improvement?
• Which metrics could improve while the customer experience worsens?
• Who can override, pause or retire the system?
• What evidence must exist before the next stage?

Conclusion

AI in marketing is best treated as a set of decision capabilities, not as a general strategy or an automatic source of growth. Begin with a defined problem, compare the proposed system with a non-AI baseline, test it in the context where it will operate, and scale only when customer, commercial, operational and risk evidence support the decision.

For the technical design of ranking, recommendation, propensity and next-best action, continue to recommendation and next-best-action models. For organisation-wide governance, detailed legal classifications and formal impact assessment, use the ethics of AI in marketing.

References

1. Organisation for Economic Co-operation and Development (OECD.AI), authored by Marko Grobelnik, Karine Perset and Stuart Russell. What is AI? Can you make a clear distinction between AI and non-AI systems? Policy explainer on the revised OECD definition of an AI system. No reference number shown on the page. Published 6 March 2024; no separate last-updated date shown. Not under review or in draft at the date of checking. Not UK law: an intergovernmental policy definition, and the page states that the authors’ views do not necessarily represent the OECD or its member countries. https://oecd.ai/en/wonk/definition

2. Google for Developers, authored by Martin Zinkevich. Rules of Machine Learning: Best Practices for ML Engineering. Official engineering documentation. No reference number. No original publication date shown on the live page; last updated 25 August 2025 UTC. Not under review or in draft. Not UK law and not a regulatory source: company technical documentation produced by an organisation that develops and sells AI and cloud services, so it carries a commercial interest. https://developers.google.com/machine-learning/guides/rules-of-ml

3. National Institute of Standards and Technology (NIST), US Department of Commerce. Manage, a page of the official AI Risk Management Framework Playbook, used together with Artificial Intelligence Risk Management Framework (AI RMF 1.0). Framework document and companion playbook. Reference number NIST AI 100-1; DOI 10.6028/NIST.AI.100-1. AI RMF 1.0 published January 2023; the Playbook page shows no publication or last-updated date and was checked on 28 July 2026. Under review: the live Playbook states that the AI RMF 1.0 is being updated and that the Playbook will be updated after the AI RMF is revised. No AI RMF 2.0 had been issued as at 28 July 2026. Not UK law: voluntary US federal guidance, sector-agnostic and not marketing-specific. https://airc.nist.gov/airmf-resources/playbook/manage/ and https://doi.org/10.6028/NIST.AI.100-1

4. Information Commissioner’s Office (ICO). Guidance on AI and data protection. UK regulator guidance; not a statutory code of practice. No reference number shown on the landing page. Updated 15 March 2023; status checked 28 July 2026. Under review: the live page states that, due to changes made by the Data (Use and Access) Act, the guidance is under review and may be subject to change. UK source and the applicable regulator for UK data protection. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/

5. Randall A. Lewis and Justin M. Rao. The Unfavorable Economics of Measuring the Returns to Advertising. Peer-reviewed journal article, The Quarterly Journal of Economics, volume 130, issue 4, pages 1941 to 1973. DOI 10.1093/qje/qjv023. Published online 6 July 2015; issue dated November 2015; no subsequent update. Not under review or in draft. Not UK law: an academic study of US digital-advertising field experiments. https://doi.org/10.1093/qje/qjv023

6. Paul Covington, Jay Adams and Emre Sargin, Google. Deep Neural Networks for YouTube Recommendations. Peer-reviewed conference paper, Proceedings of the 10th ACM Conference on Recommender Systems (RecSys 2016). DOI 10.1145/2959100.2959190; ACM ISBN 978-1-4503-4035-9/16/09. Published September 2016; no subsequent update. Not under review or in draft. Not UK law: an industry research paper describing the authors’ own commercial platform, with a corresponding interest in it. https://doi.org/10.1145/2959100.2959190

7. D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-François Crespo and Dan Dennison, Google Research. Hidden Technical Debt in Machine Learning Systems. Peer-reviewed conference paper, Advances in Neural Information Processing Systems 28 (NIPS 2015), pages 2503 to 2511. No DOI shown on the publisher record. Published 2015; no subsequent update. Not under review or in draft. Not UK law: an engineering experience report from a commercial research group. https://research.google/pubs/hidden-technical-debt-in-machine-learning-systems/

Position as at 28 July 2026. Regulatory guidance and technical standards change. Reference 3 is expressly being revised and reference 4 is expressly under review following the Data (Use and Access) Act, so both should be rechecked before any decision is taken on the basis of this article.

Frequently Asked Questions