Who Gets to Choose the Model in an Enterprise Academy?

Model choice has left the engineering layer

A single-model AI feature lets a learning-platform vendor make most technical decisions behind the scenes. A multi-model LMS changes that arrangement. The platform may route work by capability, latency, cost or availability, but each routing choice can also affect data handling, acceptable risk and the bank’s internal AI policy. That makes AI model governance a customer control, not merely an infrastructure concern.

For a Chief Innovation Officer, the goal is not to force one model across every use case. It is to give compliance, security, learning and business owners a shared way to set boundaries without stopping capability building. A bank should be able to enable practical AI-supported learning while deciding where each model may and may not operate.

Notion makes the control surface visible

Notion’s September 9, 2026 release introduced workspace-level model controls that let owners choose which models are available for Notion Agent and Custom Agents separately, then set a default for Custom Agents. Notion frames the controls around predictable cost and compliance needs. (notion.com)

The important signal is not that every enterprise academy should copy Notion’s product design. It is that model selection is now visible to the customer. Once a platform offers several models, enterprise AI controls become part of the operating model. Hiding the choice may simplify the interface, but it leaves the buyer unable to apply policy at the point where AI work happens.

An academy contains different AI risk classes

Learning workflows do not carry the same exposure. An author using AI to turn an approved policy document into a first course draft has a different risk profile from a learner asking a tutor about a live operating procedure. Automated assessment creates another boundary because it can influence progression, certification and management reporting.

Treating all three as one generic “AI feature” creates blunt choices. The bank either accepts one broad policy or disables useful functions. AI learning platform compliance needs a more precise model: set controls according to the task, the input data, the audience and the consequence of a wrong answer.

Policy should follow the learning workflow

A workable academy configuration separates model policy by feature rather than applying one tenant-wide rule.

• Authoring can permit a defined set of models for approved internal source material, with human review required before publication.
• Learner-facing tutoring can use a narrower AI model allowlist, constrained retrieval sources and clear escalation when the system lacks an approved answer.
• Assessment can use only models and prompts validated for the task, with stricter version control and human review for consequential decisions.
• Experimental learning labs can operate in a separated policy zone that never inherits access to production learning content or sensitive banking data.

This structure preserves speed. A learning team can launch AI literacy, automation or digital-assets programmes without waiting for every future use case to clear the same approval path. At the same time, it prevents an experimental authoring capability from quietly becoming the model policy for learner advice or scored assessment.

The tenant roster needs clear rules

A strong configuration starts with a tenant-level roster. Administrators need to select approved model families and versions, set a default per feature, and exclude models that do not meet the bank’s contractual or risk requirements. They also need explicit rules for which data classifications each feature may send to an AI service.

The platform should then resolve requests deterministically. If the preferred model is unavailable, rate-limited or prohibited for a request, it should use a pre-approved secondary model or move to a defined non-AI path. It must never silently route a learner interaction to a model outside the bank’s policy. This is where multi-model routing becomes a real enterprise control surface.

Audit trails turn policy into an operating practice

A policy that cannot be inspected becomes a promise rather than a control. The academy should record the feature used, policy version evaluated, model and version selected, fallback event, outcome status and relevant administrator exception. Content logging should remain proportionate and privacy-aware; teams often need traceable metadata, not permanent copies of every learner prompt.

Retool’s framework for multi-agent governance makes a useful adjacent point: data boundaries, approval gates and a usable audit trail must be designed into the system rather than reconstructed after an incident. (retool.com) The same principle applies when several models sit behind an enterprise academy.

Governance becomes part of the buying decision

During procurement, banks should ask more than which foundation models a platform supports. They should ask who can allow or prohibit a model, whether controls differ by authoring, tutoring and assessment, how version changes are handled, what happens during outages, and whether an auditor can reconstruct the routing decision.

For App-Learning, model policy belongs alongside academy roles, learning audiences, content permissions and reporting rules. That design lets a bank keep AI enabled where it creates learning value, contain it where risk is higher, and show that the control works. The decisive question is no longer which model a platform can call. It is whether the bank can govern that call with the same discipline it applies to the rest of its learning estate.