Algeria AgencyArtificial intelligence
What you are allowed to send to a model hosted abroad
A chatbot connected to your mailbox exports your customer file, one line at a time. Nobody around the table described it that way.
A shopkeeper in Algiers put an assistant on their page. It answers delivery questions, it holds in the evening and on Friday, and it cost three weeks of work. Every message it handles — the customer’s name, their number, their address in Bab Ezzouar — goes to a server that is not in Algeria, and this was written down nowhere because nobody felt they were arranging anything.
This is where almost every AI project sold in this country breaks, and it breaks before the technical discussion rather than during it. This article describes what the law calls a transfer, what triggers one, and the three architectures that avoid the question instead of working around it.
It does not cover compliance in general — the full framework, from the register to the notification deadline is elsewhere. It covers one decision: what is allowed to leave your servers for a supplier’s, and in what form.
The call is the transfer, and nobody names it that way
An interface hosted outside Algeria does not consult your data remotely: it receives it. The message leaves your server, arrives at the supplier, is processed there, and the answer comes back. In between, the data existed on a machine that is not yours, in a country that is not yours.
The project’s vocabulary hides this systematically. People say “plug in an assistant”, “connect the AI”, “use a model” — three phrasings that describe a connection and not a despatch. Nobody around the table says “we are going to export the customer file in small pieces”, and yet that is the exact description of what the supplier’s logs record.
The confusion is reinforced by the fact that nothing is visible. A file transfer leaves a visible trace: an attachment, a send, a size in megabytes. An interface call leaves only a log line at a third party, and the business that triggered it does not even have access to that log.
The question to ask is therefore not “do we transfer data” — the answer is almost always yes — but “which data, to where, and under what authorisation”. All three are answered on one sheet of paper, and that is the subject of the rest of this article.
What the law asks, and since what date
Personal data processing in Algeria is governed by law 18-07 of 10 June 2018, amended and completed by law 25-11 of 24 July 2025, published in Journal officiel no. 48. Transferring data outside the country is subject to prior authorisation from the national data protection authority, and that did not change between the two texts.
What law 25-11 adds is an assessment requirement: the level of protection offered by the destination country enters the examination, alongside the security measures in place and the existence, there, of a supervisory authority. In other words, the question is no longer only “did you ask” but “where are you sending, and what protects the data once it arrives”.
It also adds the documents that make the request examinable. A register of processing activities describing, among other things, what leaves the country; a ledger tracing operations carried out on the files; the designation of a data protection officer; and notification to the authority within five days of becoming aware of a breach. A business holding none of these cannot describe its own transfer, and a request that describes nothing is not a request.
The above describes the state of a regulation as at 21 August 2026 and does not replace a lawyer’s advice. The exact scope of each obligation is read in the text, article by article, and some points are currently read differently by different practitioners — which is precisely why the part of this work that belongs to us stops at describing the flows.
What counts as personal data inside a customer message
A name and a phone number are obvious. Less obvious is that the body of the message almost always contains others: a delivery address, a child’s name, an order reference that leads back to an account, a mention of medical treatment, an employer’s name for invoicing.
The useful rule is not a list, it is a test: does this element, alone or combined with the other elements of the same message, single out a person among your customers? In a file of three hundred customers, “the lady from Kouba who orders on Tuesdays” singles out a person as surely as a phone number does.
Technical identifiers count too, and they are the ones forgotten. An internal account number, a session identifier, an order number: taken alone they say nothing, but they are designed to find a person in your system, and that is exactly the definition of an identifier.
Finally, the question arises not only for what the customer writes. It arises for what you add to the message before sending it: order history, the customer record, the contents of the basket. A useful assistant receives a great deal of that, and it is what makes it useful.
The supplier is not the subject; the flow is
The conversation almost always drifts towards the supplier’s reputation. This one is serious, that one is certified, another is used by banks. All true and all beside the point: prior authorisation concerns the existence of the transfer, not the quality of whoever receives it.
The confusion is expensive because it reassures. A business that chose a large supplier believes it has dealt with the regulatory question, when it has dealt with the technical reliability question — two unrelated subjects, only one of which appears in an inspection file.
It also has a practical consequence: the reasoning does not have to be redone when the supplier changes. A business that documented “we send these five fields to a service located in such a country” has a document that survives a change of provider; a business that documented the provider’s name starts again.
That is why taking stock of what you already have comes before choosing the tool, not after. The list of flows is the only part of the work that keeps its value when the technology changes, and it changes fast.
Three architectures, and what each one costs
The first strips the identifying elements before the call. The message leaves with no name, no number and no address; the model processes anonymous text; your system puts the identifiers back into the answer. It is the cheapest, it is built in a few days, and it only suits tasks whose answer does not depend on who is asking.
The second keeps the identifiers with you and sends only what the reasoning needs. An order assistant can know “loyal customer, three orders, last delivery late” without ever receiving a name. It takes more design work, because you have to decide field by field what leaves — and that work is exactly what the register asks for anyway.
The third runs the model on a machine you control. It removes the transfer question and replaces it with a fixed cost: the machine, the electricity, the administration, and somebody who can bring the service back on a Friday. Where your data lives and how long it takes to leave is the same question asked of infrastructure in general, and it is settled with the same figures.
These three are not a ranking. They answer different volumes, and the threshold can be calculated: below a certain number of calls per month, the third costs more than the first two combined, and above it the gap reverses. The threshold depends on your volume, not on a general rule.
What “anonymised” does not survive
Removing a name does not make a message anonymous. A message containing a commune, a time slot and an uncommon product often singles out one person in a mid-sized file, and it does so more sharply the more specialised the business is.
The commonest case is the order number left in the clear. It looks neutral — it is a string of digits — and it is designed to find a file. If it appears in a message sent outside and also appears in an email, an invoice or a delivery tracker, the match is possible with nothing sophisticated.
The second case is free text. You can clean the structured fields of a database and let “hello, it’s me again about my brother Karim’s order in Hydra” through in the body of the message, because the cleaning covered columns and not sentences.
The consequence is not that you should give up: it is that anonymisation is verified on real samples rather than in principle. What artificial intelligence does well and what it invents applies to automatic cleaning tools too, which recognise formats and miss turns of phrase.
Your subcontractor’s subcontractor
Most tools sold as turnkey solutions do not host a model. They call a third party’s, sometimes several depending on the task, and the data then crosses two companies instead of one. The contract you signed often names only the first.
The question to put to the supplier fits in one sentence and is rarely asked: “what is the name of the company that runs the model, in which country are its servers, and can that change without you telling me?” An evasive answer to that question is enough information not to sign.
What has to be in writing is short: the list of onward subcontractors, an undertaking to inform you before adding one, and a prohibition on using your data to train anything. The third point is the one that terms and conditions most often handle through an account setting you have to go and change yourself.
Responsibility, on the other hand, is not subcontracted. It stays with the business that collected the data, even when the fault lies with a provider it did not know existed — the same asymmetry as a cloud account opened in an employee’s name, where what is lost is not the server but the right to get into it.
Consent is not a transfer permit
Many businesses add a tick box to the form and consider the matter settled. Consent is a basis for processing data; it does not replace an administrative authorisation, which is an act of the authority and not of the customer. The two mechanisms do not cover the same thing and one cannot produce the other.
There is a practical problem on top. Consent is withdrawn, and withdrawn consent has to produce an effect: the data stops being processed, and it stops being processed at the foreign supplier too. A business with no way of requesting deletion at its provider has promised something it cannot deliver.
The box is nevertheless useful, on condition of being honest: telling the customer that their messages are processed by a service located abroad is information they have no other way of obtaining. One clear sentence beats a legal paragraph nobody reads.
The real work is elsewhere, and it is internal. The page of rules saying what employees may paste into a consumer tool treats exactly the same risk from the other end: what leaves the business without going through any project at all.
What the supplier keeps, and for how long
Three durations coexist and are rarely told apart. Processing time, counted in seconds. Retention for abuse monitoring, counted in days or weeks and switched on by default at most suppliers. And retention for service improvement, which has no announced duration and is the real subject.
The second is the one that surprises. A supplier stating it does not train its models on your data nonetheless keeps the exchanges for a short period, to detect abusive use, and that copy is accessible to people at their end. It is not hidden; it is written in documentation nobody opens.
For a sector where the data is sensitive, that alone settles it. In a clinic or a medical practice, the content of a message can reveal a state of health, and the question is no longer commercial risk but a category of data the law treats separately.
What to note before signing fits in three lines: the default retention period, whether a setting exists to shorten it, and the name of that setting. The third line is the one most often missing, because the feature exists and sits three screens away.
When the right answer is: no model at all
If three quarters of your messages are the same question about opening hours, delivery time or price, no transfer is needed because no model is. A written page and a saved reply handle those three quarters, cost a day, and raise no regulatory question at all.
If the data is sensitive and the volume low, the calculation nearly always falls the same way. Thirty requests a day in a professional practice do not justify a cleaning architecture, an authorisation request and a subcontracting contract; they justify a person who answers, and the written list of what an assistant must refuse to handle then becomes the list of what it is not given at all.
If nobody at your end can keep the register current, the project is premature whatever its technical quality. A transfer authorised on the basis of a description that is no longer true is an unauthorised transfer, and the description stops being true at the first change of tool.
These three cases share one thing: in all three, what is saved is not the cost of the model but the cost of the compliance that comes with it. That second cost is systematically absent from quotes, and it does not go away because nobody costed it.
The highlighter test: one week of conversations
Here is the operation to run this week, without us and without a tool. Export seven days of conversations from your mailbox or your site — the function exists in nearly everything, and failing that, copy them into a document. Take a hundred messages, no more.
Highlight in each one everything that designates a person: surname, first name, number, address, commune if it is precise, order number, a third party’s name, any detail that would make the person recognisable to someone who knows your customers. Do not think about the law during this step; highlight generously.
Then count two things. The number of messages with nothing left to highlight: those can leave as they are for any supplier. And the number of messages that would still be workable once the highlighted parts are removed — that is, whose answer did not depend on what was removed.
The ratio between those two numbers and your total decides the architecture before any quote. Above two thirds of messages workable without identifiers, the first architecture is enough. Below one third, you are in the second or the third, and the budget is not the one you were quoted. The count takes an hour and it belongs to you.
What we do, and what we refuse
We record the outbound flows tool by tool and write, for each, which fields leave and to which service. It is a document, not software, and it is written in your company’s vocabulary so that it stays usable when we are no longer there. We then build the chosen architecture and check it against a real sample before putting it into service.
We file no authorisation request on your behalf. A request commits the company that signs it to the accuracy of what it describes, and it is your management that must be able to answer for that description, not your IT supplier. We prepare the material; you sign.
We do not settle a borderline case. Knowing whether a particular use falls within an exception provided for in the text is a lawyer’s work, and a technical supplier who delivers that judgement to reassure you is doing you a disservice: their answer binds nobody and you have no way of contesting it. We name the moment the question leaves our trade, and we stop there.
Finally, we will often tell you the project is not worth what it sets in motion. An assistant handling thirty messages a day does not justify a full compliance chain, and saying so costs a contract we could have signed. It is the only thing that makes what we assert about the projects we do accept believable.
Frequently asked questions
Is prior authorisation needed even for a trial?
A trial with real data is processing like any other, and the fact that it is temporary changes nothing about what left the country. The sensible practice is to test on fabricated or cleaned data, which is the right method anyway: a test set contains the edge cases your real week of conversations does not.
Our supplier says it complies with the European regulation. Is that enough?
It tells you about the level of protection in the destination country, which is one element of the examination, and it does not replace the authorisation, which concerns your transfer rather than their organisation. A supplier compliant elsewhere is good news for the file, not an exemption from filing one.
If the model runs on a server rented abroad, is it the same thing?
Yes, from the flow’s point of view: the data leaves the country in both cases, and the machine being rented in your name does not change where it physically is. What changes is that you control retention and access, which makes the description far easier to write — but a transfer is still a transfer.
How long does it take to obtain an authorisation?
We publish no timeframe, because we do not have a wide enough set of observations to give an honest one and because an invented figure here would cost whoever plans on it. What we can say is that the long part is almost always describing the processing, which happens at your end, and that a business already keeping its register starts with most of the work done.
What if we use a consumer tool without connecting anything?
The flow is the same: what an employee pastes into a window goes exactly where a programmed call would go, minus any trace at the company’s end. It is in fact the hardest case to document, because nobody knows what was pasted, and it is handled by a written rule rather than by a ban.
Can we start with the first architecture and change later?
Yes, and it is often the right order, on one condition: that the boundary between what leaves and what stays is a single point in your system rather than scattered through the code. When it is in one place, changing architecture is a few days’ work; when it is everywhere, it is a rebuild.
Where we come in
If fewer than one third of your hundred messages stay workable once the highlighted parts are removed, the architecture is already decided, and it is not the cheapest of the three.
- We draw up the list of outside services your tools call, with the fields that go to each.
- We write the first rows of the register with your teams, on your real processing activities.
- We test the chosen architecture against a sample of your real conversations before building it.
We sign no request on your behalf and we deliver no judgement on a borderline case: that belongs to a lawyer, and we will tell you so rather than write it in their place.
Read next
The national AI strategy, translated for a small business
A strategy sets a direction; it imposes nothing on a business. Where it stands on 6 September 2026, what concerns you, and what already obliges you.The processing register, filled in on a real case
A twelve-person firm loses a tender on a document it had never heard named. Here are the six columns, filled in on a real assistant.The regional audit divisions: what an inspection asks for, in what order
An inspection begins with a list of documents, not with a visit. There are four, they are known, and nothing stops you producing them first.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.