AI governance in Morocco: control use without blocking innovation

AI governance in Morocco should not slow projects down with an extra approval layer. It gives teams a shared operating model for knowing which systems exist, who owns them, what data they use, which controls apply, and how to respond when an output becomes uncertain. Without that foundation, a promising prototype can reach production without a clear owner, acceptance criteria, or incident procedure.

AI governance is an operating model

Useful governance connects strategy, business operations, technology, security, data protection, and service management. It is neither a central committee nor a generic charter. It turns principles into verifiable decisions: approve a use case, require additional evaluation, restrict certain data, mandate human review, or retire a system.

The NIST AI Risk Management Framework structures this work around four complementary functions—Govern, Map, Measure, and Manage—while the NIST Playbook offers adaptable actions. ISO/IEC 42001 adds a management-system and continual-improvement approach. These voluntary references are useful working frameworks, not replacements for applicable obligations.

Start with a living inventory of AI systems

An organization cannot govern what it cannot see. The first practical asset for AI governance in Morocco is therefore a register covering internally developed models, external APIs, AI functions embedded in business software, and independent use of generative tools. Each entry should record:

• the business purpose, users, and accountable owner;
• input and output data, sensitivity, and provenance;
• model, provider, version, and operating environment;
• people or processes affected by the output;
• evaluations, controls, incidents, changes, and review date;
• conditions for suspension, replacement, or retirement.

This register naturally follows an AI audit and use-case prioritization exercise. It should also include shadow AI: an individual subscription or an automated feature inside existing software may expose data or influence a decision without ever being labelled an AI project.

Classify uses by context and impact

The same technology presents different risks when it summarizes an internal memo, recommends a sales action, or influences a decision about a person. Classification should therefore consider purpose, autonomy, reversibility, data sensitivity, external exposure, and the severity of an error.

The result does not need to be a complex matrix. Three or four levels can work if each level triggers explicit requirements such as minimum documentation, enhanced testing, specialist review, human approval, logging, or prohibition. This avoids applying the same controls to an internal writing assistant and to a system involved in a sensitive decision.

Assign roles that match real decisions

A committee does not replace operational accountability. Every system should have at least a business owner, a technical owner, and an escalation channel. Depending on context, security, data, privacy, legal, procurement, and internal control functions join the review.

A concise RACI can identify who proposes, evaluates, authorizes, operates, and suspends a system. Leadership sets risk appetite and prohibited uses; the business defines the intended result; technical teams document limitations; control functions verify requirements; and operations monitor production signals. Our consulting and strategy service helps connect those roles to existing processes instead of building a parallel organization.

Protect data and govern suppliers

In Morocco, personal-data processing is notably governed by Law No. 09-08 and overseen by the CNDP. The CNDP is also conducting work on AI and personal-data protection. Governance should therefore connect every use case to its purpose, processing basis, data categories, recipients, retention, and security measures. This operational overview is not legal advice.

For a third-party AI service, review query retention, possible use for training, processing locations, subprocessors, available logs, model changes, availability commitments, and exit options. Contract terms do not replace testing: a provider can change a model while quality on business data no longer remains the same.

These controls are stronger when supported by established data governance: catalogs, access rights, quality, lineage, and retention rules.

Place decision gates throughout the lifecycle

AI governance in Morocco becomes concrete when it follows the lifecycle. Before development, teams define purpose, affected users, and failure scenarios. During building, they control data, access, dependencies, and versions. Before production, they review evaluation results, known limitations, human oversight, and rollback plans.

A generative AI evaluation should use realistic cases and criteria defined before selecting a model. For industrialized systems, MLOps provides reproducibility, deployment, and monitoring; governance determines which thresholds and evidence make a version acceptable.

Design human oversight and incident response

Human involvement must be designed rather than merely mentioned. Teams should specify when a user can correct an output, when a decision is blocked, what information supports review, and where ambiguous cases are escalated. A human-in-the-loop approach is valuable when judgment, sensitivity, or consequences require contextual validation.

The incident plan should cover inaccurate outputs, data leakage, misuse, observed bias, outages, and performance drift. It defines reporting, triage, possible suspension, communication, root-cause analysis, remediation, and lessons learned. Logging must remain proportionate: detailed enough to reconstruct a decision, without collecting unnecessary sensitive data.

Use indicators that support decisions

Useful indicators describe actual control: inventory coverage, systems with an owner, evaluation coverage, overdue reviews, open incidents, age of corrective actions, exception frequency, and movement in business outcomes. There is no universal threshold for every organization. Each metric should be tied to a decision, an owner, and a review cadence.

For a document assistant, source traceability, escalation rate, and errors on a reference set are more informative than a generic score. Our guide to reliable RAG shows how architecture, evaluation, and operational controls can work together.

A progressive roadmap for Moroccan organizations

1. Establish scope

List current uses, including tools purchased by individual teams, and identify owners. Begin with systems already in production and those involving sensitive data or important decisions.

2. Define a minimum policy

Document allowed, prohibited, and review-required uses, data rules, responsibilities, and the incident channel. A short policy that is applied and revised is better than an exhaustive document nobody uses.

3. Pilot on a representative portfolio

Test the register, classification, evaluations, and decision gates on a small selection of systems. Team feedback will reveal unnecessary controls and missing safeguards.

4. Integrate existing processes

Add AI questions to procurement, security, change management, data reviews, and production releases. Governance becomes durable when it is embedded in daily work.

5. Review continuously

A change of model, data, use, or supplier can alter risk. Registers and evaluations should therefore track the versions that are actually operating.

Governance accelerates sound decisions

Well-designed AI governance in Morocco gives leaders visibility and teams controlled autonomy. It turns the abstract question “Can we use this AI?” into concrete criteria: for which purpose, with which data, under whose responsibility, with what evidence, and with what stop mechanism.

Kanteek can help map use cases, define roles and policies, design controls, and connect governance with data, security, and MLOps practices. Discuss your AI portfolio with us to build a framework proportionate to your operations.