AI-geletterdheid bij Codifly

Dit document bevat de verplichte kennisbasis voor alle medewerkers van Codifly.

Je hoeft geen ontwikkelaar te zijn om het te begrijpen. Bij Codifly gebruiken we twee AI-tools: Claude Desktop voor bureaumedewerkers en Claude Code voor developers. Uit de context wordt doorgaans duidelijk wat voor wie relevant is.

1. De juridische context: de AI Act begrijpen

1.1. Wat en waarom?

In mei 2024 keurde de Europese Unie de AI Act (Verordening EU 2024/1689) goed, het eerste uitgebreide alomvattende rechtskader voor AI ter wereld. Het is van kracht sinds augustus 2024 en wordt gefaseerd van toepassing, met de meest ingrijpende bepalingen tegen 2026–2027.

Het voornaamste doel van de AI Act is om vertrouwde, veilige en ethische AI-systemen te bevorderen in de EU. De AI Act geldt voor organisaties die AI-systemen ontwikkelen, verkopen of gebruiken binnen de Europese Unie.

1.2. Risicoklassificatie

De AI Act wil risico's m.b.t. AI-systemen voorkomen zonder innovatie te blokkeren. Om die reden wordt gewerkt met een risicogebaseerde aanpak: hoe meer schade een toepassing kan aanrichten, hoe strenger de eisen: "slimme" medische diagnoses houden andere risico's in dan een "slim" recommendatiesysteem in een streamingdienst.

Risicogebaseerde aanpak

Bron: de Europese Commissie

1. Verboden praktijken (art. 5). Toepassingen met een onaanvaardbaar risico zijn opgenomen in de lijst van verboden praktijken. De verboden zijn absoluut en niet onderhandelbaar, ook niet voor onderzoek.

Voorbeelden: subliminale manipulatie, sociale scoring door overheden, biometrische identificatie in real time door rechtshandhaving, emotieherkenning op de werkvloer of in het onderwijs (met zeer beperkte uitzonderingen).

2. Hoog-risico AI (art. 6-49 + Bijlage III). Bijlage III geeft een lijst van typische toepassingen die automatisch als hoog-risico gelden. Als we AI integreren in een project voor een klant, toetsen we het beoogde gebruik af tegen deze Bijlage III.

Classificatie als hoog-risico AI kan daarnaast ook ontstaan wanneer AI een veiligheidscomponent vormt van een gereguleerd product, zoals een medisch toestel, voertuig of machine. Bijlage III is dus geen exhaustieve lijst.

Voorbeelden: kritieke infrastructuur, onderwijs, arbeidsmarkt (aanwerving, ontslag, promotie), kredietverlening, rechtshandhaving, asiel, rechtsbedeling.

Praktisch voorbeeld: een klant vraagt een AI-tool die automatisch CV’s analyseert en kandidaten rangschikt. Omdat het systeem wordt gebruikt bij aanwerving, valt dit onder hoog-risico AI volgens Bijlage III van de AI Act.

Voor hoog-risicotoepassingen gelden uitgebreide verplichtingen: technische documentatie, risicobeheersysteem, menselijk toezicht, conformiteitsbeoordeling, registratie in EU-database, ...

3. Beperkt risico (art. 50). Voor dit soort systemen gelden enkel de transparantieverplichtingen van de AI Act.

Voorbeeld: chatbots moeten zichzelf identificeren als AI en Deepfakes moeten als zodanig worden gelabeld.

4. Minimaal risico. In principe geen regulering vanuit de AI Act.

Voorbeelden: spamfilters, AI-functies in games, spellingcorrectie.

1.3. Structuur van de AI Act

De AI Act telt 13 hoofdstukken en 180 artikelen. We hoeven niet allemaal juristen te worden, maar het is belangrijk om de voornaamste hoofdstukken te kennen: plots worden de meer dan honderd pagina's artikelen beheersbaar. Eigenlijk valt het, meestal, best mee!

Voor Codifly zijn de volgende onderdelen het meest relevant:

Hoofdstuk	Inhoud
Hfst. I - Algemene bepalingen (art. 1–4)	Toepassingsgebied en definities.
Hfst. II - Verboden praktijken (art. 5)	Absolute verboden AI-praktijken die fundamenteel onverzoenbaar zijn met de kernwaarden van de EU. No exceptions!
Hfst. III - Hoog-risico AI (art. 6–49)	Bijlage III geeft aan wanneer een AI-systeem een hoog-risico systeem is, hoofdstuk 3 bevat de vele vereisten en beperkingen voor deze toepassingen van AI.
Hfst. IV - Transparantie (art. 50)	Transparantieverplichtingen van toepassing bij alle soorten AI (niet beperkt tot hoog-risico AI).
Hfst. V - GPAI-modellen (art. 51–56)	Maatregelen ter regulering van de nu heel goed gekende general-purpose AI-modellen (GPAI), zoals OpenAI's GPT-4 of Anthropic's Claude.
Hfst. XII - Sancties (art. 99–101)	Boetes tot €35 miljoen of 7% van de wereldwijde jaaromzet voor verboden praktijken; tot €15 miljoen of 3% voor overige overtredingen.

1.4. Actoren: wie is wie?

De AI Act definieert verschillende rollen, elk met eigen verplichtingen. Codifly kan naargelang het project in verschillende rollen optreden, soms zelfs meerdere tegelijk.

Rol	Definitie	Voorbeeld in Codifly-context
Aanbieder (provider)	Ontwikkelt een AI-systeem (of laat het ontwikkelen) en brengt het op de markt of in gebruik onder eigen naam.	Codifly bouwt een AI-module voor een klant en levert die op: tijdens development en oplevering is Codifly aanbieder, na oplevering en mits contractueel vastgelegd is de klant dit.
Gebruiksverantwoordelijke (deployer)	Zet een AI-systeem van een andere aanbieder in, voor eigen doeleinden.	Codifly gebruikt Claude (van Anthropic) in haar interne werking.
Importeur (importer)	Brengt een AI-systeem van buiten de EU op de Europese markt.	Zelden van toepassing voor Codifly.
Distributeur (distributor)	Stelt een AI-systeem van een andere partij beschikbaar zonder het te wijzigen.	Codifly resellt, zonder het te wijzigen, een AI-oplossing van een derde partij aan een klant.
Getroffen persoon (affected person)	De natuurlijke persoon op wie het AI-systeem inwerkt of wiens data worden gebruikt.	De eindgebruiker of werknemer wiens gegevens in het systeem zitten.

Het is belangrijk stil te staan bij de term "getroffen persoon": dit is niet beperkt tot de gebruiker van het AI-systeem. Bij een AI-systeem dat bijvoorbeeld gebruikt wordt bij autonoom rijden is de getroffen persoon niet alleen de chauffeur. Ook passagiers, voetgangers, fietsers en andere weggebruikers kunnen als getroffen persoon worden beschouwd, omdat beslissingen van het systeem een impact kunnen hebben op hun veiligheid.

1.5. AI-systemen vs AI-modellen

Een bijzondere categorie in de AI Act is die van General-Purpose AI-modellen (Hfst. V AI Act). Dit zijn grote AI-modellen die getraind zijn op omvangrijke datasets en die voor een breed scala aan taken kunnen worden ingezet. Denk hierbij aan GPT-4 en Claude, gebouwd door respectievelijk de aanbieders OpenAI en Anthropic.

Voor alle duidelijkheid: de AI Act maakt onderscheid tussen AI-systemen en GPAI-modellen.

Een GPAI-model is een AI-model dat voor een breed scala aan toepassingen kan worden gebruikt. Het betreft dus de onderliggende technologie (bv. GPT-4, Claude).
Een AI-systeem is een concrete toepassing waarin zo’n model wordt gebruikt.

De AI Act legt de zwaarste verplichtingen op aan de aanbieders van deze modellen. Anthropic (de maker van Claude) is bijvoorbeeld een GPAI-aanbieder en moet voldoen aan verplichtingen rond technische documentatie, auteursrechtbeleid, trainingstransparantie en, voor de krachtigste modellen, aanvullende veiligheidsbeoordelingen. Codifly als gebruiker heeft anderzijds vooral verplichtingen inzake correct gebruik, geen verboden toepassingen, transparantie en toezicht.

Codifly zal meestal AI-systemen bouwen bovenop bestaande modellen. Voorbeeld: een klantenservice-chatbot die Codifly voor een klant bouwt met het GPT-4 model is een AI-systeem.

Bemerk wel:

Als Codifly Claude gebruikt als tool, zijn we gebruiksverantwoordelijke, niet GPAI-aanbieder. Onze verplichtingen volgen uit die rol: correct gebruik, geen verboden toepassingen, transparantie en toezicht.
Wanneer Codifly echter een AI-systeem bouwt op basis van een GPAI-model, treedt Codifly op als aanbieder van een AI-systeem, met de bijhorende verplichtingen. Na overdracht naar de klant en mits contractueel vastgelegd, is de klant aanbieder van dat AI-systeem.

2. Wat is AI, machine learning en generatieve AI?

We gaan opbouwen van klassieke software naar de fancy ChatGPT's die we dagdagelijks gebruiken. It’s going to be a bumpy ride!

2.1. Klassieke software vs. AI

Klassieke software werkt op basis van expliciete regels die een programmeur heeft vastgelegd. Als je een factuurprogramma schrijft, beschrijf je exact: "als bedrag > 1000, pas korting X toe, anders korting Y". Het programma doet precies wat er staat; niet meer, niet minder. Dat is voorspelbaar en controleerbaar, maar ook rigide: voor elke nieuwe situatie moet iemand een nieuwe regel schrijven.

Artificiële intelligentie (AI) is het brede vakgebied dat alles omvat waarbij computers taken uitvoeren waarvoor normaal menselijke intelligentie nodig is.

Binnen dat vakgebied bestaat een belangrijk subdomein: machine learning (ML). In plaats van regels te schrijven, leer je het systeem patronen te herkennen uit voorbeelddata. Je geeft het duizenden voorbeelden van facturen met en zonder kortingen, en het systeem leert zelf de onderliggende logica. Dat maakt AI flexibel: het kan omgaan met situaties die je op voorhand niet hebt voorzien. Maar het maakt het ook minder transparant: je weet soms niet meer waarom het systeem een bepaalde beslissing neemt. Bovendien zijn fouten bij machine learning moeilijker te voorspellen/auditen dan bij klassieke software.

	Klassieke software	Machine learning
Hoe werkt het?	Expliciete regels door mensen geschreven	Patronen geleerd uit voorbeelddata
Sterktes	Voorspelbaar en controleerbaar	Flexibel (schaalt naar complexe taken)
Zwaktes	Rigide (breekt bij onvoorziene situaties)	Onvoorspelbare fouten, moeilijk te voorspellen/auditen
Voorbeeld	Belasting berekenen, sorteren	Beeldherkenning, vertaling, chatbots

Binnen machine learning bestaat het subdomein deep learning, dat werkt met artificiële neurale netwerken: computationele structuren die losjes geïnspireerd zijn op de werking van het menselijk brein (al gaat die analogie maar beperkt op). Wat deep learning bijzonder krachtig maakt, is dat het automatisch abstracte kenmerken leert. Als je een neuraal netwerk wil trainen om katten te herkennen op foto's, hoef je niet zelf te definiëren wat een kat is: het netwerk leert zelf, via miljoenen voorbeelden, dat katten oren hebben, snorharen, een bepaalde textuur. Dat maakt deep learning uitermate geschikt voor complexe, ongestructureerde data zoals beelden, geluid en tekst.

2.2. Taalmodellen en generatieve AI

Een specifieke toepassing van deep learning zijn grote taalmodellen (Large Language Models of LLM's). Ze zijn getraind op enorme hoeveelheden tekst (boeken, websites, code, wetenschappelijke artikelen, ...) en hebben geleerd hoe taal in elkaar zit: welke woorden vaak samen voorkomen, hoe zinnen zijn opgebouwd, welke concepten samenhangen.

Laat één ding alvast duidelijk zijn: die LLM's die ons zo goed lijken te begrijpen, verstaan geen knars van wat we zeggen. Ze werken louter op basis van patronen en wat statistiek; ze hebben geen enkel bewustzijn of begrip.

Op basis van hun training kunnen LLM's nieuwe tekst genereren die coherent en contextrelevant is. Dat is de kern van generatieve AI: AI die nieuwe inhoud produceert (tekst, code, beelden, audio, ...) op basis van een prompt.

2.3. GPAI-modellen

De LLM's uit de vorige sectie zijn een specifiek type van een bredere categorie: GPAI-modellen (ook wel foundation models). Een GPAI-model is een zeer groot model getraind op brede, gevarieerde data dat als basis dient voor een breed scala aan toepassingen, niet enkel taal, maar ook beeld, audio of code.

Het model zelf is generiek, het is het fundament. Bovenop dat fundament kun je specifieke toepassingen bouwen door het model te verfijnen voor een bepaald domein (finetuning) of door het de juiste instructies te geven (prompt engineering). GPT-4, Claude en Gemini zijn voorbeelden van GPAI-modellen.

Analogie: een GPAI-model is als een elektriciteitsnet. Je bouwt het niet zelf, maar je sluit er apparaten op aan. De kwaliteit van het net bepaalt mee wat je kunt doen, maar je bent zelf verantwoordelijk voor hoe je het gebruikt.

Voorbeelden: ChatGPT is gebouwd op het GPAI-model GPT-4. Claude.ai, Claude Desktop en Claude Code zijn gebouwd op het GPAI-model Claude. Gemini is gebouwd op het gelijknamige model Gemini. Allen zijn voorbeelden van generatieve AI-toepassingen gebouwd op LLM's: het zijn simpelweg chatinterfaces bovenop die LLM's.

3. Hoe AI-modellen werken

Je hoeft de wiskunde niet te begrijpen om AI-tools verantwoord te gebruiken. Maar een conceptueel begrip van hoe modellen werken helpt je beter inschatten wanneer je ze kan vertrouwen en wanneer niet.

3.1. Afsluitdatum en bias

Een AI-model leert van data. Hoe meer data, en hoe gevarieerder, hoe beter het model doorgaans presteert. Een groot taalmodel als Claude is getraind op honderden miljarden woorden tekst uit het internet, boeken, code en wetenschappelijke publicaties.

Trainingsdata heeft echter een afsluitdatum. Claude weet niets van gebeurtenissen die plaatsvonden nadat zijn training werd afgesloten. Vraag je naar de meest recente wetgeving of de nieuwste versie van een npm-package, dan is het model beperkt tot wat het weet. Het zal je dat bovendien niet altijd uit zichzelf vertellen.

Tip: je kan Claude instrueren van online te zoeken. Het zal dan via een web search een aantal bronnen binnentrekken.

Bovendien weerspiegelt trainingsdata de wereld zoals die is, inclusief haar vooroordelen en blinde vlekken. Als een dataset overwegend Engelstalige tekst bevat, presteert het model minder goed in andere talen. Als historische data discriminerende patronen bevat, kan het model die patronen overnemen. Dat is bias, en het is een structureel risico van elk ML-systeem.

3.2. Training en inference

Tijdens de training past het model zijn interne parameters (gewichten) aan op basis van de voorbeelden die het ziet. Het krijgt een stuk tekst, doet een voorspelling over wat het volgende woord is, vergelijkt dat met het juiste antwoord, en past zijn gewichten aan om de fout te verkleinen. Dit proces herhaalt zich miljarden keren.

Na afloop is het model niet meer aan te passen aan nieuwe informatie (met uitzondering van de eerder vermelde finetuning), tenzij je het opnieuw traint. Dat is het verschil tussen training en inference: training is het leerproces, inference is het gebruik in de praktijk. Wanneer je een prompt geeft aan Claude, voer je een inference-stap uit: het model past zijn geleerde kennis toe op jouw vraag, zonder iets nieuws te leren.

Praktijk: Claude leert dus niets bij van gesprekken die jij met hem voert. Hij onthoudt niets tussen verschillende gesprekken.

3.3. Probabilistische uitvoer

Generatieve AI-modellen produceren probabilistische uitvoer. Dat betekent: ze berekenen niet één correct antwoord, maar een kansenverdeling over mogelijke volgende woorden. Het model kiest dan, met een zekere mate van willekeur, uit de meest waarschijnlijke opties.

Die willekeur is instelbaar via de temperatuurparameter: lager maakt het model voorspelbaarder, hoger maakt het creatiever (maar ook sneller geneigd tot fouten).

Praktijk: Claude Code maakt de temperatuur niet instelbaar, het is voorgeprogrammeerd met een lage temperatuur om deterministisch en conservatief gedrag te vertonen tijdens codegeneratie. Ook bij Claude.ai en Claude Desktop is de temperatuur niet instelbaar. Als je als ontwikkelaar echter zelf AI-toepassingen maakt met gebruik van een GPAI-model (bv. met Claude API), kan je doorgaans zelf de temperatuur meegeven.

Dit heeft twee praktische gevolgen. Ten eerste is AI-output niet-deterministisch: stel dezelfde vraag twee keer en je krijgt twee verschillende antwoorden. Ten tweede is het model geoptimaliseerd voor plausibele tekst, niet voor correcte tekst. Die twee vallen niet altijd samen.

3.4. Hallucinaties

Hallucinaties zijn misschien wel de gevaarlijkste eigenschap van generatieve AI voor dagelijks gebruik. Het model verzint informatie, niet bewust, maar als gevolg van zijn architectuur.

Het probleem is dat hallucinaties niet te onderscheiden zijn van correcte antwoorden op basis van de toon of het zelfvertrouwen van de output. Het model drukt zich even zeker uit over zaken die het weet als over zaken die het verzint.

Hallucinaties komen doordat het model heeft geleerd tekst te genereren die coherent en contextueel passend is, in tegenstelling tot tekst die feitelijk correct is. Als er een gat zit in zijn kennis, vult het dat niet op met "ik weet het niet", maar met iets dat past bij de stijl en structuur van het gevraagde antwoord. Daarbij komt dat modellen zijn getraind om behulpzaam te zijn. Een antwoord geven voelt beter aan dan een gat laten. Die optimalisatie maakt hallucinaties waarschijnlijker.

Praktijk: je vraagt Claude naar een Belgisch hogeraadarrest over een specifiek onderwerp. Als dat arrest niet prominent in zijn trainingsdata zat, heeft Claude toch een sterke neiging om iets plausibels te genereren. Hij kent de structuur van juridische verwijzingen, hij weet hoe arresten worden geciteerd, en hij bouwt iets dat klinkt als een correct citaat, geheel verzonnen. Dossienummer, datum, partijen: allemaal coherent maar allemaal volledig fictief.

Voorbeeld:

3.5. Context window

Aangezien Claude niets leert van gesprekken die je met hem voert, start elk gesprek (= sessie) opnieuw van een wit blad. We gaan even verder in termen van Claude, maar het onderstaande is ook breder van toepassing.

Ook binnen een sessie heeft Claude geen geheugen in de menselijke zin, noch een oneindig geheugen. Wat hij wel heeft, is een context window: een soort werkgeheugen dat alles bevat wat hij op dat moment kan "zien" wanneer hij een prompt ontvangt.

Zolang het gesprek kort is, bevat het het volledige gesprek vanaf het begin. Het context window heeft echter een limiet, uitgedrukt in tokens (ruwweg een viertal tekens). Wanneer het gesprek de limiet nadert, moeten dingen weg. Dit kan op 2 manieren:

Truncation: de oudste berichten worden gewoon weggegooid. Claude "vergeet" letterlijk het begin van het gesprek.
Compaction: een samenvatting van oudere delen vervangt de originele berichten. Er gaat minder verloren, maar nuance en exacte formuleringen verdwijnen wel.

In beide gevallen weet Claude zelf niet altijd wat hij niet meer weet. Hij werkt verder op basis van wat er nog in zijn context zit, zonder te signaleren dat er informatie ontbreekt.

Praktijk: bij lange gesprekken, zeker bij complexe of technische taken, neemt de kwaliteit van de uitvoer geleidelijk af. Instructies die vroeg in het gesprek werden gegeven, kunnen "wegglijden". Wanneer je merkt dat Claude zichzelf begint tegen te spreken of vroegere afspraken vergeet, is een nieuw gesprek met een frisse context vaak effectiever dan blijven verder gaan: dat laatste kan serieus op je zenuwen beginnen werken.

4. Prompting

Prompten is het formuleren van instructies of vragen aan een AI-model. Het klinkt triviaal (je typt iets, je krijgt een antwoord), maar de kwaliteit van je input bepaalt grotendeels de kwaliteit van je resultaat. Een slecht geformuleerde prompt geeft een vaag, generiek of gewoon fout antwoord. Een goede prompt geeft je precies wat je nodig hebt (althans, misschien, zoals je intussen weet).

Voor te prompten gebruiken we bij Codifly primair twee tools:

Claude Desktop: de chatinterface voor bureaumedewerkers, vergelijkbaar met ChatGPT maar dan met Claude.
Claude Code: de tool voor developers, beschikbaar in twee smaken:
als CLI-commando (claude in de terminal), voor autonome taken zoals refactoring, codegeneratie en probleemoplossing over meerdere bestanden heen;
als VS Code-extensie, geïntegreerd in de editor.

Beide tools draaien op het Claude-model van Anthropic. Dat model bestaat in twee belangrijke varianten: Claude Sonnet en Claude Opus. Sonnet is snel, kostenefficiënt en geschikt voor dagelijks gebruik. Opus is het krachtigste model maar ook aanzienlijk duurder. Het is niet bedoeld voor alledaagse taken, maar voor complexe problemen die echt dat extra denkvermogen vragen. Verwacht echter niet dat Opus plots in staat zal zijn juridische teksten op te stellen die geen supervisie vragen: zelfs de krachtigste modellen zijn gevoelig voor hallucinaties en bias.

4.1. De anatomie van een goede prompt

Een goede prompt bevat doorgaans vijf elementen:

Element	Vraag die je beantwoordt	Voorbeeld
Rol	Wie is het model in deze context?	`Je bent een senior backend developer.`
Context	Wat is de situatie of achtergrond?	`We werken met Prisma en RDS (PostgreSQL) op een Node.js monorepo. Migraties staan in ./migrations`
Doel	Wat moet het resultaat bereiken?	`Ik wil begrijpen waarom deze query traag is.`
Criteria	Waar moet het antwoord aan voldoen?	`Focus op databaseindexen, negeer applicatielaag.`
Outputstructuur	In welk formaat wil je het antwoord?	`Geef een genummerde lijst van oorzaken, daarna één aanbeveling.`

Template: Je bent [rol]. [Context]. Analyseer/schrijf/los op [object] voor [doel]. Focus op [criteria]. Geef output als [structuur].

Het is verstandig steeds over elk van de elementen na te denken, maar je hoeft niet altijd alle vijf de elementen te vermelden: soms is de context zo duidelijk dat één of twee elementen volstaan.

Praktisch voorbeeld voor een developer:

Je bent een senior TypeScript developer. We gebruiken tRPC v11 met Zod-validatie. Ik krijg een runtime error op onderstaande procedure maar geen compile-time fout. Analyseer wat er misgaat en waarom Zod dit niet opvangt. Geef eerst de oorzaak, dan de fix, dan een korte uitleg waarom die fix helpt.

Praktisch voorbeeld voor een sales-medewerker:

Je bent een ervaren IT-accountmanager. Een prospect heeft onze offerte ontvangen maar reageert al twee weken niet. Schrijf een opvolgmail die niet opdringerig klinkt maar wel een concrete call-to-action bevat: ik wil een afspraak plannen. Maximaal 100 woorden, professioneel maar warm van toon.

4.2. Het belang van context (en de gevaren van Claude Code)

Een model weet niets over jou, je project of je bedoeling. Hoe meer relevante context je geeft, hoe beter het resultaat. Hoe zou je als mens reageren in volgende twee scenario's?

Praktisch voorbeeld voor een designer:

Slecht: Geef feedback op mijn ontwerp.

Beter: Dit is een onboardingscherm voor een B2B SaaS-tool. De doelgroep zijn niet-technische HR-medewerkers. Geef feedback op leesbaarheid en hiërarchie.

Bemerk dat, wanneer je Claude Code gebruikt via de VS Code-extensie, het model automatisch meer context krijgt dan bij een gewone chatprompt. Je hoeft dit niet handmatig mee te geven:

Geopende bestanden. Claude weet welke bestanden je op dat moment open hebt staan.
Geselecteerde code. Markeer je een stuk code voor je je prompt typt, dan wordt die selectie automatisch als context meegegeven. Je hoeft niet te kopiëren en plakken.
Diagnostische informatie. Linter-fouten en waarschuwingen (de rode en gele kronkellijntjes) zijn zichtbaar voor Claude. Je kan letterlijk zeggen "fix de linting errors in dit bestand" zonder verdere uitleg.
De volledige codebase. Claude Code kan zelfstandig door je project navigeren en bestanden lezen die je niet expliciet hebt geopend. Dit is handig, maar ook een gevaar: bepaalde informatie mag, overeenkomstig onze AI policy, nooit worden ingevoerd in AI-tools.
CLAUDE.md. Dit is een Markdown-bestand in de root van je project dat Claude Code bij elke sessie inlaadt. Hierin zet je essentiële context: projectconventies, architectuurbeslissingen, veelgebruikte commando's, ...

Praktisch gevolg: bij Claude Code zijn je prompts typisch korter dan bij een chatinterface zoals Claude Desktop, omdat veel context al impliciet aanwezig is. Het blijft echter verstandig om gericht na te denken over eventuele extra context bij elke prompt. Het is verder een must na te denken over zaken die nooit ingevoerd mogen worden en zo nodig maatregelen te nemen.

4.3. Het belang van een rol

Je kan het model expliciet een rol geven. Dat stuurt de toon, het niveau en de focus van het antwoord. Het helpt het model om de juiste registers aan te spreken en onnodige algemeenheden te vermijden.

Praktisch voorbeeld voor een developer:

Jij bent een senior backend developer met expertise in Node.js en security. Review onderstaande code en geef feedback vanuit een security-perspectief. Geef je feedback als een geordende lijst van bevindingen, van hoog naar laag risico.

Praktisch voorbeeld voor een kantoormedewerker:

Je bent een HR-verantwoordelijke. Schrijf een korte aankondiging voor het hele team over de nieuwe procedure voor onkostennota's: bonnetjes moeten voortaan digitaal ingediend worden via Officient, uiterlijk de 24ste dag van elke maand. Een bewijsstuk blijft noodzakelijk. Toon is informeel maar duidelijk. Aanspreking en slotgroet voeg ik zelf toe.

4.4. Specificeer het gewenste formaat

Als je weet welk formaat je wil, vraag er dan expliciet naar. Modellen geven anders standaard een lopende tekst, vaak met bullets en headers.

Voorbeelden:

Geef me een tabel met kolommen: techniek, voor- en nadelen, geschikt voor.

Geef me enkel de code, geen uitleg.

Vat samen in maximaal drie zinnen.

Geef me een stap-voor-stap handleiding, genummerd. Markdown graag.

Het formaat is extra belangrijk bij Claude Desktop: geef aan of je een Word-bestand wilt, dan wel of Markdown voldoende is: dat laatste gaat véél sneller.

4.5. Few-shot prompting: geef voorbeelden

Een krachtige techniek is het meegeven van voorbeelden van wat je wil. Dit heet few-shot prompting: je geeft het model in enkele representatieve voorbeelden (shots) van het gewenste resultaat, zodat het model het patroon kan volgen. Deze techniek werkt heel goed bij: tekstclassificatie, data-extractie en het afdwingen van een schrijfstijl of formaat.

Tekstclassificatie: je wil dat het model items in categorieën indeelt volgens jouw logica, niet de zijne.

Voor een office manager:

Classificeer binnenkomende mails in één van deze categorieën: Factuur, Levering, Technisch probleem, Algemeen.

Voorbeelden:

'Ik heb mijn factuur van maart nog niet ontvangen.' → Factuur

'Mijn pakket is al vijf dagen onderweg maar nog niet aangekomen.' → Levering

'Ik kan niet inloggen op het portaal.' → Technisch probleem

Classificeer nu: 'Kunnen jullie de betalingstermijn op onze volgende factuur aanpassen naar 60 dagen?'

Data-extractie: je wil dat het model gestructureerde informatie haalt uit ongestructureerde tekst, in een formaat dat jij bepaalt.

Voor een office manager:

Extraheer de relevante gegevens uit onderstaande e-mails en geef ze terug als een tabel met kolommen: Afzender, Datum vergadering, Locatie, Actie vereist.

Voorbeeld:

E-mail: 'Dag Sarah, kan je volgende dinsdag 14 maart om 10u langskomen op ons kantoor in Gent? We willen de samenwerking bespreken.' → Sarah | 14 maart | Gent | Vergadering bevestigen

Verwerk nu deze e-mail: 'Hallo, graag nodigen we jullie uit op 22 april om 9u in onze Brussels office voor de kick-off. Gelieve aanwezigheid te bevestigen voor 15 april.'

Schrijfstijl of formaat afdwingen: je wil dat het model communiceert in jouw tone of voice, niet in een generieke AI-toon.

Voor een office manager:

Herschrijf onderstaande interne berichten in onze huisstijl: kort, vriendelijk, actiegericht, geen corporate gedoe.

*Origineel: 'Wij willen u erop attent maken dat het gebruik van de gemeenschappelijke keuken gepaard dient te gaan met het naleven van de reinigingsvoorschriften.'*

*Herschreven: 'Vergeet de keuken niet proper achter te laten na gebruik. Merci!'*

Herschrijf nu: 'In het kader van de optimalisatie van onze interne communicatieprocessen verzoeken wij u vriendelijk doch dringend uw afwezigheden tijdig te melden aan de betrokken teamverantwoordelijke.'

4.6. Chain-of-thought: laat het model redeneren

Voor complexe taken loont het om het model expliciet te vragen zijn redenering te tonen voor het tot een conclusie komt. Dit verbetert de kwaliteit van het antwoord aanzienlijk: het model "denkt harder na" (laat je niet vangen door deze verwoording) en slaat minder stappen over.

Voor legal:

Analyseer of dit contract een aansprakelijkheidsbeperking bevat. Redeneer stap voor stap voor je een conclusie trekt.

Voor de project manager:

Bereken de geschatte kostprijs van dit project. Denk hardop: welke componenten zijn er, hoeveel uren per component, en wat is het uurtarief?

Praktisch voor developers:

Ik wil een caching-strategie kiezen voor onze tRPC-endpoints. Denk stap voor stap: wat zijn de opties, wat zijn de trade-offs voor onze usecase (veel lees-, weinig schrijfoperaties), en wat zou je aanbevelen?

Hier wil ik ook direct de gelegenheid grijpen om de Claude planmodus te introduceren. Via die modus analyseert Claude de vraag en de situatie en werkt het een stappenplan ter implementatie uit. Tijdens het plannen draait Claude, met achterliggend de "think before doing"-filosofie, in read-only modus. Wijs!

Plan mode

4.7. Itereer in plaats van te herschrijven

De chatinterface die ons toegang geeft tot GPAI-modellen onthoudt de eerdere conversatie (prompts en antwoorden) in de context. Behandel het prompten dus niet als eenmalige actie maar als een gesprek: begin met een eerste versie, bekijk het resultaat, en stuur bij.

Effectieve bijsturingen:

Maak dit formeler.
De tweede alinea klopt niet, pas die aan: [uitleg].
Goed, maar voeg ook een risicosectie toe.
Te lang. Schrap alles wat niet essentieel is.

4.8. Verificeer kritieke output altijd

Dit sluit aan bij wat je al weet over hallucinations en bias: een model klinkt altijd zelfzeker, ook als het fout is. Gebruik AI als een slimme assistent, niet als een orakel.

Praktische vuistregel: hoe hoger de impact van de output, hoe meer je zelf verifieert.

Voorbeelden:

Juridische clausule formuleren? Altijd door een mens met domeinkennis laten valideren.
Financiële berekening voor een offerte? Nakijken en narekenen.
Broncode voor een interne tool? Zelf reviewen.
Spreuk voor op toilet: misschien is nakijken hier niet nodig ;)

Controleer in ieder geval bronvermeldingen: AI kan ze behoorlijk uit zijn duim zuigen.

5. Verantwoord gebruik in de praktijk

De vorige secties gaven je de juridische, technische en praktische achtergrond. Deze sectie vertaalt dat naar wat het concreet betekent voor jouw dagelijks werk.

5.1. Jij blijft verantwoordelijk

AI-output is input voor jouw werk, geen vervanging ervan. Je blijft persoonlijk verantwoordelijk voor alles wat je oplevert, ook wanneer het (deels) door AI is gegenereerd. "Claude heeft dat geschreven" is geen verweer: niet intern, niet naar een klant, niet juridisch.

5.2. Gebruik uitsluitend goedgekeurde tools

Je mag enkel AI-tools gebruiken die door Codifly zijn goedgekeurd. De lijst staat in de geldende AI-policy. Het op eigen initiatief installeren of gebruiken van niet-goedgekeurde tools (ook gratis versies, browser-extensies of IDE-plugins) is niet toegestaan.

Waarom is dit zo strikt? Wanneer een medewerker op eigen houtje een AI-tool installeert en gebruikt, verliest Codifly de controle over een hele reeks risico's tegelijk:

Dataverwerking zonder toezicht. Prompts en code worden naar een extern platform gestuurd. Worden ze gebruikt voor modeltraining? Wie heeft er toegang? Codifly weet het niet.
Schending van geheimhoudingsovereenkomsten. Klantcode, projectinformatie of vertrouwelijke bedrijfsdata kan zo een externe server bereiken zonder dat de klant of Codifly het weet. Dit kan leiden tot schending van eventuele geheimhoudingsovereenkomsten, met juridische aansprakelijkheid voor zowel Codifly als de betrokken medewerker.
Intellectueel eigendom. Dit risico heeft twee kanten. Enerzijds kunnen AI-gegenereerde codefragmenten intellectueel eigendom van derden bevatten, zonder dat dit zichtbaar is, waardoor onbewust inbreuk wordt gepleegd op auteursrechten. Anderzijds claimen sommige AI-tools via hun algemene voorwaarden een licentie op alles wat je invoert. Wanneer je code of content invoert die toebehoort aan een klant of aan Codifly (intellectuele eigendomsrechten worden doorgaans overgedragen via de arbeidsovereenkomst of dienstenovereenkomst), geef je feitelijk een licentie weg op IP die niet van jou is om weg te geven.
GDPR en verwerkersovereenkomsten. Wanneer persoonsgegevens worden ingevoerd in een AI-tool, wordt die tool juridisch een subverwerker in de zin van de AVG. Codifly is dan verplicht een verwerkersovereenkomst (DPA) te hebben met die aanbieder. Bij een niet-goedgekeurde tool bestaat die overeenkomst niet, wat een rechtstreekse schending van de AVG oplevert, met mogelijke gevolgen voor zowel Codifly als de betrokken medewerker.
AI Act-compliance. Als gebruiksverantwoordelijke heeft Codifly verplichtingen rond correct gebruik, toezicht en het vermijden van verboden toepassingen. Die verplichtingen zijn onmogelijk na te komen voor tools waarvan Codifly niet weet dat ze worden gebruikt.

Praktisch: je ontwikkelomgeving moet zijn opgezet zoals beschreven in de Codifly Bible (Track 1, Lesson 1). Dat omvat zowel de VS Code-configuratie als de Claude-instellingen. Wanneer die correct staan, zijn de voornaamste risico's op toolniveau al afgedekt.

5.3. Wat mag nooit worden ingevoerd

Bepaalde categorieën informatie mogen nooit worden ingevoerd in een AI-tool, ook niet in Claude.

Persoonsgegevens. Namen, e-mailadressen, telefoonnummers, adressen, rijksregisternummers, bulk-lijsten met contactgegevens van klanten, eindgebruikers of medewerkers. Zodra je persoonsgegevens invoert, ben je bezig met een gegevensverwerking in de zin van de AVG, met alle verplichtingen van dien.

Uitzondering: de AI-policy voorziet een beperkte uitzondering voor gewone identificatiegegevens van medewerkers en zakelijke contactpersonen in Claude.

Bijzondere categorieën persoonsgegevens. Deze zijn altijd verboden, in welke AI-tool dan ook. Het gaat om gegevens over gezondheid, etnische afkomst, politieke opvattingen, religieuze of levensbeschouwelijke overtuigingen, vakbondslidmaatschap, genetische of biometrische gegevens, seksuele gerichtheid, en strafrechtelijke gegevens. De AVG beschermt deze categorie extra streng omdat de gevolgen van misbruik bijzonder ernstig kunnen zijn.

Credentials en geheimen. API-keys, wachtwoorden, tokens, certificaten en private keys mogen nooit worden ingevoerd in een AI-tool. De impact is groter dan ze lijkt: een ingevoerde API-key verlaat je omgeving, gaat naar externe servers en kan worden opgeslagen of verwerkt op manieren die je niet controleert. Die externe opslag vormt bovendien een bijkomend risico: servers van derden zijn een doelwit voor cyberaanvallen, en een gelekte sleutel kan zo toegang geven tot onze eigen systemen of die van een klant.

Bij Claude Code is het risico extra reëel: de AI-tool navigeert zelfstandig door je project en leest automatisch context mee uit de workspace: het actieve bestand, open tabs, en soms de volledige projectstructuur. Omgevingsvariabelen, configuratiebestanden met secrets en .env-bestanden kunnen zo onbedoeld worden meegestuurd. Dit risico wordt op twee niveaus beheerd.

Individuele verantwoordelijkheid. Elke medewerker is zelf verantwoordelijk voor wat hij of zij met een AI-tool deelt. Vóór elke AI-interactie waarbij bestanden worden meegelezen, controleer je of er geen gegevens uit de categorieën hierboven in de context terecht zullen komen.
Structurele basisbeveiliging per werkstation. Elke medewerker configureert zijn werkstation volgens de richtlijnen in Track 1, Lesson 1. Deze basisbeveiliging sluit standaard gevoelige bestandstypen en -locaties uit van de AI-context. Waar de standaardconfiguratie onvoldoende is, bijvoorbeeld bij projecten met afwijkende structuren, maak je aanvullende uitsluitingsregels aan op projectniveau.

Vuistregel voor developers: alles wat in een .gitignore staat of via git-crypt versleuteld wordt, mag ook niet worden ingevoerd in een AI-tool.

5.4. Geen hoog-risico toepassingen

De AI Act definieert een reeks categorieën van hoog-risico AI-systemen: systemen waarbij een *fout of misbruik ernstige gevolgen kan hebben voor mensen. Gebruik van GPAI-modellen zoals Claude zijn niet hoog-risico, maar een specifieke toepassing ervan kan dat wel worden afhankelijk van waarvoor het in wordtzet.

Om een gevoel te krijgen voor wanneer dat het geval is: het gaat typisch over situaties waarbij een AI-systeem meebeslist of adviseert over een persoon, en die persoon daar de gevolgen van draagt.

Voorbeelden die een alarmbel moeten doen rinkelen:

Je vraagt Claude om CV's te beoordelen en een shortlist te maken.
Je bouwt een feature die op basis van klantgedrag automatisch bepaalt of iemand toegang krijgt tot een dienst.
Je gebruikt AI-gegenereerde samenvattingen van gesprekken met medewerkers als input voor een evaluatiegesprek.
Je vraagt Claude om risicoprofielen op te stellen van personen op basis van hun transactiegeschiedenis.
Je integreert een AI-systeem in een workflow waarbij het systeem een aanbeveling doet die in de praktijk altijd wordt gevolgd.

Wat deze gevallen gemeen hebben: een mens draagt de gevolgen van een beslissing die (deels) door een AI-systeem werd gemaakt of beïnvloed, zonder dat daar de vereiste waarborgen rond zijn gebouwd.

Ongeacht of je de alarmbel hoort rinkelen of niet: je bent zelf verantwoordelijk om te verzekeren dat een toepassing niet hoog-risico is voordat je ze bouwt of inzet. Wanneer je twijfelt, leg je de toepassing voor aan het bestuur van Codifly, vóór je begint.

Voor hoog-risico toepassingen gelden in de AI Act strikte verplichtingen: conformiteitsbeoordeling, logging, menselijk toezicht, transparantie naar betrokkenen. Die verplichtingen kan Codifly als gebruiksverantwoordelijke niet nakomen bij ad-hoc gebruik van een generatief AI-systeem door medewerkers. Zulke toepassingen vereisen een apart, gedocumenteerd traject dat niet 'zomaar' op eigen houtje kan worden opgestart.

5.5. Verboden toepassingen en discriminatie

De AI Act verbiedt een aantal toepassingen absoluut, ongeacht de context. Voor de dagelijkse praktijk zijn de meest relevante verboden:

AI-systemen die subliminale of manipulatieve technieken gebruiken om het gedrag van mensen materieel te beïnvloeden zonder hun medeweten.
AI-systemen die kwetsbaarheden exploiteren op basis van leeftijd, handicap of sociaaleconomische situatie.
AI-systemen voor sociale scoring: mensen beoordelen of rangschikken op basis van gedrag of persoonlijke kenmerken, met nadelige gevolgen buiten de oorspronkelijke context.
Emotieherkenning op de werkplek of in het onderwijs, behalve om medische of veiligheidsgerelateerde redenen.
Real-time biometrische identificatie in openbare ruimten voor rechtshandhavingsdoeleinden.

Daarnaast geldt bij Codifly een breder principe dat niet beperkt is tot de formele verboden: AI mag nooit worden ingezet om discriminerende of onethische beslissingen te nemen. Gezond verstand en respect voor de betrokken personen zijn de maatstaf.

Bij twijfel of een toepassing verboden, discriminerende of onethisch is, beslist het bestuur, zo nodig na raadpleging van een juridisch adviseur.

5.6. Transparantie naar derden

De AI Act legt transparantieverplichtingen op aan aanbieders en gebruiksverantwoordelijken. De meest relevante voor de dagelijkse praktijk:

Wanneer een AI-systeem bedoeld is om rechtstreeks met personen te interageren (chatbot, virtuele assistent), moet de gebruiker geïnformeerd worden dat hij met een AI-systeem communiceert, tenzij dit duidelijk blijkt uit de context.
Wanneer deepfake-content wordt gegenereerd of gemanipuleerd in het kader van een beroepsactiviteit, moet worden gemeld dat de content kunstmatig is.
Wanneer AI-gegenereerde tekst wordt gepubliceerd om het publiek te informeren over zaken van algemeen belang, moet worden gemeld dat de tekst kunstmatig gegenereerd is, tenzij de tekst een menselijke redactionele controle heeft ondergaan en een natuurlijke of rechtspersoon de redactionele verantwoordelijkheid draagt.

In de dagelijkse praktijk betekent dit concreet: wees eerlijk over de rol van AI wanneer dat relevant is voor de ontvanger. Bij twijfel: vermeld het gewoon (of vraag na bij het bestuur).

5.7. Eerste drie weken

Voor stagiairs en startende schoolverlaters geldt een uitzondering op het algemene gebruik van AI-tools: gedurende de eerste drie weken van tewerkstelling is het gebruik van AI-tools verboden.

De reden is praktisch, niet punitief. AI-tools zijn het meest waardevol wanneer je de materie al voldoende kent om de output te beoordelen. Wie nog bezig is met de fundamenten te leggen, mist precies die referentie: je kunt niet controleren wat je niet kent. Het risico is dan niet alleen dat je foute output oplevert, maar ook dat je zelf trager leert omdat je het denkwerk niet meer zelf doet.

6. AI-policy

De volledige lijst van regels en richtlijnen voor het gebruik van AI bij Codifly zijn vastgelegd in de geldende AI-policy, beschikbaar via de gebruikelijke kanalen. Elke medewerker is verplicht de voor hem of haar relevante onderdelen te kennen.

Dit document biedt slechts de achtergrond en het begrip om die regels te kunnen toepassen. Bij enige tegenstrijdigheid tussen dit document en de geldende AI-policy, heeft de AI-policy voorrang.