De absorptiekloof: waarom wijzigingen sneller komen dan we ze kunnen accepteren

AI is in korte tijd de nieuwe standaardtechnologie geworden om bugs, UX-problemen of beveiligingsproblemen op te sporen. Dankzij AI worden die problemen nu op machinesnelheid gevonden (en opgelost), met fixes die in minuten worden opgesteld en honderden patches die in één cyclus worden uitgebracht.

Waar we niet beter in zijn geworden, is het veilig absorberen van al die wijzigingen. En absorptie is geen doorvoerprobleem dat u met automatisering kunt oplossen. Het is de menselijke handeling van opmerken, beoordelen en bepalen of een wijziging daadwerkelijk veilig is voordat die doorstroomt en daar bestaan op dit moment maar weinig varianten van die op machinesnelheid kunnen draaien.

Ontdekking en generatie zijn vooruitgesneld terwijl het vermogen om te zien en te beslissen is achtergebleven. De meeste echte problemen met massaal patchen komen voort uit die kloof en de kosten belanden niet bij degenen die de wijziging maken. In plaats daarvan rollen ze vaak door naar beneden, naar wie het minst is toegerust om ze op te vangen.

Wat de absorptiekloof doet met QA en IT Operations

De problemen met massaal patchen beginnen bij de Quality Assurance (QA)- en operationsteams die een grote patchronde moeten absorberen. Hun verdediging tegen een slechte wijziging was altijd tijd. Testfocus, pilotgroepen, gefaseerde uitrol en soak-periodes bestaan zodat een unieke storing wordt opgemerkt voordat die het hele wagenpark raakt. Tijd is het detectiemechanisme.

Maar wanneer veertig fixes tegelijk binnenkomen en er drie dagen later iets stukgaat (neem de recente cumulatieve updates van Microsoft Patch Tuesday september 2026, die leidden tot massale storingen in Remote Desktop Services (RDS) op Windows Server 2019, 2022 en 2025), kan niemand zeggen welke patch het probleem veroorzaakte, omdat er geen venster was waarin de variabelen geïsoleerd waren. De kwaliteit van de review van het team gaat omlaag ten gunste van snelheid.

Snellere patches zijn niet automatisch betere patches

Kijkt u verder stroomopwaarts, dan verklaart dezelfde kloof waarom zoveel patches oppervlakkig kunnen zijn. Wanneer de workflow door LLM’s wordt gegenereerd, verloopt “hier is de fout, hier is de fix” razendsnel terwijl begrip traag blijft. Een AI produceert in seconden een controle en een oplossing. Uitzoeken waaróm die bug bestaat en waar hetzelfde patroon nog meer voorkomt, kost nog steeds tijd – en een mens.

Omdat genereren goedkoop is en root-cause-analyse niet, verschuift het volume naar de goedkope kant. U krijgt puntfixes die elk één instantie dichten en de onderliggende zwakte intact kunnen laten, klaar om volgend kwartaal als een iets ander probleem opnieuw op te duiken. Het is dezelfde kloof in een ander jasje: fixes sneller maken dan we begrip opbouwen en het verschil uitleveren alsof het vooruitgang is.

Precies hier gaan mensen ervan uit dat automatisering de cirkel rondmaakt. Dat doet ze niet. Althans niet helemaal, nog niet. Geautomatiseerde testsuites verifiëren wat iemand al bedacht had om te controleren. AI voegt een nuttige laag toe en vangt meer patronen af dan een statische suite kan, maar beide zijn gebonden aan wat is voorzien. Geen van beide vervangt de QA-engineer die naar een wijziging kijkt en datgene opmerkt wat niemand had gespecificeerd: de faalmodus die nooit een testcase werd omdat niemand zich die nog had voorgesteld.

Automatisering verkleint het veld dat een mens moet bewaken, maar het haalt de mens er niet uit. Doen alsof dat wel zo is, is precies hoe de onvoorziene storing ongemerkt wordt uitgeleverd.

Wat door AI gegenereerde securityrapporten betekenen voor open-sourcemaintainers

De laatste laag is degene waar niemand het over heeft. Een groot deel van de software leunt op open-sourcebibliotheken en een belangrijk deel van dat fundament wordt onderhouden door een zeer klein aantal onbetaalde vrijwilligers. Log4j maakte dat tastbaar: een logging-bibliotheek die wereldwijd in bedrijfssoftware verweven zat, in leven gehouden door een handvol vrijwilligers en zo diep begraven in dependency trees dat de meeste organisaties niet wisten dat ze die draaiden.

De maintainer van curl, een open-sourceapplicatie, is openlijk gefrustreerd door een stortvloed aan door AI gegenereerde kwetsbaarheidsrapporten die geloofwaardig ogen en vaak onjuist zijn. Een onzinrapport kost de afzender dertig seconden en de maintainer uren om te weerleggen, want een beveiligingsclaim kan niet veilig worden genegeerd zonder die te controleren. De absorbeerder onderaan de stack is vaak één uitgeputte persoon en we hebben die in feite een brandslang in handen gedrukt.

De asymmetrie maakt het erger. Een verdediger die een echte fout vindt, dient een disclosure in en geeft die vrijwilliger een tikkende klok mee. Een bedreigingsactor dient niets in en houdt een privéwapen gericht op alles stroomafwaarts. De wanhoop die dit veroorzaakt bij opgebrande maintainers is de opening voor supply chain-aanvallen zoals de XY Utils-backdoor benutte. Dezelfde kloof, dezelfde rol naar beneden, alleen heeft de persoon onderaan zich nooit voor die taak aangemeld.

De absorptiekloof dichten in patchbeheer

Niets hiervan is een argument tegen patchen. Patchen is enorm belangrijk. Ongepatchte systemen worden vroeg of laat misbruikt (het 2026 Data Breach Investigations Report (DBIR) bewijst dat) en het venster tussen disclosure en aanval wordt steeds kleiner.

Maar als wijzigingen sneller worden gemaakt dan ze kunnen worden geabsorbeerd, is het antwoord investeren in absorptie – niet alleen in versnelling.

In uw eigen omgeving betekent dat: weten wat u daadwerkelijk draait tot in de diepste afhankelijkheden, wijzigingen faseren zodat tijd zijn werk kan blijven doen, aangesloten blijven op communities en mitigeren op de implementatielaag wanneer een upstream-fix traag is of nooit komt. Voor de laag waar iedereen van afhankelijk is, betekent het dat u de capaciteit van maintainers behandelt als de gedeelde infrastructuur die ze is. Gebruikt u een open-sourcebibliotheek, help dan de last te absorberen: financier het project, draag engineeringtijd bij, lever uw fixes upstream aan en triageer echte issues in plaats van alleen rapporten in te dienen. De kloof onderaan de stack is niet het probleem van een vrijwilliger. Het is ieders probleem, want iedereen staat erop.

Uiteindelijk zijn versnelde massale patchcycli een probleem van risicomanagement, niet van snelheid. Snelheid verbetert vanzelf wel. Absorptie verbetert alleen als we die bewust inbouwen en elke mitigatie die ertoe doet, is een manier om het menselijke oordeel terug te kopen dat wijzigingen op machinesnelheid vaak wegnemen.

Reserveer echte menselijke review voor de wijzigingen die het meeste risico dragen in plaats van een dun stempel over alles heen te verdelen. Geen van deze maatregelen elimineert het risico, maar ze geven het een prijs, perken het in en leggen de beslissing terug bij iemand met de context om die te nemen en de positie om “nog niet” te zeggen. Patchen is belangrijk, maar blind patchen is simpelweg een zichtbaar risico inruilen voor een onzichtbaar risico. Heeft u Patch Intelligence AI van NinjaOne, dan is inzicht in risico’s al ingebouwd. Door inzichtelijk te maken wat meerdere bronnen over een specifieke patch zeggen en dat inzicht aan technici te geven, kunnen mensen bepalen of die patch riskant is voor het bedrijf of dat ze beter even kunnen wachten.

Het doel is niet alleen om sneller te gaan. Het is om te weten wat u accepteert wanneer u dat doet.