1. Write a role the team can evaluate
Choose one primary job for the first pilot: explain a brand story, answer approved product questions, support a museum experience or another clearly defined interaction. State who will use it, in which language, on which device and in what setting.
Record the intended age range and whether the experience involves children or personal information. These details affect the product and data decisions; they should be visible in discovery rather than inferred from the character artwork.
A usable first brief
Add a short voice and style guide with examples: a welcome, an answer, an uncertainty response and a handoff. It is easier to review concrete dialogue than broad adjectives such as “friendly” or “smart”.
2. Treat voice as a licensed project input
Choose a licensed synthetic voice, an authorised performer or another documented source. Record who holds the rights and the permitted languages, products, regions, duration and uses. Any cloning or reuse needs an appropriate permission record before production use.
Keep the consent or licence reference alongside the character version. Assign an owner for expiry, withdrawal requests and replacement voices so a character can be maintained after the pilot.
3. Build an approved knowledge-source worksheet
Retrieval-augmented generation, or RAG, retrieves relevant material from a selected knowledge base to help a model answer. Retrieval provides source context; it does not by itself guarantee a correct answer or prevent an unsupported claim.
| Knowledge decision | What to record |
|---|---|
| Source | Document, product record or content collection; version and permission to use it. |
| Owner | Person who approves the content and updates it when facts change. |
| Scope | Topics, languages and audiences the source covers; topics outside the character’s role. |
| Access | Public or private, project permissions, and whether personal information is present. |
| Answer behaviour | What can be stated, when to show a source, and what to do with conflicting or missing information. |
| Removal | How documents, indexes, cached answers and related records are handled when access ends. |
Separate approved product facts from promotional language. If a source does not establish a certification, warranty or product capability, the character should not turn it into an affirmative claim.
4. Evaluate the experience with a small question set
Prepare representative questions before the pilot. Include supported questions, missing information, conflicting sources, requests outside the role, language changes and an attempt to override the character instructions.
- Does the answer match the approved source and intended role?
- Does the voice remain understandable and consistent with the style guide?
- Does the character use the agreed fallback when it cannot answer?
- Can a user reach an appropriate support or human handoff route?
- Does the physical interface work in the expected environment?
Record the question, expected behaviour, observed answer, source version and decision. Agree the pilot acceptance criteria with the brand before presenting it as a production experience.
5. Assign ownership beyond the demo
Record the model and voice vendors, hosting region, information sent to each service, retention settings and ongoing fees. The choice should follow the target geography, audience, latency, contractual needs and actual data flow.
Assign responsibility for knowledge updates, behaviour changes, support, deletion requests and service interruptions. Include an end-of-service path so the physical product’s expected behaviour remains clear if the connected service is unavailable.
For a physical AI product, coordinate these decisions with the module, power, audio and market review. The market-readiness page lists the product questions to bring into that discussion.
Bring a role, a source set and an owner.
These inputs make the first AI discovery conversation specific enough to choose a pilot scope.
Prepare an AI project email →