In a recent leadership workshop, the discussion moved from using AI to building repeatable workflows, and then to a concern I hear a lot: how can you take responsibility for a system when you don't know enough to spot what might go wrong?
It's a fair question, and most of my answer is about who does what. If you're still working out which parts of a workflow need AI at all, start with AI and automation: where does each belong in your workflow?
You don't have to fill every role yourself
People often ask me "Do I need to learn to code?", and it usually turns into a more specific question. Do you want to commission an automation, describe the process, build it, check it or look after it?
Those jobs can be shared:
- The sponsor decides whether the problem is worth solving and provides the time and resources.
- The subject matter expert explains the rules, the exceptions and what happens when something goes wrong.
- The builder connects the systems and builds the workflow.
- The reviewer checks the results and challenges the assumptions.
- The owner looks after the automation once it's running.
In a small business, one person may hold several of these. Where the consequences justify it, an independent reviewer is worth arranging.
That's my answer to the question from the workshop. You can take responsibility for an automation you couldn't build yourself, as long as each of these roles is filled by someone with the knowledge to do it and the automation is tested before anyone relies on it.
I like putting thoughtful sceptics on the testing, because they tend to ask pointed questions about what could fail. Scepticism on its own isn't a qualification, though. Reviewers need relevant knowledge and clear acceptance criteria.
My article on automation literacy covers what you need to understand to take on these jobs, whether you build the system yourself or brief someone else.
Find the builders already in your business
Before you assume you need to hire someone, ask your team leaders: if someone had a problem with AI or wanted to connect two tools, who would they ask for help?
You may already have people experimenting with spreadsheets, integrations or AI tools who'd like to develop that skill. They also know the business: where the awkward handovers happen and which simple-looking rules have exceptions.
Being the person everyone asks for help doesn't automatically qualify someone to build a business-critical system, but it's a place to start. Look for curiosity, systematic thinking, a willingness to test assumptions and the judgement to ask for help.
Then give them time, training, approved tools and a project with clear limits. Pair them with the person who understands the process and someone who can review the technical work. If several people are doing this across the business, bring them together to share what they've built and learned.
Be clear about which capability you need. An AI champion can be excellent at helping colleagues use AI and have no interest in building integrations. A developer can understand the software and still need help with the business rules. One job title rarely covers all of it.
Leaders can help most by giving willing people a route to develop, with support that matches the responsibility. Asking someone to fit an unofficial automation job around a full workload is unlikely to produce something dependable, and it isn't fair on them either.
Bring internal or external IT into the build
In my own work, getting the right credentials and permissions can take more effort than defining the workflow. A tool can't retrieve a file or update a record unless it has access to the system that holds it.
That makes IT part of the design conversation. A builder knows how to connect the steps, while IT knows the existing systems, the access arrangements, hosting and recovery. If you wait until the demonstration is finished, you can find problems that would have changed the design.
Explain what the automation needs to read, what it needs to change and where it'll run. Give it the access that task requires, rather than copying every permission its human operator happens to have.
If you have internal IT, involve them in building a supported route from experiment to daily use. That can include an approved test environment, agreed ways to connect systems, access to technical review and clear conditions for taking a workflow into support. IT also needs budget, training and time for this bigger role.
I want IT to help people find workable ways to improve their processes. A blanket refusal leaves opportunities unexplored, and unrestricted experimentation creates problems somebody will have to clean up later. A supported route gives builders and IT something concrete to work towards.
If you use an external IT provider, have an explicit conversation about automation. Supporting laptops, accounts and backups doesn't mean the provider designs workflows or maintains custom software. They might offer those services, need to build them up or work alongside another specialist.
Before commissioning a build, agree who will:
- Design and build the workflow with the subject matter expert.
- Approve access and review the technical risks.
- Provide hosting, monitoring and recovery where needed.
- Fix failures and maintain integrations when other systems change.
- Keep the documentation and access arrangements usable if the builder leaves.
These jobs can belong to different people or suppliers. Spell out the handover between whoever builds the prototype and whoever will support the working system.
In my own consulting work, I can help define a workflow and build a prototype to explore it. Long-term operational support is a different commitment, and it needs an agreed home. A successful demonstration doesn't settle that question.
Build confidence through evidence
A working demonstration shows the idea can work. Before you rely on it, test it on examples where you know what the result should be, including unusual cases and failures.
Past work can give you a reference set. Compare the system's results with reviewed examples and investigate where they disagree. A previous human decision is worth comparing against, but it isn't automatically correct.
Then run a controlled pilot. At first, check every output, and reduce manual checking only when the evidence and the consequences justify it. A few successful weeks don't prove that rare, serious failures are covered. Some actions will keep needing approval, while other checks can be automated.
Count the time spent reviewing and correcting results when you assess the benefit. An automation that produces work quickly but creates hours of checking needs redesigning.
A quick version built with an AI coding assistant, sometimes called vibe coding, can help you explore a workflow, and what you learn from it shapes the work needed to make it dependable. I've covered that step in more detail in Non-coders can build useful software with AI.
Keep track of what you've put into use
Once people across a business start building automations, you need a shared record. Otherwise a workflow everyone depends on can become something nobody understands when its creator is away.
A spreadsheet is enough to start with. For each automation, record what it does, what triggers it, where it runs, who owns it, who supports it, what it can access or change, and how to stop or recover it. Flag anything that sends information outside the business, and whether someone approves it first. If you already have a register, use that.
The register tells you what exists. The testing, monitoring and ownership behind each entry are what make it safe to rely on.
Name the people for your first automation
Pick one workflow you want to automate. Write down who fills each of the five roles, who in IT needs to be involved, how you'll test it and where it'll be recorded. If any of those has no name against it, sort that out before anyone starts building.
If you're working out who should own your first automation, book a 25-minute Focus Call and we can talk it through.