Algeria AgencyArtificial intelligence
The impact assessment, before connecting an assistant to your customer data
It is done before go-live, and that alone is what distinguishes it from a report. Afterwards it describes a risk that has already either materialised or not.
A private school in Algiers wants to connect an assistant to its admissions mailbox: answering questions about the file, routing the rest to the office. The prototype works. Three weeks before opening, somebody asks whether the messages contain information about minors. They do, and the question should have been asked on day one.
That is what an impact assessment does, and its value lies entirely in its date: carried out before, it can stop a project; carried out after, it describes a risk that has already either materialised or not. For an artificial intelligence project it comes at the moment the architecture is decided, which is also when it is cheapest to write.
This article says when it is required, what it contains, and above all what to do when the result is bad. It replaces neither the full framework nor a lawyer’s view of your case; it describes a procedure and the reasoning it demands.
Before, or it is not an impact assessment
The difference between an impact assessment and a report is a date. The same document, the same rigour, the same pages: carried out before go-live it can cancel a project; carried out after, all it can do is observe.
That is not an administrative subtlety, it is the instrument’s function. It exists so that a business looks at what it is about to do while it can still not do it, and that window closes on opening day.
The practical consequence is a precise moment in a project, and it is neither the beginning nor the end: it is when the architecture is settled and before development starts. Earlier and you are assessing an intention, so the answers are vague; later and you are assessing an investment, and nobody wants the answer.
For an activity already running, the only defensible answer is to do it now and date it today, accepting that it is late. A late, honest assessment is a file with a weak point; a backdated one is something else, and it is the one act in this field that cannot be undone.
What the law asks, and when
Law 18-07 of 10 June 2018, amended and completed by law 25-11 of 24 July 2025, requires an impact assessment before implementing processing that presents a high risk to people’s rights and freedoms. The text wants it anticipatory: it is the priority in time that is required, not merely the existence of a document.
It comes with a second rule that surprises people and is the most useful to know: where the residual risk remains high after the measures envisaged, the authority must be consulted. So the assessment is not an internal document in every case — it can lead to a process.
It is also one of the four documents an inspection asks for, alongside the register, the logs and breach notifications. The order they are asked for in is logical: the register says what you do, the assessment says what you examined before doing it.
The above describes the state of a regulation as at 21 August 2026 and does not replace a lawyer’s advice. Whether your particular activity is high risk is a reading of a text applied to your case, and that is a lawyer’s question — we describe the procedure, not your situation.
What makes processing “high risk”
Three families recur and they are recognisable without legal training. Sensitive data: health, biometrics, opinions, judicial data. Vulnerable people: minors, patients, job applicants, anyone in a position of dependence on you. And scale: systematic, automated processing covering a lot of people.
An assistant connected to a customer mailbox rarely falls into the first family by design and frequently by accident. Nobody plans for a customer writing their state of health into a complaint; that is nonetheless what happens at a pharmacy, an insurer or a school.
The second family is the one assistant projects underestimate most, because it does not depend on content but on the relationship. An applicant writing to an employer, a patient writing to their clinic and a parent writing to their child’s school are not in a buyer’s position: they cannot simply go elsewhere.
The third is mechanical and it is the one automation creates on its own. Three hundred messages read by a human and read by a system are two different activities from a risk point of view, even when the content is identical — the second is systematic, it retains, and it produces a record. It is the same shift that makes an internal search engine never exceed the quality of the catalogue it is given: what changes is not the intention, it is the scale.
The one-hour draft
The full assessment takes time; the version that decides takes an hour. Four questions, written by hand, at the moment the architecture is being discussed: what does the system receive, what does it do with it, who can read it, and what happens when it gets something wrong.
The fourth is the one that sorts. An assistant proposing an appointment slot and getting it wrong costs ten minutes; an assistant answering a question about a medical treatment and getting it wrong does something else, and the difference appears in the answer to that one question.
That draft has no regulatory value and enormous decision value, because it arrives early enough to change the architecture rather than to document it. Most of the projects we have seen change direction changed it at that moment, not at the end of the formal assessment.
Keep it. It becomes the first page of the full assessment, and it carries something the final version always loses a little of: what the team believed it was doing before the details were written.
Describe the activity without selling it
The first part of the document describes what the system does, and that is where most assessments go wrong: they describe a commercial intention instead of an operation. “Improving customer service responsiveness” is not a description of processing.
What is one comes down to four things: the data received, field by field; what your systems add to it before processing; what the system does with it; and where all of that travels. The second is the most forgotten — a useful assistant receives the customer record and the history, which the customer did not write.
That description is almost entirely in your register if you have written one. The six columns, filled in on a real case produce exactly these elements, and this is the second time in this cluster that the register turns several days of work into an hour of reading.
Write it in the present tense and at field level. A document saying “the necessary data” lets nobody judge anything, and it also does not let you know, six months later, whether the system still does what the assessment described.
Risks to the people, not to the business
This is the inversion that decides the quality of the whole document, and almost nobody makes it spontaneously. A business listing its risks writes: fine, damage to reputation, a customer lost, service interruption. The instrument asks for something else: what the people concerned risk.
The same incident is then described differently. A leak of a school’s admissions database is not “a reputational risk”: it is the disclosure of children’s addresses and timetables. An assistant answering a billing question wrongly is not “a litigation risk”: it is a person paying what they do not owe.
That inversion has a consequence managements discover while doing it: it produces a different ranking. The gravest risks to the business and the gravest to the people are almost never the same, and an arrangement designed on the first list does not protect against the second.
It is also what makes the next section possible. A risk to the business can always be arbitrated — carried, insured, provisioned for. A serious risk to a person who did not choose to be exposed is not arbitrated the same way, and that is precisely what the assessment exists to make visible.
Measures: what reduces, and what relocates
The third part lists what reduces the risks identified, and it is judged on one simple property: a measure that cannot be verified is not one. “Raising team awareness” reduces nothing measurable; “the system only has access to the last thirty days of orders” can be checked by opening a configuration.
Three measures do most of the work on an assistant, and they are architectural rather than procedural. Reduce what goes in — send only the necessary fields. Reduce what is retained — the period at your end and at the supplier’s. And reduce what the system is allowed to do alone, by writing down what it hands over.
Beware of measures that relocate rather than reduce. Encrypting a database does not reduce the risk of a legitimate but ill-intentioned access; anonymising structured fields does nothing for what people write in free text; and having a policy signed relocates responsibility without changing what leaves.
The best test of a measure is to ask what exactly it prevents. If the answer is “it shows we take this seriously”, it belongs to the commercial file and not to the assessment — and the failure mode of these systems, which is to be wrong with confidence is mitigated by no policy.
The residual risk, the line nobody writes
After the measures, something remains. That line is the document’s conclusion and it is the one missing from nearly every assessment we read: they list risks, list measures, and stop, implying the subtraction comes to zero.
It never comes to zero, and writing it is what makes the document useful to a management. A director cannot decide on a list of risks and a list of measures; they can decide on a sentence saying what remains and who it would happen to.
It is also the line with a direct regulatory consequence. Where the residual risk remains high, the authority must be consulted — which means an honest assessment can open a process, and that an assessment systematically concluding in low risk may have been written to avoid that conclusion.
Write it as one sentence, with a subject and a verb. “The residual risk concerns free-text messages, which we cannot filter, and affects people who spontaneously write health information” is a conclusion. “Residual risk: moderate” is not.
When the result has to cancel the project
An assessment that cannot conclude in stopping is not an assessment, it is a dated formality. So it is worth knowing what the case where it does conclude that way looks like, because it does not look like a technical failure.
The first case is where the high residual risk falls on people who cannot protect themselves from it, and no available measure reduces it. An assistant reading job applicants’ files is a common example: the applicant can neither refuse nor go elsewhere, and will never know what the system did with their letter.
The second is where the necessary measures cost more than the project returns. That is a happy stop and it is frequent: a business discovering that a compliant assistant requires a cleaning architecture, an authorisation request and a subcontracting contract for thirty messages a day has just learned something useful, not something sad.
The third is the hardest to admit: the project is possible, it pays, and nobody in the business can sustain what it demands day to day. An assessment can conclude in stopping for that reason, and the same question already arises for what your employees use with no project at all — the capacity to keep to a rule is a real constraint and not an organisational detail.
Consulting the authority
Where the residual risk remains high, consultation is not a punishment: it is the mechanism provided for a case the text anticipates. The business sets out what it wants to do, what it examined and what remains, and receives a position before opening rather than after.
The difference from an inspection deserves saying plainly, because the confusion is frequent and expensive: an inspection observes what you did, a consultation is about what you intend. Arriving of your own accord with a built file is not the same position as being examined after the fact.
The file is the one you have just written, and that is the only practical benefit of doing it properly from the start: an assessment drafted seriously is passed on as it stands, one written for form’s sake has to be redone at the moment there is no time.
We will not describe how such a process unfolds or how long it takes, because we do not have a wide enough set of observations to do so honestly and because the arrangements fall to implementing regulations. What we can say is that the route exists and it is written down.
The single-paragraph test
Here is the check, and it is done this week, without us and without a document. Write in one paragraph what your assistant will do, as you would write it to a customer who asked — not to a committee, not to a supplier: to the person whose messages will be processed.
Then read it and ask two questions. Would that person, reading this paragraph, learn something they had not suspected? And is there a sentence you hesitated to write?
Both answers are more reliable risk indicators than any grid. What a customer would not have suspected is exactly what the assessment has to examine; and the sentence you hesitated over is, in our experience, the one that will appear in the residual risk.
The exercise takes a quarter of an hour and it usefully precedes everything else. A business that cannot write that paragraph honestly does not have a compliance problem: it has a project whose object it cannot describe to the person it concerns.
What we do, and what we refuse
We run the assessment at the moment the architecture is being decided, not after the prototype, and we write the description at field level — what goes in, what your systems add, what travels and where. That is the technical part, it is long, and it is the one nobody else can produce on your behalf.
We also carry the inversion: the risk list is written from the point of view of the people concerned, and we review it with your teams rather than with your management, because they are the ones who know what customers actually write.
We do not write a low residual risk to get a file through. It is the commonest implicit request on this subject, it is never phrased that way, and giving in to it destroys exactly what makes the document useful — a document whose conclusion was known in advance examined nothing.
And we offer no view on whether your processing is “high risk”. That is a legal characterisation applied to your case; it belongs to a lawyer or to your officer, and we stop at describing what the system does — which is, in practice, what they need in order to decide.
Frequently asked questions
Do we need an impact assessment for a simple answering assistant?
That depends on what it receives and who is writing, not on its technical complexity. An assistant handling delivery enquiries and one handling job applications are very different activities from the point of view of risk to people. The characterisation belongs to a lawyer; the one-hour draft, on the other hand, will tell you immediately which direction you are heading in.
Our activity is already running. Is it too late?
Too late for it to play its anticipatory role, not too late to do it. Carry it out now, date it today and accept that it is late: that is an honest file with a weak point. The one thing never to do is backdate it, which turns an administrative non-compliance into something else.
Who should write it?
The technical description comes from the people building the system, the risk evaluation is done with the teams who actually receive the messages, and the final judgement belongs to management. The data protection officer, where there is one, is the gathering point. An assessment written by only one of those three parties is recognisable immediately.
How many pages should it be?
Enough for somebody outside to understand what the system receives and what risk remains, which is rarely under three pages and rarely over ten for a project this size. Length is not a quality criterion; the absence of the residual-risk line is one, and it is missing from nearly every document we read.
What happens if the assessment concludes in high risk?
Two routes: reduce the risk by changing the architecture — the commonest and most useful case — or, if the residual risk remains high, consult the authority before go-live. A third route exists and is legitimate: not doing the project, which is the subject of section 8.
Can we reuse another project’s assessment?
The structure, yes, and it saves time. The content, no: the risks depend on what your customers write, on who they are and on what your system adds to the message, and those three do not transfer between businesses. A copied assessment describes an imaginary activity, which is the one genuinely serious defect it can have.
Where we come in
The paragraph written for the customer produced two things: what they would not have suspected, and the sentence you hesitated over. The second will end up in the residual risk.
- The examination runs while the technical hierarchy can still change, never after the prototype.
- Every field received is named, along with what your own systems attach to it before sending.
- The risk list is reviewed by the people who open the messages daily, not in a meeting room.
We will not draft a reassuring conclusion to unblock a go-live, and we do not characterise your processing in law.
Read next
Training a model: the three cases where it is worth it
Training changes the shape of answers, almost never their content. What you must supply, and the three cases where it is the right tool.Artificial intelligence: what it does well, what it invents, and what you cannot hand it
Its failure mode is not breakage, it is confident error. It produces text just good enough that nobody checks it.The AI your staff already use: what leaves the business, and the one page of rules that is enough
You bought nothing and it is already in service, on personal accounts. The problem is not the tool — it is that nobody knows what goes through it.
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.