A guided programme for mid-market and enterprise organisations that want to embed AI structurally — not a one-off workshop, nor a strategy deck without follow-through. From use-case discovery through strategy and pilot to production, governance and scaling, with a senior Dutch team that takes responsibility for both the technical and organisational side.
An AI implementation programme is a guided programme in which an organisation works from use-case discovery, through a controlled pilot, towards a production-ready AI application that is run by internal teams, and then scaled further. It is broader than an implementation training and deeper than a strategy engagement. Within a programme, we also deliver the build, the governance set-up, the change support and the handover, so that AI doesn't fade away as a pilot but takes root as a capability within your organisation.
Organisations usually get stuck in two places. The first is after the initial enthusiastic demo: there's a ChatGPT integration or a first agent, it looks impressive in a slide deck, but nobody dares to show it to customers. The legal questions haven't been answered, the data foundation is shaky, the evaluation suite is missing, and the team that built it can't maintain it. The second is six months later: three or four pilots scattered across the organisation, nobody is in charge, costs are rising without clear returns, and the board asks for a coherent AI strategy that nobody can answer well.
An implementation programme addresses both of these turning points. We make sure a first use case actually reaches production, with an honest risk analysis, a workable governance layer and a maintainable architecture. And we make sure the second and third use cases then go faster, by reusing the same patterns, gateway, evaluation infrastructure and compliance approach. The programme is designed to make your organisation steadily more self-sufficient: for pilot one we work hands-on alongside you, for pilot two you take the lead, and by pilot three we are optional.
The content is vendor-neutral. We work with Anthropic, OpenAI, Google Gemini, Mistral, Cohere, and on-premise options such as Llama 3 and Qwen via Azure OpenAI, AWS Bedrock or Google Vertex AI. Which combination makes sense for you depends on data classification, latency, cost and existing cloud commitments, not on what we happen to sell, because we don't sell licences.
An implementation programme is intended for organisations that want to develop AI as a structural capability rather than an experiment. We most often work with the following profiles.
You have a first working AI prototype running, but the step to production is blocked by the data foundation, legal questions or a team that can't carry it. You want to take the leap into serious AI without building an AI platform team yourself.
You see pilots emerging in different business units without a coherent strategy or architecture. You want one direction: a shared gateway, shared evaluation, shared governance, with room for sector-specific use cases. For this scale we also work in an enterprise programme with tailored governance.
You operate in a sector where the EU AI Act, DORA, NEN 7510 or sector-specific regulation is not optional. You need a programme in which compliance isn't bolted on at the end, but is designed in at every phase.
Your product has AI features on the roadmap (assistant, search, agent, summarising, classifying). You want to deliver those features without vendor lock-in, and you need an architecture that scales with growing usage and costs.
AI is one track within a broader transformation programme (post-merger, datafication, customer experience). You need a partner who can speak with the programme manager about phasing and dependencies, not only about models.
This isn't the right choice if you only need a demo, or if you're looking for a vendor to deliver a ChatGPT wrapper without a governance layer. Other partners are better suited for that. We only come into the picture once the organisation wants to embed AI seriously.
No report, no Miro board, no slide deck full of good intentions. What remains after the engagement is working, embraced and maintainable, and maintained by your own people.
By the end of the first cycle, at least one use case is running in production: monitored, with an evaluation suite, a token and cost dashboard, a rollback plan, and a team that can maintain it independently. Not a prototype stuck in a staging environment.
A shared LLM gateway, RAG pattern, evaluation framework and observability stack that make the second and third use cases faster and cheaper to deliver. Not ten separate integrations, but one layer on which new use cases build, in line with the AI development approach you choose.
Workable governance: use-case classification under the AI Act, DPIA linkage, model cards, audit log, escalation paths and roles for business, IT, legal and risk. Not as a policy document, but as infrastructure in which new use cases automatically receive their classification.
Eleven phases across four tracks that run in parallel (strategy, build, governance and change). We adjust the sequence and emphasis to your starting point: an organisation with an existing pilot starts somewhere different from one that has not yet done anything.
We map where AI can add value in your organisation: which processes rely heavily on unstructured text, images or decisions, which data sources are available, and where the pain points are that can be measurably reduced with the right application. This produces a scored list of use cases, not twenty, but the three to five where the low-hanging fruit is, without making risk classification unwieldy.
We look at what your organisation can already do: data platform, cloud, security, MLOps, AI literacy, legal capacity. That determines where the engagement needs extra emphasis. An organisation without a central data lake has a different starting point from one that already runs everything on Databricks or Snowflake. A team without experience of evaluations needs a different ramp-up from a team that already uses them.
This is where the strategic side comes in: what ambition your organisation has for AI, which position you choose (cost reduction, product innovation, customer experience, or a combination), and how that translates into a multi-year roadmap with phased investments. Not an 80-page deck, but one working document that fits in the board meeting. If you only need the strategy phase, we also offer a standalone AI strategy approach.
For the chosen first use case, we design the pilot including the three elements that are often missing: an honest success criterion (a measurable improvement over the existing process, not "it works impressively"), an honest failure protocol (when we stop, and what we do next), and a built-in kill switch (what we do if the model misbehaves in production). A pilot may fail; failure mode is built in.
Alongside the pilot, we set up the governance layer. Every use case receives its AI Act classification (prohibited, high-risk, limited risk, minimal risk), and every high-risk use case meets the Article 9–15 obligations (risk management system, data governance, technical documentation, logging, transparency, human oversight, robustness). For your teams we set up Article 4 AI literacy as the law requires — not as a tick-box course, but as an ongoing capability. We link to GDPR and DORA where relevant.
For the chosen use case, we determine the stack: which model family suits latency, quality and cost; which RAG pattern fits your data; which gateway for model routing and cost control; which evaluation infrastructure; and which observability. We always build in a fallback path so that you are not locked into a single vendor. For clients who want to go deeper on this without building straight away, we also offer a standalone vendor and architecture review.
Many pilots stall not on the model but on the data. Together with your data team, we lay the foundations: which sources are made available, what classification they receive (public, internal, confidential, personal data), which retrieval strategy fits, and how quality is monitored. No project where data engineers join halfway through; they sit at the table from pilot design onwards.
The pilot is being built. We work in short iterations with a cross-section at the table: AI engineer, software engineer, data engineer, product owner, a user from the work process and, where relevant, a privacy officer. Not an 'AI team' separate from the rest of the organisation — it is precisely that connection that makes the solution land. For interim technical leadership we deploy our interim AI tech lead.
A working model is not an adopted model. We work on the adoption side: who the first users are, which work processes change, what training is needed (where relevant, we draw on our AI business training), which metrics you measure for satisfaction and quality, and which escalation paths exist if a user sees something they do not trust. Change is not a chapter in a launch deck; it runs in parallel with the build.
The use case goes live. Phased: first a small group, then wider, with measurement points for quality and cost at every level. We set up observability (model, prompt version, latency, tokens, evaluation score), cost dashboards, alerts for quality regressions, and a runbook for the managing team. The handover to your people is built into this phase.
After go-live, we remain available for the initial period in which the application needs to settle into the work process. After that, the second and third use cases follow on the platform layer we have built, faster and cheaper because the foundation is already in place. Some clients continue independently from this point; others keep working with us on several use cases in parallel.
Which combination you choose depends on data classification, latency, cost and existing cloud commitments. We never work with a pre-selected stack; the choice is made in phase 06 based on your starting position. Below are the families we weigh as standard.
For general-purpose use cases where you want the sharpest model for reasoning, code or complex agent work. Higher price per token, higher quality per call.
For classification, embeddings or summarisation at volumes where token costs add up. Often a second layer beneath a frontier model, or used for specific tasks in the pipeline.
For sectors where data may not leave via an external API, or where cloud control is a hard requirement. Often run through your existing hyperscaler contract so that data stays within your data processing agreement.
Since 2026 much of the AI Act has been enforceable. Organisations that have not yet classified their applications run a compliance risk, and miss the chance to adapt their architecture to that classification before production pressure makes it difficult. We therefore do not treat the AI Act as a closing legal check, but as an overlay across the entire phasing.
In phase 01 (discovery), every candidate use case immediately receives a provisional risk classification. Use cases in the prohibited category (Art. 5) — social scoring, real-time biometric identification in public spaces, manipulation of vulnerable groups — are taken off the table straight away. Use cases with high-risk potential (Annex III: critical infrastructure, admission to education, HR selection, credit assessment, law enforcement) receive extra attention early on, because the requirements are heavy.
In phase 02 (capability assessment), we look at Art. 4: AI literacy. The law requires providers and deployers to ensure that their staff have "a sufficient level of AI literacy" — not a one-off course but an ongoing capability. For broad teams we often work with an AI business training as the base layer, with deeper modules for people working with high-risk systems.
In phase 05 (governance), for high-risk systems we build in the Art. 9–15 obligations: a working risk management system (Art. 9), data governance (Art. 10), technical documentation that stays current (Art. 11), automatic logging (Art. 12), transparency towards deployers (Art. 13), human oversight (Art. 14), and demonstrable accuracy, robustness and cybersecurity (Art. 15). Not a loose documentation exercise — infrastructure within the stack we build.
In phases 10 and 11 we set up post-market monitoring as the AI Act requires for high-risk systems, including incident reporting and tracking performance over time. Where relevant we link to your DORA and GDPR programmes so that compliance becomes one coherent chain rather than three separate audits.
The Dutch AI market is crowded: strategy agencies, Big Four consultants, vendor implementation partners, freelance prompt engineers. We do not fit into any of those boxes, and that is deliberate.
We do not sell licences from Anthropic, OpenAI, Google, Mistral or any hyperscaler. Our recommendation for your stack is therefore based solely on what fits, not on a commercial incentive. The same applies to build-vs-buy-vs-partner: if a SaaS product covers your use case, we will say so.
We do not hand over a report and walk away. We build alongside you, set up governance, manage change and stay involved until it works and your team can carry it. Building without a strategic foundation is how organisations end up with four loose pilots.
The people working on your project have hands-on experience with AI systems in production, not external consultants who only know the material. For each engagement we assemble the team based on your context: AI engineer, software engineer, data engineer, implementation lead and, where needed, a compliance specialist.
Handover to your team is built into every phase, not a handover weekend at the end. We document patterns, write runbooks, run knowledge-transfer sessions and do not build black boxes. After the engagement you can carry on without us; that is the test.
An engagement does not finish with a presentation but with a set of working artefacts your organisation can keep using. Below is what is delivered as standard.
Before we start, we look at which AI initiatives are already underway, which teams are involved and which compliance and data requirements apply. This leads to a scope and a quote that is transparently built up by phase.
Four tracks run in parallel (strategy, build, governance, change), each with a fixed working group and shared sync moments. We are on your premises one or two days a week; the rest is remote.
Once the first use case is in production, you face a choice: carry on alone with the second use case on the platform layer, or continue with us. Both are possible; we do not impose vendor lock-in.
An introductory conversation in which we go through which AI initiatives are currently under way, which phases should carry the most weight for your situation, and how your existing IT, data and compliance landscape fits in. No obligation; after the conversation we send an outline with phases, scope and a transparent cost structure.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
