How do we keep an employee-built AI workflow running when its creator is on holiday?

Keep the workflow running only if somebody else can operate it safely. That means business-controlled accounts, a named deputy, useful operating notes, visible failures and a tested manual fallback. If those conditions are missing, pause the automation or reduce it to suggestions while its creator is away. Asking an employee to check messages from the beach is not a continuity plan.

The important buying question is whether your business can rely on the workflow, not whether a colleague managed to build something impressive. An assistant that sorts enquiries may depend on an email connection, a paid automation account, a model subscription, a spreadsheet and a scheduled task on somebody's laptop. Any one of those dependencies can fail while the visible chatbot still appears available.

The UK's National Cyber Security Centre explicitly advises small organisations not to leave responsibility for cyber security with a single person. Its small-organisations guide identifies 5.5 million UK organisations with between 0 and 49 employees. That is useful context, not an estimate of AI workflow failures: small teams need shared responsibility precisely because specialist cover is limited.

Start by asking the deputy to describe what the workflow does, what it may change and what happens when it stops. If the answer is vague, treat it as an unsupported experiment rather than a dependable business service. This is not a criticism of the employee who built it. It is the point where a useful personal improvement needs business ownership.

Source: NCSC small organisations guide.

A company email address on the invoice does not prove that the business controls the automation. Confirm who owns the workspace, who can recover administrator access, where billing notices go and which identity authorises each connected service. Use named accounts with appropriate permissions rather than everybody sharing the creator's password. Store necessary credentials in an approved business password manager with controlled access.

For example, a Microsoft Power Automate flow may rely on connections associated with a particular employee. A Zapier workflow or an n8n installation has its own ownership and connection arrangements. Check the actual product, plan and configuration rather than assuming that making someone a workspace member transfers every connection. Follow the supplier's supported transfer or shared-ownership arrangements and test them before leave begins.

The deputy needs permission to observe runs, stop new work and use the agreed fallback. They do not automatically need access to every mailbox, customer file or financial system. DSIT's voluntary AI Cyber Security Code of Practice, provision 2.6, calls for permissions on connected systems to be limited to what functionality requires and risk assessed. It is guidance, not a new universal legal requirement.

Do not weaken multi-factor authentication to make holiday cover easier. Set up authorised recovery and a second appropriate administrator where supported. Record when tokens, subscriptions or certificates expire. If the workflow runs on a laptop that will be switched off, move it to an approved business-managed runtime or stop promising unattended availability.

Source: DSIT voluntary AI Cyber Security Code of Practice.

Give the deputy a short operating record rather than a folder full of screenshots nobody can interpret. It should identify the business purpose, owner, trigger, systems connected, permitted actions, review requirements and expected outputs. Include where to see successful and failed runs, where exceptions wait, how to pause the workflow and how to confirm that downstream work has stopped.

Describe the difference between a technical success and a business success. A completed run might still have written a delivery address into the wrong record, skipped an attachment or drafted a misleading customer response. The deputy should know which checks matter for this particular process and which outputs still require human approval.

Use a clearly labelled hypothetical example: an enquiry-routing assistant usually receives 20 messages each working day. A day with no routed messages might mean there were no enquiries, or that the email connection failed. Monitoring should compare incoming work with completed and outstanding items, rather than merely announcing that the automation service is online. The figure is an illustration, not a market benchmark.

Set an escalation boundary. The deputy may restart a routine connection using approved instructions, but should not rewrite prompts, expand permissions or approve payments to get things moving. Record who can make those decisions and what happens if that person is unavailable. Good cover reduces improvisation; it does not turn a non-technical colleague into an emergency developer.

Run a rehearsal in which the deputy operates the workflow without help from its creator. Use safe test records or an appropriately controlled environment. Ask them to find an exception, recognise an incorrect output, pause processing and complete the essential work manually. The creator can observe, but should not supply every missing step from memory.

Include the ordinary failures your business could realistically encounter: an expired connection, an unavailable model, a missing field and an unexpected reply. You are testing whether the business can recover, not trying to prove that the AI can answer clever questions. Record what happened, fix unclear instructions and repeat only the affected checks.

If personal data is involved, availability is also part of security. The ICO's data-security guidance explains that appropriate measures must protect confidentiality, integrity and availability, enable timely restoration after an incident and be tested for effectiveness. The guidance is flagged as under review following the Data (Use and Access) Act, so check current advice for your situation. It does not say that every small workflow needs an enterprise disaster-recovery platform.

The practical pass condition is simple: an authorised colleague can maintain essential service or switch safely to a known alternative without contacting the holidaying employee. If that fails, reduce the scope before departure. A smaller, supervised process is preferable to a more ambitious system whose only recovery procedure is one person's memory.

Source: ICO data-security guidance.

Not every workflow deserves uninterrupted operation. If it drafts an optional weekly summary, pausing for a fortnight may have almost no business impact. If it updates job commitments or handles customer messages, you need a firmer decision about cover, approvals and outstanding work. If it can move money or make sensitive employment decisions, lack of qualified cover is a reason to stop those actions, not remove safeguards.

Compare support costs with a sensible manual alternative. Here is illustrative arithmetic, not our price or an industry rate: 30 minutes of manual cover per working day across 10 days is five hours. At an assumed internal labour cost of £25 an hour, that is £125. Compare that with a written support quote, any additional software seats and the consequences of mistakes. State whether quoted prices include VAT.

Existing Microsoft 365 tools, shared task lists or a straightforward non-AI rule may provide sufficient holiday cover. A managed service can be sensible for valuable or complex workflows, but ask what hours are covered, who owns recovery, what response means and whether the provider can actually repair your connected systems. A monitoring alert alone is not an operational support service.

Do not buy a custom continuity platform merely because an employee is taking leave. First use the ownership, access and monitoring facilities already available in your approved tools. Spend where a clear gap remains. If the workflow cannot be made supportable at a proportionate cost, the honest answer may be to retire it.

Do not keep an employee-built workflow running unattended when nobody understands its permissions, it uses personal accounts, or it can make significant commitments without review. A business owner accepting the risk does not remove duties to customers, employees or people whose data is being processed. Pause it until the operating arrangements match the consequences of failure.

Equally, do not impose a heavyweight support contract on every staff experiment. A personal assistant that rewrites internal notes and cannot act on business systems needs a different arrangement from an unattended workflow that changes records. Keep useful low-risk experimentation possible, but distinguish it from a service the rest of the team depends on.

Before leave starts, make an explicit decision: continue with named cover, run in suggestion-only mode, or pause with a manual fallback. Tell the affected team which option applies, who handles exceptions and when normal operation will be reviewed. Keep a record of outstanding items so the returning creator does not trigger duplicate work.

If you want help assessing a workflow, ask for a focused review of ownership, dependencies, recovery and the cost of the manual alternative. You should leave with a practical recommendation, including the possibility that you do not need more AI. The standard is not uninterrupted automation at any price. It is dependable business work without making an employee permanently on call.