“ We already have a register, we're compliant. ” This sentence, heard at the launch of almost every AI project in Monaco, is the surest sign that compliance is about to go off the rails. Because an Artificial Intelligence system does not merely process personal data: it ingests data to feed itself, it cross-references data to make suggestions, it transmits data to technical components in order to function. Each of these gestures triggers a precise obligation under law n°1.565, and it is at exactly these points, invisible from a register, that deployments get caught out.
The law n°1.565 of 3 December 2024 modernised Monaco's personal data protection framework and aligned it with the European GDPR and the Council of Europe's Convention 108+. The supervisory authority, the APDP (Personal Data Protection Authority), succeeds the CCIN with broadened powers. Let us define the scope of this article from the outset: law n°1.565 governs the “ personal data ” dimension of a project, not the whole question of AI. It is precisely this dimension that derails the majority of deployments, and it is this dimension that we set out here, obligation by obligation, in the order in which a pipeline encounters them.
The reflex to correct first: AI is not one processing operation, it is several
When a firm declares “ I have an AI project ”, it generally has a single purpose in mind: responding to clients faster, preparing a KYC file, drafting minutes. From the standpoint of law n°1.565, this is never a single processing operation. It is at least three, stacked on top of one another, and each has its own compliance logic.
- The dataset that feeds the system (indexed documents, histories, emails), with its own lawfulness.
- The processing at the moment of use (the agent that reads, cross-references, suggests), with its legal basis and its minimisation.
- The outbound flows to the technical components (language model, host, connected tools), with their status as sub-processing and their transfers.
As long as one reasons in terms of “ one project, one declaration ”, two-thirds of the obligations are missed. The compliance of an AI system is built layer by layer, because that is how the system itself is built. The register does not lie: it describes the project as it was conceived, not as the machine actually makes it live.
The legal basis, applied to what the model really does
Law n°1.565 requires a legal basis for each processing operation: consent, performance of a contract, legal obligation, or legitimate interest. On paper, everyone knows this. The difficulty, with AI, is that the legal basis of the business activity does not automatically cover what the system does with the data.
Take a family office consolidating an estate. Collecting the client's documents rests on the performance of the mandate contract: perfectly clear. But if one decides to index ten years of client archives so that an agent can “ find comparable situations ”, one has created a new purpose, whose foundation is no longer a given client's mandate but the firm's legitimate interest in serving them better. This legitimate interest must be asserted, it must be documented, and it must be balanced against the rights of the data subjects. This balancing exercise is not a lawyer's detail: it is the analysis that decides whether the flow has the right to exist, and it is the one that is missing on the day the APDP asks the question.
The right reflex, from the framing stage onwards: for every data flow that enters the system, write in a single sentence why you have the right to do it. If the sentence does not come, the flow has no business being in the pipeline. It is a brutal test, and it is the most effective one we know of for cleaning up a scope before the first line of code.
Minimisation: an agent does not need to see everything
This is the most counter-intuitive obligation for anyone discovering AI, and the most powerful. One imagines that a model is all the better for being given access to everything. Law n°1.565 says the opposite: one processes only data that is adequate, relevant and limited to the purpose. And the technology, well handled, proves the law right.
In concrete terms, one does not plug an agent into the entire information system. One opens a perimeter to it. For an assistant preparing reminders for capital calls at a property management firm, the agent needs the co-owner's name, their share and their balance: it has no need whatsoever to know the composition of their household, their private exchanges with the residents' committee or their insurance file. This compartmentalisation is not an instruction given to the model (a model executes prohibitions poorly): it is an access restriction set upstream, at the level of the data itself, per client and per purpose, so that the system never receives what it has no business seeing, even if it wanted to.
Minimisation is not a constraint one endures after the fact: it is the best technical protection that exists. Data that an agent has never received can be neither leaked, nor biased, nor held against you by the APDP. One never secures anything as well as what one has chosen not to expose.
RAG or training: two regimes, two levels of risk
Here is the distinction that separates well-designed projects from the rest, and that almost no one explains to executives. Making an AI work on your documents can mean two radically different things.
Training (fine-tuning)
One modifies the model's internal parameters with your data. The data is then absorbed into the model, melted into its weights, with no line remaining isolable. Compliance consequences: it becomes very difficult to prove that a piece of data has been erased, because the right to erasure under law n°1.565 collides with a model that does not “ unlearn ” cleanly; and the risk of involuntary disclosure of confidential information, in the course of an answer, genuinely exists. For data covered by Monégasque professional secrecy, this is rarely the right choice.
Retrieval-augmented generation (RAG)
Here, the model is not modified. Your documents remain in a database that you control, chunked and indexed for search. With each question, the system goes to fetch only the relevant passages and supplies them to the model as context, for the duration of one answer, then withdraws them. The data never enters the model's weights; it stays with you, alongside. Three decisive consequences follow: erasure becomes simple again (you remove the document from the index, and it disappears from every future answer); traceability is native, since the system knows which source served which answer and can cite it; and compartmentalisation per client is real, because access is granted only to the authorised index.
For the vast majority of Monégasque use cases (wealth management, shipowners' files, co-ownerships, clinic files), a RAG over documents that you keep control of is not only simpler to operate, but structurally more compliant. When a supplier proposes “ to train a model on your data ”, the first question to ask is therefore: are we talking about real training, or about RAG ? In everyday conversation, the word “ train ” often denotes RAG. The legal implications, however, are not of the same order, and the gap is paid for at the moment of an erasure request.
Automated decision-making and human intervention: a requirement, not a comfort
Law n°1.565, in keeping with the GDPR, regulates decisions producing legal effects or significantly affecting a person when they are taken on an exclusively automated basis. The person is then entitled to human intervention, to the expression of their point of view, and to the contestation of the decision.
This point is systematically underestimated, because one tells oneself “ my AI doesn't decide, it assists ”. The boundary is finer than it appears. An agent that automatically classes a client file as “ high AML/CFT risk ” and triggers a freeze, a tool that rejects a rental application in a prestige building, a scoring system that refuses to enter into a relationship: if the human merely rubber-stamps the machine's output with no real margin of appreciation, you are in automated decision-making, with the obligations that go with it.
Hence the principle we hold to on every deployment: the AI prepares, orders, proposes and gives reasons; the human decides. The “ human-in-the-loop ” is not a cosmetic precaution. It is what keeps the processing on the right side of the law, provided the validation is substantial. A human who clicks “ OK ” a thousand times a day without reading does not constitute human intervention within the meaning of the text. Compliance is then played out in the ergonomics: the validation workstation is designed so that the reason for the proposal is legible, so that rejecting costs the same gesture as accepting, and so that the decision remains real rather than reflexive.
Transfers and sub-processors: why a sovereign architecture simplifies everything
A “ consumer-grade ” AI system, by default, routes your data to servers outside the Principality, often outside Europe. Law n°1.565 strictly regulates these transfers outside Monégasque territory and imposes a contractual framework for sub-processors. Each technical component you plug in (the language model, the host, the messaging tool connected to the agent) is legally a sub-processor, with a contract to sign, a location to know and guarantees to verify. An AI pipeline quickly assembles five or six of these components; that is as many links to document.
This is where architecture stops being an engineer's subject and becomes a compliance subject. If the processing takes place in the Principality or on a controlled European private cloud (with a local host such as Monaco Cloud, Monaco Telecom or Telis, or in a European private deployment), the question of out-of-zone transfers largely resolves itself: there is simply no longer any flow to frame towards the outside. The number of sub-processors melts away, the contractual chain shortens, and the demonstration of compliance becomes legible. We remain agnostic as to the model used (Claude, Mistral AI or Gemini depending on the case): what matters is not the brand that computes, but the place where the data is processed and the nature of the contract that governs it.
In other words, sovereignty is not merely a reassuring posture for the marketplace: it is an architectural decision that mechanically removes a portion of the heaviest obligations of law n°1.565. In Monaco, where professional secrecy is a pillar of reputation, this removal at source is worth far more than a stack of contractual clauses meant to catch up with a flow that could simply never have been created.
The impact assessment (DPIA): when it is required and what it contains
The data protection impact assessment is not optional when a processing operation is liable to give rise to a high risk to the rights of individuals. And an AI project very often ticks the criteria that trigger it: large-scale processing, sensitive data, cross-referencing of sources, evaluation or scoring of individuals, a degree of automation. For many Monégasque use cases, the question is not “ is a DPIA needed ? ” but “ was it done before coding, or are we going to suffer it ? ”.
A useful DPIA describes the processing and its purposes, justifies necessity and proportionality (this is where minimisation is proven, with supporting evidence), lists the risks to individuals and the measures that reduce them (compartmentalisation, logging, human validation, data residence), then concludes on the residual risk. Conducted upstream, it takes a few days and steers the architecture: it says where training would be imprudent, which flow to remove, which access to restrict. Conducted after the fact, it turns into an autopsy, and can freeze an entire project at the precise moment it was about to go into production.
The case of financial players: 1.565 meets AML/CFT
For a private bank, a family office or a financial profession, a second framework is superimposed: AML/CFT (anti-money laundering and counter-terrorist financing), framed by law n°1.362 and supervised by SICCFIN. And the two logics can pull in opposite directions.
AML/CFT requires retaining, monitoring, documenting. Law n°1.565 requires minimising, limiting the retention period, respecting the rights of individuals. An agent that automates part of the AML/CFT screening lives at exactly this intersection. The good news: the two frameworks reconcile if they are handled together from the design stage. The retention imposed by AML/CFT constitutes a legal obligation that provides, precisely, the legal basis and the duration that law n°1.565 calls for: what one commands, the other accepts, provided it is written down. One must still distinguish what falls under the regulatory obligation from what falls under operational comfort, and not retain “ out of habit ” what nothing requires keeping. A right of access exercised by a client on the grounds of an AML/CFT freeze, for its part, collides with the non-disclosure rules specific to the field: this is typically the kind of arbitration that is prepared upstream, not under pressure.
What a compliant AI pipeline looks like
Put end to end, here is the blueprint of an AI system that holds up before the APDP. It reads like a chain, and each link answers a precise obligation.
- Qualified sources: one knows which data enters, where it comes from, and on what legal basis (mapping first, never modelling).
- Minimisation and compartmentalisation: the agent receives only the strict minimum, isolated per client and per purpose, with the restriction set at the access level.
- Local and logged processing: the computation takes place in a sovereign zone, in RAG rather than in training, and every access, every source, every output is traced.
- Substantial human validation: nothing with a significant effect goes out without a real human decision, tooled to stay real.
- Living register and DPIA: the processing is entered in the register, the impact assessment is done and updated when the scope shifts.
This is not a layer one lays at the end on an already-built system. It is the order in which one builds it. Compliance done well does not slow the project down: it spares it from stalling along the way, which remains the leading cause of failure for AI deployments. And when the project falls under a structuring digital programme, this rigour of framing is also what makes a file presentable to the Blue Fund of Extended Monaco, whose public co-financing can reach 70 % excl. VAT for eligible entities.
Where our role stops
Let us say it plainly: this article describes a method for engineering compliance, not legal advice. Minervia frames these obligations from the audit stage, designs the architecture so that they are met by construction, and documents what must be documented. But the legal qualification of a processing operation, the drafting of notices, the arbitration of a delicate legitimate interest or the interface with the APDP fall to your legal counsel and your DPO. The best projects we support are precisely those where technical expertise and legal counsel work together, from the very first week, because most of the costly mistakes lodge themselves at the boundary of the two.
If you are launching an AI project and cannot answer, for each data flow, the question “ on what basis, seen by whom, processed where, validated by whom, traced how ”, this is the right moment for an audit. It is better to ask these five questions before the first line of code than after the first request from the APDP.