Короткий ответ: своя модель в контуре нужна тогда, когда есть внешнее требование, которое нельзя закрыть иначе, — и почти никогда не нужна ради экономии или ощущения надёжности. По деньгам собственный сервер проигрывает облаку в несколько раз на любых объёмах, реальных для компании 50–200 человек. Он выигрывает ровно в одном: данные не покидают вашу сеть, и это единственный аргумент, который стоит того, чтобы платить разницу.
Проблема в том, что разговор о контуре обычно начинается не с требования, а с тревоги. Собственник читает про утечки, служба безопасности говорит «наружу ничего не отдаём», ИТ-директор соглашается — и компания покупает сервер за миллион с лишним, чтобы обрабатывать переписку, в которой нет ничего, кроме адреса доставки и названия товара. Через полгода узел загружен на два процента, администратор уволился, а модель работает на весах годичной давности.
Ниже — рабочий фильтр. Пять признаков, при которых контур обязателен; четыре повода, по которым его берут зря; честная граница того, что on-premise закрывает по 152-ФЗ, а что остаётся на вас; расчёт гибридной схемы, которая в большинстве случаев оказывается верным ответом; и форма записки на одну страницу, которой оформляется решение. Технические конфигурации и бюджеты железа разобраны отдельно — в статье про локальную модель под 152-ФЗ.
Пять признаков, при которых свой контур обязателен
Каждый из них — внешнее требование, а не внутреннее предпочтение. Проверка простая: признак засчитывается, только если вы можете показать документ, в котором он написан. Не пересказать, а показать: пункт закона, статью договора, отраслевой приказ, служебную записку с подписью.
- 1Специальные категории персональных данных. Состояние здоровья, диагнозы, биометрия, данные о судимости, религиозные и политические убеждения. Если в текст, который уходит в модель, попадает хоть строка такого рода — например, жалоба пациента с описанием симптомов, — режим обработки становится строже, и передача третьему лицу требует отдельного и очень аккуратного основания. Что именно вы обязаны делать как оператор, разобрано в статье про обязанности оператора персональных данных.
- 2Коммерческая тайна в документах. Не «конфиденциально» на словах, а введённый в компании режим коммерческой тайны с перечнем сведений и подписями сотрудников. Если договор с поставщиком или расчёт себестоимости входит в этот перечень, отправка его во внешний сервис — это раскрытие, и объясняться придётся не с проверяющим, а со своей же службой безопасности.
- 3Условие заказчика или госконтракта. Прямой пункт в договоре: обработка данных заказчика только на территории и в инфраструктуре исполнителя, без привлечения третьих лиц. Такой пункт встречается всё чаще, и он не обсуждается — либо контур, либо отказ от контракта.
- 4Отраслевой регламент. Медицина, финансы, оборонный заказ, критическая информационная инфраструктура. Здесь требование приходит не из 152-ФЗ, а из отраслевого регулирования, и оно обычно жёстче общего.
- 5Письменный запрет службы безопасности на внешние вызовы. Именно письменный, с подписью и обоснованием. Устное «мы против» — это не признак, а начало разговора: часто выясняется, что запрет относится к конкретному классу данных, и после обезличивания на входе возражение снимается.
Наличие любого из пяти делает контур обязательным. Но проверять стоит все, потому что от их количества зависит архитектура: один признак почти всегда закрывается гибридом — локально обрабатывается только чувствительный поток. Три и больше обычно означают, что весь процесс придётся держать внутри, и тогда гибрид только усложняет схему без выигрыша.
Четыре повода, по которым контур покупают зря
Это не редкие случаи. По нашему опыту разбора входящих запросов на локальную модель примерно половина заканчивается выводом «вам это не нужно», и почти всегда причина — один из четырёх поводов ниже.
| Повод | Что на самом деле | Что делать вместо этого |
|---|---|---|
| «У нас переписка с клиентами, это персональные данные» | Имя и телефон — обычные персональные данные, а не специальная категория. Российское облако с серверами в РФ закрывает вопрос трансграничной передачи полностью | Взять российское облако, подписать поручение обработки, получить письменный отказ провайдера от обучения на ваших запросах |
| «Данные публичные, но пусть лучше свои» | Каталог товаров, тексты сайта, инструкции, открытые прайсы — обрабатывать их локально нет ни одной причины | Разделить поток: публичное — в облако, всё остальное разбирать по существу |
| «Мы небольшие, но хотим сразу правильно» | При 3 000–15 000 обращений в месяц контур стоит в 5–8 раз дороже облака. «Сразу правильно» на этих объёмах — это как раз облако | Заложить адаптер, который позволит перенести обработку в свой контур за часы, когда появится требование |
| «Чтобы было надёжнее» | Свой сервер надёжнее только при своём администраторе и резервном узле. Без них один отказ останавливает процесс на день, а облако — нет | Сформулировать требование письменно. Если формулировка не получается — требования нет |
Сравнение в две колонки. Левая, с рамкой сплошной линией, подписана «Признак: есть документ» и содержит пять строк: «Специальные категории ПД», «Режим коммерческой тайны», «Пункт договора или госконтракта», «Отраслевой регламент», «Письменный запрет службы безопасности». Правая, с рамкой штриховой линией, подписана «Повод: документа нет» и содержит четыре строки: «Это персональные данные», «Пусть лучше свои», «Хотим сразу правильно», «Чтобы было надёжнее». Между колонками вертикальный разделитель с подписью «Покажите документ». Чертёжный стиль, подписи по-русски.
Что on-premise снимает, а что остаётся на вас
Самое частое заблуждение про локальную модель звучит так: «поставим свой сервер и закроем вопрос с персональными данными». Свой сервер закрывает один вопрос из трёх. Остальные два остаются, и проверяющий спросит о них независимо от того, где считает модель.
| Обязанность | Свой контур | Российское облако | Комментарий |
|---|---|---|---|
| Трансграничная передача данных | Снимается по построению | Снимается договором о размещении серверов в РФ | Оба варианта решают вопрос, просто разными средствами |
| Третье лицо в цепочке обработки | Снимается: обработчика нет | Остаётся: нужно поручение обработки провайдеру | Единственная обязанность, которую контур убирает целиком |
| Правовое основание и цели обработки | Остаётся полностью | Остаётся полностью | Локальность не создаёт основания. Согласие или иное основание нужно так же |
| Журналы доступа: кто читал диалоги | Остаётся, и делать журнал придётся самим | Остаётся, часть журналов даёт платформа | В своём контуре это дополнительная работа, а не готовая функция |
| Срок хранения диалогов и их удаление | Остаётся полностью | Остаётся полностью | Диалог с моделью — такая же запись, как письмо в почте |
| Поручение обработки подрядчику сопровождения | Остаётся: администратор подрядчика видит данные | Остаётся | Самая частая забытая бумага в проектах с локальной моделью |
| Ответственность за утечку и уведомление регулятора | Остаётся целиком на вас | Остаётся на вас как на операторе | Свой сервер не перекладывает ответственность, а концентрирует её |
Считайте по строкам: из семи обязанностей контур снимает одну и помогает с ещё одной. Пять остаются в любом случае, и три из них — журналы, сроки хранения и поручение подрядчику — в локальном варианте оказываются дороже, потому что готовых инструментов платформы у вас нет и всё это делается руками. Об этом стоит помнить, когда служба безопасности представляет контур как способ закрыть тему целиком.
Локальный сервер обслуживает живой человек: обновляет веса, чинит отказы, разбирает очередь запросов. При отладке он неизбежно видит содержимое обращений — то есть те самые данные, ради которых покупался контур. Если сопровождение отдано подрядчику, нужны поручение обработки, перечень допущенных лиц, NDA и журнал доступа к серверу. Компании, которые ставят контур «чтобы данные никто не видел», обычно узнают об этом на первом же инциденте. Как ограничивать такой доступ технически, разобрано в статье про принцип минимальных прав.
Гибрид: чувствительное — локально, остальное — в облако
Когда признак ровно один — например, специальные категории данных встречаются в пятой части обращений, — тратить полную цену контура на весь поток не нужно. Гибридная схема обрабатывает чувствительные обращения на маленьком локальном узле, а всё остальное отправляет в российское облако. Ключевой элемент здесь не модель, а решение о том, куда направить конкретное обращение.
- 1Классификатор чувствительности на входе
Первый шаг конвейера — не модель, а быстрая проверка: есть ли в тексте признаки специальной категории, номер договора из перечня коммерческой тайны, имя контрагента из закрытого списка. Работает на правилах и словарях, а не на модели: правило проверяемо построчно и не «галлюцинирует».
- 2Правило маршрутизации и правило сомнения
Совпал признак — обращение идёт на локальный узел. Не совпал — в облако. Не удалось определить — по умолчанию на локальный узел: цена лишнего локального вызова несопоставима с ценой ошибочной отправки наружу.
- 3Журнал маршрута
На каждое обращение пишется строка: время, кто, по какому правилу, куда ушло. Это единственный документ, которым вы сможете доказать проверяющему или заказчику, что чувствительный поток наружу не выходил.
- 4Владелец правил и порядок пересмотра
Список признаков живёт: появляются новые типы обращений, новые контрагенты, новые категории. Нужен человек, который раз в квартал пересматривает правила, и порядок разбора спорных случаев. Без этого через год половина потока уйдёт в «по умолчанию локально», и гибрид превратится в дорогой контур.
Гибрид не бесплатен: классификатор, маршрутизация, журнал и регламент — это разовая надстройка. Считаем её честно: классификатор чувствительности и маршрутизатор — 25 часов, журнал маршрута и отчёт «что куда ушло» — 8 часов, повторный замер качества на второй модели — 14 часов, регламент и разбор спорных случаев — 6 часов. При ставке 3 000 ₽/час это 159 000 ₽ разово. При экономии 35 670 ₽ в месяц надстройка окупается за 4,5 месяца, а за год гибрид экономит 428 040 ₽ против чистого контура.
Карта потока слева направо. Слева блок «Входящие обращения: 10 000 в месяц». Далее ромб «Классификатор чувствительности: правила и словари» с тремя выходами. Верхний выход подписан «признак совпал — 3 000» и ведёт к блоку «Локальный узел, 24 ГБ» внутри рамки «периметр сети». Нижний выход подписан «признака нет — 7 000» и ведёт к блоку «Российское облако». Третий, короткий выход подписан «не определено — по умолчанию локально» и загибается к верхнему пути. Под ромбом отдельный блок «Журнал маршрута: время, кто, по какому правилу, куда». Внизу подпись: «54 030 ₽ в месяц против 89 700 ₽».
Полная цена контура: в год и на одно обращение
Смету контура почти всегда считают по одной строке — стоимости железа. Это примерно треть расхода. Ниже — три варианта на одинаковой нагрузке 10 000 обращений в месяц, в месяц, в год и в пересчёте на одно обращение. Разработка самого агента, база знаний и интеграции в расчёт не входят: они одинаковы во всех трёх вариантах и стоят 250 000–500 000 ₽ по рыночным ориентирам на заказного ИИ-агента.
| Вариант | В месяц | В год | Цена одного обращения | Что вы за это получаете |
|---|---|---|---|---|
| Российское облако | 10 400 ₽ | 124 800 ₽ | 1,04 ₽ | Нет трансграничной передачи. Остаётся третье лицо в цепочке и поручение обработки |
| Гибрид: локальный узел + облако | 54 030 ₽ | 648 360 ₽ | 5,40 ₽ | Чувствительный поток не покидает сеть, остальной идёт в облако. Плюс 159 000 ₽ разово |
| Чистый контур, средняя конфигурация | 89 700 ₽ | 1 076 400 ₽ | 8,97 ₽ | Наружу не уходит ничего. Все журналы, сроки хранения и дежурство — ваша работа |
Из этой таблицы следует цифра, которую стоит произнести на совещании вслух: требование держать всю обработку в своём контуре стоит компании около 950 000 ₽ в год при потоке 10 000 обращений в месяц — это разница между 1 076 400 ₽ и 124 800 ₽. Если требование настоящее, это нормальная цена за закрытый вопрос, и её надо заложить в бюджет. Если требования нет, а есть тревога, компания платит 950 000 ₽ в год за ощущение.
Цена одного обращения падает по мере роста объёма: при 30 000 обращений в месяц контур даёт 2,99 ₽, а сравнивается с облаком примерно на 86 000 обращений — этот порог мы считали в статье про локальную модель под 152-ФЗ. Для компании 50–200 человек 86 000 обращений в месяц — почти недостижимый объём, поэтому вывод устойчивый: контур берут за требования, а не за экономию, и любая презентация, где он подан как способ сэкономить, считает что-то не то.
Столбчатая диаграмма из трёх столбцов, ось Y — рубли за одно обращение от 0 до 10. Столбцы: «Российское облако — 1,04 ₽», «Гибрид — 5,40 ₽», «Чистый контур — 8,97 ₽». Под каждым столбцом вторая подпись с годовой суммой: 124 800 ₽, 648 360 ₽, 1 076 400 ₽. Между первым и третьим столбцом фигурная скобка с подписью «цена требования: 951 600 ₽ в год». Внизу подпись: «нагрузка 10 000 обращений в месяц, сентябрь 2026, модельный расчёт».
Записка на одну страницу, которую примет служба безопасности
Решение о контуре — это решение на миллион с лишним в год, и оно должно быть оформлено так, чтобы через год его можно было перечитать и понять, почему так решили. Работающая форма — одна страница из семи пунктов. Её принимают и служба безопасности, и аудит, и внешний проверяющий, потому что в ней есть главное: связь между требованием и потраченными деньгами.
- 1Процесс и его владелец. Какой именно процесс автоматизируется, кто отвечает за результат, сколько обращений в месяц проходит. Одна-две строки.
- 2Что фактически уходит в модель. Не «персональные данные», а пример реальной строки запроса с замазанными значениями. Это самый полезный пункт: половина споров заканчивается прямо здесь, когда выясняется, что в модель уходит номер заказа и текст вопроса, а не карточка клиента.
- 3Требование, которое заставляет держать контур. Цитата из документа с реквизитами: пункт закона, статья договора, номер приказа, дата и подпись служебной записки. Если процитировать нечего — переходите к пункту 7.
- 4Отвергнутые варианты и почему. Обезличивание на входе — почему не подходит. Российское облако с поручением обработки — почему не закрывает. Гибрид — почему не применим. По одному предложению на вариант.
- 5Архитектура в трёх строках. Где стоит узел, какая модель и какого размера, кто и как получает к нему доступ, где лежат журналы.
- 6Эксплуатация. Кто администратор, сколько часов в месяц, что происходит при отказе в пятницу вечером, кто дежурит, есть ли резервный контур.
- 7Деньги. Годовая стоимость выбранного варианта и годовая стоимость отвергнутого — рядом, в двух строках. Разница между ними и есть цена требования из пункта 3.
Записка занимает два-три часа работы и экономит недели споров. Отдельная её польза — диагностическая: если пункт 3 не заполняется, а пункт 7 показывает миллион в год, разговор о контуре закрывается сам собой, без конфликта и без обид. Это тот же принцип, по которому мы просим формулировать требования до старта в статье про подготовку данных к внедрению.
Нарисованный (не скриншот) лист А4 в чертёжном стиле с заголовком «Обоснование размещения модели». Семь пронумерованных блоков сверху вниз с короткими подписями: «1. Процесс и владелец», «2. Что фактически уходит в модель — пример строки», «3. Требование: пункт, дата, подпись», «4. Отвергнутые варианты», «5. Архитектура в трёх строках», «6. Эксплуатация и дежурство», «7. Деньги: 1 076 400 ₽ против 124 800 ₽ в год». Блок 3 обведён жирной рамкой с пометкой на полях «нечего вписать — решение отрицательное». Внизу три линии для подписей: «Владелец процесса», «Информационная безопасность», «ИТ».
Когда решение можно и нужно отложить
Отложить — не значит отказаться. В большинстве случаев правильная последовательность выглядит так: сначала запуститься на облаке, набрать статистику и понять, что за данные реально ходят через систему, и только потом принимать решение о контуре. Причин три.
- Пока процесс не работает, вы не знаете профиль данных. Оценка «у нас там наверняка чувствительное» до запуска почти всегда завышена. После месяца эксплуатации становится видно, что доля действительно чувствительных обращений — не 100 %, а 20–30 %, и это меняет решение с контура на гибрид.
- Пока не измерена нагрузка, конфигурация выбирается наугад. Конфигурация зависит от пиковой одновременной нагрузки, а не от числа сотрудников. Купленный заранее сервер обычно оказывается либо избыточным, либо не тем — как считать пик из своей статистики, разобрано в статье про стоимость сервера под свою модель.
- Пока нет адаптера, переезд дорогой; с адаптером — дешёвый. Заложите в архитектуру слой, который прячет провайдера за единым интерфейсом вызова: 14 часов на старте. После этого перенос обработки из облака в свой контур становится задачей на 34 часа, а не проектом на полтора месяца. Это единственная работа, которую действительно стоит сделать заранее.
И последнее. Свой контур не выключает необходимость думать о том, что модель делает с данными внутри. Она по-прежнему может выдать в ответе фрагмент чужого документа, если базу знаний собрали без разграничения прав; по-прежнему может ошибиться и по-прежнему требует ограничителей и выборочного контроля. Локальность решает вопрос «куда ушли данные», а не вопрос «что система с ними сделала». Это разные задачи, и вторая обычно дороже первой.
