AI en websitebeveiliging: slim werken met controle

Wat weten we over AI en aanvallen?

Het Britse NCSC verwacht in zijn beoordeling richting 2027 dat AI onderdelen van cyberaanvallen effectiever en efficiënter maakt. Dat is een algemene dreigingsinschatting met waarschijnlijkheden. Het is geen bewijs dat een bepaalde website is aangevallen en evenmin bewijs dat een specifiek model een bepaalde fout zelfstandig ontdekte. Bron: NCSC, Impact of AI on cyber threat from now to 2027.

Dat onderscheid is belangrijk wanneer een nieuwsbericht wordt doorgestuurd met een stellige samenvatting. Een bericht kan een onderzoeker noemen, een leverancier bedanken of beschrijven dat software tijdens onderzoek is gebruikt. Daaruit volgt niet automatisch hoeveel van het werk door AI werd gedaan. Zonder een controleerbare beschrijving van dat onderzoek nemen wij zulke conclusies niet over.

Ook bij de huidige PHP-melding koppelen we geen modelnaam aan autonome ontdekking zonder daarvoor specifiek bewijs te hebben. Je hoeft op dat bewijs bovendien niet te wachten om je eigen situatie te laten controleren. De relevante vraag is of jouw omgeving aan de kwetsbare voorwaarden voldoet en welke maatregel daarvoor nodig is. De reputatie van de ontdekker verandert dat onderhoudswerk niet.

Een ondernemer heeft meer aan een beheerder die zegt welke informatie nog ontbreekt dan aan een beheerder die een spannend verhaal compleet maakt. Vraag bij stellige uitspraken daarom naar de oorspronkelijke melding. Is de conclusie letterlijk onderbouwd, of is het een interpretatie? Laat interpretaties gewoon zo noemen. Dat maakt een uitleg niet zwakker, maar bruikbaarder.

Denk in werkzaamheden, niet in een strijd tussen mens en machine

Een praktische manier om AI te beoordelen is de werkdag op te delen. Welke taak mag sneller? Welke taak moet zorgvuldig blijven? Een lange foutmelding samenvatten is iets anders dan een klantendatabase aanpassen. Een test voorstellen is iets anders dan een productieomgeving omzetten. Eén toestemming voor hulp bij de website hoort niet al die activiteiten tegelijk open te zetten.

Wij zouden bijvoorbeeld een assistent een geanonimiseerde lijst met softwareonderdelen laten ordenen. De uitkomst kan zijn dat een beheerder gemakkelijker ziet welke onderdelen eerst onderzocht moeten worden. Dat maakt de lijst nog niet actueel. Iemand moet controleren wanneer de gegevens zijn verzameld en of het daadwerkelijk de live omgeving betreft.

Hetzelfde geldt voor code. Een AI kan een voorstel schrijven dat een fout lijkt te herstellen. Daarna willen we weten welke bestaande werking geraakt wordt. Kan iemand nog inloggen? Komt een ingevuld formulier op de juiste plek aan? Kan een beheerder de wijziging terugdraaien? Een mooi codevoorbeeld beantwoordt die vragen niet vanzelf.

Als je dat onderscheid zichtbaar maakt, wordt het gesprek rustiger. Je hoeft AI niet volledig te verbieden en ook niet blind te vertrouwen. Je geeft het werk waarvoor controle mogelijk is, terwijl belangrijke beslissingen een herkenbare eigenaar houden. Wie zich verder wil verdiepen, vindt uitleg en praktische hulpmiddelen bij zelf leren.

Begin met een opdracht die klein genoeg is om te beoordelen

“Maak onze website veilig” klinkt ambitieus, maar is een onbruikbare opdracht voor een losse AI-sessie. Het eindpunt is onduidelijk. De beschikbare toegang is onbekend. Er staat niet bij welke klantprocessen behouden moeten blijven. Daardoor kan zelfs een goedbedoelde uitvoering een ander probleem oplossen dan jij bedoelde.

Een betere opdracht beschrijft het gewenste resultaat en de grenzen. Bijvoorbeeld: onderzoek waarom het contactformulier een fout geeft, gebruik alleen de testomgeving en verander niets aan de betaalinstellingen. Vraag eerst een beschrijving van de oorzaak, daarna een voorstel en pas vervolgens uitvoering binnen de afgesproken ruimte.

Voor een onderhoudstaak kan de opdracht nog concreter. Welke website, welke omgeving, welk onderdeel, welke uiterste tijd en welke terugvalmogelijkheid? Benoem ook wanneer het werk moet stoppen. Ontbreekt een actuele reservekopie, blijkt de fout groter dan gedacht of is er mogelijk toegang tot klantgegevens nodig? Dan is overleg onderdeel van goed werk.

Dit is geen pleidooi voor eindeloze toestemming bij iedere komma. Kleine tekstcorrecties hebben andere gevolgen dan wijzigingen in inloggen of betalen. Stem de controle af op het risico. De afspraak moet vooral voorkomen dat een beperkte opdracht ongemerkt verandert in een herbouw, accountmigratie of aanpassing van gegevens die niet in scope stonden.

Toegang is een technische afspraak, geen goede bedoeling

Een assistent die alleen een rapport moet lezen, heeft geen reden om dat rapport te kunnen verwijderen. OWASP noemt te ruime functionaliteit, rechten en zelfstandigheid als oorzaken van het risico dat het “Excessive Agency” noemt. Die indeling is een bruikbaar vertrekpunt voor het beoordelen van een AI-koppeling. Bron: OWASP, LLM06:2025 Excessive Agency.

Onze praktische invulling begint met een klein toegangsoverzicht. Daarin staat niet alleen de naam van de tool, maar ook het account, de omgeving en de toegestane handelingen. “Toegang tot de website” zegt te weinig. “Voorstel maken voor drie contentbestanden in een aparte werkomgeving” is veel beter te begrijpen en achteraf te controleren.

Laat daarnaast opschrijven wie die toegang kan intrekken. Als een samenwerking stopt, moet je niet hoeven uitzoeken welke losse accounts ooit zijn aangemaakt. Een vertrekprocedure hoort bij de inrichting. Hetzelfde geldt als een medewerker van rol verandert of een tijdelijke leverancier klaar is met zijn opdracht.

Een nuttige proef is om een taak bewust te laten mislukken buiten de toegestane ruimte. Kan een hulpmiddel met alleen leesrechten toch een wijziging opslaan? Kan een testaccount een echte klant zien? Zulke controles laat je uitvoeren binnen een expliciet afgesproken test. Niet op goed geluk op een klantomgeving, en niet door iemand zonder toestemming.

Wat je niet in een prompt zet

Een wachtwoord, API-sleutel of sessiecookie is geen handige context. Het is toegang. Kopieer daarom geen volledige instellingenbestanden naar een chat om een fout sneller uit te leggen. Vaak kun je de naam van een instelling, het type fout en een onschadelijk voorbeeld delen zonder de werkelijke waarde prijs te geven.

Wij zouden ook geen complete klantenlijst toevoegen wanneer de vraag over de vormgeving van een formulier gaat. Het ontwerp heeft meestal genoeg aan fictieve invoer. Denk aan een verzonnen bedrijfsnaam, een duidelijk voorbeeldadres en een aanvraag zonder persoonlijke bijzonderheden. Die voorbeelden moeten herkenbaar testmateriaal blijven en niet in rapportages als echte leads verschijnen.

Een logbestand verdient dezelfde aandacht. Tussen gewone foutregels kunnen adressen, tokens, bestelnummers of inhoud uit een formulier staan. Laat een bevoegde beheerder vooraf bepalen welke regels relevant zijn en gevoelige velden verwijderen. Het doel is de fout begrijpen, niet zoveel mogelijk informatie verzamelen omdat uploaden gemakkelijk is.

Is een geheim toch gedeeld? Verwijderen uit de chat is niet hetzelfde als het ongeldig maken. Laat de verantwoordelijke beheerder beoordelen welke toegang vervangen moet worden en waar die waarde verder gebruikt wordt. Gebruik daarbij het eigen incidentproces. Dit artikel biedt geen bevestiging dat een specifieke leverancier die gegevens heeft bewaard of ingezien.

Een voorstel moet begrijpelijk zijn voordat het wordt uitgevoerd

Een goede wijzigingsbeschrijving bestaat voor ons uit vier onderdelen: wat er misgaat, wat er verandert, wat bewust niet verandert en hoe het resultaat wordt gecontroleerd. Dat past vaak in een korte alinea. Ontbreekt één onderdeel, dan is er meestal nog denkwerk nodig voordat uitvoering verstandig is.

Stel dat een fictieve onderhoudstaak het uploaden van afbeeldingen raakt. “Upload veiliger gemaakt” is dan geen voldoende beschrijving. We willen weten welke bestanden toegestaan blijven, wat een bezoeker ziet bij een afwijzing en of bestaande afbeeldingen gewoon bereikbaar blijven. Dat zijn vragen over gebruikersgedrag, niet alleen over codekwaliteit.

Laat een AI ook aangeven waar het niet zeker van is. Een afhankelijkheid kan onbekend zijn, een testomgeving kan afwijken of een externe koppeling kan niet bereikbaar zijn. Die beperkingen horen naast het voorstel te staan. Ze mogen niet verdwijnen in een enthousiaste slotsamenvatting met “alles opgelost”.

Bij een grotere technische verandering kan een afzonderlijke beoordeling nuttig zijn. Die beoordeling moet het daadwerkelijke verschil bekijken, niet alleen de uitleg van degene die het maakte. Een tweede AI die dezelfde samenvatting herhaalt, is nog geen onafhankelijke controle. De beoordelaar heeft eigen bewijs nodig om iets zinnigs te kunnen zeggen.

Test het klantproces, niet alleen de nieuwe regel code

Een website is pas bruikbaar wanneer mensen hun doel kunnen bereiken. Wij zouden een wijziging aan een aanvraagformulier daarom niet alleen beoordelen op een groen testresultaat. We willen ook zien wat er gebeurt na verzending: duidelijke bevestiging, juiste bestemming, herkenbare registratie en geen dubbele aanvraag bij opnieuw klikken.

Dat hoeft niet iedere keer met echte klantgegevens. Spreek testgegevens af en houd ze herkenbaar. Wil je een echte e-mailbezorging controleren, gebruik dan een adres waarvoor je toestemming hebt en beperk de inhoud. Het ontvangen van één testbericht bewijst bovendien niet dat alle toekomstige berichten onder alle omstandigheden aankomen.

Denk ook aan afwijzingen. Een te lang bericht, een verplicht veld dat ontbreekt of een verlopen sessie zijn geen zeldzame randgevallen voor de gebruiker die ze meemaakt. De website moet daar begrijpelijk mee omgaan. Een assistent kan zulke situaties helpen bedenken; iemand moet vervolgens controleren wat de site werkelijk doet.

Voor technische basiscontroles kun je terecht bij onze uitleg over technische SEO. Die discipline overlapt deels met kwaliteit van een website, maar is geen vervanging voor een beveiligingsonderzoek. Een goed indexeerbare pagina kan nog steeds een onveilige beheerkoppeling hebben. Houd de doelen van iedere controle apart.

Behandel informatie van buiten als informatie

Een AI die een supportbericht leest, ziet tekst van iemand anders. Die tekst kan een verzoek bevatten dat niet bij de oorspronkelijke opdracht hoort. Bijvoorbeeld een instructie om een bestand te delen of een account te wijzigen. De aanwezigheid van zo'n instructie in een document maakt de afzender nog niet bevoegd.

Onze werkafspraak zou daarom zijn: een opgehaald document kan feiten bevatten, maar mag niet zelfstandig de opdracht uitbreiden. Een klantvraag gaat eerst door de normale beoordeling. Een gevonden handleiding wordt op relevantie en herkomst bekeken. Een foutmelding wordt onderzocht zonder instructies uit die foutmelding automatisch uit te voeren.

Voor een ondernemer is dit vooral herkenbaar als functiescheiding. Degene die een verzoek indient, bepaalt niet automatisch wie het uitvoert en welke toegang daarvoor wordt geopend. Dat blijft gelden als de eerste lezer een AI is. Leg uitzonderingen vast, zodat haast niet telkens een nieuwe werkwijze oplevert.

Bij het maken van koppelingen kan een schema helpen: welke bron levert gegevens, welke stap beoordeelt ze en welke stap mag iets veranderen? Het schema moet ook aangeven waar menselijke controle plaatsvindt. Een verbinding die eenvoudig te installeren is, kan anders ongemerkt meer bedrijfsprocessen raken dan aanvankelijk bedoeld.

Maak het werk overdraagbaar

Een assistent kan midden in een taak stoppen. Een browser kan de toegang verliezen. Een collega kan het overnemen. Daarom willen we een korte werkregistratie die niet afhankelijk is van één chatvenster. Daarin staan het doel, de laatste gecontroleerde toestand, de uitgevoerde wijzigingen en de eerstvolgende veilige stap.

Die registratie hoeft geen kopie van alle gesprekken te zijn. Juist een beknopt overzicht helpt. Noem bestanden of instellingen zonder geheime waarden. Zet erbij welke test werkelijk is uitgevoerd en wat nog niet is gecontroleerd. Onderscheid “klaargezet”, “gepubliceerd” en “live nagekeken”. Die woorden beschrijven verschillende toestanden.

Een simpel fictief voorbeeld: een formulieraanpassing is lokaal getest, maar de e-mailkoppeling was niet beschikbaar. De juiste overdracht is dan niet “formulier klaar”. Het is “formulierweergave getest; bezorging en registratie nog controleren”. Zo kan een volgende uitvoerder verder zonder een onbewezen aanname als uitgangspunt te nemen.

Dit geldt ook voor een overstap naar andere techniek. Een AI die een nieuwe site bouwt, heeft niet automatisch de oude klantrechten, bestanden en URL's behouden. Lees daarvoor onze aanpak voor overstappen zonder onnodig SEO-verlies. De overdracht van werk is onderdeel van kwaliteit, niet de administratie achteraf.

Een beslisroute voor jouw volgende AI-taak

Begin bij de gevolgen van een fout. Kan het werk alleen een concepttekst veranderen? Dan is een eenvoudige inhoudscontrole vaak passend. Kan het toegang, betaling, klantgegevens of bereikbaarheid raken? Dan willen we een concreter plan, een afgebakende testomgeving en een benoemde verantwoordelijke voor de uitvoering.

Gebruik vervolgens deze beslisroute:

1. Beschrijf in één zin wat na afloop aantoonbaar beter moet zijn.
2. Benoem de website, omgeving en bestanden of functies die binnen de opdracht vallen.
3. Bepaal welke gegevens daarvoor echt nodig zijn en welke niet gedeeld worden.
4. Laat eerst een voorstel maken wanneer de gevolgen niet eenvoudig terug te draaien zijn.
5. Spreek af welke praktijktest nodig is voordat het werk klaar mag heten.
6. Controleer na publicatie het werkelijke resultaat en bewaar een korte overdracht.

Dit is onze voorgestelde werkwijze, geen certificeringsnorm. Je kunt haar kleiner maken voor een eenvoudige taak en uitgebreider voor gevoelige processen. Het belangrijkste is dat de controle past bij wat er mis kan gaan. Een extra controle zonder duidelijke bedoeling voegt vooral vertraging toe.

Wil je jouw situatie bespreken, dan beginnen we bij wat de website doet en wie haar beheert. Niet bij een verplicht nieuw platform. Via plan een gesprek kun je dat voorleggen. Een bestaande WordPress-website kan een andere aanpak nodig hebben dan een kleine informatieve site zonder accounts.

Vijf vragen die wij aan een AI-voorstel stellen

Waar komt deze conclusie vandaan?

We willen kunnen terugzien of het antwoord op actuele gegevens, een gelezen bestand of een algemene veronderstelling rust. Een verwijzing naar een handleiding is nuttig, maar bewijst niet dat onze omgeving hetzelfde is ingericht. De conclusie hoort bij het bewijs dat werkelijk beschikbaar is.

Wat gebeurt er als de aanname onjuist is?

Een onjuiste aanname over een kleur heeft andere gevolgen dan een onjuiste aanname over een database. Door dat vooraf te benoemen, wordt duidelijk welke controles eerst nodig zijn. Soms is de beste volgende stap geen wijziging, maar één ontbrekend gegeven ophalen bij de bevoegde beheerder.

Welke bestaande werking blijft behouden?

Vraag expliciet naar het klantproces dat niet mag veranderen. Een nieuwe pagina mag mooi zijn, maar de bestaande login en betaling moeten blijven werken. Een voorstel dat alleen het nieuwe onderdeel beschrijft, kan belangrijke afhankelijkheden buiten beeld laten. Maak behoud daarom onderdeel van de opdracht.

Wat is werkelijk getest?

“De tests zijn groen” krijgt pas betekenis met de testnaam, de omgeving en het resultaat. Een controle op tekstweergave zegt weinig over een webhook of een e-mail. Laat de uitvoerder ook de niet geteste onderdelen noemen, zonder die automatisch als geblokkeerd of afgerond te bestempelen.

Wat hebben we nodig om te stoppen of terug te gaan?

Een terugvalmogelijkheid moet bij de concrete wijziging passen. Denk aan een vorige publicatie, een gecontroleerde reservekopie of het uitschakelen van een nieuwe koppeling. Laat de beheerder beoordelen wat uitvoerbaar is. Meer achtergrond staat in backup en hersteltest.

Spreek af wat er gebeurt wanneer de assistent stopt

Een praktische afspraak die gemakkelijk wordt vergeten: wie merkt dat een geautomatiseerde taak niet is afgerond? Een assistent kan een deel van de controles uitvoeren en daarna geen toegang meer hebben tot een externe dienst. Zonder duidelijke status lijkt stilte dan op een geslaagde afronding.

Wij zouden voor terugkerend werk drie uitkomsten gebruiken: afgerond met bewijs, aandacht nodig of niet uitgevoerd. Daarbij hoort een verantwoordelijke die een melding kan beoordelen. De melding hoeft geen gevoelige foutinhoud te bevatten. Een verwijzing naar het betreffende proces en de ontbrekende controle kan voldoende zijn.

Vraag ook wanneer automatisch opnieuw proberen verstandig is. Een mislukte leesactie verschilt van een onzekere betaling of publicatie. Bij zo'n onzekere wijziging moet eerst worden vastgesteld wat al gebeurd is. Anders kan een goedbedoelde herhaling dubbele handelingen veroorzaken. Laat deze keuzes vooraf vastleggen door degene die de koppeling bouwt, zodat de assistent ze niet tijdens een storing hoeft te improviseren.

Veelgestelde vragen over AI en websitebeveiliging

Verder lezen zonder opnieuw bij nul te beginnen

Deze pagina gaat over de manier van werken met AI. Voor de andere beslissingen binnen hetzelfde onderwerp kun je gericht verder:

• De PHP-kwetsbaarheid van oktober 2026 en wat je moet controleren.
• Wanneer een website zonder PHP past.
• PHP updaten met een plan voor continuïteit.
• De samenhang tussen WordPress, PHP en plugins.
• Wat Cloudflare wel en niet oplost rond PHP.
• Een backup beoordelen met een hersteltest.
• Een website voor €75 per maand en heldere beheerafspraken.
• Overstappen met behoud van belangrijke URL's en functies.
• Twintig beveiligingsvragen aan je webbureau.

Wil je weten wie je hierover spreekt? Bekijk over ons. Voor de commerciële mogelijkheden vind je meer op prijzen. Je hoeft geen complete beveiligingsanalyse aan te leveren om een gesprek te beginnen. Een duidelijke omschrijving van je website, je beheerder en je twijfel is een bruikbaar startpunt. Deel daarbij geen wachtwoorden of geheime sleutels.