"Bouw een SaaS" betekende vroeger dat u iets duurzaams bezat. In 2026 kan een AI-codeeragent de kernfunctionaliteit van uw app opnieuw opbouwen, uw landingspagina een nieuwe stijl geven en uw advertentieteksten in één middag reverse-engineeren — zie ook ons eigen stuk over hoe ver codeeragents inmiddels zijn. De interface, de onboardingflow, de positionering: alles is nu goedkoop te kopiëren. Wat niet goedkoop te kopiëren is, is een model dat u zelf op uw eigen data hebt fine-getuned en dat een algemeen frontiermodel stilletjes verslaat bij precies die ene taak die uw bedrijf nodig heeft.
Dat is de verschuiving die aandacht verdient: fine-tuned small language models (SLM's) — grofweg 0,5 tot 12 miljard parameters — te gelde maken zoals u een SaaS-product zou licentiëren, in plaats van (of naast) weer een wrapper rond de API van iemand anders te leveren.
Waarom de SaaS-gracht erodeert
De klassieke SaaS-gracht was nooit echt de code — het was de tijd die een concurrent nodig had om die te schrijven. Die tijd is ingestort. Codeeragents kunnen in uren in plaats van maanden een werkende kloon van de meeste CRUD-en-dashboardproducten opzetten, en ze zijn even goed in het kopiëren van het marketingoppervlak: de advertentiehaakjes, de opbouw van de landingspagina, de psychologie van de prijspagina. Niets daarvan vereist dat u uw broncode steelt; het volstaat uw product te bekijken en een agent te vragen de vorm ervan na te bouwen.
Wat overblijft als echte gracht, is alles wat een concurrent niet zomaar door een agent kan laten reproduceren: eigen data, distributie die u al hebt verdiend, in de loop van de tijd opgebouwd vertrouwen — en steeds vaker een model dat u zelf hebt getraind en waar een generieke kloon simpelweg geen toegang toe heeft.
Wat er echt veranderde: fine-tunen werd makkelijk
Fine-tunen vroeg vroeger om een ML-onderzoeksteam. Wat er in 2026 veranderde, is dat frontiermodellen echt goed werden in het begeleiden van één enkele operator door de hele pijplijn van begin tot eind — niet alleen vragen erover beantwoorden, maar het mechanische werk zelf doen. Modellen als DeepSeek-V4-Pro (in augustus 2026 algemeen beschikbaar), GLM-5.3, Kimi K3 (de release van Moonshot AI, een van de grootste beschikbare open-weight modellen) en GPT-6 Astra (OpenAI's huidige vlaggenschip) kunnen datasetvoorbereiding, LoRA-/QLoRA-adaptersetup, het debuggen van trainingsruns en het exporteren van het resultaat naar GGUF (voor lokale inference in de stijl van llama.cpp en Ollama) of MLX (voor Apple Silicon) bekwaam afhandelen — de deployment-formaten waarmee een fine-tuned model buiten een onderzoeksnotebook daadwerkelijk draaibaar wordt.
Dat is de echte doorbraak. Het is niet dat kleine modellen ineens slimmer werden — het is dat de tooling om ze te specialiseren is ingekrompen van een onderzoeksproject van meerdere maanden tot iets wat één technisch bekwaam persoon in dagen kan draaien, met een frontiermodel als bouwpartner in plaats van elke stap met de hand te doen.
De gracht was nooit "wij hebben een taalmodel". Elke concurrent heeft toegang tot dezelfde frontier-API's als u. De gracht is een model dat is getraind op data die uw concurrent niet heeft, beoordeeld aan een lat die hij niet heeft gehaald, verpakt als iets wat u van begin tot eind in handen hebt.
Waarom een fine-tuned SLM een SoTA-model kan verslaan bij een specifieke taak
Een frontiermodel is gebouwd om bijna overal goed in te zijn, wat betekent dat zijn capaciteit over een enorm scala aan taken is uitgesmeerd die het van u nooit te zien krijgt. Een klein model dat is fine-getuned op enkele honderden tot enkele duizenden zorgvuldig samengestelde, taakspecifieke voorbeelden draagt die overhead niet — het hoeft alleen goed te zijn in die ene taak waarvoor u het trainde, en kan dat bereiken met een fractie van de parameters.
De economie ondersteunt dit. Zelfs de huidige open-weight modellen van frontierklasse — DeepSeek-V4-Pro, GLM-5.3, Kimi K3 — draaien al tegen ruwweg een vijfde tot een dertigste van de kosten per token van gesloten frontier-API's en blijven op algemene benchmarks concurrerend. Een klein model dat voor één smalle taak is fine-getuned en zelf wordt gehost, gaat daar aanzienlijk verder in: kostenreducties in het bereik van 90%+ en meervoudige latencyverbeteringen ten opzichte van een algemene frontier-API worden voor goed afgebakende toepassingen vaak gemeld, al hangen de exacte cijfers sterk af van de taak, het basismodel en hoe gedisciplineerd de evaluatie is. Het is uw model, gehost op uw eigen infrastructuur — geen gedeelde rate limits, geen verrassende prijswijzigingen, geen klantdata die standaard naar de API van een derde partij gaat.
Niet zeker welke van uw workflows fine-tunen waard zijn?
Het lastige deel is niet het draaien van een LoRA-job — het is het kiezen van de juiste taak, het opbouwen van een eerlijke evaluatieset en weten wanneer een fine-tune het echt waard is om te onderhouden. Precies dat afbakenwerk doen we met klanten voordat er een trainingsrun start.
Plan een consultHet draaiboek: van idee naar licentieerbaar model
Stap 1 — Kies een smalle, herhaalbare taak. Classificatie, gestructureerde extractie, een specifieke stijl van generatie, een goed afgebakende domeinchat — geen open assistent. Fine-tunen beloont een taak waarvan u de grenzen daadwerkelijk kunt definiëren.
Stap 2 — Stel een echte dataset samen. Een paar honderd tot een paar duizend hoogwaardige, geverifieerde voorbeelden verslaan steevast een slordige scrape van 100.000 rijen. Gebruik een frontiermodel om kandidaatvoorbeelden te genereren en op te schonen, en laat vervolgens een mens een representatieve steekproef beoordelen voordat er iets de training in gaat.
Stap 3 — Fine-tune met LoRA of QLoRA op een klein basismodel. Binnen het bereik van 0,5–12 miljard parameters blijven houdt een trainingsrun goedkoop genoeg om op één GPU of een bescheiden gehuurde instantie te itereren, in plaats van een job op datacenterschaal.
Stap 4 — Evalueer rigoureus tegen de SoTA-baseline. Dit is de stap die mensen overslaan, en het is degene die u daadwerkelijk vertelt of u iets hebt dat het verkopen waard is. Bouw een achtergehouden testset die het model nooit heeft gezien, laat het frontiermodel en uw fine-tune naast elkaar draaien en wees eerlijk over waar welke wint.
Stap 5 — Exporteer voor echte deployment. GGUF voor llama.cpp- en Ollama-compatibele lokale inference, MLX voor Apple Silicon — de formaten waarmee een klant het model daadwerkelijk op eigen hardware kan draaien in plaats van een gehoste endpoint te moeten vertrouwen.
Stap 6 — Licentieer het als software. Per gebruiker, op basis van gebruik of een vast bedrag voor een private on-prem-installatie — dezelfde verpakkingspatronen die SaaS al gebruikt. Het product is alleen toevallig modelgewichten en een evaluatieraamwerk in plaats van een webapp.
Waar dit niet werkt
Dit is geen blanco vervanging van SaaS, en het zo behandelen is hoe deze projecten mislukken. Een paar eerlijke kanttekeningen:
Brede, open toepassingen blijven frontiermodellen bevoordelen. Fine-tunen blinkt uit bij smalle, herhaalbare taken met een duidelijk goed antwoord — niet bij algemeen redeneren of open gesprekken, waar breedte juist het hele punt is.
Licenties van basismodellen tellen. Zelfs ruim gelicentieerde open-weight modellen kunnen voorwaarden voor commercieel gebruik hebben. Controleer de licentie voordat u een bedrijf bouwt op de gewichten van een ander.
Modellen verouderen. Naarmate basismodellen beter worden, kan een fine-tune-voorsprong krimpen of verdwijnen. Budgetteer periodiek opnieuw tunen als onderdeel van het product, niet als een eenmalige bouw die u nooit meer aanraakt.
De bottleneck is datakwaliteit, niet rekenkracht. Een fine-tune is zo goed als wat u erin stopt. Teams die stap 2 hierboven overslaan en erop rekenen dat het fine-tuneproces een slordige dataset repareert, zijn steevast teleurgesteld in het resultaat.
Een stille, onderbelichte trend
Het is een patroon dat vaker opduikt in technische kringen dan in het publieke debat: operators die het afgelopen jaar stilletjes tientallen smalle, taakspecifieke modellen hebben fine-getuned, met verrassend weinig dat is opgeschreven in verhouding tot hoe effectief de resultaten doorgaans zijn. Een deel daarvan komt door de fixatie van het vakgebied op frontiermodel-launches, die de aandacht voor het minder glamoureuze werk wegdrukken om een klein model te specialiseren op een echt bedrijfsprobleem. Een deel komt doordat een werkende fine-tune een echt concurrentievoordeel is, en wie er een bouwt weinig prikkel heeft om precies uit te leggen hoe.
Het instinct erachter houdt echter stand: voor een goed afgebakende, hoogvolume, specifieke taak verslaat een fine-tuned maatwerk-SLM steeds vaker een generieke SaaS-wrapper rond een frontier-API — goedkoper om te draaien, sneller in reactie en onder uw eigen controle in plaats van gehuurd van de rate limits van een ander. Het is geen vervanging voor elk SaaS-product, en het is niet gratis — het datasetwerk en de evaluatiediscipline zijn echte kosten. Maar als categorie die het in 2026 serieus verkennen waard is, heeft het de aandacht verdiend. Weegt u dit af tegen de kosten van een conventionelere bouw, dan is ons overzicht van wat AI-implementatie werkelijk kost een goede volgende lectuur, en onze kijk op de open-source AI-toolinggolf behandelt de aangrenzende toolingverschuiving die dit alles goedkoper bouwbaar maakt.