The pilot worked on a spreadsheet
What we do. We connect to the real systems before anything is promised. The readiness verdict names every integration point and states plainly what is reachable, what is not, and what that changes.
AISTORSServicesData and retrieval for AI
Service 03Data your AI can actually use.
Answers from your own records.
For teams whose first AI project stalled on the data rather than the model. The model can reason. It cannot reach the record. Your answers sit across systems that disagree with each other and nobody has decided which one wins. We build a reliable path to the fields that matter, ground retrieval in your own documents, and score it against questions your team wrote.
Book a 30-minute call
Where we start
We read your actual records before promising anything. First AI projects usually fail here rather than on the model, and it is far cheaper to find out at this stage.
01
Who this is for
If the left column is not you, say so on the call and we will tell you what would help instead.
This is for you if
- Your first AI project stalled on data access. The pilot worked against a spreadsheet and then met the real systems, and stopped.
- The answers exist but are scattered. Across a CRM, an ERP, a document store and somebody's drive, usually in more than one version.
- People ask the same questions repeatedly. Enough repetition that retrieval over your own records repays the work of building it.
- You can name a source of truth. Or you are willing to decide one, field by field, and have that choice written down and owned.
- Somebody will write the test questions. A person who can supply real questions with known right answers, so quality is measured rather than asserted.
This is not for you yet if
- You want a data warehouse programme. Most processes need a reliable path to a handful of fields, not a platform programme. We would rather scope the small version.
- Nobody will arbitrate the contradictions. Retrieval over contradictory records just returns contradictions faster. Somebody on your side has to choose.
- The knowledge is not written down anywhere. If it only exists in people's heads, retrieval has nothing to ground itself on and will invent the rest.
- You expect fine-tuning to solve it. It usually will not, and it is the expensive way to find out. We build the retrieval baseline first and show you the number to beat.
- The records genuinely cannot be read. Residency rules we design around. Systems with no reachable interface at all are a different problem.
02
What we fix, and how
Four things stop data projects. Each has a specific answer, and the first one is deliberately cheap.
Your systems contradict each other
What we do. We name the contradictions, choose a source of truth per field with you, and record the choice with an owner against it. That decision record is yours and outlives the engagement.
Nobody can say whether the answers are any good
What we do. Retrieval is scored against a fixed, versioned set of real questions labelled by your team, before it ships and again on every change. Without that set, quality is an impression.
The data cannot leave your estate
What we do. Then it does not. Open-weight models and open retrieval components run entirely inside your tenancy. We give you the cost and latency trade-off in numbers rather than in principle.
03
What you get
Retrieval over contradictory data returns contradictions faster, so the contradictions are named first.
What we build
- Enterprise search across what you already own. One query surface over the document stores, wikis, ticket histories and shared drives that currently require knowing where to look.
- Retrieval grounded in your own documents. Answers that cite the source passage, so a person can check the answer rather than trust it.
- Data pipelines and warehousing. Ingestion, transformation and scheduling, built with your platform's native tooling and documented for handover.
- Real-time paths where the workload needs one. Streaming or change-data-capture where batch genuinely will not do, and batch where it will, because streaming everything is a cost decision disguised as an architecture decision.
- Record reconciliation across systems. Where the CRM, the finance system and the operational tool disagree about the same customer, that disagreement is named and a source of truth is chosen.
- Lineage and ownership documentation. Which system is authoritative for which field, and who owns it. Two thirds of IT leaders report uncertainty here.
- Model fine-tuning on your data. Only where retrieval has been tried first and measurably falls short, because fine-tuning is the more expensive answer to most questions.
- Private and self-hosted models. Open-weight models run inside your tenancy where data cannot leave the estate.
- A data readiness verdict, in writing. Including the case for fixing the data before building anything on top of it.
What this is not
- Not a data warehouse rebuild. We scope the smallest data work that unblocks the specific process you want to improve, not a platform programme.
- Not a licence for a search product. Built on your platform's own retrieval services or open components. Nothing of ours has to keep running.
- Not a promise that retrieval fixes bad records. Retrieval over contradictory data returns contradictions faster. Where the records are the problem we will say so.
- Not fine-tuning by default. It is the last option, not the first, and we will show you the retrieval baseline it has to beat.
- Not a migration off your existing stack. If your warehouse works, it stays.
04
How it runs
The source of truth is a decision with a named owner, not a diagram.
01
Data readiness assessment
Which systems hold the record, which have usable interfaces, where records disagree, and what has to be fixed before anything is built. Gartner names absent AI-ready data as the reason 60 percent of AI projects get abandoned, so this is settled first.
02
Source of truth decided, in writing
For every field the process depends on, one system is authoritative and one person owns it. Disagreements between systems are documented rather than averaged away.
03
Pipelines built on your platform
Ingestion, transformation and scheduling using your platform's native services, with tests and a documented failure path. Batch where batch is honest, streaming only where the workload requires it.
04
Retrieval, then evaluation
Retrieval built and scored against a fixed set of real questions your team labelled, so retrieval quality is a number rather than an impression.
05
Handover with lineage documented
Field-level lineage, ownership, refresh schedule and runbooks. The point at which your team can extend this without us.
05
Platform native
Built on your platform's own retrieval and pipeline services. Nothing of ours has to keep running.
Azure
Azure AI Search, Fabric and OneLake, Data Factory, Synapse, Purview for lineage and classification, Azure OpenAI embeddings.
AWS
OpenSearch and Kendra, Glue and Lake Formation, Redshift, DataZone for governance, Bedrock Knowledge Bases.
Google Cloud
Vertex AI Search, BigQuery, Dataform and Dataflow, Dataplex for lineage and quality, pgvector on Cloud SQL.
DigitalOcean
Managed Postgres with pgvector, Spaces for object storage, managed Kafka where streaming is justified, open-source retrieval components on DOKS.
We hold certifications on four platforms and no reseller relationship on any, so there is no commission behind a recommendation to move.
06
The evidence, if you want it
You do not need these numbers to recognise the problem. They are here because somebody in your approval chain will ask.
60%
of AI projects will be abandoned through 2026 where they are not supported by AI-ready data. Gartner also reported that 63 percent of surveyed data-management leaders either lack the data-management practices AI requires or are unsure whether they have them.
Source: Gartner, 26 February 2025.
72%
of IT leaders cite insufficient infrastructure for real-time data processing as a barrier, up from 61 percent the year before. 66 percent cite uncertainty around data lineage, timeliness and quality, and 65 percent cite fragmented ownership of data.
Source: Confluent, 2026 Data Streaming Report.
44%
name data quality as the number one implementation barrier, in pilots and at scale.
Source: UST, Enterprise AI at Scale, 2026; global survey of 510 senior leaders.
The same barrier appears at three different heights depending on who is counted. UST puts data quality at 44 percent of senior leaders, PYMNTS Intelligence at 63 percent of executives, and the RSM US Middle Market AI Survey at 34 percent of middle-market respondents. The definitional differences matter more than the spread, which is why a Diagnostic measures your own data rather than quoting an average.
07
What the barrier actually is
Insufficient real-time infrastructure is the barrier named most often, and it rose year on year.
Artifact / What IT leaders say is blocking AI at scale
Share citing each barrier
08
Questions we are actually asked
Do we need a data warehouse before we can use AI?
Usually not, and this is the most common reason a first AI project gets over-scoped. Most processes need a reliable path to a handful of fields, not a platform programme. The assessment tells you which of the two you are actually looking at, and we would rather scope the small version.
Our records contradict each other across systems. Is that a blocker?
It is the work, not a blocker. Every organisation past a certain size has this. What matters is that the contradictions are named, a source of truth is chosen for each field, and the choice is written down and owned. Retrieval over contradictory data just returns contradictions faster.
Should we fine-tune a model on our data?
Probably not first. Retrieval grounded in your documents answers most questions more cheaply, is easier to update when the documents change, and can cite its source. We will build the retrieval baseline and show you the number fine-tuning would have to beat before spending your money on it.
Can this work without our data leaving our environment?
Yes. Open-weight models and open retrieval components run entirely inside your tenancy. It is slower to build and usually costlier to run than a managed API, and we will give you that trade-off in numbers rather than in principle.
How do you know the retrieval is any good?
It is scored against a fixed, versioned set of real questions labelled by your team, before it ships and again on every change. Without that set, retrieval quality is an impression rather than a measurement.
Do we need real-time data?
Less often than vendors suggest. Streaming everything is a cost decision disguised as an architecture decision. We build streaming where the workload genuinely requires it and batch where batch is honest, and the assessment says which is which for your process.
09
Next step
Bring the process, and we will find the data.
Thirty minutes, no obligation. Describe a process and the systems it touches. We will tell you whether the data is reachable, and what has to be true before anything is built on it.
- Assessment duration
- Three to five days, credited against the build.
- Investment
- Scoped on the introductory call.
- If you stop after the assessment
- You keep the data readiness verdict in writing, including the case for fixing the data before building anything on top of it.
Book a 30-minute call
Or write to [email protected].
10
Related work
Service 01
AI agents and assistants
Inside the system, not beside it. The work that has to reach the record this page makes reachable.
Service 05Cloud architecture and migration
The landing zone, pipelines and platform engineering underneath the data work. Built once, documented, handed over.
DisclosureAI capability and data handling
Which model providers, on what terms, and where an open-weight model runs inside your tenancy instead.