ITAR, EAR та ваш SaaS: Коли продаж програмного забезпечення за кордон тихо робить вас експортером

Ніхто у вашій компанії не займається експортом. Немає жодного вантажного доку, митного брокера чи експортного відділу. І все ж у момент, коли клієнт в іншій країні завантажує ваш мобільний застосунок, інтегрує ваш SDK або отримує API-доступ до не тієї функції, ваш SaaS-бізнес щойно міг здійснити експорт за законодавством США — з обов'язками щодо ліцензування, перевірок та ведення записів. Ось як визначити, коли це відбувається, і що з цим робити.

Два режими за 90 секунд​

Експортний контроль США діє через дві окремі системи, які адмініструються двома різними відомствами. Порядок має значення: ви перевіряєте першу систему перед тим, як переходити до другої.

ITAR — оборонні товари. Міжнародні правила торгівлі зброєю, адміністровані Управлінням з контролю за торгівлею оборонними товарами (DDTC) Державного департаменту, контролюють оборонні вироби, оборонні послуги та пов'язані технічні дані, перелічені в Списку боєприпасів США (USML). Якщо ваше програмне забезпечення було спеціально розроблене або модифіковане для військового застосування — наведення, цілевказування, військовий зв'язок чи подібне — ви в зоні дії ITAR, де ліцензії отримати складно, винятків мало, а цивільні штрафи сягають семизначних сум за кожне порушення. Більшість комерційного SaaS ніколи сюди не потрапляє, але ви повинні спершу виключити цей варіант, оскільки ITAR має пріоритет, коли застосовується.

EAR — все інше. Правила експортного адміністрування, адміністровані Бюро промисловості та безпеки (BIS) Міністерства торгівлі, охоплюють усі інші товари американського походження, включаючи комерційне програмне забезпечення та технології. Підконтрольні товари зазначені в Списку контролю за експортом (CCL) під класифікаційним номером експортного контролю (ECCN); товари, що підпадають під дію EAR, але не зазначені в жодному списку, позначаються як EAR99. Більшість звичайного бізнес-програмного забезпечення належить до EAR99 або ECCN низької чутливості, що означає: для більшості напрямків ліцензія не потрібна — але "EAR99" все одно є класифікацією за правилами, а не звільненням від них. Обмежені напрямки, обмежені сторони та заборонене кінцеве використання все одно можуть вимагати ліцензії.

Одна неприємна особливість охоплює обидва режими: багато адміністративних порушень не вимагають злочинного наміру. Відправлення — або передача, або надання доступу — підконтрольного товару в неправильне місце або особі може створити відповідальність, навіть якщо ніхто не мав наміру порушувати правила. Саме тому найважливіша звичка відповідності — це класифікувати до передачі, а не пояснювати після отримання листа про заходи примусу.

Чому засновники SaaS вважають, що це їх не стосується​

Припущення здається розумним. Нічого не залишає країну в коробці; код знаходиться в дата-центрі США, а іноземні клієнти лише взаємодіють з ним через браузер. Протягом багатьох років керівництво BIS підтримувало вузьке тлумачення цього погляду:

• Консультативний висновок 2009 року встановив, що хмарний провайдер зазвичай не є "експортером", коли його клієнти використовують орендовані обчислювальні потужності для створення або переміщення підконтрольних технологій — це клієнт.
• Висновок 2011 року встановив, що провайдер, відповідно, не потребує ліцензій на умовний експорт для свого власного ІТ-персоналу з іноземним громадянством, який може стикатися з клієнтськими даними в мережі.
• Висновок 2014 року, на який часто посилаються, встановив, що надання користувачам доступу до "хмарної вітрини" — те, що ми зараз називаємо SaaS — не є експортом самого програмного забезпечення, за умови, що користувачі не завантажують його.

Цей висновок 2014 року є великою причиною того, чому індустрія SaaS змогла масштабуватися глобально, не ставлячись до кожного входу як до експортної події. Але він вузький: він охоплює використання без завантаження, він залежить від фактів і нічого не говорить про п'ять ситуацій нижче, де SaaS-компанії регулярно перетинають межу. І ґрунт зсувається — про це трохи згодом.

П'ять способів, як SaaS-компанії насправді стають експортерами​

1. Завантаження, SDK та мобільні застосунки​

Висновок 2014 року захищає доступ без завантаження. У момент, коли іноземна особа завантажує ваше програмне забезпечення — мобільний застосунок, десктопний клієнт, SDK, локальний агент, навіть образ контейнера — це класичний експорт програмного забезпечення в країну цієї особи. Кожен напрямок завантаження тоді потребує стандартного аналізу: класифікація, країна, кінцевий користувач, кінцеве використання.

Практичний наслідок: якщо ваш продукт має будь-який завантажуваний компонент, підтримуйте актуальне визначення ECCN або EAR99 для кожного завантажуваного артефакту та переконайтеся, що ваші умови розповсюдження та ліцензування враховують санкційні напрямки, а не виявляють прогалину під час перевірки належної обачності для раунду фінансування.

2. Обмін вихідним кодом і технічними даними з іноземними особами​

Згідно з EAR, передача підконтрольної технології або вихідного коду іноземному громадянину на території США є "умовним експортом" до країни останнього громадянства або постійного проживання цієї особи — ліцензія потрібна, якщо експорт такої ж технології в цю країну вимагав би ліцензії. ITAR має паралельне та суворіше правило для технічних даних.

Це пастка, яка найчастіше ловить невелику команду:

• Інженер з іноземним громадянством у вашому штаті в США, який може переглядати весь монорепозиторій, може потребувати аналізу умовного експорту для кожної підконтрольної технологічної області, до якої він має доступ.
• Офшорний підрядник з доступом до вихідного коду шифрування або підконтрольних алгоритмів через GitHub отримує технологію у своїй країні, а не просто "допомагає".
• Демонстрація екрану в службі підтримки, яка проводить іноземного клієнта через підконтрольну конфігурацію, може бути передачею технології.

Рішення операційні, а не екзотичні: класифікуйте свою технологію, сегментуйте доступ до репозиторіїв за проєктами, позначайте підконтрольну технологію та перевіряйте рішення про доступ так само, як перевіряли б відправлення. Фахівці з торгівлі називають письмову версію цього планом контролю за технологіями, і його складові негламурні — безпека передачі, фізична безпека, контроль доступу до ІТ, маркування та процедури утилізації.

3. Шифрування у вашому продукті​

Майже кожен SaaS-продукт використовує шифрування — TLS під час передачі, AES у стані спокою, бібліотеки типу OpenSSL або хмарні криптоплатформні API. Програмне забезпечення та технології шифрування контролюються з міркувань національної безпеки, зазвичай під ECCN, такими як 5D002 (програмне забезпечення) та 5E002 (технології).

Хороша новина полягає в тому, що BIS створило широкий в'їзд для звичайної комерційної криптографії:

• Більшість масових продуктів шифрування підпадають під полегшений режим (група 5x992), а не під ліцензійну заявку.
• Ліцензійний виняток ENC (15 CFR § 740.17) дозволяє експорт та реекспорт відповідних об'єктів шифрування без ліцензії, а правило 2021 року усунуло кілька застарілих тягарів, включаючи більшість попередніх повідомлень для публічно доступного вихідного коду шифрування.
• Реєстрація шифрування в BIS більше не потрібна.

Єдине зобов'язання, яке стартапи найчастіше пропускають, — це паперова робота, а не дозвіл: експортери, які самостійно класифікують продукти шифрування за ліцензійним винятком ENC(b)(1), зазвичай повинні подавати щорічний звіт про самостійну класифікацію до BIS, що охоплює попередній календарний рік, до 1 лютого. Внесіть це в календар відповідності поруч із податковими дедлайнами та ведіть постійний список класифікації експорту для кожного продукту та компонента, щоб звіт писався сам.

4. API-доступ до підконтрольних технологій — включно з моделями ШІ​

Для звичайних функцій SaaS доступ через браузер та API без завантаження все ще підпадає під висновок 2014 року. Але регулятори почали виділяти технології найвищої чутливості. Міністерство торгівлі почало розглядати віддалений, API-базований доступ до передових моделей ШІ як контрольований "вивільнення" моделі — різкий розрив з історичною позицією, що віддалена взаємодія без передачі технології не є експортом.

А Конгрес може піти далі. У січні 2026 року Палата представників ухвалила Закон про безпеку віддаленого доступу (RASA), який надав би BIS повноваження регулювати віддалений доступ іноземних осіб до об'єктів, підконтрольних EAR, через інтернет- або хмарні сервіси — закриваючи те, що ініціатори називають "хмарною лазівкою". На момент написання цього тексту закон очікує на розгляд у Сенаті. Якщо він стане законом, тягар відповідності для компаній, що працюють у хмарі, суттєво розшириться, а зона комфорту "використання без завантаження" від 2014 року звузиться.

Що робити, поки закон у русі: інвентаризуйте, які ваші API відкривають доступ до підконтрольної технології (шифрування, високопродуктивні обчислення, моделі ШІ/МЛ, геопросторові або сенсорні функції — звичайні підозрювані), журналюйте, хто отримує до них доступ і звідки, і структуруйте свої умови та контролі доступу так, щоб ви могли обмежити напрямки та користувачів, якщо правила зміняться під вами.

5. Клієнти, напрямки та кінцеве використання​

Навіть програмне забезпечення EAR99 потребує ліцензії — або повністю заборонене — для певних напрямків, сторін і цілей:

• Санкційні напрямки змінюються зі зовнішньою політикою; продаж або надання доступу в підсанкційні країни без дозволу заборонено, а регіональні обмеження (Росія, Білорусь, окуповані регіони України) тепер охоплюють навіть звичайне бізнес-програмне забезпечення EAR99.
• Обмежені сторони повинні перевірятися в кожній угоді. Перевіряйте кожного клієнта, реселера та інтеграційного партнера за консолідованими списками обмежених сторін уряду перед наданням доступу та періодично повторюйте перевірку — списки змінюються, і структури власності ваших клієнтів теж.
• Заборонене кінцеве використання включає військові, ядерно-рухові та певні застосування спостереження. Загальний інструмент управління проєктами, проданий зі знанням, що він підтримуватиме військове кінцеве використання в обмеженому напрямку, все одно може порушувати правила.

Жодне з цього не потребує корпоративного відділу відповідності. Потрібен чек-лист, який виконується до першого рахунку-фактури: класифікуйте об'єкт, перевірте сторону, перевірте напрямок, підтвердьте кінцеве використання та запишіть відповідь.

Що коштує помилка​

Штрафи розроблені так, щоб перевищувати прибуток від угоди на порядки:

• За EAR кримінальні порушення можуть призвести до штрафу до $1 мільйона за порушення та до 20 років позбавлення волі для фізичних осіб; адміністративні штрафи сягають сотень тисяч доларів за порушення та щороку коригуються з урахуванням інфляції.
• Кримінальні штрафи за ITAR досягають такої ж шкали $1 мільйон/20 років, з цивільними штрафами в семизначних сумах за порушення.
• Окрім штрафів, BIS може повністю позбавити експортних привілеїв — це смертний вирок для компанії, чий продукт поширюється глобально, — а порушення можуть сплисти через роки під час перевірки належної обачності при придбанні, коли покупець зменшує ціну придбання на оцінену експозицію.

Показовий приклад: у 2023 році виробник жорстких дисків погодився на врегулювання з BIS на суму $300 мільйонів через відвантаження, пов'язані з обмеженим китайським виробником телекомунікаційного обладнання — найбільший одноразовий адміністративний штраф, який BIS коли-небудь накладало. Ваша компанія менша, але арифметика зменшується, а не зникає.

Є також справжній пряник. Політика BIS розглядає добровільне саморозкриття (VSD) як вагому пом'якшувальну обставину, що заслуговує на значно зменшений штраф — тоді як навмисне нерозкриття значного можливого порушення є обтяжуючим фактором, що його збільшує. Фінальне правило 2024 року кодифікувало цей двосторонній стимул. Практичне повідомлення: коли ви виявляєте минуле порушення, розслідуйте його негайно з адвокатом, виправте процесуальну прогалину та розкрийте. Приховування — це єдина відповідь, яку вказівки карають навмисно.

Контрольний список відповідності експорту для малого бізнесу​

Вам не потрібен відділ торговельного права. Вам потрібні ці сім звичок, адаптованих для команди без такого відділу:

1. Спершу виключіть ITAR. Підтвердьте письмово, що нічого з того, що ви продаєте, розміщуєте або надаєте, не було розроблено для військового використання та не знаходиться в USML. Якщо відповідь незрозуміла, отримайте визначення юрисдикції до того, як щось відправляти.
2. Класифікуйте все за EAR. Призначте кожному продукту, завантажуваному компоненту та технологічній області ECCN або визначення EAR99 та підтримуйте список актуальним. Якщо самостійна класифікація неоднозначна, BIS приймає запити на класифікацію товарів.
3. Ставтеся до шифрування обдумано. Визначте, чи є кожен об'єкт шифрування масовим, відповідним для ENC або таким, що вимагає ліцензії; подавайте щорічний звіт про самостійну класифікацію до 1 лютого, якщо він вимагається для ваших об'єктів.
4. Перевіряйте кожну іноземну транзакцію. Перевіряйте клієнтів, реселерів і підрядників за списками обмежених сторін; перевіряйте напрямки на відповідність чинним санкціям; документуйте перевірку забороненого кінцевого використання. Автоматизуйте це під час надання доступу, а не покладайтеся на чиюсь пам'ять.
5. Контролюйте доступ до технологій. Сегментуйте репозиторії коду, позначайте підконтрольну технологію та проводьте перевірки умовного експорту перед наданням іноземним громадянам (включно зі співробітниками) доступу до вихідного коду або технічних даних.
6. Зберігайте записи протягом п'яти років. EAR вимагає, щоб записи про експорт, як правило, зберігалися протягом п'яти років від дати транзакції. Зберігайте класифікації, журнали перевірок, ліцензійні рішення та журнали відвантажень або доступу там, де їх зможуть знайти аудитор або команда належної обачності покупця.
7. Навчайте розробників. Розробники, девопси та інженери підтримки щодня створюють експортні події (надання доступу до репозиторію, обмін збіркою для налагодження, демонстрація екрану з конфігурацією). Щорічне навчання плюс односторінковий посібник "запитай перед тим, як поділитися" запобігає більшості ненавмисних передач.

Тримайте витрати на відповідність видимими у своїх книгах​

Відповідність експорту з'являється у ваших фінансах задовго до того, як з'явиться у справі про примусове стягнення: зовнішні адвокати для перевірок класифікації, підписки на перевірку обмежених сторін, контроль умовного експорту в процесі найму HR, години персоналу за вашим щорічним звітом про шифрування — і, якщо ви коли-небудь подасте такий, юридичні витрати на добровільне саморозкриття. Відстежуйте це як окрему категорію витрат, а не ховайте в загальних юридичних або програмних витратах, щоб бачити, скільки насправді коштує обслуговування кожного ринку та продуктової лінійки. Поєднайте це зі згаданим вище п'ятирічним слідством — класифікації, журнали перевірок та ліцензійні рішення, подані за транзакціями, — і ваші аудитори та команда належної обачності будь-якого майбутнього покупця отримають чіткі відповіді замість археологічних розкопок. Ваші документи про збереження записів та панелі в /fava/ є природним місцем для цього паперового сліду.

Тримайте свої фінансові записи готовими до аудиту з першого дня​

Коли ви відкриваєте свій SaaS для клієнтів по всьому світу, ведення чітких фінансових записів — включно з кожним витраченим доларом на відповідність і кожним рішенням про експорт — є важливим. Beancount.io надає бухгалтерію у відкритому текстовому форматі, яка дає вам повну прозорість і контроль над вашими фінансовими даними, з записами під контролем версій, яким аудитор може легко слідувати. Почніть безкоштовно і побачте, чому розробники та фінансові фахівці переходять на бухгалтерію у відкритому текстовому форматі.