Introduction

Harnessing the transformative potential of AI for positive outcomes requires careful navigation by decision-makers. To support this process, Cenfri has developed an AI Implementation Framework to help public sector decision-makers in emerging economies assess how AI tools should be integrated, localised, governed, and safeguarded within their specific institutional contexts.

Originally developed in collaboration with the Ministry of ICT and Innovation in Rwanda as part of the Rwanda Economy Digitalisation (RED) Programme, the framework is designed for broader application across public institutions and private-sector organisations in emerging economies.

Note: The term AI includes a wide range of tools and techniques, from predictive analytics and machine learning models to generative AI systems such as Large Language Models (LLMs). This article and the framework offers a holistic approach to evaluating AI implementation, but places a particular emphasis on the implementation of generative AI systems.

Global AI context: Dealing with uncertainty

It remains difficult to predict the trajectory of AI developments. Advances could accelerate dramatically towards “super intelligence” or develop more unevenly through periods of “jagged progress”, where current LLMs plateau and alternative approaches emerge.

But the pace and nature of AI development is not the only consideration. Policymakers seeking to harness AI face a combination of technological, economic, and geopolitical uncertainty. Control over frontier AI capabilities is concentrated among a small number of companies and a handful of countries. Geopolitical tensions, export controls, cloud dependencies, and supply chain constraints further complicate access to infrastructure and computing power, particularly for smaller developing economies.

While the current AI ecosystem may reflect elements of a technology bubble, any future correction is still likely to leave behind valuable infrastructure and lower costs. The greatest opportunities may therefore lie not in building frontier models, but in effectively diffusing, integrating, and applying AI within real-world systems.

The Cenfri AI Implementation Framework

AI implementation is not a single technical decision. It requires a series of interconnected choices about infrastructure, governance, localisation, cost, risk, and institutional readiness. Different use cases require different implementation pathways, and the same technology can produce very different outcomes depending on how it is adapted, deployed and embedded in local systems.

For governments, this matters because there are risks both in moving too quickly and in moving too slowly. Poorly deployed AI can create new costs, dependencies, and governance challenges. But failing to engage with AI where it could improve services, strengthen institutions, or ease binding development constraints may also mean missing important opportunities.

A further imperative for governments is how to build for ongoing adaptation as AI evolves, rather than simply deciding whether or not to adopt what is currently available. Adaptation in this context refers to more than tailoring AI to local languages, institutions, or use cases. It also means making implementation choices that preserve future flexibility. Given the pace of change in AI, governments should avoid thinking only about what works today, and consider how easily systems can evolve, switch providers, incorporate new models, or respond to changing requirements over time.

The Cenfri AI Implementation Framework focuses on how AI can be implemented and is intended to cover the spectrum of choices governments face when moving from idea to deployment. It includes five broad implementation considerations relating to the technical and operational design of an AI use case deployment. These implementation considerations are:

• AI integration
• AI autonomy
• Deployment model
• Local adaptation
• Need for compute

The first two considerations, AI integration and AI autonomy, relate to how the AI will be used, where it is embedded in workflows and how much responsibility it is given. The remaining three relate to how AI will be deployed for the use case: where the system runs, how far it is adapted to local needs, and what infrastructure is needed to support it.

Each of the five considerations represent a spectrum of implementation choices. Public sector decision-makers need to understand where a specific use case sits across these five dimensions, because different combinations have important implications for implementation costs, risks, feasibility and potential value:

AI integration

The AI integration consideration relates to how deeply AI will be embedded in institutional workflows and systems. At one end, AI may be used as a standalone tool, such as an individual using ChatGPT outside of a core government system. From there, AI can become embedded in workflows, supporting specific operational processes such as document review or call-centre support. Further along this spectrum, it can become embedded in systems of record, influencing authoritative systems where official records are maintained. At the far end, AI can support cross-system orchestration, coordinating multiple systems across an end-to-end process.

AI autonomy

This consideration measures how much authority the AI has to act. At the lowest end, AI simply informs, it summarises, searches, or explains. The next step is to propose actions, where it drafts outputs or suggests actions for human review. Further along is execute with approval, where it can act only after a human confirms. At the highest end is execute with guardrails, where the system acts automatically within predefined limits and escalates exceptions. This progression matters because increasing autonomy can create more value, but it also increases governance needs and the consequences of poor design.

Deployment model

This considers where the AI system runs, where data is processed, and implicitly who is responsible for operating and maintaining the system. The deployment model ranges from external APIs (application programming interfaces), where the provider handles the technical deployment, to hybrid models that combine external models with local data and controls, to in-country hosting, where more control over data and latency is retained, and finally to distributed edge, where models run on local devices or nearby servers. The progression here is not just technical. It reflects a change in who controls the system, where the data sits, and how much operational responsibility sits locally.

Local adaptation

This assesses how far the model is tailored to local conditions. At one end is no localisation – using an off-the-shelf service as is. Then comes local augmentation, such as adding local context or guardrails. After that is local tuning, where an existing model receives additional training on local information. At the far end is extensive local training, where a new model is built through substantial additional training. This progression helps distinguish between simply consuming AI and actively shaping it for local needs, such as language or domain specificity.

Compute needs

This consideration measures the level of processing power required to train the model and to run the use case. Some use cases are CPU (central processing unit) native and can run on ordinary computing environments. Others are GPU (graphics processing unit) assisted, where some accelerator capacity is useful. More demanding use cases become GPU dependent, and the most demanding require GPU cluster scale. It is also necessary to distinguish between the compute required to train or adapt a model and the compute needed to run the system. This matters because not every promising use case needs heavy infrastructure and not every ambitious AI plan is justified simply because it sounds advanced.

Taken together, these five considerations demonstrate that implementing AI is not a single decision. It is a set of repeated/ongoing design choices. A government chatbot, a grading tool, a radiology support system, and a local language model may all involve AI, but the way they are integrated, adapted, deployed and resourced can be very different. The framework is meant to surface these choices in thinking through a particular use case.

The framework also hints at why some AI opportunities may be attractive early on, while others may be better approached more cautiously. Some use cases may sit at the simpler end of most of the five implementation considerations – low integration, low autonomy, external deployment, little localisation, and modest compute needs. Others may require deeper embedding, stronger local control, more adaptation, and more infrastructure. The framework does not tell public sector decision-makers what to choose. It helps them understand what they are choosing.

Use-case mapping

1. Coding assistant for government teams

A coding assistant can help public-sector software teams write, test, and document code more efficiently, improving the delivery of digital public services. Within the framework, this is typically a standalone or workflow-embedded tool operating at a “propose” level of autonomy, where developers retain full control over implementation decisions.

In most cases, the tool relies on an external API, requires little or no local model adaptation, and can run on standard CPU-based infrastructure. Because it is comparatively simple to deploy and govern, it represents one of the least complex use cases in the framework and is immediately deployable in many contexts.

2. Automated grading of exam papers

AI-assisted marking systems can help reduce examination backlogs, lower teacher overtime costs, and accelerate turnaround times for assessments, particularly during high-pressure periods such as end-of-year and transition examinations. This use case may begin as a standalone tool but often becomes workflow-embedded once integrated with student records and grading systems.

Given the importance of accountability and fairness, the system should remain firmly within an “execute-with-approval” model, with human moderators retaining final oversight of grading decisions. Because the tool must interpret local curricula, grading conventions, and language nuances, it typically requires hybrid or in-country deployment alongside some degree of local augmentation or fine-tuning. Compared to coding assistants, this use case introduces higher governance requirements and operational complexity but also offers more visible public-service benefits.

3. Weather forecasting and multi-channel alerts

Weather forecasting systems can combine machine learning with meteorological data to issue automated alerts through SMS, apps, and public media channels. These systems are often workflow embedded or localised standalone tools and may operate with a relatively high degree of autonomy, including execute-with-guardrails functionality with pre-set conditions that, when met, automatically trigger the system to issue alerts, or escalate to a human in case of anomalies.

The technical requirements are manageable, especially where data volumes are modest and local processing is sufficient. The value can be substantial, particularly for agricultural resilience and public safety. Costs are generally contained, risks are limited to operational issues such as false alerts, and the main requirement is basic organisational readiness.

4. AI radiology triage in district hospitals

In district hospitals, AI radiology tools can support clinicians by pre-analysing X-rays and CT scans to help identify conditions such as fractures, tuberculosis, and pneumonia. This is a deeply workflow-embedded use case that should remain within a “propose” model, with clinicians retaining final authority over diagnosis and treatment decisions.

Because of the sensitivity of medical data, the need for reliable performance, and the realities of low-connectivity environments, these systems often require hybrid, in-country, or edge-based deployment models. They also demand local validation, robust governance frameworks, and careful assessment of training and inference infrastructure to operate effectively.

While the implementation costs and operational risks are substantially higher, the potential public value is also considerable, particularly in healthcare systems where radiology expertise is limited. Successful deployment, therefore, depends not only on the technology itself but on sustained investment in institutional capability, infrastructure, and oversight.

5. A large language model fluent in local language

At the most ambitious end of the spectrum is the development of a deeply adapted large language model trained to understand and generate conversation in local language. Rather than serving a single application, this model functions as a shared capability layer that other products and services can build on. For example, everything from voice-based agricultural advice to digital health interactions in local languages.

This is a far more complex proposition than the other examples. It requires cross-system orchestration, a high degree of autonomy, in-country hosting, extensive local training, and large-scale GPU infrastructure. The direct fiscal return may be limited in the short term, but the broader social and economic upside could be transformative if it helps dismantle structural barriers such as language exclusion and low digital literacy. It is, however, a capital-intensive strategic bet with significant fiscal, strategic, and sovereignty risks, and it would require a major expansion of state capacity to implement successfully.

Applying the framework

To explore the full methodology, download the Cenfri AI Implementation Framework. Look out for forthcoming articles in this series, which will focus on costs, risks and feasibility factors and how to evaluate the fiscal, social, and economic value of AI implementation.

Download the full framework here: Cenfri AI Implementation Framework