The Problem That Repeats in Every Tender Document
AI proposals arrive at evaluation committees written in confident language, full of terms like generative models, deep learning, and intelligent automation, yet this language rarely reveals the real difference between a vendor with a mature delivery methodology and one repackaging an off-the-shelf tool with an Arabic interface. The problem is not a lack of information, but proposals that look similar on the surface while differing fundamentally at points that only surface during implementation.
In the Saudi government and enterprise sector, technical evaluation criteria are often built around general elements like company experience, team size, and price, criteria that are legitimate but insufficient for evaluating an AI solution. A low price may reflect a scope of work trimmed away from real needs, and a promise of major outcomes may conceal the absence of a clear plan for data quality or for testing the model in the actual operating environment before launch.
The recurring outcome in AI projects that stall after contracting is rarely an outright technical failure. It is usually a gap between what the proposal promised and what can actually be delivered within the entity's real data, infrastructure, and operational capacity. This gap is discovered after the contract is signed, and preventing exactly that is what a sound evaluation framework is meant to do.
The Cost of a Wrong Decision: Why Lowest Price Is Not Enough
When an AI proposal is selected on lowest price alone, without deep scrutiny of implementation methodology, the real cost does not appear in the project invoice. It appears in wasted time during delivery, in repeated scope adjustments, and in the credibility the government entity or enterprise loses with internal users when the solution does not work as promised. This does not mean price is unimportant, it means price alone tells us nothing about decision quality.
Conversely, the large promises found in proposals, such as radically improving operational efficiency or fully automating complex processes, require calm, critical scrutiny rather than automatic rejection or blind acceptance. The essential question a technical committee should ask is not whether the promise is theoretically possible, but whether the proposal explains how that promise will be achieved within the entity's actual data, regulatory constraints, and internal team's capacity to adopt and sustain the solution.
Delaying the effort to build precise evaluation criteria carries a cumulative cost. Every tender evaluated with superficial criteria creates a precedent used in future tenders, gradually weakening the entity's ability to distinguish a serious vendor from one selling promises. This is not a warning of catastrophic outcomes, it is a realistic description of how decision quality erodes over time when evaluation criteria remain generic and disconnected from the nature of AI as a data-and-context-dependent solution.
Decision Criteria: What the Technical Committee Should Actually Ask
The first and most important criterion is clarity on the data methodology: does the proposal explain how the vendor will work with the entity's actual data in terms of quality, completeness, and sensitivity, and what is the plan if the data is not ready as assumed? Strong proposals address this openly and include an initial data assessment step before committing to outcomes, while weak proposals simply assume data readiness as a given.
The second criterion is validation and testing: how will the model or solution be tested before being fully relied upon in operations? Is there a defined pilot phase with clear success metrics, or does the transition from signing to full launch happen without an independent verification checkpoint? The absence of this phase in a proposal should be treated as an early warning sign, regardless of how compelling the accompanying marketing language is.
The third criterion concerns governance and continuity after delivery: who owns the model and the derived data, what is the maintenance and update plan, and does the solution depend permanently on the vendor's team or does it build genuine internal capability within the entity? A fourth criterion, less technical and more organizational, is how well the proposal aligns with the entity's nature as a government body or organization subject to specific internal requirements for security, privacy, and escalation, because an excellent technical solution in one context is not necessarily suitable for this entity's context.
What a Strong Proposal Must Actually Contain
A serious AI proposal begins with a clear diagnosis of the need before the solution, meaning it demonstrates that the vendor understood the actual operational or decision-making problem the entity is trying to solve, rather than proposing an off-the-shelf tool applied to a problem it has not deeply understood. This shows practically in how the scope of work is written: is it built on measurable objectives, or is it a generic description of a technology applicable to any entity?
A strong proposal clearly separates what is certain from what is estimated: a realistic timeline, dependencies on other internal parties, and anticipated risks with a plan to manage them, rather than a proposal free of any caveat that looks flawless only on paper. It also precisely defines the boundary between what the vendor's team delivers and what requires genuine participation from the entity's own team, because many AI projects stall not due to technical weakness but due to the absence of clear internal commitment from the entity itself.
Finally, a strong proposal presents a post-delivery governance model that is no less detailed than the implementation model, explaining periodic model review mechanisms and how changes in data or operational context will be handled over time. This is precisely what distinguishes a vendor selling a project that expires upon delivery from a vendor building a working relationship grounded in ongoing accountability.
Common Evaluation Pitfalls Worth Watching For
A recurring mistake is giving excessive weight to presentation design and visuals at the expense of technical content accuracy, particularly when committee members come from fully non-technical administrative backgrounds. The solution is not to exclude these members but to equip them with specific evaluation questions they can ask without needing deep technical expertise, such as directly asking about the data quality verification plan and the acceptance criteria for results.
Another mistake is treating all AI proposals as one homogeneous category, when they differ fundamentally between an analytical solution supporting decisions, a process automation solution, and a generative-model-based solution for user interaction, each requiring partially different evaluation criteria. Applying one uniform standard across different solution types weakens the accuracy of comparison between competing proposals.
A third, perhaps more serious, mistake is the absence of a formal clarification question stage with competitors before final award. Many ambiguities in proposals can be resolved through a direct, documented question, which reduces reliance on general impressions and increases reliance on specific, comparable, documented answers evaluated fairly and equally across competitors.
The Next Step: Building an Evaluation Standard That Serves, Not Complicates, Your Decision
If your entity is preparing to launch a tender that includes an AI component, or reviewing a terms of reference document still in draft, the real question worth pausing on is this: do the current evaluation criteria genuinely reflect the nature of the required solution, or are they generic criteria recycled from previous tenders unrelated to AI? It is a simple question, but an honest answer to it often reveals a gap worth addressing before the tender is issued, not after proposals are received.
If your technical committee needs an independent review of evaluation criteria, help drafting precise clarification questions for competitors, or a neutral interpretation of a complex technical proposal before an award decision, this is precisely the natural point of intersection with ASLS.AI's strategic AI advisory services, where the role is to support decision quality from an independent position, not to represent a vendor or promote a particular solution.
We are not here to promise guaranteed outcomes, nor to pressure immediate action. If your entity already has clear, well-tested evaluation criteria, this article serves simply as a useful confirmation. But if, while reading, you noticed that your current terms of reference lack a clear standard for data quality, a validation stage, or post-delivery governance, that is a practical signal worth a short, no-obligation initial advisory conversation to review these criteria before they become a contractual decision that is difficult to adjust later.