As the tech becomes more capable, is it realistic to expect non-specialists to understand its technical risks?
ON OCT 1, 2026, it was reported that more than 95,000 customers’ e-mail addresses had been exposed, after an employee of Bee Cheng Hiang used an artificial intelligence tool to help generate code for a marketing e-mail programme.
The Personal Data Protection Commission’s investigation found that AI was used to assist with writing code that subsequently handled a local mailing list. The code was deployed without adequate testing and review.
Singapore’s first AI-related data breach shows the dilemma small and medium-sized enterprises (SMEs) face in AI adoption: The more capable AI becomes, the less realistic it is to expect non-technical employees to spot the underlying technical risks.
SMEs are often already short-staffed, with employees wearing multiple hats. The same employee introducing an AI tool may be responsible for marketing, operations and customer communications.
In many SMEs, there may be no software engineer to review AI-generated code, no cybersecurity specialist to assess an integration and no data-governance team to determine what information an AI system should be allowed to access.
Large companies can draw on dedicated developers, cybersecurity specialists, data-protection officers, legal teams and internal audit functions. They can build policies around AI use and put specialists between employees and higher-risk technology.
Most SMEs cannot.
At the same time, the very reason SMEs are turning to AI is to move faster and do more with fewer people.
If safe adoption requires the same layers of specialist oversight and controls expected of a large organisation, SMEs risk losing the agility that makes AI valuable to them in the first place. The question, therefore, is not simply how SMEs can adopt AI safely, but how AI governance can be made accessible enough for small businesses to use, without requiring them to become experts in governance themselves.
The answer cannot be to tell SMEs to build more sophisticated governance frameworks.
Governance needs to be translated into product design #
Major enterprise platforms already offer extensive security controls and activity logs. However, these tools are typically designed for IT administrators, not an SME owner balancing daily operations.
Knowing that permissions can be configured in a complex admin console is very different from knowing which permissions are appropriate for a daily workflow.
To drive safe adoption among SMEs, the next generation of AI products should compete not only on capability, but also on how easily a non-technical user can understand, verify and control what the system does.
An SME owner should not need to understand software architecture to know whether an AI assistant can access the company’s customer database. The product should make that clear.
When an AI system is connected to an e-mail account, shared drive or customer database, the business should be able to see:
- what information the system can access;
- which applications and files it can reach;
- where information is processed;
- what the system is authorised to do;
- which actions require human approval; and
- how those permissions can be changed.
They should be visible and understandable at the point of configuration, not buried in technical documentation.
Crucially, permissions should follow the task, not the maximum capability of the technology.
An AI system that can read an inbox should not automatically have permission to send from it. One that analyses a customer database should not automatically be able to modify the records.
This is particularly important as AI becomes more agentic.
Traditional software generally performs a defined function when instructed. An AI agent can potentially interpret information, make decisions and execute a series of actions across different systems.
The product should therefore allow businesses to control these levels of autonomy rather than treating them as a single switch. Boundaries must be enforced at the software layer, rather than left to instructions in a prompt.
If an AI agent drafts a customer e-mail, the application itself should withhold the “send” until a human explicitly authorises it. After the workflow has been tested and its failure modes understood, the business can then expand the AI’s access or automate selected low-risk actions. Oversight also requires explainability.
For non-technical managers to review AI outputs safely, products should display their intermediate analytical steps and data sources alongside final results. This allows a business owner to check the logic against familiar commercial reality without needing to inspect raw code.
If a product is marketed to an SME on the basis that the business does not need a team of technical specialists to use it, the product cannot assume a tech team will be available when something goes wrong.
Operational safety must be designed directly into the product itself.
Testing tools should make it easy to test workflows before they touch live data.
Permissions should be granular and easy to modify. Higher-risk actions should have appropriate approval mechanisms. Activity should be sufficiently visible for a business owner to understand what the system has accessed and done.
This is not about eliminating human responsibility. Businesses remain responsible for how they deploy technology and handle personal data. But as AI tools grow more capable and complex, the burden of risk management must shift.
If AI is going to democratise capabilities once reserved for specialists, the industry also needs to democratise the guardrails that specialists used to provide: clear permissions, meaningful testing, appropriate oversight and controlled access. The writer is the founder and chief executive of Estha, an AI software company. AI tools were used for editing before submission. The writer remains fully accountable for the commentary’s accuracy, originality and final form.