Semantic Layer Consulting & Data Architecture in Amsterdam

Amsterdam's Data Stack Has an AI Problem Nobody Talks About Publicly

Amsterdam sits at the center of European tech. The city has produced some of the continent's most sophisticated scale-ups, a dense concentration of fintech and e-commerce companies, and a data engineering talent base that is genuinely world-class. Most of the companies I meet here have invested heavily in cloud infrastructure. Snowflake contracts, dbt pipelines, Fivetran syncs, Looker dashboards.

And yet when AI enters the picture, most of them hit the same wall.

The AI projects stall. The AI agents produce answers that are fast and confidently wrong. The business intelligence dashboards that everyone trusted suddenly show different numbers depending on who runs them. The data team is drowning in one-off data requests because no one trusts the self-service layer enough to actually self-serve.

This is not an AI problem. It is a data architecture problem. Specifically, it is a semantic layer problem that most Amsterdam companies have been deferring for two or three years because the BI dashboards were good enough and the pressure to ship AI came suddenly.

I started Unwind Data as an independent data architect Amsterdam companies can call before they buy the wrong tool, commission the wrong migration, or let a vendor-aligned consulting firm design an architecture that serves the vendor's product map rather than the client's actual stack. Being based here matters. The tool choices, the regulatory environment, and the scale-up growth patterns are specific to this market.

What a Data Architect Actually Does in 2026

The role has shifted significantly. A data architect used to be the person who drew the entity-relationship diagram and handed it to the engineering team. That version of the job still exists inside large enterprises with legacy on-premise infrastructure. But in the Amsterdam scale-up and enterprise ecosystem, a data architect in 2026 is doing something different.

The questions have changed. It used to be: how do we store and move this data? Now it is: how do we make this data trustworthy enough for AI to reason on? How do we define our business logic in a way that is consistent across every tool that touches it, including the AI agents we are deploying?

That shift puts the semantic layer at the center of modern data architecture. Not as a BI feature, but as governed infrastructure. The data architect's job is to ensure that "revenue" means the same thing in Looker as it does in the Python notebook, in the AI agent's query, and in the board report. When those definitions diverge, and they always diverge without explicit governance, the data foundation becomes a liability instead of an asset.

In practice, the work as a data architect Amsterdam-based clients commission covers four interconnected areas.

Stack assessment and architectural design. Understanding where your data actually lives, how it flows, what the transformation layer looks like, and where the semantic definitions are currently stored (usually fragmented across tools). This produces a clear picture of what you have and what the right architecture looks like for where you are going.

Semantic layer design and implementation. Building the actual semantic layer: metric definitions, dimension models, governance logic, access policies, and the tooling that fits your specific stack. This is where the architectural decision between dbt Semantic Layer, Snowflake Semantic Views, Cube, AtScale, or a BI-embedded approach gets made based on evidence rather than vendor preference.

Data governance integration. A semantic layer without governance is a definition library nobody enforces. The governance work covers ownership models, change-approval processes, data quality checks, and the documentation that keeps your data team from re-litigating metric definitions every quarter.

AI readiness validation. Testing whether your data infrastructure can actually support the AI use cases you are building toward. This means verifying that the semantic layer serves structured, governed context to LLMs and AI agents, that the business logic is machine-readable, and that the outputs your AI produces can be traced back to definitions your data team owns and can audit.

Why the Semantic Layer and Data Architecture Cannot Be Separated

Companies often come to me with one of two framing problems.

The first: "We need a semantic layer consultant to help us pick a tool and build the metric definitions." That framing is too narrow. The semantic layer does not exist in isolation. It sits on top of your transformation layer, which sits on top of your ingestion pipelines, which sits on top of your warehouse. If the transformation layer produces data that is inconsistent or ungoverned, the semantic layer will inherit those problems regardless of how good the tool is. The tool choice is rarely the bottleneck. The underlying data architecture is.

The second framing problem: "We need a data architect to redesign our stack." That framing is too broad. Redesigning everything takes too long and costs too much. The more useful question is: what is the minimum architectural work that gets your data to a state where you can trust it for AI and consistent BI? For most Amsterdam companies, the answer is some combination of semantic layer implementation and targeted data governance work, not a full warehouse migration.

I approach every engagement by starting at the semantic layer as the diagnostic point. Where your metrics disagree is where your architecture has the most acute problem. That disagreement tells you exactly what to fix and in what order.

The Amsterdam Market Context

Working in Amsterdam specifically matters for a few reasons that do not show up in a generic consultancy pitch.

The Dutch data engineering market has strong talent but thin specialist depth in semantic layers and AI data readiness. Data engineers here are excellent at pipelines and transformation. The semantic layer and AI readiness layer are newer disciplines, and the local talent pool that combines deep semantic layer experience with practical AI deployment knowledge is genuinely small. Most Amsterdam companies are either building this internally with engineers who are learning it in real time, or paying large international consultancies for generalist advice that does not reflect the local stack reality.

The Dutch regulatory environment also creates specific requirements. GDPR compliance in the data architecture is not optional, and it affects how semantic layers are designed, particularly around access controls, data lineage, and the auditability of AI-generated outputs. Having done expert briefings for Dutch government institutions on AI and data foundations, I understand how this regulatory context intersects with modern data architecture decisions in a way that a US-headquartered consultancy typically does not.

Amsterdam's scale-up ecosystem has also made specific tool bets. Snowflake is dominant here in a way that it is not in some other European markets. dbt is the transformation standard at most companies that have invested in modern data infrastructure. Looker has a strong installed base from the Google Cloud relationship. Those specific bets shape what the right semantic layer architecture looks like in this market, and an advisor who works in this ecosystem daily knows those constraints from direct implementation experience.

Who Unwind Data Works With

Unwind Data works with two types of organizations.

Scale-ups that have outgrown their early data infrastructure. You built dashboards that worked when the company was smaller. Now you have three BI tools, metric definitions that live in four different places, and an AI initiative that is producing outputs nobody trusts. The data team is spending more time resolving definitional disputes than building new capability. This is the moment to get the semantic layer right.

Enterprises that are deploying AI and discovering the data foundation is not ready. The model is fine. The infrastructure to give the model reliable, governed, consistent data is not. This is the most common failure mode we see in enterprise AI projects across the Netherlands, and it is almost always a semantic layer and data governance problem disguised as an AI problem.

Across both segments, the industries where this problem is most acute in Amsterdam are fintech, e-commerce, SaaS, and sustainability-adjacent companies operating under CSRD reporting requirements. Each of those industries has a specific version of the data architecture problem, and the semantic layer solution looks different in each context.

Independent Advisory vs. Vendor-Led Consulting

Every major semantic layer vendor has a consulting or professional services arm. Looker has implementation partners. dbt Labs has preferred implementation partners. Snowflake has a professional services team. Cube and AtScale have solutions engineering resources.

Those resources are often technically competent. But they are not independent. When a Snowflake professional services team evaluates your semantic layer options, Snowflake Semantic Views will be the answer. When a dbt preferred partner evaluates your stack, MetricFlow will be the answer. That is not because the other options are wrong. It is because the incentive structure of the engagement points in one direction.

Unwind Data has no vendor relationship, no referral agreement, and no product to sell. We have worked with production implementations of dbt Semantic Layer with MetricFlow, Snowflake Semantic Views, Cube, AtScale, and LookML. We know where each one breaks in practice, not just in the documentation. That knowledge is only available to someone who has built and maintained these implementations across multiple client environments without a vendor affiliation.

The honest version of semantic layer consulting often results in a recommendation not to buy a new tool at all. Many organizations already have the tooling they need. What they are missing is the architectural design that makes the tooling they already pay for actually govern their business logic. That recommendation is very difficult to make if your revenue depends on selling software licenses.

What an Engagement Looks Like

Most engagements start with a diagnostic. Before writing a single metric definition, we need to understand your stack, your current state, and where the most painful definitional conflicts exist. This is typically a focused session of two to three weeks that produces a clear architectural recommendation: what to build, in what tool, in what sequence, and what the governance model looks like when the build is done.

For organizations that need a semantic layer built from scratch on an existing warehouse, implementation runs four to eight weeks depending on the number of core metrics and the complexity of the underlying data model. We certify the fifteen to forty metrics that drive decisions first. Less critical metrics follow once the foundation and the governance process are in place.

For organizations migrating an existing semantic layer, the timeline depends on the state of what you are migrating from. A LookML implementation that has been maintained carefully is a very different starting point than a BI-embedded semantic layer that was never designed to be portable.

All engagements include knowledge transfer. The goal is not to create dependency on external consulting. The goal is for your data team to own, maintain, and extend the semantic layer without us when the engagement closes. That means documentation, internal training, and architectural decisions that your analytics engineers can reason about independently.

The Conversation Worth Having

If your AI initiatives are stalling on data quality and consistency problems, the bottleneck is almost certainly the data architecture underneath the model. Specifically, the absence of a governed semantic layer that gives your AI systems a reliable, consistent, machine-readable version of your business logic.

Getting that layer right is not a vendor procurement decision. It is an architectural decision that requires understanding your stack, your team, your regulatory context, and your business objectives. If you are looking for a data architect Amsterdam-based or elsewhere in the Netherlands, or if you need a vendor-neutral semantic layer consultant who has built production implementations across the tools your team is already running, that is the conversation Unwind Data is built for.

There is no sales process. No RFP requirement. No initial meeting with an account executive before you talk to the person doing the work. Just a direct conversation about your stack and what the right next step looks like.

Reach out at wesley@unwinddata.com or connect on LinkedIn.