Which security must be in place before your AI goes live?

Security is the step that most often gets left behind. Not because business owners think it does not matter, but because there is no moment at which someone says: that is enough. With a lawful basis or a processing agreement you know when you are done. With security the law names no concrete measure at all. It only says the level has to match the risk.

That is not sloppiness on the legislator's part, it is a choice. And it means the question "what do I need in place before the AI goes live" can only be answered by looking at what could go wrong in your own situation. Below is how to do that without a security department, what belongs to AI in customer contact in practice, and where the line runs between your work and your vendor's.

Why is there no list of mandatory measures anywhere?

Article 32 GDPR is titled "Security of processing", which is exactly what you would expect: a list of things to install. That list is not there. The text opens with "taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing" and the risks to the rights and freedoms of natural persons. Then comes the instruction: take appropriate technical and organisational measures to ensure a level of security appropriate to the risk.

The Dutch data protection authority puts it in plain words: every organisation that processes personal data has to decide for itself which measures are needed, and to do that it first has to look at the risks the processing brings with it. So there is no regulator's checklist to hide behind. But there is also no standard your business cannot carry: the level scales with the risk, not with the size of the company.

Two things follow that are often misread. First: a small business may spend less on security, because the cost of implementation is literally in the text as a factor. But that is a weighing, not a free pass — when the risk is high, cost weighs light. Second: the risk you have to weigh is the harm to the people the data is about, not the harm to you. A leak of two hundred chats about a blocked drain is a different thing from a leak of two hundred chats about a medical complaint, even if the two companies are the same size.

What does "appropriate" mean when you work with a handful of people?

Appropriate means: you looked, you chose, and you can explain why. For a small business that fits on a single sheet of paper. Five questions are enough. What can go wrong with these conversations? How bad is that for the customer? How likely is it? What are we doing about it? What risk is left, and do we find that acceptable?

What AI changes here is not the weight of the requirements but the number of places customer data ends up. Before the AI you usually had one place: the mailbox or the phone. Once an assistant is running, there are quickly four. The conversations themselves, in the vendor's system. The searchable knowledge source the assistant draws its answers from, which often has fragments of old conversations in it. The log files of what was asked and answered. And the environment of the party supplying the language model. Every copy is a place where things can go wrong, and every copy belongs in your assessment by name.

There is one more difference with ordinary software. An AI assistant does something on its own: it reads incoming messages and it sends messages back. That means a mistake does not sit still but travels outwards, to a customer. Security here is not only about getting in, but also about what can get out unchecked.

Who can actually see the conversations?

Access management has the best ratio of effort to effect, and at the same time it is the measure that is worst arranged in small companies. The classic weak spot is the shared login: one account the whole team works with, with a password that was passed around in a group chat. As long as that is the case, you can never establish after an incident who saw what, and when someone leaves you cannot withdraw one person's access without disturbing everyone.

Four groups can reach the conversations, and you have to walk through all four separately.

• Your own people. Personal accounts, two-factor login, and rights per role. A holiday temp handling customer questions does not need an export button.
• The AI itself. This is the new question. A colleague looks up one customer; an AI assistant has a standing connection to everything you plug it into. Bound that: read-only where reading is enough, only the fields the answer needs, and no default access to folders or tables it can reach "just in case".
• People at the vendor. Support and admin staff at your vendor can almost always reach your data technically. That need not be a problem, but it should not be a surprise. Ask in writing who can do it, when they do it, and whether you can see it afterwards.
• Wherever escalations land. When the AI does not know, the conversation goes to a human. Those forwarded conversations end up in a shared mailbox, a chat group or a private phone. That is nearly always the worst-protected copy in the whole chain, and it is the one people systematically forget to assess.

Which measures fit AI in customer contact specifically?

The measures below are not legal requirements — as said, those do not exist. They are a translation of the risks that come with this way of working into something you can arrange on a Tuesday afternoon. Which of them belong in your case depends on your own assessment.

Measures and why they fit AI in customer contact

Measure	Why it fits here
Personal accounts with two-factor login	Without accounts that trace to a person you cannot establish afterwards who read or exported a conversation. That makes any investigation after an incident impossible.
Bounded read rights for the AI	The assistant searches faster and wider than a person. Whatever it can see, it can put into an answer — including to the wrong customer.
Separate knowledge source for internal documents	Purchase prices, staff arrangements and internal notes do not belong in the source the customer-facing assistant draws from, even if they sit in the same folder.
Version history on instructions and knowledge source	If the assistant suddenly says something else, you need to see who changed what and when. Without that a mistake cannot be rolled back or explained.
A cap on outgoing messages	A mistake in an automated system repeats itself within seconds. An hourly ceiling puts a roof on the damage before anyone notices.
An off switch anyone can operate	If only the vendor or one technical person can stop it, it keeps running through a weekend or a holiday.
Testing without real customer data	Trial setups and demos live longer than intended and are rarely secured as well as the real environment.
Securing the device that holds the connection	If the customer channel runs through a phone, that phone is part of your security. A handset without a screen lock is an open mailbox.
An agreed recovery path	A backup that has never been restored is an assumption. Knowing how you are running again within a day is part of the level you claim.

What should you log — and what should you not?

Logging is what makes the rest of your measures verifiable. Without a log you are left with "we think nobody could reach it". That is not evidence, and during an incident it is not a starting point either: you cannot then establish how many conversations were opened, by whom, and from when.

There are two kinds of logs and the distinction matters, because they pull in opposite directions. An activity log records who did what and when. A content log keeps what was said in the conversation. The first you want to grow deliberately, the second you want to shrink deliberately.

What belongs in an activity log for AI in customer contact:

• logins and failed login attempts, with time and account;
• exports and downloads of conversations — this is the action by which data leaves your system;
• changes to the assistant's instructions and to the knowledge source it draws from;
• connections that are added or switched on, including who did it;
• the number of messages sent per hour or per day, so that an outlier stands out.

What you do not want is for the full text of conversations to end up in a second system nobody manages. Many connectors send the whole message along to a debugging service or a monitoring tool by default. Switch that off or trim it back. Attachments, payment details and passwords a customer happens to type do not belong in a log at all.

Two things go with this and are easily forgotten. Log files are personal data themselves, so they need a retention period and restricted access just as much as the conversations do. And a log nobody reads only helps after the fact. Put at least one alert on it that reaches you by itself — for example a message when the number of outgoing messages passes the agreed ceiling.

Do you fall under NIS2, and how do you establish that?

A lot is being sold around NIS2 to companies that do not fall under it at all. The test is simpler than the marketing suggests. Article 2 of the NIS2 Directive sets two filters that both have to hold: your organisation is of a type listed in Annex I or II of the directive, and it qualifies as a medium-sized enterprise under the EU definition in Recommendation 2003/361/EC. The Dutch national cyber security centre summarises it the same way: sector and size together determine whether an organisation is in scope.

In the Netherlands the directive has been implemented in the Cyberbeveiligingswet, in force since 15 August 2026, replacing the earlier network and information systems act. An important detail: no letter arrives. The Dutch government states explicitly that organisations are themselves responsible for testing whether they fall under the act. So run that test actively, and record the outcome — including when the outcome is "no", because then you have something to point at.

If you are in scope, something substantial changes for your AI project. Article 21 of the Cyberbeveiligingswet imposes a duty of care: appropriate and proportionate technical, operational and organisational measures for the risks to the security of the network and information systems you use for your activities. That is broader than the GDPR. The GDPR looks at personal data; the duty of care looks at your systems and your service as a whole. A bought-in AI solution that runs your customer contact is such a system. You cannot keep it outside on the argument that it is only a tool.

And there is a third route by which these requirements reach small companies, more common than the statutory one: the contract. If you supply an organisation that is in scope, there is a good chance they will push their requirements down to you as a supplier. Then they apply to you not by law but by agreement — with the same practical effect, and usually with a tighter deadline.

What is yours and what is your vendor's?

The security duty in article 32 GDPR rests on both parties: on the one who decides what the data is used for, and on the party that supplies the system and processes the data on their behalf. Shared does not mean split here. When it goes wrong, the customer comes to you and the regulator comes to you. Having had a good vendor is a mitigating circumstance then, not an answer.

The division that works in practice looks roughly like this. Your vendor is up for the machinery underneath: encryption of connections and storage, updates, separation between customers, availability, and the conduct of their own staff. You are up for everything on your side: which data you put in, who gets an account and who keeps one after leaving, what the AI may reach, what it may send, and on which devices the channel stands open.

Between those two sits a grey zone that causes most of the trouble: settings the vendor supplies but you have to switch on. Retention periods, enforced two-factor login, limits on who may export, and whether or not your conversations are used to improve models. Default settings are chosen to make sign-up smooth, not to cover your risk. So walk through them one by one before you go live, not after.

Three things you want in writing before the start, and this goes beyond the standard contract you need anyway. Who at the vendor can look into the conversations and under what conditions. What happens to the conversations if you stop: do you get them out, and are they deleted afterwards. And how and how quickly they warn you when something goes wrong on their side — because you are the one who has to act after that, and without timely word from them you will not make your own deadlines. All three belong in the contract, not in a sales conversation.

What do you check in the week before go-live?

Setting security up is weeks of work; checking that it holds is an hour. Walk through these points and put a date and a name next to them, so you can show later that it happened.

1. Everyone with access is on a list with an account of their own. Nobody on it has left the company.
2. Two-factor login is on for every account, including yours and the external builder's.
3. You know which sources the assistant can read, and you looked at that list yourself instead of assuming it.
4. The assistant cannot change or delete anything where reading is enough.
5. There is a ceiling on outgoing messages, and an alert reaches you when it is hit.
6. Two people know how to stop the system, and it has been tried once.
7. The test environment no longer holds real customer data.
8. It is written down who to call at the vendor when something breaks, with a name and a time window.
9. You have recorded whether you fall under the Cyberbeveiligingswet, with the outcome and the date.

If there is a gap, that is not a reason to call the project off. It is a reason to start smaller. One channel instead of three, or a setup in which the AI only drafts and a person presses send. Starting narrow is itself a security measure: it keeps the damage small from exactly the things you do not know yet.

How do you keep it up once it is running?

A security level is not a state but maintenance. Two fixed moments are enough for a small business. In the first month you look at outgoing traffic weekly: not at the content of every conversation, but at its shape — how many messages, to how many unique people, at what times. That is where you spot a deviation first. And every quarter you go through the account list: people who left, temporary staff, the builder who finished three months ago and still holds admin rights.

And with every change you redo the assessment: an extra channel, a new connection to your administration, a change of vendor, or an assistant that may suddenly move appointments instead of only answering. If what the system can do or can reach changes, the risk changes — and the previous assessment no longer holds. If you are considering an extension with clearly more impact on people, check as well whether a separate assessment beforehand is needed; the law names the use of new technology explicitly as a trigger for that.

What all of this adds up to is not only less risk. It is also the only honest answer to the question a customer or a regulator will eventually ask: how did you know this was safe enough? There is no certificate that answers it for you. There is only an assessment you made, wrote down, and have kept up since.