How to introduce AI into marketing in a controlled way

AI is not introduced into marketing by activating a licence. A reliable rollout takes one bounded use case through seven steps: make use visible, check the prerequisites, design the pilot, prepare the team, evaluate the evidence, approve operation, and scale in a controlled way or roll back. Access to a tool is only a technical possibility. It is neither permission to use data nor approval for client spend or live changes.

The right starting point is small enough for the team to recognise and correct errors, but relevant enough for a result to be measured. SATW recommends a needs analysis, small pilots and clear governance for Swiss SMEs. The SECO SME Portal stresses that employees must understand the limits and critically assess AI predictions and results. That combination of benefit, learning and control is more helpful than a blanket rollout.

Phase 1: make actual use visible

Many introduction programmes officially start from zero even though employees already use freely available assistants. So begin with an inventory without blame. Record the application, purpose, team, account type, data types, outputs produced, recipients, integrations and the role responsible.

The inventory must also make shadow use visible. A private login, copied customer messages or confidential briefings can carry different risks from an approved internal test. The National Cyber Security Centre (NCSC) explicitly recommends not entering personal, sensitive or confidential customer and company data into AI applications and reviewing the terms of use. Until a controlled company framework exists, this conservative boundary is a sensible starting point.

At the same time, communicate what the inventory is for: reducing risk, capturing useful experience and creating clear routes for permitted tests. A blanket ban with no accessible alternative can only make use invisible.

Phase 2: check the prerequisites for exactly one use case

Readiness is not a general maturity grade. A company can be ready for internal summaries and not for automated personalisation. Assess the specific case across seven areas.

Problem: Today’s bottleneck is described, occurs often enough and is relevant to the marketing goal. A simpler process or rule change has been weighed as an alternative.

Responsibility: A specialist role owns the outcome and how the system is used. Data protection, security, IT and legal have clearly defined review rights.

Data: Sources, purpose, quality, access, retention and deletion are known. Test data may be used. Critical data is excluded or explicitly approved.

Evidence: The baseline, reference, test cases, guardrail metrics and minimum improvement are fixed before the pilot.

Process: Human review, exception handling, escalation, stop and manual fallback are workable.

Technology: The account, configuration, integration, logging, versioning and cost limit are clarified.

People: The employees affected understand the purpose, limits, new responsibilities and the reporting route. There is time for training and feedback.

Model access alone is not enough. Capabilities and data readiness therefore belong in the assessment, without deriving a blanket maturity level from them.

Assess each area as “ready”, “with conditions” or “blocked”. A blocked data or responsibility area must not disappear behind a good average score.

Phase 3: design the pilot as a learning contract

A pilot needs a narrow scope: one team, one task, a defined data set and a fixed output format. Historical or internal data are not automatically free of personal information. Where possible, use approved anonymised or synthetic test cases so that real data subjects are avoided. Include difficult and rare cases alongside typical examples.

The pilot plan states:

• the assumption being tested;
• the current reference performance;
• permitted and excluded data;
• test cases and assessment criteria;
• the system’s role and human approval;
• budget and usage limits;
• critical errors and immediate stop points;
• the four possible final decisions.

The final decisions are “stop”, “narrow the scope”, “test again” and “start the operational review”. “Pilot complete” must not automatically mean “roll out”.

In its planning guidance, the Microsoft Cloud Adoption Framework recommends focused proofs of concept to test technical feasibility and value assumptions before broad implementation. It suggests internal starting cases with no customer impact. That is a useful precautionary structure, but not proof of a particular product, a duration or a successful outcome.

Phase 4: prepare the team and the workflow

Training must be tailored to the role. Users need different knowledge than approvers, administrators or the people responsible for incidents. Everyone should know what the system is supposed to do, what it cannot do, which data is off limits, how outputs are reviewed and where observations are reported.

For the specific task, a short exercise is more valuable than a general AI presentation. Have employees assess good, borderline and clearly wrong outputs. Check whether they can find sources, recognise uncertainty and trigger the stop procedure.

Introducing AI often changes invisible work. If AI produces first drafts faster, the review load can rise. If a system flags anomalies, someone needs time to investigate false alarms. So record the work before and after the change, including corrections, escalations and workarounds.

Employees should be able to give feedback without being held responsible for every error. At the same time, it stays clear who carries the final professional decision. “The model suggested it” is not a transfer of responsibility.

Phase 5: evaluate evidence, not impressions

Assess every test output against the schema defined in advance. Depending on the case, this includes factual accuracy, source attribution, completeness, brand rules, rights, data protection, processing time and necessary rework. Measure the entire process time, not just the generation time.

Separate four questions:

1. Does the technology work reliably?
2. Are the outputs usable for the task?
3. Does the entire process improve on the baseline?
4. Can the process be operated with acceptable residual risk?

A “yes” to the first question does not answer the others. Document the model version, configuration, test data set and assessors. Otherwise a later repeat is not comparable.

Include negative results. Perhaps the system saves drafting time but creates too much rights review. Perhaps it only works for a narrow product range. Then a narrower scope may be more sensible than a rollout.

Phase 6: approve operation separately

Live operation needs more than pilot metrics. An operational decision checks:

• production data flows and permissions;
• suppliers, contracts and cost control;
• logging and traceable versions;
• quality and risk monitoring;
• support, the incident reporting route and recovery;
• testing changes to the model, prompt, data or integration;
• manual fallback and safe decommissioning;
• periodic review of purpose and benefit.

Governance accompanies the lifecycle instead of being ticked off once before the start. The OECD principle on accountability stresses the traceability of data, processes and decisions. For operation this means: the team records the version, approval, measurement result, incident and change in such a way that a later decision remains verifiable. The principle is not a Swiss certificate and does not replace a specific legal or security review.

The operational approval must state explicitly which actions the system may carry out. Analysis-only access does not authorise changes. Draft-only permission does not permit publication. An explicitly scoped standing operational permission can cover these actions, so an already authorised action does not need a new approval each time. A technical implementation is not yet consent to a live change.

Phase 7: scale in a controlled way or roll back

Scaling changes the context. More teams, languages, customer groups or data sources can create new errors and rights questions. Extend only one relevant dimension at a time and repeat the matching tests. Watch whether quality falls under higher volume or employees bypass controls.

Define the end early as well. A system is decommissioned when the benefit fails to materialise, costs rise, the supplier changes materially, data is no longer suitable or risks cannot be controlled. Export, deletion, a replacement process and communication belong in the exit plan.

A realistic pace for the introduction

There is no universal number of weeks. Duration depends on data, risk, integration, procurement and the specialist time available. So plan on the basis of decision criteria that have been met rather than calendar optimism. An internal assistant may need less preparation than a system with personal data and customer action. The checks should be proportional to the risk of the use case.

A good programme makes progress visible: inventory created, use case approved, test data released, pilot evaluated, operational decision documented. It does not count the number of activated accounts as adoption success.

What should be different after the introduction

In the end there is not just a tool. The company has a named task, a measurement baseline, trained people, a reviewed data path, documented limits, an incident process and a next decision. Employees know when they may use the system and when not. Managers see benefit and residual risk separately.

This keeps the introduction reversible and able to learn. Marketing can expand a worthwhile case, end a weak one and carry the findings over to the next idea. Controlled introduction does not mean eliminating every uncertainty. It means making uncertainty visible, giving it a person responsible and granting only those permissions justified by the test results.

How maitiq helps: test the pilot as a complete workflow

Take a recurring job, such as preparing a campaign review. Define the data input, the expected decision template and examples of good and faulty results. Also test missing data and contradictory goals. Have the future users walk through the process with real cases approved for that purpose.

The introduction has succeeded when the team uses the process in day-to-day work and less rework arises. maitiq configures the solution for your context, trains the people involved and supports the first operating cycles. That way, the technical setup and actual use are solved together.

How a first pilot with maitiq begins

A limited initial assessment shows which organisational and technical gaps must be closed before the rollout and how maitiq structures the transition into operation. You receive a clearly scoped use case, the open data and control questions, a pilot plan and the criteria for later operation.

Sources and how to read them

The sources have different roles: SATW provides guidance for Swiss SMEs, the SECO interview a practice report from a Swiss SME, the NCSC cyber-safety advice, the OECD a governance principle and the Microsoft Cloud Adoption Framework vendor planning guidance. Provider and association publications 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.