What should an organization do before implementing AI?

What is happening

Leadership wants a position on AI. Teams are experimenting. Vendors are adding AI features to products the organization already owns. The pressure is to show progress, and the fastest visible progress — a pilot — is often the least useful place to start.

Why readiness gets skipped

• AI capability arrives inside tools you already licensed, so no procurement gate is triggered.
• Pilots are cheap and easy to authorize; governance is neither.
• The perceived competitive risk of waiting outweighs the felt risk of moving early.
• Nobody has been made accountable for AI outcomes, so nobody is required to be ready.

What to do first

1. Start from a business problem

Identify two or three problems where the constraint is genuinely volume of reading, drafting, summarizing, classifying, or searching. Those are where current AI tools tend to help. Problems whose constraint is missing data, unclear ownership, or unresolved decisions are not AI problems.

2. Assess the ground truth

• What data does the use case require, where does it live, and who is permitted to see it?
• Is the underlying process consistent enough that an output can be judged right or wrong?
• How will an error be detected, and by whom?
• What would be the consequence of a confident, incorrect output reaching a customer, an employee, or a regulator?

3. Put a minimum decision path in place

Even at pilot stage, you need a way to record what tool is being used, what data it touches, who approved it, and who reviews the output. This is not heavyweight governance; it is an inventory and an approval route.

4. Name the owner

Someone must be accountable for AI-related risk — usually an existing risk, security, or technology leader rather than a new function. Ownership without authority does not count.

What not to do

• Do not begin with a tool selection. Begin with a use case.
• Do not pilot on regulated, confidential, or customer-identifiable data before controls exist.
• Do not build a policy that only says no — teams will route around it.
• Do not treat an AI feature inside an existing product as automatically approved because the product is.
• Do not promise headcount outcomes before the operating impact is understood.

Questions to ask

• What decision or task are we changing, and who is accountable for it today?
• What data leaves our environment, and under what contractual terms?
• How does a human verify the output, and how long does that take?
• What happens to the work if the tool is unavailable or the vendor changes terms?
• What does success look like in a measure we already track?

Warning signs

• The initiative is described by technology rather than by outcome.
• No one can list the AI tools currently in use across the organization.
• Pilots are running on production data without a documented approval.
• The business case depends on efficiency gains no one has defined how to measure.

When internal teams can handle it

Organizations with an established risk function, a clear data owner, and a technology leader with authority can usually run readiness internally. The work is disciplined rather than exotic.

When outside help may be appropriate

When AI use is already widespread and undocumented, when the organization operates under regulatory obligations it has not yet mapped to AI use, or when leadership needs an independent view of which use cases are worth pursuing.