A customer service chatbot is useful when it can answer a defined set of questions from maintained information and hand over everything else. Start with a narrow job such as explaining product specifications. Account changes, refunds and order access need separate permission checks; fluent answers do not establish that a user is authorized.
Define what the assistant may answer and do
Write down the supported questions, the source of each answer and the owner who keeps that source current. A product-description question can use a published catalog. An order-status question concerns a specific customer and requires authenticated access to that order. A refund request changes business records and should have a separate approval policy.
| Request | Required evidence or check | Failure response |
|---|---|---|
| Product specification | Current catalog entry and product identifier | Ask which product; offer a human handoff if the entry is missing |
| Order status | Authenticated customer and server-side order ownership check | Refuse access to another customer's order |
| Refund | Eligible order, policy and authorized action | Hand over cases outside the approved workflow |
Retrieval can supply relevant documentation to a language model. It does not guarantee that the resulting answer is correct. Before rollout, test the answer against the underlying record and include questions for which the record has no answer.
Keep permissions outside the language model
Treat messages and retrieved text as untrusted input. The OWASP prompt injection prevention guidance describes layered defenses; separating instructions from data does not replace authorization at a tool boundary. A document that says “ignore the access rules” must never grant additional access.
Check permissions when the server executes a tool. Filtering suspicious wording can be an additional defense, but it cannot guarantee that every prompt injection is recognized. Likewise, removing selected strings from retrieved text does not establish that the remaining material is safe. Keep secrets outside model context and give tools only the access needed for their job.
Use a test customer to request another customer's order, then repeat the request through a malicious instruction embedded in a retrieved document. Both attempts should fail at the same server-side permission check. Record the result without exposing either customer's private data.
Plan capacity for the platform you actually use
If the assistant uses Power Platform, consult Microsoft's request limits and allocations for the relevant product and license. Those allocations are specific to that platform. They do not describe every chatbot provider, guarantee a free tier or prove that adding more bot instances increases an account's allowance.
Measure the operations consumed by a completed conversation, including retries and integrations. Test a busy period and decide what happens when a dependency is unavailable. A clear handoff or queued request is preferable to an invented order status.
Evaluate a pilot before expanding it
For a hypothetical international catalog, start with one maintained product range and a small set of approved answers. Compare completed answers with the catalog, inspect failed handoffs and review any attempted tool action. Response time, incorrect answers and support effort are measurements to collect, not improvements to promise in advance.
The NIST AI Risk Management Framework provides a voluntary approach to managing AI risk. It is not product certification or a guarantee of compliance, safety or financial return. Assign an owner for incidents, source updates and the decision to pause the assistant.
Continue the pilot when answers remain traceable, unauthorized actions are blocked and support staff can resolve failures. Expand the assistant's scope only after testing the additional data and actions. Discuss a chatbot workflow with AIS Tech.