Should staff be allowed to build their own AI automations at work?

6 September 2026

Why this question matters now

Staff are already using AI at work, whether leaders have planned for it or not. The Office for National Statistics reported that AI use among UK businesses with 10 or more employees rose from around 12% in late 2023 to around 35% by June 2026, while 28% of businesses with 0 to 9 employees also reported using at least one AI technology. That means the question is no longer whether AI will enter everyday work. It already has.

The more practical question is whether your business wants this activity to happen visibly or quietly. When an employee builds a small automation to summarise enquiries, chase missing job notes, draft responses or move data between tools, they may be solving a real operational problem. They may also be creating a process nobody else understands, using a tool nobody has approved, with data nobody has assessed.

SAP UK reported in 2026 that 68% of organisations said staff use unapproved AI tools at least occasionally, while 60% said employees had not completed comprehensive AI training. That gap is the danger. Enthusiasm is useful. Hidden enthusiasm is risky. If people are automating work because the approved systems are too slow, too manual or too frustrating, banning AI outright usually pushes the behaviour underground.

The better answer is to treat employee-built automation as a controlled innovation channel. Let staff propose ideas. Let them test low-risk prototypes. But require a simple approval gate before anything becomes part of the working process. That protects the business without wasting the insight of the people closest to the work.

Source: Office for National Statistics, Artificial intelligence in UK businesses and SAP UK, AI training and shadow AI research.

What staff should be allowed to build

For most UK SMEs, staff should be allowed to build or suggest AI automations that assist with preparation, organisation and low-risk admin. Good first examples include summarising internal meeting notes, drafting non-sensitive checklists, turning approved templates into first drafts, flagging missing fields in forms, sorting generic enquiries for human review, preparing weekly task summaries, or creating reminders from project notes.

The common thread is that the automation helps a person work faster, but does not quietly make a binding decision. A useful staff-built automation should produce a draft, a flag, a recommendation or a queue. It should not approve a payment, reject a job applicant, send final advice to a client, update prices, change a customer contract, delete records, or publish public content without review.

A simple traffic-light rule works well. Green automations are personal productivity helpers using no personal data or confidential client information. Amber automations touch internal business data or shared workflows and need manager approval before use. Red automations affect customers, finance, HR, legal, safety, regulated advice, system permissions or public communications and need proper technical and management review.

This is where tools matter. It is one thing for someone to use an approved Microsoft Copilot workspace, ChatGPT Team, Gemini for Workspace, Make, Zapier or Power Automate environment with company accounts and access controls. It is very different for them to connect a personal AI account to business spreadsheets, emails or CRM exports. The business needs to know where the data goes, who can access the workflow, what happens if the employee leaves, and how the automation can be switched off.

The policy does not need to be a 40-page document. A one-page rule set plus a lightweight AI register is enough for many small businesses. The register should record the tool, purpose, owner, data used, permissions, review date, estimated saving, known risks and fallback process.

What should managers check before approving it

Before approving a staff-built AI automation, a manager should ask seven plain questions. What job does it do? What data can it see? What systems can it change? What could go wrong? Who checks the output? Who owns it? How do we turn it off?

That checklist sounds basic, but it catches most of the real risks. If nobody can explain the job, the automation is probably too vague. If it needs access to customer data, contracts, accounts records or HR information, it needs a higher level of review. If it can change live records, send messages externally or trigger another process, it is no longer a personal productivity hack. It is part of the business operation.

Managers should also require a short test before approval. Use five to ten real but safe examples, preferably anonymised where personal data is not needed. Check whether the automation handles normal cases, missing information, ambiguous instructions and obvious errors. Record what it got wrong. If the person who built it cannot explain why the errors happened or how the team should spot them, it is not ready for routine use.

Costs should be visible too. A small automation may look free if it uses an existing AI subscription, but hidden costs can include extra licences, API usage, maintenance time, training, documentation and support when it breaks. A sensible approval note should estimate both sides: hours saved per month and expected running cost. If the automation saves 10 hours a month in admin and costs £30 a month in software, it may be worthwhile. If it saves 20 minutes but creates a fragile process nobody can support, it probably is not.

Most importantly, approval should not depend on whether the automation is impressive in a demo. It should depend on whether it makes a real process safer, faster or more consistent when ordinary staff use it on ordinary work.

The data protection and security line

The line becomes much firmer when personal data, client information or confidential business records are involved. The ICO's AI and data protection guidance points organisations back to core UK GDPR principles: accountability, governance, lawfulness, fairness, transparency and accuracy. A staff-built automation does not get a free pass just because it was created informally.

If an automation processes personal data, the business still needs to understand the lawful basis, data minimisation, retention, access controls and risks to individuals. For higher-risk processing, a data protection impact assessment may be needed. If the automation produces recommendations about people, such as customers, employees, job applicants or vulnerable individuals, managers should be especially careful about fairness, explainability and human review.

The National Cyber Security Centre's shadow IT guidance is directly relevant. It describes shadow IT as unknown assets used for business purposes outside corporate processes, and explicitly notes that this can include unauthorised AI technologies. The NCSC also makes an important practical point: shadow IT is rarely malicious. It often happens because staff are trying to get work done when approved tools or processes are not adequate.

That matters for management tone. If you punish every unofficial experiment, staff will hide what they are doing. If you ignore it, you lose visibility. The better route is a no-blame disclosure path: tell staff they can bring existing AI automations forward for review without automatic trouble, provided they stop any risky data use while it is assessed.

For a small business, a safe minimum standard is this: no passwords, no bank details, no special category data, no confidential client files, no employment decisions, no live CRM writes, and no external messages without approval. Start there, then create approved routes for useful ideas that genuinely need more access.

Source: ICO, Guidance on AI and data protection and NCSC, Shadow IT guidance.

When this is NOT right for you

Staff-built AI automation is not right for you if your business has no agreed tools, no data rules, no manager ownership and no appetite for review. In that situation, letting everyone automate freely will create a mess: duplicated workflows, inconsistent customer handling, hidden data exposure, unclear accountability and broken processes when the original builder moves role or leaves.

It is also not right for tasks where the downside of a mistake is serious. Do not start with payroll, HR decisions, credit control, legal advice, regulated professional judgement, safeguarding, medical information, high-value sales commitments or finance approvals. AI can help prepare information in those areas, but it should not run them independently.

There is another honest limit. Some staff-built automations are clever but not worth adopting. A workflow that saves one person five minutes a week may still be fine as a personal helper, but it should not become company infrastructure unless the saving, reliability and maintainability justify it. The business should avoid turning every good idea into a permanent system.

The strongest approach is staged. Let people suggest improvements. Let trusted staff prototype in a sandbox or approved workspace. Review the best ideas monthly. Adopt only the automations that solve repeated work, reduce errors, improve handovers or give managers better visibility. Document them lightly, train the team, and set a review date.

If you do that, employee-built AI automation becomes a useful signal about where the business is too manual. If you do not, it becomes another unmanaged process problem wearing a modern label.

Is This Right For You?

This approach is right for you if your team is already finding clever ways to save time with ChatGPT, Copilot, Gemini, Zapier, Make, Power Automate or similar tools, and you want to bring that work into the open without killing useful initiative.

It is not right if you want staff to automate finance approvals, HR decisions, legal advice, customer commitments or regulated work without proper review. In those areas, AI can still assist, but a qualified person must stay accountable for the final decision.

A good rule is simple: encourage ideas widely, approve automations carefully, and start with workflows where a mistake is easy to spot and cheap to fix.

Frequently Asked Questions

Can staff use ChatGPT to automate their own admin?

Yes, if the task is low risk and does not involve confidential, personal or customer data. For anything connected to shared systems, customer records or business decisions, they should use approved tools and get manager approval first.

What should be banned completely?

Ban staff from putting passwords, bank details, confidential client files, employee records, special category data, legal advice requests, HR decisions or final finance approvals into unapproved AI tools. Also ban automations that send external messages or change live records without review.

Do we need an AI register for small staff automations?

Yes, but keep it simple. Record the tool, purpose, owner, data used, permissions, review date, risks and fallback process. A lightweight spreadsheet is enough for many SMEs.

Who should approve employee-built AI automations?

The line manager should approve low-risk workflow helpers. Anything involving personal data, customer impact, finance, HR, legal, regulated work or system access should also be reviewed by the business owner, data protection lead or external IT support.

What if staff are already using unapproved AI tools?

Use a no-blame review process. Ask people what they are using, what problem it solves and what data it touches. Stop risky use immediately, then decide whether to replace it, approve it with controls, or remove it.

How do we know whether an automation is worth keeping?

Measure hours saved, errors reduced, turnaround time, rework, staff feedback and support burden. If the automation saves meaningful time without creating hidden risk or maintenance problems, keep it. If it is fragile or rarely used, retire it.