ITAR, EAR en uw SaaS: wanneer het verkopen van software in het buitenland u stilletjes tot exporteur maakt

Niemand bij uw bedrijf houdt zich bezig met export. Er is geen laadperron, geen douane-expediteur, geen exportafdeling. En toch, op het moment dat een klant in een ander land uw mobiele app downloadt, uw SDK integreert, of API-toegang krijgt tot de verkeerde functie, heeft uw SaaS-bedrijf mogelijk zojuist een export verricht onder de Amerikaanse wet — met licentie-, screening- en administratieverplichtingen tot gevolg. Hier leest u hoe u herkent wanneer dit gebeurt en wat u eraan doet.

De twee regimes in 90 seconden​

De Amerikaanse exportcontroles verlopen via twee afzonderlijke systemen, beheerd door twee verschillende agentschappen. De volgorde is belangrijk: u controleert het eerste systeem vóór het tweede.

ITAR — defensieartikelen. De International Traffic in Arms Regulations, beheerd door het Directoraat Defensiehandelscontrole (DDTC) van het ministerie van Buitenlandse Zaken, controleren defensieartikelen, defensiediensten en daarmee verbandhoudende technische gegevens die op de US Munitions List (USML) staan. Als uw software specifiek is ontworpen of aangepast voor een militaire toepassing — navigatie, doelbesturing, militaire communicatie of iets dergelijks — bevindt u zich in ITAR-gebied, waar licenties moeilijk te verkrijgen zijn, weinig uitzonderingen gelden en civiele boetes per overtreding kunnen oplopen tot zeven cijfers. De meeste commerciële SaaS belandt hier nooit, maar u moet dit eerst uitsluiten, omdat ITAR altijd de jurisdictie overneemt wanneer het van toepassing is.

EAR — al het overige. De Export Administration Regulations, beheerd door het Bureau of Industry and Security (BIS) van het ministerie van Handel, bestrijken alle andere producten van Amerikaanse oorsprong, inclusief commerciële software en technologie. Gecontroleerde producten verschijnen op de Commerce Control List (CCL) onder een Export Control Classification Number (ECCN); producten die onder de EAR vallen maar nergens vermeld staan, worden aangemerkt als EAR99. De meeste gangbare zakelijke software is EAR99 of een ECCN met lage gevoeligheid, wat betekent dat voor de meeste bestemmingen geen licentie nodig is — maar "EAR99" is nog steeds een classificatie onder de regelgeving, geen vrijstelling ervan. Beperkte bestemmingen, beperkte partijen en verboden eindgebruiken kunnen alsnog een licentievereiste triggeren.

Eén ongemakkelijk kenmerk geldt voor beide regimes: veel administratieve overtredingen vereisen geen opzettelijke misdrijf. Het verzenden — of verzenden via overdracht, of toegang verlenen tot — een gecontroleerd artikel naar de verkeerde plaats of persoon kan aansprakelijkheid creëren, zelfs als niemand de bedoeling had om de regels te overtreden. Daarom is de nalevingsgewoonte die het belangrijkst is, het classificeren vóór u verzendt, niet het uitleggen nadat een handhavingsbrief arriveert.

Waarom SaaS-oprichters aannemen dat dit niet op hen van toepassing is​

De aanname voelt redelijk. Er verlaat niets het land in een doos; de code bevindt zich in een Amerikaans datacenter en buitenlandse klanten hebben er alleen via een browser interactie mee. Jarenlang ondersteunde de BIS-richtlijn een nauwe versie van dat standpunt:

• Adviesopinie uit 2009 stelde vast dat een cloudprovider over het algemeen niet de "exporteur" is wanneer zijn klanten gehuurde computerruimte gebruiken om gecontroleerde technologie te creëren of te verplaatsen — de klant is dat.
• Een opinie uit 2011 concludeerde dat de provider daarom geen deemed export-licenties nodig heeft voor zijn eigen buitenlandse IT-medewerkers die mogelijk klantgegevens op het netwerk tegenkomen.
• Een veelgebruikte opinie uit 2014 stelde dat gebruikers toegang geven tot een "cloudgebaseerde winkel" — wat we nu SaaS noemen — geen export is van de software zelf, op voorwaarde dat gebruikers deze niet downloaden.

Die opinie uit 2014 is een belangrijke reden dat de SaaS-industrie wereldwijd kon opschalen zonder elke inlog als exportgebeurtenis te behandelen. Maar deze is beperkt: hij dekt gebruik-zonder-download, is feitelijk specifiek en zegt niets over de vijf situaties hieronder, waar SaaS-bedrijven routinematig de grens overschrijden. En de grond is aan het verschuiven — daarover zo meer.

Vijf manieren waarop SaaS-bedrijven daadwerkelijk exporteurs worden​

1. Downloads, SDK's en mobiele apps​

De opinie uit 2014 beschermt toegang zonder download. Op het moment dat een buitenlandse persoon uw software downloadt — een mobiele app, een desktopclient, een SDK, een on-prem agent, zelfs een containerimage — is dat een schoolvoorbeeld van export van software naar het land van die persoon. Elke downloadbestemming vereist dan de standaardanalyse: classificatie, land, eindgebruiker, eindgebruik.

Praktische consequentie: als uw product een downloadbaar onderdeel heeft, onderhoud dan een actuele ECCN- of EAR99-bepaling voor elk downloadbaar artefact en zorg ervoor dat uw distributie- en licentievoorwaarden rekening houden met gesanctioneerde bestemmingen, in plaats van de hiaat te ontdekken tijdens due diligence voor een financieringsronde.

2. Delen van broncode en technische gegevens met buitenlandse personen​

Onder de EAR is het vrijgeven van gecontroleerde technologie of broncode aan een buitenlandse onderdaan in de Verenigde Staten een "deemed export" naar het meest recente land van staatsburgerschap of permanente verblijfplaats van die persoon — een licentie is vereist als het exporteren van dezelfde technologie naar dat land er een zou vereisen. ITAR heeft een parallelle en strengere regel voor technische gegevens.

Dit is de valkuil die een klein team het meest waarschijnlijk zal treffen:

• Een buitenlandse ingenieur op uw Amerikaanse loonlijst die de hele monorepo kan bekijken, heeft mogelijk een deemed export-analyse nodig voor elk gecontroleerd technologiegebied waartoe ze toegang hebben.
• Een buitenlandse contractant met GitHub-toegang tot encryptiebroncode of gecontroleerde algoritmen ontvangt technologie in hun land, niet zomaar "helpen".
• Een support-schermdeling die een buitenlandse klant door een gecontroleerde configuratie leidt, kan een vrijgave van technologie zijn.

Oplossingen zijn operationeel, niet exotisch: classificeer uw technologie, segmenteer repository-toegang per project, markeer gecontroleerde technologie en screen het toegangsbesluit op dezelfde manier als u een zending zou screenen. Handelsadviseurs noemen de geschreven versie hiervan een technologiecontroleplan, en de ingrediënten zijn onopvallend — transmissiebeveiliging, fysieke beveiliging, IT-toegangscontroles, markering en verwijderingsprocedures.

3. Encryptie in uw product​

Bijna elk SaaS-product gebruikt encryptie — TLS tijdens transport, AES in rust, bibliotheken zoals OpenSSL of platform-crypto-API's. Encryptiesoftware en -technologie worden gecontroleerd om nationale veiligheidsredenen, meestal onder ECCN's zoals 5D002 (software) en 5E002 (technologie).

Het goede nieuws is dat BIS een brede oprit heeft gebouwd voor gangbare commerciële cryptografie:

• De meeste massamarkt-encryptieproducten komen in aanmerking voor versoepelde behandeling (de 5x992-groep) in plaats van een licentieaanvraag.
• License Exception ENC (15 CFR § 740.17) staat export en wederuitvoer toe van in aanmerking komende encryptie-items zonder licentie, en een regel uit 2021 verwijderde verschillende verouderde lasten, waaronder de meeste voorafgaande kennisgevingen voor openbaar beschikbare encryptiebroncode.
• Er is geen encryptieregistratie bij BIS meer vereist.

De resterende verplichting die startups het vaakst missen is papierwerk, niet toestemming: exporteurs die encryptieproducten zelf classificeren onder License Exception ENC(b)(1) moeten over het algemeen jaarlijks vóór 1 februari een zelfclassificatierapport bij BIS indienen over het voorgaande kalenderjaar. Zet het op de nalevingskalender naast uw belastingdeadlines en houd een permanente exportclassificatielijst bij voor elk product en onderdeel, zodat het rapport zichzelf schrijft.

4. API-toegang tot gecontroleerde technologie — inclusief AI-modellen​

Voor gewone SaaS-functies valt browser- en API-toegang zonder download nog steeds onder de opinie uit 2014. Maar toezichthouders zijn begonnen met het uitsnijden van de meest gevoelige technologie. Het ministerie van Handel is overgegaan tot het behandelen van externe, API-gebaseerde toegang tot geavanceerde AI-modellen als een gecontroleerde "vrijgave" van het model — een scherpe breuk met het historische standpunt dat externe interactie zonder technologieoverdracht geen export is.

En het Congres kan nog verder gaan. In januari 2026 nam het Huis de Remote Access Security Act (RASA) aan, die BIS de bevoegdheid zou geven om externe toegang door buitenlandse personen tot EAR-gecontroleerde items via internet- of clouddiensten te reguleren — waarmee het "cloudgat" dat voorstellen noemen, wordt gedicht. Op het moment van schrijven wacht dit wetsvoorstel op actie van de Senaat. Als het wet wordt, breidt de nalevingslast voor bedrijven die op de cloud opereren aanzienlijk uit en wordt de comfortzone van gebruik-zonder-download uit 2014 smaller.

Wat te doen terwijl de wet in beweging is: inventariseer welke van uw API's gecontroleerde technologie blootleggen (encryptie, high-performance computing, AI/ML-modellen, geospatiale of sensorfusiefuncties zijn de gebruikelijke verdachten), log wie er vanaf waar toegang toe heeft en structureer uw voorwaarden en toegangscontroles zodat u bestemmingen en gebruikers kunt beperken als de regel onder u verandert.

5. Klanten, bestemmingen en eindgebruiken​

Zelfs EAR99-software heeft een licentie nodig — of is ronduit verboden — voor bepaalde bestemmingen, partijen en doeleinden:

• Gesanctioneerde bestemmingen veranderen met het buitenlandse beleid; verkopen of toegang verlenen tot embargo-landen zonder toestemming is verboden, en regionale beperkingen (Rusland, Wit-Rusland, bezette regio's van Oekraïne) reiken nu zelfs tot gewone EAR99-bedrijfssoftware.
• Beperkte partijen moeten deal voor deal worden gescreend. Controleer elke klant, wederverkoper en integratiepartner tegen de geconsolideerde lijsten van beperkte partijen van de overheid vóór u toegang verleent, en herscreen regelmatig — lijsten veranderen, en ook de eigendomsstructuren van uw klanten.
• Verboden eindgebruiken omvatten militaire, nucleaire voortstuwings- en bepaalde surveillancetoepassingen. Een generiek projectbeheertool die wordt verkocht met de wetenschap dat het een militair eindgebruik in een beperkte bestemming zal ondersteunen, kan nog steeds de regels overtreden.

Geen van dit vereist een enterprise-nalevingsafdeling. Het vereist een checklist die vóór de eerste factuur draait: classificeer het item, screen de partij, controleer de bestemming, bevestig het eindgebruik en schrijf het antwoord op.

Wat het kost als het misgaat​

Boetes zijn ontworpen om de winst op de deal met ordes van grootte te overschrijden:

• Onder de EAR kunnen strafrechtelijke overtredingen tot $ 1 miljoen per overtreding en tot 20 jaar gevangenisstraf voor individuen opleveren; administratieve boetes lopen op tot honderdduizenden dollars per overtreding en worden elk jaar aangepast aan de inflatie.
• ITAR-strafrechtelijke boetes bereiken dezelfde schaal van $ 1 miljoen/20 jaar, met civiele boetes in zeven cijfers per overtreding.
• Naast boetes kan BIS exportprivileges volledig ontzeggen — een doodvonnis voor een bedrijf waarvan het product wereldwijd wordt gedistribueerd — en overtredingen kunnen jaren later tijdens de due diligence bij een overname aan het licht komen, wanneer de koper de aankoopprijs verlaagt met de geschatte blootstelling.

Het sprekende voorbeeld: in 2023 stemde een harde schijf-fabrikant in met een schikking van $ 300 miljoen met BIS over zendingen die verband hielden met een beperkte Chinese telecomapparatuurfabrikant — de grootste op zichzelf staande administratieve boete die BIS ooit had opgelegd. Uw bedrijf is kleiner, maar de rekenkunde schaalt af, niet weg.

Er is ook een echte wortel. Het BIS-beleid behandelt een vrijwillige zelfonthulling (VSD) als een sterke verzachtende omstandigheid die een sterk verlaagde boete oplevert — terwijl het opzettelijk niet melden van een significante mogelijke overtreding een verzwarende factor is die deze verhoogt. Een definitieve regel uit 2024 codificeerde dat tweezijdige stimulans. De praktische boodschap: wanneer u een eerdere overtreding ontdekt, onderzoek dan prompt met juridisch advies, los het proceshiaat op en meld het. Het begraven ervan is de enige reactie die de richtlijnen opzettelijk straffen.

Een nalevingschecklist voor kleine bedrijven​

U heeft geen handelsrechtelijke afdeling nodig. U heeft deze zeven gewoonten nodig, afgestemd op een team zonder er een:

1. Sluit ITAR eerst uit. Bevestig schriftelijk dat niets dat u verkoopt, host of deelt is ontworpen voor militair gebruik of op de USML voorkomt. Als het antwoord onduidelijk is, vraag dan een jurisdictiebepaling aan voordat u iets verzendt.
2. Classificeer alles onder de EAR. Ken elk product, downloadbaar onderdeel en technologiegebied een ECCN- of EAR99-bepaling toe en houd de lijst actueel. Wanneer zelfclassificatie onzeker is, accepteert BIS verzoeken voor goederenclassificatie.
3. Ga bewust om met encryptie. Bepaal of elk encryptie-item massamarkt, ENC-geschikt of licentieplichtig is; dien jaarlijks vóór 1 februari het zelfclassificatierapport in als uw items dit vereisen.
4. Screen elke buitenlandse transactie. Controleer klanten, wederverkopers en contractanten tegen lijsten van beperkte partijen; verifieer bestemmingen tegen actuele sancties; documenteer de beoordeling van verboden eindgebruik. Automatiseer dit in de provisioning, niet in iemands geheugen.
5. Beheer de toegang tot technologie. Segmenteer coderepositories, markeer gecontroleerde technologie en voer deemed export-controles uit voordat u buitenlandse onderdanen (inclusief werknemers) toegang geeft tot broncode of technische gegevens.
6. Bewaar administratie vijf jaar. De EAR vereist dat exportadministratie over het algemeen vijf jaar vanaf de transactie wordt bewaard. Bewaar classificaties, screeningsresultaten, licentiebeslissingen en verzend- of toegangslogboeken op een plek waar een auditor — of het due diligence-team van een koper — ze kan vinden.
7. Train de builders. Ontwikkelaars, DevOps en supportengineers creëren dagelijks exportgebeurtenissen (repo-toegang verlenen, een debug-build delen, een configuratie schermdelen). Jaarlijkse training plus een eenpagina's "vraag voordat u deelt"-gids voorkomt de meeste onbedoelde vrijgaven.

Houd uw nalevingskosten zichtbaar in uw boeken​

Exportnaleving verschijnt in uw financiën lang voordat het in een handhavingsactie verschijnt: externe adviseurs voor classificatiebeoordelingen, abonnementen voor screening van beperkte partijen, deemed export-controles in uw HR-onboarding, de personeelsuren achter uw jaarlijkse encryptierapport en — als u ooit een dergelijk bestand indient — de juridische kosten van een vrijwillige zelfonthulling. Houd deze bij als een eigen uitgavencategorie in plaats van ze te verbergen in algemene juridische of softwarekosten, zodat u kunt zien wat elke markt en productlijn werkelijk kost om te bedienen. Combineer dat met de hierboven genoemde administratie van vijf jaar — classificaties, screeningslogboeken en licentiebeslissingen per transactie — en zowel uw accountants als het due diligence-team van een toekomstige overnemer krijgen schone antwoorden in plaats van archeologie. Uw documentatie over record retention en dashboards in /fava/ zijn natuurlijke plekken voor dat papieren spoor.

Houd uw financiële administratie vanaf dag één auditklaar​

Terwijl u uw SaaS openstelt voor klanten over de hele wereld, is het essentieel om duidelijke financiële administratie te onderhouden — inclusief elke nalevingsdollar en elke exportbeslissing. Beancount.io biedt plain-text boekhouding die u volledige transparantie en controle geeft over uw financiële gegevens, met versiebeheerde administratie die een accountant daadwerkelijk kan volgen. Start gratis en ontdek waarom ontwikkelaars en financiële professionals overstappen op plain-text boekhouding.