A support assistant that answers from your real policies — and says so when it doesn't know.

Yes. The engineering that matters in a customer-facing assistant includes refusing to invent things such as refund policies or delivery dates. A language model's replies vary from one run to the next, so an assistant needs evaluation, and human review where the stakes justify it, before it is called ready. Grounding its answers in content the business already holds is covered on the RAG development page. Is it security-reviewed as well? Yes, by our security team rather than the people who built it, including guardrail verification and prompt-injection resilience testing. That work is described on the AI security page.

It can be built to decline, and the decline can be checked, but Anthropic does not claim any technique ends invention outright. Its Customer support agent guide lists a guardrail that reads "Avoid contractual commitments: Ensure the agent doesn't make promises or enter into agreements it's not authorized to make." Its hallucination guide recommends giving the model explicit permission to say it does not know. The same hallucination guide adds that its techniques cut hallucinations but "they don't eliminate them entirely". So a refusal is something an evaluation checks, not something a build can promise.

When the question needs a person, and deciding which questions those are is part of designing the product. Anthropic's Customer support agent guide names Escalation efficiency among its success criteria for a support assistant, which makes a missed handover something that is measured rather than noticed by a customer. Where the conversation arrives once it leaves the assistant is the business's decision, and it belongs in the design from the start alongside the subjects the assistant declines.

An evaluation against success criteria, not a convincing demo. Anthropic's Customer support agent guide puts it this way: "To determine the readiness of your solution, evaluate the chatbot performance using a systematic process combining quantitative and qualitative methods." Anthropic's prompt engineering overview opens with what it expects to exist first. "This guide assumes that you have:" 1. "A clear definition of the success criteria for your use case" 2. "Some ways to empirically test against those criteria" 3. "A first draft prompt you want to improve". It then adds: "If not, spend time establishing that first." The prompt is last on that list. 'It seemed fine in testing' is not a release criterion.

They can, and they give realistic questions, but a set built from real chats is a copy of those chats and can carry the same personal data. It then falls under the same retention and erasure decision as the transcripts themselves, and that decision is best made before the set is built. Under India's DPDP Act, 2023, the erasure and retention duties commence in tranche (c), eighteen months after publication of the Rules, which the DPDP Act compliance page dates to May 2027, and that page covers how they will work.

Decide before launch what it does with a user who may be under eighteen. Under section 2(f) of the DPDP Act, 2023, which is already in force, a child "means an individual who has not completed the age of eighteen years". Section 9(1) will call for verifiable consent of a parent before a child's personal data is processed, section 9(4) allows prescribed classes of Data Fiduciary and prescribed purposes to be exempted, and Rule 12 of the DPDP Rules sets those out with conditions, all of which commence in tranche (c), eighteen months after publication of the Rules, which the DPDP Act compliance page dates to May 2027.