AI Implementation for Dutch SMEs: A Practical Roadmap

Most Dutch SMEs we talk to already use AI somewhere in the business, usually before anyone officially decided to. Someone drafts a reply in a chatbot on their own laptop, someone else summarises a long supplier contract with a free tool nobody signed off on. That's AI adoption, and it happens on its own. AI implementation is a different thing: deciding that one specific process will run on AI on purpose, getting the data that process depends on into a usable state, choosing whether to buy a ready-made tool or build something, and putting rules around it before it ever touches a customer's data. This guide covers that second part — the part that turns scattered tool use into something the business can actually rely on and account for.

Start With One Process, Not an "AI Strategy"

The projects that stall are the ones that start with a goal like "we should do something with AI" and no fixed scope. Six months in, there's a pilot nobody uses, a vendor contract nobody remembers signing, and no way to say whether any of it worked.

The projects that go somewhere start narrower: one process, with a clear before-and-after, where a mistake is recoverable rather than a legal or reputational problem. Good first candidates tend to share three traits: they happen often enough that automating them is worth the setup effort, the inputs are fairly consistent, and a human can still check the output before it goes anywhere important. Drafting first-line replies to routine support questions, extracting line items from supplier invoices, or summarising internal meeting notes all fit that pattern. A first customer-facing legal document, or anything that decides who gets paid, does not — not yet.

If you already know which process you want to automate, our guide to automating business processes covers the broader catalogue of what SMEs automate and with which tools, AI or otherwise; our walkthrough of automating invoice processing is a concrete example of exactly this kind of first project done well.

Get the Data Right Before You Pick the Tool

An AI tool is only as good as what it's given to work with, and this is where most implementation timelines actually slip. Supplier names spelled three different ways across your systems, invoices filed as scanned images with no consistent structure, customer records split across a CRM and a spreadsheet that disagree with each other — none of that is a problem until you try to point an AI tool at it, at which point it becomes the whole project.

Before you evaluate a single vendor, it's worth an honest look at the data the chosen process actually touches: is it in one place or scattered across systems that don't talk to each other, is it structured consistently enough for a tool to parse reliably, and who currently owns keeping it clean. Our Data & Databases team does exactly this kind of readiness work, often before an AI project starts rather than during it, which is the cheaper time to do it.

Off-the-Shelf, Configured, or Custom: What You're Actually Buying

"We're implementing AI" can mean three very different purchases, and conflating them is how budgets get blown.

An off-the-shelf feature already inside tools you use. If your email, office suite or helpdesk platform already has an AI feature built in, turning it on and training people to use it well is usually the cheapest and fastest option, and the right starting point for a well-defined, common task.

A configured tool, built on a vendor's platform but shaped around your business. A chatbot trained on your own product information, or a document-processing tool configured for your specific invoice layouts, sits here. Our guide on what a chatbot actually costs to build breaks down this middle tier specifically: real price bands and what drives them.

A custom-built system, tied into your own data and workflows. This is the right tier when no vendor tool fits the process closely enough, or when the process is specific enough to how your business actually works that forcing it into a generic tool would cost more in workarounds than building it properly. Our guide to custom software development costs and our AI & Automation team cover this end of the range.

Most SME AI projects should start at the first or second tier. Jumping straight to custom because a demo looked impressive is one of the more expensive mistakes we see.

When Your AI Tool Touches Personal Data, the AVG Applies

The moment an AI tool processes customer data, employee data, or anything else covered by the AVG (the Dutch GDPR), this stops being a purely technical decision.

Under the GDPR, if a vendor's tool factually carries out the processing on your instructions — summarising support tickets that contain customer names, for instance — your business is the *controller* and the vendor is a *processor*, and Article 28 of the GDPR requires a written processing agreement between the two before that processing starts. Without one, the Autoriteit Persoonsgegevens (the Dutch data protection authority) treats both sides as in breach, not just the one who should have asked. That agreement needs to cover the actual processing assignment, what the vendor is and isn't allowed to do with the data, the security measures it commits to, and what happens to the data once you stop using the tool.

Breach notification works a specific way here too: if the vendor has an incident involving your data, it has to tell you about it as soon as possible, but it may only report that breach to the Autoriteit Persoonsgegevens itself if you've explicitly authorised it to. The responsibility for reporting within the legal deadline stays yours, even when the incident happened on the vendor's infrastructure — which is exactly why the processing agreement should spell out how and how fast the vendor notifies you, not leave it implied.

None of this is a reason to avoid AI tools that touch personal data. It's a reason to ask for the processing agreement as part of the proposal, before anyone starts feeding real customer records into the tool, not after.

Write the AI Policy Before Anyone Uses the Tool

A written AI policy isn't a legal requirement in itself, but it's the document that turns "please be careful with AI" into something staff can actually follow, and it's the first thing worth having in place, even for a one-tool pilot.

A policy worth having answers a short list of concrete questions: what AI use is actually for at your company; who it applies to (all staff, specific roles, freelancers too); which AI tools are approved, kept as a list that's reviewed regularly rather than left to assumption; what may never go into an AI tool — personal data, trade secrets, or sensitive customer information, especially in tools that haven't been checked against the AVG; who checks AI-generated output before it's used for anything that matters, since even capable tools still get things wrong with confidence; and who's responsible when something does go wrong.

Two of those questions are no longer just good practice. Since 2 February 2025, a number of AI systems and practices are prohibited outright under the EU AI Act — the Act specifically bans certain uses regardless of company size. And as of that same date, any organisation that develops or uses AI systems has to ensure the people operating them have a basic working understanding of how the systems work and what their limits are — an "AI literacy" obligation the Act now imposes directly, not a recommendation. A written policy, kept current and actually read by new hires, is the practical way most SMEs meet that second obligation without turning it into its own compliance project. If you need the fuller picture of how the AI Act's risk categories apply to a specific system you're deploying, our guide to EU AI Act compliance covers that in more depth; this guide stays focused on the implementation decisions themselves.

Pilot Before You Scale

Once the process, the tool tier and the policy are settled, resist running the first version everywhere at once. A pilot with one team, a fixed time window of a few weeks, and one or two numbers you actually check at the end — time saved, error rate, how many people kept using it once the novelty wore off — tells you more in a month than a company-wide rollout tells you in a quarter, because you can still see what's actually happening.

Keep a human reviewing the output during the pilot, even for a task that seems low-risk. The point of the pilot isn't just to prove the tool works; it's to find out what it gets wrong, before that happens at scale.

What Usually Goes Wrong

A few patterns account for most AI implementations that stall or quietly cause damage:

• Shadow AI predates the project. By the time anyone decides "we're implementing AI properly," staff have usually already been pasting business information into consumer AI tools for months. The policy work above is just as urgent for that reason, regardless of how far along the formal pilot is.
• Nobody owns it. Implementation lands on whoever was enthusiastic enough to push for it, and momentum dies the moment that person gets pulled onto something else.
• Nothing gets measured, so nothing gets decided. Without a before-and-after number, a pilot either runs forever on inertia or gets quietly dropped, and either way nobody can say whether it was worth the effort.
• Tool sprawl. Buying a tool before the process it's meant to solve is clearly defined leads to three overlapping subscriptions, each used for a sliver of what it was bought for.

FAQ

Do we need a written AI policy if we only use one AI tool? Yes. Risk starts with the first tool, not the tenth, and a policy is far easier to write before multiple tools and habits are already in place than to retrofit afterward.

Is AI implementation mainly a technical project or an organisational one? Mostly organisational. Choosing the right tool tier matters, but the harder parts — picking the right first process, getting the data ready, writing the policy, and deciding who owns the result — are decisions, not code.

Do we need a processing agreement for every AI tool we use? Only for tools that actually process personal data on your instructions, which makes the vendor a processor under the AVG. A tool that never sees customer or employee data doesn't trigger this, but check that assumption before you rely on it, not after.

How long should a pilot run before we decide to scale it? Long enough to see past the novelty effect, typically a few weeks to a couple of months, with a fixed end date set in advance so the decision doesn't drift indefinitely.

What's the difference between this guide and your guide to automating business processes? That guide is the catalogue: which processes SMEs automate and with which tools, AI or not. This one is about the decisions specific to adopting AI responsibly — the data, the vendor tier, the AVG obligations and the policy — once you've already picked AI as the approach.

Implementation Is a Project, Not a Subscription

An AI tool that actually earns its keep is the result of a sequence of decisions made in the right order: one process, clean enough data, the right tier of tool, a processing agreement where personal data is involved, a policy staff actually read, and a pilot small enough to learn from. Our AI & Automation team scopes and builds this end to end, our Cybersecurity & Identity team can review the access and data-protection side of a specific tool before it goes live, and our Data & Databases team handles the readiness work most implementations skip until it becomes a problem.