What should managers check before approving an AI automation built by an employee?

20 August 2026

Start with the purpose, not the tool

The first thing to check is boring but essential: what problem is the automation supposed to solve? If the answer is vague, do not approve it yet. A good employee-built AI automation should have a clear job, such as summarising inbound enquiries, checking forms for missing fields, drafting supplier follow-up emails, categorising support tickets, or preparing a weekly status report for human review.

The manager should ask for the purpose in one sentence, the current manual process, the expected time saving, and the person who will rely on the output. This stops useful experiments turning into hidden business systems. It also prevents a common small business problem: someone builds a workflow because it is technically possible, then the team quietly starts depending on it before anyone has checked whether it is accurate, secure or affordable.

For a UK SME, the approval threshold should rise with business impact. An automation that rewrites meeting notes is low risk if it uses non-sensitive content and a person checks the result. An automation that prioritises customer complaints, recommends refund decisions or updates CRM records is higher risk because mistakes can affect customers, cash flow and trust. The same AI tool can be harmless in one workflow and risky in another.

The UK government's AI Knowledge Hub describes AI governance as covering risk management, compliance, assurance, resource allocation, stakeholder engagement and alignment with business objectives. That sounds formal, but in a small business it can start with three questions: what is the business objective, what can go wrong, and who is accountable?

Do not approve a workflow because it feels clever. Approve it because it solves a real, repeated problem with a clear owner, a measurable benefit and a risk level the business understands.

Check what data the automation can see

The second check is data access. Ask exactly what the automation reads, stores, sends, copies or uploads. That includes obvious sources such as client files, emails, CRM records, invoices and spreadsheets, but also hidden sources such as browser extensions, connected drives, conversation history, API logs and copied text pasted into a chatbot.

If the workflow uses personal data, the UK GDPR matters. The ICO's AI and data protection guidance is clear that organisations using personal data in AI systems need to consider accountability, lawful basis, fairness, transparency, security and data minimisation. The ICO also provides an AI and data protection risk toolkit designed to help organisations identify and reduce data protection risks in AI systems. For a manager, the practical version is simple: if the automation does not need a data field, it should not receive it.

Employee-built automations often fail this test because they begin as private experiments. A member of staff may paste a customer email into a free AI tool, connect a personal automation account to a work spreadsheet, or give a workflow more CRM access than it needs because the default setting was easiest. That can create a data protection problem even when the employee was trying to help.

Use a narrow access rule. Start with read-only access where possible. Limit the workflow to one folder, one mailbox, one form, one CRM view or one exported report. Avoid giving employee-built automations broad access to the whole company drive, full CRM, full inbox or finance system. If the automation needs sensitive personal data, special category data, employee records, financial records or confidential client material, the manager should involve the data protection lead or external support before approval.

A useful test is: would you be comfortable explaining this data access to a client, employee or regulator? If not, the automation needs redesign before it goes live.

Review permissions, suppliers and security

Once the data is clear, check the permissions and supplier risk. Many small businesses use tools such as ChatGPT, Microsoft Copilot, Gemini, Zapier, Make, Power Automate, Airtable, Notion, HubSpot and browser extensions to build quick automations. The risk is not only the AI model. It is the chain of tools, accounts and permissions around it.

Ask which account owns the automation. If it is built under an employee's personal login, that is usually not good enough for a business process. What happens if the employee leaves, changes role, loses access or accidentally deletes it? A workflow that affects customers, operations or reporting should sit under a company-controlled account with admin access, documented ownership and sensible access controls.

The NCSC has warned that prompt injection and AI supply chain weaknesses can lead to serious security incidents. Its 2026 guidance on agentic AI also recommends starting small, using agents for low-risk tasks first, and applying established cyber security controls from the outset. For managers, that means treating AI automations like any other connected system: check authentication, logging, permissions, supplier trust, and who can change the workflow.

Be especially careful with browser extensions and unofficial connectors. A spreadsheet add-on that can read every tab, a Chrome extension that can access pages you visit, or a no-code connector with broad permissions may create more risk than the automation saves. Ask whether the supplier has business terms, data processing information, security documentation, export options and support. Free tools are not automatically unsafe, but they often lack the controls a business needs.

For most employee-built automations, a reasonable first approval standard is company account only, least-privilege permissions, named owner, documented supplier list, and no password sharing. If any of those are missing, fix them before approval.

Test the output before anyone relies on it

The fourth check is testing. An employee saying it worked on a few examples is not enough if the automation will affect real work. The manager should ask to see a small test record: what inputs were used, what outputs came back, what was checked, what failed, and what changed as a result.

For a low-risk workflow, 10 to 20 test cases may be enough. For example, if the automation classifies inbound enquiries into sales, support and finance buckets, test it against simple cases, messy cases, old enquiries, edge cases and deliberately confusing examples. If the automation drafts supplier chasing emails, test whether it stays polite, uses accurate order details, avoids making false promises, and flags cases where a person should step in.

For higher-risk workflows, testing should be more structured. Use real examples where appropriate, but remove unnecessary personal data. Compare the AI output against the old manual process. Track false positives, false negatives, missed exceptions and time spent checking. If the workflow saves two hours but creates one hour of review and half an hour of correction, the real saving is only 30 minutes. That may still be worth it, but the business should know the truth.

Testing should include failure behaviour. What does the automation do when the input is blank, ambiguous, duplicated, outdated or outside the allowed scope? Does it guess, stop, ask for help, or escalate to a person? The safest internal AI workflows are often the ones that confidently refuse to act when the input is not good enough.

Set a minimum evidence rule. Before approval, the employee should show the manager the workflow, the test examples, the known limitations and the human review point. If the business cannot see how it was tested, it should not be treated as approved.

Decide where human review is mandatory

Managers should be very clear about the difference between AI assistance and business authority. An employee-built automation can prepare, summarise, draft, check, flag and route work. It should not quietly become the final decision-maker for anything that affects money, contracts, customers, staff, legal rights, regulated work or sensitive data.

In a UK small business, mandatory human review should apply where the output affects a customer commitment, price, refund, complaint, credit decision, employee matter, supplier payment, contract position, legal interpretation, financial recommendation or health and safety issue. It should also apply where the AI output may be biased, incomplete, out of date or difficult for the affected person to challenge.

This is not just caution. The ICO's guidance on AI and data protection includes accountability and governance expectations for AI systems, and UK organisations remain responsible for how personal data is processed. If an AI workflow gives a wrong answer to a customer or causes an unfair internal decision, the business cannot simply blame the software or the employee who built the automation.

Build the review into the workflow, not into a vague policy. For example, the automation can draft a customer response but require a team leader to approve before sending. It can flag overdue invoices but require finance to approve the chase message. It can summarise job applications but should not rank candidates unless the business has assessed discrimination, transparency and employment risk properly.

A good manager approval should state the review rule in plain English: who checks the output, when they check it, what they are checking for, and what they must do if the answer looks wrong. If nobody owns the review, the automation is not ready.

Document ownership, cost and rollback

The last approval check is operational. Who owns the automation after it goes live? Who fixes it if it breaks? Who pays for it? Who reviews it after 30 days? How does the team stop using it if it starts causing problems?

This is where many employee-built workflows become fragile. They work brilliantly while the enthusiastic person who built them is nearby, then fail when a supplier changes an API, a spreadsheet column is renamed, a prompt stops behaving, a licence expires or the employee leaves. The business may not even realise the automation is failing until customers complain or records become messy.

For a small business, the documentation does not need to be a 40-page technical manual. A one-page AI automation register is enough for most low and medium-risk workflows. Record the name, purpose, owner, tools used, data accessed, permissions, review rule, monthly cost, known risks, test date, approval date, next review date and rollback step. If you cannot write those things down, you probably do not understand the workflow well enough to approve it.

Cost deserves a real check. A no-code automation may begin on a free tier and become expensive once task volume rises. A £25 per month tool can also create hidden costs if three people spend time checking, correcting and maintaining it. Approve based on net value, not subscription price alone.

Finally, require a fallback. The team should know how to pause the automation, who to tell, what manual process to use, and how to check whether recent outputs need correction. This matters because AI workflows do not always fail loudly. Sometimes they quietly drift, skip records, misclassify work or produce plausible but wrong answers. A rollback plan is not pessimism. It is basic operational hygiene.

When this is NOT right for you

Employee-built AI automation is not right for every process. It is not the right starting point for payroll decisions, hiring or dismissal recommendations, credit approvals, final legal advice, medical or safety-critical decisions, regulated financial advice, high-value contractual commitments, or anything that processes sensitive personal data without proper controls.

It is also not right if the employee cannot explain how the workflow works, the business cannot access the account, the supplier is unknown, the automation needs broad access to company systems, or nobody has time to review the outputs. Those are not minor gaps. They are warning signs that a useful experiment is being asked to carry more risk than it can safely handle.

If the idea is valuable but risky, do not throw it away. Move it into a managed project. Narrow the scope, reduce the data access, add human approval, use business accounts, document the supplier position, and test it properly. The goal is not to stop staff innovating. The goal is to make sure useful ideas become dependable business processes rather than hidden liabilities.

Is This Right For You?

This checklist is right for you if staff are already building useful AI workflows in ChatGPT, Copilot, Zapier, Make, spreadsheets, CRM tools or browser extensions, and you need a sensible approval process without creating enterprise-level bureaucracy.

It is not enough if the automation makes final decisions about jobs, pay, credit, refunds, eligibility, legal advice, regulated work or sensitive personal data. Those use cases need formal governance, data protection input and, often, specialist legal or technical review before approval.

Frequently Asked Questions

Should managers ban staff from building their own AI automations?

Usually no. A blanket ban often drives useful experimentation underground. A better approach is to allow low-risk experiments, require approval before operational use, and set clear rules for data, permissions, testing and human review.

What is the minimum approval checklist for a low-risk AI automation?

Check the purpose, owner, tools used, data accessed, permissions, test examples, review point, monthly cost and rollback step. For simple internal workflows, that can fit on one page.

When does an employee-built automation need a DPIA?

If it processes personal data in a way that is likely to create high risk, especially through profiling, monitoring, sensitive data, automated decisions or large-scale processing, you should assess whether a Data Protection Impact Assessment is required. Take data protection advice if unsure.

Can staff use personal ChatGPT, Zapier or Make accounts for business automations?

Not for anything the business relies on. Operational workflows should use company-controlled accounts with admin access, proper permissions and documented ownership, otherwise the business may lose control when the employee leaves or changes role.

How much testing is enough before approval?

For low-risk workflows, test 10 to 20 varied examples and record the results. For anything customer-facing, financial, staff-related or data-sensitive, use a larger test set, include edge cases and require human review before live use.

Who should approve an employee-built AI automation?

The workflow manager should approve the business purpose and process impact. A data protection or operations lead should review personal data and permissions. Technical support should review integrations and security where the automation touches core systems.

What should happen after approval?

Run the automation under supervision, review it after 30 days, measure the real time saving, check errors, update documentation and confirm whether it should continue, change or be retired.

What is the biggest red flag?

The biggest red flag is an automation that touches real customers, money, staff or sensitive data, but nobody can explain the data access, testing, review process or rollback plan.