Обновить

Комментарии 15

В компаниях обычно просто чат для предоставления услуг не используется. Его могут использовать разве что разработчики для написания кода (но тогда это тоже самое, как если бы его использовали просто физлица).

Компании же обычно работают по апи. И услуги строят на обращениях к апи. Так что вы бы лучше апи и сравнили, там ситуация будет отличаться

В данной статье преимущественно рассматриваются юридические аспекты использования моделей. Они общие, как для АПИ, так и для чата

Это тема для отдельной статьи. С одной стороны есть общие признаки, поскольку облачные модели - это все чей-то чужой компьютер, с другой - TOS и политики в отношении обоработки данных у рассмотренных в посте моделей при доступе через веб и по API могут существенно отличаться.

И третья статья тоже нужна - о правовых рисках развертывания моделей на собственной инфраструктуре

а че это вы в рейтинге не учитываете стоимость?

Поясните юридическим языком, пожалуйста, почему у Мистраля проблемы с 152 ФЗ

Спасибо за содержательный вопрос.

Как и все иностранные ИИ-модели, в случае внесения конечным пользователем персональных данных в Мистраль, будет осуществлена их трансграничная передача. Кроме того, учитывая нынешние напряженные отношения с "коллективным Западом", нет гарантий что эти данные:

  • будут удалены по требованию пользователя;

  • не будут использоваться для дообучения ИИ-системы (т.е. сохранены);

  • не будут переданы третьим лицам либо опубликованы.

Всё это запрещено в соответствии с 152-ФЗ.

И самое главное, что, видимо, не удалось донести в статье - что используя сервисы, доминицированные в иностранных государствах, нельзя рассчитывать на правовую защиту своих интересов. Т.е. иностранный контрагент может в любое время отключить сервис или использовать полученные данные неправомерным образом, и его никак будет не привлечь к ответственности за это.

Я вас просил юридически обосновать.

Вы составляли уведомление для РКН с трансграничной передачей ПД? Большая разница с уведомлением без трансграничной передачи ПД?

Еще раз, в чем юридические проблемы с точки зрения ФЗ-152 от использования сервисов дружественной (Франция, GDRP) согласно РКН страны, о чем вы утверждаете в вашей таблице? Не ваши субъективные страхи, а реальный конфликт с законом в чем?

Тысячи компаний в РФ используют Мистраль, объясните, в каком месте они нарушают ФЗ-152

Проблема в том, что Mistral AI - французское акционерное общество (юр. адрес - 15 rue des Halles, 75001 Париж, Франция). Достоверных сведений о том, что базы данных, используемые для сбора ПДн посредством веб-версии LeChat, находятся в России, нет (если у Вас есть, буду благодарен за уточнение).

Согласно части 5 ст. 18 ФЗ-152 в редакции 2025 года при сборе ПДн операции с использованием баз данных, находящихся за пределами территории РФ, не допускаются. Ч. 8-9 ст. 13.11 КоАП. И это только начало.

Далеко не в каждой задаче, связанной с использованием LLM, используются персональные данные. Например, дизайнеру, использующему графические модели для быстрого прототипирования, вообще, персональные данные в работе не нужны, поэтому данный риск не всем актуален. А так, сотрудники могут персональные данные и в Гугле по дурости вбивать.

Корректнее было бы описывать, какие модели (и по какому тарифу) для каких задач подходят. А то если взять, например, случай обработки врачебной тайны, то я, вот, не уверен, что отчественные модели по бесплатному тарифу (без заключения доп. соглашений) для этого случая подойдут (с учётом возможности дообучения на запросах).

Это часто выпадает из фокуса внимания, но ПДн - это не только буквально имя, номер телефона и тд. Дизайнер, использующий графические модели через веб - тоже субъект персональных данных в отношении информации, которая создается в результате работы метрических системам и тд.

О специальных категориях ПДн - хорошее предложение, это тема для отдельной, более глубокой статьи.

В данном случае, это уже будет проблема сервиса LLM, насколько он соответствует законам. Пока что россиянам не запрещено пользоваться иностранными сервисами, обрабатывающими их персональные данные. Поэтому ответственность здесь будет не на стороне дизайнера.

Вы правы, но я имею в виду другую ситуацию - когда дизайнер не сам по себе использует сервис, как частное лицо, а когда его труд кто-то организует.

Если труд организован правильно, то, хочется верить, что будет создан корпоративный аккаунт. Если же работодатель заставляет дизайнера регистрироваться на свою личную почту, то, да, передача персональных данных.

Да даже если запретят. Пойдут на три буквы и все. Вообще похую, что там считает наше государство про это.

про требуется/не требуется VPN - вы вводите в заблуждение.

В отдельных случаях достаточно EDNS Client Subnet (ECS) типа dns.comss.one/dns-query

С некоторыми можно работать через интерфейсы типа perplexity - там вообще никаких ограничений (на web) нет

технические детали обхода "санкций" с помощью настройки DNS

### 3. Техническая суть механизма (аналогия с BGP Anycast, но на L7):
``bash
# С публичными DNS (Google/Cloudflare):
Ваш IP (RU) → DNS-запрос → Резолвер (EU/US) → Возврат глобального CDN IP → Блокировка

# С
comss.one:
Ваш IP (RU) → DNS-запрос → Резолвер (RU) → Возврат локального CDN IP → Доступ разрешён
`
*Ключевые элементы*:
-
Гео-аффинити DNS: Резолвер привязан к российским AS (AS48625)
-
ECS-фильтрация: Не передаёт /24 подсеть клиента в upstream-запросах
-
CDN Hijacking: Возвращает IP локальных точек входа (например, Cloudflare Moscow вместо Frankfurt)
-
Reverse DNS spoofing: PTR-записи резолвера маскируют происхождение (dynamic-pool.comss.one вместо dns.google)

---

### 4.
Схема работы в терминах OSI:
| Уровень | Обычный сценарий | Ваш случай с
comss.one |
|----------|----------------------------|---------------------------------|
|
L3 | Ваш реальный IP (RU) | Ваш реальный IP (но через RU CDN) |
|
L4 | Прямое соединение | TCP-проксирование через локальный POP |
|
L7 | DNS → Глобальный Anycast | DNS → Локальный CDN-эндпоинт |

---

### 5.
Как это обходит блокировку (на примере HTTP(S)):
1.
Фаза DNS:
`mermaid
graph LR
A[Ваш клиент] --> B[
comss.one DNS]
B --> C{Гео-фильтр CDN}
C -->|"Если RU DNS"| D[Московский CDN IP]
C -->|"Если EU/US DNS"| E[Франкфуртский CDN IP]
`
2.
Фаза соединения:
- Сервис видит:
-
X-Forwarded-For: ваш IP
-
Via: 95.163.88.77 (Moscow CDN)
-
Проверки сервиса:
- GeoIP для CDN-узла → "Москва" → разрешено
- ASN CDN-узла → "российский провайдер" → разрешено
- Отсутствие ECS → не видит ваш реальный
/24

---

### 6.
Почему это работает эффективнее VPN:
-
Латентность: Нет оверхеда на шифрование/туннелирование
-
TCP-метрики: TTL и RTT соответствуют локальному трафику
-
SNI-маскировка: TLS ClientHello содержит реальное SNI (не вызывает подозрений)
-
CDN-доверие: Локальные IP из "белых списков" сервисов

---

### 7.
Уязвимости схемы:
1.
DNS-блокировка резолвера:
- Решение: Использование DoH/DoT и IPv6
2.
Анализ трафика CDN:
- Риск: Выявление аномальных X-Forwarded-For
3.
Таргетирование AS48625:
- Решение: Ротация резолверов в пуле

---

### 8.
Проверка механизма:
`bash
# Сравнение маршрутов:
diff <(traceroute -T -p 443
api.service.com) <(traceroute -T -p 443 95.163.88.77)

# Анализ TLS-рукопожатия:
openssl s_client -connect api.service.com:443 -servername
api.service.com -showcerts
``

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации