Professional Privilege, Confidentiality and Data Sovereignty in Legal AI

For Moroccan legal teams, sovereignty is not a slogan. It is part of the trust architecture.

A lawyer's authority rests, more than is often acknowledged, on a quiet promise: what you tell me stays with me. That promise is older than software. It survives technology only if technology is designed to respect it.

This article does two things. It first explains why confidentiality, privilege, and sovereignty are not negotiable in legal AI. It then maps the specific Moroccan framework (Law 09-08, Law 05-20, the CNDP, the DGSSI, the maCERT, the DNSSI) that any legal AI buyer in Morocco must read before signing anything.

The goal is not a treatise on Moroccan cyber law. The goal is narrower and more useful. To give a legal team the vocabulary, the actors, and the questions it needs to evaluate a legal AI offering inside the Moroccan reality.

Professional secrecy is a duty, not a preference

In Moroccan legal practice, as in most francophone jurisdictions, professional secrecy is structural. It binds the lawyer, it protects the client, and it is taken seriously by both the profession and the courts.

The implications for legal AI are direct. If a tool, by design, sends client information to a third-party server in another country, processes it in ways the lawyer cannot inspect, and retains traces the lawyer cannot delete, then the lawyer has effectively shared client information with a party the client never agreed to. The fact that the third party is a software vendor does not change the analysis. The duty is the lawyer's.

This is not an abstract concern. It is the single most important question to resolve before any legal AI is brought into a firm or an in-house team.

What actually happens when you paste a contract into a public chatbot

It is worth being precise, because much of the public conversation is vague.

When a user pastes a contract into a public, consumer-grade AI tool, several things typically happen at once.

• The text leaves the user's device and is transmitted, often to servers outside the country.
• It is processed by a model that the user does not control.
• Depending on the tool's terms, the content may be retained, logged, used to improve the service, or reviewed by humans for quality control.
• The user has, in practice, no realistic way to recall it.

For a marketing draft, that may be a tolerable trade-off. For a confidential settlement term, an internal investigation memo, a non-public M&A document, a regulator's draft response, or a client's private dispute, it is not.

International enterprise legal AI platforms (Harvey, Legora, and similar) have built their value proposition partly on this realisation. Their architectures are designed so that client content stays inside a controlled perimeter, with contractual guarantees about data handling. That is the right baseline. The next question is whether that perimeter is the right perimeter for Morocco.

The three layers of confidentiality

It helps to separate confidentiality into three layers, because they are often confused.

1. Technical confidentiality. Encryption in transit and at rest, tenant isolation between clients, segregation of environments, vulnerability management. These are necessary, but they are not sufficient. A system can be technically secure and legally problematic.

2. Legal confidentiality. Whose law governs the data? Where is it physically stored? Who can compel its disclosure? Under what conditions is it subject to a foreign legal request? For a Moroccan law firm or in-house team handling Moroccan matters, the answers matter, and they are not the same in every jurisdiction.

3. Operational confidentiality. Who, inside your own organisation, can see what? A litigation matter visible to the entire firm is a confidentiality problem even if the firm's servers are perfectly secure. Role-based access, matter-level permissions, audit logs of who opened what, and the ability to revoke access cleanly are part of the picture.

A serious legal AI architecture addresses all three. A consumer tool addresses, at best, the first.

Data sovereignty, in plain language

Data sovereignty is the idea that data is subject to the laws and jurisdiction of the country where it is stored and processed. For legal data, by definition sensitive, sovereignty is not a marketing line. It is a question about who can, in a given situation, lawfully obtain access to a file.

For Moroccan legal teams, the relevant points are typically these.

• Hosting location. Where, physically, is the data?
• Operator jurisdiction. Which country's laws does the operator answer to?
• Cross-border transfers. Under what conditions can data leave Morocco, and is that compatible with the engagement letter and with applicable rules?
• Sub-processors. Who else, downstream, sees the data, and under what regime?

These questions are not exotic. They are exactly the questions a competent in-house team asks any major SaaS vendor today. Legal AI deserves at least the same level of scrutiny.

The Moroccan framework. Two laws, one direction

Legal AI does not enter Morocco on a blank page. It enters a country with a defined cybersecurity doctrine, a national data protection authority that has been operational for more than a decade, and a regulator of vital information systems sitting inside the national defense administration.

Two laws form the backbone relevant to legal AI.

Law 09-08, on the protection of individuals with regard to the processing of personal data. It is the Moroccan reference for personal data protection. It applies to any organisation processing personal data in Morocco, public or private. It creates obligations of declaration, of legal basis, of purpose limitation, of security, of retention, and of data subject rights. It is enforced by an independent authority, the CNDP.

Law 05-20, on cybersecurity. It organises the protection of information systems for state administrations, territorial authorities, public establishments and enterprises, and operators of so-called infrastructures of vital importance (banks, telecom operators, energy, transport, health, and others designated as such). It introduces obligations around governance, designation of an information systems security officer, technical and organisational safeguards, and incident notification to the national cybersecurity authority.

Read together, these two laws answer two different but adjacent questions.

• 09-08 asks: how is personal data protected, regardless of who holds it?
• 05-20 asks: how are critical information systems protected, regardless of whether they hold personal data?

A legal AI deployment in a Moroccan bank, a public hospital, a regulated insurer, or a ministry sits at the intersection of both.

Three institutions, three roles

Three institutions matter directly. They are easy to confuse, so it is worth being precise.

CNDP, Commission Nationale de contrôle de la protection des Données à caractère Personnel. The CNDP enforces Law 09-08. It receives declarations of personal data processing, examines complaints, conducts inquiries, and can sanction breaches. Any legal AI tool that processes personal data on Moroccan soil, and almost every legal AI tool does because legal documents are personal-data-dense, operates under the CNDP's field of view.

DGSSI, Direction Générale de la Sécurité des Systèmes d'Information. Attached to the National Defense Administration, the DGSSI is the national authority for the security of information systems. It defines the national doctrine, supervises cybersecurity requirements applicable to public bodies and operators of vital importance, and coordinates the national response to major incidents. For a legal AI buyer, the DGSSI is the reference for questions about system-level security expectations.

maCERT, the Moroccan Computer Emergency Response Team. Operating under the DGSSI, maCERT is the operational arm. Monitoring threats, issuing alerts and advisories, providing technical assistance during and after incidents. A serious legal AI vendor operating in Morocco should be aware of maCERT's published advisories and aligned with current threat intelligence.

The simplest way to remember the division of labour.

• CNDP = who can use the data, and for what.
• DGSSI = how the systems holding the data must be protected.
• maCERT = what to do when something goes wrong.

Alongside Law 05-20, Morocco publishes a national security directive for information systems, the Directive Nationale de la Sécurité des Systèmes d'Information (DNSSI). It establishes baseline expectations applicable to public organisations and operators of vital importance: governance, risk management, system protection, incident detection, business continuity. For a legal AI buyer, the DNSSI is less a checklist to memorise and more a signal of expectation. Any vendor serving regulated Moroccan clients should be conversant with its categories and able to discuss alignment without flinching.

Why this framework reshapes the legal AI conversation

Three consequences follow.

1. The trust perimeter is regulated, not merely contractual. In many jurisdictions, the confidentiality of legal AI is essentially a contractual matter between the client and the vendor. In Morocco, on top of that contract, sits a statutory framework administered by the CNDP for personal data and, for regulated entities, by the DGSSI for system security. A legal AI deployment is therefore not a private agreement between two parties. It is a private agreement that operates within a public framework. This means certain questions are no longer negotiable preferences. They are baseline expectations.

2. Hosting and jurisdiction matter, in writing. For organisations subject to Moroccan public-sector or vital-importance rules, hosting choices, operator jurisdiction, sub-processor chains, and cross-border data flows become elements of the security file. A legal AI vendor unable or unwilling to discuss its hosting setup in concrete terms is, for these buyers, immediately disqualifying. For private-sector organisations not formally designated as vital-importance operators, the framework is less prescriptive, but the direction of travel is the same. Clients ask the questions. Boards ask the questions. Insurers ask the questions.

3. Audit trails are a legal feature, not an IT feature. In a traditional legal practice, the audit trail is implicit. The file folder, the email chain, the partner's annotations, the time entries. In a digital, AI-assisted practice, the audit trail must be explicit. Who accessed which document, when, what they asked the AI, what the AI returned, who validated the output, and who finally signed. A legal AI architecture without audit logs, without traceable retrieval, and without clear access records is, in this context, not a security weakness. It is a regulatory weakness. The two cannot be separated.

In Morocco and francophone practice

Morocco's position is distinctive. It is a country with a mature legal profession, growing in-house legal sophistication, active financial and corporate sectors, a strong tradition of professional secrecy, and a data protection authority that is increasingly engaged. It is also a country where many sensitive matters (banking supervision, foreign exchange controls at BAM, anti-money-laundering at the UTRF, intellectual property at OMPIC, tax) involve regulators who themselves expect a high standard of confidentiality.

Three Moroccan realities give the framework particular weight.

The financial sector. Banks and insurers operating in Morocco are simultaneously among the heaviest users of legal documentation (contracts, KYC, AML files, regulatory correspondence) and among the most regulated holders of information systems. Their legal AI choices sit at the centre of both 05-20 and 09-08 considerations.

The public and parapublic sector. Ministries, public establishments, and large public enterprises handle volumes of legal work (public procurement, litigation, administrative decisions, employment matters) that are natural candidates for legal AI. They also operate under direct DGSSI oversight. Their procurement processes will ask cybersecurity questions, in writing, and expect substantive answers.

The bilingual reality. A French-language contract and an Arabic-language administrative act on the same matter must sit inside the same regulated perimeter. Any legal AI offering that handles one language under one architecture and the other under another creates regulatory ambiguity. The trust perimeter must be linguistically symmetric.

The conclusion is straightforward. For Moroccan legal teams, the question is not "should we use AI?" The question is under what architecture AI can be used without breaking the promise the profession is built on.

Practical example

Consider a confidential M&A transaction handled by an in-house legal team at a Casablanca-based group, supported by external counsel. The legal team works across a draft sale and purchase agreement with multiple negotiated versions, due diligence findings on sensitive employment and tax matters, communications with external counsel, internal memos for the executive committee, and regulatory notifications.

Three scenarios.

• Documents pasted into a public AI chatbot. Each paste is a separate confidentiality event. The team has no realistic way to know what is retained, where, or by whom. Even a single instance can be difficult to explain to a client, a counterparty, a regulator, or in case of dispute, a bâtonnier.

• A consumer-grade AI tool with a "private mode" toggle. Better, but the team is relying on a setting they do not control, on a server they do not own, in a jurisdiction whose interaction with their own engagement letter is unclear. The architecture is not aligned with the trust requirement.

• A Legal OS with Morocco-hosted infrastructure, tenant isolation, role-based access, audit logs, and AI that operates strictly within the matter's perimeter. The transaction can move quickly, the team uses AI productively, and the confidentiality promise to the board and the counterparty remains intact. When the CNDP question arises in a board committee, the documentation supports the answer rather than complicating it.

The point is not that the third option is comfortable. The point is that it is the only option compatible with how serious legal work has always been done, and with the regulatory environment in which Moroccan legal teams operate.

This example is illustrative. Any specific deployment or procurement decision must be reviewed by qualified Moroccan legal, compliance, and information security professionals.

What this changes for Burhan

Burhan is built on the assumption that confidentiality, sovereignty, and auditability are not features to be added later. They are the starting conditions.

In practical terms, that translates into design choices aligned with the Moroccan regulatory reality, not retrofitted to it. A tenant model that isolates each client's data, hosting choices aligned with Moroccan sovereignty expectations, role-based access at the matter level, audit logs on document access and AI interactions, and a documentation posture that supports a buyer's internal regulatory file, whether that file is going to a CNDP review, a CISO sign-off, a board committee, or a client questionnaire.

None of this turns Burhan into a cybersecurity product. Burhan is a Legal Operating System. But a Legal OS that ignores Law 05-20, Law 09-08, the DGSSI, the maCERT, and the CNDP would not be Moroccan in any meaningful sense. It would be foreign software with a local logo.

The lawyer remains responsible for the engagement, the advice, and the final output. The system's job is to make that responsibility easier to honour, not harder.

Key points

• Professional secrecy is structural. Any AI tool used in legal work inherits the duty, and pasting client content into public chatbots is a decision with consequences.
• Confidentiality has three layers (technical, legal, operational) and a serious deployment addresses all three.
• Moroccan legal AI deployments operate within a defined framework: Law 09-08 (CNDP), Law 05-20 (DGSSI), and the DNSSI for regulated entities.
• CNDP, DGSSI, and maCERT play distinct roles. Who can use the data, how the systems are protected, what happens when something goes wrong.
• Hosting, jurisdiction, sub-processors, audit trails, and linguistic symmetry (FR/AR under the same architecture) are regulatory expectations, not procurement details.