Урок 1: Шесть контуров обработки данных — где живут ваши запросы и ответы

Чему вы научитесь

• Различать шесть контуров AI-системы: от личного чата в браузере до полностью изолированного air-gap
• Быстро определять, где физически и юридически живут ваши запросы, файлы, логи и ответы модели
• Отделять «удобный пилот» от контура, который можно законно и стабильно эксплуатировать на предприятии
• Подбирать контур под класс задачи: черновик письма, RAG по регламентам, анализ ПД, помощник оператора, КИИ
• Ставить интегратору правильный вопрос не «какую модель вы возьмёте», а «в каком контуре она будет жить и кто за него отвечает»

Первый вопрос любого AI-проекта — не «какая модель умнее». Первый вопрос — куда уходят данные и кто владеет контуром. На одном конце шкалы — личный ChatGPT Plus в браузере: быстро, дёшево, удобно. На другом — air-gapped контур в закрытом сегменте завода: дорого, медленно в обновлении, но управляемо. Между ними — ещё четыре варианта, и именно они определяют, можно ли проект запускать без конфликта с ИБ, 152-ФЗ и требованиями КИИ.

Логика модуля p.2 простая: сначала выбираем контур, потом класс модели, потом железо. Если сделать наоборот, получится типичный промышленный анти-паттерн: команда купила дорогую модель, а юрист и CISO через месяц объяснили, что отправлять туда данные нельзя. Для темы персональных данных возвращайтесь к уроку p.3/01. Для значимых объектов КИИ — к уроку p.3/02. Для санкционной доступности западных сервисов — к уроку p.3/05.

Шесть контуров: карта без маркетинга

Decision tree: как выбрать контур за пять вопросов

flowchart TD
    A[Есть ли в задаче данные из значимого объекта КИИ?] -->|Да| B[Смотрите только On-prem или Air-gap]
    A -->|Нет| C[Есть ли ПД, КТ или чувствительные внутренние документы?]
    C -->|Да| D[Нужен корпоративный договор и управляемый контур]
    C -->|Нет| E[Это личный эксперимент или обучение команды?]
    E -->|Да| F[Consumer Public или Public API на синтетике]
    E -->|Нет| G[Нужна интеграция в продукт или бизнес-процесс?]
    G -->|Да| H[Public API, Enterprise Cloud или Private VPC]
    G -->|Нет| I[Consumer Public достаточно]
    D --> J[Нужна ли сетевая изоляция и приватная маршрутизация?]
    J -->|Да| K[Private VPC или On-prem]
    J -->|Нет| L[Enterprise Cloud]

Это дерево специально жёсткое. Оно отсекает ложную экономию. Если задача заходит в КИИ, спор о «лучшем API» заканчивается: остаются контуры 5 и 6. Это прямое следствие урока p.3/02. Если задача включает персональные данные, сначала вспоминаете урок p.3/01, а уже потом спорите о модели. Если сервис западный и вы строите на нём постоянный бизнес-процесс, возвращайтесь к уроку p.3/05 и задайте вопрос о санкционной устойчивости до подписания договора.

Где граница между соседними контурами

1 и 2: consumer public против public API

Разница не в качестве модели. Разница в форме ответственности.

Consumer Public — это «человек разговаривает с сервисом». Public API — это «система компании вызывает модель программно». Во втором случае вы хотя бы можете управлять ключами, лимитами, журналированием, политикой ретраев и интеграцией в свой gateway. В первом вы покупаете удобство. Во втором — строительный материал для продукта.

Поэтому правило простое: как только сценарий должен жить дольше одного пилота, уходите из consumer в API или enterprise-контур. Consumer хорош для изучения возможностей, сравнения промптов и быстрых черновиков. Для этого, кстати, уместен и arckep.ru: безопасно прогонять синтетические примеры, смотреть разницу между моделями, платить рублями и не привязывать западные карты. Но arckep.ru, как и любой другой внешний сервис, не легализует ПД и не заменяет корпоративный контур.

2 и 3: public API против enterprise cloud

Здесь граница проходит по слову управляемость.

Public API подходит, когда вам нужен вызов модели и вы готовы сами строить вокруг него почти всё остальное: авторизацию, логи, маскирование ПД, DLP, ограничение функций, мониторинг стоимости. Enterprise Cloud имеет смысл, когда компании нужен не просто API, а полноценный управляемый сервис: SSO, роли, workspace, data residency, admin console, централизованное отключение функций, журнал аудита.

Проще: API — это кирпич. Enterprise Cloud — это уже часть здания.

3 и 4: enterprise cloud против private VPC

На бумаге оба варианта «корпоративные». Но enterprise cloud — это всё ещё shared service провайдера. Private VPC / dedicated tenant — это уже попытка взять плюсы облака и одновременно сократить поверхность риска.

Именно на этом слое обычно живут решения, где:

• нельзя отправлять данные в общий multi-tenant SaaS;
• нужен private endpoint, VPN или direct interconnect;
• нужен предсказуемый throughput;
• предприятие ещё не готово тащить всё в собственный ЦОД.

Для многих промышленных компаний это самый практичный переходный шаг: сначала dedicated tenant в облаке, потом — при росте нагрузки и ужесточении требований — on-prem.

5 и 6: on-prem против air-gap

On-prem — это «всё у меня в контуре, но сеть наружу в принципе существует». Air-gap — это «рабочего канала наружу нет». Разница огромная и по ИБ, и по операционке.

On-prem подходит большинству предприятий, которым нужны локальность, контроль и санкционная устойчивость. Air-gap нужен там, где сам факт сетевого выхода уже неприемлем. Цена за это — тяжёлая эксплуатация: обновление весов, перенос пакетов, проверка артефактов, отдельные процедуры CI/CD, отдельный backup-процесс.

Матрица «какой контур для какого класса задачи»

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

Практический алгоритм выбора контура

1. Опишите данные до выбора модели. Не «будем подключать LLM», а «у нас есть PDF регламенты, журналы ремонтов, фото дефектов, ФИО сотрудников, телеметрия линии».

2. Определите правовую границу. Есть ли ПД, коммерческая тайна, КИИ, санкционный риск поставщика. Если да — отсеките лишние контуры сразу.

3. Определите цену ошибки. Черновик для человека терпит consumer и public API. Подсказка оператору — уже нет.

4. Проверьте, нужен ли вам договорной контур. Если нужен SSO, журнал аудита, роли и ответственность поставщика, consumer отпадает автоматически.

5. Поймите, что важнее: скорость старта или суверенность. Быстрее всего стартуют 1-3. Лучше всего контролируются 5-6.

6. Зафиксируйте решение письменно. В карточке проекта должно быть указано: какой контур выбран, почему остальные отклонены и что станет триггером миграции в более жёсткий контур.

Что обычно выбирают зрелые команды

Зрелая команда почти никогда не живёт в одном контуре навсегда. Нормальная траектория выглядит так:

• обучение команды и сравнение моделей — контуры 1 или 2 на синтетике;
• первый корпоративный помощник по внутренним знаниям — контуры 3 или 4;
• рабочий контур для чувствительных данных — контуры 4 или 5;
• всё, что касается значимых объектов КИИ, диспетчеризации, технологических режимов и закрытых сегментов — контуры 5 или 6.

То есть вопрос не «какой контур правильный вообще». Правильный вопрос — какой контур правильный для этой задачи на этом этапе зрелости. Но и здесь есть жёсткая оговорка: некоторые задачи сразу перепрыгивают через ранние стадии. КИИ, ПД, чувствительная КТ и санкционно нестабильный стек — как раз такие случаи.

Итоги