AI controls in Cherryrise sit with the workspace admin, not with a vendor default: every AI feature is off until an admin turns it on, the off state is enforced on the server rather than just hidden in the UI, and nothing you process is ever used to train models across tenants. That combination — opt-in, admin-gated, per-workspace, and isolated — is the whole point of treating control as a feature instead of a footnote.
Why the admin holds the switch
AI in support touches customer data — message bodies, names, order details, whatever a customer happened to paste into a ticket. The decision to send that data through a model is a data-governance decision, so it belongs to the customer's admin, not to a default someone shipped. Each feature is opt-in, per workspace, and clearly labelled, so turning it on is a deliberate act with an obvious owner.
This matters most for teams with compliance obligations or strict multi-tenant isolation requirements. If you run a regulated workspace, you want to be able to say precisely which features are active and who enabled them — not discover after the fact that a model was reading threads because it was on out of the box.
Off by default, opt-in by design
A fresh Cherryrise workspace behaves as if the AI features do not exist. Nothing drafts replies, nothing summarizes threads, nothing auto-categorizes, until an admin opts in. "Off by default" is not a marketing posture here; it is the initial state of the configuration, and it stays that way through upgrades unless someone with the right role changes it.
The practical effect: enabling AI is a choice you make once you have read what each feature does, decided it fits your data policy, and assigned responsibility for it. That is the opposite of the common pattern where a new capability lights up everywhere on release and admins scramble to find the switch.
Gated server-side
A toggle that only hides a button in the UI isn't a control. If the request can still be made — by a script, an old client, or a crafted call — then "off" is a suggestion, not a guarantee. Cherryrise gates AI features server-side, so an "off" feature genuinely doesn't run: the code path that would call a model is never reached, and no thread text leaves the boundary.
This is the same principle as RBAC and assigned-only agents — permissions are enforced where it counts, on the server, not painted over in the front end. If you care about how access is scoped more broadly, the reasoning carries over from role-based access for support teams.
Per workspace, not per account
AI settings live with the workspace, not the account. That distinction matters for anyone running more than one workspace under one roof:
- An agency can enable drafting for one client's workspace and leave another fully off, matching each client's contract.
- A multi-brand company can pilot summaries in a single support team before deciding whether to roll wider.
- A self-hosted deployment keeps the same granularity — the switch is per workspace whether you run Cherryrise for us or on your own infrastructure.
Because the setting is scoped to the workspace, isolation between tenants is preserved by construction. Turning AI on for one workspace says nothing about, and does nothing to, any other.
No cross-tenant training
Cherryrise does not train models on your customer data, and nothing from one tenant is ever used to shape behavior for another. Processing happens per workspace, inside the same isolation boundary that enforces RBAC and data residency. There is no shared pool of your tickets quietly improving a model that other customers benefit from.
If your data-handling questions go deeper — residency, sub-processors, retention — the security page and the data residency checklist spell out the boundaries rather than waving at them.
Control as a feature
Framing matters. This is not "AI-powered" as a banner across the product; it's a switch you own, with a clear default and a clear owner. The same argument applies to replies — see should you let AI write support replies — and to the unglamorous, genuinely useful side of AI in AI triage and thread summaries.
Treating control as a first-class feature also means the off switch is documented, auditable, and reversible. You can turn a feature on, watch how it behaves, and turn it back off without a support ticket or a migration.
A checklist before you enable
Before flipping any AI feature on for a workspace, it's worth a short pass:
- Confirm ownership. Decide which admin role is responsible for the setting and who reviews it.
- Read what the feature touches. Drafting and summaries read thread content; auto-categorization reads inbound mail. Know the inputs.
- Match it to your data policy. If you have residency or retention commitments, confirm the feature fits inside them.
- Start narrow. Enable one feature in one workspace, observe, then widen.
- Keep the reverse path in mind. Because it's server-gated and per workspace, turning it back off is immediate and complete.
None of this is heavy process. The point is that an opt-in, admin-gated design gives you a place to make the decision deliberately instead of inheriting it.
Frequently asked questions
Is Cherryrise AI on by default?
No. Every AI feature is off by default. An admin has to turn it on, per workspace, before any AI runs. A fresh workspace behaves as if the features do not exist until someone with the right role opts in.
Does Cherryrise train models on our support data?
No. Cherryrise does not train models on your customer data, and nothing from one tenant is used to improve behavior for another. Processing happens per workspace inside your tenant's isolation boundary, which is the same boundary that enforces RBAC and data residency.
What does gated server-side actually mean?
It means the off switch is enforced on the server, not just in the interface. When a feature is off, the code path that would call a model is never reached, so no thread text is sent anywhere. Hiding a button in the UI is not a control, because the underlying request can still be made.
Can different workspaces have different AI settings?
Yes. AI settings are per workspace, so an agency or multi-brand team can enable drafting for one workspace and leave another fully off. The setting lives with the workspace, not the account, so isolation between tenants is preserved.
Every AI feature is admin-gated and server-side. See the controls or read security.