DHS verplicht federale instanties DeepSeek te verwijderen en derdeproducten te onderzoeken

De Amerikaanse Department of Homeland Security verplicht federale civiele instanties DeepSeek en gelieerde producten uit hun IT-systemen te verwijderen, uit aanbestedingen te weren en ook derdeproducten te onderzoeken die DeepSeek gebruiken. De les voor elke organisatie: een AI-model uitsluiten lukt alleen als u ook geïntegreerde diensten en de volledige leveranciersketen kunt identificeren.

Op 20 oktober 2026 publiceerde de Federal Register een order van de DHS die DeepSeek-producten uitsluit van de IT-systemen en aanbestedingen van federale civiele uitvoerende instanties. De order gelast niet alleen verwijdering van de DeepSeek-app en -API, maar strekt zich uitdrukkelijk uit tot producten en diensten van derden die met DeepSeek-implementaties zijn gebouwd. Volgens de publicatie bestaan er uitzonderingsprocedures voor gemotiveerde aanvragen.

Wat heeft de DHS precies besloten over DeepSeek?

De DHS draagt federale civiele instanties op om DeepSeek en gelieerde ondernemingen te verwijderen uit hun informatiesystemen, toekomstige aanschaf te blokkeren en bestaande toepassingen te onderzoeken op onderliggende DeepSeek-componenten. Uit de berichtgeving van Quartz blijkt dat de maatregel verder gaat dan de eigen app of API en ook derdeproducten raakt die DeepSeek verwerken.

• Verwijdering van DeepSeek- en gelieerde producten uit federale civiele IT-systemen.
• Uitsluiting van DeepSeek en gelieerde ondernemingen uit toekomstige aanbestedingen.
• Onderzoek naar derdeproducten en -diensten die DeepSeek-implementaties bevatten.
• Uitzonderingsmogelijkheden via een gemotiveerde aanvraag.

De onderliggende order is volgens de berichtgeving van 7minAI News op 24 juli 2026 ondertekend op grond van de Federal Acquisition and Supply Chain Security Act en pas in oktober openbaar gemaakt. Het is dus een inkoop- en supply-chainmaatregel, geen losse veiligheidswaarschuwing.

Geldt dit verbod ook voor bedrijven buiten de federale overheid?

Nee. De order richt zich op federale civiele uitvoerende instanties van de Amerikaanse overheid. Het is geen algemeen verbod op DeepSeek voor alle 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 dan de doelgroep. Naar onze inschatting is de order vooral een voorbeeld van hoe een gezaghebbende inkoper een AI-leverancier beoordeelt op de risico's van gegevenstoegang en herkomst, en dat oordeel vertaalt naar harde inkoop- en verwijderingseisen. De DHS heeft met deze publicatie 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.

Waarom reikt de maatregel verder dan de zichtbare DeepSeek-app?

Omdat een AI-model zelden alleen in de herkenbare app zit. Een model kan via een API draaien onder de motorkap van een ander product, als bouwsteen in een geïntegreerde dienst, of via een subprocessor in een keten die een eindgebruiker nooit ziet. Door ook derdeproducten te benoemen, erkent de DHS dat het uitsluiten van een model pas effect heeft wanneer de volledige keten in beeld is.

De order laat één praktische vraag open: hoe stelt een instantie vast of een derdeproduct een DeepSeek-implementatie bevat? Onze analyse hierop: dat vraagt meer dan een lijst met zichtbare AI-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.

Wat betekent dit besluit voor bestuurders, juristen en CISO's?

Onze analyse: omdat de DHS ook derdeproducten raakt die DeepSeek gebruiken, volstaat een inventaris van zichtbare AI-apps niet langer voor organisaties die met gevoelige informatie werken; daarom moet de CISO per AI-toepassing vastleggen welk onderliggend model en welke provider, API en subprocessor er achter zitten, en dat deze maand starten voor de systemen met de hoogste gegevensgevoeligheid. Omdat de order verwijdering én aanbestedingsuitsluiting combineert, raakt het risico ook contracten en inkoop; daarom moet de jurist nu contractueel afdwingen dat leveranciers hun AI-subverwerkers en modelherkomst opgeven en bij wijziging melden, zodat een verboden component later aantoonbaar vervangbaar is. Omdat een model via een onzichtbare route toch gegevens kan verwerken, ontstaat het risico dat gevoelige informatie langs een niet-goedgekeurde provider loopt; daarom moet de verantwoordelijke bestuurder niet-goedgekeurde modelroutes technisch laten blokkeren in plaats van alleen in beleid te verbieden. Omdat de order uitzonderingsprocedures kent, blijkt dat een uitsluiting een toetsbaar besluit is en geen automatisme; daarom moet de organisatie per model de beoordeling, de verwijdering of de goedgekeurde uitzondering los en controleerbaar bewaren, zodat bij een audit herleidbaar is wie wat wanneer besloot.

Als samenvatting van die analyse een korte checklist:

1. Inventariseer modellen en third-party componenten, niet alleen de zichtbare apps.
2. Koppel elke component aan eigenaar, versie, locatie, toegangsrechten en verwerkte gegevens.
3. Toets contractuele en technische vervangingsmogelijkheden per leverancier.
4. Blokkeer niet-goedgekeurde modelroutes technisch, niet alleen in beleid.
5. Bewaar bewijs van beoordeling, verwijdering, uitzondering of goedkeuring.

Wie deze stappen overslaat, loopt het risico dat een later verboden of ongewenst model nog steeds gegevens verwerkt via een dienst die niemand als AI-component had geregistreerd. Het thema past in bredere discussies over AI-security en dreigingsbeheersing, 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.

Bronnen: Het artikel steunt op de DHS-order in de Federal Register en op berichtgeving van Quartz en 7minAI News over de reikwijdte ervan.