After defining an AI use case, the investment decision becomes more concrete: should the organization buy a ready-made solution, adapt an existing product, or develop components for its requirements? A persuasive demonstration or a low license price cannot settle that choice. The decision depends on task performance, integration with systems and data, applicable obligations, and clear responsibility for ongoing operation and change.

This article offers a practical approach for leaders and technology, data, and procurement teams in Saudi Arabia. Its matrix, scoring scale, and example are editorial tools to adapt to the context. They are not an official assessment standard or a recommendation to buy a particular product.

Define the task before comparing solutions

Start with a sentence identifying the task, user, and authority: “Help a service employee classify an incoming request, while the employee retains responsibility for routing it.” This gives competing approaches a shared task to perform. If the use case remains unclear, first define the problem and intended value. RMG’s article on AI use cases discusses this earlier stage in Arabic.

Distinguish three approaches, recognizing that the final solution may combine them:

• Ready-made solution: An existing product used with its standard configuration options. It is a candidate when testing shows that the available features can meet the task and its conditions.
• Adapted product: An existing product or model combined with organization-specific knowledge sources, integrations, interfaces, or business rules. Consider it when the core capability fits and the main gaps concern context or connectivity.
• Custom development: Application, model, or workflow components developed for defined requirements, potentially using existing components. It needs evidence supporting what will be built and a clear ability to operate and maintain it.

Three alternatives evaluated against the same task and shared acceptance criteria, rather than mandatory sequential stages.

Custom development does not necessarily mean training a model from scratch. Buying a product does not remove integration and testing work. Ask each provider to identify the components it controls, those supplied by other parties, and the changes possible in each.

Resolve essential acceptance conditions before scoring

A solution may be easy to use yet fail to respect document permissions or the required operating environment. Extra points for other features should not compensate for that failure. Agree with business, data, security, and legal specialists which conditions must be satisfied before procurement can proceed.

Ask what data the solution will process and where, who can access it, and whether the provider uses it for other purposes. Examine permissions, retention, deletion, and export, and determine whether these answers can be tested in an authorized environment. Record each condition as satisfied with evidence, not satisfied, or unresolved. An unresolved condition needs verification; urgency should not turn it into acceptance.

If the solution processes personal data, verify the processor’s safeguards and compliance; supplier selection does not remove the controller’s responsibilities. Review data-protection measures and the conditions for transfers or disclosures outside Saudi Arabia under the Personal Data Protection Law and its regulations, including transfer risk assessments in the specified cases.

For cybersecurity, establish which National Cybersecurity Authority controls and sector requirements apply to the organization and service. ECC 2-2024 defines organizational scope and control applicability according to the technologies used. Do not present every control as an identical obligation for all organizations, or treat local hosting alone as proof of full compliance.

Compare five dimensions and request evidence

Once the essential conditions are met, test alternatives using a common scope, sample, and acceptance criteria. Connect each score to an observation or test result, and document the limits of the available evidence.

Dimension	What to examine	Evidence to request
Fit	Task performance, Arabic, specialist terminology, and exceptions	Results on a relevant sample, including errors and limitations
Data	Sources, updates, permissions, and retrieval	A data-flow map and demonstrated permissions and update behavior
Integration	Connected systems, user identity, and failed requests	An end-to-end test covering failure and retry scenarios
Operations	Monitoring, support, updates, and recovery	Defined responsibilities, a response plan, and a recovery exercise
Cost	Setup, use, maintenance, change, and exit	Estimates using the same time horizon and usage assumptions

 

An illustrative zero-to-three scale could assign zero to an unmet criterion, one to an untested promise, two to partial evidence, and three to evidence meeting the acceptance criterion. Agree weights before comparing offers and keep “unknown” as a separate status. A high overall score must not conceal an unmet essential condition.

Test the sensitivity of the result. Does the ranking change when integration or operating cost becomes more important? If a small change in assumptions reverses the order, investigate that uncertainty before making a long commitment.

Compare the cost of completing an accepted task

Total cost extends beyond the license or development invoice. It may include hosting, data preparation, integration and testing, human review, monitoring, support, training, and eventual change or migration. Compare these items over the same period, distinguish initial investment from recurring expense, and avoid counting an item twice.

Define an “accepted task” before calculating its cost: a correctly classified request confirmed by an employee, or a draft that passes review, rather than any response generated by the system. A low price per request may still require extensive correction. Compare expected demand with a higher-demand scenario and record how review time and failures affect the cost of an accepted result.

Cost categories to include in the comparison. This is a qualitative illustration, not relative cost weights or study results.

Do not turn an early estimate into a promise of guaranteed savings. NIST’s AI RMF can help structure discussion of risks across the solution lifecycle, while keeping voluntary guidance distinct from applicable Saudi requirements. Using the framework does not confer a compliance certification. [5]

A practical example of service-request classification

Consider an organization that wants to suggest a destination for service requests without routing them automatically. A ready-made platform recognizes common categories, but testing reveals difficulty with important internal terminology. The team can test adaptation through a terminology resource, rules, knowledge sources, and suitable integration before assuming it needs a new model.

If the task relies on relationships between records in several systems and the product cannot retrieve the required information or enforce access restrictions, a custom component may warrant investigation. The decision still depends on suitable data and a capable operating team. A distinctive requirement alone does not establish a business case for building.

Test alternatives against the same sample, including straightforward, incomplete, and conflicting requests, and retain examples that were not used for tuning. Record routing errors, correction time, and permission boundaries, then compare the results with the acceptance criteria. This is a hypothetical example explaining the approach, not an RMG customer case or a claimed project result.

Turn the comparison into an actionable decision

Conclude the evaluation with a short decision record identifying the chosen approach, reasons for rejecting alternatives, test evidence, operating boundaries, cost assumptions, and service owner. Connect procurement to verifiable acceptance criteria rather than a broad feature list.

Document the exit arrangements: which data, configurations, and business rules can be retrieved, and in which formats. Specify who responds when a connected system changes its interface, how external model updates are managed, and when the task must be retested. If an essential condition still lacks evidence, choose a limited trial or further verification rather than approving broad deployment.

Establish a clear scope before investing

The appropriate solution may combine purchased and custom components. Define the organization’s needs, test the gap, and build only what the evidence justifies. The decision then rests on value that can be examined and the organization’s ability to operate the result.

RMG’s published AI strategy development and implementation service provides a route to discuss the current state, use cases, implementation planning, and evaluation, alongside its AI solution development offering. A use-case brief and evidence matrix can establish an appropriate scope before development is commissioned. The linked service pages are in Arabic.