Hoe wij met AI omgaan

Publieke pagina + intern nalevingsmemo artikel 50 AI-verordening

Pakketversie 1.0 — 31 juli 2026

Dit document: versie 2.1 (31 juli 2026)

Dit document hoort bij het documentenpakket pakketversie 1.0 (31 juli 2026). Dat pakket bestaat uit vier documenten, elk met een eigen documentversie: de algemene voorwaarden (versie 1.0), de verwerkersovereenkomst (versie 1.0), de privacyverklaring (versie 1.0) en deze pagina plus het memo (versie 2.1). Een klant accepteert altijd een pakketversie, niet een los document. Wijzigt er één document, dan gaat de pakketversie omhoog.

Wat er ten opzichte van versie 2.0 is veranderd, en waarom.

1. De architectuur is op 31 juli 2026 verbouwd en getest. De gedeelde Composio-projectsleutel staat niet langer op de klantmachines, en de AgentMail-mastersleutel ook niet. De beschrijving in versie 2.0 was op dit punt achterhaald en is vervangen door wat er nu werkelijk draait. Zie "Waar de sleutels staan" en memo §6.

2. Het beheerkanaal is er nu echt. In versie 2.0 stond hier een invulveld en de opmerking dat "wij hebben geen toegang" en "wij verzorgen de updates" niet allebei waar kunnen zijn. Dat kan nu wél, omdat het kanaal is omgedraaid: de server vraagt bij ons om werk in plaats van dat wij bij de server naar binnen gaan.

3. Er is een kostenplafond met automatische noodrem. Dat is een beveiligingsmaatregel én een dienstbeperking: bij extreem verbruik valt de AI-medewerker tijdelijk stil. Dat schrijven we op waar je het kunt lezen voordat je tekent.

4. Telefonie is overal geschrapt. Wij leveren geen telefoniekanaal. Versie 2.0 beloofde de AI-vermelding "ook aan de telefoon". Een belofte over een dienst die niet bestaat, hoort nergens te staan.

5. Eén AI-vermelding, letterlijk, overal. Er was een verschil tussen de formulering in de algemene voorwaarden en die hier. Er is nu één zin, met één registernummer, die alle documenten letterlijk citeren.

6. De zorguitsluiting is versmald tot zorggerelateerde communicatie en patiëntgegevens, met terugbetaling naar rato als wij op die grond beëindigen.

7. LinkedIn is teruggebracht tot wat het is: connectieverzoeken en profielgebaseerd contact. Een commerciële DM naar een ZZP'er krijgt dezelfde toets als koude e-mail.

8. Het Bel-me-niet-register is uit de tekst. Dat register bestaat sinds 1 juli 2021 niet meer.

9. Het auditlogboek heeft nu één bewaarregel die niet meer botst met het vernietigen van de server op dag 30.

>

Wat in versie 2.0 al is rechtgezet en zo blijft: de machineleesbare markering van artikel 50 lid 2 is van ons en niet van onze leveranciers; de doorgifte naar de Verenigde Staten staat per ontvanger als in te vullen en te verifiëren grondslag in plaats van als voorbehoud; artikel 11.7 Telecommunicatiewet staat erin, inclusief de onprettige conclusie dat koude e-mail en koude WhatsApp naar ZZP'ers en eenmanszaken niet mag; de belofte over schijfversleuteling is teruggebracht tot wat ze technisch waarmaakt; en het afmeldwoord is overal "stop".

DEEL 1 — Publieke pagina: Hoe wij met AI omgaan

Deze tekst is bedoeld voor mijnannabel.nl en zakelijk.mijnannabel.nl.

In het kort

Wij verkopen AI-medewerkers. Dat betekent dat er bij ons veel berichten worden geschreven door een computer. Wij vinden dat je dat altijd moet weten. Daarom:

• Onze AI-medewerkers maken zich in het eerste bericht van elk gesprek kenbaar als AI, met deze zin: "Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens." In elk kanaal waarin wij leveren — e-mail, WhatsApp en de chat op onze eigen website. Tegen iedereen. Dat kun je als klant niet uitzetten, niet tegen meerprijs, en er zijn geen uitzonderingen.
• In onze e-mails zit daarnaast een technische markering in de berichtkop, zodat ook software kan zien dat de tekst door AI is opgesteld.
• Onze eigen verkoop-AI, Mike, doet precies hetzelfde.
• De stemmen in onze video's zijn computerstemmen. Dat zeggen we erbij: in beeld, hardop, in de begeleidende tekst én in de bestandsgegevens.
• Vraag je om een mens, dan zetten we je door. We reageren op werkdagen zo snel als we kunnen. Antwoord met "mens".
• Wil je niets meer van ons horen? Antwoord met "stop". Dan blokkeren we je meteen en krijg je daarvan één bevestiging. Daarna is het stil.
• Wij leveren geen telefonie. De AI-medewerker belt niet en neemt de telefoon niet op.

Hieronder leggen we uit hoe het werkt en waar de grenzen liggen.

Wat is een AI-medewerker?

Een AI-medewerker is software die werk doet dat normaal een medewerker zou doen: e-mail en WhatsApp lezen en beantwoorden, afspraken inplannen, dingen uitzoeken en documenten opstellen.

Bij ons krijgt elke klant een eigen server in een datacenter in Duitsland (Hetzner Online GmbH). Daar draait die ene AI-medewerker, voor die ene klant. Je huurt hem per maand. De eerste twee weken kosten niets en je kunt maandelijks opzeggen. Stop je, dan kun je je gegevens nog 30 dagen exporteren.

De AI-medewerker werkt via e-mail en WhatsApp, en op onze eigen website via het chatvenster. Telefonie leveren wij niet: de AI-medewerker belt niemand op en beantwoordt geen telefoon. Als je dat ergens leest, klopt het niet.

Een AI-medewerker is geen mens en doet ook niet alsof.

Over die versleutelde schijf, eerlijk

De schijf van jouw server is versleuteld. Dat helpt tegen iemand die fysiek bij de hardware kan: een schijf die wordt gestolen, verkeerd wordt afgevoerd of uit een rek wordt getrokken, en een kopie van een afgesloten volume.

Wat het niet doet: je beschermen tegen de hostingpartij zelf. Jouw server is een virtuele machine. Zolang die draait, zit de versleutelingssleutel in het werkgeheugen, en dat geheugen draait op hardware die Hetzner beheert. Wie schrijft dat je gegevens "altijd onleesbaar" zijn, vertelt maar de helft. Wij zeggen het liever zelf dan dat een technisch onderlegde koper het er later uit haalt.

Over beheer en toegang, ook eerlijk

In de vorige versie van deze pagina stond dat "wij hebben geen toegang" en "wij verzorgen het beheer" niet allebei waar kunnen zijn. Dat klopte, en daarom hebben wij het beheerkanaal omgedraaid. Zo werkt het nu:

• Na oplevering hebben wij geen toegang tot jouw server. De sleutel waarmee de machine wordt ingericht, wordt na de oplevering ingetrokken. Wij kunnen dus niet inloggen, niet meekijken en niet in bestanden of berichten kijken.
• De server vraagt zelf om werk. Elk kwartier vraagt jouw machine bij ons of er iets voor hem klaarstaat. Wij duwen niets naar binnen; hij haalt op.
• Hij voert alleen opdrachten uit een vaste, korte lijst uit. Vier soorten: een instelling wijzigen, een instelling verwijderen, een versienummer noteren, of zijn eigen toestand rapporteren. Geen willekeurige code, geen commando's, geen toegang tot je bestanden of je gegevens. Een opdracht die niet op de lijst staat, wordt geweigerd.
• Alles wordt vastgelegd. Elke opdracht en elk resultaat komt in het logboek. Je kunt dus achteraf zien wat wij hebben laten doen en wanneer.

Dit kanaal bestaat om één reden: zodat wij sleutels kunnen vervangen en instellingen kunnen corrigeren zonder ooit in jouw omgeving te hoeven kijken.

Wat dit kanaal niet kan: een storing verhelpen die alleen ter plekke te verhelpen is, of het besturingssysteem bijwerken. Dat gaat niet via die vier opdrachten. Hoe wij dat wél doen, wat wij daarvoor aan jou vragen en hoe je het kunt weigeren, staat in [NOOD- EN UPDATEPROCEDURE — uitschrijven en invullen vóór publicatie]. We zetten daar liever een open veld dan een geruststellende zin die we niet kunnen waarmaken.

Waar de sleutels staan, en wat wel en niet gedeeld is

Je AI-medewerker praat met je mailbox, je agenda en je andere apps via een koppelpartij (Composio). Tot 31 juli 2026 stond de gedeelde projectsleutel van die koppelpartij op elke klant-server. Dat vonden wij niet uit te leggen, en het is er sinds die dag af. Zo is het nu:

• Op jouw server staat alleen een eigen token. Dat token is een afgeleide handtekening: het werkt uitsluitend voor jouw omgeving en is elders nergens te gebruiken. Wie het steelt, heeft geen sleutel in handen waarmee hij bij een andere klant kan.
• Jouw server praat niet rechtstreeks met de koppelpartij, maar via een koppelserver (hub) die wij beheren. Daar, en alleen daar, staat de gedeelde projectsleutel.
• Elke klant heeft bij de koppelpartij een eigen sessie, met een eigen gebruikers-id en een eigen sessie-URL.
• Voor de mailbox van de AI-medewerker (AgentMail) geldt hetzelfde: de mastersleutel is van de klantmachines gehaald. Elke klant heeft nog uitsluitend een sleutel die zijn eigen mailbox ziet.

Wat wél gedeeld blijft, want dat hoor je ook te weten: het projectaccount bij de koppelpartij is er één, van mijnannabel, en de sleutel daarvan wordt door onze hub gehouden. De scheiding tussen klanten zit dus in drie dingen tegelijk — een eigen server, een eigen sessie met een eigen gebruikers-id, en een token dat alleen voor die ene klant werkt — en niet in een apart account per klant. Wie bij onze hub binnenkomt, komt bij die gedeelde sleutel. Daarom staat die hub apart, doet hij niets anders, en logt hij alles.

Wat er gebeurt als het verbruik ontspoort

Een AI-medewerker die op hol slaat, kan in een paar uur een rekening opbouwen waar niemand blij van wordt. Daarom:

• Elke klant-server meldt elk uur zijn eigen modelverbruik.
• Bij 70% van het maandbudget gaat er een waarschuwing uit. Wij zien die en nemen contact met je op.
• Bij overschrijding wordt de modelsleutel van jouw server automatisch verwijderd. Vanaf dat moment zijn er geen betaalde AI-aanroepen meer mogelijk, totdat wij dat herstellen.

Dat is bewust een harde noodrem en geen zachte waarschuwing. Het beschermt jou tegen een rekening die je niet zag aankomen, en ons tegen een verlies dat we niet kunnen dragen. Maar het is ook eerlijk om te zeggen wat het betekent: bij extreem verbruik valt de AI-medewerker tijdelijk stil. Dat is een beperking van de dienst en staat daarom ook zo in onze algemene voorwaarden. Het maandbudget dat voor jou geldt, staat in je overeenkomst: [MAANDBUDGET MODELVERBRUIK PER KLANT — invullen, gelijk aan de algemene voorwaarden].

De AI maakt zich altijd kenbaar als AI

Elke keer dat een AI-medewerker van ons contact heeft met een mens, staat in het eerste bericht van dat gesprek dat het om een AI-systeem gaat. Overal dezelfde zin, letterlijk:

"Je hebt contact met de AI-medewerker van [bedrijfsnaam]. Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens."

Deze tekst staat bij ons in een register onder nummer DISC-009 en wordt op één plek beheerd. Alle andere documenten — de algemene voorwaarden voorop — citeren precies deze zin en verwijzen naar dat nummer. Zo kan er geen tweede versie ontstaan.

Wat een "gesprek" is. Een gesprek is een reeks berichten tussen één AI-medewerker en één persoon in één kanaal, waarbij tussen twee opeenvolgende berichten niet meer dan 24 uur zit. Ligt het langer stil en begint het daarna opnieuw, dan is dat een nieuw gesprek en komt de zin er weer bij. Dezelfde definitie staat in onze algemene voorwaarden, zodat de belofte controleerbaar is en niet aan uitleg onderhevig.

Daarna herhalen we het in de ondertekening van elk bericht.

Dit is niet uitschakelbaar. Het staat in onze voorwaarden en het zit vast in de software: kan de vermelding om wat voor reden dan ook niet worden toegevoegd, dan gaat het bericht niet weg maar naar de conceptenmap. We krijgen weleens de vraag of de AI zich niet gewoon kan voordoen als "Sanne van de klantenservice". Het antwoord is nee, en dat blijft nee. Wie dat toch wil, is bij ons aan het verkeerde adres.

Waarom zo stellig? Omdat het sinds 2 augustus 2026 verplicht is (artikel 50 van de Europese AI-verordening), maar vooral omdat het het enige eerlijke is. Iemand die met een computer praat, hoort dat te weten voordat hij besluit wat hij deelt.

En een markering die software kan lezen

De AI-verordening vraagt niet alleen om een zin die een mens kan lezen, maar ook om een markering die een machine kan lezen. Voor de teksten die onze AI-medewerkers schrijven zijn wij de aanbieder, dus is dat onze taak — niet die van onze leveranciers.

Daarom:

• In elke uitgaande e-mail van een AI-medewerker zit een vaste berichtkop die aangeeft dat de inhoud door AI is opgesteld.
• In kanalen die geen berichtkoppen kennen (WhatsApp, chat) gebruiken we een vaste, altijd identieke openingszin die software kan herkennen. Meer laat dat kanaal technisch niet toe, en dat schrijven we liever op dan dat we doen alsof.
• In onze video's zit de markering in het bestand zelf (Content Credentials / C2PA), naast het label in beeld en de gesproken zin.
• Van elk verstuurd bericht leggen we vast of de markering erop zat.

Ook onze eigen verkoop-AI doet dit

Als je een mail van ons krijgt, is de kans groot dat die geschreven is door Mike, onze eigen AI-medewerker. Mike doet ons voorwerk: hij beantwoordt vragen, plant kennismakingen in en onderhoudt contact met mensen die zich bij ons gemeld hebben.

In het eerste bericht van elk gesprek staat:

"Je hebt contact met Mike, de AI-medewerker van mijnannabel. Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens."

En onder elk bericht:

Mike — AI-medewerker van mijnannabel. Dit bericht is opgesteld door een AI-systeem. Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens. Ryan Collins neemt dan persoonlijk contact met je op, op werkdagen zo snel als we kunnen. Geen berichten meer ontvangen? Antwoord met: stop.

Antwoord je met "stop", dan blokkeren we je adres direct. Je krijgt daar één bevestiging van en daarna niets meer.

Wij vinden het wat raar om AI-medewerkers te verkopen zonder ze zelf te gebruiken. Dus gebruiken we ze zelf, en houden we ons aan onze eigen regels.

Hoe wij nieuwe klanten benaderen — en wat we niet doen

Hier zijn wij in de eerste versie van deze pagina te makkelijk over geweest. In Nederland regelt artikel 11.7 van de Telecommunicatiewet of je iemand ongevraagd een commercieel bericht mág sturen. Dat artikel is strenger dan veel mensen denken, ook zakelijk. Dit is hoe wij het doen:

Wat wij niet doen

• Geen koude WhatsApp. Nooit, voor niemand, voor geen enkel aanbod. WhatsApp gebruiken we alleen voor bestaande klanten en voor mensen die er zelf om vragen.
• Geen koude e-mail naar eenmanszaken en ZZP'ers. Een eenmanszaak of ZZP'er is juridisch een natuurlijk persoon. Daarvoor geldt gewoon: eerst toestemming. Ook als het adres openbaar op een website staat, ook als het "info@" is.
• Geen commerciële berichten via LinkedIn naar eenmanszaken en ZZP'ers. Een LinkedIn-bericht is ook een elektronisch bericht. Wij hebben in een eerdere versie geschreven dat LinkedIn "anders" is. Dat was te makkelijk. Een verkoopvoorstel in een DM krijgt bij ons dezelfde toets als een verkoopmail.
• Geen koude telefoontjes naar eenmanszaken en ZZP'ers. Sinds 1 juli 2021 bestaat het Bel-me-niet-register niet meer. Het is vervangen door een opt-in-regime voor telemarketing richting natuurlijke personen: je moet vooraf toestemming hebben. Omdat een ZZP'er een natuurlijk persoon is, geldt dat ook voor hem. "Bellen mag altijd" is onjuist en dat schrijven we hier dan ook niet.
• Geen adressen die we ergens hebben weggeplukt. Een geschraapte lijst is geen toestemming.

Wat wij wel doen

• LinkedIn, beperkt: een connectieverzoek sturen en reageren op wat iemand zelf op zijn profiel of tijdlijn deelt. Wordt het een commercieel voorstel aan een eenmanszaak of ZZP'er, dan geldt de regel hierboven.
• Reageren op mensen die zelf contact zoeken (inbound, formulier, download, demo-aanvraag).
• Bestaande klanten mailen over onze eigen, gelijksoortige diensten, met in elk bericht een afmeldmogelijkheid.
• E-mail naar een zakelijk adres van een rechtspersoon dat door dat bedrijf zelf is gepubliceerd om zulke berichten te ontvangen. Dan staat in het eerste bericht meteen wie wij zijn, waar wij het adres vandaan hebben, waarom we schrijven, hoe lang we de gegevens bewaren en hoe je je afmeldt.

Wat er altijd in het eerste bericht staat

Wie wij zijn, waar wij aan je gegevens komen, waarom we je benaderen, dat je bezwaar kunt maken, hoe lang we prospectgegevens bewaren (12 maanden na het laatste contact, daarna weg) en het woord "stop". Dat is niet alleen netjes, het is artikel 14 AVG.

De toezichthouder hierop is de Autoriteit Consument & Markt. Vind je dat wij ons hier niet aan houden, laat het ons weten — en anders weet je ACM te vinden.

Onze video's worden ingesproken door een computer

Wij maken video's, soms persoonlijk gericht aan één bedrijf. De stem die je hoort is geen echt persoon. Het is een computerstem (wij gebruiken daarvoor Microsoft Azure Speech, in de Europese regio West-Europa).

Je ziet en hoort dat:

• In beeld staat vanaf de eerste seconde: "AI-gegenereerd — computerstem".
• De video begint met de gesproken zin: "Even vooraf: de stem die je hoort is een computerstem en deze video is met AI gemaakt."
• In de begeleidende tekst of e-mail staat hetzelfde nog een keer.
• In het bestand zelf zit een machineleesbare markering.

We doen dit ook bij video's waarvan je het misschien meteen doorhebt. Beter twee keer gezegd dan één keer verzwegen.

Wat de AI wél zelfstandig doet

• Berichten lezen, sorteren en samenvatten.
• Concepten schrijven voor antwoorden.
• Uitzoekwerk doen en bronnen erbij zetten.
• Documenten en overzichten opstellen.
• Afspraken inplannen in je agenda, binnen de regels die jij instelt.
• Standaardvragen beantwoorden waarvan jij hebt goedgekeurd hoe het antwoord luidt.

Wat de AI niet doet

• Geen prijzen verzinnen. Staat een prijs niet in wat jij hebt aangeleverd, dan noemt de AI geen prijs.
• Geen levertijden verzinnen.
• Geen toezeggingen doen namens jou: geen korting, geen garantie, geen afspraak over aansprakelijkheid, geen contract.
• Niet doen alsof hij een mens is.
• Geen juridisch, medisch of financieel advies geven.
• Geen sollicitanten beoordelen, scoren of rangschikken, en geen oordelen vellen over werknemers. Dat is onder de AI-verordening een hoog-risicotoepassing en dat leveren wij niet.
• Geen koude WhatsApp of koude e-mail in strijd met artikel 11.7 Telecommunicatiewet, ook niet als jij dat als klant zou willen.
• Niet bellen. Telefonie is geen onderdeel van de dienst.

Weet de AI het niet, dan verzint hij niets, maar schakelt hij door naar jou:

"Dit kan ik niet zelf beantwoorden. Ik leg je vraag neer bij [naam] en je krijgt zo snel mogelijk antwoord van een mens."

Zorg: wat wij niet leveren, en wat wel

Wij leveren de AI-medewerker niet voor zorggerelateerde communicatie en niet voor het verwerken van patiëntgegevens. Dat is een bewuste keuze: die communicatie brengt eisen met zich mee — beroepsgeheim, de eisen aan medische hulpmiddelen, de omgang met gezondheidsgegevens — die wij vandaag niet waarmaken.

Dat is een grens per toepassing, niet per sector. Een fysiotherapiepraktijk, een tandarts of een kliniek mag onze AI-medewerker gewoon gebruiken voor facturatie, leveranciersmail, offertes of het inplannen van een gesprek met de accountant. Wat niet mag: contact met patiënten, of iets doen met gegevens over hun gezondheid.

Blijkt tijdens de looptijd dat de AI-medewerker toch voor patiëntcontact of patiëntgegevens wordt gebruikt, dan beëindigen wij de overeenkomst. In dat geval betalen wij het vooruitbetaalde bedrag over de resterende periode naar rato terug. Wij vinden het niet netjes om te beëindigen én het geld te houden bij iemand die niets heeft verzwegen.

Wat je moet weten om ermee te werken (AI-geletterdheid)

Sinds 2 februari 2025 verplicht artikel 4 van de AI-verordening iedereen die AI-systemen aanbiedt of gebruikt om te zorgen dat de mensen die ermee werken er genoeg van snappen. Dat geldt voor ons én voor jou.

Wat wij doen: wij zorgen dat onze eigen mensen weten wat het systeem wel en niet kan, en wij geven jou bij de start een korte uitleg — wat de AI-medewerker doet, waar zijn grenzen liggen, hoe je ziet dat hij iets fout heeft en wat je dan doet. Wat jij doet: je zorgt dat iedereen die bij jou met de AI-medewerker werkt die uitleg heeft gehad voordat hij begint. Dat is geen cursus van een dag; het is een half A4 en tien minuten aandacht. Maar het moet wel gebeuren, en het staat daarom ook in onze voorwaarden.

Hoe jij de controle houdt

Eerst concepten. In de eerste periode werkt de AI-medewerker standaard in conceptmodus. Hij schrijft, jij leest en drukt op verzenden. Pas als jij vindt dat het goed gaat, geef je hem meer ruimte, per soort bericht. Je kunt altijd terug naar conceptmodus.

Jij bepaalt waar hij bij mag. Mailbox, agenda en andere tools koppel je zelf en je kunt de koppeling zelf weer weghalen.

Er is een logboek. Elke actie van de AI wordt vastgelegd: wat er is gelezen, wat er is verstuurd, aan wie, op welk moment, of de AI-vermelding erop zat, en of een mens het heeft goedgekeurd. Ook de opdrachten die via het beheerkanaal binnenkomen staan erin. Je kunt dat inzien. Wij bewaren het auditlogboek 12 maanden tijdens de looptijd; bij beëindiging gaat het logboek mee in de export en wordt het uiterlijk op de dertigste dag na einde vernietigd, samen met de server, de sleutel en de back-ups.

Aan-uitknop. Je kunt de AI-medewerker op elk moment pauzeren of stoppen. Opzeggen kan per maand, zonder opzegtermijn.

Jij blijft eindverantwoordelijk. Dat willen we niet wegpoetsen. Wat er namens jouw bedrijf de deur uitgaat, komt op jouw naam en op jouw conto. Wij bouwen het gereedschap, zorgen dat het eerlijk is over wat het is en dat je het niet kúnt uitzetten; jij bepaalt wat je ermee doet. Onder de AI-verordening ben jij daarbij gebruiksverantwoordelijke, met je eigen verplichtingen richting de toezichthouder.

Wat er gebeurt als de AI een fout maakt

De AI maakt fouten. Niet af en toe theoretisch, maar in de praktijk. Hij kan iets verkeerd begrijpen, een detail missen of iets stelligs zeggen dat niet klopt. Daarom die conceptmodus, daarom die grenzen, en daarom dit stukje.

Gaat er iets mis, dan:

1. Zeg je het gewoon. De AI stuurt een correctie waar duidelijk in staat wat er niet klopte: "Correctie: mijn vorige bericht klopte niet. [wat er niet klopte]. Dit is de juiste informatie: [juiste informatie]. Excuses — dit bericht is nagekeken door een mens."

2. Zetten we die soort bericht terug op concept, zodat het niet nog eens gebeurt zonder dat er iemand meekijkt.

3. Kijken we in het logboek wat er precies is gebeurd en waarom.

4. Passen we de instructies aan, en als het aan onze software ligt: die.

Ging het mis in een bericht dat een AI-medewerker namens een klant verstuurde? Dan is die klant degene die het rechtzet richting zijn eigen klant. Wij helpen met uitzoeken en meestal ook met de tekst.

Waar je een mens bereikt. Klopt er iets niet, of gaat het over je persoonsgegevens, een datalek, een klacht of een opzegging? Mail dan naar privacy@mijnannabel.nl. Dat is bewust een ander adres dan info@mijnannabel.nl: dat laatste wordt eerst door de AI-medewerker gelezen, en voor gevoelige of bewijsgevoelige post vinden wij dat geen goed idee.

Waar je gegevens staan

Om open kaart te spelen over de keten:

Staat er bij een partij "nee", dan geldt voor die partij: standaardcontractbepalingen module 3 plus een uitgevoerde overdrachtstoets, en waar die toets daarom vraagt aanvullende maatregelen. Wij vullen dit per partij in en verifiëren het vóór de eerste klant; een voorbehoud in de trant van "voor zover gecertificeerd" is geen grondslag en zetten we hier dus niet neer. Dezelfde regel, met dezelfde datum, staat in onze privacyverklaring en in bijlage 1 van de verwerkersovereenkomst.

Hoe de sleutels en de scheiding tussen klanten geregeld zijn, staat hierboven onder "Waar de sleutels staan". Het korte antwoord: eigen server, eigen sessie met eigen gebruikers-id, eigen token — binnen één projectaccount van mijnannabel, waarvan de sleutel op onze hub staat en niet bij jou.

Hoe lang we wat bewaren

Kort samengevat; de volledige lijst staat in onze privacyverklaring.

Vragen, of het er niet mee eens?

mijnannabel

Contactpersoon: Ryan Collins

E-mail (wordt eerst door de AI-medewerker gelezen): info@mijnannabel.nl

E-mail die alleen een mens leest: privacy@mijnannabel.nl

Websites: mijnannabel.nl en zakelijk.mijnannabel.nl

Rechtsvorm: besloten vennootschap (B.V.)

Vestigingsadres: Kortelaan 3, 3771 HS Barneveld

KvK-nummer: 42143671

Btw-nummer: NL869911788B01

Denk je dat wij ons niet houden aan wat hier staat, of aan de AI-verordening? Laat het ons eerst weten, dan lossen we het op. Kom je er met ons niet uit, dan kun je terecht bij de Nederlandse markttoezichthouder voor AI-systemen ([NEDERLANDSE MARKTTOEZICHTHOUDER AI — aanwijzing controleren vóór publicatie]). Gaat het over je persoonsgegevens, dan kun je naar de Autoriteit Persoonsgegevens. Gaat het over ongevraagde berichten, dan is de Autoriteit Consument & Markt het adres.

Laatst bijgewerkt: 31 juli 2026 — documentversie 2.1, pakketversie 1.0. Wijzigingen in deze pagina houden we bij, zodat je kunt zien wat er wanneer veranderd is.

DEEL 2 — Intern nalevingsmemo artikel 50 AI-verordening

Voor: Ryan Collins, mijnannabel

Datum: 31 juli 2026

Documentversie: 2.1 (pakketversie 1.0)

Onderwerp: Wat artikel 50 AI-verordening per 2 augustus 2026 van ons vraagt, per uiting — plus artikel 11.7 Telecommunicatiewet, de nieuwe sleutel- en beheerarchitectuur en de doorgifte naar de VS

Status: intern — niet publiceren

Let op de datum. Artikel 50 gaat over twee dagen gelden. Alles wat hieronder als "moet" staat, moet op 2 augustus 2026 live zijn.

>

Blokkade vooraf, één. Zonder KvK-inschrijving is er geen rechtspersoon die kan contracteren, geen btw-nummer voor geldige facturen en geen incassant-ID voor de SEPA-incasso. Deel 1 kan pas online als 42143671, NL869911788B01, besloten vennootschap (B.V.) en Kortelaan 3, 3771 HS Barneveld zijn ingevuld.

>

Blokkade vooraf, twee. Deel 1 doet harde technische beloftes. Die moeten op de dag van publicatie waar zijn. Zie §8.5: publiceren mag pas na een aantoonbare test per kanaal, met datum en naam eronder.

1. Waar we het over hebben

Verordening (EU) 2024/1689 (de AI-verordening). Artikel 50 zit in hoofdstuk IV en gaat alleen over transparantie. Het geldt ongeacht of een systeem hoog risico is of niet. Een chatbot die niets spannends doet, valt er net zo goed onder.

De vier onderdelen die ons raken:

Op die "tenzij het overduidelijk is" moeten we niet gaan leunen. Dat is precies de uitzondering waar een toezichthouder achteraf anders over denkt dan jij. Wij labelen altijd.

Artikel 26 hoort hier niet. Dat artikel gaat over gebruiksverantwoordelijken van hoog-risicosystemen, en dat is precies wat wij in §9 verbieden. Gebruik artikel 26 dus nergens als grondslag voor de gewone verantwoordelijkheid van onze klanten. Daarvoor gelden artikel 50 lid 4 en onze eigen contractuele afspraak. In de algemene voorwaarden stond dit fout en het moet daar worden gecorrigeerd (§12).

2. Onze rollen — en waarom lid 2 wél van ons is

Drie gevolgen daarvan:

Eén: lid 1 rust op ons. Omdat wij aanbieder zijn van de AI-medewerker, is het onze taak om het systeem zó te bouwen dat de mens aan de andere kant weet dat hij met AI praat. Dat is precies waarom "niet uitschakelbaar" geen marketingclaim is maar een noodzaak: als de klant het uit kan zetten, voldoen wíj niet.

Twee: lid 2 rust óók op ons — dit was in versie 1.0 fout. Versie 1.0 stelde dat de machineleesbare markering "op Microsoft rust, niet op ons". Dat klopt voor de audio die Azure Speech genereert. Het klopt niet voor de e-mail- en WhatsApp-teksten die de AI-medewerker zelfstandig opstelt: lid 2 noemt tekst expliciet, en van dat systeem zijn wij de aanbieder. De uitzondering in lid 2 voor systemen met een "ondersteunende functie voor standaardbewerking" of die "de inputgegevens niet wezenlijk wijzigen" gaat niet op voor een agent die zelf antwoorden schrijft. Zie §5 voor wat we dus moeten bouwen.

Drie: artikel 25 lid 1, zorgvuldig geformuleerd. Een klant wordt zélf aanbieder langs drie routes: (a) het systeem onder eigen naam of merk in de handel brengen, (b) een substantiële wijziging aanbrengen, of (c) het beoogde doel zo wijzigen dat het systeem hoog risico wordt. Een klant die de AI-vermelding weghaalt of verhult valt daar niet automatisch onder. Wat er dan wél aan de hand is: het is wanprestatie onder onze voorwaarden, het kán een substantiële wijziging opleveren, en de klant blijft in de regel gebruiksverantwoordelijke — met eigen verplichtingen jegens de toezichthouder. Zo moet het ook in de algemene voorwaarden staan; niet als "de klant wordt dan aanbieder".

En wat níét kan: een bestuurlijke boete van de AP of de AI-markttoezichthouder contractueel doorschuiven naar de klant. Die boete wordt opgelegd aan de overtreder. Wat wel kan is een civielrechtelijke vrijwaring voor de schade die wij lijden doordat de klant zich niet aan de voorwaarden hield. Die vrijwaring moet het einde van de overeenkomst overleven; dat staat nu niet in de survivalbepaling van de algemene voorwaarden en moet daar bij (§12).

Aansprakelijkheid, exact zoals in de algemene voorwaarden. Beperkt tot de vergoeding over twaalf maanden, met een bodembedrag van € 500 dat ook tijdens de proefperiode geldt, gevolgschade uitgesloten, met de wettelijke uitzonderingen voor opzet en bewuste roekeloosheid. Dat bodembedrag hoort er in elk document bij te staan; het weglaten in een samenvatting maakt de samenvatting onjuist.

3. De vermelding — één formulering, overal

Er is één disclosurezin, in elk kanaal, tegenover elke natuurlijke persoon, in het eerste bericht van elk gesprek. De vaste kern, letterlijk en onveranderlijk:

Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens.

Daarvoor staat één identificerende zin. Voor de AI-medewerker van een klant is dat DISC-009, en dat is de enige plek waar deze tekst wordt beheerd. De algemene voorwaarden citeren DISC-009 letterlijk en verwijzen naar dat registernummer, zodat er niet twee versies kunnen ontstaan (dat was tot deze ronde wél het geval).

Definitie van "gesprek" — deze hoort ook in artikel 1 van de algemene voorwaarden, anders is de belofte niet te auditeren:

Een gesprek is een reeks berichten tussen één AI-medewerker en één persoon in één kanaal, waarbij tussen twee opeenvolgende berichten niet meer dan 24 uur zit. Zit er meer dan 24 uur tussen, dan begint een nieuw gesprek en wordt de AI-vermelding opnieuw gegeven.

Daarnaast staat de vermelding in de ondertekening van elk bericht. Dat is strenger dan lid 5 vraagt en dat is expres.

Kanalen. E-mail, WhatsApp en het chatvenster op onze eigen site. Telefonie is geen kanaal en komt in geen enkel document meer voor als belofte of als functie.

Voor elke uiting hieronder staat de letterlijke Nederlandse tekst. Niet parafraseren, niet inkorten. Beheer ze als versies (zie §8.1).

3.1 Verkoopmail van Mike

Grondslag: art. 50 lid 1 (rechtstreekse interactie) + lid 5 (bij eerste contact) + lid 2 (markering, zie §5).

Waar: in de eerste alinea, boven of direct onder de aanhef — niet alleen in de voettekst, want lid 5 vraagt om "duidelijk en herkenbaar" bij eerste contact. En daarnaast in de handtekening.

DISC-001 — bovenaan het eerste bericht:

Je hebt contact met Mike, de AI-medewerker van mijnannabel. Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens.

DISC-002 — handtekening onder élke mail, ook vervolgmails:

Mike — AI-medewerker van mijnannabel. Dit bericht is opgesteld door een AI-systeem. Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens. Ryan Collins neemt dan persoonlijk contact met je op, op werkdagen zo snel als we kunnen. Geen berichten meer ontvangen? Antwoord met: stop.

DISC-003 — bevestiging na "stop", eenmalig, en daarna nooit meer iets:

Je bent afgemeld. Je adres is geblokkeerd en je ontvangt geen berichten meer van mijnannabel. Dit is de laatste mail die je van ons krijgt.

Nooit gebruiken: "Mike van mijnannabel" zonder de vermelding AI. Ook geen achternaam voor Mike, geen pasfoto, geen "ik zat net te denken aan jullie bedrijf". Alles wat suggereert dat er een mens zit, is precies wat lid 1 verbiedt.

Let op: of je die mail überhaupt mág sturen, is een andere vraag dan of de disclosure erin staat. Zie §4.

3.2 Mike op WhatsApp of in het chatvenster

Grondslag: art. 50 lid 1 + lid 5.

Waar: het eerste bericht van elk gesprek, en opnieuw als een gesprek langer dan 24 uur heeft stilgelegen.

DISC-004 — eerste bericht in WhatsApp of chat:

Je hebt contact met Mike, de AI-medewerker van mijnannabel. Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens. Wil je niets meer van ons horen, antwoord dan met: stop.

DISC-005 — openingsregel in het chatvenster op de website, vóór de bezoeker typt:

Je chat met de AI-medewerker van mijnannabel. Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens.

(In versie 2.0 stond hier een kortere, afwijkende zin. Die is vervallen: één formulering betekent één formulering, ook in een klein chatvenster.)

Harde regel: WhatsApp is verboden voor acquisitie. Mike benadert via WhatsApp niemand die zich niet zelf heeft gemeld. WhatsApp gebruiken we uitsluitend voor bestaande klanten en voor mensen die er zelf om vragen. Twee redenen, allebei zelfstandig genoeg:

1. Artikel 11.7 Telecommunicatiewet dekt elk elektronisch bericht, niet alleen e-mail. Zonder toestemming mag het niet (zie §4). Diezelfde redenering geldt voor een commerciële DM op LinkedIn; dat hebben we in versie 2.0 ten onrechte anders behandeld.

2. De WhatsApp Business Messaging Policy verbiedt ongevraagde berichten zonder aantoonbare opt-in, op straffe van blokkade van het account. We leggen in onze eigen voorwaarden aan klanten op dat ze zich aan de Meta-voorwaarden houden; dan kunnen we ze zelf niet overtreden.

De koude-WhatsApp-flow van Mike moet uit. Dat is geen redactie maar een aanpassing in de pijplijn.

3.3 Gepersonaliseerde video met synthetische stem

Grondslag: art. 50 lid 4 als het materiaal als deepfake kwalificeert, plus art. 50 lid 2 voor de markering — die zetten wij er zelf op.

Waar: vier plekken — in beeld, gesproken, in de begeleidende tekst, en in het bestand.

DISC-006 — in beeld, vanaf seconde 0 tot het einde, leesbaar op mobiel:

AI-gegenereerd — computerstem

DISC-007 — gesproken, als allereerste zin van de audio:

Even vooraf: de stem die je hoort is een computerstem en deze video is met AI gemaakt.

DISC-008 — in de e-mail, de videobeschrijving of op de landingspagina:

Deze video is automatisch gemaakt. De stem is een computerstem (AI-gegenereerde audio); er spreekt geen echt persoon.

MARK-003 — in het bestand: Content Credentials (C2PA) of een gelijkwaardige inbedding, plus de markering in de bestandsmetadata. Wij zetten die er zelf op. Of Microsoft de audio ook markeert is meegenomen, maar het is niet onze grondslag om het na te laten — die redenering was in versie 1.0 het probleem.

De nuance, eerlijk opgeschreven. Artikel 50 lid 4 gaat strikt genomen over deepfakes: materiaal dat lijkt op bestaande personen of gebeurtenissen en ten onrechte authentiek overkomt. Een generieke computerstem die niemand nadoet, is dat waarschijnlijk niet. Maar zodra de stem een kloon wordt van jouw stem, of de video wordt gepresenteerd alsof Ryan Collins zelf spreekt, val je er wél onder. En omdat wij transparantie als merkwaarde voeren, doen we het sowieso. Kosten nul, risico weg.

Niet doen: de stem van een bestaand persoon klonen zonder schriftelijke toestemming van die persoon. Dan komen er naast de AI-verordening ook portretrecht en de AVG bij kijken.

3.4 De AI-medewerker die namens een klant met diens klanten communiceert

Grondslag: art. 50 lid 1 en lid 2 (op ons als aanbieder) + lid 5. De klant is gebruiksverantwoordelijke, maar de plicht om het systeem zo te ontwerpen dat het niet uit kán, ligt bij ons.

Waar: eerste bericht van elk gesprek, plus handtekening onder elk bericht, plus de markering uit §5.

DISC-009 — eerste bericht, e-mail én WhatsApp, identiek. Dit is de bron van de formulering voor het hele pakket:

Je hebt contact met de AI-medewerker van [BEDRIJFSNAAM KLANT]. Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens.

DISC-010 — handtekening onder elk bericht:

[NAAM AI-MEDEWERKER] — AI-medewerker van [BEDRIJFSNAAM KLANT]. Dit bericht is opgesteld door een AI-systeem. Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens. [NAAM CONTACTPERSOON] kijkt mee en neemt het over waar nodig. Geen berichten meer ontvangen? Antwoord met: stop.

DISC-015 — bevestiging na "stop", namens de klant, eenmalig:

Je bent afgemeld. Je adres is geblokkeerd en je ontvangt geen berichten meer van [BEDRIJFSNAAM KLANT]. Dit is het laatste bericht dat je van ons krijgt.

(Deze klantvariant ontbrak: DISC-003 bestond alleen voor mijnannabel zelf, terwijl de belofte van directe blokkering plus één bevestiging ook voor klanten geldt.)

Technisch fail-closed inbouwen: kan de vermelding of de machineleesbare markering om wat voor reden dan ook niet worden toegevoegd (template ontbreekt, veld niet ingevuld, bericht wordt afgekapt, header wordt gestript), dan gaat het bericht niet de deur uit maar naar de conceptenmap met een melding. Dat is het verschil tussen "we hebben het geprobeerd" en "we kunnen bewijzen dat het altijd gebeurt".

In de klantovereenkomst, kort — en met een letterlijk citaat van DISC-009 plus het registernummer:

De AI-medewerker maakt in het eerste bericht van elk gesprek, in elk kanaal, kenbaar dat hij een AI-systeem is, en voorziet uitgaande berichten van een machineleesbare markering. De tekst van die vermelding luidt: "Je hebt contact met de AI-medewerker van [bedrijfsnaam]. Ik ben een AI-systeem, geen mens. Wil je een mens spreken, antwoord dan met: mens." (registernummer DISC-009). Deze vermelding en markering zijn niet uitschakelbaar en niet aanpasbaar door de klant. Het is de klant niet toegestaan de AI-medewerker te presenteren als een natuurlijk persoon of onder de naam van een bestaande medewerker te laten communiceren. Handelt de klant hiermee in strijd, dan is dat een tekortkoming in de nakoming; de klant blijft daarbij zelf gebruiksverantwoordelijke in de zin van de AI-verordening en draagt de daarbij horende eigen verplichtingen jegens de toezichthouder.

3.5 Escalatie, correctie en afmelden

Geen artikel 50-plicht, wel het bewijs dat je grenzen bewaakt.

DISC-011 — escalatie:

Dit kan ik niet zelf beantwoorden. Ik leg je vraag neer bij [NAAM CONTACTPERSOON] en je krijgt zo snel mogelijk antwoord van een mens.

DISC-012 — correctie:

Correctie: mijn vorige bericht klopte niet. [WAT ER NIET KLOPTE]. Dit is de juiste informatie: [JUISTE INFORMATIE]. Excuses — dit bericht is nagekeken door een mens.

DISC-013 — afmelden: het woord is overal "stop", in elk document en elke uiting. Er is geen tweede woord, geen "verwijderen", geen link-alleen-variant. "stop" leidt tot directe blokkering van dat adres of nummer, plus één bevestiging (DISC-003 voor mijnannabel, DISC-015 namens een klant) en daarna niets meer.

3.6 Het artikel 14-blok bij een eerste zakelijke e-mail

Dit stond wel in het register maar de letterlijke tekst ontbrak. Bij een eerste bericht aan iemand van wie wij de gegevens niet zelf hebben gekregen, moet artikel 14 AVG-informatie erin. Vast blok, onderaan het bericht, boven de handtekening.

DISC-014:

Waarom je dit bericht krijgt. Wij zijn mijnannabel (besloten vennootschap (B.V.), KvK 42143671, Kortelaan 3, 3771 HS Barneveld). Wij hebben je zakelijke e-mailadres gevonden via [BRON VAN HET ADRES]. Wij gebruiken je naam, functie, bedrijfsnaam en e-mailadres om je te benaderen over onze AI-medewerkers. De grondslag daarvoor is ons gerechtvaardigd belang bij directe marketing (artikel 6 lid 1 sub f AVG). Wij bewaren deze gegevens tot 12 maanden na ons laatste contact en verwijderen ze daarna. Je hebt recht op inzage, correctie en verwijdering van je gegevens, en je kunt bezwaar maken tegen dit gebruik. Voor het verzenden en verwerken van dit bericht schakelen wij dienstverleners buiten de Europese Unie in; hoe dat is geregeld staat in onze privacyverklaring: [LINK PRIVACYVERKLARING]. Antwoord met: stop, dan blokkeren wij je adres direct en hoor je niets meer van ons. Ben je het niet eens met hoe wij met je gegevens omgaan, dan kun je een klacht indienen bij de Autoriteit Persoonsgegevens.

4. Mag je dit bericht überhaupt sturen? Artikel 11.7 Telecommunicatiewet

De AVG regelt of je de gegevens mag verwerken. Of je het bericht mag sturen, regelt artikel 11.7 Telecommunicatiewet. Een keurige belangenafweging onder artikel 6 lid 1 sub f AVG helpt je daar niets.

Waarschuwing over de lidnummers. Dit pakket verwees op meerdere plekken naar specifieke leden van artikel 11.7 Tw. Eén verschuiving in de wettekst maakt al die verwijzingen fout. Daarom beschrijven we hieronder de inhoud van elke regel en zetten we er (artikel 11.7 Telecommunicatiewet) bij. Vul de nummers pas in nadat je ze in de geldende tekst op wetten.overheid.nl hebt nagekeken, en doe dat in alle vier de documenten tegelijk.

De hoofdregel — (artikel 11.7 Telecommunicatiewet): ongevraagde communicatie voor commerciële, ideële of charitatieve doeleinden via elektronische berichten mag alleen met voorafgaande toestemming. In Nederland geldt dat ook zakelijk. Dat is strenger dan in veel andere lidstaten, waar b2b buiten schot blijft. "Elektronisch bericht" is techniekneutraal: e-mail, WhatsApp en een DM op een platform vallen er allemaal onder.

De uitzondering voor bestaande klanten (soft opt-in) — (artikel 11.7 Telecommunicatiewet): heb je iemand iets verkocht, dan mag je hem over je eigen, gelijksoortige producten of diensten mailen, mits hij zich bij het verkrijgen van het adres kon afmelden en dat in elk bericht opnieuw kan.

Identiteit en afmeldmogelijkheid — (artikel 11.7 Telecommunicatiewet): in elk bericht moet duidelijk zijn wie de afzender is en moet een werkende afmeldmogelijkheid staan.

De beperkte b2b-ruimte — (artikel 11.7 Telecommunicatiewet): voor contactgegevens die een rechtspersoon zelf heeft bestemd voor het ontvangen van dit soort communicatie, is er ruimte. Let op het woord rechtspersoon.

En hier zit ons probleem. Een eenmanszaak, een ZZP'er, een vennoot in een vof, een maat in een maatschap: dat zijn natuurlijke personen. De b2b-ruimte geldt voor hen niet. Voor die groep geldt gewoon opt-in, of de soft opt-in bij een bestaande klantrelatie. En "ZZP" staat als eerste in onze doelgroep.

De conclusie, zonder omweg:

• Koude e-mail naar geschraapte adressen van eenmanszaken en ZZP'ers is niet toegestaan. Ook niet als het adres openbaar op een website staat. Ook niet met een nette afmeldlink. Dit onderdeel van de acquisitiepijplijn moet uit.
• Koude WhatsApp is verboden voor acquisitie, voor iedereen, ongeacht rechtsvorm.
• Een commerciële DM op LinkedIn is een elektronisch bericht en krijgt dus dezelfde toets. Naar een eenmanszaak of ZZP'er dus niet zonder toestemming. Wat wél kan op LinkedIn: een connectieverzoek sturen en reageren op wat iemand zelf publiceert.
• Telefonisch koud benaderen van natuurlijke personen mag niet zomaar. Het Bel-me-niet-register is per 1 juli 2021 afgeschaft en vervangen door een opt-in-regime voor telemarketing richting natuurlijke personen: vooraf toestemming, of een bestaande klantrelatie binnen de daarvoor geldende grenzen. Omdat wij zelf betogen dat ZZP'ers natuurlijke personen zijn, kunnen we telefoon niet als vrije route opvoeren. In versie 2.0 stond "Bel-me-niet-regels controleren" — dat was feitelijk onjuist en is hiermee gecorrigeerd.

Wat wél mag:

Toezicht: de Autoriteit Consument & Markt handhaaft artikel 11.7 Tw. De AP gaat over de gegevensverwerking eronder. Dat zijn twee sporen, geen keuzemenu.

Actie: de doelgroeplijsten opsplitsen op rechtsvorm vóór 2 augustus, en de e-mailpijplijn zo inrichten dat een rij zonder aantoonbare grondslag technisch niet verzonden kán worden — hetzelfde fail-closed-principe als bij de disclosure.

5. De machineleesbare markering (art. 50 lid 2) — wat we moeten bouwen

Lid 2 vraagt een markering die machines kunnen lezen, in een formaat dat doeltreffend, interoperabel, robuust en betrouwbaar is "voor zover technisch haalbaar". De zichtbare zin uit §3 dekt lid 1, niet lid 2.

Vastleggen dat het is gebeurd. Elke uitgaande boodschap krijgt in het logboek de velden markering_toegepast (ja/nee), markering_id, markering_versie. De combinatie verstuurd = ja en markering_toegepast = nee bestaat niet, want fail-closed. Komt hij toch voor, dan is dat een incident dat wordt onderzocht en vastgelegd.

Wat we níét doen: verwijzen naar Microsoft, xAI of een andere leverancier als oplossing. Voor de teksten zijn wij de aanbieder. Dat een leverancier misschien ook markeert is meegenomen, geen grondslag.

6. De architectuur achter de beloftes: sleutels, beheerkanaal en kostenbewaking

Op 31 juli 2026 is dit gebouwd en getest. De beschrijving die tot vandaag in de publieke documenten stond, is daarmee achterhaald en overal vervangen. Dit is de stand van vandaag; wijzigt de architectuur, dan wijzigen deze alinea's mee en gaat de pakketversie omhoog.

6.1 Sleutels — wat er van de klantmachines af is

Was: de gedeelde Composio-projectsleutel stond op elke klant-server. De AgentMail-mastersleutel ook.

Is:

• Er draait een broker op de hub. De klant-server praat niet rechtstreeks met Composio maar via die broker.
• De klant-server kent alleen een eigen token: een HMAC, dus een afgeleide handtekening en geen elders bruikbaar geheim. Het token werkt uitsluitend voor die ene klant.
• De gedeelde projectsleutel staat uitsluitend op de hub.
• Elke klant heeft een eigen Composio-sessie met een eigen gebruikers-id en een eigen sessie-URL.
• Voor AgentMail is de mastersleutel van de klantmachines gehaald; elke klant heeft nog uitsluitend een sleutel die zijn eigen mailbox ziet.

Wat gedeeld blijft, en dus in de openbare documenten moet blijven staan: het Composio-projectaccount zelf is er één, en de hub houdt de sleutel daarvan. De isolatie tussen klanten bestaat dus uit drie lagen tegelijk (eigen server, eigen sessie met eigen gebruikers-id, eigen token), niet uit een apart account per klant. Dat is een eerlijker en sterker verhaal dan wat er stond, maar het is geen "volledig gescheiden accounts" en zo moeten we het ook nooit opschrijven.

Gevolg voor het risicoprofiel: de hub is nu het waardevolste doelwit in de keten. Behandel hem daarnaar: aparte machine, geen andere functies, default-deny naar buiten, alle brokerverkeer gelogd, en de sleutelrotatie via het kanaal uit §6.2.

6.2 Het beheerkanaal — wat het is en wat het niet kan

• Na oplevering hebben wij geen toegang tot de klant-server. De provisioningsleutel wordt ingetrokken.
• De server haalt elk kwartier werk op bij ons. Wij duwen niets naar binnen.
• Hij voert uitsluitend opdrachten uit een vaste, korte lijst uit: een instelling wijzigen, een instelling verwijderen, een versienummer noteren, of zijn toestand rapporteren. Geen willekeurige code, geen shell, geen toegang tot bestanden of gegevens.
• Elke opdracht en elk resultaat wordt vastgelegd, en dat log is voor de klant inzichtelijk.
• Doel van het kanaal: sleutels kunnen vervangen en instellingen kunnen corrigeren zonder ooit in de omgeving van de klant te kijken.

Wat er niet mee kan, en wat we dus nog moeten regelen: een storing die alleen ter plekke te verhelpen is, en het bijwerken van het besturingssysteem. Zolang [NOOD- EN UPDATEPROCEDURE] niet is uitgeschreven, mag op de publieke pagina niet staan dat wij "de beveiligingsupdates installeren". Dat is nu een open veld en dat moet het blijven tot het klopt. Dit is een blokkade voor publicatie van de zin, niet voor de hele pagina.

6.3 Kostenbewaking — beveiligingsmaatregel én dienstbeperking

• Elke klant-server meldt elk uur zijn eigen modelverbruik.
• Bij 70% van het maandbudget volgt een waarschuwing.
• Bij overschrijding wordt de modelsleutel van die server automatisch verwijderd. Daarna zijn er geen betaalde AI-aanroepen meer mogelijk tot wij dat herstellen.

Juridisch is dit twee dingen tegelijk en beide moeten opgeschreven worden. Het is een beveiligings- en beheersmaatregel (artikel 32 AVG, en bewijs dat wij grip houden op een systeem dat zelfstandig kosten maakt). En het is een beperking van de dienst: bij extreem verbruik valt de AI-medewerker stil. Een dienstbeperking die je niet vooraf noemt, is een gebrek. Daarom staat het in deel 1 én hoort het als uitdrukkelijke beperking in de algemene voorwaarden, met het budget per klant erbij.

7. Doorgifte naar de Verenigde Staten — invullen vóór de eerste klant

Hoofdstuk V AVG eist dat de grondslag per ontvanger vóór de eerste doorgifte vaststaat. "EU-VS Data Privacy Framework voor zover gecertificeerd, anders standaardcontractbepalingen" is geen grondslag maar een voorbehoud. Dat moet uit alle vier de documenten en uit deze tabel.

Microsoft ontbrak in deze tabel, terwijl de algemene voorwaarden er wél iets over zeiden en de publieke pagina "niet van toepassing" invulde. Drie verschillende antwoorden op dezelfde vraag. Vanaf nu staat in alle documenten dezelfde regel met hetzelfde invulveld en dezelfde controledatum.

Hoe je dit invult, en het is werk dat jij zelf moet doen:

1. Zoek de partij op in de officiële DPF-lijst op dataprivacyframework.gov. Noteer de datum waarop je keek.

2. Controleer niet alleen óf ze erop staan, maar ook of de certificering actief is en of ze de juiste datacategorie dekt. Een certificering die alleen HR-gegevens dekt, dekt onze klantcommunicatie niet.

3. Staat de partij er niet op, of dekt de certificering de lading niet: teken standaardcontractbepalingen module 3 (verwerker naar subverwerker — dat is onze positie) en voer een overdrachtstoets uit. Leg die toets schriftelijk vast, inclusief de aanvullende maatregelen die eruit volgen.

4. Zet de uitkomst per partij in bijlage 1 van de verwerkersovereenkomst, in de privacyverklaring en in de tabel op de publieke pagina. Dezelfde uitkomst, dezelfde datum, overal.

5. En de hub zelf: die draait bij Hetzner Online GmbH in datacenter Falkenstein, Duitsland (EU). Dat is binnen de EU, dus op dat punt is er geen doorgifte naar buiten de EU.

6. Herhaal dit minstens jaarlijks en bij elke wijziging in de keten.

Composio, AgentMail en xAI zijn relatief jonge Amerikaanse bedrijven. Ga er niet van uit dat ze gecertificeerd zijn. Dit is een harde blokkade richting de eerste klant.

8. Hoe je aantoont dat je eraan voldoet

Toezicht draait niet om of je het goed bedoelde, maar of je het kunt laten zien.

8.1 Disclosure- en markeringsregister

Eén bestand met alle standaardteksten uit §3 en alle markeringen uit §5, elk met een id, een versienummer, de datum vanaf wanneer die versie in gebruik is, en het kanaal waar hij hoort. Onder versiebeheer. Verander je een zin, dan komt er een nieuwe versie bij en blijft de oude staan. Zo kun je van elk bericht uit het verleden laten zien welke tekst er destijds onder stond.

Dit register is de enige bron van de AI-vermelding. De algemene voorwaarden, de privacyverklaring en de publieke pagina citeren eruit en verwijzen naar het registernummer. Ze schrijven de zin niet opnieuw op in eigen woorden. Dat is precies hoe er in versie 2.0 twee formuleringen naast elkaar konden bestaan.

Er staat geen enkel telefoon-id in dit register, en dat is geen omissie: wij leveren geen telefonie. Komt dat er ooit, dan is dat een nieuw kanaal met een eigen DISC-nummer, een eigen fail-closed-regel en een eigen logveld — en niet een zin die alvast ergens beloofd wordt.

8.2 Logging per uitgaand bericht

Log per bericht in elk geval:

• bericht_id, tijdstempel (UTC), kanaal, richting, klant_id
• afzender_identiteit (Mike, of de AI-medewerker van welke klant)
• ontvanger_hash (gepseudonimiseerd)
• disclosure_toegepast (ja/nee), disclosure_id + versie, positie (opening / handtekening / beeldlabel / gesproken)
• markering_toegepast (ja/nee), markering_id + versie
• grondslag_benadering (toestemming / bestaande klant / rechtspersoon-gepubliceerd adres / inbound) en bron_van_het_adres — voor artikel 11.7 Tw en artikel 14 AVG
• modus: concept of autonoom
• goedgekeurd_door (id van de mens) en goedkeuring_tijdstip, als het een concept was
• model + versie, promptversie
• escalatie (ja/nee) + reden
• afmelding_ontvangen + blokkering_tijdstip
• bij video: stem_id, azure_regio, beeldlabel_aanwezig, gesproken_disclaimer_aanwezig, c2pa_aanwezig
• vanuit het beheerkanaal (§6.2): opdracht_id, opdracht_type, tijdstip, resultaat

Twee logboeken, niet één — dit is nieuw en het lost een praktisch probleem op. Een gehashte ontvanger is prima voor analyse, maar waardeloos als bewijs dat je een bepaald bericht met een geldige grondslag naar een bepaald adres hebt gestuurd, en ook waardeloos als de klant inzage wil. Daarom:

• In het analytische log (bij ons, over alle klanten heen): alleen ontvanger_hash, geen adressen in platte tekst.
• In de omgeving van de klant zelf (op zijn eigen server, onder zijn eigen zeggenschap): het herleidbare auditlogboek met adres, grondslag en bron. Dat is het logboek waarop hij recht op inzage heeft en waarmee hij zich verweert tegen een klacht bij de ACM of een verzoek onder artikel 14 AVG.

De koppeling tussen beide is de hash plus het bericht_id. Zo hoeven wij geen adressenbestand van onze klanten aan te leggen om toch te kunnen bewijzen dat het proces heeft gewerkt.

Bewaartermijn, één regel, in elk document gelijk: het auditlogboek wordt 12 maanden bewaard tijdens de looptijd; bij beëindiging gaat het logboek mee in de export en wordt het uiterlijk op de dertigste dag na einde vernietigd, samen met server, sleutel en back-ups. Dat lost de botsing op die er tot deze ronde in het pakket zat: 12 maanden bewaren stond tegenover alles vernietigen op dag 30. Er blijft dus na dag 30 geen auditlogboek bij ons achter. Wil een klant het langer houden, dan moet hij het binnen die 30 dagen exporteren; die zin hoort in de algemene voorwaarden en in de verwerkersovereenkomst te staan.

Artikel 50 zelf zegt niets over logbewaring; dit is bewijsvoering. Voor hoog-risicosystemen schrijven artikel 19 en artikel 26 lid 6 minimaal zes maanden voor — die artikelen gelden hier niet, maar het is nuttig om te weten dat twaalf maanden daar sowieso boven zit als er ooit een hoog-risicotoepassing bij zou komen.

Alles wat je logt met disclosure_toegepast = nee of markering_toegepast = nee en dat toch verstuurd is, is een incident. Als het goed is bestaat die combinatie niet, omdat het fail-closed is (§3.4).

8.3 Steekproef

Elk kwartaal 20 verstuurde berichten per kanaal handmatig nakijken: staat de juiste zin er, op de juiste plek, in de juiste versie, en is de kop uit MARK-001 bij aankomst nog aanwezig? Uitkomst in één regel vastleggen met datum en wie het deed. Kost een half uur en is het enige stuk papier waarmee je laat zien dat je actief controleert in plaats van hoopt.

8.4 Testen in de bouwstraat

Eén automatische test per kanaal die faalt als een gegenereerd bericht de disclosurezin of de machineleesbare markering mist. Eén die faalt als een adres zonder geldige grondslag_benadering door de verzendroute komt. En één die faalt als het beheerkanaal een opdracht accepteert die niet op de vaste lijst van §6.2 staat. Die tests draaien bij elke wijziging. Dit is het goedkoopste bewijs dat er is en het voorkomt dat een refactor de zin stilletjes sloopt.

Concreet, als checklist voor de bouw:

1. E-mail: bericht genereren, versturen naar een eigen testmailbox, ontvangen bericht ophalen en controleren op DISC-009 in de eerste alinea, DISC-010 in de handtekening en de koppen uit MARK-001. Faalt als één daarvan ontbreekt.

2. WhatsApp: bericht genereren en controleren dat de eerste regel exact gelijk is aan DISC-009 (stringvergelijking, geen "bevat ongeveer").

3. Chat: het venster laden en controleren dat DISC-005 zichtbaar is vóórdat de bezoeker kan typen.

4. Video: een testvideo renderen en controleren op beeldlabel vanaf frame 0, de gesproken zin in de eerste seconden en een leesbare C2PA-inbedding in het bestand.

5. Fail-closed: een bericht bouwen waarin de disclosuretemplate met opzet leeg is, en controleren dat het in de conceptenmap belandt en niet wordt verstuurd.

6. Grondslag: een adres zonder grondslag_benadering door de verzendroute duwen en controleren dat het wordt geweigerd.

7. Beheerkanaal: een opdracht buiten de vaste lijst aanbieden en controleren dat de klant-server hem weigert en de weigering logt.

8. Kostenplafond: het verbruik kunstmatig over het budget duwen en controleren dat de modelsleutel wordt verwijderd en er daarna geen betaalde aanroep meer lukt.

8.5 De publicatiegate — en waarom dit geen formaliteit is

Deel 1 belooft: fail-closed naar de conceptenmap, een kop op élke uitgaande AI-mail, directe blokkering op "stop" met één bevestiging, logging van de markering per bericht, C2PA in videobestanden, een kwartaalsteekproef, en een beheerkanaal dat alleen vier soorten opdrachten uitvoert.

Klopt er één van die beloftes niet op de dag van publicatie, dan is dat niet alleen een risico onder de AI-verordening. Het is dan ook een misleidende mededeling in de zin van artikel 6:194 BW richting zakelijke afnemers, en oneerlijke handelspraktijk richting consumenten. Dat is een aansprakelijkheidsgrond waar geen exoneratie in onze eigen voorwaarden tegen helpt.

Daarom: deel 1 gaat pas online als de acht tests uit §8.4 zijn gedraaid en per test is genoteerd: datum, uitkomst, wie het deed. Eén regel per test volstaat. Zonder die acht regels geen publicatie, ook niet "alvast, want het is bijna 2 augustus".

Zolang [NOOD- EN UPDATEPROCEDURE] leeg is, mag op de publieke pagina niet staan dat wij beveiligingsupdates installeren. Nu staat er een open veld; dat is de eerlijke variant en die mag blijven staan tot de procedure er is.

8.6 Nog even over de boete

Overtreding van artikel 50 valt onder artikel 99 lid 4: tot 15 miljoen euro of 3% van de wereldwijde jaaromzet, het hoogste van de twee. Voor het mkb en start-ups geldt op grond van artikel 99 lid 6 het laagste van die twee. Dat maakt het risico voor ons in euro's beperkt, maar het reputatierisico niet: een AI-bedrijf dat betrapt wordt op een AI die zich voordoet als mens, verkoopt daarna niets meer.

Voor artikel 11.7 Tw geldt een eigen boeteregime van de ACM, los van dit alles.

9. Grenzen die al gelden: hoog risico, verboden praktijken, AI-geletterdheid

9.1 Werving en selectie is hoog risico

Dit is het onderwerp waar het misgaat, want het klinkt als gewoon administratief werk.

Bijlage III, punt 4 onder a van de AI-verordening merkt aan als hoog risico: AI-systemen bedoeld voor werving of selectie van personen, met name voor gerichte vacatureadvertenties, het analyseren en filteren van sollicitaties en het beoordelen van kandidaten. Punt 4 onder b voegt daaraan toe: besluiten over promotie of beëindiging, taaktoewijzing op basis van gedrag of persoonskenmerken, en het monitoren en beoordelen van prestaties.

Als een klant onze AI-medewerker inzet om sollicitanten te screenen, wordt dat systeem hoog risico — en worden wij aanbieder van een hoog-risicosysteem. Dan komt er een pakket bij dat we vandaag niet hebben: risicobeheersysteem, datagovernance, technische documentatie, automatische logging, gebruiksaanwijzing voor de gebruiksverantwoordelijke, menselijk toezicht by design, eisen aan nauwkeurigheid en cyberbeveiliging, een kwaliteitsmanagementsysteem, een conformiteitsbeoordeling, CE-markering en registratie in de EU-databank. Plus verplichtingen voor de klant zelf uit artikel 26 — dat is de enige plek in dit memo waar artikel 26 thuishoort: menselijk toezicht door bekwame mensen, logs bewaren, en werknemers vooraf informeren.

Reken op maanden werk. Dat is voor nu geen optie.

Verbieden in de voorwaarden — per toepassing, niet per sector. Bijlage III verbiedt geen bedrijfstakken maar specifieke toepassingen daarbinnen. Een taalschool of een installateur van waterleidingen mag onze AI-medewerker gewoon voor klantenmail gebruiken. Formuleer dus zo:

Het is niet toegestaan de AI-medewerker in te zetten voor werving en selectie of voor beslissingen over werknemers. Daaronder valt in elk geval: het beoordelen, scoren, rangschikken of filteren van sollicitanten, het opstellen van gerichte vacatureadvertenties op basis van persoonskenmerken, en het beoordelen of monitoren van prestaties, promotie, taaktoewijzing of ontslag van werknemers.

Dezelfde logica geldt voor zorg. Ook daar is de grens de toepassing en niet de sector: verboden is zorggerelateerde communicatie en het verwerken van patiëntgegevens, niet "de zorgsector". Een fysiotherapiepraktijk mag de AI-medewerker gebruiken voor facturatie en leveranciersmail. Beëindigen wij op deze grond, dan betalen wij naar rato terug over de resterende periode. Beëindigen zonder restitutie terwijl de klant niets heeft verzwegen, houdt geen stand onder artikel 6:248 lid 2 BW — dat is precies het soort beding waar een rechter overheen stapt.

Technisch afdwingen waar het kan. Een detectie op cv-achtige bijlagen en sollicitatietermen die een waarschuwing aan de klant en aan ons oplevert. Perfect wordt dat niet, maar "wij wisten van niets" is geen verweer als je het had kunnen zien.

Vragen bij het onboarden. Twee vinkjes: gebruikt u de AI-medewerker voor sollicitaties of personeelsbeoordeling? En: gebruikt u hem voor patiëntcontact of patiëntgegevens? Ja = niet leveren, of eerst met elkaar praten.

Wat wél mag — zuiver voorbereidend en administratief werk, zonder oordeel over de persoon:

• Een ontvangstbevestiging sturen op een sollicitatie.
• Een gesprek inplannen dat een mens al heeft besloten te voeren.
• Een sollicitatiemail letterlijk doorsturen of archiveren.
• Een neutrale samenvatting maken van feitelijke gegevens, zónder oordeel, score of rangorde.

De valkuil. Artikel 6 lid 3 kent een uitzondering voor systemen die alleen een enge procedurele of voorbereidende taak doen. Maar diezelfde bepaling zegt: die uitzondering geldt nooit als het systeem profilering van natuurlijke personen uitvoert. Zodra de AI kandidaten met elkaar vergelijkt, een geschiktheidsoordeel geeft, een score toekent of een selectie maakt, ben je aan het profileren en is het hoog risico. De grens ligt bij oordelen, niet bij aanraken.

9.2 Verboden praktijken (artikel 5), sinds 2 februari 2025

Emotieherkenning op de werkvloer en in het onderwijs is verboden, op smalle uitzonderingen na. Bouw dus nooit iets dat "de toon van de sollicitant analyseert" of "de stemming van medewerkers meet". Dit is geen risicoklasse maar een verbod: er is geen conformiteitsroute die het alsnog mogelijk maakt.

9.3 AI-geletterdheid (artikel 4), sinds 2 februari 2025

Deze plicht ontbrak in het hele pakket en moet erin. Ze geldt sinds 2 februari 2025 voor aanbieders én gebruiksverantwoordelijken, ongeacht risicoklasse, en raakt dus zowel ons als elke klant. Neem in de algemene voorwaarden één alinea op met deze strekking, en gebruik dezelfde strekking op de publieke pagina:

Wij zorgen ervoor dat onze eigen mensen en onze klanten weten wat het systeem wel en niet kan: wat de AI-medewerker doet, waar zijn grenzen liggen, hoe je ziet dat hij iets fout heeft en wat je dan doet. De klant zorgt ervoor dat iedereen die bij hem met de AI-medewerker werkt, daarvoor is geïnstrueerd voordat hij ermee begint.

Praktisch bij één persoon: leg een half A4 vast met wat de AI-medewerker doet, waar zijn grenzen liggen en wat je doet bij een fout. Dat is meteen je onboardingdocument voor klanten en meteen je bewijs dat je aan artikel 4 hebt gedacht. Noteer de datum en de versie erop.

10. Overzicht in één tabel

11. Actielijst vóór 2 augustus 2026

12. Wat dit memo van de andere drie documenten vraagt

De verwerkersovereenkomst en de privacyverklaring zijn in deze ronde niet meegetoetst. Zolang dat niet is gebeurd, is de kruisconsistentie van termijnen, subverwerkers en doorgiftegrondslagen niet vastgesteld. Dat is een openstaand punt en geen afgeronde zaak. Deze lijst is de minimale set wijzigingen die uit dit memo volgt.

Algemene voorwaarden

1. Artikel 1: definitie van "gesprek" opnemen (§3).

2. Artikel 2 lid 5: toevoegen "met uitzondering van de artikelen 8 en 10, waarvan niet ten nadele kan worden afgeweken", zodat een individuele afspraak de AI-vermelding en het verbod op verboden gebruik niet kan uithollen.

3. Artikel 2 lid 3: de zorguitsluiting versmallen tot zorggerelateerde communicatie en patiëntgegevens, met terugbetaling naar rato bij beëindiging op die grond.

4. Artikel 5 lid 2: kanalen zijn e-mail en WhatsApp (plus het chatvenster op onze eigen site). Telefonie schrappen.

5. Artikel 7 lid 5: de verwijzing naar artikel 26 AI-verordening vervangen door artikel 50 lid 4 plus de eigen contractuele afspraak over menselijk toezicht.

6. Artikel 7 lid 6 en artikel 22: één bewaarregel voor het auditlogboek, letterlijk zoals in §8.2.

7. Artikel 8: DISC-009 letterlijk citeren met vermelding van het registernummer; de telefoonbelofte schrappen.

8. Artikel 16: de Microsoft-regel identiek maken aan §7 van dit memo, met hetzelfde invulveld en dezelfde controledatum.

9. Artikel 19 lid 1: het bodembedrag ongewijzigd laten; dit memo neemt het over in §2.

10. Artikel 24 lid 4: artikel 9 (vrijwaring bij verboden gebruik) toevoegen aan de bepalingen die het einde van de overeenkomst overleven.

11. Nieuwe bepaling: de dienstbeperking uit §6.3 (kostenplafond met automatische noodrem), met het maandbudget per klant.

12. Nieuwe alinea: AI-geletterdheid (§9.3).

13. Beschrijving van het beheerkanaal (§6.2), inclusief het intrekken van de provisioningsleutel.

Verwerkersovereenkomst

14. Bijlage subverwerkers: broker-architectuur beschrijven zoals in §6.1, inclusief wat gedeeld blijft; AgentMail-sleutel per klant.

15. Bijlage doorgifte: dezelfde tabel en dezelfde controledata als §7, inclusief Microsoft.

16. Beveiligingsmaatregelen: beheerkanaal met vaste opdrachtenlijst, logging daarvan, en het kostenplafond als beheersmaatregel.

17. Logboek: dezelfde bewaarregel, plus de gescheiden bewaring uit §8.2 (hash bij ons, herleidbare gegevens in de klantomgeving) met de grondslag erbij.

18. Vernietiging op dag 30: server, sleutel, back-ups én logboek, na export.

Privacyverklaring

19. Doorgiftetabel identiek aan §7, inclusief Microsoft en de hub.

20. Bewaartermijnentabel identiek aan die in deel 1.

21. Prospectgegevens: 12 maanden na laatste contact, met verwijzing naar DISC-014.

Alle vier

22. Op elk document: pakketversie 1.0, 31 juli 2026, plus de eigen documentversie eronder.

23. Overal dezelfde AI-vermelding, letterlijk uit DISC-009, met registernummer.

24. Nergens telefonie als kanaal of belofte.

25. Overal " (artikel 11.7 Telecommunicatiewet)" bij artikel 11.7 Tw, tot de nummers zijn geverifieerd.

Dit memo is opgesteld op basis van de tekst van Verordening (EU) 2024/1689 en de Telecommunicatiewet zoals bekend bij het opstellen, en op basis van de architectuur zoals die op 31 juli 2026 is gebouwd en getest. Controleer vóór publicatie van deel 1 de wetsverwijzingen tegen de actuele tekst, en of de Europese wetgever de toepassingsdata of uitvoeringsregels nog heeft gewijzigd — er is in Brussel gesproken over uitstel van onderdelen van de verordening. Ga niet uit van uitstel dat niet officieel in het Publicatieblad staat. Wijzigt de architectuur, dan wijzigt §6 mee en gaat de pakketversie omhoog. Laat een jurist meelezen op de definitieve versie.

Opgesteld op 31 juli 2026. Documentversie 2.1, onderdeel van pakketversie 1.0.