De grootste bedreiging voor je bedrijfsgegevens komt vaak niet van buiten, maar van een simpele menselijke fout binnen je eigen organisatie. Dat blijkt uit twee ernstige datablunders bij AI-specialist Anthropic in één week, waarbij interne code en documenten per ongeluk publiek werden gemaakt.

Wat er aan de hand is

AI-bedrijf Anthropic heeft in korte tijd twee grote interne fouten gemaakt die gevoelige informatie blootlegden. Eerst werd de volledige broncode van de programmeertool Claude Code per ongeluk online gezet, bestaande uit ongeveer 1.900 bestanden en ruim 512.000 regels code. Een securityonderzoeker ontdekte dat de code publiek te downloaden was, waarna kopieën snel op GitHub verschenen. Het bedrijf noemt dit zelf een “menselijke fout”. Eerder diezelfde week was al interne documentatie over een nieuw AI-model, genaamd Mythos, openbaar geworden door een verkeerd geconfigureerde databank. Hierdoor kreeg de concurrentie inzicht in de werking van het systeem en vertrouwelijke ontwerpkeuzes.

Wat dit betekent

Dit nieuws onderstreept een fundamentele verschuiving in risicoperceptie. Voor veel ondernemers ligt de focus op het weren van externe hackers, maar deze incidenten tonen aan dat interne processen en menselijke handelingen minstens zo kwetsbaar kunnen zijn. Vooral voor MKB-bedrijven die werken met gevoelige klantdata, intellectueel eigendom of unieke bedrijfsprocessen is dit een belangrijk signaal. Een verkeerde configuratie, een foutieve toegangsinstelling of een onbedoelde upload kan je concurrentievoordeel direct tenietdoen. Het feit dat dit gebeurt bij een geavanceerd techbedrijf als Anthropic laat zien dat geen enkel bedrijf hier immuun voor is.

Hoe je dit kunt toepassen

De praktische les is niet om meer geld in complexe beveiligingssoftware te stoppen, maar om je interne procedures kritisch onder de loep te nemen. Het gaat om bewustwording en eenvoudige controles.

Als je gevoelige documenten of code deelt met teamleden… stel dan een eenvoudig ’tweepersonen-principe’ in voor het wijzigen van toegangsrechten of het publiceren van bestanden naar externe servers. Laat een tweede persoon controleren of een map of database echt ‘privé’ staat ingesteld voordat deze wordt gevuld.

Als je afhankelijk bent van clouddiensten voor opslag… plan dan een maandelijkse audit in van je gedeelde mappen en link-instellingen. Veel datalekken ontstaan doordat een map ooit tijdelijk ‘publiek’ werd gezet voor een specifiek project en daarna vergeten werd. Maak een checklist voor het afsluiten van projecten waarin het resetten van toegangsrechten een verplicht stap is.

Als je nieuwe software of tools in gebruik neemt… besteed dan specifiek aandacht aan de standaard privacy- en deelsettings tijdens de onboarding. Vaak staan deze standaard op ‘publiek’ of ‘bedrijf’ om samenwerking te stimuleren. Stel een bedrijfsbrede richtlijn op voor de initiële configuratie van nieuwe tools, waarbij de meest restrictieve instelling de norm is.

Als je een ontwikkelteam hebt dat met eigen code werkt… implementeer een pre-release checklist die niet alleen naar de code zelf kijkt, maar ook naar waar en hoe deze wordt opgeslagen. Zorg dat het per ongeluk pushen naar een publieke repository technisch wordt bemoeilijkt of ten minste een extra waarschuwing genereert.

De kern is om menselijke fouten niet te zien als individueel falen, maar als een systeemrisico dat je met eenvoudige, herhaalbare processen kunt mitigeren. Begin met het in kaart brengen van waar je meest gevoelige data ligt en wie daar toegang toe kan wijzigen.

Bron: Computable