The answer in brief
Automate a step you can explain, supervise and measure.
AI automation for business combines system connections, explicit rules and, where useful, an AI model to move a repeatable process forward. A good first automation does not try to replace a job. It removes predictable handling around work that still has a responsible human owner.
Begin with a stable trigger, known inputs and a result that the process owner can judge. Give rules the exact checks, use AI for bounded interpretation or drafting, and route uncertain or consequential cases to a person. Record what happened so failures can be found and corrected.
Step one
Choose the first workflow by its shape, not its novelty.
The best candidate is usually familiar and slightly dull: people perform it often, the inputs already exist and avoidable handling slows it down. Score the process before discussing a model or platform. A weak process does not become stable because AI is added to it.
| Signal | Ready to explore | Better to wait |
|---|---|---|
| Frequent | The same task happens often enough to observe and compare. | The task is rare, seasonal or still being invented. |
| Bounded | A clear event starts it and a recognisable result finishes it. | The request is to automate a whole role or department. |
| Repeatable | Most cases follow known steps, with named exception owners. | Every case depends on undocumented judgement. |
| Observable | Inputs, actions, approvals and failures can be recorded. | Nobody can reconstruct what happened after a mistake. |
| Measurable | The process owner can define a useful baseline and outcome. | Success means only that the automation appears impressive. |
Three concrete starting points
Invoice follow-up
A bounded finance workflow with clear records, timing rules, exceptions and approval points.
Examine the workflowLead follow-up
A routing and response workflow where speed helps but commercial judgement stays with a person.
Examine the workflowCustomer onboarding
A coordination workflow spanning messages, information requests, internal tasks and access decisions.
Examine the workflowProcess before product
Map what actually happens before choosing tools.
Process documentation should describe a real case, including the unofficial workarounds. A tidy diagram based only on policy can miss the inbox, spreadsheet or message thread that keeps the process moving in practice.
Trigger and finish
What event starts the work? What observable state means it is complete?
Inputs and sources
Which fields and documents are needed? Which system is authoritative when records disagree?
Actions and permissions
What may be read, drafted, created, updated or sent? Which account authorises each action?
Decisions and owners
Which choices are exact rules? Which need judgement? Who approves or resolves exceptions?
Failure and recovery
What happens when data is missing, a dependency is unavailable or the same event arrives twice?
Baseline and evidence
How long does the process take now? Where does it wait, fail or create rework?
The resulting boundary becomes the basis of a written scope. See the documented discovery and decision process on our how we work page.
Divide work between rules, AI and people.
Reliable automation is usually a mixed system. Exact software rules are easier to test than model output, while people are better placed to own consequences, relationships and unusual context. Use AI only where its flexibility creates enough value to justify extra testing and review.
Rules
Use for dates, field validation, thresholds, duplicate prevention, routing and permissions. The expected result can be stated exactly.
AI
Use for bounded extraction, classification, summarising or drafting. Constrain the source material, output format and action that may follow.
People
Keep for approvals, exceptions, sensitive communication and decisions with material effects. Name the owner, response route and evidence they need.
A useful decision test
If a wrong output could deny access, commit money, create a binding promise, affect someone's rights or cause significant harm, do not let model confidence stand in for accountable approval. Reduce the scope or keep the decision with a suitable person.
From idea to operation
Move through seven evidence-building stages.
Observe the work
Walk through a real recent case with the person who does the task. Record the trigger, every system touched, the decisions made, the waiting points and the ways a case can go wrong.
Draw the boundary
State what the workflow may prepare or change, what it must never do and which decisions require approval. Excluding a risky step is often better than adding a complicated control around it.
Map data and access
List each field the workflow receives, why it is needed, its source of truth, where outputs go and who can see them. Confirm account ownership and the minimum permissions required.
Build the smallest useful path
Implement one end-to-end outcome before covering every variation. Use deterministic rules for exact conditions and introduce AI only where language or ambiguous input genuinely needs interpretation.
Test normal and awkward cases
Test missing fields, duplicates, delayed systems, bad formatting, misleading instructions, uncertain model outputs and actions that should be blocked. Define the expected safe result for each case.
Pilot with visible review
Run in draft-only, shadow or approval mode first. Let the process owner compare the workflow with current work and change the boundary before wider use.
Measure and decide
Compare the pilot with the baseline, including rework and exceptions as well as time saved. Keep, revise or stop the workflow based on evidence rather than sunk effort.
Our AI automation services page explains how those stages translate into a scoped business workflow.
Design safeguards and tests around the specific workflow.
Security and privacy are design inputs, not a final checklist. The appropriate controls depend on the data, systems, users and consequences in scope. Start by minimising what the workflow can access and what it is allowed to do.
Safeguards to decide
- Minimum data fields and system permissions.
- Approved sources for model context and prompts.
- Who may view, approve, retry or override an action.
- How secrets and service accounts are managed.
- What run history is needed without over-logging data.
- How retention and deletion fit the actual purpose.
- How the workflow pauses, rolls back or hands off.
Cases to test
- A valid ordinary record and a valid exception.
- Missing, stale, conflicting or malformed input.
- A duplicate trigger or delayed retry.
- An unavailable connected service.
- An instruction embedded in untrusted content.
- An unsupported or uncertain AI output.
- An action attempted without the required approval.
Read the fuller explanation of our security and data approach before proposing a process that handles personal, confidential or otherwise sensitive information.
Measure speed, quality, reliability and adoption together.
Time saved is useful but incomplete. A fast workflow that creates rework, hides exceptions or is ignored by its users has not improved the process. Agree a small set of measures before the pilot and compare equivalent cases.
- Speed
- Hands-on handling time, total elapsed time and waiting between owners.
- Quality
- Corrections, incomplete outputs, inappropriate drafts and avoidable rework.
- Reliability
- Completed runs, blocked actions, duplicates, retries and safe escalations.
- Adoption
- How often the intended team uses, accepts, edits or bypasses the workflow.
Set a review point and a stop condition. Expansion should follow evidence that the current boundary works; it should not be the default next step.
Before work begins
Ask a provider questions that expose the operating boundary.
- What exact trigger, output and exception path are in scope?
- Which systems, data fields and account permissions are required?
- Where can AI output influence an action, and who reviews it?
- How will duplicates, timeouts and partial failures be handled?
- What vendors receive data, and what settings or terms apply?
- What run records will exist, and who can inspect them?
- How will retention, deletion and handover be agreed?
- Which test cases and acceptance measures must pass?
- Who owns the workflow and connected accounts after handover?
- What condition would cause the pilot to pause or stop?
Sources and limitations.
This guide uses current primary guidance as a reference for questions and risk-management structure. It does not claim that The Free AI Guys is certified under these frameworks, that every control applies to every workflow or that following this guide guarantees compliance in any jurisdiction.
- NIST AI Risk Management Framework (opens in a new tab)
A voluntary framework organised around Govern, Map, Measure and Manage. NIST states that AI RMF 1.0 is being revised.
- UK ICO guidance on AI and data protection (opens in a new tab)
Risk-based guidance covering governance, transparency, lawfulness, fairness, security, data minimisation and rights. The ICO marks it as under review following legislative change.
- OAIC guidance on commercially available AI products (opens in a new tab)
Official Australian guidance on due diligence, privacy risks, data flows, human oversight, testing and ongoing monitoring.
Bring one process, not a technology shopping list.
Describe what starts the task, who performs it, the tools and data involved, where it gets stuck and what a good finish looks like. We can assess whether it has a sensible first boundary.
Apply Today