Many people want to get closer to AI in practice, but quickly discover that it's not just about models and use cases. It's also about whether your database and data platform can actually support the data flows, response times and workloads that AI requires. For some use cases, it's the ability to deliver updated data quickly. For others, it's about being able to semantically search large amounts of data, connect information across sources or handle large volumes of events over time. If data is scattered, performance fluctuates, and access, quality and responsibility are not clearly defined, it becomes difficult to take AI from demo to operation. Here's a look at the issues that typically get in the way and what you should prioritize first.
It's normal for the business to demand AI solutions. The challenge is that many setups are not built for the data, accessibility and scalability requirements of modern AI use cases. This is especially true when AI is not only used for experimentation, but also for search, decision support, automation or other processes closer to operations.
Traditional databases and legacy systems have often evolved over many years. Data ends up in silos, definitions slip, and integrations become specialized solutions. As a result, AI teams spend a disproportionate amount of time finding, understanding and preparing data before they can build anything of value.
This becomes particularly apparent when AI use cases depend on data that needs to be available in near real-time or when a model or application needs to pull context from multiple sources along the way. If your data only becomes "fresh" once a day, or if accessing it requires special people or workarounds, it will be difficult to take AI use cases from experimentation to operation.
If you try to fix everything at once, you'll end up with a bigger platform but the same problems. In practice, it's more effective to prioritize three areas.
AI doesn't require "all data". It requires the right data, in a quality you can vouch for and in a format that can be used again and again. This applies to both classic analytics and AI use cases, where output quickly becomes unreliable if data is incomplete, too old or defined differently across systems.
Typical obstacles in practice:
Data exists in multiple systems with different definitions
Quality is discovered late, often only when output looks wrong
Access depends on individuals and informal agreements
Metadata is missing, so it's unclear where data comes from and what it means
To move forward, you need to be able to answer three questions without long threads in Teams: What is the real source? Who owns the data? And what is "good enough" quality for the purpose?
Scalability is important, but it's not the goal in itself. In an AI context, it's about whether the platform can deliver data fast and stable enough for training, retrieval and operational use. That's not to say that everything has to be real time, but you need to know which use cases require low latency, frequent updates or access to large amounts of data in a short time.
In practice, it's often about:
Low and stable response time on the data the models use
High capacity when processing large amounts of data
A setup that can handle peak loads without becoming unpredictable
Traditional databases are still key here, and Oracle and Microsoft SQL, for example, remain strong and versatile foundations. But that is not always enough. If you work with retrieval-augmented generation, semantic search, or similar use cases, vector search may be relevant because you need to find content based on meaning rather than exact keywords.
If you are working with relationships, dependencies or networks across entities, other data models may be more suitable. And if you're working with large volumes of metrics or events over time, storage and query requirements are different. The point is not to chase new technology, but to assess whether your current database choice actually fits the AI use cases you want to support.
If governance comes second, AI work quickly ends up in a gray area: who can use what data? How do you document it? Who takes responsibility when something goes wrong?
It's all about making it easy to do the right thing in everyday life.
This typically means:
Clear access control and audit trail
Clear ownership of datasets and pipelines
Standards for logging, monitoring and handling changes
Budget and cost guardrails so spending doesn't run unattended
The closer AI gets to operations, the more important it becomes that data flows, access and responsibility are not based on special exceptions. This is especially true if AI output is used in processes that directly affect customers, operations or decisions.
Cloud provides flexibility and lets you scale as needed.
But cloud doesn't make you AI-ready by itself. If data pipelines are fragile, ETL and ingestion don't mesh, or the platform can't deliver data fast enough for the use cases you want to support, you often just get more complexity in a new environment. Azure Data Factory or similar tools can be useful for getting data into workflows, but that doesn't change the need to manage data quality, transformation logic and ownership along the way.
Even the best model will be limited by data. It's therefore more realistic to think of data quality as an ongoing discipline, not as a project with an end date.
You can make this more manageable by introducing:
Validation at load so errors are caught early
Continuous monitoring so quality isn't only discovered in output
Basic lineage so you can explain where data comes from and what has changed
This also applies to data flows into AI workflows. Data ingestion, pipelines and transformation logic must be robust enough that you can trust the output. Otherwise, AI quickly becomes another layer on top of an already hard-to-manage setup. If you only discover errors when the model answers incorrectly or a recommendation looks strange, you're already too late.
To make the stakes more precise, you can start here:
What is the main AI use case and does it require batch, near real-time or continuous access to data?
Can your current setup deliver the data fast and stable enough for that use case?
Where is the database choice or architecture a limitation today, for example in retrieval, semantic search or large amounts of event data?
Do you control data quality, access and responsibility before data is used in AI workflows?
What is the first area that should be modernized if AI is to move closer to operations?
If these are unclear, this is often the best place to start.
At Cegal, we're ready to help you do just that. As a one-stop shop for all database types and with experienced database experts, we start with your existing setup and help clarify where you should migrate, modernize or build, depending on which AI use cases you want to support. The goal is not to rebuild everything, but to ensure that your data and platform are strong enough where AI will actually create value.