DHS verplicht federale instanties DeepSeek te verwijderen

U moet per AI-toepassing in uw organisatie kunnen aantonen welk onderliggend model, welke provider en welke gegevensroutes eraan verbonden zijn, en u moet technische controles hebben die niet-goedgekeurde modellen blokkeren in plaats van alleen in beleid te verbieden.

Een order van de Amerikaanse DHS die DeepSeek en gelieerde producten uit federale civiele IT-systemen en aanbestedingen uitsluit van 20 oktober 2026 stelt vast dat een AI-model uitsluiten alleen effect heeft wanneer de volledige leveranciersketen in beeld is, inclusief derdeproducten die het model gebruiken. De order erkent dat een model zelden alleen in de herkenbare app zit, maar via een API, als bouwsteen in een geïntegreerde dienst of via een subprocessor kan draaien. In onze beoordeling is dit vooral een voorbeeld van hoe een gezaghebbende inkoper AI-risico's beoordeelt op basis van gegevenstoegang en herkomst, en dat oordeel vervolgens vertaalt naar harde inkoop- en verwijderingseisen. Voor elke organisatie die met gevoelige informatie werkt, betekent dit dat een inventaris van zichtbare AI-apps niet langer volstaat.

Welke risico's ontstaan als u de modelherkomst niet in kaart brengt?

Een AI-model kan via onzichtbare routes gegevens verwerken. Wanneer u alleen zichtbare AI-tools registreert, loopt u het risico dat gevoelige informatie langs een niet-goedgekeurde provider loopt zonder dat iemand dit kan traceren. De DHS-order erkent dit door ook derdeproducten te benoemen die DeepSeek gebruiken; een verbod op het model zelf helpt niet als dezelfde model via een andere dienst nog steeds actief is.

De praktische vraag die de order open laat, is hoe u vaststelt of een derdeproduct een verboden implementatie bevat. Dit vraagt meer dan een lijst met zichtbare tools. Het vereist dat per toepassing bekend is welk model, welke provider, welke API en welke subprocessor achter de dienst zitten, en welke gegevens daarlangs stromen.

• Onzichtbare modelroutes — een model kan via API, bouwsteen of subprocessor draaien zonder dat het in de app-inventaris verschijnt.
• Gegevensverlies via derdeproducten — gevoelige informatie kan langs een niet-goedgekeurde provider lopen via een dienst die niemand als AI-component had herkend.
• Onvolledige contractuele controle — leveranciers die hun AI-subverwerkers niet opgeven, maken het onmogelijk om verboden componenten later aan te tonen of te vervangen.
• Audit-onmogelijkheid — zonder documentatie van wie wat wanneer besloot, kunt u niet aantonen dat een uitsluiting of uitzondering rechtmatig was.
• Technische blindheid — beleid dat alleen verbiedt zonder technische blokkade, kan niet voorkomen dat een model toch gegevens verwerkt.

Welke controles moet u per AI-toepassing kunnen aantonen?

De DHS-order erkent dat uitzonderingsprocedures bestaan; dit betekent dat een uitsluiting een toetsbaar besluit is en geen automatisme. Voor u volgt hieruit dat u per model de beoordeling, de verwijdering of de goedgekeurde uitzondering los en controleerbaar moet bewaren.

1. Registreer welk model elke toepassing gebruikt en welke lawful basis voor de gegevens eraan verbonden is — documenteer per workflow welk model, welke provider en welke gegevenssoorten betrokken zijn.
2. Dwing contractueel af dat leveranciers hun AI-subverwerkers en modelherkomst opgeven en wijzigingen melden — zorg dat u weet wanneer een onderliggend model verandert.
3. Implementeer technische controles die niet-goedgekeurde modelroutes blokkeren — verlaat u niet op beleid alleen; zorg dat verboden componenten niet kunnen communiceren.
4. Bewaar per model de beoordeling, verwijdering of uitzondering herleidbaar — documenteer wie wat wanneer besloot, zodat u dit bij audit kunt aantonen.
5. Prioriteer systemen met de hoogste gegevensgevoeligheid — begin deze maand met de toepassingen die de meest gevoelige informatie verwerken.

Wie valt onder deze order en wie niet?

De DHS-order richt zich op federale civiele uitvoerende instanties van de Amerikaanse overheid. Het is geen algemeen verbod op DeepSeek voor Amerikaanse bedrijven, ziekenhuizen, advocatenkantoren of particulieren. Wie niet onder de federale civiele overheid valt, is juridisch niet aan deze order gebonden.

Toch is het belang breder. De order is vooral een voorbeeld van hoe een gezaghebbende inkoper een AI-leverancier beoordeelt op risico's van gegevenstoegang en herkomst, en dat oordeel vertaalt naar harde inkoop- en verwijderingseisen. De DHS heeft niet vastgesteld dat elk gebruik van DeepSeek tot een datalek leidt; zij heeft het risico onaanvaardbaar geacht voor federale civiele systemen en daar een gerichte maatregel aan verbonden.

Hoe past dit in uw risicobeheersing?

De order combineert verwijdering en aanbestedingsuitsluiting. Dit betekent dat het risico niet alleen IT-teams raakt, maar ook contracten en inkoop. Voor uw organisatie volgt hieruit dat de jurist nu contractueel moet afdwingen dat leveranciers hun AI-subverwerkers en modelherkomst opgeven en bij wijziging melden, zodat een verboden component later aantoonbaar vervangbaar is.

Dit thema past in bredere discussies over AI-security, over het dataverblijf per verwerkingsstap vaststellen, over risico's in AI-trainingsdata en pijplijnen, en over het behandelen van AI-risico als systeembreed resiliëntievraagstuk. Tooling kan u helpen bij het registreren van modelroutes en het afdwingen van technische controles. Wat tooling niet kan doen: bepalen welke gegevens gevoelig genoeg zijn om een model uit te sluiten, of welke uitzonderingen in uw context aanvaardbaar zijn. Dat blijft uw eigen professionele oordeel.