A business is ready for an AI pilot when it can name one useful outcome, provide the information needed to deliver it, assign an accountable owner and measure what happens. You do not need to modernise the entire company first. You do need a process that someone can explain and a way to stop the pilot if it creates more work than it removes.
What does AI readiness mean in practice?
Readiness means having the evidence and operating conditions to test a specific use case, rather than simply having access to an AI tool.
An enquiry assistant, a document classifier and a forecasting feature need different inputs and success criteria. A business-wide maturity score can hide those differences. Start with the proposed task and ask what must be true for that task to work.
NIST's voluntary AI Risk Management Framework organises risk work around Govern, Map, Measure and Manage. It is a useful reference for accountability and evaluation, but it is not a certification that your proposed system is ready. The worksheet below is PROMTURE's practical planning aid, not an official NIST assessment.
Sources: NIST — AI Risk Management Framework
Which questions should you answer before a pilot?
Check the process, information, authority, integrations, baseline and ownership separately. An unresolved permission boundary should not disappear inside an average score.
Mark each area ready, needs work or unknown. Attach an example or a document to every ready answer. If nobody can demonstrate where the current price or approval rule comes from, treat it as unknown even if the team believes the data exists.
| Area | Evidence to collect | Resolve before launch |
|---|---|---|
| Process | One completed case and one exception | Conflicting definitions of completion |
| Information | Approved sources with an update owner | Outdated or contradictory facts |
| Authority | Allowed reads, writes and reviewers | Access broader than the task needs |
| Integration | A tested route into the receiving system | Manual copying hidden in the demo |
| Baseline | Handling time, corrections and task volume | No way to compare the result |
| Operations | An owner, fallback and recurring budget | Nobody responsible after delivery |
How much data do you need to begin?
Enough representative information to expose the task's normal cases, exceptions and limits; there is no useful universal minimum.
For a service-enquiry pilot, collect approved service descriptions, qualification rules and examples of enquiries that were accepted, declined or redirected. Remove personal details that the pilot does not need. Include incomplete messages and requests outside your offering, rather than selecting only easy examples.
Create a small source register with a location, owner, review date and access rule for each document. A spreadsheet can be sufficient for this register. The important decision is who resolves conflicting versions, not which storage product has the most features.
If the task depends on live stock, account balances or delivery capacity, static documents are insufficient. Confirm that the pilot can retrieve the authoritative current value or clearly defer the answer. A model should not fill a missing operational fact with a plausible guess.
What should the first pilot actually do?
Choose a bounded task with a visible output and an affordable manual fallback.
Consider an illustrative agency that receives mixed website and support enquiries. Its pilot could classify each message and prepare a suggested response for review. It would not quote a price, promise a deadline or send the reply independently. The reviewer can compare the suggestion with the original enquiry and correct it before use.
Measure total handling time including review, useful classifications, missed urgent requests and the reasons suggestions were rejected. A draft produced in seconds has little value if it takes longer to verify than writing a fresh response. Compare the pilot with the current process on the same kinds of enquiries.
Write the decision rule before testing: expand if the agreed quality and effort targets hold; narrow the task if one category causes most failures; stop if review overhead outweighs the benefit. This turns a pilot into a purchasing decision rather than an indefinite experiment.
What should you bring to an AI implementation discussion?
Bring the workflow, sample cases, source register, constraints and a named decision-maker.
Ask the implementation partner to identify the assumptions that could invalidate the project. Request separate estimates for discovery, integration, ongoing usage and maintenance. Agree who owns the accounts, configuration, evaluation examples and documentation at handover.
PROMTURE's recommended starting brief fits on one page: the task, current friction, required systems, prohibited actions, proposed measurements and the person who can approve a change. This is enough to scope a focused discovery conversation without pretending the solution is already known.
Common questions
Do we need a data warehouse before using AI?
Not for every use case. A narrow pilot may work with a small set of maintained documents and existing systems. Build additional data infrastructure only when the task's scale, freshness or access requirements justify it.
Can we start if our processes still use spreadsheets?
Yes, if ownership, record identity and update rules are clear. First resolve contradictory versions and uncontrolled edits. Moving the same confusion into a new database will not resolve it.
Who should own an AI pilot?
The person accountable for the business outcome should own the acceptance criteria. Technical teams own implementation and system health; operational staff must be able to review failures and continue essential work.