Trust
An assistant that cannot refuse is a liability on a page where answers become commitments.
Control is not a settings screen. It is the combination of what the assistant can see, what it must refuse, and what it hands over instead.
- Private launchOnboarding selected teams now
- Answers from your pages onlyIt refuses when your content does not cover it
What it does
Three layers: source control decides what it can retrieve from, grounding and refusal decide what it will say, and escalation rules decide what it must hand to a person regardless.
Why it matters
On a marketing site the cost of a wrong answer is not a poor experience. It is a commitment your company did not make, in writing, to a buyer. An invented price or a misremembered policy is the expensive failure, and it is expensive precisely because it sounds plausible.
The dangerous hallucination is never the absurd one. It is the answer that is fluent, specific and slightly out of date, because nobody catches it.
Ownership matters for a different reason. Whoever holds the conversation log holds the record of what your customers could not find, which is a genuine asset. That should be settled in writing before it accumulates, not after.
How it works
Source control
The assistant retrieves only from sources you nominate. Nothing else is reachable, which is why source selection is the first control rather than a setup chore.
Grounding
Answers are phrased from the retrieved passages. Where they do not cover the question, the assistant says so.
Refusal as a first class behaviour
Refusal rate is a health metric, not a failure metric. An assistant that never refuses is either exceptionally well sourced or quietly improvising.
Guardrails in code, not only in the prompt
Rules written only into the system prompt are suggestions. Anything with commercial consequence, such as never quoting a price, belongs in code as well.
Escalation over improvisation
Where the assistant is uncertain and the stakes are high, handing over beats guessing.
Where a prompt rule is not enough
Instructions in a system prompt are strong defaults, not guarantees. They work almost always, and almost always is the wrong standard for anything with money attached.
The test is what happens if the rule fails once. If the answer is an awkward reply, a prompt rule is fine. If the answer is a written quote your company did not authorise, or a statement about data handling you cannot support, the rule needs to exist in code as well.
In practice that means a short list: never state a price not present in a retrieved passage, never confirm a compliance certification, never assert a contractual term, never claim availability of an unshipped feature. Four rules that belong in both places.
The reason to be specific rather than general is that broad prompt instructions to be careful degrade under a long conversation. Narrow rules enforced outside the model do not.
What is built and what is planned
A signed DPA, published retention periods and a current subprocessor list are planned before paid rollout. None of them exists today, and we would rather say so.
Where the data goes
Conversation data belongs to the site owner. Creobot holds no security certification and does not claim SOC 2, HIPAA, ISO 27001 or PCI DSS. It does not claim zero retention, and it does not claim that submitted data is never used for model training, because those depend on provider terms we will name on the subprocessor list rather than summarise here. Security and data boundaries.
Where this comes up
Questions
Trust
Is this the capability you need?
Access is by waitlist, demo request or public-content pilot. Tell us what your site has to answer and we will say honestly whether this covers it.