Open-source of proprietary LLM: wat werkt voor uw agent?
U wilt een agent bouwen. Dan komt vroeg of laat de vraag: welk taalmodel zit eronder? Open-source of een proprietary model van een grote aanbieder? Het antwoord hangt af van wat uw agent doet, niet van wat de pers schrijft.
Uw agent verwerkt inkomende bestellingen. Op dinsdag staat er een factuur in de mailbox van een leverancier die niet overeenkomt met de inkooporder. De agent moet dat signaleren, de afwijking benoemen en het ter goedkeuring voorleggen. Klinkt eenvoudig. Maar of het model dat erin zit die taak betrouwbaar uitvoert, hangt af van keuzes die u maanden eerder maakt.
Die keuze begint bij het taalmodel. Elk model heeft een ander karakter, andere kosten, andere privacyimplicaties en andere technische eisen. Dit artikel helpt u die keuze doordenken, zonder technische voorkennis vereist.
Proprietary modellen leveren de meeste capaciteit uit de doos
Proprietary modellen zijn modellen van commerciële aanbieders: denk aan de modellen achter Claude van Anthropic, de GPT-reeks van OpenAI, en Gemini van Google. U gebruikt ze via een API. U betaalt per token. U heeft zelf geen hardware nodig.
De sterkte van deze modellen is hun bereik. Ze begrijpen context in lange documenten, volgen meerstaps-instructies, en werken goed met ongestructureerde tekst zoals inkomende e-mails of handgeschreven werkbonnen. Voor taken waarbij taalkennis en redeneren centraal staan, presteren ze op dit moment beter dan de meeste open-source alternatieven.
Het nadeel is dat uw data de infrastructuur van die aanbieder passeert. Bij FactumAI werken wij standaard met Anthropic: de verwerking van taalmodelcalls vindt plaats in de VS, opslag en overige verwerking in Frankfurt. Dat is opgenomen in onze sub-verwerkerslijst met een transfer impact assessment. Dat is transparant, maar het betekent dat u als MKB-ondernemer moet nadenken over wat u door dat model stuurt.
Open-source modellen geven u meer controle, maar vragen meer beheer
Open-source modellen zoals Llama van Meta, Mistral en Qwen zijn vrij beschikbaar. U kunt ze draaien op uw eigen server of bij een cloudprovider in de EU. De modelgewichten zijn publiek, de code is controleerbaar, en u bepaalt zelf waar de data blijft.
Dat klinkt aantrekkelijk. Maar er is een prijs. U of uw leverancier moet de infrastructuur beheren, de modellen finetunen voor uw domein, en zorgen dat de prestaties op peil blijven. Open-source modellen zijn de afgelopen twee jaar sterk verbeterd, maar op complexe redeneervaardigheden zitten er nog altijd gaten ten opzichte van de beste proprietary modellen. Niet altijd relevant, soms wel.
Welk werk doet uw agent precies? Als hij gestructureerde data vergelijkt, eenvoudige beslissingen uitvoert en templates invult, kan een kleiner open-source model dat uitstekend aan. Als hij ongestructureerde tekst moet interpreteren en contextueel redeneren, is dat een ander verhaal.
De keuze draait om drie concrete variabelen
Ik beoordeel de modelkeuze altijd langs drie assen. Niet als ideologie, maar als praktisch filter.
De eerste as is taakcomplexiteit. Vergelijkt uw agent twee getallen, of interpreteert hij een klachtenmail en koppelt hij die aan een openstaande order? Complexere taken vragen krachtigere modellen. Eenvoudige, repetitieve taken zijn prima te doen met kleinere, goedkopere of zelf-gehoste modellen.
De tweede as is datagevoeligheid. Wat stuurt u naar het model? Klantnamen, factuurbedragen, medische gegevens of bedrijfsvertrouwelijke contractinformatie vragen een bewuste afweging over waar die data terechtkomt. Dit is geen reden om automatisch open-source te kiezen, maar het is een reden om de vraag te stellen. Voor een agent die factuurverwerking verzorgt en daarbij inkoopbedragen en leveranciersgegevens verwerkt, is dit een gesprek dat u vroeg in het traject voert.
De derde as is totale beheerlast. Open-source op eigen infrastructuur is goedkoper per token, maar vraagt onderhoud. Updates van het model, monitoring, schaalbaarheid bij pieken in gebruik. Dat kost tijd of geld. Voor de meeste MKB-bedrijven is het niet de meest efficiënte keuze om dat zelf te beheren.
Gemengde architecturen zijn geen uitzondering meer
In de praktijk kiezen steeds meer bouwerijen voor een combinatie. Een krachtig proprietary model voor de redeneerlaag, een goedkoper of zelf-gehost model voor de routinetaken. Denk aan een agent die klantvragen classificeert met een klein model, en alleen de complexe gevallen doorstuurt naar een groter model voor verdere verwerking.
Die aanpak verlaagt de kosten per taak en houdt gevoelige data weg van externe modellen waar dat kan. Het maakt de architectuur wel iets ingewikkelder. Of die complexiteit de moeite waard is, hangt af van het volume. Bij een agent die tientallen duizenden tokens per dag verwerkt, begint kostenoptimalisatie te tellen. Bij een agent die tien keer per dag iets doet, is de winst marginaal.
Bent u benieuwd of een kennisbankagent voor uw interne documenten in aanmerking komt voor een hybride aanpak? Dat is precies het soort vraag dat wij in de eerste fase van een traject uitwerken, voordat er een regel code geschreven wordt.
Kosten zijn voorspelbaar, maar niet triviaal
Proprietary modellen rekenen per token. Een token is ruwweg een woord of woorddeel. De prijzen variëren per aanbieder en modelgrootte. Voor de meeste MKB-toepassingen zijn de kosten per maand beheersbaar, maar ze hangen sterk af van het volume en de promptlengte.
Een eenvoudige rekensom: als uw agent elke dag honderd documenten verwerkt van gemiddeld duizend woorden per stuk, praat u over een flink volume per maand. Of dat neerkomt op tien of honderd euro hangt af van het model en de precieze aanroepstructuur. Vraag dit altijd te schatten voordat u een keuze maakt. Het is een aanname die u met eigen aantallen kunt invullen, maar de grootteorde is belangrijk.
Open-source op eigen hardware heeft andere kostenstructuren: serverkoop of -huur, elektriciteit, beheer. Die zijn minder variabel, maar ook minder flexibel bij pieken. Voor bedrijven met een grillig gebruik is variabele API-pricing soms juist goedkoper.
Vendor lock-in is een risico dat u kunt beheersen
Een terechte zorg: wat als uw modelaanbieder de prijs verdubbelt, stopt met een versie of zijn beleid wijzigt? Vendor lock-in is reëel bij proprietary modellen. Maar het is beheersbaar als u uw agent goed bouwt.
De sleutel is een abstractielaag. Als uw agent via een modelagnostische interface werkt, kunt u het onderliggende model wisselen zonder de hele applicatielogica te herschrijven. Wij bouwen standaard zo, en dat is precies waarom de vraag welk model er nu onder zit minder bepalend is dan hoe de agent zelf is opgebouwd.
Open-source heeft hier theoretisch een voordeel: u bent nooit afhankelijk van één commerciële partij. Maar als uw open-source model draait op de infrastructuur van AWS, Azure of Google, heeft u de afhankelijkheid verschoven, niet opgeheven. Echte onafhankelijkheid vereist eigen hardware, en dat is voor de meeste MKB-bedrijven geen realistisch scenario.
Begin niet met het model, begin met de taak
De meest voorkomende fout is dat de modelkeuze voor de taakomschrijving komt. Iemand heeft ergens gelezen dat open-source modellen goedkoper zijn, of dat proprietary modellen beter zijn, en gaat van daaruit bouwen. Dat is achteruit denken.
Wat moet uw agent doen? Hoe gevoelig is de data die hij verwerkt? Hoeveel volume verwacht u? Heeft u interne capaciteit om infrastructuur te beheren? Die vragen bepalen welk model logisch is, niet andersom. Lees daarvoor ook welk proces geschikt is voor een agent voordat u over modellen nadenkt.
Een concrete eerste stap: schrijf op wat uw agent de komende maand moet doen, hoe vaak, met welke data en wat er mis mag gaan. Dat overzicht is het startpunt voor een goede keuze. Alles wat daarna komt, inclusief het model, volgt uit dat document.
Over dit onderwerp
Is een open-source LLM veiliger dan een proprietary model voor mijn bedrijfsdata?
Niet automatisch. Een open-source model dat u zelf host biedt meer controle over waar data terechtkomt, maar vereist ook dat u de beveiliging van die infrastructuur zelf beheert. Een proprietary model via een provider met een goed verwerkersovereenkomst en transfer impact assessment kan in de praktijk veiliger zijn dan een zelf-gehoste omgeving zonder goed beveiligingsbeheer. De vraag is niet open-source of proprietary, maar wie de infrastructuur beheert en hoe.
Kan ik later nog wisselen van taalmodel als ik eenmaal een agent heb gebouwd?
Ja, mits de agent gebouwd is met een abstractielaag tussen de applicatielogica en het model. Dan vervangt u het model zonder de rest te herschrijven. Is die laag er niet, dan is wisselen tijdrovend. Vraag bij elke bouwpartij of agent-as-a-service oplossing expliciet of de architectuur modelagnostisch is.
Wat kost het gebruik van een proprietary LLM per maand voor een MKB-agent?
Dat hangt af van het volume en de promptlengte. Voor een agent die dagelijks een beperkt aantal documenten of berichten verwerkt, zijn de maandelijkse API-kosten doorgaans beheersbaar, maar de grootteorde varieert sterk. Laat dit altijd schatten op basis van uw eigen verwachte gebruik, niet op basis van een gemiddelde. De kosten zijn variabel en schalen mee met het gebruik.
Welke open-source modellen zijn in 2026 serieuze opties voor zakelijke agents?
Llama van Meta, Mistral en Qwen zijn de meest gebruikte open-source modellen voor zakelijke toepassingen. Ze zijn sterk verbeterd en geschikt voor gestructureerde taken en documentverwerking. Voor complexe redeervraagstukken of lange contextvensters presteren de beste proprietary modellen op dit moment nog beter. Welk model het meest geschikt is, hangt af van uw specifieke taak.