Один и тот же ИИ-ассистент можно собрать тремя способами: вызывать зарубежную модель по API, купить контур в российском облаке или развернуть модель на собственных серверах. Функционально — похоже, юридически и по цене — три разные истории. Ошибка в выборе места обработки данных обходится дороже самой разработки: от требований локализации до невозможности пройти аудит корпоративного клиента.
Выбор не должен опираться на привычку или обещания продажников вендора. Ниже — семь шагов: от классификации данных сценария до фиксации решения в документах. Методика одинаково работает для чат-бота на сайте, внутреннего ассистента по регламентам и генерации коммерческих предложений. Разовая консультация с подбором режима и вендора у НЬЮ-ССТ — от 90 000 ₽ (сентябрь 2026).
Пошаговый план
Классифицируйте данные сценария
Выпишите, что реально попадёт в промпты и базу знаний: публичные материалы сайта, внутренние регламенты, персональные данные клиентов, коммерческие условия, кадровые документы. Для каждого элемента — класс по вашей политике. Смешанные данные разбивайте: часть сценария может работать на публичных данных через API, чувствительная часть — в закрытом контуре; это нормальная архитектура, а не исключение.
Проверьте правовые ограничения
Базовые опоры — 152-ФЗ: первичный сбор персональных данных граждан РФ должен происходить на территории России; запись, систематизация и накопление этих данных — в базах на территории РФ; трансграничная передача — по основаниям с учётом требований к иностранным получателям. Отдельные режимы — гостайна, банковская и отраслевая тайны, требования к государственным информационным системам с ИИ-модулями. Если в сценарии есть персональные данные, зарубежный публичный API отпадает сразу — дальнейшие шаги выбирают между контурами в РФ.
Перечислите доступные режимы обработки
Их обычно три: внешний API модели (быстро, дёшево на старте, данные уходят провайдеру); выделенный контур у российского оператора или вендора модели (данные в РФ, изоляция на договоре, доступ к администрированию); собственная инфраструктура с open-weights моделью — полный контроль, вся ответственность на вашей команде. Для каждого режима зафиксируйте, где физически обрабатываются промпты, логи и векторная база знаний — это три разных хранилища, и правила у них могут различаться.
Сравните режимы по единым критериям
Составьте таблицу: соответствие классу данных, срок запуска, разовая и ежемесячная стоимость, контроль над моделью и обновлениями, проверяемость для аудита, нагрузочная способность. Оцените каждый режим по каждому критерию — числом или баллом, а не прилагательными. Модельный пример: публичный API закрывает класс «публичные данные» за дни, выделенный контур в РФ берёт персональные данные за 4–8 недель, собственное развёртывание — 0,9–1,2 млн ₽ на старт контура среднего масштаба.
Задайте вендору правильные вопросы
До договора получите письменные ответы: где физически обрабатываются промпты и ответы; обучается ли модель на ваших данных и как отключить это; где хранятся логи и кто их читает; возможен ли экспорт данных при расторжении; проходит ли вендор аудит и готов ли показать отчёт. Ответы «не волнуйтесь, всё безопасно» — не ответ: фиксируйте каждый пункт в договоре. Вопросы одинаковы и для зарубежных, и для российских провайдеров — различия проявятся в самих ответах.
Зафиксируйте выбор в документах
Решение оформите протоколом: сценарий, класс данных, выбранный режим, обоснование, ограничения. Режим пропишите в политике использования ИИ, запись о системе и месте обработки внесите в реестр ИИ-активов, для персональных данных — в DPIA и уведомлении оператора. Без бумажного следа через год никто не вспомнит, почему ассистент с клиентскими данными живёт именно в этом контуре, и каждую проверку придётся разбирать заново.
Проверьте выбор на пилоте и пересматривайте
Пилот покажет то, чего не видно в таблице: реальную долю эскалаций, качество ответов в выбранном контуре, стоимость токенов на вашем профиле нагрузки, скорость поддержки вендора. Зафиксируйте метрики пилота против ожиданий. Пересмотр привяжите к событиям: появились персональные данные в новом сценарии, сменился провайдер, изменились требования локализации или договорные условия вендора.
Чек-лист
Решение о месте обработки готово, если:
- Данные сценария классифицированы, смешанные потоки разделены
- Персональные данные россиян выделены в отдельный контур
- Ограничения локализации и трансграничной передачи проверены
- Отраслевые требования (ГИС, тайны) учтены или исключены
- Режимы обработки перечислены с физическим расположением
- Промпты, логи и векторная база рассмотрены как отдельные хранилища
- Таблица сравнения заполнена по единым критериям
- Стоимость посчитана на вашем профиле нагрузки, а не на демо
- Вендор письменно ответил про обучение на данных и логи
- Условия экспорта данных при выходе зафиксированы в договоре
- Протокол выбора подписан и датирован
- Политика использования ИИ и реестр активов обновлены
- DPIA и уведомление отражают место обработки
- Метрики пилота сверены с ожиданиями, дата пересмотра назначена
Что влияет на результат
Итоговое решение сильнее всего зависит от состава данных и дисциплины вендоров. Если в сценарии нет персональных данных и тайн, выбор сводится к экономике и скорости — побеждает самый дешёвый быстрый вариант. С персональными данными картина меняется: решающими становятся территория обработки, договорные гарантии и проверяемость, а цена уходит на второй план. Влияет профиль нагрузки: редкие мощные запросы и круглосуточный поток миллионом мелких обращений по-разному ложатся на тарифы API и на собственный контур. Наконец, значение имеет аудитория заказчика: работа с госструктурами и крупными корпорациями часто предъявляет собственные требования к контуру, и режим выбирается под самого строгого потребителя результата, а не под средний сценарий.
Практика показала: решение, принятое за один день без таблицы, меняется потом вдвое дольше. Выделите на выбор неделю: два дня на классификацию данных, два на сбор письменных ответов вендоров, остальное — сравнение и протокол. Вопросы отправляйте всем кандидатам одновременно одинаковым списком — различия в полноте ответов сами по себе критерий выбора. Не поддавайтесь на давление сроков запуска: контур, выбранный наспех под пилот, живёт в компании годами и становится самым слабым местом на каждом аудите. Если требования могут ужесточиться, закладывайте архитектуру с возможностью переноса: абстракция вызова модели позволяет сменить провайдера без переписывания продукта. И фиксируйте решение датой — через полгода обстоятельства изменятся, и важно понимать, на основании чего выбор делали.
Частые ошибки
Ошибки при выборе места обработки повторяются из проекта в проект:
- Выбор по удобству интерфейса. красивый чат провайдера не отменяет вопроса, где физически обрабатываются персональные данные клиентов
- «Всё в одном контуре». публичные и чувствительные данные в одном режиме переплачивают либо нарушают требования — разделяйте сценарии
- Верба вендору на словах. необеспеченное письменно «мы не обучаемся на ваших данных» — главный источник конфликтов после инцидента
- Забытые логи. промпты вычистили, а история диалогов осталась в логах за пределами РФ — место обработки определяется по всем копиям
- Решение без протокола. без документа о выборе команда через год не вспомнит основание, и система не пройдёт аудит клиента
Инструменты и сроки
Достаточно матрицы «сценарий × класс данных», опросного листа вендора и протокола выбора; по срокам достаточно недели на анализ и сравнение режимов, ещё 4–8 недель на запуск выделенного контура при необходимости. Сравнение режимов по цене ведите на горизонте года: стартовая экономия публичного API часто съедается ростом нагрузки.
- Матрица «сценарий × класс данных»
- Опросный лист для вендора
- Протокол выбора режима
Что получится в итоге
В итоге решение получается обоснованным и спокойно переживает проверку клиента и регулятора: каждый сценарий работает в минимально достаточном контуре, места обработки подтверждены договором и документами, а стоимость посчитана на реальной нагрузке. Такое решение ещё и масштабируется: новый сценарий сначала классифицируется, потом попадает в существующий режим — вместо стихийной покупки нового сервиса под каждую задачу.