Enterprise AI programmes are usually data programmes first
Enterprise AI programmes rarely stall because a team cannot select a model. They stall because the underlying data cannot be found, trusted, governed, or used safely in production.
A polished prototype can query a small, manually prepared dataset and impress a leadership team in days. Moving that capability into a real business process is different. The model may need data from operational systems, documents, customer interactions, product records, contracts, telemetry, and financial platforms. Each source has an owner, a history, access rules, changing definitions, and varying quality. The AI system then introduces further questions: which data informed an answer, who was permitted to see it, what happens when the source changes, and how will the organisation detect a bad result?
AI readiness is therefore a data and operating-model question before it is a model question. The organisations that make steady progress build a dependable path from source data to an AI-supported decision or workflow. They establish accountability for the data, reduce ambiguity in high-value domains, and make controls usable by delivery teams.
That work supports generative AI, machine learning, analytics, process automation, and future initiatives that have not yet been defined. It also improves the reliability of existing reporting and operational decision-making.
Start with decisions and workflows, not a data lake
"Prepare our data for AI" is too broad to guide investment. It can result in a long programme to centralise everything, followed by a search for valuable use cases. Most enterprises already have more data than they can effectively govern. Copying it into a new platform does not make it reliable or useful.
A better starting point is a decision, workflow, or customer interaction where better use of data would produce a measurable outcome. Examples include helping service agents find the current answer to a technical or policy question; detecting exceptions in an order, claims, or maintenance process; forecasting demand with a transparent set of drivers; matching product, supplier, and pricing records across systems; and reducing the manual effort needed to extract and validate information from documents.
Each use case should identify the decision to be improved, the people affected, the acceptable level of error, the systems of record, and the action a user can take after receiving an AI output. This narrows the data scope. It also exposes where human review is required and where a faulty answer would be unacceptable.
For a retrieval-based assistant, the priority may be versioned policies, technical manuals, ownership metadata, access controls, and a process for retiring superseded material. For a forecasting model, the priority may be consistent product identifiers, historical demand, promotions, stock positions, and a clear definition of the target measure. These are different engineering problems. Treating them as one generic AI data-platform programme creates unnecessary cost and delay.
This same outcome-led thinking applies to cloud work. A cloud consultancy should frame architecture and modernisation around governed foundations and practical operating needs, rather than treating a platform choice as the strategy.
Know which data can be trusted, and why
Data quality is often described as a technical hygiene issue. For AI, it is a product and risk issue. A system cannot reliably answer a question about a customer, contract, asset, or transaction if the organisation cannot establish which record is authoritative.
Quality should be defined in the context of the use case. Common dimensions include completeness, validity, accuracy, timeliness, consistency, uniqueness, and representativeness. The last dimension deserves particular attention. A dataset can pass technical checks while failing the real task. A service assistant trained on well-written standard procedures may still perform badly on the legacy products, exceptional cases, and regional policies that generate the most customer contact. A demand model may look accurate across the portfolio while producing poor results for low-volume or newly launched products.
The answer is not to wait for perfect data. Perfect data is rarely available, and waiting can hide the business choices that determine what "good enough" means. Instead, establish explicit quality thresholds for a defined use case, measure them continuously, and design the workflow around known gaps. If a document is out of date, the assistant should identify that condition rather than present it as a current answer. If a forecast lacks enough history, the model should say so or fall back to a simpler method.
Data contracts can help. A contract sets expectations between the team producing a dataset and the team using it: schema, definitions, freshness, permitted use, ownership, service levels, and how breaking changes are communicated. This makes data dependencies visible and turns quality from a periodic clean-up project into an operational responsibility.
Make data discoverable with business context
A central repository without useful metadata becomes a larger place to lose information. Engineers may know where tables and files live, but AI initiatives also need business users, analysts, risk teams, and product owners to understand what the data represents and whether it is appropriate to use.
A useful catalogue records more than a name and technical schema. It should answer practical questions: what business concept the dataset represents; which system or process created it; who owns the definition and supports the pipeline; whether it is a system of record, a derived dataset, or a temporary extract; what transformations produced it; how often it updates; and what classifications, retention rules, and access restrictions apply.
Lineage connects those answers. It lets a delivery team trace a model feature, dashboard figure, or generated answer back through transformations to the original source. When the source definition changes, lineage helps identify affected products and controls. When an AI output is challenged, it provides evidence for investigation.
AWS's Data Analytics Lens treats governance, access control, and data and metadata changes as core analytics design concerns, alongside reliability, performance, and cost management. It is a useful architecture review framework because it connects those concerns to the way workloads are designed and run.
A catalogue does not have to become a large documentation programme before it creates value. Start with the data products needed for the first few use cases. Require a concise business description, named owners, classification, quality indicators, and lineage through the main transformations. Build the habit into delivery pipelines so that metadata is maintained as systems evolve.
Resolve identity and master data problems
AI amplifies ambiguities that people have learned to work around. A human sales team may know that "ACME Ltd", "Acme UK", and a legacy account code all refer to the same customer. An automated system will not infer that safely without a deliberate identity strategy. The same issue affects products, suppliers, locations, employees, assets, and contracts.
Master data management is not a prerequisite for every AI use case, but it becomes important wherever the system must join information across domains or take action. An assistant that summarises one document collection can work with relatively limited entity resolution. A system that recommends a next-best action using customer history, product availability, pricing, and support activity cannot.
The organisation should establish canonical identifiers for the entities that matter to the use case, matching and survivorship rules for duplicates and conflicting attributes, a named authority for each core attribute, a process for correcting identity errors at source, and a way to distribute the agreed identity across consuming systems.
This is often difficult because it exposes competing business definitions. That difficulty is useful information. If finance, sales, and operations use different definitions of a customer or an active order, a model cannot solve the disagreement. The organisation has to decide which definition applies to which decision.
Govern access at the level AI requires
AI can make data easier to search, summarise, and combine. It can therefore make inappropriate access easier too.
Traditional reporting controls may be insufficient for an assistant that retrieves content across document stores or an agent that can call operational systems. Role-based access remains useful, but it may need to be supplemented by attribute-based controls such as region, business unit, project, clearance, customer relationship, or document classification. The AI application should enforce the same entitlements as the systems where the data originated.
Before production, teams should decide whether the application can retrieve only documents the requesting user may read; how personal, commercially sensitive, and regulated data is classified; whether prompts, retrieved content, and outputs are retained; which actions need human approval; and how the organisation will audit the data, prompt, model version, tools, and rules involved in a consequential outcome.
Security design should include the retrieval path, model integration, tool access, logging, evaluation datasets, and administration interfaces. It should also include operational processes. A well-designed policy that no team can interpret during delivery will either be bypassed or slow every initiative to a halt.
For cloud environments, the relevant controls belong in the platform: identity, encryption, network boundaries, secrets management, logging, policy enforcement, and repeatable deployment. Cloud engineering services should provide this durable capability across architecture, platform engineering, and long-term system evolution.
Build pipelines that are observable and change-aware
AI depends on data that continues to arrive, transform, and remain interpretable after launch. A model can degrade because upstream data changes, because a source system is replaced, or because a document collection accumulates outdated material. These are operational issues, and they need operational controls.
A production data pipeline should make it possible to see whether expected data arrived; whether volume, schema, freshness, or distribution changed; which quality rules failed; which downstream datasets and AI products are affected; who has been alerted; and whether the issue requires a rollback, a data correction, or a model evaluation.
Treat transformations as software. Keep them in version control, test important assumptions, review changes, and deploy them through controlled environments. Record the version of the dataset or corpus used in model training and evaluation. For retrieval systems, preserve document versioning, chunking logic, embeddings, access filters, and relevance tests. For predictive systems, record feature definitions, training windows, labels, evaluation measures, and approval decisions.
This is where data engineering, platform engineering, and MLOps meet. A successful AI team needs a path to deploy models or AI applications, but it also needs a path to maintain the data those systems depend on. Users should be able to flag an incorrect answer, missing document, poor recommendation, or data discrepancy in the context of their work. Those signals should route to the team that can correct the source, pipeline, prompt, retrieval configuration, or model.
Design for cost and resilience early
Data platforms can become expensive long before AI workloads reach meaningful scale. Duplicate storage, uncontrolled extracts, always-on compute, frequent reprocessing, and poorly governed high-cardinality queries all add cost. Generative AI adds token usage, retrieval processing, evaluations, and potentially agent tool calls.
Cost control should not be reduced to monthly billing reviews. Teams need a way to attribute spend to data products, workloads, and business outcomes. They should understand the cost of retaining raw data, transforming it, serving it, and using it in an AI workflow. That makes it possible to decide where real-time processing is justified, where batch is sufficient, and which data should be retained at high-cost tiers.
Resilience has a similar business dimension. An AI assistant supporting internal research might tolerate delayed updates. A system assisting operational decisions may require defined recovery targets, source fallbacks, clear degradation behaviour, and a manual route when the service is unavailable. The acceptable design depends on the harm caused by delay or incorrect guidance.
The right first workload is not always the most visible one. The workload prioritisation guide makes the related point for migration: dependency clusters, security, governance, and the ability to reduce uncertainty should influence sequencing. The same principle applies to AI. Choose an early use case that proves the data, control, and operating patterns that later teams can reuse.
A practical 90-day path to readiness
Days 1-30: select and assess
Choose one or two bounded use cases with a measurable outcome and an engaged business owner. Map the source systems, decisions, data classifications, current quality issues, owners, and failure consequences. Identify the minimum viable dataset or document collection. Agree evaluation criteria before building.
Days 31-60: establish the controlled data path
Create repeatable ingestion and transformation steps. Implement access controls, classification, audit logging, quality checks, and catalogue entries for the selected data products. Resolve the identity and definition issues that affect the use case. Build representative evaluation data, including difficult cases and known exceptions.
Days 61-90: test the complete workflow
Run the AI application with real users in a controlled setting. Measure data quality, retrieval relevance or model performance, user correction rates, latency, cost, and business impact. Test access boundaries and failure scenarios. Decide what must be improved before production and which components can become standards for the next use case.
This approach gives leaders a clearer investment decision. Instead of approving a broad promise to become AI-ready, they can see the actual readiness gaps, the cost of addressing them, and the business result produced by a governed workflow.
Enterprise data is ready for AI when teams can answer simple but demanding questions: what is this data, where did it come from, who owns it, who may use it, how current is it, what changed, and what should happen when it is wrong? Answer those questions for the data that powers valuable decisions, then make the answers part of everyday delivery. That is the foundation on which useful AI can be built and operated.
