AI governance is often discussed as if it begins when somebody buys an AI platform. In reality, it starts much earlier.
It starts with the data already inside your systems, the decisions those systems already support, the permissions people already have, and the controls already in place around automation.
That is especially true inside Zoho One.
Zoho is increasingly embedding AI across CRM, Analytics, Desk, Creator, Recruit and other applications. That creates a lot of opportunity, but it also means AI governance cannot sit in a separate policy document somewhere outside the platform.
It has to exist inside the way the platform itself is designed.
The question is not simply: “Are we using AI responsibly?”
The more useful question is: “What is this AI allowed to see, what is it allowed to do, and how do we know when it gets something wrong?”
Those are architecture questions as much as governance questions.
AI governance is often discussed as if it begins when somebody buys an AI platform. In reality, it starts much earlier. It starts with the data already inside your systems, the decisions those systems already support, the permissions people already have, and the controls already in place around automation.
That is especially true inside Zoho One. Zoho is increasingly embedding AI across CRM, Analytics, Desk, Creator, Recruit and other applications. That creates a lot of opportunity, but it also means AI governance cannot sit in a separate policy document somewhere outside the platform. It has to exist inside the way the platform itself is designed.
The question is not simply: “Are we using AI responsibly?”
The more useful question is: “What is this AI allowed to see, what is it allowed to do, and how do we know when it gets something wrong?”
Those are architecture questions as much as governance questions.
One of the biggest mistakes organisations make is deploying AI because the capability exists.
Zia can summarise records, AI can classify tickets, Generative AI can draft communications, Agents can potentially trigger actions.
All useful capabilities, but the first question should still be:
What decision or process are we trying to improve?
For example, there is a meaningful difference between:
- summarising a CRM account for a salesperson;
- recommending the next action on a deal;
- automatically changing a customer status;
- generating a care-related recommendation;
- sending a customer communication without human review.
They all use AI – They do not carry the same level of risk – The governance model should reflect that.
A useful starting point is to classify use cases by consequence.
Low-risk use cases
These generally assist users without materially changing business outcomes.
Examples might include:
- summarising notes;
- drafting internal content;
- categorising records;
- suggesting responses;
- highlighting trends.
Human review remains easy and the AI is not making a binding decision.
Medium-risk use cases
These influence decisions or processes.
Examples might include:
- lead scoring;
- prioritising service cases;
- recommending candidate shortlists;
- suggesting workflow actions;
- identifying anomalies.
These require stronger oversight because AI output can influence what happens next.
High-risk use cases
These directly affect people, money, access, eligibility or regulated decisions.
Examples might include:
- automatically rejecting a candidate;
- making a credit decision;
- changing a clinical pathway;
- approving or denying access;
- initiating a financial action.
At that point, the governance requirement becomes much more significant.
The technology may be the same.
The consequence is no
This is one of the most important controls.
AI does not need access to everything simply because everything exists inside Zoho.
If an AI feature is operating inside CRM, ask:
- Which modules can it access?
- Which fields?
- Which records?
- Which user roles?
- Does it inherit the user’s existing permissions?
- Can it access sensitive or restricted information?
- Can generated output expose information from another record or team?
The same principle applies in Creator, Desk, Recruit, Analytics and elsewhere.
The correct model should be:
minimum necessary access for the use case.
Not:
give the AI broad access and control what users see afterwards.
That distinction matters.
Once AI is allowed to reason across multiple datasets, governance becomes much more difficult if those boundaries were never properly designe
Poor permissions become more dangerous when AI is introduced.
A badly designed role model might previously have meant that a user could manually find information they should not really see.
With AI, that same user may be able to ask for it directly.
That changes the risk profile.
Before enabling AI features broadly, I would review:
- roles;
- profiles;
- field-level access;
- record-level access;
- sharing rules;
- admin permissions;
- integration users;
- API access.
This is not glamorous AI work.
It is foundational.
If access control is weak, AI governance will be weak too.
“Human in the loop” is often used as a blanket governance phrase.
But simply involving a human does not automatically make a process safe.
The more useful question is:
Where does human judgement actually add control?
If AI drafts an email and a user reviews it before sending, that is meaningful.
If AI makes a complex recommendation and a user simply clicks “Approve” every time, the human step may add very little.
Good governance means designing human intervention around consequence.
The higher the impact of the AI output, the more meaningful that intervention should be.
That may mean:
- reviewing before action;
- requiring explicit approval;
- presenting the underlying data;
- showing confidence or rationale;
- allowing easy override;
- logging the final decision.
The goal is not to put people back into every step.
It is to put judgement where judgement matters.
This is particularly important as Zoho introduces more agentic capabilities.
There is a major difference between:
“Here is what I recommend.”
and:
“I have done it.”
An AI system that recommends a next action is advisory.
An AI system that updates records, sends messages, creates documents, changes workflow stages or triggers downstream processes is operational.
That creates a much higher governance requirement.
Before allowing AI to act, I would want clarity on:
- what actions it can perform;
- under what conditions;
- which systems it can change;
- whether approval is required;
- whether actions can be reversed;
- how failures are handled;
- how actions are logged.
The technical capability to act should never be confused with permission to act.
If AI contributes to a business decision, there should be enough evidence to reconstruct what happened.
That does not mean storing every token or every intermediate step.
It means retaining enough information to answer:
- what AI capability was used;
- what record or process it affected;
- what data it relied on;
- what output it produced;
- what action followed;
- who approved or overrode it;
- when it happened.
Without that, AI becomes difficult to govern operationally.
This is particularly important in regulated environments.
If a decision is challenged later, “the AI suggested it” is not a sufficient audit trail.
As organisations begin using AI agents, prompts become part of the control environment.
A prompt is no longer just text.
It can define:
- what an agent is trying to achieve;
- what information it can use;
- what actions it can perform;
- when it should escalate;
- how it should handle exceptions.
That means prompts and agent instructions should be treated more like configuration than casual user input.
For important workflows, I would expect:
- version control;
- testing;
- approval;
- documented ownership;
- controlled changes.
If somebody can materially change the behaviour of an enterprise AI agent by editing a prompt, that prompt is part of your application architecture.
Govern it accordingly.
This is one of the simplest tests I would apply.
If an existing process requires approval, AI should not silently route around it.
If a user cannot normally access a record, AI should not expose it indirectly.
If a workflow requires a mandatory field, AI should not create a record without it.
If an action normally generates an audit event, AI-triggered action should do the same.
AI should operate inside the control environment.
It should not create a parallel one.
That is where many governance problems begin.
Many organisations measure AI adoption.
How many users activated the feature?
How many prompts were submitted?
How many summaries were generated?
Those numbers can be useful, but they are not governance metrics.
Better questions include:
- How often is AI output overridden?
- How often is it wrong?
- Which use cases generate the most exceptions?
- Are certain teams relying on AI more heavily than others?
- Are users accepting recommendations without review?
- Are there patterns in incorrect output?
- Are AI-enabled processes actually improving outcomes?
Governance should evolve based on behaviour.
Not just policy.
Every meaningful AI use case should have somebody responsible for it.
Not merely the platform administrator.
There should be clear ownership across:
- business outcome;
- data;
- technical implementation;
- risk;
- ongoing monitoring.
If nobody owns the AI use case after launch, it will gradually become unmanaged.
That is no different from any other enterprise capability.
The difference is that AI behaviour can change as models, prompts, data and user behaviour change.
That makes ownership even more important.
For most organisations, AI governance does not need to begin with a huge committee or an enormous policy framework.
It can start with a simple control model.
For every AI use case, document:
| Question | What you need to know |
|---|---|
| What is the use case? | The specific process or decision being supported |
| What is the risk level? | Low, medium or high consequence |
| What data is used? | Systems, modules, fields and sensitivity |
| What can the AI do? | Read, recommend, create, update or trigger |
| Is human approval required? | Where judgement or sign-off sits |
| How is activity logged? | Evidence of output, action and override |
| Who owns it? | Business and technical accountability |
| How is it monitored? | Accuracy, exceptions and outcomes |
That is not the whole governance framework.
But it is a strong starting point.
And, more importantly, it is something teams can actually use.
The biggest mistake is treating governance as something that happens after AI has already been deployed.
By then, the difficult decisions have often already been made.
Permissions are already broad.
Data is already being shared.
Automations are already live.
Users have already built habits around the capability.
It is much easier to govern AI when the controls are part of the architecture from the beginning.
That means asking questions about data ownership, access, action, audit and accountability before enabling the feature.
Not after somebody raises a concern.
The organisations that get AI governance right will not necessarily be the ones with the longest policies.
They will be the ones where the platform itself makes responsible behaviour easier.
Good governance is often presented as a constraint.
I think that misses the point.
The objective is not to stop people using AI.
It is to create enough confidence that the organisation can use more of it safely.
When data ownership is clear, permissions are controlled, actions are auditable and higher-risk decisions have the right oversight, teams can move faster because they understand the boundaries.
That is what good governance should do.
Not create fear around AI.
Create confidence around how it is used.
About Mason & Co
Mason & Co helps organisations design and govern Zoho environments that need to scale without losing control.
We work across Zoho One, CRM, Creator, AI, automation, integrations, data and enterprise architecture, with a particular focus on environments where trust, auditability and operational resilience matter.
If AI is starting to appear across your Zoho estate but the governance model has not kept pace, an architecture and AI-readiness review is usually the right place to start.