S06E39 - Kunnen AI-assistenten echt de HR wereld veranderen?

In deze aflevering van AIToday Live is Bart Slaets te gast, oprichter van Paybix. Hij deelt inzichten over het gebruik van AI binnen zijn start-up, specifiek gericht op het vereenvoudigen van internationale payroll processen.

Bart vertelt over de ontwikkeling van een AI-assistent die bedrijven helpt met lokale wetgeving en payrollvraagstukken in verschillende landen. Luister naar de uitdagingen, oplossingen en de toekomstvisie van AI in de HR-sector.

Links

• Website: Paybix, platform voor internationale payroll oplossingen (https://www.paybix.eu)
• Website: Info Support, IT-diensten en -oplossingen (https://www.infosupport.com)

Aigency
Aigency ontwerpt en ontwikkelt waardevolle, robuuste en betrouwbare Machine Learning-modellen.

Info Support
Info Support is de specialist in maatwerk software en leidend in kunstmatige intelligentie (AI).

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Schrijf je in voor onze nieuwsbrief en ontvang exclusieve toegang tot nieuws, blik achter de schermen en meer!

Transcript

1
00:00:00,000 --> 00:00:07,040
Hoi, leuk dat je weer luistert naar een nieuwe aflevering van de AIToday Live. Mijn naam is

2
00:00:07,040 --> 00:00:11,800
Joop Snijder, CTO bij Aigency. Mijn naam Niels Naglé, Area Lead, Data & AI bij Info Support.

3
00:00:11,800 --> 00:00:19,040
En vandaag een gast van over de grens, Bart Slaets. Bart, welkom in deze aflevering.

4
00:00:19,040 --> 00:00:22,280
Voordat we gaan starten, zou je jezelf willen voorstellen aan de luisteraars?

5
00:00:22,280 --> 00:00:28,360
Oké, ik ben Bart Slaets. Ik ben 50 jaar geworden, dus dat is dan heel erg.

6
00:00:28,360 --> 00:00:28,960
Gefeliciteerd.

7
00:00:28,960 --> 00:00:35,400
Dank je wel, nog maar pas. Ik heb 25 jaar bij SD Worxs gewerkt, dus een grote

8
00:00:35,400 --> 00:00:40,640
sociaal secretariat zoals we dat in België noemen. Waarvan de laatste acht jaar bij

9
00:00:40,640 --> 00:00:45,720
ProTime en sinds twee jaar mijn eigen start-up begonnen, Paybix, samen met twee co-founders.

10
00:00:45,720 --> 00:00:47,640
Ja, en wat doet Paybix?

11
00:00:47,640 --> 00:00:53,360
Paybix is een bedrijf dat zorgt dat bedrijven die internationaal gaan,

12
00:00:53,360 --> 00:00:57,640
dus bedrijven die niet zo groot zijn dat ze SAP kunnen aankopen,

13
00:00:57,640 --> 00:01:01,960
maar dat ze eigenlijk hun payroll in al die landen moeten gaan regelen.

14
00:01:01,960 --> 00:01:07,960
Daar zorgen wij dat we een platform hebben gemaakt dat boven die lokale payroll engines

15
00:01:07,960 --> 00:01:12,920
ligt, zodat ze toch centrale invoer en centrale rapportering kunnen doen over hun hele populatie,

16
00:01:12,920 --> 00:01:15,120
ja, wereldwijd eigenlijk.

17
00:01:15,120 --> 00:01:19,880
Ja, precies. En jullie zijn gestart met een eigen AI-assistent, hè?

18
00:01:19,880 --> 00:01:21,040
Ja, onlangs.

19
00:01:21,040 --> 00:01:21,480
Klopt.

20
00:01:21,480 --> 00:01:27,360
En daar gaan we het vandaag over hebben. Hoe zijn jullie erop gekomen om hiermee te beginnen?

21
00:01:27,360 --> 00:01:34,320
Ja, wel, het is wel een verhaal. Het is op zich zo dat je moet je voorstellen,

22
00:01:34,320 --> 00:01:40,080
die bedrijven, onze klanten dus, dat zijn de kleinere bedrijven die dus multi-country

23
00:01:40,080 --> 00:01:44,200
payroll moeten runnen, wat op zich niet evident is, want je hebt in elk land een

24
00:01:44,200 --> 00:01:50,040
andere sociale wetgeving en andere regels. En wat zo'n bedrijf dan typisch gaat doen,

25
00:01:50,040 --> 00:01:54,080
is, een voorbeeld, we hebben een bedrijf en die zitten in zes landen met ongeveer

26
00:01:54,080 --> 00:01:58,680
80 medewerkers en er is één dame in Brussel die die zes payrolls moet doen.

27
00:01:58,680 --> 00:01:59,200
Oh ja.

28
00:01:59,200 --> 00:02:05,080
En ze deed dat dus tot hiertoe, of voor ons, gewoon, het zei, met het lokale payrollpakket,

29
00:02:05,080 --> 00:02:10,240
ze ging dat gewoon invoeren in Spanje, in Polen, in Tsjechië, ook in België en in Nederland.

30
00:02:10,240 --> 00:02:16,480
Maar, ja, op zich is het dus heel moeilijk om dan al die lokale regels te kennen.

31
00:02:16,480 --> 00:02:20,960
Sommigen deed ze zelfs gewoon via mail en dan moest ze gewoon doorsturen,

32
00:02:20,960 --> 00:02:25,840
die verdient zoveel, die heeft vakantie gehad enzo, om eigenlijk de impact op de payroll te

33
00:02:25,840 --> 00:02:33,400
gaan regelen. En dan, ja, dus dat was het ene, het fenomeen, dat mensen eigenlijk dan de sociale

34
00:02:33,400 --> 00:02:38,480
regels lokaal moeten kennen en er moeten we voor opzoeken. En langs de andere kant,

35
00:02:38,480 --> 00:02:45,080
ja, kwam ik dus in contact met Tim Mahy, Tim Mahy van Info Support, dus dat is iemand die ik al heel

36
00:02:45,080 --> 00:02:49,040
lang ken en een goeie relatie mee heb. En wij spreken elke drie, vier maanden nog eens af,

37
00:02:49,040 --> 00:02:55,640
sinds ik in mijn start-up zit. En dus die triggerde mij eigenlijk wel van, ja, zeg,

38
00:02:55,640 --> 00:03:00,440
en AI, en heb je daar al mee bezig geweest? Ik zeg, ja, AI op zich, ja, ik ben IT'er,

39
00:03:00,440 --> 00:03:04,240
dus het interesseert me sowieso wel en ik ben er wel mee bezig, maar nu ook niet helemaal in de

40
00:03:04,240 --> 00:03:08,280
diepte. Het komt er vooral op neer dat ik de businessmensen op mijn voeten op de grond moet

41
00:03:08,280 --> 00:03:12,640
zetten over wat AI kan zijn, want ze denken dat het alles zal overnemen en alles zal kunnen,

42
00:03:12,640 --> 00:03:19,600
terwijl het op zich een algoritme is. En dus hij zei, ja, maar ja, kan je dat niet inzetten voor

43
00:03:19,600 --> 00:03:25,720
bijvoorbeeld die kennisopbouw te gaan doen bij jullie klanten? En zo zijn we dan beginnen nadenken

44
00:03:25,720 --> 00:03:34,520
en hebben we dus twee POCs gedefinieerd, die we dan samen hebben uitgevoerd ook. En de eerste POC

45
00:03:34,520 --> 00:03:42,160
ging er eigenlijk over dat de klanten hun documenten, dus bijvoorbeeld lokale policies,

46
00:03:42,160 --> 00:03:46,720
dus als je terugdenkt aan die lokale wetgeving, ja, je hebt een car policy, maar ja, die is wel

47
00:03:46,720 --> 00:03:53,000
wat verschillend in al die verschillende landen. En je hebt de vakantieregelingen en een hoop van

48
00:03:53,000 --> 00:03:57,600
die dingen waar je typisch policy documenten voor hebt. Ja, als je in één land zit, dan heb je

49
00:03:57,600 --> 00:04:02,080
misschien al zeven, acht policies voor een medewerker. Je kan je voorstellen dat dat er

50
00:04:02,080 --> 00:04:06,520
heel veel worden als je dus in verschillende landen zit. En om als HR dan nog te gaan weten,

51
00:04:06,520 --> 00:04:13,360
ja, die medewerker zit in dat land, dus die heeft die policies, wouden we een test doen waarbij

52
00:04:13,360 --> 00:04:22,480
dat we dus eigenlijk policy documenten opladen in AI en dat je dan aan AI kon vragen, ik heb een

53
00:04:22,480 --> 00:04:26,240
ongeluk met mijn wagen, wat moet ik doen? Of wie moet ik contacteren? Of wie mag er met mijn

54
00:04:26,240 --> 00:04:32,080
bedrijfswagen rijden? Of wat is onze bonusplan? Hoe werkt dat? Bijvoorbeeld van die zaken. En dus

55
00:04:32,080 --> 00:04:36,560
dat hebben we gedaan. We hebben op zich wel maar voor één land getest. We hebben onze eigen policy

56
00:04:36,560 --> 00:04:42,000
documenten opgeladen als test en dan konden we dus vragen stellen aan de AI. En dat hebben we dan

57
00:04:42,000 --> 00:04:48,480
effectief ook gedaan en dat hebben we dan in de PoC-fase afgewerkt. Dus dat werkte eigenlijk wel

58
00:04:48,480 --> 00:04:54,040
goed. Ja. En dus dat was de eerste PoC en de tweede PoC ging dan, dus dit was dan eigenlijk

59
00:04:54,040 --> 00:04:59,480
interne kennis die moest opgebouwd worden. Het andere is dan de externe kennis over de sociale

60
00:04:59,480 --> 00:05:05,960
wetgeving lokaal. En daar had ik dan terug met Tim een babbel over. Ik zei van ja maar ja,

61
00:05:05,960 --> 00:05:12,560
zo'n search engines en die zoeken maar en je bent niet zeker dat het helemaal juist is. En van waar

62
00:05:12,560 --> 00:05:17,480
komt die data dan? Dat is op zich wel belangrijk voor een payrollpersoon waarbij dat het over

63
00:05:17,480 --> 00:05:24,240
juridische data gaat. Dus toen zei hij, en dat wist ik dus nog niet, ja maar je kan helemaal scopen.

64
00:05:24,240 --> 00:05:28,920
Je kan die search gaan scopen met een Bing search. Kan je dan gaan aangeven over welke

65
00:05:28,920 --> 00:05:33,840
sites hij mag gaan zoeken. En op die manier zijn we daar dan dieper op ingegaan. Dat was onze PoC-2,

66
00:05:33,840 --> 00:05:40,960
waar we dan gezegd hebben van kijk je kiest eerst een land, een scope dus, en binnen die scope gaan

67
00:05:40,960 --> 00:05:46,120
wij websites opgeven waarbinnen de Bing search dan mag gaan zoeken. Waarbij je een vraag kan

68
00:05:46,120 --> 00:05:51,320
stellen in je eigen taal. Dus je terug die Brusselse dame die Frans-talig op zich is,

69
00:05:51,320 --> 00:05:56,760
die kan dus een vraag stellen in het Frans en wij gaan dan bij wijze van spreken als het dan over een

70
00:05:56,760 --> 00:06:02,360
Spaanse wetgeving gaat. Dan duidt ze eerst aan ik wil de Spaanse scope kiezen omdat het over een

71
00:06:02,360 --> 00:06:06,920
Spaanse vraag gaat. En dan kan ze bijvoorbeeld zeggen, ik zeg maar iets, ik zit met een ontslag

72
00:06:06,920 --> 00:06:11,960
in Spanje. Wat zijn de regels in Spanje om aan een ontslag, wat moet ik dan allemaal doen bijvoorbeeld?

73
00:06:11,960 --> 00:06:17,760
En die wetgeving? En die wetgeving staat op de Spaanse sites uiteraard van de overheid en van

74
00:06:17,760 --> 00:06:25,360
ja werk en welke sites heb je er allemaal. Dus sociaal-juridische sites en je hebt een hele hoop

75
00:06:25,360 --> 00:06:31,760
van die van die government sites die officieel onderhouden wordt. Waar je dus van mag uitgaan

76
00:06:31,760 --> 00:06:38,160
dat ze juist zijn en daar ga ik het dan over. En daardoor hebben we die dus opgelijst. Een tiental

77
00:06:38,160 --> 00:06:44,760
zeg maar iets per land. En daar en dus als ze nu een vraag stelt in het Frans dan gaan wij dat

78
00:06:44,760 --> 00:06:49,080
vertalen in het Spaans. Want die sites zijn in het Spaans dat kan hij ja heel goed. En dan gaat

79
00:06:49,080 --> 00:06:55,840
hij dan dat zoeken met die Bing search op die lokale sites, al die sites. En dan gaat hij het

80
00:06:55,840 --> 00:07:00,440
antwoord mergen uit verschillende antwoorden die hij dan gevonden heeft. Om dan eigenlijk zo tot een

81
00:07:00,440 --> 00:07:05,200
algemeen antwoord te komen. Maar wat we daar dan belangrijk bij vonden was wel dat we daar een

82
00:07:05,200 --> 00:07:10,360
bronverwijzing terug bij kregen. Zodat ze eventueel kunnen verder gaan zoeken. Ook al is het dan in

83
00:07:10,360 --> 00:07:15,600
het Spaans, je kan met je browser wel wat vertalen en zo. En dan wat hij dus nu doet, dat staat

84
00:07:15,600 --> 00:07:20,440
effectief. Dus dit hebben we verder uitgewerkt. Die zit ook effectief in onze in onze applicatie

85
00:07:20,440 --> 00:07:25,520
nu. En dus je kan die vraag stellen en dan geeft hij daaronder het antwoord, het gemerged antwoord,

86
00:07:25,520 --> 00:07:33,040
van de... Dan geeft hij het gemerged antwoord van al die antwoorden die hij dan binnen gekregen heeft.

87
00:07:33,040 --> 00:07:37,120
En dan geeft hij daaronder een vijftal bronvermeldingen. Hij geeft die dan in die tekst

88
00:07:37,120 --> 00:07:44,040
tot de bronvermeldingen en dan van waar hij dat gehaald heeft. Ja. Mooi. We kregen al een melding

89
00:07:44,040 --> 00:07:53,360
binnen net alsof het bericht binnenkwam vanuit Spanje. Ja geweldig. Want uiteindelijk heb je een

90
00:07:53,360 --> 00:07:59,560
soort van... In plaats van dat je de kennisbank gebruikt die je vaak intern in je organisatie

91
00:07:59,560 --> 00:08:05,720
hebt. Zeggen jullie van, ja maar de overheden, de diverse overheden, die hebben de laatste

92
00:08:05,720 --> 00:08:10,680
informatie, hebben ze online staan. Die gebruik je. Dus je gebruikt eigenlijk externe informatie.

93
00:08:10,680 --> 00:08:18,160
Klopt. Om je eigen antwoorden te verrijken. Gebruik je daar dan ook nog die eerste documenten

94
00:08:18,160 --> 00:08:25,960
waar je het over had van... De interne policies. Ja. Die pok hebben we niet verder uitgewerkt.

95
00:08:25,960 --> 00:08:31,600
Dus we hebben die wel in onze demo-testomgeving hebben we die wel staan. Maar als ik dan met

96
00:08:31,600 --> 00:08:36,800
klanten erover begon te praten, omdat we vandaag, zoals ik zei, we hebben een aantal kleinere klanten

97
00:08:36,800 --> 00:08:43,520
van 80 medewerkers. En die zeiden dan van, goh witte, die informatie externe in al die landen,

98
00:08:43,520 --> 00:08:48,360
dat is vandaag voor mij de grootste prioriteit. Ja precies. Alhoewel, ik vertelde gewoon van,

99
00:08:48,360 --> 00:08:52,760
kijk we zijn die twee Proof-of-Concepts aan het doen, wat zou jou interesseren om klantfeedback te krijgen.

100
00:08:52,760 --> 00:08:58,400
En dan zeiden zij over die PoC 2, ja maar dat betrouw ik niet. Dat je eigenlijk een vraag

101
00:08:58,400 --> 00:09:04,520
externe stelt. Want ja, ik gebruik geen ChatGPT bijvoorbeeld om zo'n vragen te stellen over

102
00:09:04,520 --> 00:09:08,480
Sociaal-juridische kennis, omdat ik daar niet zeker van ben. En toen moest ik eigenlijk uitleggen,

103
00:09:08,480 --> 00:09:13,520
maar wacht, we doen dat juist anders. We gaan eigenlijk alleen echte bronnen, officiële bronnen

104
00:09:13,520 --> 00:09:18,320
raadplegen. En toen switchte dat plots. En was dat eigenlijk de grootste interesse van de twee.

105
00:09:18,320 --> 00:09:22,720
Dat is eigenlijk de reden dat we de tweede eerst nu hebben uitgewerkt. En dat die nu in productie

106
00:09:22,720 --> 00:09:26,960
staat. De eerste hebben we nog in de kast zitten. Ja precies. Totdat we, ja, waarschijnlijk de

107
00:09:26,960 --> 00:09:31,520
grotere bedrijven zullen daar meer interesse voor hebben vermoed ik. Ja en je bent dus twee

108
00:09:31,520 --> 00:09:37,080
PoCs ingedoken. Ja. Wat waren de zaken waar je tegen aanliep tijdens de PoC? Waar je zegt van,

109
00:09:37,080 --> 00:09:43,600
ah daar heb ik echt wel wat van geleerd en dat wil ik meegeven. Wel, ik moet zeggen dat ik daar

110
00:09:43,600 --> 00:09:51,440
toch wel van geschrokken ben van de complexiteit om dat te maken. Dus ook ik als gebruiker van

111
00:09:51,440 --> 00:09:57,640
ChatGPT lijkt dat allemaal super simpel. Je stelt een vraag en dan stel je een tweede vraag die

112
00:09:57,640 --> 00:10:03,160
gebaseerd is op jouw eerste vraag. Ja dat blijkt dus al geen evidentie te zijn. En blijkt dus echt

113
00:10:03,160 --> 00:10:09,880
typisch chatgpt gerelateerde, ja, kennis te zijn. Die ze dan daar hebben ingestoken. Als je dat zelf

114
00:10:09,880 --> 00:10:15,320
wil genereren, ja dat is gewoon, ja, dat kan allemaal. Maar dan zou de pok ontploffen qua

115
00:10:15,320 --> 00:10:19,240
complexiteit. En vandaar hebben wij bijvoorbeeld gekozen. We hebben een invoerveld, een tekstveld,

116
00:10:19,240 --> 00:10:23,760
waar de gebruiker zijn vraag kan instellen. En als hij dan een tweede vraag wil stellen,

117
00:10:23,760 --> 00:10:28,280
dan maken wij eigenlijk alles terug leeg. Waardoor hij genoodzaakt is om de volledige

118
00:10:28,280 --> 00:10:31,960
context terug mee te geven. Omdat we dat dus gewoon niet wilden implementeren in deze fase.

119
00:10:31,960 --> 00:10:39,200
Dat is bijvoorbeeld een… En heeft dat dan te maken met dat het model dingen gaat combineren

120
00:10:39,200 --> 00:10:45,000
die dan niet meer juist zijn, waardoor je geen exact antwoord krijgt? Ja, op de duur, ja, je krijgt

121
00:10:45,000 --> 00:10:50,440
op de duur de kans dat er eigenlijk dingen insluipen, context van voorgaande vragen,

122
00:10:50,440 --> 00:10:56,560
wat je eigenlijk niet meer wil. En we, vanwege het feit dat we het heel juist wilden creëren,

123
00:10:56,560 --> 00:11:02,400
of het antwoord moet heel juist zijn, hebben we nu gekozen voor, nee, geef maar terug de context op

124
00:11:02,400 --> 00:11:06,720
en we beginnen gewoon elke keer van nul af. Dan moet je de hele vraag maar terugstellen,

125
00:11:06,720 --> 00:11:12,800
ofzo, met de nodige context. Dus dat was toch iets waar ik niet wist, dat dat eigenlijk toch

126
00:11:12,800 --> 00:11:17,800
niet zo evident is om dat mee te pakken. Context. Wel slim, want op een gegeven moment loopt,

127
00:11:17,800 --> 00:11:23,360
want zelfs die context loopt ergens eruit, maar er is een bepaald venster aan wat meegenomen kan

128
00:11:23,360 --> 00:11:29,760
worden. Dus je bent ook niet zeker van wat allemaal exact aan wordt meegenomen. Dus dat is wel een

129
00:11:29,760 --> 00:11:33,680
slimme manier om dat op die manier zo aan te pakken. Ja, voor nu. We hadden ook een beperkt budget

130
00:11:33,680 --> 00:11:38,640
natuurlijk voor die POC, dus daarvoor moest ik dan wel die keuzes maken. Maar je hebt heel goed

131
00:11:38,640 --> 00:11:45,360
dan nagedacht over risico's, hoe los je dit op en hoe kan je dit veilig uitvoeren? Ja, maar dat is

132
00:11:45,360 --> 00:11:51,400
denk ik ook wat we constant moeten doen in een start-up. Als je twee jaar bezig bent, je hebt

133
00:11:51,400 --> 00:11:56,640
een heel klein budget en je moet een product of een platform maken, dan is voor mij key product

134
00:11:56,640 --> 00:12:04,160
management. En product management is slim kiezen. En dat moesten we gewoon hier ook doen. Maar ik

135
00:12:04,160 --> 00:12:08,560
moet ook zeggen dat daar dan weer wel Tim kwam elke week langs om te kijken hoe het dan met de

136
00:12:08,560 --> 00:12:13,680
POC stond en daar kon ik dan ook wel met hem over discussiëren om de complexiteit in te schatten,

137
00:12:13,680 --> 00:12:18,000
want dat was dan niet altijd makkelijk. Maar ik denk dat het eigenlijk misschien wel een zege is

138
00:12:18,000 --> 00:12:22,800
dat je niet zo'n groot budget hebt, want dan moet je ook deze keuzes maken. Ik denk door het maken

139
00:12:22,800 --> 00:12:28,640
van deze keuze dat je een veiliger, beter betrouwbaarheid weet te krijgen. Ja, ik denk

140
00:12:28,640 --> 00:12:38,440
het ook. Slim. En heb je ook afwegingen moeten maken? Want ik neem aan dat soms als je iets zoekt,

141
00:12:38,440 --> 00:12:44,960
dat je geen antwoord krijgt of dat misschien de betrouwbaarheid, de zoekresultaten te laag zijn

142
00:12:44,960 --> 00:12:50,800
ten opzichte van de vraag die je stelt. Moest je daar ook keuzes in maken van wat je daarmee doet?

143
00:12:50,800 --> 00:12:55,960
Goh, dat heb ik nog niet helemaal opgelost. Dat doet hij soms. Hij zegt soms ik heb geen

144
00:12:55,960 --> 00:13:05,040
antwoord. En dan we zijn ook in het begin begonnen, omdat we coveren nu met dat ding de 30 Europese

145
00:13:05,040 --> 00:13:09,760
landen. Op zich kan het platform globaal, maar daar was niet aan te beginnen. Dus we hebben gewoon

146
00:13:09,760 --> 00:13:15,280
de 30 landjes toegevoegd en dan moesten we per in Bing search kan je dan per land de sites aanduiden

147
00:13:15,280 --> 00:13:21,360
waarop je mag zoeken. Maar dat is niet zo evident om die sites te vinden. Want ja, in Tsjechië of

148
00:13:21,360 --> 00:13:27,160
in ik weet niet waar, begin maar hoe dat die sites allemaal heten. Dus op zich hebben we daar twee

149
00:13:27,160 --> 00:13:33,320
manieren voor. Dus op zich vragen we aan onze lokale partners. We hebben in elk land een lokale

150
00:13:33,320 --> 00:13:39,000
partner. Van welke sites gebruiken jullie eigenlijk? Maar die antwoorden komen toch niet zo vlot. Die

151
00:13:39,000 --> 00:13:43,160
mensen zijn ook heel druk bezig en dus dat is niet zo evident. Dus gebruik ik daar dan weer wel

152
00:13:43,160 --> 00:13:49,960
ChatGPT voor. Dus ik zeg dan ik ben een payroll tax consultant en ik zoek een betrouwbare site met

153
00:13:49,960 --> 00:13:55,720
accurate informatie. Geef mij voor Tsjechië de vijf belangrijkste sites. En dan geeft hij eigenlijk

154
00:13:55,720 --> 00:14:03,520
wel ja typisch de government sites en en sociaal-juridische en misschien wel van een zeg maar een vakbond

155
00:14:03,520 --> 00:14:08,720
of zo. Een hele grote vakbond die kan er dan ook tussen zitten. En dan dat ik zo aan acht of tien

156
00:14:08,720 --> 00:14:15,000
sites kom die ik dan per land kan toekennen. En natuurlijk als het als de lokale partij nog

157
00:14:15,000 --> 00:14:21,680
bijkomende sites geeft dan voegen we die ook nog toe. Waardoor dat we nu toch wel al wat meer context

158
00:14:21,680 --> 00:14:27,800
hebben en wat meer kans hebben dat het goed komt. Maar ja dat die soms het niet weet ja dat is wel

159
00:14:27,800 --> 00:14:34,400
zo. Als je kijkt naar tien sites of alle sites in heel de wereld. Ja de kans dat je dan is een

160
00:14:34,400 --> 00:14:40,920
antwoord die is er natuurlijk wel. Wat ook bijvoorbeeld is is als je zoekt hoeveel vakantiedagen

161
00:14:40,920 --> 00:14:47,160
heeft een werknemer in Spanje of hoeveel vakantiedagen heeft een medewerker in Spanje. Ja kan

162
00:14:47,160 --> 00:14:51,880
gewoon het een kan gewoon zijn dat die het niet vindt omdat die het woord medewerker om een of

163
00:14:51,880 --> 00:14:55,840
andere reden niet goed vertaald krijgt of zo. En dat dat dan juist zo niet benoemd wordt op die

164
00:14:55,840 --> 00:15:01,200
lokale sites. Dus er zit zo nog wel een kantje aan dat we nog niet helemaal opgelost hebben.

165
00:15:01,200 --> 00:15:07,160
Nee want daar raak je inderdaad wel wat. Dat is wel een hele interessante denk ik ook. Want dat is

166
00:15:07,160 --> 00:15:12,560
een heel genuanceerd verschil. Dus die taalmodellen die kunnen heel goed als je een medewerker,

167
00:15:12,560 --> 00:15:19,040
werknemer. Want dan weet die zeg maar die woorden liggen zo dicht bij elkaar. Daar kan ik wat mee.

168
00:15:19,040 --> 00:15:23,920
Maar in de zoektechnologie heb je dat een heel stuk minder. Daar proberen ze dat ook wel een

169
00:15:23,920 --> 00:15:28,880
beetje. Ja maar is echt wel minder. Om daar onderscheid in te maken van je gebruikt search

170
00:15:28,880 --> 00:15:34,840
om iets te zoeken. Ja je hebt het taalmodel om het uiteindelijk als antwoord weer terug te vertalen.

171
00:15:34,840 --> 00:15:41,560
Ja ja ja ja ja en dan loop je tegen dat soort synoniemen. Dat zullen nog oplossingen misschien

172
00:15:41,560 --> 00:15:46,480
zijn. Als we hebben stellen een vraag in de lokale taal. Die wordt vertaald of de taal van

173
00:15:46,480 --> 00:15:51,200
de medewerker die wordt dan vertaald naar de lokale taal van de sites. Ja en daar zouden we kunnen

174
00:15:51,200 --> 00:15:57,760
bij wijze van spreken een aantal pogingen nog doen. We doen nu één poging. Je zou kunnen kiezen om

175
00:15:57,760 --> 00:16:03,400
om dan te zeggen ja herformuleer je vraag en probeer het nog eens. En zo zou je maar dat is dan al wat

176
00:16:03,400 --> 00:16:10,280
advanced. Daar zijn we nog niet. Hoe was het voor de gebruiker om met het systeem in aanraak te

177
00:16:10,280 --> 00:16:14,880
komen? Want daarvoor moest hij waarschijnlijk alles zelf op zoeken. En hoe bevalt dat? Ja wel

178
00:16:14,880 --> 00:16:21,520
dit heb ik nu. Het is echt nieuw. Dus ik heb nog niet heel veel feedback. Op zich hebben we, zijn

179
00:16:21,520 --> 00:16:27,840
we maar in eind van het jaar begonnen. Dus december en november hebben we de nog beginnen beslissen

180
00:16:27,840 --> 00:16:33,800
wat we gaan doen. We hebben dan in december de twee PoCs gemaakt. December en januari. Om dan

181
00:16:33,800 --> 00:16:38,440
eigenlijk te beslissen dat we met PoC 2 gingen doorgaan. Dus op zich ik denk dat het nog maar

182
00:16:38,440 --> 00:16:45,240
een maand anderhalf maand of zo effectief in de toepassing zit. En dan is het ook nog zo dat niet

183
00:16:45,240 --> 00:16:51,680
elke gebruiker dat heel intensief aan het gebruiken is. Dus ik heb nog niet zo heel veel feedback van

184
00:16:51,680 --> 00:16:57,160
dus daar moeten we nog echt wel stapjes zetten om met klanten te beginnen praten. Wat is nu? Dus

185
00:16:57,160 --> 00:17:03,000
nee daar zijn we nog niet. Ja ik denk wel alle hele mooie en ook een hele mooie voorloper. Er zijn

186
00:17:03,000 --> 00:17:07,480
heel veel bedrijven die hierover spreken dit zouden willen. Jullie hebben dit daadwerkelijk

187
00:17:07,480 --> 00:17:13,440
in productie. Dus dat is al sowieso waanzinnig. Ja dat wilde we ja. Het was op zich zoals ik zei

188
00:17:13,440 --> 00:17:20,000
een klein ding. Als je hoort op vier maanden tijd met met één developer van Info Support en eentje van

189
00:17:20,000 --> 00:17:25,320
mij. Ja viel het dan eigenlijk wel mee. Het was dan ook niet eens vol tijd. Er kwam maar een dagje

190
00:17:25,320 --> 00:17:29,560
per week langs. Dan valt dat eigenlijk wel mee qua budget om dat te doen. En dan wouden we wel

191
00:17:29,560 --> 00:17:33,600
ook weer als start-up kunnen zeggen kijk we hebben zoiets. Het is dan wel leuk om je dan wat te

192
00:17:33,600 --> 00:17:38,760
differentiëren van de grotere bedrijven. Heb je al een beetje inzicht in de operationele kosten

193
00:17:38,760 --> 00:17:47,040
hiervan? Want je weet nu niet hoeveel vragen er gesteld gaan worden en iedere vraag kost geld.

194
00:17:47,040 --> 00:17:53,480
Klopt. Dus je zei daarnet zijn er dingen die je geleerd hebt. Eén complexiteit. Twee dat kost toch

195
00:17:53,480 --> 00:17:59,960
wel wat geld. Dus de hele wereld denkt oh chatgpt is gratis. En ze maken iedereen verslaafd.

196
00:17:59,960 --> 00:18:06,920
Zal ik maar zeggen. Maar ja de bedrijven die gaan dit betalen. Dus ik denk dat wij, ik ben heel,

197
00:18:06,920 --> 00:18:13,120
dus wij zitten nu in de Microsoft founders hub. Dus wij hebben nog Azure credits. Waardoor ik

198
00:18:13,120 --> 00:18:18,680
gelukkig nog tot november credits heb om dit allemaal uit te testen. Oh zo die heb je van

199
00:18:18,680 --> 00:18:24,560
Microsoft gekregen. Ja dus de Microsoft founders hub is eigenlijk een manier om gedurende vier jaar,

200
00:18:24,560 --> 00:18:31,280
maar dat lukt niet. Want het eerste je krijgt duizend euro bij de start van je startup. En

201
00:18:31,280 --> 00:18:36,000
dan als je dan zegt ik ga product maken. Dan moet je er iets over vertellen. Dan krijg je vijfduizend

202
00:18:36,000 --> 00:18:42,720
dollar is het zeker. En dan als je dan, dat geldt ook maar twaalf maanden. Dus als je met die duizend

203
00:18:42,720 --> 00:18:46,680
zou toekomen wat niemand doet. Dan zou je in totaal vier jaar door kunnen. Want je hebt zo

204
00:18:46,680 --> 00:18:55,800
vier fases. En in fase drie krijg je 25.000 denk ik. En dan nu hebben we 150.000. Dus dat is eigenlijk

205
00:18:55,800 --> 00:19:01,160
wel veel. We hebben van belang zoveel niet nodig. Ik probeer ook heel erg budgetbewust onze Azure

206
00:19:01,160 --> 00:19:06,040
opzet te doen. Om dat in november niet te moeten downsizen. Dan doe je het alleen maar pijn. Dus

207
00:19:06,040 --> 00:19:10,840
ik probeer enkel te gebruiken wat we nodig hebben. En dus die Azure zit daar nu mee in. Maar ik denk

208
00:19:10,840 --> 00:19:15,200
dat we een component moesten activeren die wel 300 euro was denk ik. Als ik het me goed herinner.

209
00:19:15,200 --> 00:19:24,800
En dus ja dat. Per maand denk ik. Ja per maand uiteraard. Plus dan die tokens nog eens en zo.

210
00:19:24,800 --> 00:19:31,600
Dus ja het kost wel wat geld. En als je de vraag krijgt, kan je er geld voor vragen. En daar zijn

211
00:19:31,600 --> 00:19:35,600
we ook nog niet helemaal uit hoor. Hoe dat we daarmee gaan omgaan. Want het is een dure grap.

212
00:19:35,600 --> 00:19:40,400
En die POC 1 die zou nog veel meer gekost hebben. Dus dat is ook een beetje de reden waarom we,

213
00:19:40,400 --> 00:19:45,040
omdat we, één van de feedback van de klanten. Maar die eerste POC, als je al die documenten

214
00:19:45,040 --> 00:19:49,600
moet opladen. Dan heb je nog extra componenten die je helemaal gaat opkappen in al die. Ja en

215
00:19:49,600 --> 00:19:54,360
dan zijn het al de technische termen. En dan gaat hij dat eigenlijk helemaal opkappen in die,

216
00:19:54,360 --> 00:19:59,960
ja soort tokens bij wijze van spreken. Die dan opgeslagen worden in dat netwerk. Waar hij dan

217
00:19:59,960 --> 00:20:05,040
kan in gaan zoeken. En dan moet je eigenlijk per klant ja een pak data beginnen bijhouden. Wat dan

218
00:20:05,040 --> 00:20:12,680
ook weer een kost heeft. En dan search erop. En ja dus het is een lopende rekening. Ja. En net wat

219
00:20:12,680 --> 00:20:16,800
je zegt. Dat wordt gewoon heel vaak vergeten. Dat er allerlei operationele kosten aan zitten.

220
00:20:16,800 --> 00:20:23,480
Die ook best wel heel moeilijk te voorspellen zijn. Want je wil dat dat deze vragen nu veel

221
00:20:23,480 --> 00:20:29,600
makkelijker gesteld gaan worden. Dus het idee is denk ik ook dat er meer vragen. Toename van

222
00:20:29,600 --> 00:20:36,760
vragen. Maar toename van vragen betekent ook een toename. En vooral variabele kosten. Ja daar zit

223
00:20:36,760 --> 00:20:41,800
het in mijn naam inderdaad. Variabele kosten. Hoe ga je daar rekening mee houden? Ja. Dat is waar.

224
00:20:41,800 --> 00:20:48,520
Dus ja dat is iets waar we ook nog geen beeld over hebben. Dus dat zullen we nog moeten afwachten.

225
00:20:48,520 --> 00:20:55,440
Maar ja dat dus dat is ook het punt. Dus nu ook in startup fase wil ik het nu natuurlijk wat testen

226
00:20:55,440 --> 00:21:01,280
en zo. Ja het zou kunnen dat we als het succesvoller wordt. Dat we daar toch een betaalde versie van

227
00:21:01,280 --> 00:21:07,400
moeten gaan maken. En dan wij hebben onze onze prijs is altijd per persoon per maand. Dus omdat we

228
00:21:07,400 --> 00:21:13,480
in de p-roll zitten. En ik zeg maar je hebt 200 of 400 of 1000 medewerkers in je bedrijf. Dan rekenen

229
00:21:13,480 --> 00:21:17,760
wij een kost per medewerker per maand. Omdat je natuurlijk dat management van die mensen doet om

230
00:21:17,760 --> 00:21:21,960
hun p-roll te gaan bepalen. En dan kunnen wij er bij wijze van speken gemakkelijk zeggen. We doen dat

231
00:21:21,960 --> 00:21:26,960
gemakkelijk. We zouden dan kunnen zeggen we doen er een halve euro bij per medewerker. En dan spreid

232
00:21:26,960 --> 00:21:32,080
je die kost waardoor er dan toch wel een stuk van betaald wordt. Omdat je kan verwachten hoe meer

233
00:21:32,080 --> 00:21:35,960
medewerkers hoe meer soorten vragen je krijgt. En dus je zou het daar wat kunnen relateren. Precies.

234
00:21:35,960 --> 00:21:43,520
Ja dat is nog dat is ook wat sales. Ja en dan hebben jullie ook nog een keuze gemaakt in welk

235
00:21:43,520 --> 00:21:50,120
model je eronder hebt. Ik neem aan je zit in Microsoft technologie geef je aan. Dus het betekent

236
00:21:50,120 --> 00:21:57,640
dat je de Azure OpenAI services hebt. En dan heb je keuzes in in ieder geval GPT 3.5, 4, Mistral is

237
00:21:57,640 --> 00:22:03,480
er nu bij gekomen. Die hebben allemaal een verschillende pricing operationeel. Dus 3.5 is

238
00:22:03,480 --> 00:22:08,760
heel veel goedkoper dan 4. Hebben jullie daar nog een keuze in gemaakt? Ja omdat we nu enkel de

239
00:22:08,760 --> 00:22:13,560
vertaling nog maar gebruiken. Die hielden eigenlijk wel mee en hebben niet te hoog moeten gaan. Omdat

240
00:22:13,560 --> 00:22:17,000
we dan die Bing search gebruiken. Die doet eigenlijk het werk om te gaan zoeken. En dan gaan we dat

241
00:22:17,000 --> 00:22:28,160
wel terug mergen. Dus we moeten niet zo heel veel zoeken via chat. Maar ook daar bleek dan, wist ik

242
00:22:28,160 --> 00:22:33,880
ook niet, dat je ook wel inderdaad verschillende manieren hebt om die merge enzo. Je hebt open

243
00:22:33,880 --> 00:22:40,760
source verhalen en je hebt inderdaad het Microsoft ja de componenten in Azure dan wel eens waren. En

244
00:22:40,760 --> 00:22:47,280
daar hebben we nu nog wel gekozen voor een open source. Puur vanwege kost. Maar ik moet zeggen

245
00:22:47,280 --> 00:22:52,200
dat ook daar is een maand of twee geleden ik in de term niet meer. En dat hebben dan mijn twee

246
00:22:52,200 --> 00:22:58,840
developers geregeld. Maar daar heb je ook keuzes gemaakt om die operationele kosten eigenlijk zo

247
00:22:58,840 --> 00:23:06,280
laag mogelijk te maken. Ja. Want heel veel denken van ja maar we moeten GPT 4, het allernieuwste

248
00:23:06,280 --> 00:23:14,320
model. Wat ook meteen het allerduurste is. Er zit een factor in die is echt waanzinnig. Ja. Dat is

249
00:23:14,320 --> 00:23:18,720
ook zo. Ja. En wat dat bijvoorbeeld ook is. Hij was traag. Op een gegeven moment werd hij traag.

250
00:23:18,720 --> 00:23:24,960
Ja. Ja. En dus dan waren we aan het praten van ja maar als je dan ook weer hier als voorbeeld

251
00:23:24,960 --> 00:23:30,680
ChatGPT. Je stelt een vraag en dan begint die zo woordjes te zetten. Ja. Waardoor het precies

252
00:23:30,680 --> 00:23:37,080
niet zo lang duurt om een antwoord te krijgen. Maar als je dat dus wil dan heb je dus weer een

253
00:23:37,080 --> 00:23:42,000
extra complexiteit. Dus bij ons gaat die nu heel hard rekenen en dan komt hij met een antwoord.

254
00:23:42,000 --> 00:23:47,200
Maar dat kan dus vijf, zes, zeven seconden duren. En dan gaat die het antwoord in één keer geven.

255
00:23:47,200 --> 00:23:52,400
Dat was ook iets waar ik dacht ah ja, dat is iets wat je verwacht dat die dat doet. Maar toch weer

256
00:23:52,400 --> 00:23:57,280
niet evident is. Precies. Er zitten veel kantjes aan die als je dieper erop ingaat toch heel

257
00:23:57,280 --> 00:24:03,840
complex. Ja. En waar je als developer problemen over na moet denken. Maar ook qua kosten over na

258
00:24:03,840 --> 00:24:08,120
moet denken. Klopt. Want het is de beleving van langere doorlooptijd. Want waarschijnlijk

259
00:24:08,120 --> 00:24:12,240
het volledige antwoord is misschien wel even snel als dat ChatGPT mee toe. Misschien is dat wel

260
00:24:12,240 --> 00:24:17,760
sneller. Ja. Dus dat hebben ze heel slim gedaan qua interface. Ja. Zwaar. Om al woorden terug te

261
00:24:17,760 --> 00:24:23,520
geven. Ja. Gaandeweg. We hebben dat opgelost door dan een upgrade te doen van onze app service.

262
00:24:23,520 --> 00:24:28,400
Want ja, als we dan eentje hoger namen met meer CPU en meer memory. Dan ging hij wel gedeeld door

263
00:24:28,400 --> 00:24:32,840
drie of zo. Want we zaten eerst echt veel langer. En nu zitten we op een seconde of vijf, zes. Wat

264
00:24:32,840 --> 00:24:39,400
nog wel doenbaar is. We hebben er dan een spinnetje en zo en een spinnetje bij gestoken. Sava. Ja.

265
00:24:39,400 --> 00:24:44,400
En uiteindelijk, als je het gaat vertalen naar waarvoor je het nu toepast. Als je zelf handmatig

266
00:24:44,400 --> 00:24:49,560
moet gaan zoeken. Dan zou de tijd nog vele malen hoger liggen dan hiermee. Dus wat dat betreft zit

267
00:24:49,560 --> 00:24:53,280
er al een hele efficiënt slag in. Maar dat zijn wel de zaken waar je dan in terecht gaat komen. Om

268
00:24:53,280 --> 00:24:57,720
die optimalisatie te gaan doen. En kosten en performance af te gaan wegen. Ja. Dat zijn wel

269
00:24:57,720 --> 00:25:01,680
allemaal keuzes waar je in het begin niet over nadenkt. Nee. Wat we nu gewoon gewend zijn. Ik

270
00:25:01,680 --> 00:25:06,280
vraag het of ik zet het ergens aan en het is er. Ja. Maar dat is geen magie. Er komt zoveel

271
00:25:06,280 --> 00:25:11,240
achterkijken die. Ja. Dat is wat gewoon weggeschoven is. Dus ja. Inderdaad. Ik had

272
00:25:11,240 --> 00:25:18,720
onder wel eventjes de pricing opgezocht. Van OpenAI. Dus nu de GPT4 Turbo. Dat is het aller

273
00:25:18,720 --> 00:25:27,400
allernieuwste model. Als je daar de output tokens betaal je 30 euro per 1 miljoen tokens. 30 dollar.

274
00:25:27,400 --> 00:25:33,720
Sorry. 30 dollar per 1 miljoen tokens. Ja. En dat in vergelijking. En een token voor de luisteraar.

275
00:25:33,720 --> 00:25:38,520
Dat kunnen ook delen van woorden zijn. Dat kan ook gewoon de punt zijn. Achter een zin. Dat is

276
00:25:38,520 --> 00:25:47,480
ook gewoon één token. Ja. Dus per per miljoen 30 dollar. Kijk je naar 3.5. Dan hebben we het over

277
00:25:47,480 --> 00:25:55,240
1 dollar 50 per 1 miljoen tokens. Ja. Dus daar zit echt een enorme factor in. Van wat de keuze is.

278
00:25:55,240 --> 00:26:01,120
Wat je je onderzet aan operationele kosten. Ongelooflijk. Ja. Klopt. Dus als je op je kosten

279
00:26:01,120 --> 00:26:05,240
en je operationele kosten gaat letten. Doe hier alsjeblieft onderzoek naar. En ga niet altijd

280
00:26:05,240 --> 00:26:09,080
voor het nieuwste. Test het wel natuurlijk. Van wat is de kwaliteit en performance die je haalt.

281
00:26:09,080 --> 00:26:13,720
En is dat noodzakelijk ja of nee. Ja. Niet altijd maar het nieuwste van het nieuwste. Omdat.

282
00:26:13,720 --> 00:26:25,560
Dat is waar. Klopt. Ja. Wat zou zeg maar als je mag dromen. Over een jaar zeg maar. Waar zou dit

283
00:26:25,560 --> 00:26:31,920
staan. Ja. Het punt is dat ik nog wel een hoop andere ideeën heb erover. Die we zouden willen

284
00:26:31,920 --> 00:26:38,880
kunnen maken. En dan is het ook weer afwegen. Bijvoorbeeld vandaag terug in die perelwereld.

285
00:26:38,880 --> 00:26:45,520
Want elke perel engine heeft een lijst van perelcodes. En dat in België bijvoorbeeld. In

286
00:26:45,520 --> 00:26:51,360
ons perelsysteem in België. Of hetgeen dat wij gebruiken. Zijn er pak 500. Voor verschillende

287
00:26:51,360 --> 00:26:56,760
perelcodes. Dat gaat dan over een bonus. Dat gaat over een vakantiedag. Feestdag. Klein verlet.

288
00:26:56,760 --> 00:27:03,240
Ouderschapsverlof. Moederschapsverlof. Borstvoedingsverlof. Je hebt van alles. Maar evengoed.

289
00:27:03,240 --> 00:27:08,400
Werkloosheid en heel veel glooncodes. En dus omdat wij in ons systeem. In ons platform.

290
00:27:08,400 --> 00:27:12,680
Willen wij eigenlijk over al die landen heen. Appelen met appelen vergelijken. En de invoer

291
00:27:12,680 --> 00:27:18,200
heel eenvoudig gaan doen. Waardoor wij al die codes mappen op een set van onze eigen groepen.

292
00:27:18,200 --> 00:27:22,960
Subgroepen. En een soort van codelijst. Waarvoor het voor de gebruiker transparant is. Ik geef ik

293
00:27:22,960 --> 00:27:27,680
een loon in voor iemand van in Tsjechië terug. Of in Spanje. Dan kies ik eigenlijk uit de lijst.

294
00:27:27,680 --> 00:27:32,800
En die lijst wordt dan super beperkt. We gebruiken achterliggende reële looncode weliswaar. Maar voor

295
00:27:32,800 --> 00:27:39,040
de gebruiker is het heel gemakkelijk om die te vinden. Maar dat verrijst natuurlijk dat je bij

296
00:27:39,040 --> 00:27:45,840
de opstart die looncodes mapt op onze lijst. En dus dat is op zich wel een werkje. En ofwel doet de

297
00:27:45,840 --> 00:27:50,880
lokale HR dienst dat. Maar we merken dat dat toch geen evident werkje is. En dus meestal moeten wij

298
00:27:50,880 --> 00:27:59,800
dat zelf doen. Bij onze operations name. En dus zei een van mijn co-founders. Goh Bart. Kan AI dat

299
00:27:59,800 --> 00:28:06,360
niet oplossen? En dus daar ben ik nu de voorbije weken maar weliswaar tussendoor mee bezig geweest.

300
00:28:06,360 --> 00:28:11,400
Om te kijken in hoeverre kan hij eigenlijk die looncodelijst mappen op onze looncodelijst.

301
00:28:11,400 --> 00:28:17,360
Pure basis van de omschrijving. Die soms nogal cryptisch is. Maar daar ben ik redelijk ver

302
00:28:17,360 --> 00:28:22,080
in gelukt eigenlijk. Want ik had. Oké. Ik moet wel. We zijn op het punt dat ik eigenlijk elke

303
00:28:22,080 --> 00:28:26,120
looncode wel een categorie moet geven. Is het een betaalde code of een onbetaalde code? Of is het

304
00:28:26,120 --> 00:28:32,360
een bonus of is het een parameter? Want je hebt ook parameters. En als je die categorie

305
00:28:32,360 --> 00:28:36,960
bij wijze van spreken meegeeft. En dan moet die natuurlijk in een kleinere set gaan zoeken. Dat

306
00:28:36,960 --> 00:28:41,120
is dan het effect ervan. Maar dat maakt dat ik toch. Voor bijvoorbeeld de Nederlandse. Daar had

307
00:28:41,120 --> 00:28:49,240
ik 77 pdl-codes. En daar had hij er 72 van juist. Oh ja. Dus dat was al een goede vooruitgang. Om

308
00:28:49,240 --> 00:28:55,320
dat natuurlijk voor onze platform. Omdat we natuurlijk de iets kleinere bedrijven willen

309
00:28:55,320 --> 00:29:01,720
targetten. Is de opstartkost belangrijk. En als we die natuurlijk kunnen laten zakken door te zeggen.

310
00:29:01,720 --> 00:29:07,800
Kijk geef ons de looncodelijst. En wij gaan die voor preppen. Door er eigenlijk al eens met AI

311
00:29:07,800 --> 00:29:12,680
door te gaan. En dan een hele. Dan moet je eigenlijk nog maar wat corrigeren bij de foutjes die je dan

312
00:29:12,680 --> 00:29:17,080
gemaakt hebt. Maar je hebt al een hele goede preset. Dat is bijvoorbeeld iets waar we nu

313
00:29:17,080 --> 00:29:23,080
mee bezig zijn om te kijken. Kunnen we daar niks mee doen? Mooi. Maar het gaat ook. En dat is dan ook

314
00:29:23,080 --> 00:29:29,320
weer dan in de discussies met Tim. Dat zijn echt wel leuke discussies. Bijvoorbeeld een van de dingen

315
00:29:29,320 --> 00:29:34,520
die we daar nog hadden. Is mailtjes sturen. Is super evident. Maar we hebben een self-service.

316
00:29:34,520 --> 00:29:40,520
En een self-service. Daar heb je het feit van. Ik heb een vakantie aangevraagd gedaan. En mijn

317
00:29:40,520 --> 00:29:44,200
chef moet weten dat ik een vakantie aangevraagd gedaan heb. En dan moet die die goedkeuren. En

318
00:29:44,200 --> 00:29:47,480
dan krijgt de medewerker terug een mailtje. Ja het is goed gekeurd. Maar het kan ook zijn dat

319
00:29:47,480 --> 00:29:53,760
dat ietsje harder van op de hoogte moet gehouden worden. Of dat het een work from home is. Die dus

320
00:29:53,760 --> 00:29:59,200
een zelfgoedkeuring krijgt. Maar dat de medewerker. Dat de chef wel op de hoogte moet gebracht worden.

321
00:29:59,200 --> 00:30:04,240
En dus je hebt heel veel soorten mailtjes met heel veel variabelen in. En nu hebben we dus. Ja.

322
00:30:04,240 --> 00:30:10,960
Sendgrid gebruikt typisch. Met een hoop templates. Maar je zou ook kunnen zeggen. Kijk. Genereer een

323
00:30:10,960 --> 00:30:15,760
mailtje met deze parameters. Met die bestemmeling. In deze taal. En in zijn lokale taal nog eens. Van

324
00:30:15,760 --> 00:30:23,440
die medewerker. En genereer eigenlijk dan de tekst voor mij. Ja. Dat zou eigenlijk. Ja. Dan heb je

325
00:30:23,440 --> 00:30:29,920
eigenlijk alle varianten in één keer meegenomen. Ja. Dat is een superleuk ding. Alleen is daar direct

326
00:30:29,920 --> 00:30:36,800
bij mij de kost. Ja. Want dan ga je wel wat tokens genereren. En puur voor een mailtje. Dus. We gaan

327
00:30:36,800 --> 00:30:40,040
het nog even houden bij de templates denk ik. Maar dat zijn. Er zijn zeker een hoop ideeën die

328
00:30:40,040 --> 00:30:45,480
wel nog spelen. Die het interessant zou kunnen maken. Ja. Nou wat daar misschien nog wel interessant

329
00:30:45,480 --> 00:30:51,080
is. Want ik denk dat het een hele mooie case is. Juist omdat die taalmodellen zo goed met taal om

330
00:30:51,080 --> 00:30:56,960
kunnen gaan. Ja. En de verschillende talen. Maar er is ook best al wat onderzoek naar. Wat ze dan

331
00:30:56,960 --> 00:31:04,800
noemen. Caching. Dat is iets wat qua betekenis op elkaar lijkt. Dus dan kan het zeg maar net iets

332
00:31:04,800 --> 00:31:11,080
anders ingegeven zijn. Maar is uiteindelijk het uiteindelijke mailtje. Zou eigenlijk hetzelfde

333
00:31:11,080 --> 00:31:15,600
kunnen zijn als wat al eens een keer eerder is gestuurd. En dan hoef je dus niet naar je taalmodel.

334
00:31:15,600 --> 00:31:22,680
Heb je dus niet die operational kost. Oké. Dat wist ik niet. Ja. En dan lijken dingen dus semantisch

335
00:31:22,680 --> 00:31:27,560
op elkaar. En als ze dan zo erg semantisch op elkaar lijken. Kun je dus eigenlijk wat je al

336
00:31:27,560 --> 00:31:32,800
had opgeslagen. Herbruiken. Kan je gewoon herbruiken. Ah ja. Cool. Oké. Dus daar. Dat

337
00:31:32,800 --> 00:31:37,000
zou toch misschien eens bekijken. Toch? Ja. Ja. Absoluut. Ja. En die mailtjes worden waarschijnlijk

338
00:31:37,000 --> 00:31:41,280
nu ook al gestuurd. Dus wat je ook vaak nu ziet is dat de mailtjes die allemaal verstuurd worden.

339
00:31:41,280 --> 00:31:45,680
Dat daar eigenlijk gekeken wordt naar wat voor categorisering kan je op die mailtjes al loslaten.

340
00:31:45,680 --> 00:31:50,360
Om eigenlijk te komen tot inzichten op wat er nu al verstuurd wordt. En of daar al patronen in te

341
00:31:50,360 --> 00:31:55,400
herkennen zijn. Maar dan ga je wel grasduinen in de data. En daar zit tijd en kosten in. En dan kijken

342
00:31:55,400 --> 00:32:01,080
wat je kan organiseren. Ik denk dat die semantische gelijkheid. Heel veel. Dat je daar best wel heel

343
00:32:01,080 --> 00:32:07,400
veel in zou kunnen halen. Bart, we hebben ook een virtuele co-host. En zij wil ook eigenlijk

344
00:32:07,400 --> 00:32:29,480
altijd een vraag stellen. Oké. Aisha. Aisha. Goed je hier te zien. Ik ben Aisha. De AI-assistent

345
00:32:29,480 --> 00:32:36,880
van deze show. Zou je het goed vinden als ik je een vraag stel? Uiteraard. Hoe kunnen we AI trainen

346
00:32:36,880 --> 00:32:45,080
met data die representatief is voor de hele bevolking? Hoe kunnen we AI trainen? Hoe kunnen

347
00:32:45,080 --> 00:32:51,720
we AI trainen met de data die representatief is voor de hele bevolking? Oké. Oei. Dat is geen

348
00:32:51,720 --> 00:33:01,240
gemakkelijke vraag. Ik denk dat we, ja, als ik kijk naar HR, dan is dat op zich wel een gevaarlijk

349
00:33:01,240 --> 00:33:08,360
iets. Wat dat, als je dan zegt 'trainen met data', ja, iets waar natuurlijk de HR-mensen en wijzelf

350
00:33:08,360 --> 00:33:14,580
grote bang van hebben, is het feit dat het over superpersoonlijke data gaat. En dus de eerste

351
00:33:14,580 --> 00:33:19,920
vraag die ik ook wel krijg is, en dan niet met het zoeken van die juridische info, want dat is

352
00:33:19,920 --> 00:33:22,800
sowieso extern, maar bijvoorbeeld die eerste vraag is, ja, waar wordt dat dan eigenlijk allemaal

353
00:33:22,800 --> 00:33:27,080
opgeslagen? En waar gaat die data naartoe? En hoe werkt dat dan met die search engine? Dus je hebt

354
00:33:27,080 --> 00:33:35,840
eigenlijk nog wel wat uitleg, educatie nodig bij de klanten eventueel, als je zoiets zou gaan doen.

355
00:33:35,840 --> 00:33:45,240
En dus ik denk dat er zeker interessante trends te trekken zijn, zeker over die HR-data en over al

356
00:33:45,240 --> 00:33:52,680
die afwezigheden. En zeker vandaag in het wellbeing-verhaal hebben we superveel data vanuit

357
00:33:52,680 --> 00:33:59,960
Perel en alles wat eraan gerelateerd is. En evengoed ook loonkosten en equal pay en ESG en

358
00:33:59,960 --> 00:34:06,920
al die zaken, injuries, we houden allemaal bij. Dus er zijn zeker trends in te trekken, maar ik weet

359
00:34:06,920 --> 00:34:12,360
niet dat, als ik vandaag zou zeggen, ja, die data gaan we ook gebruiken om trends te trekken voor

360
00:34:12,360 --> 00:34:18,520
de ganse bevolking. Dat weet ik niet zo goed. Dus het zou zeker kunnen, maar dan is de databeveiliging

361
00:34:18,520 --> 00:34:24,120
key, volgens mij. Als dat een beetje een antwoord is op haar vraag, want het was echt een moeilijke

362
00:34:24,120 --> 00:34:29,360
vraag. Zullen we eens even kijken? Hartelijk dank voor je grondige en verhelderende uitleg.

363
00:34:29,360 --> 00:34:39,680
Kijk eens aan. Ja, heel interessant. En vooral, weet je, zo'n mooi inzicht over wat je in de

364
00:34:39,680 --> 00:34:44,560
praktijk eigenlijk, dat je dit hebt lopen. Als je nou terug zou kijken, zou er iets zijn,

365
00:34:44,560 --> 00:34:49,560
wat je, want je hebt nu veel meer kennis, wat je anders zou doen met de kennis die je nu hebt?

366
00:34:49,560 --> 00:34:54,440
Stel dat je dit traject over zou moeten doen, bijvoorbeeld die POC 2, dus wat je nu in productie

367
00:34:54,440 --> 00:35:01,600
hebt. Zou je anders beginnen? Ik denk het niet. Nee, ik heb niet het gevoel dat we daar ergens

368
00:35:01,600 --> 00:35:08,960
heel veel tijd zijn verloren of dat we ergens onbedoelde kosten hebben gemaakt of zo. In mijn

369
00:35:08,960 --> 00:35:14,840
ogen is het heel efficiënt verlopen. Ik heb ook wel direct afgesproken dat we dat dus niet al zien

370
00:35:14,840 --> 00:35:20,920
van "we gaan nu twee weken vol tijds daaraan programmeren", omdat ik ondertussen ook wel weet

371
00:35:20,920 --> 00:35:27,480
dat inzichten groeien door tijd. En soms moet je gewoon even iets doen en dan het een week

372
00:35:27,480 --> 00:35:31,800
laten liggen om erover na te denken en dan eigenlijk het volgende stapje te zetten. En

373
00:35:31,800 --> 00:35:36,400
het feit dat we dus die track, zoals ik zei, een halve dag tot een dag in de week deden,

374
00:35:36,400 --> 00:35:43,400
elke week, dus elke week dezelfde dag was dat, hebben we er twee, drie maanden over gedaan. Dus

375
00:35:43,400 --> 00:35:50,040
een dag of acht, twaalf, daartussen zal het ergens liggen. Als je die achter elkaar zou doen, dan

376
00:35:50,040 --> 00:35:55,000
zou je niet het resultaat halen, denk ik, dat we nu hebben gedaan. Puur omdat we elke keer die

377
00:35:55,000 --> 00:36:02,280
reflectie konden maken. Ja, tijd om na te denken. Dus ik heb niet het gevoel dat we daar enige tijd

378
00:36:02,280 --> 00:36:07,040
verloren zijn eigenlijk. Misschien eigenlijk wel gewonnen door het rustig aan te doen. Ik denk het

379
00:36:07,040 --> 00:36:12,640
wel. Dat is een mooie. Dat is een mooie inderdaad. Want vaak werken we ook heel snel inderdaad. Ja,

380
00:36:12,640 --> 00:36:17,640
ja dat is niet altijd. Ik zie dat nu ook weer, als ik teruggrijp naar het product management. Ik heb

381
00:36:17,640 --> 00:36:23,440
toch het meest, ik kom van vroeger had ik een product management team, nu moet ik zelf de

382
00:36:23,440 --> 00:36:28,640
schermpjes terug tekenen. Dat is super leuk, maar ik zie toch dat ik zelf een drie tot vier

383
00:36:28,640 --> 00:36:32,760
iteraties nodig heb om een scherm te tekenen. Dus ik teken een scherm, ik probeer dat helemaal

384
00:36:32,760 --> 00:36:37,920
conceptueel uit te denken. De logica moet er ook in zitten. Hoe past het in het groter geheel? Ik

385
00:36:37,920 --> 00:36:42,920
teken dat en dan laat ik dat eigenlijk liggen. Ik moet echt twee maanden voor zijn op de developers

386
00:36:42,920 --> 00:36:47,760
om dat goed te krijgen, want ik moet dat dan twee, drie weken laten liggen. Dan heel de logica terug

387
00:36:47,760 --> 00:36:51,880
afchecken en dan kom ik gegarandeerd dingen tegen die niet kloppen of die niet dat ik dacht,

388
00:36:51,880 --> 00:36:55,920
olle, wat heb ik dan nu getekend? Dat klopt toch niet meer? En dan heb ik toch echt wel een drietal

389
00:36:55,920 --> 00:37:01,360
iteraties nodig. En je ziet dat tijd op dat moment belangrijk is. Ik zou niet kunnen zeggen,

390
00:37:01,360 --> 00:37:06,120
ik teken dat en begin er morgen maar aan. Dat zou niet goed zijn. Het leuke is, we hebben

391
00:37:06,120 --> 00:37:12,240
aflevering hiervoor met Willem Meints, architect op het gebied van AI en gesproken large language

392
00:37:12,240 --> 00:37:18,560
models over de OWASP top 10 voor large language models. En dat gaat over beveiliging van dit soort

393
00:37:18,560 --> 00:37:25,560
modellen. En het begin, de inleiding van die OWASP top 10 voor large language models,

394
00:37:25,560 --> 00:37:32,600
die zegt van we hebben een checklist gemaakt voor degene die overhaast AI in productie wil

395
00:37:32,600 --> 00:37:37,160
brengen. En daarom is jouw verhaal juist wel mooi. Die zegt van, ja even een stapje terug,

396
00:37:37,160 --> 00:37:43,440
rustig aan. Maar met die rust ben je eigenlijk eerder op je eindbestemming. Eigenlijk de haas

397
00:37:43,440 --> 00:37:50,480
en de schildpad. De haas en de schildpad is uiteindelijk eerder aan de finish door goed

398
00:37:50,480 --> 00:37:57,440
na te denken over welke stappen je neemt. Ja mooi. Wat ik mooi vind om te horen is dat je

399
00:37:57,440 --> 00:38:02,440
eigenlijk bij de problematiek AI gewoon meeneemt in, is de potentiële oplossing. Waar ik nieuwsgierig

400
00:38:02,440 --> 00:38:07,840
aan ben is, wat zijn voor jou de criteria van, ga ik het met AI oplossen? Ga ik het traditioneel

401
00:38:07,840 --> 00:38:20,320
met software oplossen? Heb je daar een? Wanneer zou ik AI kiezen? Ja soms is het gewoon super

402
00:38:20,320 --> 00:38:26,320
moeilijk om het algoritme te bedenken of te schrijven in conventionele programmeertalen,

403
00:38:26,320 --> 00:38:34,400
denk ik. En ik denk dat zoals dat mailtje of zoals het zoeken naar de juiste, die perelcode mapping

404
00:38:34,400 --> 00:38:40,400
bijvoorbeeld, ja begin maar eens aan een label te matchen met een ander label, met alle opties die

405
00:38:40,400 --> 00:38:45,000
daarbij zijn. Daar kan je gewoon niet van winnen, dat moment. En ik denk dat in zo'n gevallen,

406
00:38:45,000 --> 00:38:51,880
dat je inderdaad AI moet bekijken, weliswaar de kost ernaast leggen, maar ja dan denk ik dat het

407
00:38:51,880 --> 00:38:56,120
interessant is. Ik denk dat het in heel veel gevallen ook nog gewoon beter is om het gewoon

408
00:38:56,120 --> 00:39:02,880
te programmeren. Dus maar ja, dus ik denk dat het een beetje in die trend is. Hoe complex is om

409
00:39:02,880 --> 00:39:09,960
het te maken zelf en en wat is de tegenhanger en wat is de kost in AI? En als startup moet je kiezen

410
00:39:09,960 --> 00:39:15,960
wat denk ik goed is. We hebben het al over gehad, over operationele kosten. Hoe zorg je dat je bij

411
00:39:15,960 --> 00:39:20,640
blijft op wat de ontwikkelingen zijn met AI en wat zou je andere mensen aan willen raden die

412
00:39:20,640 --> 00:39:24,760
ook bij willen blijven? Want ja, je wil top of the game zijn in je startup, maar je hebt ook genoeg

413
00:39:24,760 --> 00:39:33,480
andere aandachtsgebieden. Hoe blijf je bij? Ja, er zijn altijd meer features verwacht dan tijd. Nu ja,

414
00:39:33,480 --> 00:39:42,280
hoe blijf je bij? Wel, ik blijf bij door veel externe mensen te kennen, denk ik. En dat komt

415
00:39:42,280 --> 00:39:48,760
natuurlijk omdat ik al heel lang in de IT management zit. Zelf ooit lang geleden developer was geweest,

416
00:39:48,760 --> 00:39:53,920
dus ik bedoel ik begrijp die concepten wel heel goed, denk ik. Ik zou niet meer zelf kunnen

417
00:39:53,920 --> 00:39:58,480
zoiets maken, maar ik begrijp wel waarover het gaat. We kunnen aan een bord gaan staan en beginnen

418
00:39:58,480 --> 00:40:06,440
tekenen. En dan natuurlijk, ja, al tien jaar CTO, dus ik heb een gigantisch netwerk dat ik probeer

419
00:40:06,440 --> 00:40:11,760
wel goed in ere te houden. En door dus zoals met een aantal mensen elke drie, vier maand is een

420
00:40:11,760 --> 00:40:16,960
lunchje te doen of is af te spreken of is ja, de vraag is echt, heb je iets gemaakt? Wat denk je ervan?

421
00:40:16,960 --> 00:40:22,840
Ik denk dat dat wel helpt om zo aan nieuwe ideeën en aan nieuwe trends te komen. Want

422
00:40:22,840 --> 00:40:27,600
iemand zegt iets wat je gewoon triggert om er beginnen over na te denken. En als je dan open

423
00:40:27,600 --> 00:40:34,800
staat voor feedback en kritiek, dan dat is het leraarste eigenlijk. Mooi, mooi. Ik denk dat we

424
00:40:34,800 --> 00:40:40,960
heel wat inzichten van je hebben gekregen. Super bedankt. Ik heb in ieder geval, weet je, de haas

425
00:40:40,960 --> 00:40:47,400
en de schildpad. Dat is een mooie om mee te eindigen. Maar vooral eigenlijk van de stappen die jullie

426
00:40:47,400 --> 00:40:52,600
hebben gezet om dit daadwerkelijk in productie te krijgen. Overig goed over nagedacht. Super

427
00:40:52,600 --> 00:40:59,560
bedankt dat je dit met ons wilde delen. Ja, graag gedaan. Leuk dat je er weer luisterde naar een

428
00:40:59,560 --> 00:41:07,200
aflevering van AIToday Live. Bart, nogmaals bedankt voor alles wat je ons verteld hebt. Wil je meer

429
00:41:07,200 --> 00:41:13,320
weten, meer horen over het onderwerp AI in het algemeen? Vergeet je dan niet te abonneren via

430
00:41:13,320 --> 00:41:18,240
je favoriete podcast app. Druk op het knopje volg en dan krijg je vanzelf een seintje bij

431
00:41:18,240 --> 00:41:21,040
de volgende aflevering. Dank je wel. Tot de volgende keer.

432
00:41:21,040 --> 00:41:21,540
[Muziek]

433
00:41:21,540 --> 00:41:41,940
[Muziek]