Preventing Hallucinations: Building a QA-First Automation Engine on Make.com
TL;DR — AI-generated content gets a bad reputation because most teams skip the QA layer entirely. Building a Source Anchoring system in Make.com — where every AI output is tethered to a verified data source before review — reduces hallucination risk from an existential threat to a manageable editing task.
The Day I Published Something That Was Not True
I need to tell you about the competitive battle card.
This was early in our AI content workflow, before I had built any real safeguards. I used a competitor’s feature set as context and asked an AI model to generate a comparison table. The output looked clean, professional, properly formatted. I reviewed it quickly, thought it looked right, and sent it to the sales team.
Two days later, a sales rep used it in a live deal. The prospect pushed back on a specific claim about the competitor’s pricing model. The claim was wrong — the model had blended details from two different products and presented it as a single accurate statement. The deal survived, but the credibility hit to that rep was real, and my own credibility with the sales team took a knock it took months to rebuild.
That is the hallucination problem in practice. Not a philosophical concern about AI accuracy. An actual moment where a confident-sounding output caused real damage in a live revenue situation.
Everything I built after that moment was designed to make sure it could not happen again.
Why Hallucinations Happen (and Why Prompting Harder Is Not the Fix)
The instinct when hallucinations occur is to blame the prompt. Add more context. Be more specific. Tell the model not to make things up.
These things help at the margins, but they do not solve the structural problem. Large language models generate statistically plausible text. When they do not have accurate source material to draw from, they produce text that sounds accurate but is assembled from patterns rather than facts. The model does not know it is wrong. It is not lying. It is generating.
The only reliable fix is not better prompting — it is Source Anchoring: ensuring that the AI is generating from verified, current source material rather than from its training data or from vague contextual instructions.
Source Anchoring means: before the AI writes anything, the automation pulls the actual data it needs from a verified source and injects that data directly into the prompt. The model is not asked to recall or infer. It is asked to transform specific, verified inputs into a specific output format.
Source Anchoring in Practice
Here is what this looks like inside a Make.com scenario for three common PMM content types:
Release Notes and Feature Descriptions
Source: Bitbucket PR data (as covered in the previous post in this series) or a structured product update sheet maintained by the product team.
The Make.com scenario pulls the PR description or product update entry — actual text written by the team that built the feature — and injects it into the AI prompt as the primary source. The prompt instructs the model to transform this specific input into a customer-facing summary, and explicitly states: “Do not add claims, features, or capabilities that are not present in the source text provided.”
The model cannot hallucinate a feature that does not exist in the source material if the source material is the only content it is working from.
Competitive Claims
Source: Google Search Console (for keyword and demand data), or a structured competitor fact sheet updated by the PMM team from primary research.
Competitive content is the highest-risk category for hallucinations, because the model’s training data about competitors may be outdated or simply wrong. The rule here is absolute: no competitive claim goes into any asset without a live, human-verified source citation attached.
In the Make.com scenario, competitive content requests trigger a mandatory source check step. The automation pulls the current version of the competitor fact sheet and passes it as the sole context for any competitive comparison. If the fact sheet does not contain information on a specific topic, the AI prompt is instructed to flag the gap rather than fill it.
Metrics and Performance Data
Source: Google Search Console API, CRM exports, or your analytics platform.
Numbers are the most dangerous category because they are precise enough to be verifiable and wrong in ways that erode trust instantly. The Make.com scenario for metric-based content pulls data directly from the API at the time of generation — not from a cached snapshot, not from a manually entered figure in a brief, and certainly not from a model’s training data.
Every metric that appears in generated content comes from a live pull with a timestamp. If the API call fails, the scenario pauses and alerts the operator rather than proceeding with a potentially stale or inferred figure.
The QA Layer Architecture in Make.com
Beyond Source Anchoring, a functional QA layer needs one more component: a review routing step that ensures no AI-generated content reaches a final destination without a human checkpoint.
The architecture looks like this:
- Trigger fires (scheduled, webhook, or manual)
- Source data pulled from verified endpoint
- Source data injected into AI prompt with explicit grounding instructions
- AI generates output
- Output routed to a “pending review” queue — a Notion database, a Slack channel, a Google Doc folder, wherever your team does its best reviewing
- A human approves, edits, or rejects before the content moves to the next step
Step 5 is the gate most teams skip because they are optimising for speed. That is a reasonable optimisation for low-stakes content like internal summaries or draft social posts. It is not a reasonable optimisation for anything that will reach a prospect, a customer, or a public channel.
The speed advantage of AI-generated content is not eliminated by adding a review step. A human reviewing a well-anchored AI draft takes minutes, not hours. The blank-page problem is solved. The accuracy risk is contained. Both things can be true simultaneously.
Building the Habit Into the Team
The technical architecture is the easier part. The harder part is building the habit that Source Anchoring requires.
It means that competitive fact sheets need to be maintained. Product update entries need to be written in a form the automation can consume. Metric queries need to be mapped to the right API endpoints.
None of this is onerous if it is designed as a lightweight, repeatable process from the start. The competitive fact sheet is a living document that gets updated whenever a new piece of verified competitive information surfaces. The product update entry is a two-field form the product team fills in at launch. The metric queries are parameterised and version-controlled.
What you are building is not just a QA layer for AI content. You are building the source-of-truth infrastructure that makes your entire GTM operation more reliable — regardless of whether AI is involved in generating a specific piece of content.
Key Takeaway for PMM Leads
Hallucinations are an infrastructure problem, not a prompting problem. The fix is Source Anchoring — ensuring that AI output is always generated from verified, current data pulled directly into the prompt at generation time. A Make.com QA layer that enforces Source Anchoring and routes output through a human review gate before distribution turns AI content risk from existential to manageable. Build the infrastructure. Maintain the sources. Trust the gate.
Frequently Asked Questions
Is Source Anchoring different from retrieval-augmented generation (RAG)?
They are related concepts. RAG is the technical architecture where a system retrieves relevant documents from a knowledge base before generating a response. Source Anchoring is the operational practice of ensuring that verified, current source data is always present in the prompt before generation happens. In a Make.com context, Source Anchoring achieves a similar result through workflow design rather than through a dedicated vector database — the automation pulls source data from your existing tools (GSC, CRM, Bitbucket) and injects it directly. For most PMM use cases, this is sufficient and considerably simpler to implement.
What counts as a “verified source” for PMM content?
For product claims: anything written or approved by the product team — a PR description, a product spec, a release entry. For competitive claims: primary research you have conducted yourself or from analyst reports you have licensed. For metrics: data pulled directly from your analytics platform or CRM with a timestamp. The standard is not perfection — it is traceability. If a claim is challenged, you should be able to point to the source it came from.
How do I handle the scenario where no verified source exists for a topic the AI needs to address?
This is the correct failure mode for Source Anchoring to produce. If the automation cannot find a verified source for a specific claim, the right output is a flagged gap — not a generated answer. The Make.com scenario should be designed to route gap flags to the PMM owner as a task, not to proceed with an unanchored generation. A content gap identified by the system is a useful signal. A hallucinated answer to fill a content gap is a liability.
How much additional time does a QA-first workflow add to content production?
Less than you expect. The Source Anchoring step — pulling from a verified API or document — adds seconds to the automation runtime. The human review step, when the draft is well-anchored and the source is solid, typically takes two to five minutes for a standard content asset. The time cost is minimal compared to the cost of publishing inaccurate content and managing the downstream consequences.