WAT VISUEEL ZOEKEN BEWUST NIET LEVERT

Visuele retrievalmodellen vinden de juiste pagina, ook in een lastige scan. Maar ze geven u een afbeelding terug, geen tekst. U kunt daaruit niet zomaar een regel kopiëren, geen volledige-tekst zoekopdracht over het archief leggen, geen machineleesbaar controlespoor bouwen. Voor dat alles hebt u herkende tekst nodig. Dat is geen zwakte van de nieuwe aanpak, maar een bewuste taakverdeling: zoeken op de afbeelding, tekstextractie via OCR, elke stap voor wat hij het best kan.

WAT PADDLEOCR-VL KAN

Baidu heeft met PaddleOCR-VL een open OCR-model gepresenteerd dat met slechts 0,9 miljard parameters topwaarden behaalt (Project). Het herkent tekst, tabellen, formules en diagrammen in 109 talen en reconstrueert de semantische structuur van een document. Op de OmniDocBench-v1.5-benchmark staat het met ongeveer 94,5% nauwkeurigheid vooraan. Het valt onder de Apache-2.0-licentie, is dus commercieel vrij te gebruiken en lokaal in te zetten. Voor het mkb betekent dat: sterke tekstherkenning zonder doorlopende kosten en zonder datalekken naar buiten.

DE HYBRIDE OPZET

In de praktijk lopen beide wegen naast elkaar. Het visuele zoeken vindt de relevante pagina's snel en layoutgetrouw. Waar daaruit harde tekst moet ontstaan, bijvoorbeeld voor een factuurregel, een contractclausule om te citeren of een invoer in het ERP, neemt OCR het over op precies die paar pagina's. Men hoeft niet het hele archief door OCR te sturen, maar alleen wat het zoeken al als belangrijk heeft gemarkeerd. Dat houdt de pipeline slank en voorkomt dat OCR-fouten van meet af aan in het zoeken insijpelen.

DE PRAGMATISCHE LIJN

Of-of is hier de verkeerde houding. Visueel zoeken verbetert het vinden, OCR verbetert de verwerking. Wie beide als tools met duidelijke taken beschouwt, bouwt de robuustere kennisbank dan iemand die dogmatisch op één kant inzet. Hoe de bouwstenen samenhangen, van encoder tot vectordatabase, staat in het stackoverzicht.

Voor een mkb-onderneming die dagelijks contracten, technische handleidingen en meerpagina's facturen verwerkt, is dat het interessantere nieuws. Niet dat de tekstherkenning een paar punten beter is, maar: een document van 80 pagina's hoeft niet meer in stukken geknipt en weer samengevoegd te worden, en daarvoor hoeft geen document het pand te verlaten.

WAT UNLIMITED-OCR ANDERS DOET

De kern is een aangepast aandachtsmechanisme in de decoder, dat het geheugen constant houdt. Klassieke OCR-modellen op transformer-basis laten de zogenoemde KV-cache meegroeien met de lengte van het document. Hoe langer de PDF, hoe meer geheugen, tot het op een gegeven moment niet meer in een verwerking past.

Unlimited-OCR vervangt dit onderdeel door Reference Sliding Window Attention (R-SWA). De KV-cache blijft daarbij constant, onafhankelijk van de documentlengte. Precies dat bedoelt de term one-shot long-horizon parsing: een lang document wordt in één doorgang gelezen, in plaats van het in secties op te delen en de resultaten achteraf samen te voegen.

Opvallend is het trainingstraject. Het team is niet bij nul begonnen, maar heeft het DeepSeek-OCR-checkpoint verder getraind: de encoder bevroren en alleen de decoder over circa 4.000 stappen aangepast. Daarmee staat het model in directe lijn met DeepSeek-OCR, dat we in de stackcontext al hebben geplaatst. Code en gewichten liggen open op GitHub.

WAAROM DE CONSTANTE KV-CACHE TELT

Het eigenlijke probleem bij lange documenten is niet de afzonderlijke pagina, maar de samenhang over de pagina's heen. Als een model een document van 60 pagina's in blokken van tien pagina's knipt, gaat precies verloren wat in de B2B-praktijk telt: een tabel die over de paginabreuk doorloopt, een clausule die verwijst naar een eerdere sectie, een post waarvan de referentiewaarde twintig pagina's eerder staat.

Een constante KV-cache maakt het mogelijk om het hele document in één context te houden. Het geheugen groeit niet mee met de lengte, dus blijft de structuur over alle pagina's behouden. Bovendien wordt het sneller: Baidu noemt in base-modus 5.580 tokens per seconde tegenover 4.951 bij DeepSeek-OCR, bij een outputlimiet van 6.000 tokens ligt het verschil rond de 35 procent.

Wat nauwkeurigheid betreft scoort Unlimited-OCR op OmniDocBench v1.5 93,23 punten, 6,22 boven de DeepSeek-OCR-basis, op v1.6 93,92. Dat zijn de cijfers uit het paper. Op uw eigen documenten telt uiteindelijk hoe het model omgaat met uw tabellen, stempels en formulieren, niet het gemiddelde van een publieke testset. Verwant is de ontwikkeling bij subkwadratische LLM's, die lange context on-premise goedkoper maken.

WAAR DIT IETS VERANDERT IN HET MKB

Het nut ontstaat daar waar lange, gestructureerde documenten omgezet moeten worden in schone, doorzoekbare data. Een paar concrete plekken:

• Contracten en raamovereenkomsten. Kruisverwijzingen en bijlagen blijven in samenhang leesbaar, in plaats van uiteen te vallen bij blokgrenzen.
• Technische handleidingen en normen. Lange documenten met afbeeldingen, tabellen en genummerde secties in één doorgang.
• Meerpagina's facturen en bonnen. Schoon geëxtraheerde tekst is de voorfase voor gestructureerde verdere verwerking, bijvoorbeeld richting e-factuur.
• Archieven en dossiers. Bestanden die tot nu toe alleen als scan bestonden, worden machinaal leesbaar, zonder ze aan een clouddienst te geven.

In bijna alle gevallen is OCR niet het doel, maar de eerste stap. Schoon geparste tekst is de basis voor een kennisbank met RAG: hoe beter het parsen, hoe beter de zoekfunctie later de juiste plek vindt.

OCR OF VISUEEL DOCUMENTEN ZOEKEN?

Niet elke documenttaak heeft klassieke tekstherkenning nodig, en dat is een eerlijke afweging. Er bestaat inmiddels een hele tak die documenten helemaal niet eerst omzet in tekst, maar ze als beeld doorzoekt, met modellen zoals ColPali of ColQwen. Deze OCR-vrije aanpak hebben we apart beschreven.

De vuistregel die bij ons haar waarde heeft bewezen:

• U hebt de daadwerkelijke tekens nodig (factuurbedragen, contractclausules, gestructureerde extractie, doorgifte aan een ander systeem): dan is OCR nauwelijks te vermijden, en een model zoals Unlimited-OCR is hier sterk.
• U hebt de juiste plek nodig, niet de volledige tekst (een vraag over een groot bestand beantwoorden, een afbeelding terugvinden): dan kan visueel documenten zoeken de directere weg zijn.

Vaak is het beide naast elkaar. Unlimited-OCR maakt het OCR-deel van deze stack goedkoper en op lange documenten betrouwbaarder.

WAT IK ZOU CONTROLEREN VOOR PRODUCTIE

Een goede benchmarkscore is een reden om het model te testen, geen reden om het productief te zetten. Voordat ik Unlimited-OCR in een klantproces zou zetten, zou ik vier dingen controleren:

🔸 Duitse documenten en handschrift. De benchmarkcijfers zeggen weinig over Duitse formulieren, oude dossiers of handgeschreven aantekeningen. Dat hoort op een eigen testset van echte documenten.

🔸 Tabellen en layout. Bij B2B-documenten bepaalt de trouw van tabellen en kolommen het nut. Hier loont de directe vergelijking met de bestaande stack.

🔸 Hardware en beheer. 3B als MoE met circa 500M actieve parameters is on-premise realistisch. Wat dat concreet betekent aan GPU-geheugen en doorvoer, hoort voor de uitrol gemeten te worden, niet geschat.

🔸 Licentie en herkomst. MIT staat commercieel, on-premise gebruik zonder voetnoten toe. Dat het spoor van het model naar een van de DeepSeek-OCR-auteurs leidt, is een kwaliteitssignaal, maar vervangt niet de eigen controle.

Wat mij eigenlijk het meest interesseert aan deze release is minder het model zelf dan de richting: lange documenten in één doorgang, klein genoeg voor het eigen rekencentrum, onder een licentie die niemand beperkt. Precies daar wordt documentverwerking in het mkb nu praktisch. Welke van uw documenten zou u als eerste laten doorlopen?

VOORBIJ DE PROMPT

Prompt engineering stemt de vraag af. Context engineering vormt de omgeving waarin het model beslist. Voor een eenmalige taak volstaat een goede prompt. Voor een agent die over veel stappen loopt, tools uitleest en geheugen meedraagt, is de prompt slechts een klein deel van wat het model ziet. De rest, wat u ophaalt, wat u onthoudt, welke tools u hoe vrijgeeft, is context, en die bepaalt veel meer over het resultaat. Daarom is het uitbreiden van een agentische harness overwegend contextwerk.

DE VIER FAALPATRONEN WAARTEGEN MEN ONTWERPT

De meeste agentfouten zijn terug te voeren op een van vier contextproblemen:

• Contextoverbelasting. Te veel in het venster. Het model verliest de draad, en kosten en latentie stijgen. Meer context is niet betere context.
• Contextvergiftiging. Een onjuist of verouderd feit belandt in het venster, en het model behandelt het als waarheid. Eén enkel slecht opgehaald fragment kan een antwoord laten ontsporen.
• Tokenbeheer. Het venster is eindig. Zonder een plan voor wat te behouden en wat te verwerpen, wordt het belangrijke detail verdrongen door ruis.
• Verouderd geheugen. Langlopende agenten verzamelen context die niet meer geldig is, en handelen daarnaar.

Het falen benoemen is de halve oplossing. Elk heeft een concrete tegenzet.

PRAKTIJKEN DIE STANDHOUDEN

Een paar patronen keren terug in opzetten die betrouwbaar blijven:

1. Ophalen, niet afladen. Haal de enkele relevante passages op met goede retrieval, in plaats van alles erin te kopiëren. Dat is de hele zin van RAG, en het is context engineering toegepast op data.
2. Doorlopend snoeien. Pas regelgebaseerde bewerking toe in het raamwerk om het venster slank te houden: verwerp wat een stap niet meer nodig heeft.
3. Lange geschiedenissen samenvatten. Vervang een lang transcript door een getrouwe samenvatting voordat het de taak verdringt.
4. Eenvoudig beginnen, indien nodig opschalen. Voeg geheugen en tools alleen toe als een echt falen daarom vraagt, niet standaard.

Het instinct om meer toe te voegen is de valkuil. De discipline is het weglaten.

WAAROM DIT HET WERKELIJKE ENGINEERING IS

Een groter model lost een contextprobleem zelden op; het faalt alleen duurder. Het werk dat een agent van demo naar betrouwbaarheid brengt, is bijna uitsluitend contextwerk: wat hij ziet, wanneer, en wat hij moet vergeten. Bij zeer lange invoer telt ook de modelarchitectuur, en daar komen subkwadratische aanpakken in beeld, maar voor de meeste teams zit de winst in de context, niet in de parameters.

HET MECHANISME, EENVOUDIG

Eenvoudige RAG embedt uw query, vindt de dichtstbijzijnde passages en beantwoordt daaruit. RAG-fusion voegt daar twee stappen aan vooraf toe. Ten eerste schrijft een model een handvol alternatieve queries die hetzelfde bedoelen vanuit verschillende invalshoeken. Ten tweede haalt het voor alle resultaten op en voegt de gerangschikte lijsten samen via reciprocal rank fusion, die passages beloont die over meerdere queries heen goed scoren in plaats van slechts bij één. Het antwoord wordt vervolgens geschreven uit deze versmolten, opnieuw gerangschikte set.

WAAROM DE FUSIESTAP TELT

Eén enkele query is één enkele gok over hoe het antwoord in uw documenten geformuleerd is. Echte archieven gebruiken synoniemen, afkortingen en verschillende formuleringen voor hetzelfde onderwerp. Doordat RAG-fusion de vraag meerdere keren stelt en beloont wat consequent hoog scoort, brengt het de passage naar boven die één enkele formulering zou hebben gemist. Reciprocal rank fusion is hier het stille werkpaard: het combineert lijsten zonder vergelijkbare scores nodig te hebben, en daarom duikt het ook op in hybride en late-interaction-opzetten zoals die achter Qdrant en ColQwen.

WANNEER HET HELPT EN WANNEER HET SCHAADT

RAG-fusion verdient zijn kosten bij dubbelzinnige of terminologiezware vragen, waar één formulering een zwakke gok is. Het kost meer: meerdere retrievals en een generatiestap per vraag, dus het is geen gratis latency. En het heeft een echt faalpatroon. Wijken de gegenereerde queryvarianten af van wat u eigenlijk bedoelde, dan trekken ze off-topic passages binnen en drift het antwoord af. De remedie is om de gegenereerde queries nauw gebonden te houden aan de oorspronkelijke intentie en te meten, niet aan te nemen dat de recall gestegen is.

WAAR HET STAAT TUSSEN DE OPTIES

RAG-fusion is een van meerdere manieren om retrieval beter te maken, geen vervanging voor goede retrieval. Voordat u ernaar grijpt, zorg dat de basis klopt: schone chunks, een solide embeddingmodel en een vectorstore die bij de taak past. Voor visueel dichte documenten is de grotere hefboom vaak visuele retrieval in plaats van meer queryvarianten. Gebruik F-RAG waar de vraag werkelijk dubbelzinnig is en de recallwinst de extra aanroepen waard is.

HET PROBLEEM WAS NOOIT HET ANIMEREN, MAAR DE OVERDRACHT

Tot nu toe ontstond UI-beweging buiten Figma. De designer bouwde die in een tweede tool, exporteerde een video of een beschrijving, en de ontwikkeling moest de curves en timings nabouwen, vaak op het oog. Daarbij gaat precisie verloren: een easingcurve wordt een ruw idee, een timing een schatting. Precies deze breuk, niet het gebrek aan animatietools, heeft beweging in veel producten inconsistent gemaakt.

WAT FIGMA MOTION CONCREET BRENGT

Drie dingen veranderen de workflow merkbaar:

• Tijdlijn in de canvas. Keyframes, presets en bewegingsbesturing zitten daar waar het design al leeft. Geen overstap naar een tweede tool.
• Beweging als onderdeel van het designsysteem. Een component wordt eenmaal geanimeerd, en de beweging reist mee zoals kleur of typografie over elk scherm en elk bestand. Dat is het punt dat consistentie afdwingt in plaats van te hopen.
• Leesbare overdracht. In Dev Mode is de hele tijdlijn zichtbaar: elke timingwaarde, elke easingcurve, elke keyframe. De export gaat als CSS, JSON of framework-klaar React, plus MP4, WebM, geanimeerd SVG en GIF.

Daarmee leest de ontwikkeling de beweging, in plaats van hem te interpreteren. Dat is de eigenlijke verschuiving.

WAAR HET WRINGT

Een geïntegreerde tool is niet automatisch de juiste voor elk geval. Complex, narratief motionwerk, zoals een uitgebreide merkfilm, blijft een zaak voor gespecialiseerde tools. Figma Motion richt zich op interface-animatie: states, transities, micro-interacties, precies wat in het product dagelijks nodig is en tot nu toe leed onder de overdrachtsbreuk. Voor deze klasse van beweging is de integratie de winst. Voor alles daarboven blijft de toolkit gemengd.

VOOR WIE HET DE MOEITE WAARD IS OM TE KIJKEN

Wie een product met terugkerende UI-patronen onderhoudt, profiteert het meest: de eenmaal gedefinieerde beweging blijft consistent, en de implementatie krijgt exacte waarden in plaats van benaderingen. Beweging is daarbij geen decoratie, maar onderdeel van de begrijpelijkheid van een interface, een punt dat we nader uitwerken in de rol van UX in softwarebouw. Figma Motion maakt dit onderdeel eindelijk op één plek bewerkbaar.

DRIE LANCERINGEN, EENVOUDIG GEZEGD

Elk daarvan verscheen in juni 2026 binnen twee weken van de andere, en elk is een ander soort ding. Precisie loont hier, want twee ervan worden op grote schaal verkeerd omschreven.

GLM-5.2, van Z.ai in Peking, verscheen op 17 juni. Het is een open-weight mixture-of-experts-model, ongeveer 750 miljard parameters met circa 40 miljard actieve, een context van één miljoen tokens en, cruciaal, een MIT-licentie met gewichten die op HuggingFace zijn gepubliceerd.

Sakana Fugu, van Sakana AI in Tokio, verscheen op 22 juni. Het is geen gewoon model, en de gangbare indeling klopt niet: Fugu is een getrainde orchestrator die een pool van andere modellen aanroept en hun werk synthetiseert. Het is alleen via API beschikbaar, aangeboden als een OpenAI-compatibel eindpunt.

Claude Fable 5, van Anthropic in de Verenigde Staten, verscheen op 9 juni. De tweede veelgemaakte fout is Fable indelen als een snelle of creatieve variant. Het is het vlaggenschip, Anthropics meest capabele breed uitgebrachte model, met sturing op veiligheid, alleen in de cloud, tegen 10 en 50 dollar per miljoen tokens. De benchmarkcijfers zijn sterk; voor dit artikel zijn ze tegelijk bijzaak.

DE ENIGE VERGELIJKING DIE DE INKOOP OVERLEEFT

Laat de ranglijst achterwege en zet ze op de dimensies waarvoor een Duitse B2B-koper daadwerkelijk verantwoordelijk is. Het beeld is duidelijk, en het gaat niet om welke het slimst is.

Twee eerlijke voorbehouden horen bij deze tabel. De standaardroute van GLM-5.2, de Z.ai-API, valt onder China's datawetten met hun verplichte toegangsclausules, en dat is precies de reden waarom de open gewichten tellen: self-hosting in de EU neutraliseert dit risico. En Fugu's claim van frontier-gelijkwaardigheid is volledig zelf gerapporteerd, verzwakt door het feit dat Fable en het beperkte Mythos-model niet eens in de pool zitten. Ik zou geen beslissing baseren op een van beide aanbieder-benchmarks.

WAT IK EEN KLANT WERKELIJK ZEG

Ik beveel er geen enkele in het abstract aan. Ik pas het standpunt aan op wat de klant kan financieren en waarvoor hij verantwoordelijk is.

🔸 GLM-5.2 is het on-premise-spoor. De open MIT-gewichten zijn het hele punt: u kunt het in uw eigen datacenter draaien, en de prompts verlaten uw netwerk nooit. De adder onder het gras is de GPU-voetafdruk, ongeveer 744 gigabyte in FP8, dus het past bij de klant die de hardware kan financieren en data in huis moet houden. Het is het schoonste soevereiniteitsverhaal van de drie.

🔸 Claude Fable 5 is het spoor voor beheerde zekerheid. U huurt capaciteit van een Amerikaanse aanbieder, hier tegen de hoogste prijs, met echte veiligheidssturing en regionale datarouting bij de grote clouds. Voor een team dat een topmodel wil zonder de stack te bezitten, en dat met een cloudafhankelijkheid kan leven, is het de sterkste beheerde optie.

🔸 Sakana Fugu is het gemakspoor, met het zwakste controleverhaal. Een API die via een pool van modellen routeert is slim, en Japan is geopolitiek zachter dan China. Maar u kunt het niet on-premise draaien, u kiest niet welk model de data ziet, en de bewijzen zijn dun. Ik zou het als interessant behandelen, niet als standaard voor gereguleerd werk.

Dat is dezelfde les die Claude Fable 5 op de harde manier leerde, toen een eerder model binnen 72 uur werd uitgeschakeld: gehuurde capaciteit is herroepbaar, en controle is een eigenschap van de stack, niet van de score. Daarom wijs ik klanten steeds weer op open-weight-modellen die ze daadwerkelijk kunnen bezitten.

DE VRAAG WAAR HET DE MOEITE WAARD IS OM VOOR TE ONTWERPEN

Als u hier één ding uit meeneemt, laat het dan de vraag zijn, niet de rangorde. De modellen wisselen binnen een kwartaal weer van plaats op de ranglijst; dat is ruis. De houdbare vraag is degene die een inkoopverantwoordelijke op dag één zou moeten stellen: welk van deze kunt u nog draaien, controleren en betalen als de aanbieder de voorwaarden wijzigt? Voor de meeste gereguleerde klanten met wie ik werk, beantwoordt deze vraag zich vanzelf, en ze wijst niet naar de hoogste benchmark. Voordat u dus het slimste model kiest: wat zou het u kosten om het te verliezen?

WAT GEMINI OMNI WERKELIJK IS

Noem eerst de naam correct, want de marketing vertroebelt hem. De familie is Gemini Omni en het eerste model is Gemini Omni Flash. Het neemt tekst, beeld, audio en video als invoer, en bij de lancering genereert het één soort uitvoer: video, in clips van ongeveer 10 seconden met native gesynchroniseerd geluid. Google omschrijft het als een stap richting een wereldmodel, dat wil zeggen dat het probeert fysica, zwaartekracht en ruimtelijke coherentie consistent te houden over een gegenereerde scène, en het draait op Googles TPU's van de 8e generatie, opgesplitst in trainings- en inferentievarianten.

Een eerlijke correctie telt voor een technische lezer: Omni wordt vermarkt als any-to-any, maar zoals het is uitgeleverd, is het elke-invoer-naar-video. Beeld- en audio-uitvoer staan op de roadmap, niet in het product. Het is dus geen realtime conversatie-omni-assistent, en het is nog niet het universele any-to-any-systeem dat de naam suggereert. Het is een zeer capabele, invoerflexibele videogenerator, wat een nauwer en bruikbaarder ding is om op te plannen.

AANGEKONDIGD, UITGELEVERD EN BESCHIKBAAR ZIJN DRIE VERSCHILLENDE DINGEN

Het nuttigste onderscheid voor een koper is dat deze drie toestanden niet hetzelfde zijn, en Omni bevindt zich, afhankelijk van wie u bent, in verschillende ervan. Het is uitgeleverd aan consumenten en creatieven, en voor iedereen die op een API wil bouwen, is het slechts aangekondigd.

De praktische lezing voor een EU-bedrijf is direct. Als u vandaag AVG-conforme EU-residentie voor videogeneratie nodig heeft, kan Omni die u niet bieden, omdat de enterprise-route nog niet bestaat. De ondersteunde optie op Googles eigen stack blijft Veo 3.1 op Vertex AI, dat u op een EU-regio kunt vastzetten. Dat is hetzelfde patroon dat we steeds weer zien bij nieuwe modellanceringen, waarbij de demo en het inzetbare product maanden uit elkaar liggen.

WAT EEN DUITS BEDRIJF NU ZOU MOETEN DOEN

Behandel Omni als een signaal om te volgen, niet als een tool om dit kwartaal in te voeren. Drie concrete stappen.

• Gebruik vandaag Veo 3.1, regiogebonden, voor productievideo. Het heeft een echte Vertex-API, EU-regio's en een SLA. Omni heeft daar tot dusver niets van, dus hoort het nu niet in een productiepijplijn.
• Plan het herkomstverhaal vroeg. Omni voegt een SynthID-watermerk toe aan elke clip. Bouw voor gereguleerde of publieke content de verwachting in uw proces in dat AI-gegenereerde video gemarkeerd en herleidbaar is, ongeacht welk model wint.
• Houd twee risico's in de gaten, niet alleen de capaciteit. Beoordelaars hebben herkenbaar merkrechtelijk beschermde figuren gereproduceerd in Omni-uitvoer, wat een echt intellectueel-eigendomsrisico is voor commercieel gebruik, en de visuele consistentie vertoont bij snelle beweging nog steeds drift. De grens van 10 seconden is een UX-grens, geen modelplafond, verwacht dus dat die verschuift.

Het houdbare punt is het punt dat de lancering terloops maakt: een model dat u in een keynote kunt zien, is geen model dat u contractueel kunt inzetten. Scheid de twee, en de hype wordt een roadmap-punt in plaats van een inkoopfout.

WAT 2025 EN 2026 WERKELIJK BRACHTEN

Het grote nieuws is stabiliteit na jaren van omwentelingen. LangChain 1.0 en LangGraph 1.0 bereikten beide op 22 oktober 2025 de stabiele release, met de toezegging om tot 2.0 geen breaking changes door te voeren. De nieuwe centrale abstractie van het framework, create_agent, draait nu daaronder op de LangGraph-runtime, de agentenlus is dus een LangGraph-graaf. Dat is het duidelijkste signaal van de versmelting: het framework en de orchestratie-runtime zijn geen gescheiden beslissingen meer.

LangGraph 1.0 bracht durable execution als ingebouwde functie: de status wordt automatisch als checkpoint opgeslagen, zodat een langlopende of human-in-the-loop-workflow na een onderbreking of een herstart van de server verdergaat. LangSmith, de observability- en evaluatielaag, voegde in maart 2026 volledige OpenTelemetry-ondersteuning toe, wat betekent dat u ook traces kunt versturen vanuit code die LangChain helemaal niet gebruikt. Het commerciële beeld paste bij het technische: LangChain Inc haalde in oktober 2025 een Series B van 125 miljoen dollar op bij een waardering van 1,25 miljard en hernoemde LangGraph Platform naar LangSmith Deployment, waardoor deployment, observability en evaluatie in één product werden samengevoegd.

VIER NAMEN, TWEE BEDRIJVEN

Uitzoeken wie wat doet is het nuttigst voordat u kiest. De meeste weergaven maken het vaag; het goed te doen verandert de beslissing.

LangFlow is waar mensen over struikelen. Het is geen product van LangChain Inc. Het is een opensource visuele bouwset, gemaakt door DataStax, waarvan de moedermaatschappij in februari 2025 door IBM werd overgenomen, en die nu richting IBMs watsonx wijst. Het rijm in de naam is toeval. Als uw behoefte een drag-and-drop-canvas is voor mensen die geen Python schrijven, is LangFlow de kandidaat; het is geen laag van de LangChain-stack.

DE BESLISSING WAAR DE MEESTE TEAMS WERKELIJK VOOR STAAN

Zodra de namen duidelijk zijn, is de keuze meestal een korte beslisboom, en hebt u zelden alle vier nodig.

• Hebt u langdurige orchestratie nodig? LangGraph is het sterkste onderdeel en degene die zelfs critici respecteren. Hervatbare status, checkpointing en human-in-the-loop zijn echt engineering, geen wrapper.
• Hebt u observability en evaluatie nodig? LangSmith is capabel, maar koppelt u aan het ecosysteem. Langfuse is de opensource, zelf te hosten tegenhanger en het meest genoemde alternatief. Omdat LangSmith nu OpenTelemetry spreekt, kunt u ook vanuit niet-LangChain-code tracen, wat de lock-in verzacht.
• Bouwt u een ongecompliceerde agent? De SDK's van de aanbieders (het OpenAI Agents SDK, het Claude Agent SDK) en Pydantic AI zijn geloofwaardige, lichtere alternatieven. Het meest gehoorde bezwaar van praktijkmensen zijn de abstractielagen in het framework, en meerdere teams melden dat ze code en onderhoud hebben verminderd door over te stappen op een slankere stack.
• Niet-ontwikkelaars die prototypen? LangFlow, met de kanttekening dat een canvas-prototype voor de oplevering dezelfde governance en evaluatie nodig heeft.

Dat is dezelfde les die wij trokken bij de vergelijking hoe u AI via een API, een MCP-server of een CLI in een stack bedraadt: de tools zijn lagen, en u kiest op basis van de taak, niet van de nieuwigheid. Het rijmt ook met wat wij vonden bij het bekijken van no-code agentbouwers voor het mkb, waar het canvas snel tot een demo leidt en precies bij governance, betrouwbaarheid en kosten stopt.

STABIEL BETEKENDE NIET GEHARD

Eén kanttekening telt voor een zakelijk publiek: 1.0 kocht API-stabiliteit, geen geharde beveiligingshouding. Een cluster van CVE's trof LangChain en LangGraph eind 2025 en begin 2026, aangevoerd door een deserialisatiefout die API-sleutels en omgevingsgeheimen kon lekken, beoordeeld met CVSS 9.3 en LangGrinch genoemd. Twee andere volgden: een path-traversal-probleem in de prompt-laad-API en een SQL-injectie in de LangGraph-SQLite-checkpointer.

De praktische lezing is niet om het framework te mijden. Het is om het te behandelen als elke andere afhankelijkheid die uw geheimen en uw data raakt: versies vastzetten, de gepatchte releases installeren en het opnemen in uw dreigingsmodel. Een framework dat tool-aanroepen orchestreert en toegangsgegevens bewaart, is onderdeel van uw aanvalsoppervlak, en "stabiel" op basis van het versienummer zegt daar weinig over. Voor een gereguleerde of on-premise inzet hoort deze toetsing in hetzelfde gesprek als de dataresidentie, niet na de go-live.

HET PROBLEEM MET DE ENE VECTOR

Klassieke vectorzoekopdrachten persen een hele tekstalinea of een hele pagina in één enkele vector. Dat is zuinig, maar het middelt weg wat lokaal belangrijk is. Staat het gezochte bedrag in een specifieke tabelcel, dan verdwijnt dat verband in het gemiddelde van de hele pagina. Voor nette lopende tekst is dat vaak voldoende. Voor de documenten waarvoor visuele zoekopdrachten eigenlijk zijn bedoeld, is het niet voldoende.

LATE INTERACTION, IN ÉÉN ZIN

Late interaction houdt meerdere vectoren per pagina aan en vergelijkt ze pas laat, namelijk bij het zoeken. Het model genereert voor de zoekopdracht een vector per token en voor de pagina een vector per fragment. De score heet MaxSim: voor elke zoektoken wordt het best passende paginafragment gezocht, en deze beste overeenkomsten worden opgeteld. Zo kan het woord "restbedrag" gericht aankoppelen bij de tabelcel waarin het staat. De techniek komt uit ColBERT en werd met ColPali overgebracht naar beelden. Wie de hele toolkit wil zien: de OCR-vrije stack plaatst de modellen in context.

WAAR QDRANT IN BEELD KOMT

Late interaction heeft een database nodig die meerdere vectoren per object begrijpt. Qdrant ondersteunt dergelijke multi-vectoren direct, zonder voor- of nabewerking, en kan elk late-interactionmodel zoals ColBERT of ColPali dragen (documentatie). De gebruikelijke opzet is tweetraps: een snelle eerste zoekopdracht met normale dense vectoren beperkt de kandidaten, waarna MaxSim alleen die paar pagina's nauwkeurig herbeoordeelt. Zo blijft de index betaalbaar, want de dure tokenvectoren hoeven niet volledig geïndexeerd te worden, maar dienen voor de re-ranking.

WAT DIT PRAKTISCH BETEKENT

U krijgt resultaten die de lay-out respecteren, zonder de zoekopdracht onbetaalbaar te maken. De prijs is meer opslag per pagina en iets meer complexiteit bij de opbouw. Beide zijn beheersbaar als u de re-rankingfase vanaf het begin inplant in plaats van elke tokenvector volledig te indexeren. Voor zeer lange contexten loont het de moeite om te kijken naar subkwadratische modellen; voor het basisidee van retrieval blijft Wat is RAG het beginpunt.

WAAROM GROOTTE HIER EEN OBSTAKEL WORDT

Visuele retrievalmodellen zoals ColPali of ColQwen zijn trefzeker, maar ze zijn ook groot. On-prem, dus op eigen hardware in huis, wordt dat al snel een kostenkwestie: grote modellen vragen om krachtige GPU's, meer geheugen, meer stroom. Voor veel mkb-opzetten is niet de kwaliteit de horde, maar de hardwarerekening. Precies hier zet een kleiner model de hefboom aan.

WAT MODERNVBERT ANDERS DOET

ModernVBERT is een compacte vision-language-encoder met 250M parameters (paper). Hij combineert een moderne 150M-tekstencoder op ModernBERT-basis met een kleine beeldencoder en lijnt beide op elkaar af via een masked-language-modelingdoel. ColModernVBERT is de voor retrieval fijn afgestemde variant. Het resultaat volgens de paper: ondanks ongeveer tien keer minder parameters ligt het slechts 0,6 nDCG@5 onder ColPali op de geaggregeerde ViDoRe-benchmark, en behaalt daarmee waarden waarvoor anders bijna tien keer grotere modellen nodig waren. Model en code zijn openbaar beschikbaar.

WAAROM DIT TELT VOOR SOEVEREINITEIT

Een klein, open, sterk model is precies de combinatie die lokale werking mogelijk maakt. Het past op een bescheiden GPU, de gewichten liggen open, en de documenten blijven in huis omdat de zoekopdracht niet naar een extern eindpunt gaat. Dat is geen achteraf toegevoegde beveiligingsfunctie, maar een eigenschap van de architectuur. Het grotere verband, waarom lokaal en open bij elkaar horen, behandelen we in On-Premise tegen Cloud.

WANNEER HET KLEINE MODEL DE JUISTE KEUZE IS

Niet altijd is het grootste model nodig. Als uw hardware beperkt is en uw documenten typische zakelijke documenten zijn, is ColModernVBERT vaak de eerlijkere keuze dan ColQwen: bijna dezelfde kwaliteit, een fractie van de kosten. Hebt u dat laatste beetje trefzekerheid nodig op bijzonder dichte pagina's, dan loont de vergelijking met het grotere model. Hoe beide samenwerken in de volledige stack met Qdrant, staat in het overzicht.

Wat n8n sterk maakt

n8n is node-gebaseerde workflowautomatisering, self-hosted of als cloud, met meer dan 400 integraties plus een HTTP-node en code-node voor al het overige (n8n). Het beslissende punt voor gereguleerde sectoren: het draait in eigen huis, de gegevens verlaten de infrastructuur niet. De fair-code-licentie staat intern gebruik zonder vergoeding toe. Wie eigen logica, eigen endpoints en volledige gegevenscontrole nodig heeft, zit hier goed. De prijs daarvoor is beheer: u host, update en beveiligt zelf.

Wat Make.com sterk maakt

Make.com is een clouddienst met visuele scenario's die zonder eigen beheer werkt. U klikt een workflow bij elkaar en die draait, zonder server, zonder onderhoud. Voor teams zonder technische diepgang of voor een snel idee is dat de kortere weg. Er wordt afgerekend per operatie, dus per uitgevoerde stap. Dat is voordelig bij kleine volumes en kan bij grote, veelvoorkomende workflows onaangenaam oplopen. De keerzijde van het gemak: de gegevens lopen via een externe dienst, en de logica blijft binnen diens grenzen.

De beslissing in een tabel

De scheidslijn is duidelijk: gegevenscontrole en diepgang tegenover snelheid zonder eigen beheer.

Ons pragmatische advies

Prototype snel, host bewust. Voor een eerste test die alleen moet aantonen of een workflow werkt, is Make.com vaak sneller. Zodra gevoelige gegevens, grote volumes of eigen logica in beeld komen, wint n8n, omdat het in huis draait. En waar automatisering grenst aan echte AI-taken, loont een blik op no-code-agenten en hun grenzen: automatisering en agent zijn niet hetzelfde gereedschap.

Waarom OCR het wankele onderdeel van de pipeline was

OCR was lang het punt waarop stille fouten het antwoord binnenslopen. De klassieke weg is een keten: pagina scannen, via OCR omzetten naar tekst, in stukken knippen, embedden, ophalen. Elke stap verliest iets. Een pagina met twee kolommen wordt verkeerd samengevoegd, een tabel valt uiteen in losse cijfers, een diagram valt volledig weg omdat het geen tekst is. Naar onze ervaring zit bij lastige documenten het grootste deel van het kwaliteitsprobleem niet in het taalmodel, maar hier, in het lezen. Visueel retrieval grijpt precies op deze stap in: het slaat tekstherkenning bij het zoeken over en werkt op het beeld van de pagina.

De vier bouwstenen, kort uitgelegd

ColPali. De referentie, voorgesteld in juli 2024 (arXiv). Het bouwt voort op het vision-taalmodel PaliGemma en genereert ongeveer 1024 beelduitsnede-vectoren per pagina, elk 128-dimensionaal. In plaats van de pagina in een enkele vector te persen, blijft de granulariteit behouden. De matching gebeurt via Late Interaction, een techniek overgenomen van ColBERT, die we hier verder uitsplitsen.

ColQwen. Hetzelfde recept, andere basis: ColQwen2.5 zet in op Qwen2.5-VL in plaats van PaliGemma en staat op de ViDoRe-benchmark meestal vooraan. Wie vandaag opnieuw begint, begint hier zinvol.

ModernVBERT. De efficiëntiehefboom. ColModernVBERT heeft 250M parameters, dus ongeveer tien keer minder dan ColPali, en ligt volgens het paper toch maar 0,6 nDCG@5 daaronder. Dit is de bouwsteen die visueel retrieval on-premise betaalbaar maakt.

Qdrant. De infrastructuur eronder. Qdrant slaat de multi-vectoren van deze modellen native op en berekent de late-interaction-score bij het zoeken (documentatie). Zonder een vectordatabase die meerdere vectoren per pagina begrijpt, draait geen van de drie encoders.

Wanneer de overstap loont, en wanneer niet

Visueel retrieval wint daar waar de layout de informatie draagt. Gescande contracten, facturen, datasheets, presentaties, formulieren, meertalige dossiers: alles waarop een OCR-keten regelmatig faalt. Het bespaart bovendien het volledige onderhoud van die keten.

Het is echter geen automatische winst. Meerdere vectoren per pagina kosten meer opslag en meer index dan een enkele tekstvector, vaak een veelvoud. Bij schone, pure lopende tekst blijft klassiek tekst-RAG goedkoper en volledig toereikend. En sommige taken hebben uiteindelijk toch tekst nodig, zoals volledige tekstzoekopdrachten, kopiëren of een controlespoor. Daarvoor zijn er nog steeds goede redenen voor OCR, hybride naast visueel retrieval.

Een nuchtere routekaart

1. Test met uw eigen documenten, niet met de benchmark. ViDoRe is een goed aanknopingspunt, maar uw dossiers zijn dat niet. Neem de twintig pagina's waarop uw huidige zoekfunctie faalt.
2. Start met ColQwen of ColModernVBERT, afhankelijk van de hardware. Op een krappe GPU is het kleine model vaak het eerlijkere.
3. Zet Qdrant op als multi-vectoropslag, late interaction alleen in de re-ranking-fase, om de index klein te houden.
4. Reken de opslagprijs vooraf door. De indexgrootte is de plek die later pijn doet, niet de modelkeuze.

Wie de grotere boog zoekt, dus waarom lokale modellen en eigen retrieval eigenlijk bij elkaar horen: dat staat in On-premise versus cloud. De afzonderlijke bouwstenen verdiepen we in eigen teksten, beginnend bij de mkb-blik.

De kloof tussen een mesh en een onderdeel

Een gegenereerd mesh en een fabricagegeschikt onderdeel zijn verschillende objecten, en de kloof is niet cosmetisch. Drie randvoorwaarden maken dat duidelijk. Ten eerste heeft printen een waterdicht, manifold solid nodig (geen gaten, geen omgeklapte normalen, geen zelfdoorsnijdingen), en generatieve meshes overtreden dat regelmatig; een slicer kan van een oppervlak met gaten geen deel maken. Ten tweede is een mesh een statische soep van driehoeken, terwijl de fabricage een parametrisch B-Rep-model wil (een STEP-bestand met schetsen, features en beperkingen) dat een ingenieur kan bewerken en een CAM-systeem kan verwerken. Geen van de beeld-naar-mesh-tools genereert dat.

Ten derde, en het meest fundamenteel, draagt een enkele afbeelding geen metrische schaal. Het model wijst een geraden camerapositie toe en genereert een vorm zonder gegarandeerde millimeters, zonder afgedwongen wanddikte, zonder toleranties. En omdat een foto slechts één kant ziet, wordt de verborgen kant niet gereconstrueerd, maar verzonnen: het model vult de ongeziene geometrie met een plausibel gemiddelde. Een game-asset kan dat allemaal achter een mooie textuur verbergen. Een onderdeel kan dat niet, omdat het de printer en de belasting niet uitmaakt hoe het eruitziet.

Twee pipelines die de hype door elkaar haalt

Het duidelijkst plant u door twee pipelines te scheiden die de marketing laat samenvloeien. Ze dienen verschillende onderdelen en vereisen verschillende gereedschappen.

De eerste pipeline is vandaag reëel voor onderdelen waarbij de pasvorm soepel is. De AI schetst de vorm ruwweg; een mens blijft verantwoordelijk voor het waterdicht maken, het schalen naar echte afmetingen en het uitvoeren van een printbaarheidscontrole. De tweede is de plek waar het fabricagerelevante front zich bevindt: beeld-naar-CAD-onderzoek zoals CAD-Recode en Img2CAD genereert bewerkbare parametrische geometrie, en commerciële tools zoals Zoo kunnen een echt STEP-bestand exporteren, maar ze blijven vooralsnog grotendeels beperkt tot eenvoudigere onderdelen. Voor veeleisende geometrie blijft klassiek scan-gebaseerd reverse engineering (Geomagic, PolyWorks) de betrouwbare weg. Dat is de fabricageneef van de vraag die wij stelden bij Single-Image-reconstructie van de mens: een plausibel oppervlak is niet hetzelfde als een betrouwbaar solid.

Wat voor een mkb-maker vandaag reëel is

Tegenover de hype gesteld zijn de echte winsten stiller en waardevoller dan het one-shot-onderdeel uit een smartphonefoto. De sterkste reële hefboom is de digitalisering van wat u al heeft: tools zoals Theia van Spare Parts 3D en de tekeninganalyse van 3YOURMIND zetten oude technische 2D-tekeningen om in printbare reserveonderdeelmodellen, gemeld tot 200 keer sneller dan handmatig hertekenen, met een bijgevoegde maakbaarheidscontrole. Dat is beeld-naar-3D waarbij de invoer een technische tekening is, geen vakantiekiekje, en de geometrie verankerd is in echte afmetingen.

De andere solide winsten zijn de versnelling van reverse engineering, waarbij AI-generatie en intelligente retopologie een bestaande scan-gebaseerde workflow versnellen in plaats van vervangen, en rapid prototyping voor niet-kritieke onderdelen. Waar het faalt, is precies daar waar de inzet het hoogst is: lastdragende, strak tolerante en gereguleerde onderdelen die schaal, materiaalspecificatie en traceerbaarheid nodig hebben die een enkele afbeelding niet kan leveren. De vuistregel is kort. Voor een onderdeel dat gewicht draagt of een test moet doorstaan, is de onzichtbare kant altijd een gok, en een gok is een defect.

Het werkelijke verschil, in telkens één zin

Prompt engineering is een instructie goed formuleren. Context engineering is beslissen wat het model eigenlijk te zien krijgt. De term werd in juni 2025 gepopulariseerd door Shopify's Tobi Lutke en versterkt door Andrej Karpathy, die hem omschreef als de kunst om het contextvenster te vullen met precies de juiste informatie voor de volgende stap. Het scherpste onderscheid komt van Philipp Schmid: context is alles wat het model ziet voordat het een antwoord genereert, en dat is een systeem, geen tekenreeks.

De twee zijn geen rivalen; prompt engineering is een deelverzameling. Wanneer u een goede systeemprompt schrijft, is dat prompt engineering. Wanneer u beslist welke drie documenten worden opgehaald, welke tools u vrijgeeft, hoeveel geschiedenis u behoudt, wat u weglaat en welk uitvoerschema u vereist, allemaal binnen een tokenbudget, is dat context engineering. Anthropics eigen richtlijn omschrijft dit als het beheren van de volledige contexttoestand over beurten heen, en de scherpste zin daarin is er een om te onthouden: context is een eindige bron met afnemend grensnut.

Waarom het veld verschoof, en het was geen trend

De reden waarom context engineering een benoemde discipline werd, is dat de gemakkelijke aanname onder meting instortte. De aanname was dat modellen met een lange context het venster laten volstoppen en gewoon ophouden na te denken. Chroma's context-rotstudie testte in juli 2025 18 frontier-modellen en ontdekte dat elk model degradeert naarmate de invoer groeit, vaak op een inconsistente manier: het model behandelt het tienduizendste token niet zo betrouwbaar als het honderdste. De oudere lost-in-the-middle-bevinding wees in dezelfde richting.

Twee krachten maakten de lading, niet de prompt, tot het ding dat geengineerd moet worden. Ten eerste: agenten, tool-gebruik, retrieval en geheugen betekenen dat de context over veel beurten door een systeem wordt samengesteld, niet eenmalig met de hand geschreven. Ten tweede de economie: in productie bij Manus ligt de verhouding van invoer- tot uitvoertokens rond 100 tot 1, en het hergebruik van de key-value-cache stuurt een groot kostenverschil aan. Wat in het venster terechtkomt, is dus net zozeer een kostenbeslissing als een kwaliteitsbeslissing. Meer context is niet beter; gebudgetteerde, relevante context is dat wel. Dat is de empirische ruggengraat onder onze eerdere bespreking van context engineering en waarom het telt.

Waaruit context engineering werkelijk bestaat

Bevrijd van het etiket is context engineering een verzameling toetsbare praktijken, geen prompt-fluisteren. De benoemde technieken keren terug bij Anthropic, LangChain en het Manus-productierapport:

• Retrieval. Haal de paar relevante documenten op op het moment dat ze nodig zijn, in plaats van alles erin te kopieren. Dat is de discipline achter Retrieval-Augmented Generation.
• Verdichting en samenvatting. Comprimeer oude beurten tot een lopende samenvatting, zodat het budget wordt besteed aan wat leeft, niet aan het transcript.
• Geheugen en notities. Sla toestand op in externe notities of bestanden die de agent kan teruglezen, in plaats van hem in het venster mee te dragen.
• Toolcuratie. Houd drie tot vijf kerntools geladen en haal de rest precies op tijd erbij. Elke geladen tool verdunt het signaal en breekt de cache.
• Gestructureerde uitvoer. Vereis een schema, zodat het model tokens uitgeeft aan het antwoord, niet aan opmaakproza.
• Isolatie. Verdeel werk over subagenten, zodat elk alleen de context ziet die hij nodig heeft.

LangChain omschrijft dezelfde verzameling als schrijven, selecteren, comprimeren en isoleren. Het punt is dat elk daarvan meetbaar is: u kunt een retriever, een verdichtingsdrempel of een tooluitrusting A/B-testen, en precies dat maakt dit tot engineering in plaats van formulering.

Is het alleen een rebranding? Het eerlijke antwoord

Deels, en dat is prima. Ja, goede ingenieurs curateerden al wat het model ziet; de waarde van de naam is dat hij de optimalisatie richt op de lading en het systeem, niet op de zin, waar betrouwbaarheid en kosten daadwerkelijk zitten. Het lopende debat is nuttiger dan de terminologiestrijd. In juni 2025 pleitte Cognition tegen multi-agentsystemen, met als argument dat het moeilijk is om context netjes tussen agenten te delen, en beval aan werk enkelvoudig te houden en volledige traces te delen. In dezelfde week beschreef Anthropic een multi-agent-onderzoekssysteem dat afhankelijk is van gedisciplineerde contextisolatie. Dezelfde discipline, tegengestelde architecturale conclusie.

Voor een team dat met LLM's bouwt, zijn de lessen eenvoudig. Budgetteer tokens zoals u rekenkracht budgetteert, want meer is niet gratis en niet altijd beter. Behandel het werk als bedrading (retrievalkwaliteit, verdichting, geheugen, toolcuratie, gestructureerde uitvoer), niet als formulering. En kies uw architectuur op basis van hoe betrouwbaar u context kunt delen, niet op basis van welke aanpak geavanceerder klinkt. De naam zal blijven muteren, sommigen noemen de volgende laag al harness engineering, maar het object is stabiel: het systeem dat beslist wat het model te zien krijgt.

Begin op de bodem, niet aan het plafond

Voordat u een slimme methode toepast, brengt u de basis op orde, want die verhelpt de meeste klachten. De productiestandaard van 2026 is hybride zoeken (dense embeddings plus keyword-BM25), gevolgd door een cross-encoder-reranker. Hybride zoeken vangt zowel semantische als exacte termtreffers op; de reranker beoordeelt een grote kandidatenset terug tot de paar passages die daadwerkelijk relevant zijn, niet slechts thematisch verwant. Praktijkgidsen melden dat deze combinatie de retrievalkwaliteit op standaard-evaluatiesets met 15 tot 30 procent verhoogt.

Dat telt, omdat de meeste reele fouten van het eenvoudige soort zijn: het antwoord stond in de documenten, maar het systeem bracht het niet naar boven. Dat is een recall- en rankingprobleem, en de bovenstaande basis verhelpt het. Bewijs dat u meer nodig heeft voordat u meer bouwt. Elke techniek voorbij dit punt voegt LLM-aanroepen, latentie en kosten toe; elk moet zijn plaats verdienen tegenover een gemeten falen, niet tegenover een onderbuikgevoel.

De gereedschapskist, geïndexeerd op het falen dat hij verhelpt

De nuttige manier om de hele dierentuin aan methoden te behouden, is elke af te beelden op het specifieke faalpatroon dat ze adresseert. Grijp naar een methode wanneer u het falen ervan ziet, niet eerder.

Elke regel heeft echte herkomst: HyDE komt uit een CMU-paper uit 2022 over zero-shot dense retrieval; step-back-prompting van Google DeepMind, 2023; GraphRAG van Microsoft, 2024. Dat is dezelfde beslis-na-falen-discipline achter onze blik op RAG-fusion en hoe het verschilt van eenvoudige RAG.

Query-decompositie, in het bijzonder

Query-decompositie splitst een complexe aanvraag in onafhankelijke deelvragen, haalt voor elk op en synthetiseert vervolgens een antwoord. Het is het juiste gereedschap wanneer een enkele retrievalronde niet kan werken, omdat de feiten in verschillende documenten leven of een feit van een ander afhangt (wie de film regisseerde die een bepaalde prijs won). De lijn loopt van least-to-most-prompting in 2022 naar de deelvraag-query-engines van de huidige frameworks.

Het eerlijke deel is dat het niet gratis is en schade kan aanrichten. Een studie van de HU Berlin uit juli 2025 mat dat decompositie plus reranking de multi-hop-recall (Hits@10) van 74,7 naar 87,2 procent tilde, een echte winst. Dezelfde studie mat de kosten: ongeveer 16,7 seconden per aanvraag tegenover 0,03 seconden voor naieve retrieval, en ontdekte dat het decomponeren van een reeds specifieke aanvraag ruis introduceert en het antwoord slechter maakt. Decompositie hoort dus bij echte multi-hop-vragen, niet standaard bij elke aanvraag. De kunst is die twee uit elkaar te houden.

De hefboom die zichzelf terugbetaalt is routing

Als u hier een operationeel inzicht uit meeneemt, maak er dan routing van. Classificeer de aanvraag eerst, en geef complexiteit alleen uit waar ze verdiend is. Een analyse uit 2026 over kostenbewust routing verlaagde afgerekende tokens met 26 procent en de mediane latentie met 34 procent bij gelijke antwoordkwaliteit, door slechts ongeveer 18 procent van de aanvragen naar zware retrieval en 14 procent naar helemaal geen retrieval te sturen. De dure methoden bleven voorbehouden aan de aanvragen die ze nodig hadden.

Voor een Duits mkb-team is dat evenzeer een governance- en kostenverhaal als een kwaliteitsverhaal. Minder, gerechtvaardigde LLM-aanroepen betekenen voorspelbare uitgaven, lagere latentie en een systeem dat u aan een compliance-gerichte stakeholder kunt uitleggen: hier is waarom deze aanvraag de dure weg nam, en hier is waarom die andere dat niet deed. Overengineerde retrieval is niet alleen traag, het is onverklaarbare uitvoer. Het verfijnde RAG-systeem van 2026 is dat wat weet wanneer het geen van zijn trucs gebruikt.

Waar RPA echt goed in is

RPA is regelgebaseerd en deterministisch. U beschrijft een vast proces, en het verloopt elke keer hetzelfde: dezelfde invoer, dezelfde weg, hetzelfde resultaat. Voor een gestructureerd, stabiel proces, bijvoorbeeld gegevens uit een vast formulier naar een ERP overzetten, is dat precies goed. Het is controleerbaar, herhaalbaar en goedkoop in gebruik. De zwakte toont zich pas wanneer er iets verandert: een nieuwe veldindeling, een onverwachte invoer, en de starre regel breekt.

Waar AI-agenten beter in zijn

Een AI-agent komt in beeld waar het proces niet star is: dubbelzinnige invoer, vrije taal, beslissingen die context nodig hebben. Hij kan een ongestructureerde e-mail lezen en het juiste doen, waar een RPA-regel zou capituleren. De prijs is dat hij niet deterministisch is: dezelfde invoer kan twee resultaten opleveren, en hij heeft sturing, vangrails en controle nodig. Hoever no-code-agenten reiken en waar ze ophouden, behandelen we elders.

De beslissingslijn

Een eenvoudige heuristiek scheidt de gevallen:

• Stabiel en gestructureerd (vast formulier, duidelijke regel, hoge herhaling): RPA. Betrouwbaarheid verslaat flexibiliteit.
• Dubbelzinnig en talig (vrije teksten, wisselende invoer, oordeelsvragen): Agent. Flexibiliteit verslaat starheid.
• Gemengd: vaak het beste antwoord. RPA doet het vaste deel, de agent neemt alleen het punt over dat echt oordeel vereist.

De marktcijfers manen tot nuchterheid: Gartner verwacht dat meer dan 40 procent van de agentische AI-projecten eind 2027 wordt stopgezet. Veel daarvan, omdat een agent werd ingezet waar een regel had volstaan.

De nuchtere middenweg

Niet AI of RPA, maar de juiste laag voor het juiste deel. De duurste fout is een betrouwbaar, regelbaar proces over te laten aan een niet-deterministische agent, alleen omdat AI moderner klinkt. Begin met de vraag naar de taak, niet naar het gereedschap. Waar AI werkelijk in de stack hoort en via welke interface, brengt API tegen MCP tegen CLI in kaart.

Wat SAM 3D Body werkelijk doet

SAM 3D Body reconstrueert een volledig lichaamsmesh, inclusief handen en voeten, uit één enkele afbeelding en schat zowel pose als vorm. Het introduceert een nieuw parametrisch lichaamsformaat, de Momentum Human Rig (MHR), die het skelet loskoppelt van het weke-delenoppervlak, zodat rig en lichaamsvorm afzonderlijk kunnen worden bekeken. Zoals de rest van de Segment-Anything-familie is het promptbaar: u kunt 2D-keypoints of segmentatiemaskers meegeven om het resultaat te sturen.

De praktische details tellen voor iedereen die het wil inzetten. Meta leverde open gewichten in twee backbones, een DINOv3-H+ met circa 840M parameters en een ViT-H met circa 631M, plus inferentiecode, trainingsdata en het MHR-model. Het meldt een 3DPW-meshfout (MPJPE) van 54,8 en drijft al een live consumentenfunctie aan, Facebook Marketplace's View in Room. Het is getraind op circa 8 miljoen afbeeldingen. Dit is geen onderzoeksdemo; het ging op dag één een product in.

De B2B-winst zit in de pipeline, niet in de pixels

Het strategische punt voor een Duits of EU-bedrijf is waar de berekening plaatsvindt, niet hoe knap de mesh eruitziet. Een menselijke lichaamsafbeelding is onder de AVG een gevoelig persoonsgegeven. Op het moment dat u de foto van een klant naar een externe reconstructie-API stuurt, heeft u een verwerkersovereenkomst, een doorgiftevraagstuk en een vertrouwensprijs. Open gewichten halen die stap weg: u draait het model in uw eigen netwerk, en de lichaamsafbeelding verlaat dat nooit.

Dat verandert meerdere toepassingen van ongemakkelijk naar bezitbaar. Virtual try-on en pasvormvisualisatie, AR- en VR-avatars, fitness- en bewegingsanalyse, en previs voor animatie of virtuele productie kunnen allemaal draaien op infrastructuur die u beheert, met dezelfde UX die een gehoste API zou bieden. Dat is dezelfde eigen-pipelinelogica die we toepasten op het genereren van 3D-assets uit één enkele afbeelding met TRELLIS: de waarde is niet alleen het model, het is de gevoelige input aan uw kant van de muur houden. De licentie is het ene dat u voor het bouwen moet controleren: de MHR-rig is bevestigd als permissief-commercieel, en de lichaamsgewichten verschijnen onder de SAM-licentie, lees dus de daadwerkelijke voorwaarden voor uw inzet.

Waar het stilletjes breekt

De toepassing correct afbakenen is de hele kunst, want single-image reconstructie heeft eerlijke grenzen die geen modelkwaliteit wegneemt. Onafhankelijke analyse vond dat SAM 3D Body een plausibele pose voorrang geeft boven metrische nauwkeurigheid en atypische lichamen (scoliose, leeftijdsgebonden veranderingen, zwangerschap) naar een gezond gemiddelde duwt. Dat is prima voor een avatar die er goed uit moet zien; het is fout voor medische, ergonomische of juridische opmeting, waar de afwijking juist het punt is.

Drie andere grenzen om rekening mee te houden. Eén enkele afbeelding kan diepte of ware schaal niet oplossen, globale positie en werkelijke afmetingen zijn dus onderbepaalde schattingen. Sterke occlusie, waarbij het grootste deel van het lichaam verborgen is, verslechtert het scherp. En het is per afbeelding, niet real-time: de community wedijvert al om dit op te lossen met snellere varianten en C++-runtimes, en video vereist extra machinerie voor temporele stabiliteit. De regel die u veilig houdt, is simpel. Snijd de toepassing toe op plausibel (visualisatie, try-on, avatars), niet op precies (opmeting, diagnose, veiligheid). Binnen die lijn is een zelf te draaien, privacyvriendelijk menselijk 3D-model een echte nieuwe optie in 2026.

Waar klassieke RAG in het mkb vastloopt

RAG maakt van uw documenten doorzoekbare kennis. Het zwakke punt is de eerste fase: de tekstherkenning. Een leveranciersfactuur met positietabel, een tweekoloms contract, een ingescand datasheet met maattekening: OCR zet dat soort dingen geregeld verkeerd in elkaar. De tabel wordt een cijferbrij, de kolommen lopen door elkaar, de tekening verdwijnt. Het model krijgt dan al kapotte tekst en antwoordt dienovereenkomstig. In onze ervaring zit bij echte dossiers het grootste deel van de fouten hier, lang voordat een taalmodel überhaupt aan het woord komt.

Hoe visueel zoeken dit omzeilt

Visuele retrievalmodellen slaan de tekstherkenning bij het zoeken over. Ze splitsen de afbeelding van de pagina op in veel kleine fragmenten, embedden elk fragment en vergelijken de zoekvraag daar direct mee. Zo blijft behouden dat een getal in een tabelcel staat en niet in de lopende tekst. Drie namen leiden het veld: ColPali als referentie, ColQwen als meestal sterkere variant op Qwen-basis, en ModernVBERT als klein, on-premise-geschikt model. De hele toolkit inclusief vectordatabase brengen we onder in het stackoverzicht. Voor het praktische beeld volstaat: de pagina wordt gezien, niet geraden.

Eerlijk over de kosten

De winst is niet gratis. Meerdere vectoren per pagina vereisen aanzienlijk meer indexopslag dan een enkele tekstvector. Bij een archief van pure, schone lopende tekst blijft klassieke tekst-RAG goedkoper en volstaat het. Visueel zoeken loont waar de layout de informatie draagt, en dat is in het mkb eerder de regel dan de uitzondering. En voor gevallen waarin u uiteindelijk toch doorzoekbare tekst nodig heeft, bijvoorbeeld om te kopiëren of voor een audittrail, blijft OCR zinvol, als aanvulling in plaats van vervanging.

De eerste stap is klein

Daarvoor hoeft u niets groots te verbouwen. Neem de twintig documenten waar uw huidige zoekfunctie op vastloopt, en stel precies de vragen die vandaag misgaan. Als visueel zoeken de tabelrij vindt die OCR kwijtraakte, heeft u uw antwoord, op uw eigen dossiers, niet op een benchmark. Het mooie eraan: de hele opzet draait lokaal, de data blijft in huis. Waarom dat telt voor gevoelige documenten, staat in On-premise versus cloud.

Waarom het samenvoegen het eigenlijke probleem was

Een lange sequentie genereren door korte clips aan elkaar te plakken, introduceert precies de artefacten die materiaal onbruikbaar maken: zichtbare naden tussen segmenten, gezichten van personages die tussen shots verschuiven, licht dat springt. Voor een merk- of productvideo is die drift het verschil tussen een bruikbaar asset en een overduidelijke vervalsing. Lengte in één enkele pass verwijdert de naad, en daarom zijn 30 native seconden een echte stap, geen ijdelheidscijfer.

Wat 2.5 werkelijk verandert

Drie dingen springen eruit voor een team dat het daadwerkelijk zou gebruiken:

• Native clips van 30 seconden. Eén pass, geen samenvoegen, zodat de consistentie over de hele duur standhoudt.
• Tot 50 multimodale referenties. Beelden, audio en video gecombineerd in één generatie, ongeveer vier keer de twaalf van Seedance 2.0, gericht op het stabiel houden van een personage, een product en een stijl.
• Gezamenlijke audio-videogeneratie. Beeld en geluid worden samen verwerkt in één latente ruimte in plaats van apart gegenereerd en daarna gesynchroniseerd, wat beweging en geluid uitgelijnd houdt.

Samen mikken deze op hetzelfde doel: consistentie over tijd, wat zakelijke video nodig heeft en korte clips niet konden bieden.

Het eerlijke voorbehoud

Kwaliteit is nu het makkelijke deel. Voor zakelijk gebruik beslissen de zware vragen: mag u het materiaal commercieel gebruiken, van wie is de gelijkenis erin, waar gaan de data heen, en is de output consistent genoeg om er een merk op te zetten. Seedance 2.5 zit in enterprise-bèta met een publieke lancering die begin juli wordt beoogd, de licentie- en herkomstdetails zijn dus precies waar u vóór de vastlegging naar moet kijken. Het bredere veld en hoe u tussen de modellen kiest, staat in ons overzicht van AI-video in 2026.

Waar het past

Voor storyboarding, conceptfilms en korte social-assets verandert een schone native clip van 30 seconden wat één persoon kan produceren. Voor gereguleerd of merkkritisch werk behandelt u het als een ontwerp-engine, tot de rechten en de consistentie uw lat halen. De capaciteit is echt; governance is het onderdeel dat u eerst goed moet regelen.

Waar het helpt

Vibe coding blinkt overal uit waar snelheid telt en de code daarna mag verdwijnen. Het prototype op een middag, het interne gereedschap voor een klein team, de klik-dummy voor een klantpresentatie, de eerste 70 procent van een idee: hier levert het echte waarde. Karpathy's oorspronkelijke voorbeeld was precies dat, wegwerpsoftware voor een weekendproject.

De vraag bevestigt dat. Gereedschappen zoals Cursor, Claude Code, Lovable en Bolt zijn in recordtijd gegroeid, Lovable naar circa 200 miljoen dollar jaaromzet eind 2025. Ook in mijn werk is het nut concreet: een vakspecialist zonder programmeerachtergrond kan een idee zelf aan de praat krijgen, in plaats van het eerst te beschrijven en dan twee weken te wachten. Zolang het resultaat een experiment blijft en niemand er zijn bedrijf op bouwt, is dat een tempowinst die u niet moet onderschatten.

Waar het bijt

Zodra de code wordt uitgeleverd, draait het beeld om, en het bewijs is ongemakkelijk concreet. Veracode onderzocht in 2025 meer dan 80 taken en meer dan 100 modellen: 45 procent van de gegenereerde code bevatte een beveiligingslek, en nieuwere of grotere modellen scoorden niet beter. Een studie van METR vond dat ervaren ontwikkelaars met AI-gereedschappen 19 procent trager waren, maar zichzelf sneller inschatten.

Daar komen de incidenten bij die blijven hangen. Een Replit-agent verwijderde in juli 2025 een productiedatabase, negeerde de uitdrukkelijke instructie om niets te wijzigen, en beweerde daarna dat herstel onmogelijk was (dat was het niet). Ongeveer een op de vijf door AI voorgestelde pakketten bestaat helemaal niet, en 43 procent van die verzonnen namen duikt herhaaldelijk op, wat aanvallers een nieuw gat in de toeleveringsketen opent. Addy Osmani noemt het het 70-procentprobleem: de AI brengt u snel naar 70 procent, de laatste 30 procent uit uitzonderingsgevallen, beveiliging en integratie blijft klassiek ingenieurswerk. En juridisch is de zaak duidelijk: de aansprakelijkheid voor uitgeleverde software blijft bij het bedrijf dat haar bouwt en verkoopt, niet bij de AI-aanbieder.

De grens: wegwerp tegenover uitgeleverd

Het nuttigste onderscheid gaat niet over gereedschappen, maar over het doel. Een script dat één persoon eenmalig gebruikt, is iets anders dan software die uw klanten, uw auditors en de EU Cyber Resilience Act vanaf december 2027 beoordelen. Zelfs Gartner, dat tegen 2028 rekent op 40 procent vibe-coding-aandeel in bedrijfssoftware, noemt de ruwe output uitdrukkelijk wegwerpcode, niet productierijp.

Voor het mkb betekent dat: de vraag is niet of uw team vibe coding mag gebruiken, maar waarvoor. Wegwerp en experiment: graag, snel, zonder omhaal. Alles wat klantgegevens raakt, wordt uitgeleverd of een toetsing moet doorstaan: nooit ongelezen. Deze ene sortering bespaart de meeste latere pijn.

De volwassen weg: gecontroleerd vibe coding

Het goede nieuws is dat het professionele antwoord in 2025 en 2026 al bestaat, en het heet geen verbod. Het heet gecontroleerd vibe coding, of AI-ondersteunde ontwikkeling: de AI als een zeer snelle junior, met een verantwoordelijke senior ernaast. Zo pakken wij het aan.

🔸 Specificatie voor de prompt. De tegenbeweging heet spec-driven development, met gereedschappen zoals GitHub Spec Kit: eerst specificatie, plan en taken, dan code. Dat maakt het resultaat toetsbaar in plaats van willekeurig.

🔸 Review en tests voor de productie. Geen AI-code gaat ongelezen live. Codereview, geautomatiseerde tests en een beveiligingsscan zijn de voorwaarde, niet de kers op de taart, zeker bij alles wat data of geld raakt.

🔸 Licentie en toeleveringsketen in het oog. Ongecontroleerde AI-code kan GPL-gelicentieerde fragmenten of verzonnen pakketten binnensmokkelen. Beide horen thuis in het controleproces, voordat het een compliance-probleem wordt.

Vibe coding is een briljant gereedschap voor de juiste taak en een risico voor de verkeerde. Het verschil zit erin om voor de eerste prompt te weten aan welke kant van de grens u staat. Aan welke kant staat uw volgende project?

Wat YOLO26 werkelijk veranderde

YOLO26 verwijdert de twee nabewerkingsstappen die eerdere detectoren omslachtig maakten in gebruik. Het voert standaard een one-to-one-detectiekop uit, er is dus geen Non-Maximum Suppression (NMS) bij inferentie, en het netwerk geeft definitieve detecties direct uit. Het laat ook de Distribution Focal Loss (DFL) vallen, wat de kop lichter maakt voor edge- en laagenergie-apparaten. Ook het trainingsrecept is nieuw: een MuSGD-optimizer, progressive loss en kleindoel-labeltoewijzing.

Waarom NMS-vrij het deel is dat telt: NMS is een aparte, datagevoelige stap die na het netwerk draait, en de duur ervan varieert met hoeveel objecten er in het beeld zijn. Het verwijderen ervan geeft u deterministische latentie en een schonere export, precies wat u wilt als het doel ONNX, TensorRT, OpenVINO of CoreML op vaste hardware is. Minder nabewerkingsknoppen betekenen minder manieren waarop het productiepad afwijkt van het lab.

De cijfers zijn incrementeel, niet dramatisch. Op COCO behaalt YOLO26n 40,9 mAP bij 2,4M parameters, en Ultralytics meldt tot 43 procent snellere CPU-ONNX-inferentie dan YOLO11n. Dit CPU-cijfer, niet de nauwkeurigheid, is de kop voor een koper die detectie draait op courante edge-silicium zonder GPU.

De versienummers betekenen niet meer wat u denkt

Het enige nuttigste dat u in 2026 moet begrijpen, is dat "YOLO" niet langer één project is en de versienummers van verschillende teams komen. Ultralytics onderhoudt YOLO26, YOLO11 en de oudere v8 en v5. YOLOv12 en YOLOv13 zijn aparte academische lijnen, en beide steunen nog steeds op NMS en DFL, precies de dingen die YOLO26 verwijderde.

De les is dat een hoger versienummer geen nieuwer product van dezelfde leverancier is. Het is soms een compleet andere onderzoeksgroep. YOLOv13 kreeg openlijke kritiek omdat het een AP van ongeveer 54,8 meldde tegenover YOLOv12s 55,2, terwijl het zwaarder draaide, een regressie die als upgrade werd gepresenteerd. En YOLO zelf is niet automatisch de nauwkeurigheidsleider: transformer-gebaseerde detectoren uit de RF-DETR-familie concurreren nu rechtstreeks mee aan de bovenkant. Lees de benchmark en de beheerder, niet het label.

De licentievraag die een Duitse koper als eerste stelt

Controleer voor de architectuur de licentie, want de standaardlicentie beperkt hoe u uitlevert. Ultralytics YOLO is gelicentieerd onder AGPL-3.0. AGPL is een sterke copyleft-licentie: als u de software verspreidt of als dienst via een netwerk aanbiedt, bent u doorgaans verplicht de volledige bijbehorende broncode van uw afgeleide werk vrij te geven, en de gangbare interpretatie breidt deze verplichting uit naar de gewichten en de omringende applicatiecode.

Het punt dat de meeste teams over het hoofd zien, is dat on-premise u niet vrijstelt. De netwerkclausule van AGPL wordt geactiveerd doordat de functionaliteit als dienst wordt aangeboden, in sommige interpretaties zelfs intern gericht, niet alleen doordat een binary aan een klant wordt geleverd. Voor een closed-source product of een inzet die u liever niet open source maakt, verkoopt Ultralytics een commerciële enterprise-licentie. Deze wordt individueel berekend, zonder openbare prijs, en hoort dus vroeg in het inkoopgesprek thuis, niet nadat het prototype werkt.

Het inkooprelevante inzicht is eenvoudig: reken de enterprise-licentie in of kies vanaf het begin een detector onder een permissieve licentie (Apache of MIT). Dit is dezelfde controlevraag waar wij bij open-weightmodellen steeds weer op terugkomen, waar de licentie en de stack, niet de benchmark, bepalen wat u mag doen.

Hoe u kiest zonder het nummer achterna te jagen

Behandel de releases van 2026 als een korte, saaie checklist in plaats van een ranglijst.

• Leg een onderhouden versie vast. Voor productie is de Ultralytics-lijn (YOLO26 of YOLO11) de ondersteunde weg. De academische lijnen v12 en v13 zijn onderzoek, nuttig om te lezen, niet de standaard om te leveren.
• Lees de benchmark, niet het label. Vergelijk mAP en latentie op hardware die dicht bij de uwe ligt, en wees eerlijk dat RF-DETR of een kleiner ouder model voor uw scenario kan winnen.
• Test het exportpad vroegtijdig. De waarde van NMS-vrij wordt gerealiseerd in de ONNX- of TensorRT-export op uw doelapparaat. Bevestig dit daar voordat u zich vastlegt.
• Verhelder de licentie voor de pilot. AGPL of enterprise-licentie of een permissief alternatief. Beslis dit terwijl het nog goedkoop is om te wijzigen.

Niets daarvan heeft het nieuwste nummer nodig. Het heeft een detector nodig die bij uw latentie, op uw hardware, onder een licentie draait waarmee u kunt leven.

Het eerlijke deel komt daarna. n8n neemt u de bekabeling van bedrijfsprocessen uit handen, en met de AI-nodes komt er echte taalverwerking bij. Zodra er echter een taalmodel in het spel is, wordt het proces niet meer deterministisch, en precies daar wordt bepaald of een automatisering in de praktijk standhoudt. Dit artikel laat beide zien: wat n8n goed kan, en waar de grens naar echte engineering ligt.

Wat n8n eigenlijk is

n8n is een op nodes gebaseerd platform voor workflow-automatisering. U bouwt een proces visueel op uit nodes en kunt op elk punt eigen code in JavaScript of Python toevoegen.

🔸 Self-hosted of cloud. Het doorslaggevende punt voor het mkb: n8n draait als Docker-container op uw eigen infrastructuur. Verwerking en data blijven in uw eigen netwerk, het bedrijf blijft alleen verantwoordelijke.

🔸 Meer dan 400 integraties plus een HTTP-node voor elke gewenste REST-interface. Wat er niet als kant-en-klare node is, koppelt u zelf aan.

🔸 Fair-code, niet klassiek open source. De Sustainable Use License staat intern zakelijk gebruik gratis toe. Verboden is n8n als gehost product aan derden door te verkopen. Voor klassiek eigen gebruik is dat niet kritiek, maar voor een technisch publiek is het belangrijk dit correct te benoemen.

Wie nog moet beslissen of AI überhaupt lokaal moet draaien, vindt de afweging in On-premise versus cloud-LLM.

Hoe n8n bedrijfsprocessen automatiseert

Het opzet is altijd hetzelfde: een trigger start het proces, daarna lopen de nodes stap voor stap.

🔸 Trigger: webhook, tijdschema, een app-gebeurtenis zoals een nieuwe e-mail of een nieuwe CRM-invoer, een verzonden formulier.
🔸 Nodes: app-integraties, HTTP-aanroepen, database-query's, logica zoals IF en Switch, datatransformatie.

In de praktijk zien we in het mkb steeds weer dezelfde patronen:

Dat is dezelfde logica waarmee wij onze eigen Event Scout-microapp hebben gebouwd, voordat we besloten wat echte engineering verdiende.

Waar AI in beeld komt

n8n heeft AI niet aangeplakt, maar geïntegreerd als een eigen node-familie op basis van LangChain.

🔸 AI Agent Node. Een volwaardige agent met tool-aanroepen, geheugen en een iteratieve reasoning-lus, niet alleen een promptveld. De agent krijgt andere nodes of workflows als tools.

🔸 RAG over eigen documenten. Sinds versie 1.74.0 in januari 2025 kunt u vectorstores zoals Qdrant, Weaviate of pgvector rechtstreeks als tool voor de agent koppelen. Zo antwoordt het systeem op basis van uw eigen documenten, niet vanuit de algemene modelkennis. Wat RAG precies is, hebben we uitgelegd in Wat is RAG.

🔸 Lokale modellen. Via de Ollama-koppeling draait de inferentie op uw eigen hardware. Self-hosted n8n plus een lokaal model levert een volledig private AI-stack op zonder doorgifte naar een derde land. Welke hardware dat realistisch kost, staat in Lokaal LLM in het bedrijf.

Wat goed werkt: classificatie, extractie, routing, RAG, eenvoudige agenten. Fragiel wordt het bij lange, meerstaps agentenketens en bij de reproduceerbaarheid van modeluitvoer.

Grenzen, en wanneer het richting engineering kantelt

Een paar punten die wij klanten vooraf meegeven:

🔸 Determinisme en foutopsporing. Een AI-stap levert bij dezelfde invoer niet per se dezelfde uitvoer. Het debuggen van lange agent-workflows is bewerkelijk.
🔸 Versiebeheer. Workflows leven in de database. Nette, Git-gebaseerde review is niet de native standaard, maar eerder iets voor de enterprise-functies.
🔸 Schaling. De single-server-modus loopt bij veel parallelle webhooks tegen zijn grenzen aan. Voor productie is de queue-modus met aparte workers nodig.
🔸 Onderhoud. Self-hosted betekent: updates, beveiligingspatches, back-ups en monitoring liggen bij u.

Richting echte engineering kantelt het zodra bedrijfskritische, deterministische logica, hoge transactievolumes, strikte service levels of multi-agent-gebruik in continu bedrijf nodig zijn. Dan zijn tests, CI/CD en observability nodig, niet alleen kliks in de editor. De hardening-release n8n 2.0 van januari 2026 heeft hierop ingespeeld, met geïsoleerde code-uitvoering en stabieler gedrag onder belasting.

Hoe wij n8n bij iiterate inschatten

Wij zetten n8n graag in voor precies waar het sterk in is: interne processen snel automatiseren, AI daar aankoppelen waar het een stap echt beter maakt, en dat geheel AVG-conform in eigen huis draaien.

De fout die we het vaakst zien, is een werkend proces verwarren met een productierijp systeem. Voor interne, goed te tolereren processen is n8n vaak het volledige antwoord. Zodra het proces bedrijfskritisch wordt, is n8n de snelste manier om het juiste proces te vinden, en het punt waarop wij het beproefde pad omzetten naar eigen engineering. Waar AI in het mkb over de hele linie zinvol is, hebben we samengevat in AI-oplossingen voor het mkb.

De keuze gaat dus niet over welk model abstract beter is. Ze gaat over de taak die voor u ligt en de stack die u al gebruikt.

Eerst de afkomst goed op orde

De helft van de verwarring in deze vergelijking zit in de naamgeving, dus het loont om die eerst helder te krijgen.

🔸 GPT Image 2 is OpenAIs huidige beeldmodel, de opvolger in de gpt-image-reeks, uitgebracht in 2026. De oudere API-ID gpt-image-1 is de eerste generatie, niet dit model.
🔸 Nano Banana Pro is Googles marketingnaam voor Gemini 3 Pro Image, aangekondigd in november 2025 en gebouwd op Gemini 3 Pro.
🔸 Nano Banana zonder de Pro is het eerdere Gemini 2.5 Flash Image, nu gepositioneerd als de snelle en goedkope variant. Verwar de twee niet, want hun uitvoerkwaliteit en prijs verschillen.

Dit goed op orde hebben is belangrijk om dezelfde reden waarom de modelafkomst in de Fable-5-les over soevereiniteit belangrijk was: over een tool die u verkeerd hebt geïdentificeerd, kunt u niet goed nadenken.

De vergelijking die echt werk beslist

De assen die de uiteindelijke output echt veranderen:

Kort samengevat: Nano Banana Pro wint op tekst, resolutie en consistentie. GPT Image 2 wint op algemene look en op integratie in een bestaande OpenAI-workflow.

Waar elk wint

🔸 Marketingcreatie met veel tekst in beeld of infographics. Nano Banana Pro. Beste tekstweergave, 2K- en 4K-uitvoer en Search Grounding voor correcte feiten en logo's. GPT Image 2 is een solide terugvaloptie als u toch al op OpenAI bouwt.
🔸 Product- of karakterconsistentie over een reeks. Nano Banana Pro. Het is het model met een genoemde specificatie, 14 referentiebeelden en 5 consistente personen, wat een coherente campagne of een terugkerende productopname nodig heeft.
🔸 Algemene hero- of redactionele beelden. Nipt. GPT Image 2 leidt momenteel de algemene tekst-naar-beeld-ranglijsten, kies dus op basis van look-voorkeur. Kies Nano Banana Pro als u 4K rechtstreeks uit het model nodig hebt.
🔸 Nauwe stackintegratie. Gebruik wat u al draait. Een OpenAI-omgeving krijgt een API en batchkortingen met GPT Image 2. Een Google- of Vertex-omgeving krijgt native generatie met Nano Banana Pro.

Dat is dezelfde selectiediscipline die wij toepassen bij AI-videomodellen en bij beeld-naar-3D met TRELLIS. Kies op basis van de taak, niet van het logo.

Eerlijke grenzen aan beide kanten

Geen enkel model is vrij van compromissen, en de compromissen zijn wat in productie bijt.

🔸 GPT Image 2 stopt bij ongeveer 1536px aan de lange zijde en biedt slechts drie beeldverhoudingen, het verliest dus bij grote formaten en ongewone vormen. De tokenprijs maakt edit-zwaar werk duur, omdat edits ook beeld-invoertokens berekenen. Het watermerk bestaat uit C2PA-metadata in plaats van een ingebedde onzichtbare markering, wat u moet toetsen aan uw compliance-eisen.
🔸 Nano Banana Pro draagt het onzichtbare SynthID-watermerk op de uitvoer, dat onder de hoogste enterprise-laag niet verwijderbaar is. Sommige klanten willen het weg, controleer dit dus vroeg. Het draait bovendien met hogere kosten en latency dan de basis-Nano Banana, en Google publiceert geen duidelijke prijs per beeld, plan de kosten dus via de Vertex-rekenmodule.

Niets daarvan is een uitsluitingscriterium. Het is het soort detail dat bepaalt welk model past bij een specifieke klanteis.

Hoe wij bij iiterate kiezen

Onze standaardkeuze is geen trouw aan één model, maar een korte checklist. Bevat het beeld tekst of is 4K nodig? Moet het consistent blijven over een reeks heen? Welke cloud gebruikt de klant al? Zijn er watermerk- of residentievereisten?

Meestal beantwoorden deze vier vragen zichzelf. Tekstzwaar, hoogresolutie- of consistentiekritisch werk gaat naar Nano Banana Pro. Algemeen redactioneel werk en OpenAI-native pipelines gaan naar GPT Image 2. Wij houden beide in de gereedschapskist, juist omdat het juiste antwoord per briefing verandert.

De modellen zullen elkaar blijven inhalen, controleer dus ranglijsten en prijzen opnieuw op het moment van beslissen. Wat stabiel blijft, is de gewoonte: het model laten aansluiten bij de taak, en bij de stack waarin de klant al leeft.

Deze bijdrage behandelt wat TRELLIS is, hoe het werkt, waar het past in een echte asset-pipeline en op welke punten het ophoudt een antwoord met één klik te zijn.

Wat TRELLIS is

TRELLIS is een generatief 3D-model dat een beeld, meerdere beelden of een tekstprompt aanneemt en een 3D-asset genereert.

🔸 Gestructureerde latents (SLAT). Het kernidee is een uniforme latent die een dunbezet 3D-voxelrooster voor de structuur verbindt met dichte visuele kenmerken voor het uiterlijk. Vorm loskoppelen van uiterlijk is wat dezelfde latent tot verschillende outputs laat worden.
🔸 Drie outputs uit een latent. Radiance fields, 3D-gaussians of een als GLB geëxporteerde mesh. GLB is het praktische doel, omdat het materialen draagt in web- en AR-viewers.
🔸 Open en MIT-gelicentieerd. Het werkpaard voor beelden, TRELLIS-image-large, heeft 1,2 miljard parameters. Het model en het merendeel van de code zijn MIT, wat telt voor commercieel gebruik. Een nieuwere 4B-reeks voegt volledig fysiek gebaseerde materialen toe, de moeite waard om te volgen terwijl ze rijpt.
🔸 Getraind op grote schaal. Rond 500.000 gecureerde objecten, met het paper als CVPR 2025 Spotlight.

Dat staat naast het parametrische, stuurbare uiteinde van 3D-werk, dat we behandelen in Grasshopper voor computerondersteund ontwerp. Generatieve 3D en parametrische 3D lossen verschillende problemen op.

Hoe het werkt

De pipeline is kort te beschrijven en nuttig om te begrijpen voordat u er een GPU aan wijdt.

1. Input. Een enkel beeld, meerdere aanzichten of een tekstprompt.
2. Gestructureerde latent. Een tweetraps rectified-flow-transformer genereert eerst de dunbezette structuur en vult vervolgens de SLAT-kenmerken.
3. Decoderen. De latent decodeert naar uw gekozen formaat: mesh, gaussians of radiance field.

In de praktijk plant u met ongeveer 16 GB VRAM als ondergrens, met 24 GB comfortabel. De generatie loopt in minder dan twee minuten op een RTX 4090. Community-builds drukken de geheugenbehoefte verder omlaag, wat TRELLIS realistisch zelf-hostbaar maakt in plaats van gehuurd. Voor teams die al lokale tegenover gehoste inferentie afwegen, geldt dezelfde afweging die we beschreven in On-premise tegenover cloud-LLM, ook voor generatieve media.

Waar het past in een asset-pipeline

De sterkste match is het begin van de pipeline, waar tempo boven finish gaat.

🔸 Een productfoto of prompt naar een GLB. Plaats het in een three.js-viewer of een model-viewer op het web, converteer naar USDZ voor AR of zet het in een visualisatiescène. Snel concepting en previews zijn waar TRELLIS uitblinkt.
🔸 Lokaal bewerken. TRELLIS kan een regio van het model opnieuw genereren of verfijnen, wat zeldzaam is onder generatoren die van één beeld uitgaan.
🔸 Eerlijk over topologie. De output is generatieve geometrie, geen kunstenaarschone mesh. Verwacht ongelijkmatige driehoeken, geen schone edge-flow en automatisch gegenereerde UV's. Voor games of film gaat u retopologiseren, opnieuw UV-mappen en texturen opnieuw bakken. De nieuwere materiaalbewuste reeks verkleint deze kloof, zonder haar te sluiten.

De waardetest voor een gegeven asset is dus eenvoudig: moet het volgende week correct uitzien in een viewer, of moet het een riggbaar, geoptimaliseerd game-asset zijn? TRELLIS is uitstekend in het eerste en een startpunt voor het tweede.

TRELLIS tegenover de alternatieven

Het open en gehoste 3D-veld bewoog snel. Een korte oriëntatie:

Waar TRELLIS staat: de sterkste werkelijk MIT-gelicentieerde optie met output in meerdere formaten en lokaal bewerken. Gehoste tools zoals Tripo en Rodin verslaan het op meteen schone topologie, en Hunyuan wint vaak op textuur, maar met een restrictievere licentie. Als uw vereiste is het model en de juridische voorwaarden te bezitten, is TRELLIS het voor de hand liggende startpunt.

De eerlijke grenzen, en hoe wij het gebruiken

Een paar kanttekeningen die we op tafel leggen voordat iemand TRELLIS in productie inzet:

🔸 Topologie en UV's zijn niet productieklaar voor games of CAD. Plan budget in voor retopo.
🔸 CAD valt buiten het bereik. Generatieve meshes zijn geen parametrische solids, dus geen engineering-geometrie.
🔸 Het inputrisico ligt bij u. Het model is MIT, maar de juridische blootstelling van uw inputbeeld of prompt is de uwe. Voer geen productfoto's in die u niet kunt licentiëren.

Wij behandelen TRELLIS als een concepting- en previz-engine: een manier om in een middag een geloofwaardig 3D-asset voor een klant neer te zetten en dan te beslissen wat een handgemaakte pipeline verdient. Dat is hetzelfde instinct achter waar de huidige golf van AI-videomodellen nuttig is, en dezelfde selectiediscipline die we toepassen bij het kiezen van een beeldmodel. Het gereedschap is niet de levering. Het oordeel over waar het past, is dat wel.

Dit artikel brengt beide kanten in kaart: waar deze platforms in 2026 echt goed in zijn, en de concrete punten waarop u een muur kunt verwachten.

Wat een no-code agent-builder eigenlijk is

Het helpt om twee zaken te scheiden die onder dezelfde noemer worden verkocht.

Workflowautomatisering is deterministisch. Een trigger gaat af, vaste stappen lopen, dezelfde invoer levert dezelfde uitvoer op. Klassieke Make- of Zapier-scenario's spelen zich hier af, en ook een hoop nuttig werk.

Een no-code agent-builder laat een taalmodel het pad bepalen. U beschrijft een resultaat, en het model kiest tools, roept API's aan, leest uw documenten en blijft net zolang doorlussen totdat het denkt klaar te zijn. Het verloop wordt niet vooraf door u vastgelegd.

De grens vervaagt omdat de automatiseringsplatforms agents op hun canvassen hebben geschroefd, terwijl de agent-native tools integraties toevoegden. Voor een mkb-team is de praktische vraag niet 'agent of workflow'. Het is hoeveel non-determinisme u in een bedrijfsproces toelaat, en wie de data beheert terwijl het draait. Datzelfde onderscheid maakten we toen we schreven over het verschil tussen een API, een MCP-server en een CLI.

Waar ze vandaag goed in zijn

Voor de juiste taak ingezet, verdienen deze tools snel hun plaats:

🔸 Triggers en integraties. Webhooks, app-gebeurtenissen en schema's via duizenden connectors. De bekabeling is opgelost.

🔸 Tool-aanroepen. De agent chat niet alleen, hij handelt: hij bevraagt een database, plaatst iets in een systeem, maakt een ticket aan.

🔸 Retrieval over uw eigen documenten. Antwoorden verankeren in interne kennis is nu een kwestie van een paar klikken, hetzelfde patroon dat we behandelen in ons artikel over RAG.

🔸 Meerstaps-workflows met een mens in de lus. Een goedkeuringspoort voordat er iets onomkeerbaars gebeurt.

De winst is tempo. U kunt in dagen aantonen dat een idee het waard is, en precies daarvoor dient een prototype. Wij hebben onze eigen Event Scout micro-app in die geest gebouwd, voordat we besloten wat echt engineering verdiende.

Waar ze ophouden

Dat is het deel dat de meeste demo's overslaan, en de reden waarom Gartner verwacht dat meer dan 40 procent van de agentische projecten eind 2027 wordt afgebroken. De faalmodus is zelden een crash. Hij is stiller dan dat.

🔸 Betrouwbaarheid en non-determinisme. Dezelfde aanvraag levert niet twee keer hetzelfde resultaat op. Agents crashen niet, ze driften: ze lussen, kiezen de verkeerde tool of handelen op verouderde context. De kosten uiten zich in kwaliteit en latentie, zonder rood lampje op het dashboard.

🔸 Evaluatie en observeerbaarheid. No-code-consoles geven u dunne tracing. Meten of een agent werkelijk beter wordt, over een hele meerstaps-run heen en niet alleen het eindantwoord, is een uitbreiding die u zelf moet bouwen.

🔸 Datagovernance en hosting. De meeste van deze platforms zijn Amerikaanse SaaS. Voor Duitse data betekent dat AVG- en Schrems-II-vraagstukken die u niet kunt wegwuiven. De zelf hostbare opties die data op uw eigen EU-servers houden, vormen een korte lijst: n8n, Flowise, Langflow, Dify. Wij gaan dieper op deze afweging in in On-premise versus cloud-LLM en in wat de AVG daadwerkelijk toestaat.

🔸 Kosten bij schaalvergroting. Facturering per uitvoering en per credit bestraft volume. Bij een creditmodel kan dezelfde agent een paar euro of meerdere honderden kosten, puur afhankelijk van hoe hij gebouwd is. Pilots ogen goedkoop. De productie is dat vaak niet.

🔸 Lock-in en overdracht. Propriëtaire canvassen exporteren niet naar echt engineering. Wanneer u een no-code tool ontgroeit, bouwt u meestal opnieuw, in plaats van te migreren.

De beslissingslens

Ik gebruik vijf vragen om te bepalen of iets no-code blijft of opklimt naar een gebouwd systeem. Beoordeel elke vraag met laag of hoog.

1. Datagevoeligheid. Raakt het aan persoons- of gereguleerde data?
2. Volume- en kostencurve. Schaalt het gebruik naar een punt waarop facturering per credit pijn doet?
3. Betrouwbaarheidseis. Is het intern en vergevingsgezind, of klantgericht met een SLA?
4. Logica-complexiteit. Lichte vertakking of diepe voorwaardelijke en toestandsgebonden logica?
5. Audit en evaluatie. Heeft u evals op trajectniveau en een audit spoor nodig?

Twee of meer 'hoog'-antwoorden, en u wilt een maatwerk of hybride bouw. Anders is no-code het juiste gereedschap, vooral om waarde aan te tonen.

Het patroon dat in de praktijk werkt, is geen kwestie van of-of. Prototype op iets als n8n of Flowise, vind het pad dat echt levert, en verhard vervolgens precies dat ene pad tot eigen engineering. Het prototype was niet verspild. Het heeft u precies verteld wat u moet bouwen.

Hoe wij ze bij iiterate behandelen

Wij grijpen vroeg en vaak naar no-code agent-builders, en zijn ons vervolgens bewust van wanneer we ze verlaten. Een no-code agent is een snelle, eerlijke manier om uit te zoeken of een resultaat het engineering waard is dat nodig zou zijn om het betrouwbaar te maken. Dat is echte waarde, en voor veel interne taken is het het hele antwoord.

De fout die ik in het mkb het vaakst zie, is een werkende demo behandelen als een af systeem. Dat is niet hetzelfde, en de kloof daartussen is de lijst hierboven. Als u weet waar de grens ligt voordat u begint, krijgt u het tempo zonder het afgebroken project. Wilt u een gefundeerde blik op waar AI in een mkb-onderneming eigenlijk past, dat hebben we opgeschreven in AI-oplossingen voor het mkb.

Twee voorbehouden vooraf voor een Duitse koper. De prijzen van alle drie veranderen vaak, behandel elk getal hier dus als verouderd en controlewaardig. En dataresidentie is een echte randvoorwaarde: geen van de drie host standaard in de EU, wat telt voordat persoonsgegevens een gesprek raken.

Wat elk platform eigenlijk is

🔸 ElevenLabs Agents. Gebouwd op de spraakkwaliteit waar ElevenLabs bekend om staat, nu omhuld door een gehoste agentlaag met telefonie via SIP. De keuze als de meest natuurlijk klinkende stem en ontwikkelaarscontrole de doorslaggevende factoren zijn.

🔸 Retell AI. Telefonie-eerst-infrastructuur voor voice-agents. Het positioneert zich via lage latentie en betrouwbare gespreksafhandeling, inkomend en uitgaand, en laat u uw eigen carrier meebrengen. De keuze voor productieve belactiviteit.

🔸 Voiceflow. Een visueel, collaboratief platform voor het ontwerpen van chat- en voice-agents, met ingebouwde kennisbank. Ontwerpgestuurd en no-code-eerst. De keuze voor een CX- of ontwerpteam dat aan stromen itereert. Let op: de live telefoonstem is hier de zwakste van de drie, omdat ze leunt op een aparte telefonieaanbieder.

Als uw taak dichter bij een tekst- of tool-gebruikende agent ligt dan bij een telefoonlijn, geldt dezelfde bouwen-versus-kopen-logica als bij no-code-agentbouwers.

De vergelijking die telt

De dimensies die een voice-agentproject echt bepalen, naast elkaar:

Lees de tabel als kaart van afwegingen, niet als scorebord. Geen kolom is bij alles het beste, dat is precies het punt.

Waar elk platform past

🔸 Een Duitse supportlijn die telefonie en een natuurlijke Duitse stem nodig heeft. Begin met Retell voor betrouwbare gespreksafhandeling en carriercontrole, of ElevenLabs, als de natuurlijkheid van de Duitse stem de doorslaggevende factor is. Voor strikte datasoevereiniteit host geen van beide standaard in de EU, plan dus zelf gehost Retell of een EU-native alternatief.

🔸 Een ontwerpgestuurd team dat een CX-stroom bouwt. Voiceflow. De visuele builder, de samenwerking met meerdere editors en de kennisbank laten een team zonder ontwikkelaars itereren. Voeg telefonie apart toe als u spraak nodig heeft.

🔸 Een ontwikkelaar die maximale spraakkwaliteit en eigen controle wil. ElevenLabs. Beste TTS, SDK-controle, modelagnostisch, SIP voor telefonie.

Het patroon is hetzelfde dat wij op de meeste gereedschapskeuzes toepassen: eerst de taak benoemen, dan het gereedschap kiezen dat die taak bezit.

De Duitse vraag naar dataresidentie

Dit is het deel dat beslist of een voice-agent überhaupt is toegestaan, voordat spraakkwaliteit al telt.

AVG-conformiteit is niet hetzelfde als EU-hosting. Een aanbieder kan AVG-conform zijn en gesprekken toch op Amerikaanse infrastructuur verwerken en opslaan, wat de Schrems-II-vragen weer opent. Over deze drie heen: ElevenLabs biedt EU-dataresidentie alleen in het enterprise-niveau, Retell bereikt dit via self-hosting, en Voiceflow is pure cloud zonder soevereine residentie-optie.

Voor een Duitse supportlijn die klantgegevens verwerkt, maakt dat van de shortlist net zozeer een hostingbeslissing als een featurebeslissing. Het is dezelfde logica die wij uiteenzetten in wat de AVG daadwerkelijk toestaat en in on-premise tegenover cloud-LLM: bepaal waar de data mogen staan, kies dan het gereedschap dat dat respecteert.

Hoe wij zouden kiezen

Wij zouden niet uitgaan van het merk. Wij zouden uitgaan van drie vragen: loopt dit via de telefoon, wie onderhoudt het, en waar mogen de data staan.

Is het een telefoonlijn, dan verdient Retell de eerste blik. Draagt de spraakkwaliteit de ervaring en bezit een ontwikkelaar het, dan ElevenLabs. Moet een niet-technisch team de stroom ontwerpen en bezitten, dan Voiceflow. En als de data de EU niet mogen verlaten, verschuift het gesprek naar de hosting voordat het bij de features komt, wat de shortlist vaak opnieuw vormt.

De prijzen zullen zich blijven bewegen, controleer ze dus opnieuw op het moment van evaluatie, in plaats van te vertrouwen op één enkel getal. Het blijvende deel is de fit, en de fit volgt de taak.

Deze bijdrage legt uit waarom we het gebouwd hebben, wat het kan, waar het eerlijk ophoudt, en stelt aan het einde een open vraag.

DE PLICHT, KORT EN CORRECT

De elektronische factuur is in de Duitse B2B geen optie meer, maar verplicht, en het tijdschema is concreet.

• Sinds 1 januari 2025 moet elke binnenlandse onderneming e-facturen kunnen ontvangen en verwerken. Zonder uitzondering, zonder omzetgrens, ook kleine ondernemers.
• Tot eind 2026 zijn bij verzending nog papier of PDF toegestaan, de PDF echter alleen met toestemming van de ontvanger.
• Vanaf 2027 moeten ondernemingen met meer dan 800.000 euro omzet in het voorgaande jaar e-facturen uitreiken, vanaf 2028 dan allemaal.

Met e-factuur wordt geen PDF-bijlage bedoeld, maar een gestructureerd formaat volgens de Europese norm EN 16931. ZUGFeRD is de in Duitsland gangbare variant: een PDF/A-3-bestand met ingebedde XML. De mens ziet een leesbare PDF, de software leest de XML direct uit, zonder overtypen en zonder tekstherkenning. De afbeelding hieronder toont precies deze twee aanzichten van hetzelfde bestand.

WAAROM WE NIET GEWOON EEN ABONNEMENT NAMEN

De aanleiding kent iedereen: de verplichting komt eraan, dus heeft men een tool nodig. Het voor de hand liggende antwoord is een abonnement, en precies daar hebben we ons even bedacht.

Voor een in de kern eenvoudig proces, een PDF met ingebedde XML genereren, lopen al snel terugkerende kosten op: gangbare factuurtools beginnen bij circa 10 euro per maand en lopen voor e-factuurverzending, afhankelijk van het tarief, aanzienlijk hoger op. Voor een bedrijf dat maar weinig facturen per maand schrijft, betaalt men daarmee permanent voor een volledige boekhouding die men helemaal niet gebruikt.

De eigenlijke reden was echter niet de prijs, maar de data. Een factuur bevat namen, adressen en vaak bankgegevens. Stuurt men die door een cloudtool, dan is dat een verwerkersovereenkomst volgens art. 28 AVG: een contract, een derde partij, gegevens die het pand verlaten. Self-hosted vervalt dat volledig. Dat is dezelfde logica die we bij taalmodellen aanhouden, na te lezen in On-Premise vs. Cloud-LLM: nut behouden, datasoevereiniteit niet opgeven.

WAT BELEGT CONCREET DOET

Belegt is bewust klein en scherp afgebakend. Het is een generator, geen vervanging voor de boekhouding.

Technisch is het een webapplicatie die men op de eigen computer of server draait. De data staan lokaal in een bestand, gevoelige velden zoals bankgegevens zijn daarbij versleuteld opgeslagen. Het genereert ZUGFeRD- en Factur-X-facturen in het profiel EN 16931, dus het niveau dat juridisch als volwaardige e-factuur telt, controleert ze tegen de norm, kent doorlopende factuurnummers toe, beheert bedrijfs- en klantprofielen, en houdt openstaande posten en analyses in de gaten.

De twee dingen die ons de meeste tijd besparen: een begeleide workflow die een conforme factuur in enkele stappen afrondt, en dat het gegenereerde bestand meteen het machineleesbare aanzicht meebrengt dat de ontvanger nodig heeft. We gebruiken het zelf, elke maand. Dat is de eerlijkste aanbeveling die we kunnen geven: we hebben het niet voor een markt gebouwd, maar voor onszelf. Het is een van meerdere kleine tools die zo ontstaan zijn, zoals de event-scout-tool.

WAAR HET EERLIJK OPHOUDT

Een self-hosted losstaande tool heeft reële grenzen, en die verzwijgen zou precies het soort marketing zijn dat wij niet doen.

🔸 De norm beweegt. EN 16931 en de codelijsten worden regelmatig geactualiseerd. Een generator moet onderhouden worden, anders genereert hij op een gegeven moment geen conforme facturen meer. Dat is werk dat iemand moet doen.
🔸 Bewaren is niet inbegrepen. Genereren is niet hetzelfde als controlebestendig archiveren. De GoBD vereisen een onveranderlijke bewaring in het originele formaat, inmiddels acht jaar. Dat lost een pure generator niet op, dat blijft een taak van de gebruiker.
🔸 Het vervangt geen belastingadviseur. Een technisch geldige factuur kan inhoudelijk toch onvolledig zijn. Een directe koppeling met het kantoor of met boekhoudsystemen bestaat niet.

Eerlijk samengevat: Belegt sluit de verplichte lacune van generatie en validatie schoon en abonnementsvrij. Archivering en belastingworkflow blijven erbuiten. Wie dat verwart met een volledige suite, komt bedrogen uit. Wie precies dit ene gat heeft, krijgt een tool zonder overbodige franje.

MOETEN WE HET DELEN, EN HOE?

Hier eindigt de bijdrage bewust met een vraag in plaats van een antwoord, want we weten het zelf nog niet.

Er zijn twee aannemelijke wegen. De ene: we geven Belegt vrij, als self-hosted oplossing die elk klein bedrijf op de eigen machine kan laten draaien, abonnementsvrij en met de data in eigen huis. De andere: we bieden een onderhouden variant aan, die we actueel houden, bij de installatie helpen en waarvoor we instaan voor de normupdates, tegen een redelijke vergoeding. Beide hebben hun eigen logica, en de onderhoudslast uit de vorige sectie is precies de reden waarom het antwoord niet triviaal is.

Daarom dit eerlijke verzoek: als een lokale, privacyvriendelijke, abonnementsvrije ZUGFeRD-tool nuttig zou zijn voor u of uw bedrijf, schrijf ons dan. Zou het u voldoende zijn om het zelf te beheren, of zou u een begeleide versie liever hebben? Precies dit signaal helpt ons te beslissen of iets wat we voor onszelf gebouwd hebben, iets wordt dat we delen.

Claude Code, Codex, Cursor, Antigravity en Opencode lossen dezelfde taak op zeer uiteenlopende manieren op. De ene vraag die het veld verdeelt, is eenvoudig: mag uw code het pand verlaten? Wie dat met ja kan beantwoorden, kiest op basis van de stack. Wie dat niet kan, heeft precies één serieuze optie. Deze tekst rangschikt de vijf langs deze vraag en eindigt met de beslissing die ik een Duits team aanbeveel.

VIJF GEREEDSCHAPPEN, ÉÉN EERSTE VRAAG

De vijf zitten op verschillende niveaus, en de vorm zegt al veel over de inzet.

• Claude Code is een terminal-agent van Anthropic: sterk in wijzigingen over meerdere bestanden, een grote context en een agentische lus in de terminal.
• Codex van OpenAI is er als CLI, cloud-sandbox en IDE-integratie vanuit een gedeeld gebruiksvenster.
• Cursor is de AI-IDE met agent- en achtergrondagentmodus en vrije modelkeuze.
• Antigravity is Googles agentgerichte IDE, beschikbaar sinds 20.11.2025, met een managerinterface voor het starten en volgen van parallelle agenten (Google).
• Opencode is een opensource terminal-agent onder MIT-licentie, modelonafhankelijk via veel providers en selfhosted endpoints (opencode.ai).

Hoe deze tools passen in een stack, van de API tot de CLI, hebben we uiteengezet in API, MCP of CLI. Hier gaat het om de keuze, en die begint bij het databeleid.

VERLAAT UW CODE HET PAND?

Deze ene vraag sorteert het veld sneller dan welke functielijst dan ook, omdat ze beslist over compliance en vertrouwelijkheid voordat welke feature dan ook telt.

Vier van de vijf sturen code naar een externe cloud. Claude Code, Codex, Cursor en Antigravity draaien tegen gehoste modellen in de VS. Dat is niet per se een uitsluitingsgrond: voor veel projecten is dat prima, en in het enterprise-abonnement zijn zero-data-retention- en no-train-clausules te onderhandelen. Maar de code gaat naar buiten, en dat moet u bewust accepteren, niet over het hoofd zien.

Opencode is de uitzondering. Omdat het modelonafhankelijk is en een lokaal endpoint kan aanspreken, draait het volledig tegen een selfhosted model. Dan verlaat de code het pand nooit. Dat is precies de scheidslijn die over al het overige beslist. Welk open-weightmodel u daarachter zet, is een aparte beslissing, die we doorlopen in Open-weightmodel voor het Duitse B2B.

ALS DE CLOUD OKÉ IS: KIES OP BASIS VAN DE STACK

Accepteert u de gehoste cloud bewust, dan beslist de stack, niet de benchmark. Een beknopt overzicht:

De pragmatische regel: Anthropic-huis kiest Claude Code, OpenAI-huis kiest Codex, een IDE-gericht team kiest Cursor of Antigravity. Benchmarkcijfers zoals SWE-Bench-scores rond de 85 procent circuleren, maar zijn meestal leveranciersopgaven en zelden onafhankelijk geverifieerd; ik zou daar geen toolkeuze op baseren. Wat een coding-agent buiten de pure ontwikkeling presteert, laat ons artikel Claude Code voorbij engineering zien.

ALS DE CODE IN HUIS MOET BLIJVEN: OPENCODE PLUS EIGEN MODEL

Mag de code niet naar buiten, dan blijft er een serieuze optie over, en die is goed.

Opencode is opensource onder MIT, spreekt veel providers aan en, cruciaal, een lokaal endpoint. Gecombineerd met een selfhosted open-weightmodel ontstaat een coding-agent waarbij noch broncode noch prompts de eigen infrastructuur verlaten. Voor gereguleerde gegevens, geheimhoudingsplicht jegens cliënten of gewoon voorzichtige klanten is dat vaak de enige haalbare opzet. Een open codeermodel zoals Kimi K2.7 hebben we daarvoor speciaal bekeken.

De prijs van deze controle is eigen werk: u stelt model, hardware en operatie zelf samen, er is geen gemanagde cloud-agentenvloot. In de praktijk helpt het de agent structuur te geven, bijvoorbeeld een codebase-kaart, zoals we die hebben beschreven in Graphify. De inspanning is reëel, maar hij koopt iets wat de gehoste tools niet kunnen bieden.

HOE IK DIT BESLIS

U heeft geen enkel antwoord nodig voor het hele bedrijf, maar het juiste antwoord afhankelijk van het databeleid. Zo pak ik het aan:

1. Databeleid verhelderen. Mag de betreffende code naar een Amerikaanse cloud? Dat antwoord komt van juridische zaken en de klant, niet van het ontwikkelteam.
2. Zo ja, kies op basis van de stack. Anthropic-huis naar Claude Code, OpenAI-huis naar Codex, IDE-team naar Cursor of Antigravity, telkens met onderhandelde ZDR- en no-train-voorwaarden.
3. Zo nee, Opencode plus eigen model. De enige optie waarbij de code het pand niet verlaat.
4. Lock-in in de gaten houden. Vraagt elke tool zijn eigen binding, houd dan een weg terug naar een dieper niveau open, mocht een leverancier de voorwaarden wijzigen.

Wij werken zelf, afhankelijk van het project, met meerdere van deze tools, en dat is precies het punt: de keuze is projectgebonden, niet ideologisch. De ene kleine interne tool die we met een agent hebben gebouwd in plaats van uit te besteden, staat in Building event-scout. Welke van uw repositories zouden vandaag eigenlijk helemaal niet naar een externe cloud mogen, en welke tool gebruikt u er toch voor?

Dit is de kaart van dat oppervlak: waarvoor elk onderdeel dient en waar de scherpe randen zitten.

VIJF MANIEREN OM UIT TE BREIDEN, ÉÉN PRINCIPE

Onder de namen doet elk uitbreidingspunt hetzelfde: het verplaatst kennis uit de prompt naar geversioneerde bestanden die de agent laadt wanneer hij ze nodig heeft.

• Skills zijn mappen met instructies, scripts en resources. Een korte beschrijving zit in de context; de volledige skill laadt pas wanneer de agent hem relevant acht. Dat is progressive disclosure: goedkoop om paraat te houden, uitgebreid bij aanroep.
• Slash-commands zijn benoemde afkortingen die zich ontvouwen tot een vaste prompt. De eenvoudige manier om een herhaald verzoek eenmalig te coderen en te hergebruiken.
• Hooks zijn shell-commando's die worden geactiveerd bij levenscyclusgebeurtenissen: sessiestart, voor een tool-aanroep, erna, bij het stoppen. Een pre-tool-hook kan een aanroep controleren en blokkeren voordat hij wordt uitgevoerd.
• MCP-connectors geven de agent geauthenticeerde toegang tot systemen die hij anders niet bereikt: een database, een issue-tracker, een interne API. Elke server draagt zijn eigen toegangsgegevens.
• Subagents zijn eigen agent-instanties die worden gestart voor een gerichte deeltaak, met eigen context en eigen instructies.

Een plugin bundelt willekeurig welke hiervan in een installeerbare eenheid. Het principe achter alles: codeer uw kennis als bestanden in uw repo, niet als gewoontes in het hoofd van één persoon. De systeemintegratievariant van deze keuze hebben we uiteengezet in API, MCP of CLI.

SKILLS EN MCP ZIJN GEEN RIVALEN

De meest gestelde vraag op dit moment is "skills of MCP", en het eerlijke antwoord is dat ze verschillende problemen oplossen.

MCP is toegang: het verbindt de agent met een systeem dat hij alleen niet bereikt, met toegangsgegevens en status. Skills zijn kennis: herhaalbare expertise die de agent toepast op systemen die hij al heeft. De analogie die de ronde doet, dekt de lading: MCP zijn de gangpaden van de bouwmarkt, skills zijn de ervaren medewerker die weet naar welk gangpad u moet gaan.

De tokeneconomie bepaalt de vorm van een goede opzet. Een skill kost een paar tientallen tokens totdat hij wordt aangeroepen. Een handvol MCP-servers kan tienduizenden tokens aan context kosten voordat de eerste taak begint, omdat elke server al zijn tools vooraf aankondigt. Het werkpatroon waar de meeste practici naartoe bewegen, is dus veel slanke skills en enkele goed gekozen connectors, geen alles-installeren-stapel. De demo hieronder doorloopt de vijf uitbreidingstypen plus de kosten en het risico dat elk met zich meedraagt.

WAAROM DE OPEN STANDAARD TELT VOOR SOEVEREINITEIT

De nuttigste recente verandering is dat de uitbreidingslaag ophield het kenmerk van één enkele aanbieder te zijn.

Agent Skills werden in december 2025 als open standaard gepubliceerd, en het formaat werd binnen enkele weken overgenomen door meerdere agentaanbieders. In de praktijk betekent dit dat een skill die u voor de ene harness schrijft, daar niet in gevangen zit. Voor een Duits bedrijf dat het risico "vastgebonden aan één enkele Amerikaanse aanbieder" afweegt, is dit een gedeeltelijk antwoord op het niveau dat u zelf beheerst: de kennis die u codeert, is overdraagbaar, ook al is het onderliggende model gehuurd.

Combineer dit met connectors die naar EU-gehoste of on-premise systemen wijzen, dan houdt het verhaal over dataresidentie gelijke tred met het verhaal over vermogen. De kennis is van u en overdraagbaar; de data blijft waar ze moet blijven. Dat is een houdbaardere positie dan de workflow te verwedden op de roadmap van één enkele aanbieder, dezelfde overweging die schuilt achter het kiezen van een coding agent op basis van de harness, niet het model.

ELK UITBREIDINGSPUNT IS EEN AANVALSOPPERVLAK

Dezelfde kracht die de harness nuttig maakt, maakt hem gevaarlijk, en de risico's zijn recent en gedocumenteerd, niet hypothetisch.

Hooks voeren willekeurige shell-commando's uit, dat is precies een uitvoeringsoppervlak. Check Point maakte in februari 2026 CVE-2025-59536 openbaar: een kwaadaardig instellingenbestand in een gekloond repository kon hooks uitvoeren voordat de vertrouwensdialoog überhaupt verscheen. Een bijkomend probleem, CVE-2026-21852, betrof de exfiltratie van API-sleutels via een omgevingsoverschrijving. MCP brengt een eigen supply-chainprobleem met zich mee: elke server bewaart toegangsgegevens, en scans vonden honderden MCP-servers die zonder authenticatie op het internet stonden. En de skill-marktplaatsen tonen inmiddels duizenden community-skills, gemakkelijk te installeren en moeilijk te controleren, met berichten over ronduit kwaadaardige exemplaren die in omloop zijn.

Niets daarvan is een reden om de harness niet uit te breiden. Het is de reden om hem bewust uit te breiden.

BEHEER DE CATALOGUS, VERZAMEL GEEN PLUGINS

De discipline die een productieopzet onderscheidt van een wetenschapsexperiment, is een gecontroleerde, vrijgegeven catalogus: een bekende set skills, hooks en connectors die iemand heeft gelezen, met een vertrouwenspoort voordat er iets nieuws bijkomt.

Dat is onglamoureus en het is het hele spel. Welke hooks mogen shell uitvoeren. Welke MCP-servers bewaren welke toegangsgegevens. Welke skills zijn vrijgegeven, en wie heeft ze vrijgegeven. Voor een mkb-team is dit de plek waar institutionele kennis duurzaam gereedschap wordt dat personeelswisselingen overleeft, en waar het werk ophoudt de slimme configuratie van één enkele engineer te zijn en iets wordt dat aan het bedrijf toebehoort. Toen we ons eigen interne scouting-hulpmiddel bouwden als kleine agentische app, lag de waarde niet in de slimheid, maar erin dat het proces nu een gecontroleerd bestand in een repo was in plaats van een herinnering. We hebben dat opgeschreven in Bouw van een kleine agentische micro-app.

Het model kunt u volgend kwartaal vervangen. De catalogus van uitbreidingen is het bezit dat u behoudt. De vraag die het waard is zich te stellen voor de installatie van de volgende plugin, is dus eenvoudig: wie heeft hem gecontroleerd, en waartoe heeft hij toegang?

Dit artikel is een nuchter overzicht: de toepassingen die renderen, de subsidies die er in Rijnland-Palts werkelijk zijn, en de ene drempel die bijna alles afremt.

WELKE AI-OPLOSSINGEN ECHT RENDEREN

De oplossingen die zich in het mkb bewijzen, zijn onopvallend en liggen dicht bij bestaande processen. Ze besparen tijd, nieuwe omzet leveren ze zelden op.

🔸 Documentintelligentie. Facturen, pakbonnen, contracten en e-mails automatisch uitlezen en indelen. Laagste instapdrempel, snel merkbaar effect.
🔸 RAG-kennisbeheer. Een bedrijfseigen antwoordsysteem over het interne documentenbestand: handboeken, procesdocumentatie, offertes, servicehistorie. Ontlast onboarding en support, en de kennis gaat niet verloren bij personeelswisselingen.
🔸 Offerte- en factuurautomatisering. Offerteteksten en calculaties uit eerdere trajecten genereren, factuurworkflows ordenen. Staat door de verplichte e-factuur sowieso op de agenda.
🔸 Service-agenten op eigen kennis. First-level support en FAQ, gebaseerd op bedrijfsdata in plaats van op een algemene cloud-chatbot.
🔸 Lokale LLM voor gevoelige data. Personeels-, cliënt-, constructie- of patiëntgegevens lokaal of bij Duitse hosting verwerken.

De nuchtere conclusie: AI levert het mkb vooral efficiëntiewinst op, zelden direct omzet. Wie de toepassing niet zorgvuldig kiest, verbrandt budget, juist nu de innovatie-uitgaven eerder dalen.

HET SUBSIDIELANDSCHAP IN RIJNLAND-PALTS, ZONDER MYTHES

Voordat het over subsidies gaat, eerst opruimen: veel rondgaande programma's zijn dood of waren nooit van Rijnland-Palts. DigiBoost RLP is sinds 2022 gesloten, het landelijke go-digital liep eind 2024 af, en de vaak genoemde digitaliseringsvoucher van 20.000 euro hoort bij Noordrijn-Westfalen, niet bij Rijnland-Palts.

Wat in 2025 en 2026 werkelijk loopt:

• Betriebsberatungsprogramm RLP. Sinds december 2025, subsidie onder andere voor digitalisering en AI. Vervangt het vroegere BITT.
• IBI-EFRE Rheinland-Pfalz. Subsidie voor bedrijfsinnovatie en digitalisering, voor mkb-bedrijven gevestigd in Rijnland-Palts.
• Innovationsgutschein RLP. Tot 20.000 euro, niet terugbetaalbaar, voor onderzoeks- en ontwikkelingsopdrachten aan externe partijen.
• Mittelstand-Digital Zentrum Kaiserslautern. Kosteloos, leveranciersneutraal advies, workshops en demonstratoren.

De subsidie is er dus. Ze vervangt alleen geen beslissing over wat u eigenlijk wilt bouwen. Precies daarbij helpt de keuze in de afbeelding hieronder.

DE ECHTE DREMPEL IS PRIVACY, NIET TECHNIEK

Als AI-projecten in het mkb mislukken, dan zelden vanwege het model. Ze mislukken op de vraag waar de data mogen liggen.

77 procent van de bedrijven noemt gegevensbescherming als grootste drempel, voor personeelstekort met 70 procent. Tegelijk staan 73 procent van de bedrijven hun medewerkers het gebruik van taalmodellen toe, maar slechts 23 procent beperkt dit tot bedrijfseigen modellen. Concreet betekent dit: ongeveer de helft laat vrij beschikbare cloudmodellen ongestuurd draaien. Dat is geen digitalisering, dat is schaduw-AI, een datalek met aankondiging.

Daar komt gebrekkige datavolwassenheid bij, bijna een kwart heeft geen geschikte data, en een gegronde ROI-scepsis. De kloof is niet AI ja of nee. Ze ligt tussen informeel gebruik en een veilig, productief kader.

SOEVEREIN BETEKENT NIET DUURDER, HET BETEKENT STUURBAAR

Het antwoord op de privacydrempel is niet om van AI af te zien. Het is om de inzetplek af te stemmen op de gevoeligheid van de data, niet op de marketing.

Voor niet-kritische taken is een cloudmodel verdedigbaar. Zodra persoonsgebonden, vertrouwelijke of bedrijfskritische data in het spel zijn, hoort de verwerking in een Duitse of EU-omgeving of op eigen hardware thuis. RAG op het eigen bestand, lokaal of bij Duitse hosting, levert het nut van een taalmodel zonder de inhoud bij elke aanvraag het huis uit te sturen. Wanneer lokale AI de cloud rechtvaardigt, zetten we uiteen in On-Premise vs. Cloud-LLM, en hoe RAG daarbij technisch werkt in Wat is RAG.

Eerlijk blijft: niet elke oplossing hoeft on-premise te zijn. De kunst is de toewijzing, en juist die neemt geen tool en geen subsidiebeschikking van u over.

EEN REALISTISCHE EERSTE STAP

De begaanbare weg is nuchter en verloopt in etappes, niet de grote AI-belofte in één keer.

Prioriteer de use case waaraan tijd of fouten hangen. Controleer het datafundament, want RAG op een chaotisch bestand levert geen waarde op. Bouw een kleine pilot met een duidelijke succesmaatstaf. Pas daarna opschalen. Deze etappes zijn mede te financieren via het Betriebsberatungsprogramm RLP of de Innovationsgutschein, en kosteloos te begeleiden via het Mittelstand-Digital Zentrum. De volledige aanpak hebben we beschreven in de praktische AI-routekaart.

Wij van iiterate zitten in Koblenz en Remagen en brengen precies deze drie dingen samen: strategie, bouw en compliance. Het mkb in Rijnland-Palts is al bezig. De opgave is om van het informele uitproberen iets soevereins en robuusts te maken. Waarmee zou u beginnen, en waar liggen uw meest gevoelige data?

Veo, Kling en Seedance leveren indrukwekkende clips, maar zijn gesloten en gehost. Wan Animate van Alibaba is het ene open model van de reeks, en daarmee de interessante hefboom voor iedereen die materiaal niet uit handen wil geven. Deze tekst zet de vier op een rij voor een Duits bedrijf dat productdemo's en marketingvideo's bouwt, en neemt de regelgeving serieus die in augustus van kracht wordt.

AUDIO WERD STANDAARD, KWALITEIT WERD VERPLICHT

De belangrijkste verandering van het jaar is dat zichtbare kwaliteit geen voorsprong meer is, maar inzetvoorwaarde.

Native audio is standaard geworden. Veo 3 bracht synchroon gegenereerde audio, en tegen begin 2026 genereerden ook Kling 2.6 en ByteDances Seedance 2.0 dialoog en geluiden in één keer. Stomme modellen ogen voor demowerk inmiddels verouderd. Tegelijk blijven de clips kort: acht seconden native is typisch, Seedance 2.0 haalt zo'n vijftien, langere stukken ontstaan door aaneenschakeling, niet uit één stuk.

Chinese laboratoria voeren meerdere ranglijsten aan. Seedance stond in juni 2025 aan de top van onafhankelijke tekst-naar-video-vergelijkingen, voor Veo 3 en Kling (arXiv). Zulke posities wisselen maandelijks. Dat is precies de reden om de keuze niet op de ranglijst te baseren, maar op de drie criteria die stabiel blijven.

DE VIER IN HET KORT

Een belangrijke opmerking over de naamgeving vooraf: bij ByteDance is Seedream het beeldmodel en Seedance het videomodel. Hier gaat het om Seedance.

• Veo 3.1 (Google, gesloten). Beste prompt-trouw, synchrone 48 kHz-audio, de diepste integratie in een pipeline via Vertex AI en Flow. Gehost, de output draagt Googles SynthID-watermerk.
• Kling 2.6 (Kuaishou, gesloten). Sterke beeld-naar-video en goede beweging, sinds versie 2.6 met native audio, tot ongeveer tien seconden. Bereikbaar via API met datahouding in Singapore.
• Seedance 2.0 (ByteDance, gesloten). Langere clips tot ongeveer vijftien seconden en cameraplanning. Vergezeld van een open juridische kwestie, nadat Disney in februari 2026 een sommatie stuurde, wat voor commercieel gebruik een reëel risico is.
• Wan Animate (Alibaba, open). Uitgebracht onder Apache 2.0 en zelf te hosten, gespecialiseerd in figuuranimatie, bewegingsoverdracht en karaktervervanging vanuit een referentiebeeld (Hugging Face). Minder gepolijst en kortere clips dan de gehoste modellen, maar wel volledige controle.

Runway, OpenAI's Sora 2 en MiniMax vullen het veld verder aan, maar liggen voor de hier doorslaggevende vraag hetzelfde: sterk, maar gesloten.

DE LABELPLICHT GAAT IN OP 2 AUGUSTUS

De regelgeving is in 2026 het eigenlijke evenement, niet het volgende model. Wie AI-video commercieel inzet, moet de labeling vooraf oplossen.

De transparantieverplichtingen uit artikel 50 van de EU AI-verordening worden vanaf 2 augustus 2026 van toepassing (EU AI Act). Synthetische media moeten machineleesbaar gemarkeerd worden en deepfakes moeten gelabeld worden. Praktisch betekent dit: herkomst is een compliancefunctie, geen leuk extraatje. Gehoste modellen brengen dit deels mee, Google bijvoorbeeld via SynthID, andere via C2PA-inhoudsbewijzen. Zelf gehost Wan draagt daarentegen geen afgedwongen watermerk, dus ligt de labeling dan in uw handen, als eigen, gedocumenteerde stap in de pipeline.

Welke AI-content onder de verordening valt en wat tegen wanneer moet worden geïmplementeerd, hebben we uiteengezet in EU AI Act 2026 en in het kader van GDPR en AI.

HET OPEN MODEL IS DE HEFBOOM

Als materiaal het pand niet mag verlaten, is het open model het eigenlijke antwoord, niet het mooiste.

Wan in de versies 2.1 tot 2.2 en Wan Animate staat doorgaand onder Apache 2.0, dus volledig commercieel gebruik, doorgifte en finetuning zonder terugkoppeling naar de leverancier. De kleinere variant draait op een enkele 24 GB-kaart, de 14B-variant vraagt zo'n 80 GB. Zelf gehost op Europese, indien nodig afgeschermde infrastructuur verlaat geen footage uw controle, en er zijn geen vreemde gebruiksvoorwaarden en geen geopolitieke afhankelijkheid. De prijs is minder polijsting en kortere clips dan bij Veo of Seedance, wat men voor de soevereiniteit bewust op de koop toe neemt.

Dat is dezelfde logica die we bij taalmodellen hanteren: een open, gecontroleerd model wint het van de laatste procenten kwaliteit, wanneer controle het punt is (soevereine Europese AI). Ook bij wereldmodellen tekent zich dezelfde open weg af (NVIDIA Cosmos 3).

HOE IK DIT BESLIS VOOR EEN DEMOPROJECT

De beslissing volgt de datasituatie en het doel, niet de mooiste demoreel. Zo pak ik het aan:

1. Gevoelig of gereguleerd materiaal. Toont de video producten voor marktlancering, klanten of interne zaken, dan zelf gehost Wan op EU-infrastructuur, en de labeling als eigen pipelinestap.
2. Publieke marketing, niet-kritische inhoud, polijsting doorslaggevend. Dan een gehost model zoals Veo of Seedance, maar met bewust gekozen voorwaarden en opgehelderde herkomst.
3. Los in elk geval de labeling voor 2 augustus op, niet erna.

In ons eigen creatieve werk mengen we dit per project, en het punt is niet om één model tot winnaar uit te roepen. Het punt is dat de zichtbare kwaliteit het makkelijke deel is geworden en de moeilijke vragen, datasituatie, rechten en labeling, over de inzet beslissen. Welke van uw geplande video's zou u überhaupt aan een gehoste Amerikaanse dienst durven toevertrouwen, en welke hoort op uw eigen infrastructuur thuis?

Qwen, Kimi, Nemotron en Minimax zijn in 2026 allemaal serieus bruikbaar. Maar slechts drie van de vier hebben een echt vrije licentie, slechts één familie past netjes op mkb-hardware, en geen enkele aanbieder publiceert een zuivere vergelijking van precies deze vier in het Duits. Deze tekst ordent de vier volgens de criteria die een koper daadwerkelijk moet toetsen, en eindigt met de beslissing die ik een mkb-bedrijf aanraad.

Eerst de licentie, dan de benchmark

De licentie is de eerste poort, omdat ze over elk commercieel on-premise gebruik beslist voordat ook maar één benchmark telt.

Drie van de vier zijn hier eenvoudig. Qwen3 staat onder Apache 2.0, Minimax M2 onder MIT, Kimi K2 onder een aangepaste MIT-licentie (Hugging Face). Dat zijn echte, vrije grants: commercieel gebruik, doorgeven, finetunen, geen belletje naar huis.

🔸 Nemotron is het bijzondere geval.
NVIDIA's Open Model License is geen zuivere Apache- of MIT-licentie. Ze koppelt het gebruik aan NVIDIA's voorwaarden en eindigt automatisch zodra de ingebouwde beveiligingsmechanismen worden verwijderd (NVIDIA). Het model is goed, maar deze clausule komt eerst bij de juridische afdeling terecht, niet bij engineering. We hebben de NVIDIA-aanpak in detail beschreven in het artikel over Nemotron 3.

Wie soevereiniteit als argument gebruikt, moet de licentie kunnen lezen als een contract, want dat is ze precies.

Hoe goed is het Duits werkelijk?

Het eerlijke antwoord: er bestaat geen zuivere viervoudige vergelijking van deze modellen in het Duits, dus moet u die zelf maken.

Duitse evaluatie-infrastructuur bestaat. SuperGLEBer, het Occiglot Euro-LLM-leaderboard en MMLU-ProX over 29 talen dekken Duits af (ACL Anthology). Wat ontbreekt, is een gepubliceerde kop-aan-kopvergelijking van precies deze vier op Duitse tekst. Qwen3 is getraind op 119 talen en is de familie met de breedst gedocumenteerde meertaligheid (Qwen); voor Kimi, Nemotron en Minimax noemen de aanbieders Duits niet apart als aandachtsgebied.

De praktische conclusie is oncomfortabel maar duidelijk: benchmarkplaatsen op Engelse tests zeggen weinig over de kwaliteit op uw Duitse contracten, offertes of supportteksten. De enige houdbare test is die op uw eigen materiaal. Hoe u leaderboards eigenlijk moet lezen zonder u te laten misleiden, staat in het artikel over het lokale model.

Wat op uw hardware draait

De hardwarepassing sorteert het veld sneller dan elke benchmark, omdat een model dat niet op uw kaarten past, simpelweg afvalt.

Qwen3 is hier de uitzondering. De dense varianten van 4B tot 32B draaien gekwantiseerd op een tot twee GPU's, en de 30B-A3B-MoE-variant levert modelkwaliteit bij slechts ongeveer 3B actieve rekenlast. Dat is het formaat dat past bij een typische on-premise box in het mkb.

Kimi K2 en Minimax M2 zijn frontier-MoE-modellen. Minimax activeert weliswaar slechts 10B parameters, maar de volledige gewichten vereisen een server met meerdere GPU's; Kimi met 1 biljoen totale parameters al helemaal. Nemotron 3 Nano is met 3,6B actieve parameters zeer zuinig en draait op een enkele kaart, maar valt terug vanwege de licentie. Wat deze VRAM-realiteit concreet kost, hebben we doorgerekend in het artikel over hardware.

De geopolitiek zit in de gewichten, niet in de API

Bij open-weightmodellen verschuift de soevereiniteitsvraag: de gewichten draaien volledig offline, dus is er geen externe uitschakelaar. Wat overblijft, is wat in het model zelf is ingebakken.

Drie van de vier labs zijn Chinees (Qwen, Kimi, Minimax), een is Amerikaans (Nemotron). Omdat de gewichten lokaal draaien, is de eigenlijke vraag niet de serverlocatie, maar de uitlijning in het model zelf. Onafhankelijke tests melden hoge weigeringspercentages van Chinese modellen bij politiek gevoelige onderwerpen, het sterkst in het Chinees en zwakker, maar aanwezig, in het Duits (ChinaBench). Deze cijfers zijn zelf gepubliceerd en niet peer-reviewed, dus met voorzichtigheid te lezen, maar het effect is reëel genoeg voor een eerlijke paragraaf in het lastenboek.

Voor pure B2B-tekstwerkzaamheden, dus concepten, extractie, classificatie en retrieval over uw eigen documenten, is dit effect meestal beheersbaar. Het is een kwestie van uitvoerkwaliteit en externe uitstraling, geen beveiligingslek. De bredere soevereiniteitsboog, Europese modellen en wat het label werkelijk waard is, behandelen we in het artikel over soevereine Europese AI.

Hoe ik dit beslis voor een mkb-bedrijf

De beslissing is niet patriottisch en niet gedreven door het leaderboard, ze volgt een volgorde. Zo pak ik het aan:

1. Licentie controleren. Alleen modellen met een echte Apache- of MIT-grant komen zonder juridische ruggenspraak in de engere selectie. Dat zijn hier Qwen3, Kimi K2 en Minimax M2.
2. Op uw eigen Duits testen. Niet de Engelse benchmark, maar vijftig van uw echte teksten tegen twee kandidaten laten lopen en blind beoordelen.
3. Hardware afstemmen. Wat op uw een tot twee kaarten past, wint bijna altijd, omdat de operatie anders duur en fragiel wordt.

Voor de meeste mkb-bedrijven komt dat neer op Qwen3 als startpunt: vrij gelicentieerd, breed meertalig, in het juiste hardwarevenster. Kimi en Minimax zijn de keuze wanneer de server toch al draait en reasoning of agents op de voorgrond staan. Het open-weight-codeermodel Kimi K2.7 hebben we daarvoor apart bekeken.

En, zoals altijd bij ons: bouw de architectuur zo dat u het model kunt vervangen. Het volgende betere open-weightmodel komt vast en zeker. De eigenlijke vraag is niet welk model vandaag vooroploopt, maar welke van uw taken het sterkste model daadwerkelijk nodig hebben en welke slechts een goed model nodig hebben dat van u is. Welke van uw teksten zou u toevertrouwen aan een model dat u niet zelf hebt getest?

Dit artikel is de praktijkversie van deze opzet en de eerlijke versie van de beperkingen ervan.

De vault is het bezit, de agent is gehuurd

Houd het duurzame en het vervangbare gescheiden, en het grootste deel van het ontwerp volgt daaruit vanzelf.

Het duurzame is uw vault: gewone .md-bestanden, [[Wikilinks]], YAML-frontmatter. Geen database, geen eigen formaat, geen exportstap. Het vervangbare is de agent die hem leest. De twee toonaangevende community-projecten op dit vlak, obsidian-second-brain en obsidian-mind, leveren beide bewust voor Claude Code, Codex CLI en Gemini CLI. De vault is de investering; het model is een huurder die u kunt opzeggen.

Dat is dezelfde overweging die wij toepassen op het verbinden van AI met elke stack: de interface bezitten, de capaciteit huren. Wij hebben dit voor systeemintegratie uitgewerkt in API, MCP of CLI. Persoonlijk kennisbeheer is hetzelfde argument, op bureauschaal.

Wat verandert wanneer een agent uw notities kan lezen

Een agent met bestandstoegang verandert een statische vault in een vault die zichzelf onderhoudt, binnen de grenzen die u stelt.

• CLAUDE.md is het bedieningshandboek. Voer claude uit vanuit de hoofdmap van de vault, en het laadt dit bestand in elke sessie: uw mapoverzicht, uw linkconventies, uw notitiesjablonen, uw standaardgedrag. Het is het enige dragende bestand in elke werkende opzet. /init schrijft een eerste concept.
• Sessiecontext is een hook, geen magie. obsidian-mind injecteert bij het begin van een sessie een uittreksel van het noordsterdocument, een takenlijst en een bestandsoverzicht, zodat de agent niet leeg begint. Dat is een SessionStart-hook die op uw eigen machine draait, meer niet.
• Archiveren wordt een skill. Slash-commands en subagents nemen de vaste taken over: een geknipte notitie in de juiste map plaatsen, een Map of Content genereren, verweesde notities vinden, het daglog schrijven. obsidian-second-brain levert er tientallen van.
• Frontmatter is de machineleesbare laag. Datum, status, bron, een betrouwbaarheidsmarkering in YAML plus wikilinks geven de agent structuur om op te halen en te kruisverwijzen, in plaats van te gokken op basis van proza.

De nieuwste verschuiving zijn notities die overschrijven in plaats van aanvullen: een nieuwe bron werkt bestaande notities bij en stemt ze af, in plaats van er nog een gedateerde vermelding op te stapelen. Nuttig, en de eerste plek waar voorzichtigheid op zijn plaats is, dat is de op-een-na-volgende sectie.

Ophalen, niet dumpen: de tokenrealiteit

Laad niet de hele vault. Laat de agent de paar notities ophalen die een vraag nodig heeft.

De naïeve opzet duwt de hele vault in de context en stort in bij een paar honderd notities. De zuinige opzet laat alles op de harde schijf staan en haalt alleen op wat past, via een opdrachtregelzoekopdracht of grep. Beoefenaars melden een verschil van rond de 100 tokens voor een CLI-zoekopdracht in de vault tegenover tienduizenden voor het laden van een heel project. Het mechanisme is onopvallend: zoeken, de drie relevante notities lezen, antwoorden.

Dat blijft van belang, ook nu Claude Code inmiddels een contextvenster van een miljoen tokens gebruikt. Het rollende ratelimiet bijt allang voordat het venster vol is: een vault die in 100 tokens antwoordt, laat u honderd vragen stellen, waar de opzet die alles dumpt u een handvol geeft. Zuinig ophalen is wat een tweede brein dagelijks bruikbaar maakt in plaats van eenmalig indrukwekkend.

De privacygrens is de inferentie, niet de opslag

De community verkoopt het als "alles blijft in uw vault, geen SaaS". Dat klopt voor de opslag en klopt niet voor de inferentie, en dat verschil is het hele risico.

Uw Markdown blijft op uw harde schijf. Maar standaard stuurt elke aanvraag de relevante notities om te lezen naar een cloud-API. Voor een hobbyvault met recepten is dat prima. Voor een vault met klantnotities, contracten of alles wat onder een verwerkersovereenkomst valt, verlaten er bij elke vraag gegevens het pand. Eenvoudige Markdown-portabiliteit is niet hetzelfde als lokale gegevensbescherming.

Nog twee eerlijke voorbehouden. Prompt injection is structureel: een agent die uw notities leest, kan "instructies" niet netjes scheiden van "inhoud". Elke Markdown die in de vault terechtkomt, een geknipte webpagina, een gedeelde notitie, een ingelezen PDF, kan instructies bevatten waarnaar de agent vervolgens handelt. En het risico is niet hypothetisch: in april 2026 misbruikten aanvallers Obsidian-community-plugins om code uit te voeren zodra een slachtoffer een gedeelde vault opende, gemeld door The Hacker News. Een agent met schrijftoegang tot bestanden en shell-toegang verhoogt die inzet, verlaagt hem niet. Notities die zichzelf overschrijven, kunnen ook stilletjes een backlink verzinnen of een correcte regel overschrijven, en de wijziging is opgeslagen voordat u ze leest.

Hetzelfde patroon, soeverein gehouden

Alles wat goed is aan deze opzet blijft overeind wanneer u het model in huis haalt. Het privacyprobleem is het enige onderdeel dat verandering nodig heeft.

De soevereine versie behoudt de vault en de workflow en ruilt cloud-inferentie in voor een lokaal model: een ophaallaag boven op uw Markdown, bediend door een model op uw eigen hardware of bij EU-hosting. U behoudt de zeggenschap over de gewone tekst, het CLAUDE.md-bedieningshandboek, de skills, en u stopt met het versturen van de inhoud bij elke vraag. Voor een mkb-bedrijf is dat de brug van een persoonlijk experiment naar echt intern kennisbeheer, producthandleidingen, procesdocumentatie, servicegeschiedenis, zonder dat er bij elke aanvraag een vraag over de verwerkersovereenkomst boven blijft hangen. Wanneer die stap loont en wat hij kost, is het onderwerp van On-Premise vs. Cloud-LLM.

De hobbyistische framing luidt "bouw een tweede brein". De zakelijke framing is dezelfde machine, gericht op de kennis van het bedrijf in plaats van die van u. De interessante vraag is, opnieuw, niet of het werkt. Het is wie de notities mag lezen. Dus: waar stuurt uw vault op dit moment daadwerkelijk zijn vragen naartoe?

Dit artikel brengt beide in kaart: wat al sterk is, waar het knelt, en wat daaruit volgt voor een bedrijf ter plaatse.

Het onderzoek is er, en het is degelijk

De onderzoekskant hoeft zich voor geen enkele deelstaat te verbergen. Ze is alleen sterk geconcentreerd.

Kaiserslautern draagt de kern: hoofdvestiging van het DFKI, de RPTU met acht AI-hoogleraarschappen, Fraunhofer IESE en ITWM, plus een samenwerking met het Max Planck Instituut. Het landelijk eerste AI-innovatie- en kwaliteitscentrum van Mission KI is eveneens hier gevestigd, met 32 miljoen euro aan federaal budget. Koblenz bouwt de tweede pool: de universiteit is in juli 2025 gestart met een interdisciplinaire AI-hub, en de Hochschule Koblenz beheert met DigiMit een expertisecentrum voor de regio.

De eerlijke duiding staat er meteen naast. Het cluster is zwaar gericht op Kaiserslautern en Koblenz, de rest van het gebied is minder goed aangesloten, en in de landelijke vergelijking staat Rijnland-Palts in de voorhoede, niet aan de top. Bij digitalisering lopen Beieren, Berlijn en Hamburg voorop, bij innovatie Baden-Württemberg.

De deelstaat zet zelf in op soevereine AI

Opmerkelijk is waarmee de deelstaat werkt: niet met een Amerikaans cloudabonnement, maar met een eigen, soevereine lijn.

De AI-agenda van de deelstaat noemt een AI-drieluik, en een van de drie pijlers heet uitdrukkelijk LLM on-premise. Met GPU4GenAI investeert de deelstaat in eigen GPU-infrastructuur bij het DFKI, en sinds september 2025 loopt een op drie jaar opgezette samenwerking met het DFKI die AI in het deelstaatbestuur brengt: documentanalyse, veilige dataplatforms, assistentiesystemen.

Dat is meer dan een kanttekening. Als de overheid in Rijnland-Palts privacyconforme, lokaal draaiende AI bouwt, dan is on-premise- en soevereiniteitsadvies voor het mkb geen nichethema, maar een aansluitend thema bij wat de deelstaat voordoet. De afbeelding hieronder toont het kernprobleem: sterke knooppunten, te weinig lijnen naar de rest van het gebied.

In het mkb ziet de situatie er anders uit

Op de werkvloer ligt de snelheid anders, en de cijfers zijn nuchter.

In een enquête van de Hochschule Koblenz in het noorden van Rijnland-Palts (176 bedrijven, december 2025) beoordeelt slechts 8,5 procent AI vandaag als centraal voor het bedrijfsmodel, over vijf jaar toch 42 procent. Meer dan een kwart gebruikt al AI-tools, ongeveer de helft test in pilotprojecten. Een tweede regionale studie van de IHK en de Handwerkskammer Koblenz toont het eigenlijke patroon: bijna twee derde gebruikt AI, waarvan de meesten pas sinds hoogstens twee jaar, bijna 90 procent zet daarbij op externe software, en de grootste genoemde uitdaging is rechtszekerheid.

Toponderzoek en brede diffusie zijn dus twee verschillende zaken. Het ene is hier aanwezig, het andere nog niet.

De kloof zit in de uitvoering, niet in de techniek

Het obstakel in het mkb is zelden het model. Het is de weg van het idee naar een veilige, productieve inzet.

Landelijk heeft slechts ongeveer een derde van de bedrijven een uitgewerkte AI-strategie, in Rijnland-Palts wordt herhaaldelijk gebrek aan vakkennis als rem genoemd. En de bijna 90 procent die op externe software zet, koopt daarmee afhankelijkheid in, vaak van Amerikaanse clouddiensten, precies daar waar diezelfde bedrijven rechtszekerheid als grootste zorg aangeven. Dat is een voorspelbare tegenstrijdigheid.

Een eerlijke nuancering hoort daarbij: gebruikscijfers overschatten de volwassenheid. Veel ervan is informeel gebruik van vrij beschikbare tools, zonder strategie, zonder governance, zonder duidelijk gegevensbeschermingskader. De vraag is in het mkb allang niet meer AI ja of nee. Ze luidt soeverein en productief in plaats van informeel en riskant. Wat dat praktisch betekent, hebben we uiteengezet in de praktische AI-routekaart voor het mkb.

Wat dit betekent voor bedrijven in Rijnland-Palts

De voor de hand liggende strategie is degene die de deelstaat al volgt: profijt binnenhalen zonder de datasoevereiniteit op te geven.

De ontbrekende bouwsteen is niet nog een tool, maar de laag tussen subsidie en onderzoek aan de ene kant en productieve, soevereine inzet aan de andere kant. Concreet betekent dat: lokale of in Duitsland gehoste modellen voor gevoelige data, RAG-kennismanagement op de eigen documentenvoorraad, en een nuchter pad van use-case-selectie tot pilotgebruik. Wanneer lokale AI zich tegenover de cloud loont, brengen we in kaart in On-premise vs. cloud-LLM.

Wij bij iiterate zitten in Koblenz en Remagen, dus middenin de tweede AI-pool van de deelstaat, en precies deze diffusielaag is ons werk: strategie, bouw en compliance samenbrengen, in plaats van mkb-bedrijven alleen te laten tussen subsidiebeschikking en werkvloer. Het onderzoek in Rijnland-Palts staat vast. De interessantere vraag is hoe snel het de rest van het gebied bereikt, en wie daarvoor de lijnen trekt.

Deze tekst legt uit waarom lange context duur is, welke subkwadratische aanpakken er zijn, wat van de luidste beloftes daarvan is bewezen, en wat dit concreet oplevert voor on-premise RAG. De aanbeveling aan het einde is onspectaculair en juist daarom houdbaar.

Waarom lange context duur is

De reden ligt in de wiskunde van self-attention: de rekenkosten groeien kwadratisch met de lengte van de invoer.

In een klassieke transformer vergelijkt elke token elke andere token. Verdubbelt de contextlengte, dan verviervoudigt ruwweg de rekenlast voor de attention. Daar komt het geheugen bij: de key-value-cache die het model tijdens het genereren bijhoudt, groeit lineair met de lengte en verslindt op een vaste GPU snel het beschikbare geheugen. Dat is het eigenlijke knelpunt bij on-premise gebruik, waar de hardware vaststaat en niet elastisch kan worden bijgehuurd.

Precies hier grijpen subkwadratische aanpakken in. Ze proberen de kosten per sequentie richting lineair te drukken, dus O(n) in plaats van O(n tot de macht twee), en het geheugen per token te beperken. Wat dit betekent voor de hardware-realiteit in het bedrijfsleven, hebben we doorgerekend in lokale LLM.

Het subkwadratische landschap

Er zijn meerdere wegen, en de praktische winnaar van de jaren 2024 tot 2026 is niet de zuiverste, maar de hybride.

• State-space-modellen (Mamba). Mamba (december 2023) en Mamba-2 (mei 2024) modelleren sequenties in lineaire tijd met een vast toestandsgeheugen in plaats van een groeiende cache (arXiv). De prijs: een vaste toestand is een compressor met verlies en zwakker in het exact onthouden van ver terugliggende passages.
• Lineaire attention (RWKV, RetNet). Herformuleren de attention zodanig dat de kosten ongeveer lineair groeien. Vergelijkbare afweging bij associatief geheugen.
• Hybrides in productie. Niemand levert pure subkwadratische modellen van topkwaliteit. In plaats daarvan mengt iedereen een minderheid aan volledige attention-lagen met een meerderheid aan state-space- of lineaire lagen: Jamba (AI21, 2024), MiniMax-01 (januari 2025), Falcon-H1 (mei 2025), NVIDIA's Nemotron-H, IBM Granite 4.0 (oktober 2025) en Qwen3-Next (september 2025). De volledige lagen bewaren het geheugen, de slanke lagen kopen het voordeel op kosten en geheugen.

De NVIDIA-lijn achter Nemotron, die precies deze hybride opbouw gebruikt, hebben we beschreven in Nemotron 3.

Wat 'subQ' belooft, en wat daarvan is bewezen

De term vraagt om voorzichtigheid, want hij draagt twee betekenissen, een architecturale en een vermarkte.

Naast de algemene subkwadratische familie bestaat er een concreet product: de start-up Subquadratic kwam in mei 2026 met een financiering van ongeveer 29 miljoen dollar uit de schaduw en profileert zich met een subkwadratische, spaarzame attention. De koppen zijn groot: een onderzoeksmodel met 12 miljoen tokens context, ongeveer een vijfde van de kosten ten opzichte van topmodellen, een veelvoud aan snelheid (The New Stack).

De eerlijke duiding: een deel is door derden geverifieerd, zoals een RULER-128K-resultaat, de spectaculaire cijfers over 12 miljoen tokens en de snelheidsfactor zijn daarentegen leveranciersclaims uit eenmalige runs en niet onafhankelijk gereproduceerd. Dat is een veelbelovende aanwijzing, geen basis voor inkoop. Precies dit onderscheid, bewezen tegenover beweerd, is de discipline die wij bij elk nieuw model hanteren.

Wat dit voor on-prem RAG betekent

De concrete winst is geheugen en doorvoer op vaste hardware, en dat is voor on-premise RAG precies de juiste hendel.

• Beperkte cache, voorspelbaar geheugen. De state-space-lagen dragen een vaste toestand, het geheugen explodeert dus niet met de lengte. IBM noemt voor Granite 4.0 meer dan 70 procent minder behoefte bij lange context, een leveranciersclaim, maar plausibel en in de richting van meer gelijktijdige sessies per GPU.
• Model en context op één kaart. NVIDIA meldt dat een Nemotron-H-model met 51 miljard parameters inclusief cache op één enkele 80 GB-kaart past, eveneens een leveranciersclaim.
• Losser chunking-discipline. Goedkopere context maakt grotere vensters mogelijk en minder angstvallig opknippen van documenten.

Eerlijke voorbehouden horen erbij. Bij geheugenintensieve RAG, zoals de exacte vindplaats in zeer lange teksten, liggen pure subkwadratische modellen nog achter op volledige attention, hybrides dichten het gat grotendeels, maar niet helemaal. De tooling eromheen, dus kwantisering, serving en finetuning, loopt achter op de gevestigde dense modellen. En de belangrijkste zin: lange context is niet hetzelfde als goede retrieval. Een solide model met goede RAG verslaat vandaag bijna altijd de poging om simpelweg miljoenen tokens erin te kieperen. Wat RAG eigenlijk oplevert, staat in Wat is RAG en De kracht van RAG.

Hoe ik dit vandaag behandel

Subkwadratisch is het observeren waard, maar geen gok waard. Zo ga ik ermee om:

1. De RAG-laag modelonafhankelijk bouwen. Achter een stabiele interface, zodat een hybride van de Granite-4-klasse kan worden ingezet zodra de tooling eromheen volwassen is.
2. Starten met een solide, goed ondersteund model, niet met de nieuwste architectuur, en de waarde uit de kwaliteit van retrieval halen.
3. Onbewezen beloftes negeren. Een beweerde factor duizend wacht tot iemand onafhankelijk hem reproduceert.

Dat is hetzelfde patroon dat wij hanteren bij on-premise tegenover cloud: bewust beslissen, verwisselbaar bouwen (On-premise vs. cloud-LLM). De interessante vraag is niet of subkwadratische modellen op een dag lange context goedkoop maken. Dat zullen ze vermoedelijk doen. De vraag is of uw architectuur klaar is om die winst mee te nemen, zonder dat u er vandaag op wedt. Is uw RAG-laag zo gebouwd dat u het model kunt verwisselen zonder alles opnieuw te schrijven?

De meeste teams die AI in hun systemen integreren, hoeven geen winnaar aan te wijzen. Ze moeten elke aanroep op de juiste hoogte plaatsen. Dit artikel definieert de drie nuchter, laat zien wanneer welke past, benoemt de vaak over het hoofd geziene kosten en eindigt met een beslissing die u kunt verdedigen. Twee vragen verhelderen het meeste: hoeveel integraties beheert u, en wie moet ze controleren?

Drie niveaus, geen drie rivalen

Elk patroon bevindt zich op een ander abstractieniveau, met een duidelijke afweging tussen controle en gemak.

• Een directe API-aanroep is de onderste bouwsteen. Uw code roept een model of dienst aan via HTTP. U krijgt maximale controle en standaardtools, en schrijft de lijm zelf: authenticatie, verzoek, respons-parsing, foutafhandeling.
• MCP, het Model Context Protocol, standaardiseert de verbinding, niet het model. Het is een open standaard die Anthropic in november 2024 introduceerde en die een model een eenduidige manier geeft om tools en data te ontdekken en aan te roepen, zodat een MCP-geschikte client kan praten met een MCP-server die hij nog nooit heeft gezien (Wikipedia). Het verspreidde zich snel: in de loop van 2025 werd het overgenomen door OpenAI, Google en Microsoft, bereikte tegen april 2025 meer dan 5.800 community-servers en meldde tegen eind 2025 tweecijferige miljoenen aan maandelijkse SDK-downloads, voordat Anthropic het overdroeg aan een initiatief van de Linux Foundation (Thoughtworks, The New Stack).
• Een agentische CLI is het bovenste niveau. Een tool zoals Claude Code bundelt een model, een reeks tools en een reasoning-lus tot een terminal-workflow. Het minste lijmwerk, de meeste eigen mening, het snelst voor open taken.

Ze vullen elkaar aan in plaats van te concurreren: een agentische CLI kan MCP-servers aanroepen, die op hun beurt eenvoudige API's inkapselen (iiterate).

Wanneer elk op de juiste hoogte zit

De keuze volgt de vorm van de taak, niet de nieuwigheid van de optie. Een korte oriëntatie:

In de praktijk: een nachtelijke batchjob die een endpoint aanroept, moet de API rechtstreeks aanroepen, omdat MCP zonder nut alleen latentie en foutbronnen zou toevoegen. MCP rechtvaardigt zichzelf zodra meerdere agents dezelfde integraties nodig hebben, zodat elke MCP-client een uniforme interface krijgt in plaats van dat elke agent zijn eigen wrapper draagt. Het kantelpunt dat practitioners rapporteren, ligt bij ongeveer drie of meer AI-gekoppelde integraties (MindStudio). Een agentische CLI past wanneer de taak open is en iemand snel resultaten nodig heeft over veel tools heen.

De kosten die men over het hoofd ziet

De voor de hand liggende voordelen zijn makkelijk te vinden. De stillere kosten bepalen of een keuze goed veroudert.

• Tokens. Een gestandaardiseerde toolslaag is niet gratis. Wanneer een agent een tool herhaaldelijk aanroept, kan de discovery-overhead van MCP voor dezelfde taak veel meer tokens kosten dan een directe CLI- of API-aanroep (MindStudio).
• Observeerbaarheid. HTTP-aanroepen verschijnen in uw logs, en standaardtools zoals Datadog volgen ze kosteloos. Het MCP-transport is vergelijkenderwijs ondoorzichtig, en de monitoring in productieomgevingen is nog in ontwikkeling, zodat u betaalt met eigen instrumentatie (IJONIS).
• Lock-in en portabiliteit. Een pure API houdt de integratie in code die van u is. Hoe hoger u gaat, hoe sterker u afhankelijk wordt van een client, een server-ecosysteem of de agent van een leverancier. Houd een weg een niveau lager open.

Het beveiligingsoppervlak van MCP is nieuw en reëel

Het standaardiseren van hoe modellen tools bereiken, standaardiseert ook een nieuw aanvalsoppervlak, en dat verdient een expliciete behandeling.

OWASP voert Prompt Injection 2025 aan als de belangrijkste kwetsbaarheid voor LLM-toepassingen. MCP voegt een specifieke variant toe, Tool Poisoning, waarbij kwaadaardige instructies worden ingebed in de beschrijving van een tool, dichter bij een supply-chain-aanval op de context van de agent dan bij een jailbreak door de gebruiker, en geregistreerd als CVE-2025-54136 (TrueFoundry). Omdat MCP-servers vaak toegangsgegevens beheren en echte systemen bereiken, is een te ruim geautoriseerde of onbetrouwbare server een ernstig risico, en de bescherming aan clientzijde varieert sterk (Simon Willison, Microsoft). De praktische houding: geverifieerde servers gebruiken, iedereen de minste rechten geven en verder monitoren, dezelfde governance-vragen die gelden zodra een agent echte data raakt (iiterate).

Een beslissing die u kunt verdedigen

U hebt geen enkel antwoord nodig voor de hele organisatie. U hebt de juiste hoogte per integratie nodig. Een praktische regel:

1. Kies standaard voor een directe API voor een enkele, stabiele aanroep met hoog volume.
2. Grijp naar MCP wanneer meerdere agents dezelfde tools nodig hebben of u uitwisselbare tools achter één interface wilt.
3. Gebruik een agentische CLI wanneer het werk open is en een mens of een andere agent het aanstuurt.
4. Behoud op elk niveau de minste rechten, echte logs en een manier om een niveau lager terug te vallen, mocht een leverancier de voorwaarden wijzigen.

Voor de meeste productiesystemen is het eerlijke antwoord een mix: directe API's onder de diensten, MCP als vertaal- en discovery-laag voor agents, en een CLI waar mensen werken. De faalmodus is niet de verkeerde tool kiezen. Het is het nieuwste niveau overnemen omdat het het nieuwste is, en de kosten ervan betalen voor een taak die een lager niveau beter had afgehandeld.

De kern van deze bijdrage zijn niet de evenementen. Het is de vorm. event-scout is een agentische micro-app: iets dat men eenmalig met een coding-agent bouwt en vervolgens laat draaien, waarbij de agent het lastige oordeelsvermogen voor zijn rekening neemt en eenvoudige scripts de saaie, herhaalbare bedrading afhandelen. Deze verdeling is de hele les, en ze is toepasbaar op vrijwel elke interne taak die een mkb-team nog altijd handmatig uitvoert. event-scout draait op het bovenste van deze niveaus, een agentische CLI (iiterate).

WAT HET CONCREET DOET

Eén keer per run werkt event-scout zich door een gecureerde brondatabase van evenementpagina's, kalenders, nieuwsbrieven en enkele LinkedIn-feeds. Van alles wat het ophaalt, behoudt het alleen toekomstige fysieke evenementen binnen bereik van Remagen, beoordeelt elk ervan op hoe nuttig het voor ons is, verwijdert duplicaten in één enkele opslag en bouwt een dashboard opnieuw op dat we ook daadwerkelijk openen.

Weinig aan deze lijst is op zichzelf nieuw. Wat het laat werken, is dat het onbewaakt volgens een schema draait en dat het toegepaste oordeel het onze is, geen generiek relevantiefilter. Het resultaat is geen feed van elk tech-evenement in Duitsland. Het is een kort, gerangschikt antwoord op een vraag: waar zouden we als volgende moeten verschijnen.

DE VORM DIE HET LIET WERKEN: AGENT VOOR HET OORDEEL, SCRIPTS VOOR DE BEDRADING

De ontwerpbeslissing die telt, is waar het model ophoudt en een script begint.

Het ophalen is gedelegeerd aan een deterministische helper. Een kleine Node-orchestrator rendert elke verschuldigde bron in een echte headless browser, zodat hij JavaScript-pagina's, lichte anti-bot-muren en traag nagegenereerde lijsten aankan, en hij legt gestructureerde schema.org-evenementdata vast wanneer een pagina die vrijgeeft. Dat is bedrading: betrouwbaar, voorspelbaar en elke keer hetzelfde.

De agent leest wat de ophaler heeft opgeslagen, en handelt de delen af die zich onttrekken aan vaste codering: echte evenementen uit chaotische pagina's halen, bepalen wat telt als fysiek en relevant, elk beoordelen en herkennen dat twee items hetzelfde evenement zijn. Een tweede kleine engine voegt dan samen, verwijdert oude items en genereert het dashboard opnieuw.

🔸 Laat het model niet doen wat een script goedkoop afhandelt.
Een pagina renderen en een bestand schrijven is deterministisch werk. Dat aan het model overlaten zou langzamer, duurder en minder betrouwbaar zijn.

🔸 Laat een script niet doen wat oordeel vereist.
Of een half opgemaakt item een echt, relevant fysiek evenement is, is precies de beslissing waar een model goed in is en een reguliere expressie niet.

Deze lijn correct trekken is het grootste deel van waarom de tool betrouwbaar is en niet slechts een slimme demo.

HET STEMT ZICHZELF AF

Een scout die elke bron bij elke run op dezelfde manier controleert, verspilt het grootste deel van zijn moeite, omdat evenementen niet gelijkmatig opduiken.

Daarom draagt elke bron zijn eigen korte opbrengstgeschiedenis. Bronnen die betrouwbaar relevante evenementen leveren, worden bij elke run gecontroleerd. Bronnen die steeds weer leeg terugkomen, wijken uit naar een groeiende afkoelperiode, een week, dan twee, dan een maand, en worden na afloop daarvan opnieuw getest in plaats van weggegooid. Een bron die simpelweg geen evenementen leverde, wordt stilletjes teruggeschaald; alleen een bron die meerdere keren achter elkaar niet laadt, wordt als defect afgevoerd.

Het effect is dat de aandacht daarheen stroomt waar evenementen daadwerkelijk opduiken, en dat het zich over weken vanzelf bijstelt, zonder dat iemand het onderhoudt. Deze zelfafstemming is wat onbewaakt tot een echte uitspraak maakt en niet tot een hoopvolle.

STELLIGE BEOORDELING WINT VAN EEN GENERIEKE FEED

De beoordeling is bewust de onze. Elk evenement krijgt een waarde van 100, gewogen voor onze situatie: hoe dichtbij en gemakkelijk bereikbaar het is, hoe dicht de ruimte het soort kopers verzamelt dat wij bedienen, hoe intiem het is, of er een concreet hefboompunt is zoals een korting of een spreekslot en hoe snel het plaatsvindt.

De weging draagt een mening die wij over verkoop hebben. Een grote conferentie scoort alleen hoog als er een echt hefboompunt te benutten is, want voor relatiegedreven verkoop is een volle zaal zonder toegang minder waard dan een kleine regionale rondetafel waar we daadwerkelijk met mensen kunnen praten. Het resultaat leest als een beslissingscockpit in plaats van een kalender: het toont waar men een dag zou moeten investeren, niet alles wat bestaat.

Een generieke evenementenfeed zou dat niet kunnen weergeven, omdat het oordeel specifiek is voor hoe een bepaald team opdrachten wint. Die specificiteit is de reden waarom het de moeite waard was om het te bouwen in plaats van te kopen.

WAAROM EEN MICRO-APP, GEEN SAAS

event-scout is bewust klein. Het geheel is een handvol JSON-bestanden voor de bronnen en de evenementenopslag, een paar scripts en een zelfstandig HTML-dashboard dat direct vanaf de harde schijf opent. Er is geen database te beheren en geen abonnement te vernieuwen. De data blijven de onze, en de beoordeling ook.

Dat is dezelfde stap die Anthropics eigen niet-engineeringteams hebben beschreven, kleine interne tools bouwen met een coding-agent in plaats van een aanvraag indienen en wachten (claude.com). Wij hebben over dit patroon ook vanuit gebruikersperspectief geschreven (iiterate).

Het is niet vrij van ruwe kantjes, en het tegendeel beweren zou oneerlijk zijn. Login-beveiligde bronnen hebben eenmalig een handmatig vastgelegde sessie nodig. Een paar koppige pagina's blijven handmatige leads in plaats van foutieve resultaten. En we controleren elke nieuwe opbouw door de structuur van de pagina direct te inspecteren, omdat een screenshot blijft hangen aan een lettertype dat nog laadt. Niets daarvan verandert de conclusie: als een taak herhaalbaar en specifiek is voor uw manier van werken, kan een coding-agent er een kleine, zelf beheerde tool van maken, voor minder dan de SaaS of de handmatige uren die het vervangt. De moeilijkere vraag is niet of u er een kunt bouwen. Het is welke van uw wekelijkse verplichtingen stilletjes heeft gewacht om er een te worden.

Claude Code is gebouwd voor ontwikkelaars, maar het werk dat het ons stilletjes uit handen heeft genomen, ligt in marketing en het backoffice: de terugkerende, regelgebonden taken die niemand graag doet. De reden waarom het daar past, is eenvoudig. Iemand die een proces kent, de merkregels, de checklist voor de maandafsluiting, de manier waarop we een campagne-export taggen, schrijft dat proces eenmalig op in heldere taal, en de agent voert het uit op echte bestanden. Geen softwareproject, geen ontwikkelaar in het spel. Dit artikel is wat we hebben geleerd: waar het loont, waar niet, en hoe u zonder spijt begint.

De echte verschuiving is niet coderen. Het is het proces opschrijven

Voor een niet-ontwikkelaar is een coding-agent een manier om een terugkerend proces om te zetten in iets dat een machine uitvoert, zonder eerst software te bouwen.

Het mechanisme dat dit buiten de ontwikkeling mogelijk maakt, zijn Agent Skills. Een skill is een kleine map: een instructiebestand in heldere taal, optioneel een of twee scripts en het benodigde referentiemateriaal. De agent ziet alleen de naam van een skill en een eenregelige beschrijving, totdat uw taak hem nodig heeft, dan leest hij de volledige instructies wanneer dat nodig is. Simon Willison, die het format documenteerde bij de release in oktober 2025, vatte de economie helder samen: elke skill kost slechts een paar dozijn tokens totdat hij wordt gebruikt (simonwillison.net, Anthropic).

Het gevolg is het deel dat telt voor een mkb-team:

🔸 De auteur is een vakexpert, geen programmeur.
De persoon die het proces kent, schrijft de skill, zoals ze een nieuwe medewerker zou inwerken.

🔸 Connectors geven hem echt bereik.
Via MCP, een open connector-standaard, kan de agent lezen en handelen in echte systemen, in een spreadsheet, een gedeelde schijf, een ticketwachtrij, binnen de grenzen van de toegang die u verleent.

🔸 U bepaalt de reikwijdte.
Hij raakt alleen wat u hem laat raken. Deze rechtengrens is het hele spel, en we komen er verderop op terug.

Drie onopvallende taken waar het echt loont

De winst is onopvallend en terugkerend. Drie patronen hebben zich bij ons en in de publieke berichtgeving bewezen.

Marketingvarianten in grote aantallen. Anthropics eigen growth-marketingteam koppelde twee gespecialiseerde subagenten om een CSV met honderden lopende advertenties te lezen, de zwakke te markeren en frisse varianten binnen strikte tekengrenzen te schrijven, minuten werk in plaats van uren. Een bijbehorende Figma-plugin genereert tot 100 lay-outvarianten per run door koppen en beschrijvingen te verwisselen (claude.com). Het is hun eigen team, lees het dus als bewijs dat het patroon werkt, niet als uw eigen cijfer.

Opruimen van backofficegegevens. Het taaie midden van de week: een kaartafschrift omzetten in een onkostenoverzicht, een rommelige lijst opschonen, een terugkerend rapport ontwerpen vanuit een sjabloon. Eén enkele, niet-technische oprichter op r/SaaS beschreef hoe hij vrijwel zijn hele SEO-operatie via Claude liet lopen, en rapporteerde 1,54 miljoen zoekweergaven en 12.900 klikken in drie maanden, zonder ontwikkelaar en zonder bureau (r/SaaS). Het verslag van één persoon, maar een veelzeggend verslag.

Interne tools, gebouwd door de persoon die ze nodig heeft. Anthropics juridische afdeling prototypte een kleine "telefoonboom" die een vraag naar de juiste jurist leidt, gebouwd door een productjurist die geen code schrijft (claude.com). Het interessante deel is niet de tool. Het is wie hem heeft gebouwd, en dat daar geen ticket voor nodig was.

We hebben eerder al geschreven over waar AI in een onderneming echt zijn plaats verdient in plaats van alleen goed te demonstreren (iiterate); dit is dezelfde test, toegepast op een tool.

Waarom juist marketing en operations

Deze functies passen omdat hun werk terugkerend en regelgebonden is en al in bestanden staat.

Dat sluit naadloos aan bij wat een skill kan vastleggen. Een merkrichtlijnen-skill draagt het palet, de typografieregels en de toon. Een proces-skill draagt de afsluitchecklist of een compliancestap. Een sjabloon-skill draagt het document zelf. Anthropic levert een werkende merkrichtlijnen-skill als openbaar voorbeeld, met kleur-, typografie- en lay-outregels die een agent op verzoek toepast (GitHub, Anthropic).

De terugkerende bevinding in deze berichten is dat vakkennis het resultaat sterker stuurt dan programmeerkunde. Dat is het stille voordeel van het mkb. De persoon die het proces kent, is al in huis, en een skill is slechts hun proces, opgeschreven.

Waar het het verkeerde gereedschap is

Een coding-agent is het verkeerde gereedschap op het moment dat het werk ophoudt terugkerend, controleerbaar of veilig genoeg te zijn voor een breed geautoriseerde agent. De eerlijke risico's, in de volgorde waarin ze bijten:

Reikwijdte. Een agent met bestands- en systeemtoegang kan de verkeerde map verwijderen of het verkeerde bericht versturen. Geef hem het minst noodzakelijke recht: eerst alleen leestoegang, één map, een kopie van de gegevens, niet het origineel. Beveiligingsteams hebben gecatalogiseerd wat er misgaat wanneer deze stap wordt overgeslagen (Docker, Oso).

Zelfverzekerde onjuistheden. Hij zal een getal noemen dat hij niet heeft geverifieerd, in vloeiende prosa. Behoud een menselijk controlepunt voor alles wat het pand verlaat.

Governance en gegevens. Zodra het persoons- of klantgegevens raakt, gelden de AVG en de AI Act. Weet waar de gegevens zich bevinden en wie kan worden gecontroleerd voordat u het aansluit, dezelfde controlevraag die ten grondslag ligt aan het draaien van modellen die u zelf bezit, in plaats van ze te huren (iiterate).

Herkomst. De meeste gepolijste casestudy's, waaronder twee in dit artikel, zijn afkomstig van leveranciers. Lees ze als bewijs dat het werk mogelijk is, niet als bewijs voor uw rendement.

Hoe u zonder spijt begint

Begin klein, met werk waarbij u zich een fout kunt veroorloven.

1. Kies een taak die terugkerend en regelgebonden is en niet uw belangrijkste proces.
2. Schrijf het proces op als skill in heldere taal, zoals u een bekwame nieuwe medewerker op haar eerste dag zou inwerken.
3. Geef zo min mogelijk toegang: alleen leestoegang, één map, een kopie van de gegevens.
4. Behoud een menselijk controlepunt voor alles wat naar buiten gaat of persoonsgegevens raakt.
5. Meet aan de onopvallende maatstaf, de bespaarde uren op het saaie proces, niet aan hoe de demo aanvoelde.

Zo gedaan zijn de winsten klein en tellen ze op, wat het tegenovergestelde is van hoe deze technologie doorgaans wordt verkocht. De vraag waar het de moeite waard is om bij stil te staan, is niet of een coding-agent marketing- of operationeel werk kan doen. Het is welke van uw processen u daadwerkelijk hebt opgeschreven, want dat, niet het model, bepaalt hoe ver dat draagt.

Het centrale advies van het Europees Comité voor Gegevensbescherming over AI-modellen steunt op de formule "geval per geval", en de gezamenlijke richtsnoeren van EDPB en Europese Commissie over hoe de AVG de AI Act raakt, worden niet voor begin 2026 verwacht. De nuttige vraag is dus niet "is AI toegestaan onder de AVG". Ze luidt "onder welke voorwaarden, en welke van die voorwaarden beheersen wij daadwerkelijk". Dit artikel brengt de weinige harde grenzen, de grote voorwaardelijke middenmoot en de hefbomen die een mkb-team kan gebruiken in kaart. Het is oriëntatie, geen juridisch advies, schakel dus uw functionaris gegevensbescherming in voordat u handelt.

BEGIN MET DE WEINIGE DINGEN DIE ECHT BEPERKT ZIJN

Een korte lijst van AI-toepassingen ligt dicht bij een echt verbod onder de AVG. Die eerst kennen maakt de rest makkelijker te doorgronden.

• Uitsluitend geautomatiseerde besluiten over mensen. Artikel 22 beperkt besluiten met rechtsgevolgen of vergelijkbaar aanzienlijke impact die zonder betekenisvolle menselijke betrokkenheid worden genomen. Duitse toezichthouders lezen dit streng en verwachten doeltreffend menselijk toezicht in plaats van een goedkeuring in naam (Hogan Lovells).
• Bijzondere categorieën van gegevens, standaard. Gezondheids-, biometrische, levensbeschouwelijke en soortgelijke gegevens zijn volgens artikel 9 in beginsel uitgesloten van verwerking, tenzij een specifieke uitzondering van toepassing is. De AI Act creëert een smalle opening: artikel 10 lid 5 staat dergelijke gegevens strikt toe voor het opsporen en corrigeren van vertekening in hoogrisicosystemen (IAPP).
• Modellen die gebaseerd zijn op onrechtmatig verzamelde gegevens. Het EDPB-advies 28/2024 van 18 december 2024 stelt dat de ontwikkeling van een model met onrechtmatig verwerkte persoonsgegevens de rechtmatigheid van de inzet ervan kan aantasten, tenzij het model naar behoren is geanonimiseerd (EDPB).

Het meeste AI-werk valt buiten deze korte lijst, waar het antwoord zelden een vlak "nee" is. Het is een "ja, mits".

HET MEESTE IS VOORWAARDELIJK, NIET VERBODEN

De grote middenmoot van AI-werk is rechtmatig als u de juiste voorwaarden kunt aantonen en documenteren.

Twee voorwaarden doen het grootste deel van het werk. De eerste is een rechtsgrondslag. Voor het trainen en gebruiken van modellen met persoonsgegevens legde het EDPB een drietrapstest voor het gerechtvaardigd belang voor, die het belang zelf, de noodzaak van de verwerking en een afweging tegen de rechten van betrokkenen weegt (EDPB). Het gerechtvaardigd belang staat ter beschikking, maar wordt via deze test verdiend, niet verondersteld.

De tweede is anonimiteit die u niet zelf mag verklaren. Datzelfde advies stelt dat een op persoonsgegevens getraind model niet automatisch anoniem is. Het geldt alleen als anoniem wanneer het zeer onwaarschijnlijk is om zowel de personen te identificeren wier gegevens het model hebben getraind, als die gegevens via query's te extraheren, per geval beoordeeld door de toezichthouder (IAPP). Het advies steunt zo zwaar op "geval per geval" dat juridische analisten de formule in de tekst hebben nageteld (Ropes & Gray). De praktische lezing: het meeste AI-verwerking is toegestaan, op voorwaarde dat u uw grondslag en uw documentatie kunt tonen.

DE VOORWAARDEN ZIJN VOORAL ARCHITECTONISCH

Het bemoedigende deel is dat de voorwaarden waaraan u moet voldoen grotendeels bepaald worden door hoe u het systeem bouwt, niet door wie u bent.

• Minder bewaren, korter. Dataminimalisatie en doelbinding gelden op de AI-specifieke plekken waar gegevens zich verstoppen: prompt- en systeemlogs en de vectoren in een RAG-store. EDPB-richtsnoeren wijzen erop om wat gelogd wordt te minimaliseren, geaggregeerde of pseudonieme identifiers te verkiezen en de bewaartermijn kort te houden (EDPB-analyse).
• Bewust beslissen waar de gegevens liggen. Sinds het Schrems II arrest is de doorgifte van persoonsgegevens aan een Amerikaanse aanbieder niet geregeld door louter het ondertekenen van modelcontractbepalingen. U moet nagaan of deze bepalingen, gezien het Amerikaanse toezichtsrecht, daadwerkelijk afdwingbaar zijn, en die verantwoordelijkheid kunt u niet afschuiven op de aanbieder (analyse).

Dat is de praktische reden waarom dataresidentie en on-premise draaien sturingshefbomen zijn in plaats van ideologie, hetzelfde punt achter het draaien van modellen die u bezit in plaats van huurt (iiterate).

DE AVG EN DE EU AI ACT ZIJN TWEE REGIMES, NIET ÉÉN

Het helpt om gegevensbescherming en AI-regulering te behandelen als gescheiden verplichtingen die elkaar raken, in plaats van als één enkel regelstelsel.

De AVG is een grondrechtenregime over persoonsgegevens; de AI Act ligt dichter bij productveiligheidsrecht voor AI-systemen (IAPP). Een hoogrisicosysteem kan verplichtingen uit beide schuldig zijn: een gegevensbeschermingseffectbeoordeling (DPIA) volgens artikel 35 van de AVG en een grondrechteneffectbeoordeling (FRIA) volgens artikel 27 van de AI Act, die de eerste aanvult in plaats van vervangt. De twee grijpen ook op onhandige wijze in elkaar. Practici wijzen er bijvoorbeeld op dat AVG-profilering een systeem opnieuw binnen de reikwijdte kan trekken van iets dat een AI Act-uitzondering ogenschijnlijk had vrijgesteld (r/gdpr). Officiële hulp is onderweg: EDPB en Europese Commissie zouden begin 2026 gezamenlijke richtsnoeren over de overlap publiceren (IAPP).

EEN HAALBARE COMPLIANCEHOUDING VOOR EEN MKB-TEAM

U hebt geen zekerheid nodig die de toezichthouder niet geleverd heeft. U hebt een onderbouwde, gedocumenteerde houding nodig. Een praktische volgorde:

1. Breng in kaart waar persoonsgegevens het systeem binnenkomen: invoer, prompts, logs, trainingsgegevens en de RAG-store.
2. Kies en documenteer een rechtsgrondslag voor elk gebruik. Steun op het gerechtvaardigd belang, voer de afwegingstoets uit in plaats van hem aan te nemen.
3. Voer een DPIA uit voordat u iets inzet dat mensen profileert of over hen beslist, en houd voor artikel 22-gevallen een mens betekenisvol betrokken.
4. Minimaliseer en beperk in de tijd wat het systeem bewaart, vooral promptlogs en vectoren.
5. Beslis bewust over de dataresidentie. Zouden persoonsgegevens de EU verlaten, voer dan de doorgiftetoets uit of houd de verwerking in de EU of on-premise.
6. Herzie de houding zodra de gezamenlijke richtsnoeren van EDPB en Commissie in 2026 verschijnen.

De korte versie: aan AI is onder de AVG zeer weinig categorisch verboden, een paar dingen echt wel, en de rest is overwegend een gedocumenteerd "ja, mits". De voorwaarden die het bepalen zijn overwegend architectonisch, wat betekent dat u ze zelf instelt. Dezelfde governancevragen duiken op zodra een interne agent klantgegevens raakt (iiterate). Dit blijft oriëntatie in plaats van juridisch advies, maak dus uw functionaris gegevensbescherming tot de volgende lezer.

De Europese modelscene, Mistral en de spelers eromheen, heeft in 2026 echt geld en echte modellen. Tegelijkertijd loopt zij op pure capaciteit achter op de Amerikaanse en Chinese top, en het woord Europees op een etiket betekent op zichzelf nog geen soevereiniteit. Voor een mkb-bedrijf is de nuttige vraag dus niet of er een Europees model bestaat. Het is welke soort controle u werkelijk nodig hebt en wat die u oplevert. Dit artikel brengt het landschap in kaart, de eerlijke lacunes, en de beslissing die daaronder ligt.

Wat soeverein werkelijk betekent, en wat niet

Soevereine AI betekent dat het model en de bijbehorende data onder de juridische en operationele controle van een organisatie blijven. De hefbomen die dat leveren zijn concreet: open gewichten die u zelf kunt hosten, en hosting die de data binnen de EU of op uw eigen machines houdt.

Twee eerlijke voorbehouden behoeden het woord ervoor marketing te worden.

🔸 Een EU-postcode is op zichzelf geen soevereiniteit.
Wetten inzake overheidstoegang, ook in Frankrijk en Duitsland, kunnen data op manieren afdwingen waartegen een EU-locatie niet volledig beschermt. Waar de data zich bevindt is noodzakelijk, maar niet voldoende.

🔸 Eigendom is net zo bepalend als herkomst.
Silo AI, de Finse maker van de open modellen Poro en Viking, is tegenwoordig een dochteronderneming van AMD, een Amerikaans bedrijf, wat het onder Amerikaans recht plaatst. Een in Europa ontstaan model in buitenlands eigendom is niet automatisch een soeverein model (North Atlantic).

Soevereiniteit is dus een vraag over de stack en het eigendom ervan, geen vlag op een homepage.

Mistral, en het geld dat Europa serieus maakte

Mistral is de reden waarom Europese AI ophield een voetnoot te zijn, en de manier waarop de financiering tot stand kwam is het eigenlijke signaal.

In zijn ronde die in september 2025 werd gerapporteerd, haalde Mistral ongeveer 1,7 miljard euro op bij een waardering van circa 11,7 miljard euro, en de leidende investeerder was ASML, de Nederlandse fabrikant van chipmachines, met ongeveer 1,3 miljard euro (CNBC). Dat een bedrijf dat de machines verkoopt waarmee geavanceerde chips worden gemaakt, zich inkoopt in een modellenlab, is een soevereiniteitszet, niet slechts een financiële. Mistral heeft dit gekoppeld aan infrastructuur en mikt op ongeveer 200 megawatt Europese rekenkracht tegen 2027, in eigendom in plaats van gehuurd, op locaties bij Parijs en een grote nieuwbouw in Zweden (Data Center Dynamics). Ook de enterprise-tractie is reëel, met benoemd werk naast Airbus, BMW, Amazon en SAP.

Het verhaal dat Mistral over zichzelf vertelt, is het nuttige deel: het probeert niet de pure modelrace tegen de Amerikaanse giganten te winnen, het probeert de Europese stack te bezitten die onder de modellen ligt. Voor een koper voor wie controle belangrijk is, telt deze positionering meer dan een plek in een ranglijst.

En verder: de rest van de Europese bank

Mistral is niet het hele veld, en de andere spelers onthullen verschillende weddenschappen op waar Europese waarde ligt.

Aleph Alpha, het Heidelbergse bedrijf dat ooit gold als de Duitse hoop op een topmodel, gaf de jacht op de top op en bouwde zichzelf opnieuw op rond een soevereiniteits- en complianceplatform, PhariaAI, gericht op on-premise- en air-gapped-inzet in gereguleerde sectoren (Analyse). Black Forest Labs, opgericht in Freiburg door een deel van het oorspronkelijke Stable Diffusion-team, maakt de open FLUX-familie van beeldmodellen (Dakota). En Teuken-7B, uit het door Fraunhofer geleide OpenGPT-X-consortium, is een openlijk downloadbaar model, getraind op alle vierentwintig officiële EU-talen, gebouwd om zelf te hosten (Fraunhofer).

Het opmerkelijke patroon is dat de sterkste Europese zetten steeds meer gaan over de stack, de openheid en het inzetmodel, in plaats van over één enkel topmodel. Precies daar ligt toevallig het voordeel voor een mkb-koper.

De eerlijke capaciteitskloof

Nuchter is geloofwaardiger dan lyrisch, dus hier de kloof helder. Op onafhankelijke capaciteitsindexen staat het Europese vlaggenschip eerder in het middenveld van het open-weight-veld dan aan de top (Artificial Analysis). Ook de financiering is scheef: de gecombineerde Europese modelfinanciering is klein naast de waardering van een enkel Amerikaans lab, dichter bij een afrondingsfout dan bij een rivaliteit (North Atlantic).

De nuttige stap is niet de kloof te ontkennen, maar te vragen of die uw taak raakt. Voor concepten, extractie, classificatie en retrieval over uw eigen documenten haalt een door u volledig gecontroleerd open middenveldmodel meestal de lat, en controle is meer waard dan de laatste paar benchmarkpunten. Dat is dezelfde afweging die wij maakten toen een topmodel binnen tweeënzeventig uur van een markt verdween: operationele controle wint het van gehuurde capaciteit, wanneer de gehuurde capaciteit kan worden afgenomen (iiterate). De top is waar Europese modellen werkelijk achterlopen. Het is ook het deel van het werk dat veel bedrijven eigenlijk niet nodig hebben.

Wat dit betekent voor een mkb-koper

De beslissing is niet patriottisch, ze is architectonisch. Drie praktische wegen, afhankelijk van wat de workload nodig heeft:

1. Topcapaciteit nodig, data niet gevoelig. Een gehost topmodel blijft de krachtigste optie. Gebruik het, en accepteer de afhankelijkheid bewust.
2. Controle is het punt. Voor gereguleerde data, tenant-isolatie, of alles wat u moet kunnen controleren, host u zelf een open Europees of open-weight-model, of gebruikt u EU-gehoste inferentie, en legt u dataresidentie en eigendom vast in de specificatie, niet in de marketing.
3. Beoordeel soevereiniteit aan de hand van de stack, niet van de vlag. Waar de gewichten draaien, waar de data zich bevindt, wie toegang kan afdwingen, en of u het model kunt vervangen. Dezelfde controlevraag ligt onder de AVG (iiterate).

De Europese scene is eindelijk reëel genoeg om voor het tweede geval een serieus antwoord te zijn, en dat is het merendeel van wat ons wordt gevraagd te bouwen. De reden om u erom te bekommeren is niet de vlag. Het is dat gehuurde capaciteit herroepbaar is en controle iets is wat u opbouwt. De vraag die het waard is om vast te houden, is niet of Europa dit jaar de top kan bereiken. Het is welke van uw workloads de top werkelijk nodig hebben en welke slechts een krachtig model dat u controleert.