Poor Quality of Data 

Many business leaders underestimate how dependent AI is on the quality of the data behind it. Salesforce’s 2026 State of Data and Analytics report found that 50% of data and analytics leaders wasted significant resources on training AI models when doing it with poor-quality, disconnected organisational data. 

Gartner predicts that through 2026, organisations will abandon 60% of AI projects that are not supported by AI-ready data.. To clarify, Gartner defines AI-ready data as data that is representative of the use case, including every pattern, error, outlier and unexpected case needed to train or run the model for that specific purpose, and dependent on metadata –  information about the data itself. Metadata allows the data to be aligned, qualified and governed. 

 The distinction matters because data that already meets a company’s ordinary quality standards does not automatically count as AI-ready. A spreadsheet can be accurate and still be unsuitable for an AI use case. What constitutes AI-ready data depends on the project, but in most cases, data must first be prepared, structured and governed for the intended use. 

McKinsey’s research points to the same problem from a different angle. Only 7% of companies have fully scaled AI across their organisations, and more than two-thirds of high-performing companies name data as the primary obstacle to doing so. EY’s AI Pulse Survey of 500 senior business leaders found much the same pattern from the other side of the table: 83% said their organisation’s AI adoption would be faster with stronger data infrastructure in place, and 67% said a lack of infrastructure is actively holding adoption back.  

Part of the reason lies in the company’s underlying data infrastructure. Traditional software typically works with predefined data structures and rules. AI systems can draw information from multiple sources, including documents, databases, applications, prompts and workflows, and combine that information dynamically to produce an output. If the infrastructure is not prepared for this, the reliability of those outputs becomes much harder to control, and companies may struggle to scale AI confidently across the organisation. 

This is one of the technical reasons messy and disconnected data can cause an AI project to fail.. A model learns from whatever pattern exists in the data it is given. If a customer, an order or a completed transaction is defined one way in an ERP system, a different way in a CRM, and a third way in a spreadsheet, the model does not know which definition is correct. It only has three conflicting versions of what should be a single value, and it learns from all three as if they were separate, valid inputs. The result is a system that returns an output that cannot be trusted. 

Companies therefore need a reliable foundation that connects, prepares and governs data across systems and files before attempting to scale AI. In many organisations, that foundation is a data platform. 

A Weak Use Case 

A second common cause has little to do with AI as a technology and everything to do with  why the company decided to build it in the first place. Clients sometimes approach Eunoia saying, “Everyone does AI, and we want it too. What can you do for us?”  might take that brief and start suggesting ideas straight away. But ideas alone do not necessarily create business impact. At Eunoia, we suggest starting by identifying where AI can create measurable value, using the framework behind our Decision Operating System. 

At Eunoia, consultations focus on the business result, not the technology choice alone. This is first step in our Decision Operating System..  To understand where a data or AI project can have the greatest impact, we map the decisions the business already relies on and identify where they can be improved. 

We also offer a separate AI and data opportunity assessment that helps a company identify the use case most likely to create business value. 

Before any technical work begins, it helps to know which decisions carry the most value, who makes them, and what they currently rely on when making them. A project built without this understanding risks being centred on a weak use case. Even a technically successful AI system will produce little return if it does not improve an important decision or solve a problem people actually need solved. 

Poor Project Delivery 

A project can be chosen correctly and build on properly prepared data and still fail at the point of delivery.  What happens next depends largely on the capability and approach of the vendor delivering it. AI expertise varies considerably between providers, and the criteria below set out what to check before signing a contract with an AI company. 

Much of what follows is drawn directly from client consultations, including conversations that have helped companies avoid spending budget on the wrong project before it starts. A vendor evaluation for AI work in Malta or Cyprus usually covers the same handful of areas: track record, technical expertise and credentials, sector experience, and approach to delivery.

Most vendors can offer polished marketing material about their AI services. Fewer can show proof of delivery, backed by a named client willing to be quoted. It is easy to talk about a project concept;  taking it into production and delivering against a client’s expectations is a much stronger test of expertise. 

Eunoia’s work with NetRefer is one example of that evidence. NetRefer, a global affiliate marketing platform, was running an ageing SQL Server setup that was becoming expensive to scale. Eunoia rebuilt the platform on Databricks using a Medallion Architecture, then added a GPT-driven natural language layer so NetRefer’s own clients could query their marketing data in plain English instead of waiting on a report. That combination made NetRefer the first affiliate marketing platform to offer NLP-driven data analysis at scale, while also improving the cost efficiency of its underlying infrastructure. 

Not every outcome comes with a clean percentage attached, and that is fine. But vague promises with no track record are the real warning sign. 

Major technology providers, including Microsoft, Databricks, Snowflake and AWS, have partner programmes that assess and recognise qualified providers. These systems give customers a way to check a vendor’s claims independently of how the vendor markets itself. Credentials are therefore an important point to check when selecting an AI supplier, but they should not be considered in isolation. 

AI knowledge can broadly be divided into two areas. One is knowledge of how to use the models built by a specific technology provider: prompting, model behaviour, API usage, getting an agent to  interact correctly with tools on a particular platform. This can be learned via manuals and technical documentation published by the technology provider itself. The other is applied AI and machine learning engineering: the knowledge needed to build, train, deploy and maintain models in production, independent of any one provider.  This deeper engineering capability is particularly important when evaluating whether a vendor can move beyond a demonstration and deliver a production system. 

The knowledge behind applied AI and machine learning engineering, including probability, statistics, and understanding how models learn, is often grounded in formal academic study in machine learning, computer science, statistics or related disciplines. The AI team at Eunoia holds undergraduate degrees in machine learning, with postgraduate MSc-level study within the team as well.  This provides the theoretical foundation behind the applied work. 

Deploying models into production and organising experiments into reproducible pipelines is the next stage. That knowledge is usually gained through training focused on the specific platform in use,  and relevant certifications provide an additional external signal of that expertise. Without platform knowledge, the AI layer built on top may not run efficiently in production. 

Eunoia deploys AI on Microsoft Azure, Fabric and Databricks and holds an active Solutions Partner for Data & AI (Azure) designation and the Analytics on Microsoft Azure Specialisation, the highest level in Microsoft’s AI Cloud Partner Programme and a credential only a small number of firms worldwide hold, with Eunoia among the first in Malta to achieve it. 

AI-specific certifications from companies like OpenAI or Anthropic are useful once the underlying engineering capability is already established, since they add specific skill in building agents and chatbots rather than replacing that underlying knowledge. 

To check whether a vendor can actually deliver AI solutions, look at the following: 

1. Can they prove expertise through case studies? 
2. Does the team hold an academic background in the field? 
3. Do they have platform knowledge for the applied AI and machine learning environment where the solution will be deployed? 
4. Do they have knowledge of the specific AI model or models being considered for the solution? 

AI experience is sector-specific and it does not always transfer cleanly from one industry to another. A team that has spent years tuning demand forecasting models for a retailer has learned how promotions and seasonality distort a training set. An iGaming specialist who has built player retention and fraud detection models has learned a different lesson: how to keep a model that predicts churn structurally separate from anything touching responsible-gambling obligations. Every industry brings its own data patterns, business rules and constraints, and many of these are learned through direct practical experience. 

A useful test when evaluating sector experience is to ask for an example of a project in your specific vertical and the business challenge it solved. 

Technical depth is easy to claim, but hard to fake if you know what to look for. The first thing to watch is how a vendor proposes to test the idea before committing to a full build. A vendor with real experience proposes running that test against your actual, frequently messy data, and treats it as a way to find the difficult examples early.  A vendor without much depth may instead demonstrate a neat-looking interface built quickly on clean sample data and treat that as proof that the complete system will work in production. 

At the same stage, check who is actually named on the team put forward to deliver the project. A general developer  integrating a ready-made AI service is not the same as a specialist who designs and maintains the data and AI architecture the system depends on. Find out who is doing that work and whether those specialists remain involved after the initial build. 

When the conversation moves into how the system would actually be built, data handling is the next thing to press on. Based on Eunoia’s years of experience across verticals, real data is often messy, incomplete, or arriving continuously rather than staying still in a clean file. A vendor with genuine technical depth should be able to explain how that data will be cleaned, structured and kept flowing reliably, rather than assuming it will always arrive in the form the model expects.  

If the project involves the AI system retrieving information from your own documents or records, ask how it decides what to retrieve and how it avoids missing the right piece of information or using incorrect one. A direct question worth putting any vendor at this stage: how would your data be kept separate from other clients’ data, and would any of it be used to improve the vendor’s own models, not only yours? 

The same technical conversation should cover how a vendor talks about the system’s weaknesses. Every AI system gets some answers wrong, and a vendor who has built one in production should be able explain when errors are most likely to occur, how performance is measured, and what safeguards prevent an incorrect output from reaching a customer or report unchecked.. A vendor who promises near-perfect accuracy with no person ever needing to check the output should be challenged on how that claim is measured and maintained. 

Before signing, ask what happens once the system goes live. Behaviour can change gradually over time as real data moves away from the data on which the system was originally built and tested on, and a credible vendor should be able to describe how they would notice that early, not only how they built the first version.  If a vendor cannot answer these questions clearly, it is worth establishing exactly who is doing the technical work and how the system will be supported in production. 

 A handful of direct questions, put to a vendor before a contract is signed, can surface many of the problems that might otherwise appear months into a project. 

Checklist: Questions to Ask Before You Sign 

The questions raised throughout this guide gathered into one list to take into a vendor conversation. 

Track Record and Credentials 

1. Can they prove expertise through case studies? 
2. Does the team hold an academic background in the field? 
3. Do they have platform knowledge for the applied AI and machine learning environment the solution will run on? 
4. Do they have knowledge of the specific AI model or models being considered for the solution? 
5. Can they show a project in your specific vertical, and what business challenge it solved? 

Technical Depth and Data Handling 

1. How do they propose to test the idea before a full build, and will they test it against your actual data? 
2. Who is actually on the delivery team, and do they stay on the project once it is running? 
3. How do they clean, structure and manage data that is messy, incomplete or arriving continuously? 
4. If the system retrieves your documents or records, how does it avoid missing or retrieving the wrong information? 
5. How is your data kept separate from other clients’ data, and is any of it used to improve the vendor’s own models? 
6. How often does the system get an answer wrong, and what stops a wrong answer from reaching a customer or a report unchecked? 
7. How would they notice a drop in performance after go-live, rather than only monitoring whether the system is technically running? 

Delivery and Commitment 

1. Has the vendor ever told a prospective client to wait, and why? 
2. What happens if you do not have a formulated AI plan yet? 
3. Do they assess your team’s technical literacy before scoping out the work? 
4. What does “do” look like, and who signs off on it? 

Eunoia is a data and AI consultancy operating out of Malta and Cyprus, working across iGaming, financial services, insurance, retail and manufacturing. The sections below set out how projects are chosen and delivered, along with the credentials and case studies worth checking, using the same criteria, this guide recommends applying to any AI vendor.

A technology recommendation made before anyone has looked at the decisions the business needs to improve is usually the wrong one, however well-specified it looks on paper. 

Eunoia’s approach starts with mapping the decisions that matter most to the business and it’s performance. Which decisions get made weekly or monthly that carry the biggest financial weight? Who makes them, and what do they currently rely on to do so? Only then does the technology recommendation follow. 

From there, the usual path is a pilot on a single, contained use case. This helps test the idea before committing to a full build, reducing the risk of spending heavily on a solution before its business value has been demonstrated. Results from that pilot inform a phased delivery plan, prioritised around whichever decisions carry the most business impact. 

On technical depth, Eunoia treats a proof of concept as a test against a client’s own data, since this approach helps surface data quality issues before the full solution is developed. 

Eunoia hires specialists with academic backgrounds in data science, machine learning, and computer science. Eunoia was among the first consultancies in Malta and Cyprus to achieve the Analytics on Microsoft Azure Specialisation, Microsoft’s highest-level credential for data and analytics partners. That comes alongside established delivery work on Azure, Databricks and AWS, and a Databricks partnership.

Most of these are data-foundation projects, includingdata platform developments, modernization and migration, because credible AI capability usually depends on this foundation being in place first. Several also include an AI layer. Between them, the projects below span retail, iGaming, insurance, financial services and manufacturing. 

1. NetRefer, a global affiliate marketing platform, moved from SQL Server to a Databricks-based Medallion architecture and added GPT-driven natural language queries for its own clients, becoming the first affiliate marketing platform to offer that at scale. 
2. Hudson Holdings Group centralised ERP and footfall data from a Dynamics 365 estate over a six-month migration, moving the business onto self-service reporting. 
3. RightShip, a maritime risk management organisation, moved from traditional SQL-based reporting to a governed lakehouse built on Databricks Unity Catalog. 
4. Gordian Holdings, a regulated investor in Cyprus, consolidated scattered servicing-system data into a central warehouse, improving access to consistent information across teams and automating previously manual regulatory reporting. 
5. Toly, a global packaging manufacturer, unified reporting across Dynamics CRM, Business Central and a legacy warehouse into a single Azure data lakehouse, moving from weekly to daily reporting. 
6. Atlas Insurance migrated on-premises data cubes to a cloud-based Power BI solution, reducing processing time by roughly 83 percent. 

Choosing the best AI company in Malta and Cyprus should come down to verification. Check whether the vendor’s credentials are current and specific. Ask how they decide what to build first, and whether that decision starts with business impact or with whatever technology happens to be on offer. Look for delivered evidence and prioritise suppliers that define the business problem before recommending the technology. Ask sector-specific questions, not generic ones, and ask what happens when a project does not go to plan. A vendor confident in how it works will answer all this directly.