Deployment Is Where the Model Meets the Institution
This chapter follows an AI project run by a financial supervisory authority from an evaluated candidate into day-to-day supervisory work. The focus is the operating environment around the model: who owns the result, which systems and people must use it, what changes after launch, and how the authority responds when performance or accountability weakens. Readers should be able to identify the dependencies and records that keep a deployed model useful, secure, and stoppable rather than treating deployment as proof that the project succeeded.
The model inherits the institution’s constraints
An AI model does not enter an empty technical environment. It enters an authority with legal responsibilities, existing reporting and case systems, established supervisory routines, public procurement rules, finite budgets, and staff whose time is already allocated. The model’s performance can therefore be limited by an interface, an approval process, or a missing skill even when the underlying algorithm is sound.
The IMF paper treats an AI project as an interplay of technology, processes, and people. Its proposed project team includes a business owner who defines the use case and success criteria, a project manager who connects the business problem to delivery, and a design group that may include data engineers, data scientists, AI engineers, and software engineers. Depending on the project, cloud, DevOps, user-experience, and test expertise may also be needed. Legal and ethics representatives become particularly important for high-materiality uses or when a third party develops the system.
These roles are not a staffing chart for every authority. They are ways of assigning decisions that otherwise become invisible. The business owner can explain why a document review, market-monitoring signal, or risk estimate matters and what would make it useful after deployment. The data specialist can assess whether the inputs remain usable. The AI or software engineer can build and integrate the production system. The project manager can expose dependencies and keep the work connected to its objective. Legal and ethics functions can examine whether the data practice and system use fit the authority’s obligations and risk controls.
When resources are scarce, the IMF paper prioritizes the business-owner, data-scientist, and software-engineer functions. That does not mean other responsibilities disappear. It means people may combine roles, seek external expertise, or stage the project so that the authority can learn while it develops internal capacity. The paper also emphasizes knowledge transfer and training. If the only person who understands how a model was prepared leaves, the authority may retain a running service without retaining the ability to question it.
A vendor can supply technical capacity, but cannot supply the authority’s supervisory purpose. CGAP notes that vendors often specialize in private-sector problems, so off-the-shelf products rarely meet every market-conduct need and customization is usually required. The authority must be closely involved in specifying the data gap, desired supervisory objective, and workflow change. Otherwise, procurement can reverse the proper order: the product’s features become the problem definition, and the authority later searches for a use for what it has bought.
The surrounding infrastructure creates a similar constraint. The IMF paper identifies legacy systems that are not prepared to incorporate AI, insufficient processing power or storage, dependence on cloud providers, and information systems designed in silos. Cloud services can provide scalable computing and machine-learning platforms without the same initial investment in physical infrastructure. But the choice depends on the criticality and sensitivity of the application, the authority’s architecture and skills, and legal or regulatory requirements.