Serhii LypiiEen prompt bibliotheek opbouwen in het mkb mislukt zelden door slechte prompts. Het mislukt omdat iemand een Notion-pagina aanmaakt met 80 prompts, er drie maanden niets verandert en niemand meer weet welke versie ergens draait. De prompts zelf zijn dan vaak nog prima.
Het probleem zit in het meta-systeem. Wie schrijft, wie keurt af, wie haalt eruit, wat doe je als OpenAI of Anthropic een nieuwe modelversie uitbrengt. Zonder antwoord op die vragen wordt elke bibliotheek binnen een halfjaar een archief van prompts die niemand meer durft te gebruiken.
In dit artikel zet ik op een rij hoe je dat voorkomt: vijf velden per prompt, drie opslag-opties, en de minimale rolverdeling die in een mkb-team van vijf werkt.
Waarom een prompt bibliotheek opbouwen in het mkb meestal mislukt
Drie patronen die ik bij klanten zie terugkomen.
Lijst zonder eigenaar. Een gedeelde Notion-pagina waar iedereen prompts in plakt. Geen eigenaar per prompt, geen review-moment. Na drie maanden weet niemand meer welke prompt actueel is.
Tools zonder context. Een team koopt een prompt-management-tool (PromptLayer, Helicone, Langfuse) voordat duidelijk is wat ze willen managen. Het abonnement loopt, niemand logt nog in.
Prompts zonder modelvermelding. Een prompt die in maart op GPT-4o prima werkte, geeft in juli op GPT-5 opeens vreemde uitvoer. Wie nergens noteert welk model de basis was, kan dat niet eens reproduceren.
De gemene deler: mensen denken dat de prompts het probleem zijn. In de praktijk is het systeem rondom de prompts het probleem.
Wat een bibliotheek écht is: vijf velden per prompt
Een werkbare bibliotheek heeft minimaal vijf velden per prompt. Niet meer, maar ook niet minder.
Doel. Eén zin. “Een eerste concept van een productbeschrijving voor de webshop.” Geen omschrijvende paragraaf, geen marketingtaal. Iemand die de prompt nooit eerder heeft gezien, moet binnen tien seconden weten waarvoor hij dient.
Input. Wat verwacht de prompt aan invoer? “Productnaam, drie kernkenmerken, doelgroep in één zin.” Hier voorkom je het meeste gepruts achteraf.
Output-format. Wat komt eruit? “Drie alinea’s van maximaal vier zinnen, in tutoiement, zonder bullets.” Een prompt zonder output-format is een prompt die elke keer iets anders levert.
Eigenaar. Eén persoon. Geen “het marketingteam”, geen “iedereen”. Eén naam. Die persoon is verantwoordelijk voor de actualiteit, de review, en de beslissing om hem te archiveren.
Versie. Datum plus een nummer. v1-2026-03 is genoeg. Een changelog-veldje erbij is fijn, maar niet strikt nodig.
Dat zijn de basisvelden. Voor wie de AI-Act serieus neemt, komt daar een zesde bij: model en regio. Daarover later meer.
Waar bewaar je het: Markdown plus Git, Notion, of een prompt-tool
Drie opties, met eerlijke afwegingen.
Markdown-bestanden in een Git-repo. Gratis, ingebouwd versiebeheer, perfecte history. Nadeel: je hebt iemand in het team nodig die met Git overweg kan. Voor een mkb-team zonder developer is dit zelden de juiste keuze, ook al is het technisch de schoonste.
Notion of Coda. Toegankelijk, iedereen kan ermee werken, je kunt prompts taggen en filteren. Nadeel: versiebeheer is zwakker. Je kunt wel een history zien, maar diff-en tussen versies is omslachtig.
Commerciële prompt-tools. PromptLayer, Helicone, Langfuse. Sterke versiebeheer-features, A/B-testing, modelvergelijking. Nadeel: gebouwd voor teams met development, met de bijbehorende setup-kosten. Voor een mkb-marketingteam vaak overkill.
Voor de meeste mkb-bedrijven die ik help, is Notion of een vergelijkbare wiki-tool de juiste startplek. Eenvoudig, iedereen kan erbij, en als de bibliotheek groeit, kun je later migreren.
Begin klein. Vijf prompts in Notion met de vijf velden is meer waard dan 80 prompts zonder structuur in een fancy tool.
Versiebeheer zonder ontwikkelaars
Versiebeheer hoeft niet ingewikkeld te zijn. In een mkb-team werkt deze conventie in mijn ervaring goed.
Bestandsnaam of titel: verkoopmail-v3-2026-06-jp.md of als kolomwaarde v3-2026-06. Wat betekent het: versie 3, juni 2026, laatst aangepast door initialen JP.
Verder per prompt een kort changelog-veld:
- v1 (2026-01): eerste versie, GPT-4o.
- v2 (2026-04): output-format aangescherpt, te lange paragrafen.
- v3 (2026-06): aangepast voor GPT-5, instructie over toon toegevoegd.
Dat is genoeg. Geen Git, geen branches, geen pull requests. Wel weet je drie versies later nog waarom je een instructie hebt veranderd.
Wie test, wie keurt af, wie haalt eruit
Rollen klein houden. In een mkb-team van vijf werkt deze verdeling.
Eigenaar per prompt: één persoon. Die schrijft, test en past aan. Niet “het team”.
Reviewer: één persoon. Iemand anders dan de eigenaar, die elk kwartaal kritisch meekijkt. Bij een mkb-team is dit vaak de directie of een ervaren collega.
Gebruikers: de rest. Iedereen mag prompts gebruiken. Niemand mag ze zelf aanpassen zonder overleg met de eigenaar.
Retirement-regel: prompts die in zes maanden niet gebruikt zijn, gaan naar een “archief”-sectie. Ze worden nooit weggegooid. Context verlies je nooit terug, en een afgekeurde prompt kan over een jaar opeens weer relevant zijn.
AI-grenzen in je bibliotheek vastleggen
Dit is het stuk dat in de meeste prompt-blogs ontbreekt. Een prompt is geen onfeilbaar recept. Per prompt-template hoort een veld:
Menselijke nacontrole nodig? Ja of nee, en zo ja: waarop letten.
Voorbeelden uit klantbibliotheken die ik heb opgezet:
- Productbeschrijving: ja, op feitelijke claims (prijs, maten, garantie).
- Verkoopmail: ja, op tone-of-voice en op klantnaam.
- Samenvatting van een interne meeting: ja, op besluitvorming en actiehouders.
- Vertaling Nederlands naar Engels van een algemene tekst: nee, maar wel hardop lezen.
Dit veldje is geen formaliteit. Het voorkomt dat een collega ervan uitgaat dat de AI-uitvoer klaar is voor publicatie. Bij juridische of medische context geldt dat dubbel.
Van 5 naar 50 prompts: het schaalmoment
Op een gegeven moment groeit de bibliotheek. Bij vijf prompts heb je geen categorieën nodig. Bij vijftig wel.
Het schaalmoment is meestal rond de twintig prompts. Dan ga je tagging inrichten. Een paar voorbeelden van categorieën die in mkb-praktijken werken:
- Naar functie: marketing, sales, klantenservice, intern.
- Naar model: GPT-4o, Claude 3.5, Mistral Large.
- Naar gevoeligheid: openbaar oké, intern, vertrouwelijk.
Die laatste is direct relevant voor de AI-Act. Wie data verwerkt in een prompt, moet weten waar die data uitkomt. Een tag “klantdata: nee” of “klantdata: ja, geanonimiseerd” voorkomt later veel uitleg.
Voor de bredere AI-Act-context schrijf ik apart in AI-Act checklist voor het mkb 2026. Een prompt-bibliotheek met modelvermelding is een directe bouwsteen voor het verplichte AI-register.
EU-residency en modelkeuze per prompt
Een vaak vergeten veld: in welk model loopt deze prompt, en waar staat de data? Niet alle prompts moeten in alle modellen draaien.
Een paar werkbare regels uit klantpraktijk:
- Algemene marketing-content zonder klantdata: GPT-4o of Claude is prima.
- Klantmails met persoonsgegevens: Mistral via een EU-endpoint of Azure OpenAI in EU-regio.
- Juridische voorconcepten: Claude wordt in publieke vergelijkingen vaak genoemd voor lange documenten, maar EU-residency moet je dan via Bedrock of Vertex regelen.
Voor de uitgebreide afweging tussen modellen verwijs ik naar de officiële documentatie van Anthropic over prompt engineering. Daar staan ook concrete adviezen over structuur die je in je templates kunt verwerken.
Lokaal aanspreekpunt: hoe Lypii inricht
Een prompt-bibliotheek opzetten doe ik in één implementatie-sessie. Dat kost 95 euro per uur, in de praktijk meestal drie uur. Wat je dan hebt staan: vijf tot tien werkbare prompts in jouw stijl, de vijf velden ingericht, een rolverdeling op papier, en een review-ritme op de kalender.
Daarna ben je zelfstandig. Wil je een periodieke review-sessie of hulp bij een modelmigratie? Dat valt onder het standaardtarief van 70 euro per uur.
Wat ik niet doe: een abonnement voor “prompt-as-a-service”. Een bibliotheek is van jou, hoort van jou te zijn, en moet werken zonder dat ik elke maand langskom.
Stuur me wat je nu aan prompts hebt rondslingeren. Ik reageer binnen 4 uur op werkdagen.
