--- title: "Jev: wat als IoT-systemen niet alleen meten, maar ook begrijpen?" description: "Wat Jev wel en niet kan, en wanneer contextuele AI in IoT iets toevoegt boven regels, sensorfusie of een gespecialiseerd ML-model." url: "https://alexandervanwynsberghe.be/schrijven/jev-iot-systemen-beslissen/" language: nl-BE --- [← Alle blogs](https://alexandervanwynsberghe.be/schrijven/) Edge & AI # Jev: wat als IoT-systemen niet alleen meten, maar ook begrijpen? Jev genereert geen tekst, maar kiest uit vaste opties. Een kritische kijk op wat zo’n model kan betekenen voor connected products, en wanneer gewone engineering het beter doet. 2 november 2026 · 8 min lezen Ik heb de voorbije jaren heel wat connected devices en IoT-platformen helpen bouwen, van elektronica en embedded software tot de infrastructuur om honderden toestellen te beheren. Als ik terugkijk, komt het vaak op hetzelfde neer. Een toestel verzamelt gegevens, stuurt die door naar een platform en software bepaalt met vooraf geprogrammeerde regels wat er moet gebeuren. Een temperatuur die te hoog wordt? Alarm genereren. Een machine die langer dan vijf minuten stilstaat? Operator verwittigen. Een sensor die geen gegevens meer verstuurt? Toestel als offline markeren. Daar is niets mis mee. Vaak is dat zelfs de meest betrouwbare manier van werken. Maar zodra de omstandigheden complexer worden, programmeren we uitzondering na uitzondering. We proberen de werkelijkheid te vertalen naar softwarelogica, alleen is die werkelijkheid niet altijd zo zwart-wit als de regels die we schrijven. Met die bril keek ik naar Jev, een model dat TypeSafe AI op 15 september voorstelde. Niet omdat ik denk dat één model dat probleem oplost, wel omdat het een andere manier toont om naar beslislogica te kijken. ## Wat Jev doet, en wat het niet doet TypeSafe noemt het een System One Model, naar het onderscheid dat Daniel Kahneman maakt tussen snel, intuïtief denken en traag, analytisch redeneren. Waar een taalmodel tekst genereert, werkt Jev met vooraf gedefinieerde antwoorden. Je stuurt een toestand mee, als tekst of als JSON, en stelt daar vragen over. Jev kiest één optie uit een lijst, plaatst de toestand op een schaal of beantwoordt een ja-neevraag. Wat terugkomt is een getypeerd resultaat met een kans per optie en een confidence score, waar software rechtstreeks mee verder kan. TypeSafe spreekt van een responstijd tussen 70 en 500 milliseconden, 40 tot 200 keer sneller dan een klassiek LLM voor dit soort vragen. Dat zijn claims van de leverancier. De prijs van 0,042 dollar per miljoen inputtokens wordt wel bevestigd in een academische evaluatie van de Universiteit van Bonn en Fraunhofer IAIS. Jev scoort daarin sterk op classificatiebenchmarks, maar ruis in de labels, fijnmazige categorieën en oordelen die domeinkennis vragen blijven moeilijk. En alle geteste taken zijn tekst. Over sensordata zegt die studie niets. Minstens even belangrijk is wat Jev niet doet. Het leert niet bij terwijl je het gebruikt. Het model is getraind, en wat je krijgt is inferentie: het beoordeelt telkens de context die jij aanlevert. Online learning, waarbij een systeem zich aanpast aan nieuwe waarnemingen, is iets anders. Een agent die zelfstandig acties uitvoert, ook. Als ik in deze blog zeg dat een systeem iets begrijpt, bedoel ik dat het meerdere signalen samen interpreteert. Niet meer dan dat. Jev draait bovendien in de cloud, via een API. Een versie voor een gateway of embedded hardware is er voor zover ik kon nagaan niet. ## Aanwezigheid: drie manieren om hetzelfde probleem op te lossen Thuis werk ik met KNX en ontwerp ik mijn automatiseringen bewust. Home Assistant is een mogelijke uitbreiding, maar daar ben ik nog niet. Wat volgt is dus geen experiment, wel een denkoefening over een probleem dat iedereen met domotica kent. ![Een kleine witte bewegingssensor op een nachtkastje, met op de achtergrond een brandende lamp en een digitale klok.](https://alexandervanwynsberghe.be/_astro/home-automation-klok-lamp.DNAVMHwR_Z2j259H.webp) Een bewegingssensor op het nachtkastje. Foto: Jakub Żerdzicki via Unsplash. De eenvoudigste aanpak is een bewegingssensor met een timer. Beweging, licht aan. Tien minuten geen beweging, licht uit. Dat werkt prima, tot iemand rustig in de zetel zit en nauwelijks beweegt. Maar het draait lokaal, is voorspelbaar en je weet altijd waarom het licht uitging. De tweede aanpak combineert sensoren. Een mmWave-sensor die ook ademhaling oppikt, een deurcontact, het verbruik van de tv. Daarmee bouw je een state-machine: wie binnenkwam terwijl de deur sindsdien dicht bleef, is er nog. Of je weegt de signalen probabilistisch af. Dat lost het zetelprobleem grotendeels op en blijft lokaal en controleerbaar. De prijs is complexiteit. Elke extra sensor brengt nieuwe combinaties, tot je je eigen logica niet meer begrijpt zonder documentatie. De derde aanpak laat een model de toestand beoordelen. Laatste beweging veertien minuten geleden, mmWave meldt aanwezigheid, de tv verbruikt 80 watt, het is tien uur ‘s avonds, de deur is dicht. Is de ruimte bezet, waarschijnlijk bezet of leeg? Het model hoeft de combinaties niet expliciet te kennen. Daar zit de belofte. Maar kijk wat je ervoor in de plaats krijgt. Een externe dienst om een lamp te schakelen. Aanwezigheidsdata die je woning verlaat. Een beslissing die moeilijker uit te leggen is. En als de API niet antwoordt, heb je toch de tweede aanpak nodig. Voor verlichting zou ik het dus niet doen. Interessanter wordt het bij beslissingen die niet tijdkritisch zijn, zoals of de verwarming een uur vroeger mag zakken of een melding de moeite waard is. Daar weegt een halve seconde niet door en mag een fout eens gebeuren. ## Een machine die meer verbruikt dan normaal ![Een gele industriële robotarm in een productiecel, met grijpers en een draaitafel op de achtergrond.](https://alexandervanwynsberghe.be/_astro/industriele-robotarm.DQKWeKLX_1iNEqD.webp) Een robotcel in een productieomgeving. Foto: Freek Wolsink via Pexels. In de industrie speelt hetzelfde, op grotere schaal. Stel dat het energieverbruik van een machine plots stijgt. Een klassiek monitoringsysteem geeft een alarm boven een grenswaarde. Maar misschien is die stijging perfect normaal. Misschien verwerkt de machine een ander materiaal, draait ze sneller of is de productieorder gewijzigd. Hier zit een valkuil die in veel AI-verhalen ontbreekt. Een model begrijpt geen ruwe meetwaarden. 47 kilowatt zegt niets zolang je niet weet wat normaal is voor dit product, aan deze snelheid, op deze machine. Eerst heb je een datalaag nodig die metingen omzet naar betekenis, met gegevens uit de PLC, het MES en het ERP. Een verwacht verbruik per order, de afwijking daarop, de onderhoudshistoriek. Dat is klassiek engineeringswerk, en vaak het grootste deel van het werk. En eens die laag er is, volstaat soms een eenvoudige regel. Verbruik twintig procent boven verwacht voor dit product, gedurende tien minuten? Melden. Een contextueel model voegt pas iets toe wanneer de combinaties te talrijk worden voor regels, of wanneer een deel van de context ongestructureerd is, zoals een notitie van de operator in het ploegverslag. Net daar, bij tekst, is een model zoals Jev het sterkst. ## Hebben we hier eigenlijk AI voor nodig? Die vraag zou ik bij elk IoT-project eerst stellen. Niet omdat AI slecht is, wel omdat de alternatieven vaak beter zijn. Een goed ontworpen state-machine is snel, draait op een microcontroller van een paar euro, is testbaar en doet morgen exact hetzelfde als vandaag. Sensorfusie en een probabilistische regel vangen veel onzekerheid op zonder dat er een model aan te pas komt. Voor ruwe signalen, zoals trillingen of de stroomvorm van een motor, is een gespecialiseerd model getraind op data van die machine een betere keuze dan een algemeen model dat vooral tekst gezien heeft. Zo’n model kan vaak op het toestel zelf draaien, tot op een microcontroller toe. Daar gaat TinyML over. Handgeschreven logica wordt een probleem wanneer de uitzonderingen sneller groeien dan je ze kan testen, of wanneer de context uit veel bronnen komt en niet altijd in getallen te vatten is. Dan kan contextuele interpretatie iets toevoegen. Maar ook dan moet je de rekening maken. Wat kost een cloudcall per beslissing op duizenden toestellen? Wat gebeurt er bij een netwerkonderbreking? Welke gegevens verlaten het gebouw? En hoe lang blijft het model beschikbaar in de vorm die je getest hebt? Een connected product gaat vaak tien jaar of langer mee, een API-versie meestal niet. Gebruik geen AI omdat het kan. Gebruik het wanneer je kan aantonen dat het een probleem beter oplost dan de bestaande alternatieven. ## Wat zegt een confidence score? Jev geeft bij elk antwoord een confidence terug, afgeleid van de kansverdeling over de opties. Maar 90% confidence betekent niet zonder meer dat het model in 90% van vergelijkbare situaties juist zit. Dat klopt alleen als het model gekalibreerd is, en dan nog enkel voor het soort gegevens waarop die kalibratie gemeten werd. De studie uit Bonn vindt de kansen bij keuzevragen over het geheel goed gekalibreerd, met duidelijke uitschieters per dataset. Bij ja-neevragen ligt de standaardgrens van 50% vaak verkeerd. Met drempels afgestemd op eigen trainingsdata ging het resultaat op sommige taken flink vooruit. Voor IoT is de les eenvoudig. Een benchmark op tekst zegt weinig over een defecte sensor, ontbrekende waarden of een situatie die nooit eerder voorkwam. Wil je op een confidence score vertrouwen, toets hem dan aan je eigen gelabelde gevallen en stem je drempels daarop af. Zo leert zo’n systeem in de praktijk bij. Jij past de omgeving aan, niet het model. ## Betrouwbaarheid zit in het systeem, niet in het model Bij fysieke systemen hebben softwarebeslissingen gevolgen in de echte wereld. Een machine die om veiligheidsredenen moet stoppen, mag niet afhankelijk zijn van een modeluitkomst, en zeker niet van een externe dienst. Die grenzen blijven deterministisch en lokaal, in de hardware of de PLC. Daarboven zou ik een model enkel inzetten met een paar duidelijke afspraken. De uitkomst wordt gecontroleerd voor ze iets in gang zet. Dat Jev altijd een van de toegelaten opties teruggeeft, helpt, maar een correct gestructureerd antwoord is nog geen correct antwoord. Niet elke beoordeling leidt tot een actie. Een model mag een melding filteren of een onderhoudstaak voorstellen, de beslissing blijft bij een operator. En er is altijd een fallback voor wanneer het model niet antwoordt of te onzeker is. De betrouwbaarheid van het geheel is belangrijker dan de intelligentie van één component. ## Van connected naar context-aware IoT draaide eerst rond connectiviteit, daarna rond platformen en data-analyse. Wat ik nu zie ontstaan, is een verschuiving van gegevens doorsturen naar situaties interpreteren. Architecturaal zie ik daarin vier lagen. Onderaan de sensoren en het fysieke systeem. Daarboven dataverwerking en deterministische logica, lokaal en voorspelbaar. Dan een laag die context interpreteert. En bovenaan gecontroleerde actie, binnen grenzen die de onderste lagen bewaken. Die contextlaag hoeft geen generatieve AI te zijn. Het kan sensorfusie zijn, een anomaliemodel op het toestel zelf, een model zoals Jev in de cloud, of een combinatie. Stel je voor dat een klein model op de edge afwijkingen detecteert, dat enkel de relevante gevallen naar een contextueel model gaan, en dat een redeneermodel de complexe gevallen verder uitzoekt. Dat is een hypothese, geen bestaande toepassing van Jev. Maar het is wel de richting die ik zie. Wat ik van Jev vooral meeneem, is dat software meestal geen antwoord in tekst nodig heeft. Een monitoringplatform wil weten of een gebeurtenis belangrijk is, een machine of een toestand normaal is. Een gestructureerd antwoord met een kans erbij past daar beter bij dan een chatinterface. ## Waar ik op uitkom Een sensor die een temperatuur meet, is op zichzelf niet intelligent. Een platform dat die temperatuur visualiseert, evenmin. Interessant wordt het wanneer je die meting combineert met andere gegevens en er een relevante beslissing uit volgt. De vraag is voor mij niet hoeveel AI we in een connected product kunnen stoppen. De vraag is hoe we systemen bouwen die context beter interpreteren, zonder de voorspelbaarheid, eenvoud en betrouwbaarheid van goede engineering te verliezen. Misschien is Jev niet de technologie die dat mogelijk maakt. Niet elke innovatie wordt een product dat blijft. Maar het heeft me wel anders doen kijken naar waar in een architectuur de interpretatie hoort. Technologie is maar een middel. Wat je ermee doet, is veel interessanter. ## Bronnen - [TypeSafe AI: Introducing System One Models & Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) (aankondiging en claims van de leverancier) - [Evaluating and Benchmarking the System One Model Jev](https://arxiv.org/html/2609.37647v1) (academische evaluatie, Universiteit van Bonn en Fraunhofer IAIS) - [DataRoot Labs: Jev, Two Weeks In](https://datarootlabs.com/blog/jev-two-weeks-in) Ik ben **Alexander Vanwynsberghe**. Ik schrijf over wat er gebeurt wanneer technologie de fysieke wereld raakt. [Reageer per mail](mailto:hi@alexandervanwynsberghe.be?subject=Over%20je%20blog) · [Meer over mij](https://alexandervanwynsberghe.be/over/) ## Verder lezen ### [Gehackte koelsystemen en de keerzijde van IoT](https://alexandervanwynsberghe.be/schrijven/gehackte-koelsystemen/) Security