Written by Most AI readiness assessments get run backwards; and before you know, you might find yourself in an AI-project quagmire.
On this page
In most cases, someone decides the company needs AI, a vendor is shortlisted, and only then does anyone check whether the data behind the decision exists in a usable state. It usually doesn’t, and the project stalls between proof of concept and first real user.
A useful AI assessment builds on five core questions: which decision do we want to change, is there data behind it, can our architecture serve it, can our people run it, and can we afford to keep it alive. Fail one and you fail all of them.
Which problems should AI solve
An AI strategy should always be a subordinate clause of the business strategy. A good candidate problem has most of these properties:
- The decision is already being made, frequently. Someone triages tickets or checks invoices today, so you have a baseline and a cost per decision.
- The judgement is pattern-based, not principled. “This claim looks like the ones that turned out fraudulent” is learnable. “Is this contract clause fair?” mostly isn’t.
- The outcome is recorded. You can tell, afterwards, whether the call was right.
- There is tolerance for being wrong. A model that’s right 92% of the time is excellent or unusable depending entirely on what happens on the other 8%.
Score each candidate on value, frequency, whether the data exists today, and error tolerance. Then pick one, small enough to finish, and apply one last test: if this worked perfectly, who does something differently on Monday morning? If nobody can answer, the problem isn’t ready, whatever the data looks like.
Assess potential approaches too. Reach for the cheapest technology that solves the problem. Don’t build a vector database if a plain TF-IDF ranking will do just as well. Often times “This isn’t really a machine learning (ML) problem.” is a legitimate answer too.
Which data sources can support your AI solution
Once you set the problem, follow it backwards to the data. Most organisations have three tiers of data based on visibility:
- Known and modelled. The warehouse and the tables people already trust. Usually the smallest tier.
- Known but unmanaged. Operational databases, CRM exports, logs, third-party APIs. Someone can point at it, but nothing tests it and no two systems agree on definitions.
- Hidden. Email threads, shared spreadsheets, PDF reports, free-text ticket notes. Invisible on any architecture diagram, and very often where the ground truth lives.
To find the hidden tier, follow the decision-maker. Ask the person who makes the call today what they look at first. In our experience, usually it is a spreadsheet, and that spreadsheet is the most valuable asset in the assessment: it encodes the expert judgement you are trying to reproduce.
When assessing your data sources, ask four questions of each:
- Does it record outcomes, or only inputs? This is the one that sinks projects. Plenty of companies have five years of flagged invoices and no record of which flags were correct. That isn’t a ML problem yet, it’s a labelling job.
- How far back does it go, relative to the seasonality of the business? Eighteen months of retail history covers one Christmas… Okay, maybe two if you are lucky.
- How fresh is it, relative to the decision? A daily batch cannot support a decision made in a checkout session.
- Are you allowed to use it? Personal data, consent scope and third-party contract restrictions are cheaper to check now than after go-live.
Is your architecture ready for AI
Fewer components are essential than most platform pitches suggest, sorted by what blocks a first production model:
| Component | Why it matters | Criticality |
|---|---|---|
| Central storage (warehouse, lakehouse or a well-run database) | One place where training and serving data agree. | Essential |
| Ingestion and orchestration in code | Scheduled, re-runnable, reviewable pipelines. | Essential |
| Version control and CI | If development is siloed from production, changes and fixes will slow you down (A LOT). | Essential |
| Data quality tests and alerting | Silent schema changes cause most quiet decay. | Essential |
| Compute for training and inference | Keep resources managed and right-sized. | Essential |
| Output monitoring (drift) | Catch bugs before they go live, not after. | High |
| Access control and lineage | Important for regulatory compliance. | High |
| Experiment tracking and model registry | Matters to help deploy the right models. | High |
Everything else is situational: a serving API only if consumption is live, a vector database only for retrieval over unstructured text, a feature store only at many models across several teams.
A crucial consideration is cost: not all suitable solutions are priced equally. We moved around 45 million rows of operational data off Snowflake warehouses onto Snowflake Postgres and cut that line item from about £5,000 a month to about £300 all-in, with 97% of operational queries under 5 ms. Same vendor, same account, correct engine with a very different price.
Is your staff ready for AI
Technology is rarely the binding constraint. People are. We list the most crucial roles for any data project to take-off:
| Role | What they do for an AI platform | Criticality |
|---|---|---|
| Project owner | Champions the project and unblocks cross-department data access. These endeavours die without one. | Critical |
| Domain expert | Knows what methods and approaches work best. Without them you build the wrong thing. | Critical |
| Data engineer | Pipelines, tests, schemas. Most of the work sits here, not in modelling. | Critical |
| End users | If they are not heard out properly, nobody will use the model. | Critical |
| Analytics engineer | Refines data sources into tested dashboards. Often the highest-leverage hire. | High |
| Platform / DevOps engineer | Deployment, monitoring, cost, access. Can be part-time. | High |
| Data scientist / ML engineer | Modelling, evaluation, retraining. Usually hired first, which is a costly mistake. | Medium |
That last row is an expensive but familiar one: a data scientist hired into an organisation without pipelines spends six months doing data engineering (badly), then leaves.
Can you maintain it
An AI system is an on-going project. The systems you build need maintenance and continuous investment to bring their return:
- Drift. The world changes, and accuracy decays quietly rather than failing loudly.
- Upstream changes. New information gets added to source systems and your pipeline needs to accommodate for these.
- Provider churn. Not often, but components can get deprecated over time. This is on the provider’s schedule, not yours, so keep your systems modular and up-to-date.
- Cost. As usage patterns change, so does cost. Different processing strategies will save you the most at different maturity levels.
- The human loop. Investing in AI also means investing in your staff who use and maintain these systems. Reviewing edge cases, correcting labels, feeding corrections back and reviewing decisions regularly.
Base decisions on numbers rather than enthusiasm: estimate cost, annual run cost, and the value of the decision it improves. The Snowflake migration above took about two engineer-weeks and paid back in six. Whilst not all projects might have an obvious payout in such short term, it is always good to keep in mind when and where the returns will show and how they fit in the broader business strategy.
How FloreData can help
FloreData is a data and AI consultancy built with a people-first mindset, as one client put it, we “felt like an extension of [their] own technical team.” A readiness assessments are where personability and honest conversations matter most, because the answer is often “not this, do that instead.”
- Problem selection. We run the shortlisting with your team: candidate decisions scored on value, frequency, data availability and error tolerance, and an explicit recommendation on which ones don’t need ML at all.
- Data discovery. Finding the dark tier, decoding awkward legacy formats, and telling you plainly whether the labels exist. We’ve done this on survey data, geospatial data and operational systems.
- Architecture and cost. End-to-end data platforms, pipelines and cloud architecture, right-sized to the workload. We’ve cut real bills by matching workloads to the correct engine rather than the default one.
- Modelling and AI delivery. Production ML, natural language processing and AI deployment, including retrieval systems and agents that answer questions against your own data.
- Making it usable. Business intelligence and dashboards so the output reaches the people who act on it.
- Handover. Documentation, knowledge transfer, and a team that can run what was built. Not a black box you have to re-hire us to touch.
See our case studies and services for the detail.
Not sure where your organisation sits? Start a conversation and we’ll work through it with you.
