Qlik Answers-review: wat we leerden van tests in de praktijk

Wat we leerden toen we Qlik Answers testten op een live klantdashboard, augustus 2026.

De afgelopen maanden testten we Qlik Answers op een dashboard van een van onze klanten. We hadden al veel tests uitgevoerd op kleine, eenvoudige apps. De resultaten waren veelbelovend en de gebruikerservaring was goed, maar bij kleine apps liggen niet de complexe uitdagingen van analytics. Daarom stapten we over op een echte praktijksituatie: een verkoopmodel in productie, inclusief de bijbehorende problemen met datakwaliteit en keuzes in de modellering. 

AI-tools ontwikkelen zich snel, dus zie dit als een momentopname. Deze review beschrijft hoe Qlik Answers zich in juli 2026 gedroeg. De agentgedreven ervaring was toen niet meer gloednieuw. Qlik maakte die in februari 2026 algemeen beschikbaar en breidde tijdens Qlik Connect in april de set agents uit. Wat we van buitenaf niet kunnen vaststellen, is welke updates van de onderliggende modellen in de tussentijd zijn doorgevoerd. 

Waarom Qlik Answers en niet Claude, ChatGPT of Gemini 

Samen met de klant stelden we twee harde eisen: alleen binnen de EU en geen training met onze data. Het is belangrijk om dat expliciet te benoemen, omdat de agentgedreven ervaring van Qlik Answers standaard niet binnen de regio van je tenant blijft. Je moet je aanmelden voor cross-region inference. Daarmee kan Qlik het inferenceverzoek naar de AWS-regio sturen waar het model beschikbaar is. Voor tenants in de EU stelt Qlik dat altijd een EU-profiel voor cross-region inference wordt geselecteerd. Het verzoek blijft daardoor binnen AWS-regio’s in de EU. Ook stelt Qlik dat het inschakelen hiervan Qlik of AWS geen toegang tot je data geeft.  Over training is de documentatie duidelijk: Qlik stelt dat het geen klantdata gebruikt om AI-modellen te trainen buiten de eigen tenant van de klant. 

Voor de andere modellen konden we diezelfde garantie niet krijgen. De keuze was dus al gemaakt voordat we ook maar één antwoord hadden vergeleken. 

Hoe verhoudt Qlik Answers zich dan tot de andere modellen?

We hebben dezelfde vragen ook op onze eigen testdashboards uitgevoerd met Claude, ChatGPT en Gemini. Naar onze mening waren die antwoorden beter, met één kanttekening waar we direct tegenaan liepen: met het kleine Haiku-model zat Claude ernaast en pas met Opus presteerde het duidelijk beter dan Qlik Answers. Frontiermodellen brengen een breder pakket aan vaardigheden mee voor dit vraagstuk, waardoor ze simpelweg meer mogelijkheden hebben.

Dat is een observatie op basis van testdata en geen benchmark. Het veranderde de beslissing in dit geval niet: de EU-eis was niet onderhandelbaar.

Dit hoeft overigens niet per se een keuze voor het een of het ander te zijn. Qlik stelt zijn analysemogelijkheden ook beschikbaar via de Qlik MCP Server. Daarmee kun je clients zoals Claude of ChatGPT gebruiken om met beheerde Qlik-data en masteritems te werken. In die opzet redeneert het externe model, terwijl Qlik beheerde toegang tot de data biedt. Het nadeel is dat de data die naar het model wordt gestuurd, vervolgens wordt verwerkt volgens het beleid van die aanbieder. Voor deze klant voldeed dit daarom niet aan de eis dat alles uitsluitend binnen de EU moest plaatsvinden.

Het testdashboard dat we gebruikten heet ThermoThuis. Dit is een demoapplicatie die we hebben gebouwd met openbare data over alle adressen in Aalsmeer, waar ons kantoor is gevestigd. Het brengt informatie samen zoals energielabels, WOZ-waarden en andere woningkenmerken, om inzichtelijk te maken waar investeringen in verduurzaming waarschijnlijk de meeste impact en het hoogste rendement opleveren.

Hieronder zie je hoe Qlik Answers en Claude dezelfde prompts hebben beantwoord.  
 
Mijn eerste reactie was dat Qlik Answers deze ronde had gewonnen, omdat Claude met Haiku het verkeerde antwoord gaf. Daarna schakelden we Claude over op Opus en eerlijk gezegd vond ik Claude de sterkste van de twee. De grafieken maakten het punt duidelijk. De aantallen verschillen enigszins doordat Qlik Answers een andere meting koos dan Claude. Bij de visualisaties van de tweede prompt is dat verschil het duidelijkst. 

Prompt: Visualiseer enkele belangrijke trends

Qlik Answers:  

Prompt: Zie je een verband tussen het bouwjaar en de energielabels?

Het model doet ertoe, de context bepaalt. 

Tijdens het opzetten hiervan lazen we in verschillende bronnen hetzelfde punt: context draagt meer bij aan nauwkeurigheid dan de keuze voor een model. De tabel hieronder komt uit een van die bronnen. In elke iteratie werd dezelfde vraag gesteld; alleen de hoeveelheid context waarmee het model kon werken, veranderde.

Iteration	What changed	SQL generation	Accuracy
1	Raw tables	0%	0%
2	Modelled table, no context	38.5%	0%
3	Column descriptions	100%	15%
4	Business rules and instructions	100%	77%
5-6	Metrics, verified queries, eval refinement	100%	92%

Bron: Datacult, Het saaie werk waardoor AI Analytics daadwerkelijk werkt. 

De nauwkeurigheid stijgt van 0% naar 92% zonder ook maar één keer van model te wisselen. Onze ervaring is dat dit patroon ook buiten het lab geldt: het model doet ertoe, maar de context bepaalt. Geef een frontiermodel een dashboard zonder context en het geeft je nog steeds vol overtuiging het verkeerde getal.

Met deze review proberen we dat op een echt dashboard te testen. Eerst bespreken we de vijf dingen die we hebben aangepast om betrouwbare antwoorden te krijgen. Daarna bekijken we waar het momenteel tegen zijn grenzen aanloopt en wat nodig is om een volgende stap te zetten: context die per analyse is georganiseerd in plaats van per dashboard.

Het model waarmee we hebben getest

Stap 1: Vul het logische model 

Het eerste wat we deden, was de app beschikbaar maken voor Qlik Answers, zodat die kon worden geïndexeerd. Dat ging goed. Na even wachten konden we vragen gaan stellen. 

De antwoorden waren onjuist. Qlik Answers bedacht eigen metingen in plaats van die van ons te gebruiken. Bij een geconcateneerde facttabel levert dat cijfers op die aannemelijk lijken, maar dat niet zijn. 

De oorzaak bleek het logische model te zijn. Qlik Answers leest het logische model en redeneert op basis daarvan, maar onze master measures stonden daar niet in. Het vulde die leemte dus zelf in. Dat komt overeen met wat Qlik documenteert. Master measures en dimensies worden vóór ruwe velden geëvalueerd en items die door de ontwikkelaar zijn gedefinieerd, gelden als de vertrouwde bron. Maar dat geldt alleen voor masteritems die daadwerkelijk in het logische model staan. Die van ons stonden er niet in, dus er was niets om rekening mee te houden en Qlik Answers schreef in plaats daarvan een eigen expressie. We voegden de metingen toe aan het logische model, waarna Qlik Answers meteen antwoorden begon te geven op basis van de master measures. 

Weergave van het logische model 

Stap 2: Beschrijf je master measures

In stap 1 formuleerden we onze vragen zo dat Qlik Answers naar een specifieke master measures werd gestuurd. Dat werkt voor een test, maar zo gebruikt niemand een dashboard in de praktijk. Je wilt dat een collega van sales een vraag in eigen woorden kan stellen en het juiste antwoord krijgt. 

Daarvoor is betere context nodig. Vooral drie dingen: synoniemen voor de termen die mensen daadwerkelijk gebruiken, een uitleg van wat elke meting betekent en per meting een toelichting op wanneer die wel en niet moet worden gebruikt. 

Op basis van Qlik’s eigen richtlijnen voor het schrijven van beschrijvingen namen we elke master measure door en vulden we het beschrijvingsveld met de werkelijke zakelijke betekenis, in plaats van de expressie in andere woorden te herhalen. Voor de eerste versie gebruikten we een LLM: we gaven die onze naamgevingsconventies en lieten voor elke master measure een beschrijving opstellen. Daarna controleerden we elke beschrijving aan de hand van wat we werkelijk bedoelden. In dezelfde ronde gaven we aan welke metingen technische bouwstenen voor de onderliggende berekening zijn en welke metingen eindgebruikers horen te gebruiken. Het model kan dat verwoorden, maar alleen wij weten welke meting mensen moeten gebruiken. 

De antwoorden werden beter. De nauwkeurigheid nam toe en Qlik Answers kon een vraag zelfstandig aan de juiste master measure koppelen. Niet perfect, maar het verschil tussen een ingevuld en een leeg beschrijvingsveld is zo groot dat we deze stap niet nog eens zouden overslaan. 

Stap 3: Lees de redenering 

Vervolgens vroegen we of Customer A meer of minder had besteld dan in dezelfde periode vorig jaar. Na even wachten kregen we visualisaties op basis van het aantal orders. Daarna vroegen we om dezelfde vergelijking in euro’s. 

De redenering die Qlik Answers bij die vervolgvraag liet zien, zag er als volgt uit. Klantnamen, veldnamen en cijfers zijn vervangen om de gegevens van onze klant te anonimiseren, maar de structuur van de uitvoer is ongewijzigd: 

Het werkt. Maar het koos Gross COST PRICE, terwijl we bij deze vraag Gross Amount verwachtten. Interessant detail: Gross Amount kwam helemaal niet terug in de redenering.  

De gegenereerde meting zag er als volgt uit:

{<[Customer]={'123456 - DO NOT USE - CUSTOMER A','324567 - CUSTOMER A','456789 - STOCK ORDER CUSTOMER A'},[Date Order]={">=$(=01-01-26 12:00:00[.000000])<=$(=30-06-26 12:00:00[.000000])"}>} [Gross COST PRICE] 

Kijk naar die klantselectie. Daarin staat een account dat letterlijk DO NOT USE heet. Er staan geen orders onder, dus het cijfer klopt nog steeds, maar de AI kon niet weten dat dit account moest worden uitgesloten. Er zijn twee opties: in de context uitleggen dat Customer Status zo moet worden gefilterd dat alleen actieve klanten overblijven, of het account volledig uit het dashboard verwijderen, zodat niemand het per ongeluk kan selecteren, mens of machine. Onze ervaring is dat de tweede optie in de praktijk de enige blijvende oplossing is. 

Ook het datumfilter verdient een tweede blik. Het filterde op [Date Order], terwijl het model ook een gewoon veld Date beschikbaar stelt en Date de logischere keuze is om een periode op te filteren. De achterliggende oorzaak is dezelfde als bij de klantselectie: niets in de context gaf aan welk van de twee velden de voorkeur had, dus koos het model het veld waarvan de naam het meest op de vraag leek. Twee velden die vergelijkbaar klinken maar anders werken, zijn precies het soort zaken dat je collega’s één keer leren en nooit opschrijven. 

Het kennishiaat zit in de context

Hier zit het hiaat. Een ervaren gebruiker haalt het juiste antwoord uit een dashboard, omdat die weet welke velden je moet vermijden. Die kennis zit in het hoofd van de gebruiker, niet in de app. AI kan alleen werken met wat er is vastgelegd. Alles wat een collega uit ervaring weet, moet expliciete context worden. Anders bestaat het niet. 

Het helpt enorm dat Qlik Answers dit detailniveau laat zien. Je ziet hoe een antwoord tot stand is gekomen en, belangrijker nog, waar je de context moet aanscherpen om een beter antwoord te krijgen. Een antwoord zonder zichtbare redenering had er hier prima uitgezien. 

Lees dus de redenering en lees Qliks eigen uitleg over wat elke agent in de keten doet. Dat is de twintig minuten waard. De Semantic Search Agent selecteert de masteritems die volgens de agent nodig zijn om je vraag te beantwoorden, de Data Analyst Agent zet die om in een analysepakket en master measures en -dimensies worden vóór ruwe velden beoordeeld. Als je dat eenmaal weet, is de uitvoer van de redenering geen logbestand meer, maar een diagnosemiddel. Als de verkeerde meting is gekozen, ligt het probleem bij je beschrijving en niet bij de vraag. Elke verbetering in de rest van dit artikel kwam voort uit het lezen van die uitvoer en het terugredeneren naar de context die deze had veroorzaakt. 

Redenering van Qlik Answers. Belangrijke informatie is verwijderd. We gebruiken een reeks metingen waarvan de naam eindigt op TOTAL voor gebruik in aandeelmetingen: dezelfde berekening als bij de reguliere meting, maar dan met TOTAL in de expressie. In deze redenering scoort een van deze metingen hoog op overeenkomst. Precies daarom loont het om te controleren of in het logische model alleen de metingen beschikbaar zijn die AI daadwerkelijk mag gebruiken.  

Stap 4: Stel de vraag die een zakelijke gebruiker zou stellen 

Op dit punt stond de technische basis. De echte test is of iemand buiten het BI-team een antwoord kan krijgen. We probeerden een echte analytische vraag: 

“Jassen komen in verschillende seizoenen terug onder dezelfde Article Name. Een bepaalde jasnaam komt bijvoorbeeld voor in SEASON 25 en SEASON 24. Kun je dit analyseren en bepalen welke jassen het best zullen presteren in SEASON 26? Met ‘best’ bedoelen we de hoogste groei. Filter op [Article Season] <> CERTAIN VALUE. Relevante velden: Article BrandGroup, het merk van het seizoen. Season Year, het jaar van het seizoen. Block, het blok binnen het seizoen.” 

De resultaten waren goed. We kregen een lijst met jassen gerangschikt op groei en een tweede lijst die op dezelfde manier was opgebouwd. 

Kijk nu eens hoeveel informatie we in die prompt moesten opnemen. De prompt bevat veel ontwikkelaarskennis en details op veldniveau. Bovendien was deze korter dan we wilden: Qlik Answers beperkt een vraag tot 500 tekens, waardoor we woorden moesten schrappen om onder die limiet te blijven. Als er ruimte was geweest, hadden we meer uitgelegd. Als je de veldnamen moet kennen voordat je iets kunt vragen en je vraag vervolgens moet inkorten om in het invoerveld te passen, doet de tool zijn werk nog niet. Dat werd dus de volgende stap: er niet langer op vertrouwen dat degene die de vraag stelt het model kent, maar de dimensies beschrijven zoals we dat ook bij de metingen hadden gedaan. 

Stap 5: Beschrijf je masterdimensies 

We pasten dezelfde aanpak toe als bij de metingen. We beschreven elke dimensie, haalden de ruwe velden uit het datamodel weg uit het logische model en hielden alleen de masterdimensies beschikbaar. Zo dwing je Qlik Answers om te werken met de dimensies en metingen die je wilt laten gebruiken en blijft al het andere verborgen. Daarmee losten we ook het probleem met Date Order uit stap 3 op. Nu alleen de masterdatumdimensie nog beschikbaar is, is er geen vrijwel identiek ruw veld meer dat per ongeluk kan worden gekozen. We hoefden dus geen beschrijving te schrijven waarin we uitlegden welke van de twee de voorkeur had. De verkeerde optie verwijderen bleek minder werk dan deze beschrijven. 

Hiervoor geldt een vuistregel, en die is mechanischer dan je misschien denkt.

• Verberg de sleutelvelden
• Verberg de velden die je alleen binnen metingen gebruikt
• Verberg de vlagvelden

Laat de dimensievelden zichtbaar, want die heeft Qlik Answers nodig om de gegevens uit te splitsen. De voorbereidingsgids van Qlik wijst op dezelfde instelling: zet deze velden in het logische model onder Visibility op Hidden, of laat ze in het laadscript voorafgaan door % zodat ze automatisch worden verborgen. 

Dit heeft geen gevolgen voor je eindgebruikers. Het logische model bepaalt wat Qlik Answers mag zien, niet wat iemand in het dashboard kan selecteren en filteren. Als je daar een veld verbergt, neem je het bij niemand weg. 

De antwoorden werden opnieuw beter en Qlik Answers koos geen ruwe velden meer. Op dit punt zouden we zeggen dat de configuratie echt bruikbaar was: met voldoende aandacht voor de context en een vraag van iemand die het model kent, geeft Qlik Answers bruikbare antwoorden. Geen van beide voorwaarden kun je vanaf dag één van een zakelijke gebruiker verwachten. 

Waar het beter kan: de visualisaties 

Hier heeft Qlik Answers nog de grootste inhaalslag te maken. De juiste grafiek kiezen voor het verhaal dat je wilt vertellen is lastig, en dat kunnen we zeggen na jarenlang zelf grafieken te hebben gebouwd. Tijdens het testen zagen we genoeg visualisaties waarbij we ons afvroegen of ze de boodschap überhaupt overbrachten. 

Neem de onderstaande grafiek. Die kregen we als antwoord op deze vraag: 

“Ik wil de belangrijkste trends zien voor Article Season > CURRENT en PREVIOUS. Ik wil de verschillen per artikelcategorie. Gebruik de meetwaarde Sales EDI, specifiek Sales EDI Qty en Sales EDI Amount.” 

Als we naar het resultaat kijken, zien we twee keuzes voor de visualisatie die we niet zouden aanbevelen: 

• De bedragen in één kolom zetten. Zo verlies je elke basis voor vergelijking. 

• Een combinatiegrafiek. Over het nut daarvan in het algemeen kun je discussiëren, maar Qty op de secundaire as zetten en vervolgens ook in de balken opnemen, maakt het er niet beter op. 

Figuur 1: de grafiek zoals Qlik Answers die genereerde, met verwijderde labels en waarden om de gegevens van onze klant te anonimiseren  

Om eerlijk te zijn: je kunt het grafiektype in de vraag noemen en Qlik Answers bouwt wat je hebt gevraagd. Dit is dus geen kritiek op wat het kan, maar op wat het kiest. Het probleem zit in de standaardkeuze, en dat is wat een zakelijke gebruiker krijgt. Die weet doorgaans namelijk niet dat die om een gegroepeerd staafdiagram moet vragen. 

Met extra prompts kwamen we wel bij de juiste meetwaarde uit en konden we de juiste tabellen ophalen. De eerlijke conclusie: door het dashboard klikken was sneller geweest. 

Waar het beter kan: geen plek voor analysekennis 

Tegelijkertijd kunnen we niet alles in een prompt kwijt. We hebben sectorspecifieke concepten die we aan Qlik Answers probeerden uit te leggen, maar dat lukte niet. Om een dashboard goed te gebruiken, moet een AI leren hoe dat dashboard werkt. Dit is een breder probleem rond de semantische laag: AI heeft meer nodig dan toegang tot velden en meetwaarden, namelijk expliciete bedrijfsbetekenis en context. Hier schreven we meer over waarom de semantische laag een interface voor AI wordt.

Een voorbeeld: we bouwden een oplossing waarbij het selecteren van een waarde in een island-tabel een variabele wijzigt, en die variabele bepaalt of aantallen verpakt of onverpakt worden weergegeven. We hebben dit niet aan Qlik Answers kunnen uitleggen. Een tweede voorbeeld: alleen op echte artikelen filteren en grootboek- en promotieartikelen buiten beschouwing laten totdat je ze daadwerkelijk nodig hebt in de analyse. Ook dat kwam niet over. Standaardfilters zijn net zo belangrijk wanneer één dashboard meerdere kalenders bevat. 

We probeerden Qlik Answers ook naar een standaardbookmark te verwijzen, zodat je in elk geval weet dat het vanaf het juiste punt begint. In onze tests werd die bookmark niet opgepakt. 

Voor eindgebruikers bestaat die scheiding al in het dashboard. We dwingen die af met afzonderlijke werkbladen, elk met eigen filters, zodat een retouranalyse niet kan worden uitgevoerd met de instellingen die bij een voororder horen. Qlik Answers heeft geen equivalent. Elke analyse maakt gebruik van dezelfde ongedifferentieerde context. 

Wat we willen, is een korte AI-skillinstructie: hoe bepaalde stappen en analyses werken, welke velden je moet gebruiken en hoe een correct antwoord eruitziet. En niet één per dashboard, maar één per analyse. Een retouranalyse draait op hetzelfde dashboard als een voororderanalyse of een nabestelanalyse, en alle drie hebben ze andere instructies nodig: andere standaardfilters, andere meetwaarden en een ander beeld van hoe een correct antwoord eruitziet. Dat ontbreekt, en zonder die instructies kan een gebruiker niet betrouwbaar tot goede antwoorden komen. 

Het oordeel 

Hoe krijg je dan correcte en consistente antwoorden uit Qlik Answers?

Alles wat voor ons werkte, kwam neer op het vastleggen van wat mensen al wisten: meetwaarden in het logische model, beschrijvingen bij meetwaarden en dimensies, en standaardfilters die ervoor zorgen dat elke vraag vanuit hetzelfde uitgangspunt wordt gesteld. Dat laatste is belangrijker dan het klinkt, omdat een eindgebruiker zo een antwoord kan controleren aan de hand van het dashboard dat die al gebruikt. Zonder die controle zal de gebruiker het antwoord niet vertrouwen. 

Wat ontbreekt, is een plek voor de rest van die kennis. We willen één skillinstructie per analyse, niet per dashboard: de standaardfilters, de relevante meetwaarden, hoe de logica voor verpakt en onverpakt werkt en welke artikeltypen je moet uitsluiten. Een retouranalyse en een nabestelanalyse gebruiken hetzelfde model, maar volgen verschillende regels. Op dit moment moet die kennis óf in elke afzonderlijke prompt worden opgenomen, óf kan die nergens worden vastgelegd. Bookmarks hadden een tijdelijke oplossing kunnen zijn, maar werden in onze tests niet opgepakt. 

Dat brengt ons terug bij de tabel bovenaan dit artikel. De nauwkeurigheid ging daar van 0% naar 92% zonder het model ook maar één keer te wijzigen, en onze ervaring sluit daarbij aan: elke verbetering die we bereikten, kwam door betere context en niet door een betere engine. Daarom blijven we bij ons punt, maar dan scherper geformuleerd: het model is belangrijk, maar de context is bepalend.

Hetzelfde principe geldt ook buiten Qlik Answers. Betrouwbare AI-analytics begint bij de onderliggende data, metadata en context. Hier gaan we verder in op die bredere datafundering voor AI-analytics.

Trek dit breder dan alleen deze tool. Of je volgend kwartaal vragen aan AI gaat stellen of besluit dat nooit te doen, het werk dat voor je ligt blijft hetzelfde: breng je datakwaliteit op orde en leg de context vast die nu alleen in de hoofden van mensen zit. Elk model dat hierna komt, heeft precies dat nodig. En ook als je er nooit een AI op loslaat, is die inspanning niet voor niets geweest, want dit is dezelfde documentatie die je eigen collega’s al jaren missen. Onze ervaring is dat organisaties juist dit onderdeel uitstellen, terwijl het bepaalt of dit alles werkt.

Wil je zien wat Qlik Answers met je eigen omgeving kan?
We kunnen je helpen om je Qlik-model, logische model, meetwaarden en semantische context te beoordelen en vast te stellen wat er moet veranderen om analytics met ondersteuning van AI betrouwbaarder te maken.

> Praat met onze Qlik-consultants

Waar kan Qlik Answers nog verbeteren?

Maar we moeten net zo eerlijk zijn over de andere kant. Als wat we hier hebben getest twee jaar geleden de stand van zaken was geweest, waren we onder de indruk geweest. Bovendien testten we niet simpelweg een prille eerste release. Afgezet tegen wat andere modellen tegenwoordig kunnen en hoe ze vaardigheden combineren, schiet het tekort. De redenering die het laat zien is echt goed, beter dan wat de meeste tools je bieden, en juist daardoor konden we onze eigen context überhaupt debuggen. De visualisatiekeuzes zijn nog niet goed genoeg, en ook ontbreekt de mogelijkheid om het te leren hoe een specifiek dashboard werkt. 

Zou ik het aanbevelen?

Als je data in de EU moet blijven, is Qlik Answers een redelijke keuze en we verwachten zeker dat het beter zal worden. Maar koop het niet in de verwachting dat het werk aan de context verdwijnt. Dat werk is juist de kern. De tool maakt alleen heel duidelijk of je het hebt gedaan.