1 of 8 in the AI adoption field guide
Readiness has very little to do with AI
Most organizations already have capable AI tools. Whether those tools pay off depends on things that were in place, or missing, long before the tools arrived.
When a company asks me to help it move faster with AI, the conversation usually starts with tools. Which platform, which license, which model. Within a meeting or two it has moved somewhere else: where a certain kind of information lives, who is allowed to see it, and who would know if it were wrong.
That shift is the point of this chapter. AI has a way of surfacing problems that have been sitting quietly for years. It can accelerate a business. It can also accelerate the problems the business already has.
What usually goes wrong
The tool goes in first. The early weeks look fine, because people try it on small, self-contained tasks. Then someone asks it a real business question, and the answer depends on things the tool cannot fix:
- Information scattered across several systems, with no agreement on which copy to trust.
- Permissions that grew by accident, so people can reach more than anyone intended, or less than they need.
- Information nobody owns, so nobody can say whether it is current or correct.
- Processes that live in a few people's heads.
- Older systems that were never built to connect to anything.
None of these is an AI problem. Each one becomes an AI problem the moment the tool depends on it. The usual reaction is to blame the tool, or to start shopping for a different one. A new tool will run into the same things.
What good looks like
Good does not mean perfect. It means that for the piece of work you want AI to help with, you can answer four questions without calling a meeting:
- Where does the information live, and which copy do we trust?
- Who owns it?
- Who can reach it today?
- How does the work get done, written down well enough that someone new could follow it?
You do not need those answers for the whole company. You need them for the first piece of work. The ordinary basics have to hold as well: the accounts that will use AI sign in through managed sign-in with multi-factor authentication, and any exceptions are written down.
The first three moves
Pick one piece of work and map what it needs
Choose something specific, such as a monthly report or a client deliverable. List every source of information it draws on, who owns each one, and how an AI tool would reach it. One page is enough.
Sort the sources into three groups
Ready to connect. Needs cleanup first. Stays out for now. The sorting is the decision. It sets the scope of your first pilot and gives you a cleanup list with a reason behind every item.
Write the process down as it really runs
Then hand it to someone who does not do the work and ask them to follow it. Wherever they get stuck, AI will get stuck too.
How to tell it is working
- Ask three people where a number comes from and you get the same answer.
- Every source in the pilot has a named owner who has agreed to own it.
- Someone outside the team can follow the written process without help.
- When the pilot turns up a problem, it goes to an owner instead of being blamed on the tool.
In practice
Before one company's pilot, I worked through a map of where its engineering, production, and accounting information lived. With the map in front of us, we could see which sources already had a connection and which still needed a path into the pilot.
That is what the map is for. It shows what a pilot can cover before anyone writes a prompt.
The question to ask first
Before asking “Which AI platform should we use?”, ask “Are we ready to get the most value from the tools we already have?”
The Foundations section of the self-assessment asks two questions about this area and tells you whether it needs attention before you expand.
Take the self-assessment