How Can Dutch SMEs Build an Internal AI Team?

An internal AI team gives a business people who can decide where AI belongs, check whether it works and keep improving it as processes change. For a Dutch SME, that can begin with existing employees and specialist support rather than a new department. The first task is to make those responsibilities clear and give the people involved time to develop them.

The challenge is fitting that learning into an established business. Employees already have work to deliver, information sits across existing systems, and changing one task can create more review elsewhere. A useful starting point is one recurring workflow with an accountable owner, a measurable result and a plan for who will maintain it.

Why does internal AI capability matter for Dutch SMEs?

It matters because access to AI is moving faster than experience with it. CBS's provisional 2025 figures show AI use among 27% of Dutch businesses with 10–49 people and 45% of those with 50–249. Among businesses that considered AI but did not adopt it, 73% cited lack of experience. That last figure concerns a specific group of nonadopters, but it makes the practical learning gap very clear. CBS, December 2025

That distinction matters when planning an AI team: tool access, practical experience and implementation skills are different capabilities. Employees need to recognise useful opportunities, explain the relevant business rules and evaluate the results. Technical colleagues need enough of that context to build a reliable workflow. An adoption plan should connect those responsibilities as well as provide tools.

There is also a longer-term ownership problem. Gartner predicts that by 2028, 70% of enterprises will abandon agentic AI built through vendor forward-deployed engineering, citing costs and inability to evolve the systems independently. That is an enterprise forecast, not a Dutch SME failure rate. The relevant lesson is to agree on knowledge transfer, shared ownership and transition from the beginning. Gartner, September 2026

Who should be in our internal AI team?

Start with people who understand the work and can take responsibility for changing it. You need a business owner who can make decisions, a workflow owner who knows the real cases, and someone who understands the technical setup. Those responsibilities can sit with existing employees and an external specialist. The amount of ongoing work will tell you whether dedicated roles make sense.

Before hiring, map the capability already available inside the company. Process owners may understand exceptions that a new engineer would miss, while existing technical staff may already maintain useful automations. Look for people who can explain the work, challenge an answer and make time to practise. Pair them with the technical expertise they need, and appoint a backup so ordinary operation does not depend on one colleague.

What should we build first?

Choose one recurring workflow with a clear owner, available information and a result you can check. A useful starting question is: where does the team repeatedly gather context, move information, prepare something or check it? Reporting, document handling and internal knowledge search can be good candidates. These are examples to investigate, rather than a universal list of the best investments.

Starting point	What the team learns	Evidence of improvement
Recurring reporting	Shared definitions, traceability and review	Less total effort, fewer corrections
Document intake	Required information and exceptions	Faster completed cases, less rework
Internal knowledge search	Source quality, permissions and maintenance	More verified answers, less searching

The learning should happen inside work people already understand. That gives them a reason to question the output, explain what is missing and suggest a better approach. It also exposes the difference between a nice demo and something they would use next week. We explore that further in how to get your team to actually use AI.

Why does our AI team seem so slow?

Because building is only part of the job, and AI makes that part look deceptively fast. The team still needs to understand the information, agree on rules, get access, test unusual cases and help colleagues absorb the change. In an established business, that happens while everyone continues doing their normal work. Generating more software does not create more time for those decisions.

In one Aibl.to engagement, a client asked for a slower delivery pace so its team could understand decisions and test what was being built. The system was already in the client's environment; the remaining gap was practical understanding. This illustrates why learning and handover need their own place in the delivery plan. Infrastructure ownership alone does not establish the ability to operate and change a system.

Still, necessary learning should be visible. Ask what changed, what was tested, what is blocked and what decision is needed next. A team resolving a difficult access issue is making different progress from a team trying another model without a clear reason. Leadership needs to understand that difference, and the team needs to explain it without hiding behind technical vocabulary.

How do we know whether the team is delivering value?

Measure whether the whole workflow improved, including the work created around the AI output. Faster preparation helps little if review and correction consume the time saved. Track cycle time, quality, human effort and operating cost against the original process. Then check whether the result is actually being used; our AI productivity article goes deeper into those measures.

A useful working rhythm is to agree on the outcome together, use AI for execution, review the result and improve the system based on recurring problems. That final step helps distinguish a maintained workflow from repeated manual clean-up. If the same error returns, investigate the underlying instructions, information or checks. Include that improvement work in the team's responsibilities.

There is a second result to measure: can the internal owners explain the system, make an ordinary change and recognise when an answer needs checking? A practical handover exercise is to have them demonstrate those tasks to the implementation partner. This makes gaps visible before support is reduced. A successful demonstration by the builder does not establish that the receiving team is ready.

Where does an external AI partner add value?

An external partner can supply specialist experience and implementation capacity while internal staff retain responsibility for the business outcome. Joint building is useful where employees have time to participate. Where capacity is limited, the partner can handle heavier implementation while internal owners stay involved in design decisions, testing and operation. Agree which responsibilities will transfer and how readiness will be demonstrated.

Technical judgment also matters as new tools appear. Assess whether a change improves the selected workflow enough to justify migration, testing and disruption. A promising model or tool does not automatically belong in an existing production system. The internal team needs a way to evaluate those choices alongside its implementation skills.

The handover should include practice, not just documentation. Have the owner run the workflow, change a routine rule, check the result and work through a recoverable problem. Outside support can remain useful afterwards. The question is whether you are choosing that support because it adds value, or calling the original builder because nobody else understands the setup.

What should we put in place before starting?

Put time, access and a few clear decisions in place before asking people to build. Agree which tools and information can be used, who checks the output and who handles questions or incidents. KVK's practical AI-policy guidance covers these responsibilities for Dutch businesses. Clear working agreements give people a basis for experimenting without guessing what is allowed. KVK

For additional support, RVO lists the Netherlands' regional European Digital Innovation Hubs. Their services include testing facilities, skills development and help accessing financing, with offers and eligibility varying by programme. That is a concrete Dutch route to explore alongside implementation support. You can find the regional contacts through RVO's EDIH overview.

The next step is to select one workflow, name its internal owners and agree on both the business result and the capability they should gain. At Aibl.to, this is how implementation and applied learning come together: work on the actual system with the team and transfer the know-how needed to maintain and improve it. A workflow discussion can help clarify those responsibilities before committing to a larger build. The scope should account for who will run the system, change it and evaluate its results after delivery.