AI-Powered Product Advisers for Complex Catalogues: What Must Be Governed Before Customers Can Trust the Answers

An AI product adviser can recommend a product that sounds perfect and does not exist.

It can also recommend a real product with the wrong voltage, an incompatible accessory, an unavailable variant or an unsupported performance claim. The answer may be fluent, specific and persuasive. That makes the defect more dangerous, not less.

For complex catalogues, the commercial opportunity is genuine. Customers may need to navigate hundreds of attributes, trade-offs, compatibility rules and technical documents. A well-designed adviser can translate a customer’s job into a useful shortlist, explain differences and move the conversation forward. It can also expose gaps in product data and reduce repetitive pre-sales questions.

The interface is the easy part. Trust depends on a governed system behind it: authoritative catalogue data, deterministic constraints, clear answer boundaries, risk-based testing, privacy controls, monitored performance and a human owner who can withdraw unsafe advice.

NIST’s AI Risk Management Framework organises AI risk work around Govern, Map, Measure and Manage. That sequence is a useful antidote to beginning with a chatbot demonstration. This article applies it to product selection. It is general digital guidance, not legal, product-safety or AI assurance advice for a specific catalogue.

Decide what kind of adviser you are building

“AI product adviser” can describe several materially different systems:

Pattern	What it does	Primary risk
Guided selector	Asks structured questions and applies fixed rules	Incomplete or obsolete rules
Semantic catalogue search	Interprets natural language and retrieves relevant products	Poor retrieval or attribute matching
Ranking model	Orders eligible products by predicted relevance	Opaque bias and feedback loops
Generative adviser	Produces conversational explanations and comparisons	Unsupported or fabricated statements
Assisted handover	Summarises needs for a human specialist	Incorrect summary or lost context

Many effective experiences combine them. A customer describes the job in natural language; structured questions resolve missing constraints; deterministic logic removes ineligible products; retrieval finds evidence; a model explains the shortlist; and a specialist takes over when confidence or consequence requires it.

That is different from asking a general-purpose model to read a website and recommend something. Define the system pattern, authority and boundaries before evaluating vendors.

Write the adviser’s job statement

Use a precise statement:

For this customer cohort, help with this selection decision by using these approved sources and rules, producing these allowed outputs, while refusing or handing over these excluded cases.

“Help people find products” is not testable. “Help Australian commercial kitchen buyers shortlist compatible under-bench dishwashers from the current catalogue, excluding final electrical and installation advice” is far more useful.

The job statement becomes the basis for data scope, evaluation questions, interface disclosure and operational ownership.

Establish the product truth layer

An adviser cannot be more reliable than the product knowledge it can access. Complex catalogues commonly contain duplicate SKUs, free-text specifications, missing units, conflicting PDFs, market-specific variants, discontinued accessories and sales knowledge that exists only in people’s heads.

Before model work, define the product truth layer:

the authoritative system for product identity, status, price and availability;
a governed attribute dictionary with units and allowed values;
product-family relationships and variant inheritance;
compatibility and exclusion relationships;
market, customer and channel eligibility;
claim evidence and effective dates;
document version and supersession rules; and
ownership for correcting each field.

Google’s Merchant Center product data specification is designed for a different delivery channel, but it demonstrates the discipline required: product identifiers, availability, price, condition and detailed attributes need explicit definitions. An adviser needs an equally controlled internal contract, often with more technical depth.

Separate facts, rules and explanations

Keep three knowledge types distinct:

Facts: dimensions, materials, capacity, compatibility identifiers, warranty terms and availability.
Rules: must fit, cannot combine, only approved for, requires accessory, not available in market.
Explanations: why a feature matters, the trade-off between options and what to check next.

Facts and hard rules should usually come from governed records or services. A language model may explain them, but should not invent or silently override them. If evidence is missing, the adviser needs an honest missing-data response.

Put eligibility before ranking

A persuasive recommendation is worthless if the product is not eligible for the customer’s use.

Create a constraint pipeline:

Interpret the stated need. Extract known requirements and uncertainty.
Ask decisive questions. Resolve inputs that could change eligibility.
Apply hard constraints. Remove incompatible, unavailable or prohibited options.
Rank eligible products. Use preference, fit and evidence.
Explain the shortlist. Cite relevant product facts and trade-offs.
State assumptions. Tell the customer what remains unverified.
Escalate when required. Route consequential or ambiguous cases to a person.

Hard constraints should not be buried inside a prompt. Represent them in a testable rules layer wherever practical. A prompt can say “never recommend incompatible parts”, but an explicit compatibility service can prove which combinations pass.

Distinguish hard constraints from preferences

Customers frequently express both as ordinary language:

“It must fit a 600 mm opening” is a hard constraint.
“I would prefer something quiet” is a preference that needs a definition and trade-off.
“It must be safe for this environment” may require specialist judgement and should trigger a boundary.

The interface should confirm decisive constraints before recommending. This also lets a customer correct an extraction error rather than treating the AI’s interpretation as invisible truth.

Design an answer contract

Do not let each response take any form the model chooses. Define an answer contract that supports trust and measurement.

A robust recommendation might include:

the interpreted customer need;
the recommended product or shortlist;
the two or three strongest evidence-backed reasons;
trade-offs and excluded requirements;
assumptions or information still needed;
source links to current product pages or documents;
availability or price status with a timestamp where relevant; and
the appropriate next action.

The adviser should distinguish “the catalogue states”, “based on the information provided” and “a specialist must confirm”. It should not use cautious wording to disguise unsupported output.

The ACCC’s guidance on false or misleading claims states that product and service information must be accurate, truthful and based on reasonable grounds. AI-generated copy is still a business communication. The organisation needs evidence for claims made through the adviser and should obtain advice specific to its products and obligations.

Give refusals a useful design

A refusal should not be a dead end. Define why the adviser cannot proceed and what the customer can do:

provide a missing measurement;
choose between two constraints;
view a neutral comparison;
contact an authorised specialist;
upload an approved document through a controlled pathway; or
use a non-AI catalogue filter.

Never imply that a human specialist has verified an answer when they have not.

Use retrieval without pretending it guarantees truth

Retrieval-augmented generation can ground a response in selected catalogue content. It does not guarantee that the correct source was retrieved, that the source is current, that the model followed it or that the final claim is entailed by it.

Design the retrieval layer around:

approved source collections and access controls;
document and product versioning;
chunking that preserves tables, qualifications and units;
metadata filters for region, status and audience;
minimum relevance thresholds;
source citations traceable to exact records; and
behaviour when sources conflict or no evidence is found.

Do not treat an indexed PDF folder as a catalogue architecture. Important compatibility and eligibility rules should be structured, not dependent on a model inferring them from prose.

Control context from customers and the web

Product advisers may receive free text, uploaded files, URLs or account data. Treat those inputs as untrusted. The ACSC’s Guidelines for secure AI system development cover secure design, development, deployment, operation and maintenance of AI systems, including systems built on third-party models.

Threat scenarios include prompt injection in a supplied document, attempts to reveal system instructions, extraction of another customer’s information, unsafe tool calls and catalogue content containing malicious instructions. Constrain data access and tool permissions at the application layer; a model instruction is not an access-control boundary.

Build a risk-tiered evaluation set

A polished demo proves almost nothing. Evaluation should use representative and adversarial cases before release and continue in production.

Create a test set from:

common customer questions;
long-tail terminology and misspellings;
products with similar names but different constraints;
missing, conflicting and outdated source data;
incompatible combinations;
unavailable products and region-specific variants;
ambiguous questions that require clarification;
excluded high-consequence advice;
deliberately manipulative inputs; and
accessibility and multilingual scenarios where in scope.

Label each case with the allowed products, prohibited products, required questions, essential facts, permitted claims and expected escalation. Specialists who understand the catalogue should approve the reference answer.

Measure the system, not only the prose

Useful evaluation measures include:

Dimension	Example measure
Eligibility	Percentage of responses recommending only eligible products
Grounding	Percentage of material claims supported by approved current sources
Constraint capture	Decisive requirements correctly identified and confirmed
Retrieval	Relevant approved records found in the top results
Calibration	Low-confidence cases appropriately clarified or escalated
Helpfulness	Customer can progress without hiding uncertainty
Fairness	Comparable needs receive consistent treatment across relevant cohorts
Safety	Prohibited output and data-access tests pass

NIST’s Generative AI Profile is a companion to the AI RMF and emphasises risk management across the generative AI lifecycle, including pre-deployment testing and incident disclosure. Select measures and thresholds for the actual consequence of a wrong answer.

Do not optimise on thumbs-up alone. Customers may like confident incorrect advice, and feedback is biased towards people who notice an error.

Design privacy before conversation history grows

An adviser may collect needs, budgets, locations, account context, product use and free-text information. Some of that may be personal information. The OAIC’s guidance on commercially available AI products explains that the Privacy Act applies to uses of AI involving personal information and recommends understanding data handling, accuracy, security and vendor practices.

Decide:

what the adviser needs to collect;
whether anonymous use is possible;
when account or CRM context is introduced;
what is sent to each model or service provider;
whether inputs or outputs are retained or used for training;
how users are notified at collection;
who can review conversations;
how long records are kept; and
how deletion, correction and complaints are handled.

Do not paste a generic AI notice over unresolved data flows. Obtain privacy and legal advice for the implementation where required.

Keep customers in control

Trust is not created by adding an “AI” badge. Give users practical control:

identify the experience as automated assistance;
explain its useful scope and important limitations;
allow customers to inspect and correct interpreted needs;
show sources for material product facts;
provide a conventional search or filter alternative;
make human handover easy and preserve relevant context with consent; and
provide a way to report a wrong or unsafe answer.

Accessibility applies to the whole journey. The Web Content Accessibility Guidelines 2.2 should inform the conversational interface, form controls, status announcements, keyboard operation, error handling and alternatives. Typing into a chat box must not be the only way to select products.

Create an operating model for change

An adviser can become wrong without any model release. Product data changes, stock is withdrawn, a regulation changes, a document is superseded or a prompt is edited.

Name owners for:

business outcome and risk acceptance;
product data and compatibility rules;
adviser configuration and prompts;
model and vendor changes;
evaluation and release gates;
customer feedback and incident triage; and
suspension or rollback.

Maintain version history for the model, system prompt, retrieval corpus, rules and evaluation results. Use a change-impact gate when any of them moves. A “kill switch” should disable unsafe recommendation behaviour without taking the entire catalogue offline.

Measure commercial value with guardrails

Track outcomes such as qualified product-page visits, shortlist completion, assisted conversion, specialist handover quality, return reasons and support demand. Pair them with eligibility, grounding, complaints and incident measures.

Use a controlled comparison where practical. Higher conversion accompanied by incompatible orders, returns or customer-service corrections is not success. Segment results by catalogue family and use case; one strong category can conceal a failing long tail.

What belongs in paid Discovery

Complex product advice connects catalogue architecture, business rules, customer research, AI design, privacy, security, integrations and operations. If source systems, constraints, acceptable claims or escalation responsibilities are unresolved, an implementation quote will be built on guesses.

Paid Discovery can define the adviser’s job, map catalogue and evidence sources, identify hard rules, model the conversation and handover journeys, establish risk tiers, assess integration options and design an evaluation plan. It should surface data remediation and specialist assurance work that must precede launch. This is not a free AI audit, prototype or strategy exercise inside a proposal.

A sensible output is a decision blueprint: supported use cases, excluded advice, source architecture, rules model, answer contract, evaluation set, responsibility map, phased release and an evidence-based implementation scope.

A release gate for an AI product adviser

Before customers use the adviser, accountable owners should be able to confirm:

The supported decision and excluded cases are explicit.
Every material product fact has an authoritative owner and freshness rule.
Hard eligibility and compatibility constraints are enforced outside free-form generation where practical.
Answers expose evidence, assumptions and next steps.
Representative, edge and adversarial cases meet agreed thresholds.
Customer information flows, retention and supplier use are understood.
Access and tool permissions are constrained independently of prompts.
Accessible alternatives and human escalation work end to end.
Changes to data, rules, model and prompts trigger re-evaluation.
Owners can monitor, correct, suspend and communicate an incident.

If any answer depends on “the model will probably handle it”, the system is not ready to advise customers.

Frequently asked questions

Is an AI product adviser just a chatbot over catalogue content?

It should not be. A trustworthy adviser combines governed catalogue facts, explicit eligibility rules, controlled retrieval, an answer contract, evaluation and human escalation. A chat interface can be one presentation layer.

Can retrieval-augmented generation prevent hallucinations?

No. Retrieval can provide approved evidence, but it can retrieve the wrong source, miss a qualification or be ignored in generation. Test retrieval and final claims separately, and enforce hard constraints outside free-form output where practical.

Should the adviser recommend one product or a shortlist?

That depends on the decision and evidence. A shortlist with trade-offs is often more trustworthy when several products fit or customer preferences remain uncertain. A single answer requires strong eligibility logic and confidence.

How much catalogue cleanup is needed first?

Enough to make identity, status, decisive attributes, compatibility, eligibility and claim evidence reliable for the supported use case. Do not postpone known data defects and expect the model to reconcile them safely.

How should the business test an AI product adviser?

Use an approved set of common, long-tail, ambiguous, incompatible, missing-data and adversarial cases. Measure eligibility, grounding, constraint capture, retrieval, appropriate escalation, accessibility and safety, not only customer sentiment.

What should happen when the adviser is uncertain?

It should ask a decisive question, provide a clearly qualified comparison or hand over to a person. The behaviour should reflect consequence. It should not fill gaps with plausible product claims.

Does the adviser need a privacy assessment?

Assess what information is collected, how it is used, which providers receive it and applicable obligations. A formal PIA may be appropriate depending on risk. Obtain privacy and legal advice specific to the implementation.

When is paid Discovery required?

Use paid Discovery when catalogue sources, business rules, customer journeys, integrations, risk boundaries or operational ownership are not sufficiently resolved to design and price implementation. It is product and technical definition, not a free AI prototype.

How Emote can help

Emote helps organisations shape product-selection experiences around real customer decisions and governed catalogue data. Where the product model, rules, integrations, AI approach or risk boundary is unresolved, paid Discovery can turn those unknowns into a defined user journey, technical architecture, evaluation plan and responsible implementation scope.

Emote’s digital transformation services can connect the adviser experience to the catalogue, integration and operating changes around it.

If you are exploring an AI adviser for a complex catalogue, book a meeting with Emote to discuss the customer decision it should support first.