AI Adoption Is Still a Translation Problem.

AI demonstrations have become much easier to build. Enterprise adoption has not become equally easy.

Modern large language models can interpret loosely structured requests, handle spelling mistakes, generate code, retrieve documents and call external tools. They are significantly more flexible than the conversational-AI systems I worked with earlier in my career.

But greater capability does not automatically lead to greater adoption.

A professional will not rely on an AI system simply because it produces a fluent answer. They need to understand whether the answer fits the business context, what evidence supports it, how it can be verified and what will happen if it is wrong.

That is why I believe AI adoption is still fundamentally a translation problem.

This does not simply mean translating a business request into a better prompt. It means translating an ambiguous business need into a complete human–AI workflow in which:

• the expected business return is clear;
• the consequences of error are understood;
• the system receives the right business and technical context;
• outputs can be verified efficiently;
• human judgment remains at the appropriate decision points; and
• performance can be measured after implementation.

Without this translation layer, even an impressive AI prototype may remain something people admire in a demonstration but hesitate to use in their day-to-day work.

My perspective across different generations of AI

My view has been shaped by working with AI and analytics from several angles.

At Standard Chartered Bank, I worked on Stacy, its enterprise virtual assistant in Hong Kong. The system used NLP models and contextual-vector representations to understand customer enquiries across different banking intents.

It could answer general banking questions and connect to backend services. For example, when a customer asked for a nearby ATM or branch, the system could call a location API and return the relevant information.

Human oversight was also part of the operating model. Human annotators reviewed conversation logs across all FAQ intents—not only conversations already identified as incorrect. This helped the team evaluate answer quality, identify emerging enquiry patterns and prepare training data for continuous model improvement.

Later, at WPP Media, I led marketing analytics and marketing-mix-modeling work and supervised the development of an internal GenAI-assisted MMM workflow before my departure.

During my current career break for full-time parenting, I have been studying LLM engineering through an online course and applying techniques such as chat-completion APIs, retrieval-augmented generation and tool calling to six proof-of-concept projects for marketing analytics.

Working across these different generations of technology has reinforced one point for me:

The model may change, but businesses still need to translate uncertain technology into a workflow that people can use responsibly and confidently.

The technology has advanced, but uncertainty remains

Some capabilities associated with modern LLM applications have precedents in earlier conversational-AI systems.

Tool calling, for example, is more flexible today, but connecting a language interface to an external system is not entirely new. Stacy could understand a request, identify the relevant intent and information, call an API and return the result.

Human-in-the-loop governance is not new either. Reviewing conversations, evaluating whether answers were appropriate and feeding that information back into model improvement were already important parts of operating an enterprise chatbot.

Modern LLMs have expanded the range of possible interactions. Instead of working mainly within a defined collection of intents and responses, they can interpret open-ended questions, synthesize information, generate new content and select among multiple tools.

However, an LLM remains a probabilistic model. It generates a response token by token based on learned probability distributions. Its answers can therefore be unsupported, inconsistent or incorrect.

Errors caused by model uncertainty are not new. Traditional NLP systems could misclassify an intent, misunderstand an entity or return an inappropriate answer.

What has changed is how an error can appear.

A generative model can produce a detailed, coherent and highly convincing explanation even when part of that explanation is wrong. The fluency of the answer can make it more difficult for a non-expert to distinguish plausibility from correctness.

This does not mean that LLMs are unsuitable for enterprise use. It means that the model should not be treated as the entire solution.

The real challenge is confidence to act

When employees hesitate to use an AI system, the problem is sometimes described as resistance to change or insufficient AI literacy.

Those factors can matter. But hesitation can also be a rational response to professional risk.

Consider two different applications:

1. An AI assistant drafts Python code that an analyst can inspect, test and execute.
2. An AI assistant interprets marketing-mix-modeling results and recommends reallocating a significant media budget.

Both may create value, but the consequences of an incorrect output are very different.

In the first example, the analyst can inspect the code and identify an error before it affects a business decision. In the second, a plausible but incorrect interpretation could influence a financially significant recommendation.

The model does not carry accountability for the result. The professional using its output does.

Professionals therefore need more than a powerful model. They need to know:

• what the system is designed to do;
• what it should not be used for;
• what evidence supports its output;
• which assumptions have been made;
• how efficiently the result can be checked;
• when expert approval is required; and
• how the system responds when the available information is insufficient.

The objective should not be blind trust or maximum confidence. It should be calibrated confidence.

People should be able to rely on well-supported outputs while recognizing when the evidence is weak and escalation is necessary.

Confidence is not created by telling users that a model is powerful. It is earned through system design, transparent controls and repeated performance.

AI adoption requires both confidence and business return

Risk management is only one side of the adoption challenge.

An AI system can be carefully controlled and still fail to achieve adoption because it does not solve a valuable enough business problem.

A useful way to think about this is:

Business value × confidence to act = practical adoption

If the value is unclear, there is little reason to change an existing workflow. If users are not confident enough to act on the output, the theoretical value will never be realized.

A credible AI initiative should have a measurable path to at least one of four forms of business return.

1. Revenue generation

Can the solution improve conversion, retention, product discovery, marketing performance or commercial decision-making?

2. Cost reduction

Can it lower servicing costs, reduce manual processing, avoid rework or decrease reliance on external support?

3. Productivity improvement

Can it accelerate research, coding, data preparation, quality assurance or first-draft analysis so that professionals have more time for higher-value work?

4. Competitive advantage

Can it improve decision speed, make proprietary knowledge more accessible, enable a differentiated service or create a capability that competitors cannot easily reproduce?

These categories are only starting points. Each initiative still needs a measurable hypothesis.

For example:

• How many hours could be saved?
• How much faster could a task be completed?
• How many clarification or revision cycles could be avoided?
• What percentage of requests could be resolved through self-service?
• Could the solution improve conversion or retention?
• Could it reduce the cost per completed task?
• Could it improve the consistency or coverage of quality checks?

The expected benefits must then be compared with implementation, integration, infrastructure, governance, review and maintenance costs.

The right question is not simply:

Where can we use AI?

It is:

Where can AI produce meaningful value while keeping the consequences of error within an acceptable and controllable range?

Translating a business need into an AI workflow

A requirement such as “we want an AI assistant for marketing analytics” is not specific enough to guide system design.

Before choosing a model, framework or architecture, I would assess the opportunity through five questions.

1. What is the business value?

Which revenue, cost, productivity or competitive outcome should improve? How will that improvement be measured?

Without a defined return, it is difficult to determine whether the initiative is worth building or maintaining.

2. What is the consequence of an incorrect output?

Would an error create minor rework, or could it affect a customer, regulatory obligation, production implementation or financially significant recommendation?

Risk depends on the use case—not only on the model.

3. How easily can the output be verified?

Can the result be checked through:

• source inspection;
• code execution;
• automated tests;
• schema validation;
• an API response;
• deterministic calculations;
• business-rule checks; or
• expert review?

If checking the AI’s work requires repeating the entire task manually, the expected productivity gain may disappear.

4. How much business context is required?

Does the system need access to product documentation, internal policies, data definitions, technical architecture, historical decisions or undocumented practitioner knowledge?

The more context-dependent the task, the less likely a general-purpose chatbot will produce a consistently usable answer.

5. Does the solution fit the real workflow?

Does it remove work and shorten the process, or does it simply introduce another output that someone must review?

A technically strong solution can still fail if it appears at the wrong point in the process, creates more checking than it saves or does not produce something the next person can act on.

These questions translate a broad business request into engineering and operating requirements.

They also help determine where an LLM adds value and where a deterministic rule, calculation, API or conventional software component may be more appropriate.

The complete system matters more than the model

An enterprise AI solution is rarely just an LLM.

A practical workflow may combine:

• an LLM for interpreting language or producing a first draft;
• retrieval for relevant evidence and context;
• APIs for authoritative or current information;
• deterministic code for calculations;
• schema validation for controlling output structure;
• business rules for permitted recommendations or actions;
• permissions and access controls;
• monitoring and audit logs;
• evaluation datasets;
• escalation paths; and
• human review at selected decision points.

The objective is not to remove probability from the system completely. That would be unrealistic.

The objective is to place the probabilistic component where its flexibility creates value, while using more deterministic components where consistency, exact calculation or strict enforcement is required.

A stronger model may improve one part of the workflow. It cannot compensate for an unclear business requirement, missing context or weak operating controls.

Human judgment at the centre does not mean reviewing everything

My belief is in human–AI collaboration, with human judgment retained at the points where context, accountability or consequences require it.

That does not mean every AI output should go through the same manual review.

If a professional must repeat every task from the beginning to verify the AI’s work, the solution may create little productivity value.

Human-in-the-loop can also become a ceremonial control. Asking someone to approve an AI-generated answer is not meaningful oversight if that person lacks the evidence, time or authority needed to assess it properly.

Oversight should therefore be proportionate to the use case.

A low-consequence drafting task may only require automated validation and periodic quality sampling.

A customer-facing answer may require approved source material, monitoring and a route to a live agent or specialist.

A recommendation involving substantial financial consequences may require explicit expert approval, supporting evidence and a documented audit trail.

The objective is not to place a person after every AI output. It is to preserve meaningful human control over consequential decisions.

Start with low-risk, meaningful-value and verifiable work

Organizations are often advised to begin with low-risk AI use cases. I agree, but low risk alone is not enough.

A low-risk application that creates negligible value will not establish a compelling case for broader adoption.

The most useful starting point combines three characteristics:

1. The consequences of an error are limited.
2. The task creates meaningful value for the user or business.
3. The output can be verified efficiently.

This supports a progressive adoption roadmap.

Stage 1: Assist

AI drafts, summarizes, organizes or checks work.

Examples include:

• drafting code;
• preparing requirements;
• summarizing documentation;
• generating QA checklists; and
• producing a first-pass analysis.

The output can be reviewed before it affects a business decision.

Stage 2: Recommend

AI produces an analysis or recommendation together with evidence, assumptions and limitations. A professional evaluates the result before acting on it.

Stage 3: Act within defined boundaries

AI can call tools or execute predefined actions, but only within controlled permissions, validation rules, monitoring and escalation paths.

Stage 4: Expand selectively

Higher-consequence use cases are introduced after the organization has accumulated evidence about performance, business return, user behaviour and failure modes.

Confidence is built through consistent results and transparent learning—not through a launch announcement.

Applying this approach to marketing analytics

Several of my recent proof-of-concept projects focus on accelerating marketing analytics without removing the expert from the decision process.

For example, one project generates inspectable Python code for MMM data preparation, data-quality checks, channel-grouping proposals, correlation and VIF diagnostics, and Google Meridian exploratory analysis.

The analyst does not need to accept a black-box numerical answer. They can inspect, modify, test and execute the code.

Another project produces synthetic MMM datasets for experimentation and model-recovery testing. The outputs are explicitly treated as synthetic assumptions—not estimates of actual marketing performance.

Other projects conduct first-pass tracking reviews, audit advertising and analytics tags, or structure competitor research.

The common principle is:

Use AI to accelerate repetitive preparation, validation and first-draft analysis, while keeping experts responsible for interpretation, business context and final decisions.

These are useful starting points because the outputs are valuable but still relatively easy to inspect.

A supporting example: using RAG to improve the credibility of marketing-tracking guidance

One recent PoC tested this philosophy in a specific marketing workflow.

Non-technical marketers often need to translate a tracking requirement into something a developer can implement.

They may ask:

• How should we track a successful newsletter signup?
• Is a particular interaction already collected by GA4 Enhanced Measurement?
• Do we need a Google Tag Manager trigger?
• When is a developer-generated dataLayer message required?
• What exactly should be included in the developer brief?

A general-purpose chatbot will usually provide an answer.

The risk is not that it refuses. The risk is that it produces an answer that sounds authoritative while inventing a menu path, mixing Universal Analytics with GA4, recommending unnecessary development work or treating a button click as equivalent to a confirmed successful submission.

A non-technical marketer may have no practical way to identify the problem.

To explore a more credible approach, I built a local retrieval-augmented generation assistant for GA4 and Google Tag Manager questions.

The system retrieves relevant information from indexed official Google documentation before generating its answer. It writes for a non-technical marketer and displays the retrieved pages and passages beside the response.

When development work is required, it can prepare a first-draft brief for the marketer to copy to a developer.

The intended operating model is deliberately bounded:

AI handles repeatable questions and first-draft translation. A MarTech expert remains responsible for ambiguous, unsupported or consequential cases.

What the initial results suggest

In an initial evaluation of ten generated questions, the assistant achieved mean scores of:

• 0.945 for accuracy
• 0.885 for completeness
• 1.000 for relevance

The test was limited, and the questions were generated from indexed content. It was not a controlled comparison against an ungrounded chatbot, nor was it a user test with marketers and developers.

The results should therefore be treated as an early signal, not proof.

However, they suggest that RAG may be a promising direction for improving the credibility of AI-generated guidance.

Instead of asking the model to answer only from its pre-trained knowledge, retrieval gives it a more controlled factual basis. Displaying the source material also gives users and reviewers an opportunity to compare the generated answer with the underlying documentation.

This can support credibility in two ways.

1. It can reduce reliance on unsupported model memory

Searching approved documentation before answering narrows the information space available to the model.

This does not guarantee correctness, but it may reduce the likelihood that the system invents product features, configuration paths or technical instructions without relevant evidence.

2. It can make an error easier to identify before action is taken

Showing the retrieved evidence provides an audit path.

The user does not have to rely entirely on “the AI said so.” They can inspect the documentation behind the recommendation before sending a developer brief or publishing a container.

This matters because preventing every error may not be realistic. Reducing the chance that an error proceeds directly into implementation is also valuable.

The Campaign Manager 360 error

One evaluation failure was particularly instructive.

When asked about the attribution model used in a Campaign Manager 360 report, the assistant correctly identified non-direct cross-channel last click. It also correctly stated that the attribution model could not be changed.

However, it then reversed the meaning in its plain-language explanation by suggesting that a direct visit would receive credit over an ad.

The correct interpretation is the opposite: direct traffic is ignored when an eligible non-direct interaction exists.

The correct information had been retrieved, but the model still introduced an error when translating it into everyday language.

This does not lead me to conclude that RAG is the wrong approach. It reinforces why retrieval should be combined with visible sources, evaluation and proportionate human review.

RAG may reduce the likelihood of an unsupported answer. Citations and evidence can make remaining errors easier to catch. Expert escalation can reduce the chance that an ambiguous or consequential error leads to action.

The benefit comes from the complete workflow—not from retrieval alone.

Combining official documentation with practitioner knowledge

The PoC also points toward a stronger knowledge architecture.

Official documentation can explain what a feature does and how it is configured. It may not explain which method is most appropriate for a particular business requirement.

For example, documentation may describe Enhanced Measurement, custom events and data-layer implementation separately. A practitioner still needs to decide:

• whether an existing event is sufficient;
• whether a click is an acceptable proxy for a successful action;
• whether developer support is required;
• what information should be included in the developer brief;
• how the implementation should be tested; and
• what must be validated before publishing.

That applied judgment could be documented and indexed alongside official product information.

The resulting knowledge model would be:

1. Official documentation provides product facts.
2. Indexed practitioner knowledge provides decision criteria and implementation guidance.
3. The LLM translates the retrieved information into an answer appropriate for the marketer.
4. A human expert handles ambiguity and remains accountable for consequential decisions.

This would not make the system infallible. It could, however, provide better context, stronger recommendations and a clearer path for users to inspect how an answer was formed.

The initial PoC therefore offers a useful signal: grounding answers in approved information and exposing the supporting evidence may be the right direction for increasing credibility and reducing the risk that a hallucinated answer becomes an incorrect implementation.

The next step would be to test that hypothesis properly through:

• a controlled comparison with an ungrounded chatbot;
• a richer gold evaluation set based on real tracking workflows;
• human review by MarTech practitioners;
• usability testing with marketers and developers; and
• measurement of self-service, time savings, clarification cycles and implementation quality.

The role of the translator is becoming more important

As models become more capable, it may seem that the need to translate between business and technology will decline.

I believe the opposite is happening.

More capable models create more potential applications, but they also make it easier to build something impressive before determining whether it solves the right problem.

The translator’s role is not simply to convert a requirement into a prompt. It is to connect:

• commercial objectives;
• user workflows;
• domain and practitioner knowledge;
• data and methodological requirements;
• model capabilities and limitations;
• verification mechanisms;
• governance controls;
• human accountability; and
• measurable operating outcomes.

This requires both technical understanding and business judgment.

A technically sophisticated system that professionals cannot confidently use will not deliver its expected return. A carefully governed system that solves an insignificant problem will not create meaningful value either.

Practical adoption sits at the intersection of both.

Final thought

The hardest part of AI adoption is not getting a model to produce an answer.

It is translating a real business need into a workflow where the answer is valuable, sufficiently grounded and verifiable enough for someone to act on responsibly.

AI does not need to be infallible to create value. But professionals need clarity about its role, evidence behind its outputs and control over consequential decisions.

That means:

• selecting use cases with meaningful business returns;
• starting where errors are manageable;
• designing efficient verification;
• providing the right business and practitioner context;
• defining clear escalation paths;
• keeping human judgment at the appropriate decision points; and
• measuring performance over time.

The goal should not be confidence based on fluent language.

It should be calibrated confidence supported by evidence, controls and human judgment.

That confidence cannot be assumed. It must be engineered—and then earned through experience.

How is your organization translating AI capabilities into workflows that professionals can confidently use? I would be interested to hear how others are balancing business return, model uncertainty and human judgment.

Related project

• Marketing Tracking RAG Post
• Marketing Tracking RAG PoC — GitHub
• Marketing Tracking RAG Demo — YouTube