The guide to becoming AI-native.

01

Fund the use case that happens every day, needs little judgment at most of its steps, takes its inputs from systems you already control, and has a number you can read before and after. Keep a person at the steps that need judgment. The first project should be the one most likely to reach production, because its results are what pay for the second.

02

No, not across the whole business. You need the inputs to the one process you've chosen to be reliable: where the work arrives, what it contains, and which system holds the record. Fix those for that process, start, and let the wider clean-up follow once the first system is running and creating consistent records.

03

Workflow automation runs steps that are the same every time, such as creating a record when a form arrives. An AI agent handles steps where the input varies, such as reading a document in any layout or working out what an email is asking. If every step of your process can be written as a one-line rule, you need automation. Where a step needs reading or judgment, put an agent inside the automation and have a person check what it produces.

04

Four things decide most of the cost of an AI project: how many systems it has to connect, how many kinds of exception it has to handle, how much testing it takes before your team trusts it, and what it costs to run after launch. The number of steps and the choice of AI model matter far less. You shape three of the four before you ask for a proposal, by picking a process in one or two systems and sending its exceptions to a person.

05

Connect each AI system only to the data its job needs, get in writing where it runs and whether your data is used for training, give access by role and log every action, with a named person reviewing a sample each week. Add a one-page policy for staff use of public AI tools and a short record of each system, which answers most customer security questionnaires. A named owner and a weekly routine are enough, without a security team.

06

Pick a first process your team is glad to hand over, build it with the people who do the work, and keep their decisions visible in it. Deliver the work inside the tools they already use, close the old route on a set date and tell them what the saved hours are for. A company with no change-management function can do all of this with one named owner and a short routine for the first month.

07

Pick one measure tied to the process before anything is built, take its reading before the change, and take it again after launch with the same method. On the return side, count the hours the system took on, the errors it removed and the work it made possible. On the cost side, count the build, the running cost and your team's time. Without a reading from before, you can't prove the result after.

08

Ask who owns the system after launch, what happens when it gets something wrong, and how the result will be measured. Then ask where your data goes, which of your systems they've connected before, how they'll test with your real cases, what the work needs from your team, what support looks like after launch, and what they'd advise you not to automate. A partner who can't answer the first three plainly is a risk at any price.