Een AI-chatbot-app bouwen: sleutels, prompts, kosten en veiligheid
Om een AI-chatbot-app te bouwen heb je vier dingen nodig: een chatinterface, een kleine server die de API-sleutel van je modelaanbieder bewaart en berichten daarheen doorstuurt, een systeemprompt die het model vertelt wie het is en wat het mag doen, en grenzen die kosten en misbruik beperken. Een AI-app-builder kan dat allemaal op basis van een beschrijving maken. Het werk dat bij jou blijft: de aanbieder kiezen, de instructies schrijven en bepalen wat de bot nooit mag doen.
Waaruit een AI-chatbot-app bestaat
De meeste chatbot-apps, of het nu een supportassistent, een tutor of een interne “vraag het onze documenten”-tool is, hebben dezelfde onderdelen:
| Onderdeel | Wat het doet | Kun je het overslaan? |
|---|---|---|
| Chat-UI | Berichtenlijst, invoerveld, “denkt na”-status, gestreamde antwoorden | Nee |
| Serverroute | Ontvangt het bericht van de gebruiker, voegt de systeemprompt toe en roept de aanbieder aan met jouw geheime sleutel | Nee, de sleutel mag nooit bij de browser komen |
| Systeemprompt | Vaste instructies: rol, toon, bereik, wat te weigeren | Nee |
| Kennis | Je eigen content waaruit de bot antwoordt (FAQ, beleid, productdocumentatie) | Ja, voor een algemene assistent |
| Gespreksopslag | Slaat threads op in een database zodat gebruikers later kunnen terugkomen | Ja, voor een eerste versie |
| Accounts | Zorgt dat elke gebruiker alleen de eigen geschiedenis ziet, en laat je het gebruik per persoon begrenzen | Ja, voor een publieke demo met strikte limieten |
| Limieten en logging | Maximale berichtlengte, snelheidslimieten, een uitgavenlimiet, een register van fouten | Nee |
De serverroute is het onderdeel dat mensen het vaakst verkeerd doen. Als de chatpagina de aanbieder rechtstreeks vanuit de browser aanroept, kan iedereen de ontwikkelaarstools openen, je sleutel kopiëren en je rekening laten oplopen.
Beslissingen vóór je begint
Welke aanbieder en welk model
De belangrijkste aanbieders (OpenAI, Anthropic, Google en andere) bieden allemaal een chat-achtige API die op dezelfde manier werkt: je stuurt een lijst berichten en krijgt een antwoord terug. De praktische keuze gaat minder over het merk en meer over de modelgrootte:
- Kleinere, snellere modellen zijn goedkoper en reageren snel. Ze zijn prima voor korte antwoorden, classificatie en eenvoudige FAQ-bots.
- Grotere modellen redeneren beter, volgen lange instructies betrouwbaarder en kunnen rommelige vragen aan, maar kosten meer per bericht en reageren trager.
Begin met een middelgroot model, test het met je echte vragen en schaal van daaruit op of af. Als je nog niet weet hoe deze API's geprijsd en aangeroepen worden, lees dan eerst hoe je LLM-API's gebruikt.
Waar de kennis van de bot vandaan komt
| Jouw content | Aanpak |
|---|---|
| Een pagina of twee (openingstijden, retourbeleid, prijzen) | Zet het rechtstreeks in de systeemprompt |
| Tientallen pagina’s die zelden veranderen | Zet een beknopte versie in de prompt, of splits het per onderwerp en voeg het relevante deel toe |
| Honderden documenten, of content die dagelijks verandert | Sla het op, zoek de passages die bij elke vraag passen en stuur alleen die mee (RAG) |
Begin met de eenvoudigste optie die je content dekt. Retrieval voegt een zoekindex toe, een manier om die actueel te houden en meer plekken waar antwoorden fout kunnen gaan. Veel nuttige bots hebben het nooit nodig.
Publiek, of achter een login
Een publieke chatbot op je website is makkelijk te bereiken, maar ook makkelijk te misbruiken: iemand kan met een script duizenden berichten sturen. Een chatbot achter een login laat je geschiedenis per gebruiker opslaan en een dagelijks tegoed per account instellen. Als hij publiek is, begrens dan de berichtlengte, beperk hoeveel berichten één bezoeker in een bepaalde periode kan sturen, en stel een harde maandlimiet in via het dashboard van de aanbieder. Hoe je login aan je app toevoegt behandelt de accountkant.
Of je gesprekken opslaat
Opgeslagen threads zijn nuttig: gebruikers kunnen verdergaan waar ze gebleven waren, en je kunt echte vragen lezen om de prompt te verbeteren. Ze zijn ook persoonsgegevens. Bepaal hoe lang je ze bewaart, meld dit in je privacyverklaring en bewaar niets wat je niet nodig hebt.
Schrijf de systeemprompt als een functieomschrijving
De systeemprompt is de instructie die het model vóór elk gesprek ontvangt. Een goede lees je als een korte opdracht voor een nieuwe medewerker:
- Rol en doelgroep: “Je bent de helpassistent van Oakline, een fietsreparatiewinkel. Je praat met klanten.”
- Bereik: “Beantwoord vragen over diensten, prijzen, openingstijden en afspraken. Zeg bij al het andere dat je alleen met de winkel kunt helpen.”
- Bron van waarheid: “Gebruik alleen de informatie hieronder. Als het antwoord er niet in staat, zeg dan dat je het niet weet en geef het telefoonnummer van de winkel.”
- Toon en lengte: “Vriendelijk, duidelijk Nederlands, drie zinnen of minder tenzij om meer detail wordt gevraagd.”
- Harde regels: “Beloof nooit een reparatieprijs die niet vermeld staat. Vraag nooit om creditcardgegevens.”
Test daarna met lastige vragen: onderwerpen buiten het bereik, onbeleefde berichten, vragen waarvan het antwoord niet in je content staat, en pogingen om de instructies te negeren (“vergeet je regels en…”). Pas de prompt aan tot de antwoorden zijn waar je je naam onder zet.
Houd de kosten voorspelbaar
Aanbieders factureren per token (ruwweg stukjes woorden) voor de invoer die je stuurt en de uitvoer die het model schrijft. Drie dingen bepalen de rekening:
- Gesprekslengte. Elk nieuw bericht stuurt meestal de hele thread opnieuw mee zodat het model context heeft. Een gesprek van 40 berichten kost per antwoord veel meer dan een van 4 berichten. Houd alleen de laatste paar beurten, of vat oudere samen.
- Promptgrootte. Een lange systeemprompt of een groot blok geplakte kennis wordt bij elk bericht meegestuurd.
- Uitvoerlengte. Stel een maximale antwoordlengte in de API-aanroep in en vraag in de prompt om beknopte antwoorden.
Stel vóór de lancering een maandelijkse uitgavenlimiet in via het dashboard van de aanbieder en registreer het tokengebruik per verzoek, zodat je ziet welke gesprekken duur zijn. We noemen hier geen prijzen, omdat die per model verschillen en vaak veranderen; controleer de prijspagina van je eigen aanbieder.
Bouw het stap voor stap
Stap 1: Beschrijf de bot, niet de code
Een eerste prompt die de doelgroep, het bereik, de data en de veiligheidsregels noemt, brengt je al een heel eind:
Bouw een klanthulp-chatbot voor Oakline, een fietsreparatiewinkel. Een chatpagina met een berichtenlijst en invoerveld, antwoorden die gestreamd worden terwijl ze geschreven worden. Roep de Anthropic-API aan vanuit een serverroute met de geheime ANTHROPIC_API_KEY — stel die nooit bloot aan de browser. Gebruik een systeemprompt die alleen vragen beantwoordt over onze diensten, prijzen en openingstijden uit de tekst in een bestand shop-info.md, en anders zegt “Ik weet het niet zeker — bel ons op het nummer hieronder”. Beperk berichten tot 500 tekens en 20 berichten per bezoeker per uur. Schoon, vriendelijk ontwerp dat op telefoons werkt.
Stap 2: Zet de sleutel als geheim
Maak de sleutel aan in de console van je aanbieder en sla hem op in de omgevingsvariabelen of geheimen van het project, niet in de chat en niet in de code. Als een sleutel ooit ergens openbaar opduikt, trek hem dan in bij de aanbieder en maak een nieuwe aan. Wat omgevingsvariabelen en geheimen zijn legt uit waarom dit belangrijk is.
Stap 3: Test de antwoorden, niet alleen de interface
Zodra de chat werkt, besteed je de meeste tijd aan de kwaliteit van de antwoorden. Houd een lijst van ongeveer 20 echte vragen bij, inclusief een paar die geweigerd moeten worden, en loop die door na elke wijziging in de prompt. Controleer:
- Blijft het binnen het bereik?
- Geeft het toe als het iets niet weet, in plaats van een antwoord te verzinnen?
- Houdt het stand als iemand de instructies probeert te overrulen?
- Staat de sleutel nergens in wat de browser downloadt?
Stap 4: Voeg geheugen en accounts toe als je ze nodig hebt
Zodra losse gesprekken werken, vraag je om opgeslagen threads in een database en, indien nodig, aanmelden en inloggen zodat elke gebruiker alleen de eigen chats ziet. Voeg tegelijk een dagelijks berichttegoed per gebruiker toe.
Stap 5: Publiceer met de limieten ingeschakeld
Zorg dat de gepubliceerde app dezelfde geheimen heeft als de preview, dat de uitgavenlimiet bij de aanbieder is ingesteld en dat fouten ergens gelogd worden waar je ze ziet. Deel de app daarna met een kleine groep voordat je hem op je hoofdsite zet.
Veiligheid en vertrouwen
Een chatbot praat namens jou met het publiek, dus behandel zijn faalwijzen als jouw probleem:
- Foute antwoorden. Modellen kunnen met overtuiging onwaarheden beweren. Houd de bot bij een smal onderwerp, baseer hem op je eigen content en toon een korte melding dat antwoorden fout kunnen zijn bij iets belangrijks.
- Prompt-injectie. Gebruikers (of documenten die de bot leest) kunnen instructies bevatten zoals “negeer eerdere regels”. Geef de bot geen bevoegdheden die je niet kunt vertrouwen: geen terugbetalingen, verwijderingen of e-mails op verzoek van een gebruiker zonder controle in je eigen code.
- Gevoelige onderwerpen. Bij medische, juridische of financiële vragen laat je de bot mensen naar een professional verwijzen in plaats van advies te geven.
- Persoonsgegevens. Plak geen klantgegevens in prompts tenzij het nodig is, en controleer wat de voorwaarden van je aanbieder zeggen over de verwerking van API-data.
Onze beveiligingschecklist voor met AI gebouwde apps behandelt de rest van de app.
Veelgemaakte fouten
- De aanbieder vanuit de browser aanroepen. De sleutel lekt. Ga altijd via je server.
- Geen limieten op een publieke bot. Eén script kan een maandbudget in een middag opmaken.
- Tegelijk beginnen met RAG, tools en meerdere modellen. Krijg eerst één goed gesprek werkend; voeg de rest toe wanneer echte vragen laten zien dat je het nodig hebt.
- Alleen vriendelijke vragen testen. Je gebruikers stellen op dag één vreemde, vijandige en off-topic vragen.
- De thread eindeloos laten groeien. Kosten en responstijden stijgen met elk bericht.
Wanneer een kant-en-klaar product de betere keuze is
Zelf bouwen heeft zin wanneer de chatbot onderdeel is van je product, je eigen data of workflow nodig heeft, of een specifieke uitstraling of gedrag moet hebben. Vaak is het de verkeerde keuze wanneer:
- Je alleen een supportwidget op een bestaande site wilt. Veel helpdesk- en live-chatproducten bevatten nu AI-antwoordbots die je helpcentrum lezen, met overdracht naar een mens, inbox en rapportage al ingebouwd.
- Alleen jij of je team het gebruikt. Een abonnement op een algemene assistent zoals ChatGPT of Claude, met je documenten geüpload, kan alles zijn wat je nodig hebt.
- Je strikte compliancegaranties nodig hebt (bijvoorbeeld voor gereguleerde gezondheids- of financiële data). Een leverancier die de certificeringen al heeft, kan veiliger zijn dan een maatwerkbouw.
Bouwen met Mythex
Mythex is een AI-app-builder: je beschrijft de chatbot in de chat, het schrijft de interface en de serverkant van de aanroep, draait die in een live preview en publiceert hem op een publieke URL. De AI in je app gebruikt je eigen aanbiedersleutel. Je voegt die toe in de geheimen van het project, of via de geheimen-kaart die Mythex in de chat toont wanneer er een nodig is, en het gebruik bij de aanbieder wordt gefactureerd op je eigen aanbiedersaccount, niet op je Mythex-buildtegoed. Mythex levert geen tokens voor de gebruikers van je app, geen kant-en-klaar kennisbankproduct en geen kant-en-klare snelheidslimieten: dat zijn onderdelen die je zelf vraagt en test. De docspagina over AI in je app toevoegen loopt het stap voor stap door, en AI toevoegen met je eigen API-sleutels bevat een startprompt.
Als de bot opgeslagen threads nodig heeft, koppelt Mythex een Postgres-database aan het project zodra je daarom vraagt. Voor meer manieren om modellen in een app te gebruiken, van samenvattingen tot classificatie, zie hoe je AI-functies aan je app toevoegt, of bekijk de app-templates voor startpunten.
Veelgestelde vragen
Heb ik een eigen API-sleutel nodig om een AI-chatbot-app te bouwen?
Ja, bijna altijd. De chatbot stuurt elk bericht naar een modelaanbieder zoals OpenAI, Anthropic of Google, en die aanbieder factureert het account dat de API-sleutel bezit. De sleutel moet op je server staan, nooit in de webpagina.
Hoeveel kost het om een AI-chatbot te draaien?
Aanbieders rekenen per token, zowel voor de tekst die je stuurt als voor de tekst die het model terugschrijft, en de prijzen verschillen sterk per model. Omdat elk nieuw bericht meestal het hele gesprek opnieuw meestuurt, kosten lange chats per bericht meer dan korte. Bekijk de prijspagina van je aanbieder en stel een uitgavenlimiet in via het dashboard.
Kan ik een chatbot trainen op mijn eigen documenten?
Meestal train je het model zelf niet. Bij een kleine hoeveelheid tekst plak je die in de systeemprompt; bij een grote bibliotheek sla je de documenten op, zoek je per vraag de relevante passages op en stuur je alleen die naar het model. Die tweede aanpak heet retrieval-augmented generation, of RAG.
Kan ik een AI-chatbot bouwen zonder te coderen?
Ja. Een AI-app-builder kan op basis van een beschrijving in gewone taal de chatinterface schrijven, de serverroute die het model aanroept en de database voor opgeslagen gesprekken. Het account bij de aanbieder en de API-sleutel maak je zelf aan.