The short answer
A proportion of buyers have policies restricting AI processing of their data, sometimes absolutely and sometimes for particular categories.
Supporting that is a configuration problem rather than a product decision, provided the product still works with the features off.
Design for it from the start
- Make each AI feature independently switchable per customer.
- Ensure the underlying task is still possible manually.
- Do not degrade unrelated features when one is disabled.
- Make the setting visible and auditable to the customer.
- Enforce it at the data layer, not only in the interface.
Point five is what makes the commitment real. A hidden interface element is not an assurance that no data was sent.
Be able to state what is active
| Question | Answer needed |
|---|---|
| Which AI features are enabled | Per customer, current |
| What data would they see | Specifically |
| Where is it processed | Region and provider |
| Is anything retained | Including logs |
| Can this be audited | By them, ideally |
Being able to answer all five quickly is frequently what unblocks a deal. Not being able to answer them is read as not knowing.
Do not make the plain version worse
A product that becomes awkward without its AI features tells those customers they are second class, and they will notice.
The manual path should be a reasonable way to work, not a punishment for declining a feature.
Expect the requirement to move
- Policies change as organisations get comfortable
- Some will permit specific features but not others
- Some will permit it for some data categories only
- Regional rules may differ within one customer
- Approval may be time limited and need renewing
Granularity matters more than an on and off switch. Customers who can enable a single feature they are comfortable with frequently enable more later.