AI Platform Engineering at Bol

A look behind the scenes at how Luca Camphuisen is helping build the AI infrastructure that keeps one of the Benelux's largest e-commerce platforms moving forward.

 I started at Bol as an AI Platform Engineer in December of 2025. Before that I was a software engineer who also did a lot of cloud work on Google Cloud, using infrastructure as code to manage things.

Bol is one of the largest e-commerce platforms in the Netherlands and Belgium, and behind the webshop there are a lot of engineers building stuff. I'm part of the AI/ML Ecosystem team which falls under Bol's technical platform. Our goal is to provide sane defaults and services for everything around Agentic AI and MLOps. So our customers are the developers, data scientists, and machine learning engineers at Bol

The first question I usually get is: what is platform engineering, and what's the difference with the DevOps term you hear everywhere?

In my opinion the two are closely related. People often describe DevOps as "you build it, you run it", meaning the team that writes an application is also responsible for deploying and running it. That's fine for small deployments, but in a larger enterprise it will cause a headache. We do not want developers to need to manage VPCs, firewalls, etc.

So my job as a platform engineer is to make deploying and running applications easy. We do that by providing sane defaults for the hard, repetitive things like security, networking, compute, and in my case AI. We do not want every team to reinvent the wheel.

As platform engineers we need to take on the Agentic challenge from first-principles. These workloads are still just computer programs running on servers somewhere in a datacenter. It's not magic. They still require compute, storage, and networking.

A few things that make (agentic) AI special:

• Agents aren't deterministic.  Normal software gives you the same output for the same input. A language model doesn't. That breaks a lot of the assumptions we usually have about testing, monitoring, and "is this thing working correctly?".

• The ecosystem moves insanely fast.  A tool that's the standard today can be irrelevant in six months. You can't bet the whole platform on a single tool and hope it sticks around.

• The resources are different.  You're suddenly dealing with GPUs, models, and tokens. You now have to consider GPU scarcity, increasing token costs, scheduling ML jobs.

• Security gets a new dimension.  With AI you also have to think about what data goes into a model and what comes back out. We need to assume that an agent can go rogue. Identity becomes very important.

• Agents act on their own.  With agentic AI, the software takes actions by itself. That makes it really important to be able to see what an agent is actually doing. OpenTelemetry plays a big role here.

We're taking all of this complexity and turning it into something a data scientist or developer can just use.

A large part of the job is building what we call a golden path: the easy, paved way to do something the right way.

When that golden path comes with sane defaults and pre-approved security, teams can move fast. They don't have to go to legal and IT security for every new feature or application. It would be insane if every developer building a web app needed legal approval before they could start. You approve it once, and everyone after that can just build.

For AI, sane defaults mean things like:

• Reusable frameworks to make compliance easier (prompt & response logging, anonymisation, etc.)

• A safe, approved way to use models, so teams don't each wire up their own

• A centralised LLM Observability platform

At Bol we already have good paved roads for normal software such as frameworks for Spring Boot and Python, and a great way to deploy cloud infrastructure such as CloudSQL and GCS. The tricky part is that there isn't really a golden path for building AI applications yet. So I get to help create one, using first principles and reusing the platform features we already have.

In the software engineering world there's a saying: "premature optimisation is bad". It comes down to this: don't try to optimise your code for the future, because you can't predict the future and you'll only hurt the codebase.

The same counts for platform engineering, and it counts double for AI. AI changes fast. What's best practice this month might be outdated next month. So we stay lean. We keep the architecture simple so we can handle those rapid changes instead of being stuck with yesterday's assumptions.

Because this is a greenfield project and a young team, we're still getting started with deploying various services for our engineers at Bol. There are a lot of open questions, which makes it a great place to be right now.

We operate an agentic observability platform, so teams can actually see what their AI agents are doing under the hood: which tools got called, what the model reasoned, where it got stuck. Paired with that, we're rolling out a prompt management system that lets teams version their prompts and run evals (evaluations) against them. That combination is what actually matters: instead of tweaking a prompt and hoping it's better, a team can run an eval, look at the numbers, and know whether a change actually improved things. That turns prompt tuning from guesswork into something data-driven, which is exactly the kind of capability we don't want every team rebuilding on their own.

A few other things we're working towards, and what we expect them to unlock:

• A centralised MLOps platform  for experimenting, training, deploying, and managing machine learning models, so teams can go from experiment to production without each building their own deployment pipeline.

• Custom Kubernetes work  such as developing controllers, deploying operators, and hardening security, so teams get a platform that just works instead of each reinventing cluster setup and access control.

• Google Cloud work  such as ensuring data retention stays within the EU, enabling access to approved models, and configuring logging sinks and buckets, so compliance and infrastructure setup gets handled once instead of per team.

• Writing Architecture Decision Records (ADRs), so decisions don't just live in someone's head. The next engineer or team can see why we chose something instead of re-litigating it later.

The idea behind all of it is the same: take something every team would otherwise have to figure out alone, and turn it into a default they can rely on. It's important to stay aligned with teams so we don't build something unusable for them. We're building the golden path together with the first few teams implementing various AI use cases.

AI moves fast, and the teams building with it shouldn't have to build the road underneath them every time. That's what my job comes down to: giving the developers, data scientists, and machine learning engineers at Bol a golden path, so they can focus on their ideas instead of the plumbing.

We keep that path lean on purpose, because the field changes too quickly to over-engineer for a future we can't predict. And getting to build it from scratch is what makes this job fun.

That said, it's not all smooth sailing. One of the harder parts of the job is that whatever we build has real impact on other teams, whether they asked for it or not. Sometimes a team is convinced they've found the best way to do something, and it's on us to explain, with actual arguments, why that isn't the case, or to admit they're right and change course. Either way, that only works if you can reason from first principles instead of falling back on "this is how we've always done it." On top of that there's a constant stream of alignment: networking, SecOps, legal, cloud provisioning, cloud compute, and plenty of teams I haven't even mentioned. The golden path only holds up if all of those pieces agree on it.

Then there's the noise. The AI world produces something new to look at almost every day, and most of it won't matter in six months. Part of the job is filtering that out: figuring out what's hype, what's a real shift, and what's actually worth building a default around, instead of chasing whatever's trending this week.

That's the job in a nutshell: build a lean, fast-moving golden path, defend it when it matters, tune out the noise, and get the rest of the organisation to agree it's worth building at all. Doing that with basically a blank sheet of paper is what makes it fun.