Before the Demo: Can Your AI Market Research Vendor Explain Their AI?

There are questions about AI market research transparency that rarely come up in a demo that rarely come up in a demo — not because vendors are hiding answers, but because buyers don’t always know to ask them. What model is the platform running? Who trained it and on what data? What happens to a client questionnaire once it enters the system?

You book the demo because the technology looks promising. An hour later you’re interested — and then it goes to legal. Or compliance. Or IT security. That’s where the evaluation stalls.

Researchers who have been through that start asking different questions before the next demo. Not just “does this solve my problem” but “will this pass procurement.” That shift means getting more technical earlier — about the AI model, about data handling, about how the system actually works.

ESOMAR’s 20-question checklist includes a full section on exactly this: three questions on explainability that help buyers interrogate the technology before committing time to an evaluation that won’t survive a compliance or data governance review. Here is what those questions are, and how CodexMR answers them.

Why AI Market Research Transparency Has Become a Procurement Issue

The pattern here is worth naming directly. AI adoption in market research is accelerating. Vendor claims are multiplying at the same pace. The ability to interrogate those claims is not keeping up.

According to Trust Radius’s 2026 B2B Buying Disconnect Report, 94% of buyers fact-check AI-generated information during their purchase journey. They are doing more research, not less. The problem is that the questions most buyers ask — about pricing, integrations, case studies, and support — are not the same questions that reveal how an AI system handles their data, who built the model it runs on, or whether quality review is genuinely independent from the system that generated the output.

ESOMAR’s explainability section closes that gap.

Question 1: Can You Explain What Your AI Does Without Technical Language?

This question tests whether the vendor understands their own product well enough to describe it to a client. A useful answer names the specific tasks the AI handles — generating survey code, flagging routing errors, reviewing translations, coding open-ended responses — and names the tasks it does not handle and where a human takes over.

Vague answers sound like this: “Our AI streamlines the research workflow and delivers faster insights.” Useful answers sound like this: “The AI converts a questionnaire specification into survey code and routes it through a structured QA check. A researcher reviews the output before it moves to programming.” The first is bad marketing. The second describes a workflow you can evaluate, replicate, and hold a vendor accountable against.

Question 2: Which Model Are You Running — And Is It Yours?

Most AI research platforms do not train their own foundation models from scratch. They use third-party models from providers such as Google, Anthropic, or OpenAI, and build their domain-specific value on top of them. That is a legitimate architecture. The problem comes when vendors imply they built something from the ground up, or stay deliberately vague about which provider’s infrastructure their service depends on.

There is a further question worth raising: what happens when that underlying model gets updated? General AI models are retrained by their providers on a rolling basis. Each new version can shift output quality — meaning everything a vendor, and you, have learned about how the system performs may need to be revalidated from scratch. For buyers who depend on consistent research output, quality becomes a moving target tied to decisions made by a company with no visibility into your workflow. Ask whether the vendor pins specific model versions, or whether your delivery quality changes each time the underlying model does.

Ask directly. A vendor with a clear answer will name the foundation model and explain the distinction: the model provides general language capability, and the vendor’s layer provides research domain logic, workflow controls, validation rules, and quality checks. A vendor who cannot give you a straight answer is asking you to trust infrastructure they will not describe.

This is where data handling becomes concrete. If a platform routes your questionnaire through a third-party model API, you need to know whose terms govern that interaction — and whether the vendor has negotiated additional protections on your behalf. “We use AI” is not an answer to this question. A named provider and a clear data-handling statement are.

Question 3: What Happens to My Data?

This is the explainability question with the most direct commercial and legal consequences. When client material enters a platform that uses a third-party foundation model, two questions follow immediately: does that provider process the data, and can it be used to train or improve future models?

A credible answer addresses both without ambiguity. It names the data flow, identifies the third-party providers involved, states clearly whether client material is used for any purpose beyond the agreed service, and distinguishes between the foundation model provider’s standard terms and any additional contractual protections the vendor has arranged for enterprise clients.

A non-answer — “your data is secure” or “we comply with GDPR” — is not a response to this question. Privacy compliance and data use are two separate conversations. A vendor can be fully GDPR-compliant and still use your questionnaire to improve a shared model. The explainability question is asking about the second of those two things.

What Vague Answers Tell You

When a vendor struggles with these three questions, it usually points to one of three situations.

The platform is a thin wrapper around a general model, with no domain-specific research logic built in. The sales team does not have direct access to the technical team — which means the demo represents a different reality from the operational product. Or the vendor has not thought carefully about data handling and is counting on buyers not asking.

None of these make a platform unusable. All of them make the relationship harder to trust when something goes wrong in a live project — and in quantitative research, something always tests the edges of what the platform can handle.

How We Answer These Questions at CodexMR

We designed our approach to this section of ESOMAR around one principle: if we cannot describe it plainly, we have not thought about it clearly enough.

The CodexMR Platform uses a hybrid architecture. Google Gemini is the primary foundation model in current production workflows. The Platform also integrates Anthropic Claude and OpenAI GPT for selected tasks and client-specific requirements. We name the providers because clients should know whose infrastructure is handling their data.

Our proprietary value sits in the layer built around those models: the survey intelligence. That covers workflow design, research domain rules, structured QA schemas, routing logic, validation controls, and the human review process. The foundation model provides language capability — but it is not always a third-party one.

For selected clients, the Platform also runs on sovereign AI models and CodexMR’s own self-trained mid-sized models. The architecture is a genuine hybrid: external foundation models where they perform best, CodexMR’s own models where client requirements, privacy, or domain fit call for it, and the survey intelligence layer running across all of it. The survey intelligence layer makes that capability specific to quantitative research work — the routing logic, the compliance signals, the translation quality standards, the respondent experience checks that a general model does not carry by default.

Client material is used to deliver the agreed service. It does not feed a shared training corpus and does not influence another client’s output. That boundary holds across all three usage modes: DIY, DIT, and DIFM. New platform releases are validated by our own quantitative research teams and a dedicated QA function, using synthetic and de-identified test cases — not client work. The people testing the output know what good research implementation looks like, which is the relevant standard.

On validation: Research Ready and QAReady run on a separate technology layer from the tools that generate output. Quality review is not a system checking its own work. It is a second perspective, at a different stage, using different tools.

Wrap Up

If a vendor cannot answer these three questions before you sign, the chances of a clearer answer after are slim.

The explainability section of ESOMAR’s 20 questions exists because the market needed a shared standard for this conversation. Buyers who use it come into the relationship with better information. Buyers who skip it find out later.

This is the fourth article in our Before the Demo series. Read the previous articles here: