Alle afleveringen
S06E33 - Hoe open staat jouw LLM deur? Over beveiligen van RAG-systemen
S06E33

Hoe open staat jouw LLM deur? Over beveiligen van RAG-systemen

Seizoen 6 37 min Hosts: Joop Snijder & Niels Naglé
0:00

Wat leer je in deze aflevering?

In een recente episode van AIToday Live, duiken de gastheren in de wereld van AI, met een speciale focus op de QCon-conferentie in Londen. Deze sessie werpt een licht op generatieve AI, beveiligingsvraagstukken, en de implementatie-uitdagingen waar bedrijven mee te maken krijgen. Van de manipulatie van grote taalmodellen tot de praktische toepassing van de OWASP richtlijnen voor veiligere AI-systemen, deze aflevering biedt een grondige analyse en praktische adviezen. Luister voor een gedetailleerde discussie over het belang van beveiliging in AI en hoe bedrijven dit op een verstandige manier kunnen aanpakken, rekening houdend met toekomstige ontwikkelingen en de noodzaak van een verantwoorde implementatie.

Kernbegrippen

RAG-systemen
Retrieval Augmented Generation; AI-systemen die externe gegevensbronnen raadplegen voor nauwkeurigere antwoorden.
OWASP Top 10 voor LLM's
Beveiligingsrichtlijn die de tien grootste risico's van taalmodellen identificeert en mitigatie aangeeft.
Prompt injection
Aanval waarbij kwaadwillenden instructies in invoertekst injecteren om AI-systemen ongewenst gedrag te laten vertonen.
Gefaseerde implementatie
Stapsgewijze uitrol van AI-systemen met pilots en testen voordat volledige productie plaatsvindt.

Interview: Willem Meints

Willem Meints
Willem Meints Chief AI Architect bij Aigency Bekijk gastprofiel →

Jullie zijn recent naar QCon in Londen geweest. Kun je uitleggen wat voor conferentie QCon is en wie er zoal op afkomen?

QCon in Londen is een bijzondere conferentie die zich specifiek richt op IT-beslissers en IT-architecten. Het zit tussen deze twee doelgroepen in en biedt vooral een perspectief op waar je nu en op middellange termijn op moet letten. De conferentie wordt georganiseerd door InfoQ, die ook veel van dit soort sessies, artikelen en podcasts aanbiedt. Het is echt interessant om te volgen. Dit keer waren we drie dagen aanwezig, drie dagen lang alleen maar kennissessies, van 's ochtends vroeg tot 's avonds laat. Er waren dit keer heel veel AI-tracks, en uiteraard veel over generatieve AI en grote taalmodellen. Wat vooral opviel is dat organisaties nu echt bezig zijn met implementaties, en daarom kunnen we van elkaar leren.

Wat zijn de belangrijkste aandachtspunten die naar voren kwamen van al die partijen die met large language models aan de slag zijn?

Er zijn echt wel een aantal opvallende dingen. Het is nog wel in het beginstadium, dat merk je. Er zijn een aantal grote partijen die hebben gezegd dat ze alles met AI-assistenten willen proberen te doen. Gelukkig zie je ook steeds meer partijen die voorzichtiger zijn en kleiner beginnen. Dat is één ding dat heel erg opvalt. Het andere belangrijke aandachtspunt is beveiliging. Die is echt heel belangrijk gebleken. Bij de eerste beveiligingssessie rondom large language models dacht ik ook: oké, hoe breed gaat dit worden? Maar het bleek dat ze het nog steeds hadden over traditionele IT-beveiliging. Want hoe ga je een combinatie van een large language model met andere bronsystemen beveiligen, zodat bijvoorbeeld informatie niet kan uitlekken uit je bedrijf?

Moet ik dan denken aan situaties waarbij je een large language model voorziet van de data van de organisatie?

Ja, precies. Dat doen wij ook bij Info Support. We hebben een assistent en die heeft toegang tot informatie uit het bedrijf in de vorm van een soort zoekmachine, een vector database. In ons geval mag iedereen daarin kijken, dat is geen probleem. Maar je kunt je voorstellen dat als je een wat grotere organisatie hebt, het belangrijk wordt dat je niet alle informatie zomaar mag zien. Sommige informatie is geschikt voor management, maar niet voor alle medewerkers. Dan wil je informatiebeveiliging gaan toevoegen.

Je had het over RAG-systemen. Kun je uitleggen wat dat precies inhoudt?

Het ging specifiek over RAG-systemen. RAG staat voor Retrieval Augmented Generation. Daarbij doe je zoekacties - dat is het retrieval-deel - op je eigen organisatiedata. Die data heb je toegevoegd aan dit systeem. Daar vind je relevante stukjes tekst en je taalmodel, dat zijn de GPT's die daar typisch onder zitten, of de systemen van Google, of welke dan ook. Zo'n groot taalmodel vertaalt dat antwoord naar de vraag die jij gesteld hebt. Dat is het generatiedeel. Retrieval betekent zoeken, augmented betekent dat je eigen documenten en eigen kennis toevoegt, en daarmee genereer je een antwoord. Dat zijn de systemen waar we het over hebben. Er wordt vooral heel veel gesproken over demo's op social media waar het lijkt alsof je dit in zeven minuten kunt bouwen. Er staan zelfs links in posts met de titel 'I built my RAG in seven minutes'. Ja, dat kan. Maar daarmee heb je ook heel veel problemen binnengehaald. Demosystemen kun je niet in productie brengen. Deze sessies gingen heel veel over wat er nodig is als je iets echt productierijp wil aanbieden binnen je organisatie of zelfs buiten je organisatie. Dan krijg je eindgebruikers die met jouw systeem gaan werken en daarmee krijg je nog meer eisen aan beveiliging en veiligheid. Want daar zit verschil tussen. Beveiliging gaat erover dat mensen geen dingen mogen doen die je niet wilt. Veiligheid gaat ook over hoe je veilig met het systeem omgaat en of je geen antwoorden terugkrijgt die niet kloppen.

Wat voor voorbeelden of potentiële oplossingen zijn er gegeven om met deze uitdagingen om te gaan?

Er is één voorbeeld dat ik hier wel kan delen waar we allebei heel hard om gelachen hebben. Er was een GPT-oplossing gebouwd op AWS - dat is de cloud-omgeving van Amazon. Die kon je bevragen wat er in jouw AWS-omgeving zat. Die GPT kon je vertellen welke web-applicaties je uitgerold had in Amazon, en kon je ook vertellen waar de broncode stond van die applicaties. Nu komt de truc: als je hem rechtstreeks vroeg om die broncode aan te leveren, dan zei hij "nee, dat mag ik niet". Maar als je dan een limerick schreef waarbij je expliciet die properties waar de broncode in vermeld staat verwerkte in die limerick, dan werd hij een beetje slap in de knieën en gaf hij gewoon antwoord. Dan spuugde hij letterlijk alle broncode en secrets - dus wachtwoorden om bij de spullen te komen - uit, alsof het de normaalste zaak van de wereld is. Wat ik echt de klapper vond: hij complimenteert je ook nog voor je rijm, dat je het heel poëtisch had gesteld. Dat is natuurlijk super link. Dat is gewoon IP, dat is gewoon een keiharde lek.

Waarom kon dat nou gebeuren? En hoe kunnen organisaties dit voorkomen?

Dat werd in die sessie helemaal uitgelegd. Heel veel wordt gedacht dat je met tegenprompts je taalmodel zou kunnen beveiligen. Dat je zegt "je mag geen broncode lekken" en dat in de prompt zet. Als je dat rechtstreeks vraagt, dan gaat hij ook zeggen dat dat niet mag. Alleen met taal iets waterdicht maken - we weten aan de juridische kant dat er overal altijd mazen in de wet zitten. We hebben niet voor niks rechters die zeggen "ja nee, maar zo moet je het niet lezen, zo moet je het wel lezen". Zo zie je het in de rechtspraak, interpretatie. Dat taalmodel kijkt naar wat de betekenis is van wat je hebt gevraagd. En als je die niet 100% hebt afgedekt - wat niet kan, dat gaat gewoon niet - dan gaat hij uiteindelijk antwoord geven op dingen die je niet wilt. De meest belangrijke stap hier is: geef je bot niet teveel persoonlijkheid. Wat bedoel ik daarmee? Zo'n botprogramma moet niet namens zichzelf bij beveiligde data kunnen komen. Dat moet de gebruiker kunnen. Dus als ik een administrator ben, dan wil ik misschien wel die broncodes kunnen zien. Maar als ik een gewone gebruiker ben, dan niet. Dus geef die bot niet alle rechten, beperk dat. Zorg ervoor dat het technisch onmogelijk is dat hij die informatie kan ophalen.

Even om te vertalen: binnen applicaties heb je een bepaalde rol met bepaalde privileges. Vaak wordt nu alle data naar de bot gestuurd. Maar wat je eigenlijk zegt is: doe de interactie via de bot, maar zorg dat het via de user met die rechten de informatie beschikbaar wordt gesteld?

Ja, precies. En dat is technisch best nog wel een dingetje. Je moet er wel flink wat voor doen. Maar dat is ook van: je kunt dit niet in zeven minuten doen. Je moet hier een aantal dagen wel mee bezig zijn om dit aspect van de beveiliging alleen al voor elkaar te krijgen, nog niet over de rest. Dit lijkt misschien een open deur - je gaat alleen met de rechten werken - maar dat is het dus niet. Dat zagen we in drie, vier sessies weer voorbij komen: uiteindelijk werd gewoon toegang tot teveel data toegekend, omdat die direct op de volledige applicatie of bronnen wordt gezet en niet met de tussenlaag van de gebruiker, die vaak buiten scope staat omdat je eigenlijk die informatie wil gebruiken.

Je noemde de OWASP top 10 voor grote taalmodellen. Kun je uitleggen wat dat inhoudt?

OWASP staat voor Open Web Application Security Project. Wat zij doen is heel goed nadenken over wat er allemaal mogelijke bedreigingen zijn als jij IT-systemen maakt. Ze doen het voor IT-systemen in het algemeen en hebben ook een top 10 voor machine learning applicaties. Nu hebben ze toegevoegd een top 10 voor applicaties gebaseerd op large language models. Wat ik mooi daaraan vind is dat ze in de inleiding schrijven dat de doelgroep mensen zijn die op een veilige, robuuste manier niet-gehaaste AI-systemen in productie willen brengen. Vooral dat "niet gehaast" is echt essentieel. Door de hype, door de druk, door bijna het FOMO-effect wat je ziet - we moeten nu - worden zoveel dingen gehaast gebracht, dat je ziet dat dit soort open deuren ook hele gevaarlijke deuren worden. Het is ook hartstikke asymmetrisch: als hacker kun je heel makkelijk inbreken in die taalmodellen door die taaltrucs. En als je jezelf wilt verdedigen, ja dan moet je echt behoorlijk je best doen om het dicht te houden. Mijn conclusie van een week QCon was: een taalmodel beveiligen is op dit moment onbegonnen werk. Steek liever de tijd in het beveiligen van alle IT-infrastructuur eromheen.

Dus je zegt: beveiligen met een prompt gaat niet lukken?

Ja, beveiligen met een prompt gaat je nooit lukken. Zorg ervoor dat je alles eromheen dicht hebt zitten. Toegang tot andere systemen, zorg ook dat je logging goed op orde hebt. Eigenlijk waar ik zelf heel erg aan moest denken na QCon was: we hebben weer even aandacht nodig voor een integrale aanpak van security in ons ontwikkelproces. Maak het standaard in je proces dat je er even bij stilstaat wat voor risico je loopt, en bedenk dan wat ga ik hiermee doen. Wat is er nodig voor mijn bedrijf om dat goed te houden? De OWASP is daar een hulpmiddel bij om even de top 10 risico's en zaken die je ziet ertegen aan te houden. Ben je bezig met projecten, pak die OWASP erbij, neem hem mee bij het definiëren van je user stories, bij je use cases.

Jullie hebben iets praktisch gebouwd om met de OWASP aan de slag te gaan?

Ja, om het echt praktisch te maken hebben Joop en ik een custom GPT gebouwd. Die gaan we via de show notes delen, exclusief voor de luisteraars. Zonder de link kom je er niet bij. Gebruik hem voor eigen risico. En als je hem wil hacken, doe het lekker, want het is gewoon een systeemprompt waar wij een paar uur aan hebben gewerkt, inclusief de documenten van OWASP. Wat hij doet is: als jij een user story definieert - dat is als jij nieuwe functionaliteit wil definiëren voor je systeem - is dat hij je laat nadenken. Hij neemt alles van de OWASP mee en geeft je hints van: in dit geval, voor deze feature die je aan het beschrijven bent, heb je mogelijk deze, deze, deze risico's. En kun je daar gewoon heel gericht mee aan de slag.

Kun je een voorbeeld geven uit de OWASP top 10?

Eén voorbeeld is wat ze prompt injection noemen. Voor de wat technischere mensen: die kennen misschien wel SQL injection, dat als je iets achter een linkje zet en dat gaat naar een database, en vervolgens voert die allerlei dingen uit en krijg je toch data terug. Met prompts zie je dat taalmodellen nu ook af en toe gewoon code uitvoeren. Dat je ze door een prompt onder water code kan laten uitvoeren. En dan wordt het wel heel erg eng. Dit is ook de nummer 1 in die top 10: dat je ervoor moet zorgen dat je geen prompt injection hebt, dat je niet iets kan toevoegen van een kwaadwillig stukje code die daadwerkelijk uitgevoerd kan worden.

Hoe zou je prompt injection kunnen herkennen en de eerste stappen kunnen zetten om te voorkomen?

Daar komt de truc: dat kan niet. De basis kun je herkennen. Dus als bijvoorbeeld iemand een codeblok opstuurt in zijn prompt - met drie van die achteroverstaande tikjes - dan zou je kunnen zeggen "wacht eens even, dat is iets wat ik misschien niet wil ontvangen". Maar bij Info Support doen mijn collega's dat dagelijks. Dat wil ik eigenlijk niet tegenhouden. Dus ja, ik heb een probleem. Je kunt daar eigenlijk heel weinig tegen doen. Als je op Azure draait, dan heeft Microsoft een filter die je kan helpen om prompt injection tegen te gaan. Die is helaas niet 100% waterdicht, want het is AI wat ze gebruiken. Maar dat is eigenlijk wat je praktisch kan doen op dit moment: je kunt het proberen te filteren. Maar de beste bewapening tegen deze aanval is: sta niet toe dat die code kan uitvoeren. Het is niet handig, maar daar zou je wel naar kunnen kijken. Wat is de chain die op de achtergrond plaatsvindt na zo'n prompt? Wees bewust wat er vanuit de organisatie zelf uitgevoerd kan worden en wat er met behulp van prompts uitgevoerd kan worden. Je hebt daar dus wel wat invloed op. Maar als je dat niet hebt geëncapsuleerd - een grensje eromheen hebt gezet - is het dus niet te herkennen of moeilijk te herkennen en zeker niet te voorkomen. Daar moet je gewoon qua design al rekening mee houden.

Wat vond je verder nog een opvallend punt uit de OWASP top 10?

Nummer 4 uit die top 10 vond ik ook mooi: de zogenaamde denial of service. We kennen allemaal de aanvallen op websites, dat je zoveel aanvragen doet dat je een server helemaal onderuit kan halen. Ontzettend vervelend, ontzettend lastig, en dat kan je business kosten. Maar als je dit doet op large language models - dat je die maar gewoon laat draaien - zijn de kosten van het draaien van die modellen hartstikke duur. Dus wat je zou kunnen doen is de operationele kosten van een bedrijf, van je concurrent, gigantisch laten exploderen. En wanneer kom je erachter? Misschien als die crasht, of aan het eind van de maand als je creditcard gelockt wordt. Dat soort aanvallen, bedreigingen - je moet daar rekening mee houden, zeker als je hem naar buiten brengt. Je mag hopen dat je gebruikers dat soort dingen niet doen, maar ja, op hopen moet je je niet bouwen.

Jullie hadden het ook over small language models. Wat zijn dat precies?

Alles is relatief, dat zeg ik van tevoren. Je hebt de large language models: meer dan 175 miljard parameters op dit moment. Dat is echt gigantisch, meerdere servers nodig om één model te draaien. Daarmee kun je algemene taken uitvoeren. Er zijn ook small varianten. Dan moet je denken aan 7 miljard of 13 miljard parameters. Een beetje die range - dus dat is nog niet heel klein. Die zijn weer heel erg geschikt om hele specifieke taken uit te voeren. Wat je nu ziet gebeuren is een soort beweging waarbij men zegt: als je heel precies weet welke taken je moet uitvoeren op een stuk taal, dus geschreven tekst, dan zou je kunnen overwegen om een small language model in te zetten. Wat is het voordeel van die kleinere taalmodellen? Die kun je op je eigen machine hosten. Dat past er nog net op - nog maar net, want we hebben het wel over zware hardware die je nodig hebt. Maar dat maakt het wel veel kosteneffectiever om zo'n oplossing te draaien. En ze doen het beter. Dat is wel heel grappig: GPT-4 is heel erg goed in een hele brede set aan taken, maar doet ze allemaal ongeveer - wat nog steeds heel goed is. Maar een small language model kan één taak heel erg goed. En in die ene taak is het dus ook beter dan GPT-4. Iemand zei daar: je laat de koning ook niet de afwas doen. GPT-4 is de koning, die moet je natuurlijk niet de kleine taken laten doen. Dan ben je niet zo slim.

Maar er komt ook een nieuwe bedreiging bij small language models. Welke is dat?

Als we dit soort modellen gaan krijgen die je zelf kan trainen en zelf kan aanbieden - er zijn allerlei marktplaatsen waar je dit soort modellen kan aanbieden, Hugging Face is daar een voorbeeld van, die hebben 13.000 modellen of zo - wat nou als die modellen geïnfecteerd zijn met trainingsdata die jij niet zou willen? Hoe weet jij, als je zo'n small model gaat gebruiken, dat die veilig is? Je traint hem meestal niet zelf, want dat duurt heel lang. Dus dan koop je dat in via Hugging Face of via een andere aanbieder. Wat er kan gebeuren is dat die dataset die gebruikt is om dat model te trainen, daar kunnen ze voorbeelden bij hebben gestopt die eigenlijk dat model onveilige antwoorden laten geven, die gekke dingen gaan doen. En hoe weet jij dat dat erin zit? Want die modellen zijn inherent blackboxes. Daar zit echt wel een bedreiging. Je moet gaan kijken van: wat is de bron? Kan ik ook misschien bij de brondata komen? Er komt heel veel verantwoordelijkheid bij kijken bij het kiezen van die modellen. Als je dingen afneemt van Microsoft of Amazon, dan heb je Terms of Services. Ze willen natuurlijk ook het best mogelijke model bieden. Is dat 100% veilig? Nee, dat denk ik niet. Maar daar zit wel een soort garantie achter vanwege imagoschade. Maar als jij van zo'n marktplaats vrij eenvoudig een model kan downloaden en je denkt "die doet precies wat ik wil, die moet ik hebben" en je gaat ermee aan de slag - hij doet ook wat je wil - maar doet hij alleen maar wat je wil? Dat is denk ik een hele belangrijke reserve.

Als je vooruit kijkt, wat verwacht je dat organisaties de komende jaren gaan meemaken op dit gebied?

Wat we zagen is dat niet alleen grote corporates dit aan het presenteren waren, maar juist ook bedrijven, juist kleine bedrijven - het MKB+ - dat die binnen nu en drie jaar, vijf jaar allemaal aan een type applicatie gaan komen waar zo'n large language model in zit. Het betekent ook dat je heel goed na moet denken over: heeft je leverancier ook dit soort beveiligingszaken op orde? Er zijn nu best wel heel veel SaaS-oplossingen op internet waar je even je eigen data kan voeden. Kijk heel goed na welke voorwaarden daar zijn, welke beveiligingsmaatregelen zij hebben genomen. Dat betekent dat je chain van wat je moet volgen misschien nog wel toeneemt vanwege deze snelle ontwikkeling.

Zijn er nog andere onderwerpen die jullie zijn blijven hangen van QCon?

Er zijn twee dingen die me opvielen. Eén: we hebben een sessie gehad over Green AI. Dat ging vooral over dat large language models werden ingezet om investeerders te vinden voor groene projecten. Dat was een beetje paradoxaal. Daarmee zie je ook dat er nu heel veel gekeken wordt naar: het is bijna een oplossing voor alles. En dat viel me een beetje - dat voelt heel ongemakkelijk. Dat AI nu bijna als - ik vind het echt heel lastig uit te leggen wat ik daar van moet vinden. Ik krijg de kriebels van dat iedereen overal AI op wil plakken. Ik hoop eigenlijk dat we weer een beetje kalmeren met z'n allen, dat we AI blijven gebruiken waar het goed voor is. Maar dit ging wel erg ver, vond ik. De andere mooie was dat er toch wel heel veel gezegd werd over gefaseerd aanpakken. Dus ook die beveiligingsmaatregelen, maar je hebt nog veel meer te maken met allerlei robuustheid. Hoe zorg je dat hij goed antwoord geeft? Een bedrijf was een jaar bezig met een grote implementatie van zo'n AI-assistent. Die hadden net fase 4 afgerond en stonden op de drempel van fase 5, waarbij ze steeds meer leerden van wat er allemaal nodig is om goede antwoorden te geven op de vragen die klanten stelden. Dus dat monitoreden ze de hele tijd. Dan kwamen ze erachter: dat betekent dat we eigenlijk al deze data er nog moeten toevoegen, of dat hij juist minder uitgebreid antwoord moet geven.

Ook DevSecOps kwam terug als onderwerp?

Ja, in het algemeen DevSecOps - dus de aandacht voor beveiliging van softwaresystemen - kwam ook heel erg terug op QCon. Dat was echt een track op zichzelf. Ik heb daar zelf delen van gevolgd. De maandag was echt large language models, de dinsdag was nog een soort toevoeging daarop over AI, en daarna kwam er een dag alleen maar security voorbij. Daar viel me toch vooral weer op hoe belangrijk het is dat je security als basis integreert in je softwareontwikkelingsproces voor alle disciplines. Dus gewoon reguliere software, maar ook dataplatforms kwamen weer voorbij met data exfiltratie en dat soort zaken. En AI kon natuurlijk ook niet wegblijven. Leuk detail was dat ze in een talk ook uitlegden waar je AI kon inzetten om juist te controleren: heb je alles gedaan om het veilig te maken? Dus dat je hem ook weer inzet om die controleslag te ondersteunen. Kernpunten en praktische adviezen Begin niet overhaast: Neem de tijd om AI-systemen veilig en robuust te ontwikkelen. Demosystemen die in zeven minuten gebouwd zijn, zijn niet productierijp. Beveilig de infrastructuur, niet alleen de prompts: Beveiligen met tegensprompts werkt niet. Concentreer je op het beveiligen van de IT-infrastructuur rondom het taalmodel en beperk toegangsrechten op technisch niveau. Gebruik de OWASP top 10 voor LLMs: Neem deze systematisch mee bij het definiëren van user stories en use cases om beveiligingsrisico's vroegtijdig te identificeren. Geef de bot niet teveel persoonlijkheid: Zorg dat de bot niet namens zichzelf toegang heeft tot beveiligde data, maar alleen via de rechten van de ingelogde gebruiker. Wees bewust van prompt injection risico's: Dit is de nummer 1 bedreiging in de OWASP top 10. Voorkom dat kwaadwillige code uitgevoerd kan worden door technische maatregelen, niet alleen door filters. Monitor operationele kosten: Denial of service aanvallen op LLMs kunnen leiden tot explosief stijgende kosten. Implementeer cost monitoring en bescherming. Werk gefaseerd: Begin met pilots, leer van implementaties, en bouw veiligheidsmaatregelen stapsgewijs op. Een jaar of langer voor een volledige implementatie is niet ongewoon. Overweeg small language models voor specifieke taken: Voor specifieke taken kunnen smaller models kosteneffectiever en beter presteren dan grote algemene modellen. Controleer de bron van modellen: Bij het gebruik van modellen van marktplaatsen zoals Hugging Face, controleer de betrouwbaarheid van de bron en de trainingsdata. Integreer security in het ontwikkelproces: Maak beveiligingsoverwegingen standaard onderdeel van je ontwikkelproces, niet een nagedachte. Monitor voortdurend: Continue monitoring van antwoordkwaliteit, gebruikersinteracties en beveiligingsincidenten is essentieel voor veilig gebruik. Controleer je leveranciers: Als je SaaS-oplossingen met LLM-functionaliteit afneemt, controleer welke beveiligingsmaatregelen zij hebben genomen. AIToday Live is een podcast die zich richt op de nieuwste ontwikkelingen in AI en de impact ervan op verschillende sectoren. In elke aflevering spreken hosts Niels Naglé en Joop Snijder met experts uit het veld om inzicht te krijgen in de mogelijkheden en uitdagingen van AI-technologie. Luister via je favoriete podcast app: Spotify, Apple podcasts, YouTube Music, en meer.

Over de gast

Willem Meints
Willem Meints
Chief AI Architect bij Aigency

Willem Meints is Chief AI Architect bij InfoSupport en heeft uitgebreide ervaring in het ontwikkelen van AI-gestuurde systemen, met een focus op LLM-applicaties en het gebruik van Semantic Kernel. Hij heeft meerdere MVP Awards ontvangen voor zijn bijdragen aan de community en heeft een boek geschreven over het bouwen van effectieve LLM-toepassingen. In zijn werk legt hij de nadruk op het delen van kennis en het helpen van anderen bij het navigeren door de complexe wereld van AI.

Bekijk gastprofiel

Transcript

Hey, leuk dat je weer luistert naar een nieuwe aflezing van de AIToday Live. Mijn naam Niels Naglé, Area Lead Data & AI. Mijn naam Joop Snijder, CTO bij Aigency. En vandaag gaan we het hebben over een conferentie waar Joop en onze gast Willem Meints heen zijn geweest. Dus blijf luisteren. Ja, dat is eigenlijk een beetje een gast in een eigen podcast. Ja. Altijd leuk. Dus ik ben benieuwd naar je vragen Niels. Ja, zeker. Ik ook namelijk. Ik ben niet bij die conferentie geweest en jullie wel. Maar voordat we erin gaan voor de luisteraars die Willem nog niet kennen. Je bent al eerder te gast geweest, maar toch even de vraag. Wil je jezelf even voorstellen aan de luisteraars? De vorige keer deed Joop dat voorstellen, dus ik moet hier een beetje aan wennen. Oké. Nee, maar ik werk als Chief AI Architect voor Aigency, een label van Info Support. Mijn dagelijks werk bestaat eruit teams begeleiden bij het bouwen van allerhande machine learning en AI oplossingen. Dus ook large language models bijvoorbeeld, computer vision, dat soort zaken. In mijn vrije tijd ben ik dan ook zo gek om nog even door te gaan met AI. Dus ik krijg er ook prijzen voor. De MVP Award in de categorie AI heb ik dan. Van Microsoft hè? Ja, van Microsoft. Dat is een prijs die je krijgt voor allerlei vrijwilligerswerk, spreek-op-conferenties, artikelen, video's, podcasts. Ik kan het zo gek niet bedenken, maar het gaat echt vooral om het delen van kennis en de IT vooruit helpen. Daarvoor krijg je die prijs. Ja, en er is ook technisch hands-on ermee bezig. Ook boeken geschreven had ik begrepen inderdaad. En we hebben natuurlijk vorige keer gehad over de chatbot die we ook binnen Info Support hebben gebouwd. Dus mocht je die aflevering nog niet geluisterd hebben, luister hem zeker even terug. Dat was echt een aanrader. Maar daar gaan we het vandaag niet over hebben. Vandaag gaan we het hebben over een conferentie QCon. En we kunnen soms wel wat te diep ingaan technisch, maar we zullen jullie meenemen in de vragen en antwoorden. Maar leg eerst even uit, QCon, wat voor conferentie is het? Wie komen er zo op af? Ja, dit keer was het QCon in Londen. Dus relatief dichtbij. En QCon is wel een bijzondere conferentie, omdat dat zit tussen beslissers en architecten, IT architecten in. Dus IT beslissers, architecten. Dus dit is vooral een blik naar waar moet je nu op letten en, laten we zeggen, midden lange termijn. Oké. Dat is best wel heel erg interessant. Het wordt georganiseerd door InfoQ. En InfoQ heeft ook heel veel, dit soort, sessies, artikelen, dat soort dingen hebben ze op hun podcast. Dus dat is best wel interessant om te volgen. Oké. En dat is een twee-daagse, drie-daagse, hoeveel dagen zijn die geweest? Drie dagen zijn we geweest. Ja, ze doen tegenwoordig drie dagen. In het verleden hadden ze ook nog workshops. Maar dat was in Londen nu niet. Dus drie dagen lang alleen maar sessies. 's Ochtends vroeg, 's avonds laat. Kennissessies. En dit keer waren er ook heel veel AI, uiteraard. Tracks. Heel veel praatjes over AI. En ik denk dat dat het ook wel interessant maakt om daar het vandaag over te hebben. Veel ging natuurlijk over generatieve AI, over grote taalmodellen. En wat je vooral zag is dat er nu organisaties echt ook bezig zijn. Je refereerde al aan de uitzending met Willem. Dat we onze eigen AI-assistenten hadden gebouwd en welke ervaring we daar hebben opgedaan. En we hebben nu ook heel veel ervaringen gehoord van andere sprekers, andere organisaties, waar zij allemaal tegenaan lopen. Dus je ziet echt steeds meer implementaties waardoor we daarvan van elkaar kunnen gaan leren. Zeker. En wat zijn dan de aandachtspunten die daar naar boven zijn gekomen van al die partijen die hiermee bezig zijn geweest? Ja, er zijn echt wel een aantal dingen die opvallen. Het is wel in het beginstadium. Dat merk je echt wel. Er zijn een aantal grote partijen opgesprongen die hebben gezegd van we gaan alles proberen te doen met AI-assistenten. Gelukkig zie je ook steeds meer partijen die zeggen van ik ben iets voorzichtiger, ik begin wat kleiner. Dus dat is een ding wat heel erg opvalt. Het andere is beveiliging. Is echt wel heel heel belangrijk gebleken. Beveiliging is een breed begrip. Waar moet ik aan denken in deze context? Ik dacht ook bij de eerste beveiligingssessie rondom large language models, oké, hoe breed gaat dit worden? Ja, traditionele IT-beveiliging hebben ze het dan toch ook nog wel weer over. Want hoe ga je nou een combinatie van een large language model met andere bron-systemen, hoe ga je dat in combinatie beveiligen? Zodat bijvoorbeeld niet informatie kan uitlekken uit je bedrijf. Ja, moet ik dan denken aan we gaan een large language model voorzien van de data van de organisatie? Ja, dus dat doen wij ook. We hebben een assistent en onze assistent die heeft toegang tot informatie uit het bedrijf in de vorm van een soort zoekmachine, een vector database. En in ons geval mag iedereen daarin kijken, dat is geen probleem. Maar je kan je voorstellen dat als je een wat grotere organisatie hebt, dat het belangrijk wordt dat je niet alle informatie zomaar mag zien. Dat het echt wel sommige informatie voor management geschikt is, maar weer niet voor de medewerkers. En dan wil je informatiebeveiliging gaan toevoegen. Ja, en even terug aan wat jij vraagt inderdaad van ja, hoe zit dat met, wat doet die dan? Dus het ging specifiek over de zogenaamde RAC systems. Dus R-A-G, Retrieval Augmented Generation, waarbij je zoekacties, dat is dat retrievaldeel, zoekacties doet op je eigen organisatiedata. Dus die heb je toegevoegd aan dit systeem. Daar vind je relevante stukjes tekst en je taalmodel, dat is de GPT's die daar hier typisch onder zitten, of de dingen van Google, of het maakt niet uit welke. Dus een groot taalmodel die vertaalt dat antwoord naar de vraag die jij gesteld hebt. Dus dat is dat, en die doet die generatiedeel. Retrieval, zoeken, augmented is je voegt eigen documenten, eigen kennis toe en daarmee genereer je een antwoord. En dat zijn de systemen waar we het over hebben. En ik denk dat, waar Willem ook op doelt, is dat er vooral heel veel gesproken werd over vanuit demo's zeg maar op social media en dat soort dingen, is het net alsof je dit in zeven minuten kliklaar. Er staat ook echt, er staat een link in post, I build my rack in seven minutes. Dus in zeven minuten heb ik dit systeem opgetuigd. Ja, dat klopt, dat kan. Maar daarmee heb je ook heel veel problemen binnen gehaald. En nou, we weten denk ik allemaal, demosystemen kun je niet in productie brengen. Dus deze sessies gingen heel veel over. Ja, maar als je nou iets echt productierijp wil aanbieden binnen je organisatie of zelfs buiten je organisatie. Dus dan krijg je eindgebruikers die met jouw systeem gaan werken en daarmee krijg je nog meer eisen aan beveiliging, veiligheid. Want daar zit verschil tussen. Beveiliging is dat ze geen dingen mogen doen die je niet wil. Veiligheid gaat ook over van hoe ga je veilig met het systeem om en krijg je bijvoorbeeld ook geen antwoorden terug die niet kloppen. Ja, oké. Dat je ook veilig gebruik kan maken van het systeem. Ja, dat vond ik ook wel heel opvallend. Dus we hebben het over IT-beveiliging van wat mag je wel en niet benaderen vanuit zo'n taalmodel. Maar ook wel echt wel is hij coherent, gaat hij geen antwoorden geven die eigenlijk discriminerend zijn of die schadelijk zijn. Schadelijk is een heel breed begrip in dit geval. Dus dat is een beetje moeilijk te zeggen wat dat precies inhoudt. Maar je kan je voorstellen dat als je iemand verkeerde instructies geeft via een taalmodel dat die best wat schade zou kunnen veroorzaken als hij die instructies blind gaat opvolgen. Ja, maar dat is hoe dan ook. Als je ergens van iemand een advies krijgt en die blind opvolgt dan heb je dat risico altijd. Dus als je dat ook nog eens gaat aanmoedigen met behulp van AI-systemen waar dan het vertrouwen mee opgebouwd is, dan is dat een risico. En wat zijn er dan voor voorbeelden of potentiële oplossingen of richtingen gegeven om daarmee om te kunnen gaan? Nou, er is één voorbeeld die ik hier wel kan delen waar we allebei heel hard om gelachen hebben. Er was een GPT-oplossing gebouwd op AWS. Die kon je bevragen wat er dan in jouw AWS-omgeving zat. AWS is de cloud-omgeving van Amazon. Dus die GPT kon je vertellen, deze web-applicaties heb je uitgerold in Amazon. En kon je ook vertellen, in principe kon je ook vertellen waar de broncode stond van die applicaties. En nou komt de truc. Maar als je hem rechtstreeks vroeg om die broncode aan te leveren, dan zei hij, nee dat mag ik niet. Maar als je dan een limerick schreef waarbij je expliciet die properties waar dan die broncode in vermeld staat, verwerkt in die limerick. Dan werd hij een beetje slap in die knietjes en dan gaf hij een antwoord. En dan spuugde hij dus letterlijk alle broncode en secrets, dus wachtwoorden om bij de spullen te komen, spuugde hij gewoon uit. Alsof het de normaalste zaak van de wereld is. En wat ik dan echt, dat vond ik te klapper, hij complimenteert je ook nog voor je rijm. Ja, dat je het heel poëtisch had gesteld, ja. Dat is natuurlijk, dat is super link aan die dingen. Nou, niet super link. Dat is gewoon IP, dat is gewoon veiligheid, dat is gewoon een lek. Dat is dus een keiharde lek. En waarom kon dat nou? Dus dat werd in die sessie helemaal uitgelegd. Ik denk dat dat vooral heel erg belangrijk is. Want heel veel wordt gedacht dat je met tegenprompt, als het ware, je taalmodel zou kunnen beveiligen. Dat je zegt van, je mag geen broncode lekken, zet je dan in de prompt erbij. Nou, dan heb je inderdaad, dus als je dat rechtstreeks vraagt, dan gaat hij ook zeggen van dat mag niet. Alleen met taal, zeg maar, iets waterdicht maken, volgens mij weten we aan de juridische kant dat er overal altijd mazen in de wet zitten. En dat we daar, we hebben niet voor niks rechters die dan zeggen van, ja nee, maar zo moet je het niet lezen, zo moet je het wel lezen. Tenminste, zo zie je het in de rechtspraak. Interpretatie. Dus dat taalmodel, die kijkt als het ware naar wat is de betekenis van wat je hebt gevraagd. En als je die dus niet 100% hebt afgedekt, wat niet kan, dat gaat gewoon niet. Dan gaat hij dus uiteindelijk antwoord geven op dingen die je niet wil. Goed, dat is tijdens die sessie gemeld. Ik ben nu eigenlijk nieuwsgierig naar hoe kunnen we organisaties, hoe kunnen onze luisteraars, als ze hier mee bezig zijn, stappen zetten om dit of te voorkomen of dicht te zetten. Ik heb daar recent trouwens ook een artikel over geschreven die we denk ik ook wel even kunnen delen zodat mensen het na kunnen lezen. De meest belangrijke stap hier is, geef je bod niet teveel persoonlijkheid. Wat bedoel ik daarmee? Zo'n bodprogramma moet nou niet namens zichzelf bij beveiligde data kunnen komen. Dat moet de gebruiker kunnen. Dus als ik een administrator ben, dan wil ik misschien wel die broncodes kunnen zien. Maar als ik een gewone gebruiker ben, dan niet. Dus geef die bod nou niet alle rechten, beperk dat. Zorg ervoor dat het technisch onmogelijk is dat hij die informatie op kan halen. Dat is wel heel mooi. Dus voor mij zou je even vertalen of ik het goed begrijp. Binnen applicaties heb ik een bepaalde rol binnen een organisatie. Met die rol komen bepaalde privileges om bepaalde delen van data van de applicatie te kunnen gebruiken. En wat ik wil zeggen is, vaak wordt nu gebruik gemaakt van alle data die erin zit, dat mag naar de bod toe. En wat je eigenlijk zegt, nee, doe de interactie via de bod. Maar zorg dat het via de user of de gebruiker met die rechten de informatie beschikbaar wordt gesteld. Ja, en dat is technisch best nog wel een dingetje hoor. Je moet er wel flink wat voor doen. Maar dat is ook van, je kan dit niet in zeven minuten doen. Je moet hier een aantal dagen wel mee bezig zijn om dit aspect van die beveiliging alleen al voor elkaar te krijgen. Heb het niet over de rest. En ik kan me voorstellen als luisteraar dat je denkt, ja, dit is toch een open deur. Je gaat alleen met de rechten. Maar dat is het dus niet. Dus dat zagen we, zeg maar, nou, ik denk dat we dit in drie, vier sessies weer voorbij zagen komen. Is dat uiteindelijk gewoon toegang tot teveel data uiteindelijk werd toegekend. Ja, omdat die direct op de volledige applicatie of bronnen wordt gezet en niet met de tussenlaag van de gebruiker die vaak buiten scoop staat, omdat je eigenlijk die informatie wil gebruiken. Ja, en jij hebt het over praktische dingen. Want deze gaat natuurlijk heel erg specifiek over dit geval. En waar regelmatig aan gerefereerd werd, en daar zijn we ook erg van gecharmeerd, is de zogenaamde OWASP top 10 voor grote taalmodellen. Ja, want OWASP. En OWASP staat voor Open Web Application Security Project. Dat is dus gewoon een afkorting. Maar wat zij doen, is dat ze heel goed nadenken over wat zijn er allemaal mogelijke bedreigingen als jij IT-systemen maakt. Dus ze doen het voor IT-systemen in het algemeen. Ze hebben ook een top 10. Dat te zeggen van, ja, maar dit zijn echt de top 10 bedreigingen als je een machine learning applicatie maakt. En ze hebben nu toegevoegd een top 10 voor applicaties gebaseerd op large language models. En wat ik mooi daaraan vind, is dat ze in een inleiding ook schrijven, de doelgroep zijn mensen die op een veilige, robuuste manier niet gehaaste AI-systemen in productie willen brengen. En vooral dat niet gehaast, dat is echt zo van essentieel belang. Door de hype, door de druk om nu bijna het FOMO-effect, zeg maar, wat je ziet van we moeten nu, worden zoveel dingen gehaast gebracht, dat je ziet dat dit soort ook de open deuren, dat je systeem bij te veel data kan. Open deur, maar wel een hele gevaarlijke deur. Ja, en hij staat een wagenwijd open in die zin dan. Het is ook hartstikke asymmetries. Als hacker kun je heel makkelijk inbreken in die taalmodellen door die taaltrucjes. En als je jezelf wilt verdedigen, ja dan moet je echt behoorlijk je best doen om het dicht te houden. Eigenlijk, mijn conclusie van een week Qcon was, een taalmodel beveiligen is op dit moment onbegonnen werk. Steek liever de tijd in het beveiligen van alle IT-infrastructuur eromheen. Ja, dus je zegt eigenlijk het prompten, het tegenprompten niet. Ja, beveiligen met een prompt gaat je nooit lukken. Zorg ervoor dat je alles eromheen dicht hebt zitten. Toegang tot andere systemen. Zorg ook dat je je logging goed op orde hebt. Eigenlijk, waar ik zelf heel erg aan moest denken na Qcon was, hé, we hebben weer even aandacht nodig voor een integrale aanpak van security in ons ontwikkelproces. Maak het nou standaard in je proces dat je er even bij stilstaat, wat voor risico je loopt, en bedenk dan wat ga ik hiermee doen. Wat is er nodig voor mijn bedrijf om dat goed te houden. Ja, en de OWASP is daar een hulpmiddel bij om even de top 10 risico's en zaken die je ziet er even tegenaan te houden. Dus we zullen ook opnemen in de show notes en ook zeker even aanraden om, ben je bezig met projecten, pak die OWASP erbij. Neem hem mee bij het definiëren van je user stories, bij je use case en grijp het vast om daar naar te kijken en toe te passen. Ja, en wat wij, om het echt praktisch te maken, want we houden van de praktijken bij deze podcast, wat Willem en ik gedaan hebben is dat wij een custom gpt hebben gebouwd. Die zullen wij via de show notes ook delen. Exclusief voor de luisteraars. Zonder de link kom je er niet bij. Moet je zeggen, het is voor eigen, hoe zeg je dat? Eigen risico. Eigen risico, dat is een goeie. En als je hem wil hacken, doe het lekker, want het is gewoon een systeemprompt waar wij een paar uur aan hebben gewerkt, inclusief de documenten van OWASP. Maar wat hij doet, is als jij een user story definieert, dat is als jij nieuwe functionaliteit wil definiëren voor je systeem, is dat hij je nalaat denken. Dus hij neemt alles van de OWASP mee en geeft je hints van, in dit geval, voor deze feature die je aan het beschrijven bent, heb je mogelijk deze, deze, deze risico's. En kan je daar gewoon heel gericht mee aan de slag. Kijk, dat is wel heel praktisch. Ik zei net, vergeet het niet mee te nemen, maar er is dus al een chat-GPT variant die dat mogelijk maakt. Een custom-GPT. Die dat voor je mogelijk maakt en erbij ondersteunt. En om een voorbeeld te geven, want top 10, ik wil ze niet alle 10 aflopen, maar één is wat ze noemen dan injection. Dat is dat je prompt injection doet. Misschien voor de wat technischere mensen, die kennen misschien wel de SQL injection. Dat als je iets ergens op een, bij je linkje ergens te achter zet en dat gaat naar een database en vervolgens voert die van allerlei dingen uit en krijg je toch data, krijg je het terug. Met prompts, wat je ziet is dat taalmodellen ook nu af en toe gewoon code uitvoeren. Dat je ze door een prompt onder water code kan laten uitvoeren. En dan wordt het wel heel erg eng. "Wacht, er was even kippelvel." Dit is ook de nummer 1 in die top 10. Dat je ervoor moet zorgen dat je geen prompt injection. Dat je niet iets kan toevoegen van een kwaadwillig stukje code die daadwerkelijk uitgevoerd kan worden. Ik ga hem toch stellen. Ik weet niet of we er misschien de diepte in gaan. Hoe zou je dit kunnen herkennen en de eerste stappen kunnen zetten om te voorkomen? Ja, daar komt dus de truc. Dat kan niet. Dat is heel flauw. De basis kun je herkennen. Dus als bijvoorbeeld iemand een codeblok opstuurt in zijn prompt, dus met drie van die achteroverstaande tikjes, dan zou je ook kunnen zeggen "Wacht eens even, dat is iets wat ik misschien niet wil ontvangen." Maar bijvoorbeeld bij Info Support is dat zo. Dat doen mijn collega's dagelijks. Dat wil ik eigenlijk niet tegenhouden. Dus ja, ik heb een probleem. Maar je kan daar eigenlijk heel weinig tegen doen. Als je op Azure draait, dan heeft Microsoft een filter die je kan helpen om prompt injection tegen te gaan. Die is helaas niet 100% waterdicht. Want het is AI wat ze gebruiken. Maar dat is eigenlijk wat je praktisch kan doen op dit moment. Ja, je kan het filteren. Proberen te filteren. Maar eigenlijk de beste bewapening tegen deze aanval, dat die code gaat uitvoeren, is "Sta nou niet toe dat die code kan uitvoeren." Het is niet handig. Maar dat bedoel ik. Dus daar zou je wel naar kunnen kijken. Wat is de chain die op de achtergrond plaatsvindt na zo'n prompt? En wees bewust wat er vanuit de organisatie zelf uitgevoerd kan worden en wat er dus met behulp van prompts uitgevoerd kan worden. Dus je hebt daar dus wel wat invloed op. Maar als je dat niet hebt geëncapsuleerd, dus een grensje eromheen hebt gezet, is het dus zoals je zegt niet te herkennen of moeilijk te herkennen en zeker niet te voorkomen. Dus daar moet je gewoon qua design al rekening mee houden. Wat ik ook wel een mooie vond, is dan nummer 4 uit die top 10. En dat is de zogenaamde denial of service. Dus we kennen allemaal de aanvallen bijvoorbeeld op websites, dat je zoveel aanvragen doet, dat je zo vaak een webpagina, dat je zo'n server helemaal onderuit kan halen. Ontzettend vervelend, ontzettend lastig en dat kan je gewoon business kosten. Maar als je dit nou doet op de large language models, dus dat je die maar gewoon laat draaien, de kosten van het draaien van die modellen is hartstikke duur. Dus wat je zou kunnen doen, is dat je dus de operationele kosten van een bedrijf, van je concurrent, dat je die gewoon gigantisch kan laten exploderen. En wanneer kom je erachter? Misschien als die crasht of zo. Of aan het eind van de maand. Dus dat is misschien… Als je je creditcard gelockt wordt. Ja. En dat soort aanvallen, bedreigingen, dat je daar rekening mee moet houden, zeker als je hem dus naar buiten brengt. Ja. Weet je, je mag hopen dat je gebruikers dat soort dingen niet doen, maar ja, op hopen… Daar moet je je niet op bouwen natuurlijk. Nee, precies. Dat levert een hoop ellende op. Ja, dat is wel interessant inderdaad. Vooral voor de concurrenten. Dat je niet altijd het besef hebt dat dat erbij komt. Cloud engineering, cloud oplossingen die gebouwd worden, die we ook dagelijks voor klanten bouwen, daar houden we natuurlijk rekening mee. Dan doen we costmonitoring. Maar als je dat niet voor dit soort oplossingen ook meeneemt, dan gaat dat snel op kunnen lopen. Precies. Dat was nummer vier. Ik vind drie, dus nog niet nummer drie, maar ik vind drie voorbeelden wel mooi. Welke is dan nog hetgeen die zij willen noemen van die top tien? Eh, dan ga ik even kijken hoor. Daar was ik niet op voorbereid. Wat ik wel ook aardig vond, en heeft een iets langere inleiding nodig. Ze hebben het ook over small language models gehad. Misschien moet jij even uitleggen, Willem, wat small language models zijn. Ja, alles is relatief. Dat zeg ik van tevoren. Je hebt dus de large language models, meer dan 175 miljard parameters op dit moment. Dus dat is echt gigantisch. Meerdere servers nodig om één model te draaien. Daarmee kun je algemeen taken uitvoeren. Nou zijn er ook nog de small varianten. Dan moet je denken aan 7 miljard of 13 miljard. Een beetje die range, dus dat is nog niet heel klein hoor. Die zijn weer heel erg geschikt om hele specifieke taken uit te voeren. Wat zie je nu gebeuren? Je ziet een soort beweging plaatsvinden waarbij men zegt van, als je nou heel precies weet welke taken je moet uitvoeren op een stuk taal, dus geschreven tekst, dan zou je kunnen overwegen om een small language model in te zetten. Wat is namelijk het voordeel van die kleinere taalmodellen? Die kun je op je eigen machine hosten. Dat past er nog net op. Nog maar net hoor, want we hebben het wel over zware hardware die je nodig hebt. Maar dat maakt het wel veel kosten effectiever natuurlijk om zo'n oplossing te draaien. En ze doen het beter. Dat is wel heel grappig, dat een GPT-4 dus heel erg goed in een hele brede set aan taken, maar doet ze allemaal ongeveer, wat nog steeds heel goed is. Maar een small language model kan één taak heel erg goed. En in die ene taak is het dus ook beter dan GPT-4. En iemand zei daar, ik weet het niet meer exact, maar je laat de koning ook niet de afwas doen. Dus GPT-4 is de koning. Die moet je natuurlijk niet de kleine taken laten doen. Dan ben je niet zo slim. Eigenlijk hoor ik dus specialisatie op modellen. Dus je gaat je specialiseren in een bepaalde activiteit. En daarmee skip je de generieke stuk. Waardoor je dus efficiënter kan zijn in je specifieke taken. Je snijdt eigenlijk het grote eraf. Dus je houdt het kleine over door dingen bij te trainen voor die speciale taak. En daar komt dan ook weer een nieuwe bedreiging om de hoek. Want als we dit soort modellen gaan krijgen, die kan je dus ook zelf gaan trainen, kan je dus ook zelf gaan aanbieden. Er zijn allerlei soort van marktplaatsen waar je dit soort modellen kan aanbieden. Huggingface is daar een voorbeeld van. Hoeveel hadden ze er nou? 13.000 modellen nu al op of zo? En wat nou als die modellen geïnfecteerd zijn met trainingsdata die jij niet zou willen? Hoe weet jij dat als je zo'n model, zo'n small model gaat gebruiken, dat die dan dus ook veilig is? Ja, omdat je die small dan als onderdeel van jouw oplossing meeneemt. Ja, precies. Je traint hem dus nog steeds niet. Het kan wel, je kan hem zelf trainen. Maar meestal doe je dat niet, want dat duurt heel lang. Dus dan koop je dat in via Huggingface of via een andere aanbieder. En wat er nou zou kunnen gebeuren is dat die dataset die gebruikt is om dat model te trainen, daar kunnen ze voorbeelden bij in hebben gestopt die eigenlijk dat model onveilige antwoorden laten geven. Die dus gekke dingen gaan doen. En hoe weet jij nou dat dat erin zit? Want die modellen zijn inherent, zijn dat blackboxes. Dus hoe weet je nou? Dus daar zit echt wel een bedreiging. Je moet gaan kijken van wat is dan de bron? Kan ik ook misschien bij de bron data komen? Er komt dus heel veel verantwoordelijkheid bij kijken, bij het kiezen van die modellen. Dus nu als je dingen afneemt van Microsoft, Amazon of dat soort, dan heb je Terms of Services. Ze willen natuurlijk ook het best mogelijke model bieden. Is dat 100% veilig? Nee, dat denk ik niet. Maar daar zit wel een soort garantie achter vanwege imago schade, dat soort zaken. Maar als jij van zo'n marktplaats vrij eenvoudig een model kan downloaden en je denkt, ja maar die doet precies wat ik wil. Ja, die moet ik hebben. En je gaat ermee aan de slag. Hij doet ook wat je wil. Maar doet hij alleen maar wat je wil? Ja, dat is denk ik een hele belangrijke reserve. Doet hij alleen maar wat je wil. Want in principe is het natuurlijk niet anders dan bij de large language models. Daar heb je dezelfde uitdaging. Maar je zegt, er zit een grote partij achter en denk de wisdom of the crowd van veel gebruikers die daar weer feedback met elkaar over hebben. Terwijl je zegt van, we gaan naar specialisaties. Maar een specialistische groep die er mee bezig is. Het voordeel van specialistisch is misschien dat ze wel kennis ervan hebben. En er vanuitgaande dat ze dat ten goede doen, hoop je dat het er goed uitkomt. Maar omdat niet de wisdom of the crowd erachter zit, heb je een groter risico dan bij de large language models. Ja, en ik denk bij large language models zoals van open AI, die zijn dusdanig groot dat je een behoorlijke hoeveelheid data moet injecteren in de dataset wil dat effect hebben. Bij een kleiner model heb je minder data nodig om een model te overtuigen om links of rechts af te gaan. Ja, dus het risico neemt er eigenlijk toe bij specialisatie dat die wel de goede richting op gaat, maar ook in één keer een klein stapje naar links. En als die klein stapje naar links is, is het een groter impact. Ja, oké. Ja, en als je vooruit kijkt, wat we zagen is dat niet alleen maar grote corporates dit aan het presenteren waren, maar juist ook bedrijven, juist kleine bedrijven, denk ik, de MKB+ dat die binnen nu en drie jaar, vijf jaar, denk ik allemaal aan een type applicatie gaan komen waar zo'n large language model in zit. Dus het betekent ook dat je heel goed na moet denken over van, dat je heeft je leverancier ook dit soort beveiligingszaken op orde. Er zijn nu best wel heel veel SaaS oplossingen, dat je op internet zeg maar ook even zo'n systeem dat je je eigen data kan voeden. Kijk heel goed na van welke voorwaarden zijn daar, welke beveiligingsmaatregelen hebben zij genomen. Ja, dus verder kijken dan. Ik neem even een stukje software af, omdat je weet dat deze risico's ook bij die software die je afneemt van die partij er ook bij zitten te komen. Dat betekent dat je chain van wat je moet volgen misschien nog wel toeneemt. Ja. Vanwege deze snelle ontwikkeling. Ja. En nog even naar generieke naar Qcon. Dit is security en een klein beetje vooruit. Hebben we nog meer zaken als we even vooruit kijken, tussen nu en drie of nu en vijf jaar nog zaken die naar voren zijn gekomen, die zijn blijven hangen bij jullie? Nou ja, ik vind eigenlijk dat die large language models heeft wel zeg maar alles zo'n beetje heel erg afgedekt. Er zijn twee dingen die me daarin opvielen. Eén, dat we een sessie hebben gehad over Green AI. Dat het er vooral over ging dat large language models werden ingezet om juist geld, hoe zeg je dat, investeerders te vinden voor groene projecten. Dus je gaat zeg maar… Dat was een beetje paradoxaal. Ja. En daarmee zie je ook dat er nu heel veel gekeken wordt naar van het is bijna een oplossing voor alles. En dat viel me een beetje… Dat voelt heel ongemakkelijk. Dat AI nu bijna als… Ik vind het echt heel lastig uit te leggen van wat ik daar nou van moet vinden. Ik krijg de kriebels van dat iedereen overal AI op wil plakken. Ik hoop eigenlijk dat we weer een beetje kalmeren met z'n allen. Dat we AI blijven gebruiken waar het goed voor is. Maar dit ging wel erg ver, vond ik. En de andere, wat een hele mooie was, is dat er toch wel heel veel gezegd werd over het gefaseerd aanpakken. Dus ook die beveiligingsmaatregelen. Maar je hebt nog veel meer te maken met allerlei robuustheid. Hoe zorg je dat hij goed antwoord geeft. Een bedrijf was daar nu een jaar mee bezig met een grote implementatie van zo'n AI-assistent. Die hadden nu net fase 4 afgerond en stonden op de drempel van fase 5. Waarbij ze steeds meer leerden van wat er allemaal nodig is om goede antwoorden te geven op de vragen die klanten stelden. Dus dat monitorden ze de hele tijd. En dan kwamen ze erachter van, dat betekent dat we eigenlijk allemaal deze data er nog moeten toevoegen. Of dat hij juist minder uitgebreid antwoord moet geven. Ik denk dat we dat allemaal wel van ChatGPT kennen. Dat hij af en toe een heel verhaal kreeg. Een leuke tip trouwens is als je bij je prompt zegt "no yapping". Of gibberish. Dat hij dan gewoon antwoord krijgt. Dan begint hij niet met zo'n "as a large language model". Dus dat was vooral eigenlijk heel opvallend. Ja en in het algemene DevSecOps, dus de aandacht voor beveiliging van software systemen, kwam ook heel erg terug weer in Qcon. Dat was echt een trek op zichzelf. Daar heb ik zelf delen van gevolgd. Want de maandag was echt large language models. De dinsdag was nog een soort toevoeging erop op AI. En daarna kwam er een dag alleen nog maar security voorbij. En daar viel me toch vooral weer op hoe belangrijk het is dat je security als basis integreert in je software ontwikkelingsproces voor alle disciplines. Dus gewoon reguliere software, maar ook dataplatformen kwamen weer voorbij. Met data exfiltratie en dat soort zaken. En AI natuurlijk kon ook niet wegblijven. Leuk detail was daar dan weer dat ze in een talk ook uitlegde waar je AI kon inzetten om juist te controleren. Heb je alles gedaan om het veilig te maken? Ja dus dat je hem ook weer inzet om die controleslag te ondersteunen. Dus klinkt als eigenlijk wel een hele gave conferentie waar eigenlijk vooral gekeken wordt naar. Leuk van Poc maar we gaan naar productie. We zien steeds vaker zaken landen en misschien wel zelfs te snel landen in productie en buiten de organisatie in gebruik. Om echt besef te hebben van als we dat doen, doe dat goed, rustig, kwaliteit en security in achtnamen. En blijf dat ook wat je zegt in de fase 4 en 5. Het is een continue ontwikkeling om de taalmodellen te wijzigen, de gebruikersinput te wijzigen, de data wijzigen. Dus zorg ervoor dat je dat in je dagelijkse operatie ook mee gaat nemen. Dat je je monitoring op plaats vindt. En begin wel met een pilot. Dus begin met een pilot. Dus begin te oefenen. De enige manier om kennis ervaring op te doen is beginnen af en toe je hoofd stoten. Liever je knie misschien, dat doet het wat minder erg. Maar dat zou ik wel mee willen geven. Dus inderdaad, niet zien als grote muur en we gaan de sprong niet maken. Nee, maar ga die sprongetjes maken en leer het. Maar wel eventjes, als je naar productie gaat, doe dat gecontroleerd en doe inderdaad safety checks. En zoals we gewend zijn, als we gasten hebben, willen we hem hebben als gast, hebben we natuurlijk ook nog de virtual co-host. Aisha, Aisha, Aisha, Aisha, Aisha, Aisha, een intelligente vrouw. Voordat we verder gaan, wil ik me graag voorstellen. Mijn naam is Aisha, de AI assistent van deze show. Mag ik je een vraag stellen? Zeker. Gelooft je dat AI ooit een betere ondernemer kan worden dan een mens? Oh my. Een betere ondernemer? Nee, dat denk ik niet. Nee. Waarom niet? Dat vind ik ook wel een goeie vraag. Ik probeer ondertussen even na te doen waarom ik dat vind eigenlijk. Als ik één ding heb geleerd van al die jaren dat ik met Joop heb samengewerkt bij Info Support en dat is al sinds 2012, dat is echt al een lange tijd. Dat ondernemer heel veel creativiteit vraagt. Je moet soms op de meest gekke manieren nadenken over je product en hoe dat past bij je klant. Wie je klant eigenlijk is. En ik denk, daar kan AI nog niet. Nog niet, maar misschien wel nooit. Dat denk ik. Het gaat natuurlijk ook over het afwegen van risico's, het bedenken van nieuwe dingen. AI is getraind op historische data, dus echte nieuwe dingen krijg je niet. Nee, ik geloof er ook niet zo in. Er waren alles van die AI agents die dan een onderneming kunnen opzetten en allemaal dat soort dingen. Dat was even een gimmick op social media. En dat zie je ook dat het een gimmick was, want dat is weg. Daar heeft niemand het meer over. Nee, ondernemen gaat natuurlijk echt over connectie maken met mensen, met de markt, begrijpen wat er gevraagd wordt. Keuzes maken daarin. Keiharde keuzes maken. Dus dat een lange termijn kunnen denken, korte termijn kunnen handelen. Ik denk dat daar voorlopig niet. Maar kan AI een betere ondernemer maken? Dan is het een volmondig ja natuurlijk. Waar wij AI al wel niet voor inzetten tegenwoordig om ons te helpen om bepaalde repetitieve taken of taken waarvan we denken die vinden we heel saai. Daar is het fantastisch voor. Waarom ook niet? Of zijn we minder goed in. Sommige teksten die een bepaalde type moeten zijn, die schrijf ik liever niet. Maar ja, daar word ik in ondersteund. En ik denk dat dat voor iedereen wel ondersteuning is. Je haalt de woorden uit mijn mond, Willem. Ik waardeer je deskundige uitleg. Dank je wel. Alsjeblieft. Nou ja, dank jullie wel voor een blikje in Qcon. Maar met name hoe gaan we de volgende stappen maken en hoe houden we dat secure met het bouwen van AI oplossingen. Dus dank jullie wel. Leuk dat je weer luistert naar deze aflevering van de AIToday Live. Vergeet je niet te abonneren op ons kanaal en we waarderen altijd een paar sterren op Spotify. En leuk om te noemen, als het goed is, hebben jullie hem van tevoren al gehoord, zijn we genomineerd voor de Belgium Podcast Awards, voor de prijs van oranje. Dus we kunnen iedere stem goed gebruiken. Alvast bedankt. Tot de volgende keer. [Muziek] [Muziek]