Aergent field notes / AI

Is Your Company Ready for AI? A Practical Readiness Check

Ten concrete questions on process, data, people, risk and management that determine whether an AI pilot is responsible.

21 Oct 2026
Published
5 min
Reading time
AI
Topic
100%
Open access

Your company is not “AI-ready” because employees use ChatGPT or because it owns a lot of data. You are ready for a defined AI use case when the problem is measurable, the required data is usable and permitted, someone can judge the output, and failures can be contained and corrected.

Readiness is deliberately use-case specific. An organisation may be ready to summarise internal meetings while being wholly unprepared for automated recruitment decisions.

Score each question 0, 1 or 2

  • 0 points: unknown, unmanaged or only an assumption;
  • 1 point: partly present but not yet tested;
  • 2 points: demonstrably managed, with an owner and evidence.

A high score is not a certificate. The check exposes missing conditions before you buy software.

1. Can the business problem be measured in one sentence?

“We want to do something with AI” scores zero. “Four employees spend 28 hours a week classifying 1,400 emails” is usable. Describe volume, current handling time, cost of errors and desired improvement. If the problem is not measurable, the pilot cannot prove it worked.

2. Did you consider ordinary automation first?

A fixed rule is cheaper, more predictable and easier to test than a language model. If “amounts above €10,000 require approval” solves the problem, AI is unnecessary. AI is most relevant to text, images, speech and variation that a small rule set cannot describe. Start with the framework for which processes to automate.

3. Do you have representative examples, including exceptions?

A pilot with ten tidy examples proves little when the production inbox also contains scans, sarcasm, duplicate attachments and unknown languages. Collect real cases across a relevant period, anonymise where possible and label the right outcome. Include difficult and rare cases deliberately.

4. May you use this data for this purpose?

Map personal data, confidential customer information, copyrighted material and trade secrets. Record which supplier receives data, where processing takes place, how long data is kept and whether input is used for model training. Remove fields the task does not need.

5. Is there a process owner with authority?

IT can operate the technology, but someone from the process must define a good outcome, an acceptable error and the point at which work stops. Without a process owner, the pilot remains a demonstration for which nobody has operational responsibility.

6. Can an expert reliably judge the output?

A reviewer needs to see the source information, change the result and understand the system's failure modes. If nobody can establish within a reasonable time whether an answer is correct, you cannot build a reliable evaluation set or meaningful human oversight.

7. Is there a baseline?

Before the pilot, measure handling time per case, throughput and backlog, error and rework rate, cost per case and customer or employee impact. Then compare total time including review and correction. AI ROI does not come from model accuracy alone.

8. Can the use case connect safely to existing systems?

Check APIs, export options, identity management, logging and limits. Prefer read access for a first pilot; write access comes only after proven evaluation and rollback.

9. Is the failure mode designed?

Define what happens at low confidence, missing evidence, an outage, a cost spike or an unusual request. The system must be able to say “insufficient information” and escalate to a person. A manual fallback is part of reliable design.

10. Are management, budget and adoption covered for six months?

Models, prices, sources and workflows change after the demo. Budget for monitoring, evaluations, security updates, support and training. Name who approves new versions and which cost or quality threshold automatically pauses the system.

Result

ScoreMeaningNext step
0–7Repair the foundations firstMeasure the process, organise data, appoint an owner and classify risk
8–14A small read-only pilot is possibleOne task, representative test set, human review and a fixed cost ceiling
15–20Ready for controlled implementationRun against the baseline; expand rights and autonomy only afterwards

A zero on question 4, 5, 6 or 9 is a stop sign even when the total is high. Lawful use, ownership, review and failure handling are not optional extras that other points can compensate for.

A 30-day preparation plan

  • Week 1 — process: choose one task and measure volume, time and errors.
  • Week 2 — data: collect representative cases, classify data and record supplier questions.
  • Week 3 — evaluation: define good outcomes, failure classes and escalation rules.
  • Week 4 — design: choose pilot architecture, permissions, cost ceiling, logging and stop criteria.

Only then compare models or suppliers. This lets the problem determine the technology instead of the reverse.

Sources

Amsterdam engineering team

Turn the idea into a working system.

Discuss the workflow behind this article with a senior engineer.

Optimization Complete