Многие ИИ-решения в российских компаниях построены на зарубежных облачных сервисах — так было быстрее и дешевле начать. Сегодня это источник сразу нескольких рисков: правового, инфраструктурного и платёжного. Разберём, чем заменяются основные компоненты, в каком порядке переходить и что при этом обычно ломается.
Три риска, а не один
- Правовой: передача персональных данных россиян за рубеж — это трансграничная передача со всеми требованиями, а требование локализации баз делает такую схему трудно защитимой.
- Инфраструктурный: доступ к сервису может исчезнуть без вашего участия, и запасного плана обычно нет.
- Платёжный: оплата зарубежных сервисов из России стабильно проблемна, а обходные схемы создают собственные риски.
Важно, что эти риски независимы. Обезличивание закрывает правовой, но не спасает от отключения. Оплата через посредника решает платёжный, но не влияет на правовой. Планировать замену надо по всем трём.
Чем заменяются основные компоненты
Языковая модель
Два пути: российская облачная модель или открытая модель в своём контуре. Первый быстрее, второй надёжнее. На узких прикладных задачах — классификация, извлечение полей, ответы по базе знаний — разница в качестве обычно невелика. На задачах со сложным рассуждением потери заметны, и здесь стоит закладывать более сильную модель или разбивать задачу на шаги.
Векторный поиск
Самая простая часть миграции. Открытые векторные базы полноценны и разворачиваются локально. Модель векторизации тоже заменяется на открытую — здесь важно проверить качество именно на русском языке, у моделей оно различается заметно.
Распознавание речи и синтез
Есть и российские облачные сервисы, и открытые модели для локального развёртывания. Качество на русском у российских решений обычно выше, чем у универсальных зарубежных, — это тот случай, когда замена улучшает результат, а не ухудшает.
Компьютерное зрение
Практически не затронуто проблемой: основные библиотеки и предобученные модели открыты и работают локально. Если решение построено на облачном сервисе распознавания, замена на собственную модель обычно даёт ещё и выигрыш в стоимости на объёме.
Инструменты разработки и мониторинга
Здесь замена почти всегда есть, и часто открытая. Основная работа не в поиске аналога, а в переносе накопленных данных: истории экспериментов, метрик, версий моделей.
Порядок перехода
- Инвентаризация: какие внешние сервисы используются, где именно и какие данные через них проходят. Обычно на этом шаге обнаруживаются два-три сервиса, о которых никто не помнил.
- Приоритизация по риску: сначала то, через что идут персональные данные и что критично для процесса.
- Изоляция: работа с внешним сервисом убирается за собственный интерфейс. Это делается до замены и превращает её из переписывания в подмену реализации.
- Замер текущего качества: набор реальных задач с эталонными ответами на действующем решении. Без этой точки отсчёта невозможно сказать, стало ли хуже.
- Параллельный запуск: новый вариант работает рядом со старым, ответы сравниваются на одном потоке.
- Переключение и наблюдение: переход с сохранением возможности вернуться.
Шаг с замером текущего качества пропускают чаще всего, и именно он определяет успех. Без него после миграции возникает спор о том, стало хуже или просто кажется, и разрешить его нечем.
Что обычно ломается
Промпты
Инструкции, отлаженные под одну модель, на другой работают хуже. Это не признак плохой модели — просто модели по-разному реагируют на формулировки. Перенастройка промптов — обязательная часть миграции, и её надо закладывать в срок.
Формат ответа
Если код рассчитывает на строгий формат, а новая модель иногда добавляет пояснение перед ответом, ломается разбор. Лечится валидацией и повторным запросом при несоответствии — то, что стоило делать с самого начала.
Длина контекста
У моделей разные ограничения. Решение, привыкшее подавать документ целиком, может не поместиться — потребуется разбиение и переработка логики поиска.
Скорость
Собственная модель на своём железе может отвечать медленнее облачной, особенно под нагрузкой. Если интерфейс рассчитан на мгновенный ответ, потребуется либо оптимизация, либо изменение сценария взаимодействия.
Сколько это занимает
Для изолированного компонента вроде векторного поиска — дни. Для замены языковой модели с перенастройкой промптов и замерами — недели. Для решения, где внешний сервис вплетён в логику без изоляции, — месяцы, и большая часть времени уйдёт не на замену, а на выделение точки подмены.
Отсюда практический вывод для тех, кто только строит решение: изолируйте работу с внешними сервисами сразу. Это дешёвая страховка, которая превращает будущую замену из проекта в задачу.
Карта зависимостей: с чего начать
Прежде чем что-то менять, надо понять масштаб. Инвентаризация звучит скучно, но именно она обычно приносит главные открытия — сервисы, о которых никто не помнил, и данные, которые уходят наружу неочевидными путями.
Составьте таблицу по каждому внешнему сервису: что он делает, какие данные через него проходят, есть ли среди них персональные, насколько критичен процесс за ним, есть ли готовая замена и сколько займёт переход. Этого достаточно, чтобы расставить приоритеты по риску, а не по удобству.
Где обычно находят неучтённое
- Библиотеки, которые ходят в интернет за моделями при первом запуске. Формально это ваш код, фактически — внешняя зависимость.
- Инструменты мониторинга и аналитики, отправляющие данные в облако разработчика.
- Сервисы перевода и проверки текста, встроенные во вспомогательные скрипты.
- Прототипы, которые незаметно стали частью рабочего процесса.
Что делать, если бюджета на миграцию сейчас нет
Полная замена бывает дорогой, и откладывать её иногда приходится. Но есть меры, которые стоят недорого и существенно снижают риск уже сейчас.
- Изолируйте работу с внешним сервисом за собственным интерфейсом. Это часы работы, а будущую замену превращает из переписывания в подмену реализации.
- Прекратите отправлять наружу то, что можно не отправлять. Часто выясняется, что персональные данные попадают в запрос по инерции, а не по необходимости.
- Зафиксируйте текущее качество набором реальных задач с эталонными ответами. Без этой точки отсчёта любая будущая миграция превратится в спор.
- Проверьте замену в тестовом контуре, даже если переходить не собираетесь. Знание, что запасной вариант работает и на сколько он хуже, само по себе снижает риск.
- Опишите план перехода на бумаге со сроками и ответственными. При внезапном отключении наличие плана экономит недели.
Порядок здесь важнее скорости. Изоляция и прекращение отправки чувствительных данных наружу закрывают большую часть риска малой кровью — и делают саму миграцию, когда до неё дойдут руки, задачей на дни вместо месяцев.
Юридическая сторона перехода
Замена технологии обычно тянет за собой документы, и об этом вспоминают поздно.
- Политика обработки персональных данных содержит перечень мест хранения и лиц, которым данные передаются. После миграции его надо обновить.
- Если раньше была трансграничная передача и вы её прекращаете, это тоже отражается в документах — и это хорошая новость для проверяющих.
- Договоры с новым обработчиком должны содержать требования к мерам защиты, а не быть типовым соглашением об оказании услуг.
- Если менялся состав обрабатываемых данных, стоит проверить, покрывают ли действующие согласия новую схему.
Практический совет: включайте юриста в проект миграции с самого начала, а не после технического завершения. Часть решений — например, где именно будут храниться промежуточные данные — проще принять правильно сразу, чем переделывать.
Как понять, что переход удался
Критерий не «работает», а «работает не хуже и проверяемо». Сравните на зафиксированном ранее наборе задач качество до и после. Отдельно посмотрите на худшие случаи, а не только на среднее. Проверьте скорость под реальной нагрузкой, а не на одиночных запросах.
И оставьте возможность вернуться на время наблюдения. Переключение, после которого откат невозможен, превращает любую обнаруженную проблему в аварию вместо рабочей ситуации.
Порядок замены по компонентам: что делать первым
Компоненты различаются и по риску, и по трудоёмкости замены. Разумная последовательность идёт от простого и рискованного к сложному и терпимому.
- Прекратить отправку персональных данных наружу. Часто это не замена сервиса, а обезличивание перед отправкой — дни работы при существенном снижении правового риска.
- Заменить компоненты, где есть прямой открытый аналог: векторная база, модели векторизации, распознавание изображений. Замена механическая, качество проверяется быстро.
- Перевести речевые сервисы. Для русского языка российские решения обычно не уступают, а часто превосходят, и переход даёт улучшение, а не компромисс.
- Заменить языковую модель. Самая трудоёмкая часть из-за перенастройки промптов и повторных замеров, но и самая значимая по риску.
- Перевести инструменты разработки и мониторинга. Терпит дольше всего: они не в контуре обработки клиентских данных и их отключение не останавливает процесс.
Разделение на этапы важно ещё и потому, что позволяет получать результат постепенно. Полная миграция одним куском — это проект на месяцы, который трудно защитить в бюджете. Последовательность из пяти шагов даёт снижение риска уже после первого, и каждый следующий проще обосновать.
Как не попасть в ту же зависимость снова
Миграция решает сегодняшнюю проблему, но не защищает от завтрашней. Несколько принципов, которые делают решение устойчивым независимо от того, что произойдёт с конкретным поставщиком.
Первое: изоляция как постоянная практика, а не разовая мера перед миграцией. Любой внешний сервис — модель, распознавание речи, хранилище — работает через собственный интерфейс вашего приложения. Замена реализации становится задачей на дни при любом развитии событий.
Второе: набор проверочных задач с эталонными ответами живёт постоянно и прогоняется регулярно. Это одновременно и защита от незаметного изменения поведения провайдера, и готовый инструмент для оценки альтернативы, если она понадобится.
Третье: данные и артефакты остаются у вас. Обучающие выборки, веса моделей, история экспериментов, накопленные исправления пользователей — всё это ценность, которая не должна храниться только у поставщика услуги.
Четвёртое: для критичных процессов стоит держать проверенный запасной вариант, даже если он хуже. Знание, что при отключении основного сервиса решение продолжит работать пусть с меньшим качеством, превращает потенциальную аварию в управляемое неудобство.
Что сказать руководству, чтобы миграцию согласовали
Техническая часть обычно понятна раньше, чем находится бюджет. Несколько аргументов, которые работают лучше, чем описание технологических рисков.
Первый: перевести риск в деньги. Не «сервис могут отключить», а «процесс, приносящий столько-то, остановится на столько-то недель, пока мы найдём замену». Оценка сроков восстановления без подготовки — самый убедительный аргумент, потому что она всегда больше, чем ожидают.
Второй: разложить на этапы с быстрым первым результатом. Полная миграция как единый проект пугает суммой. Последовательность, где первый шаг стоит недорого и снимает правовой риск за недели, согласовывается значительно легче.
Третий: показать, что часть замен улучшает решение, а не только страхует. Речевые сервисы на русском, локальное распознавание изображений, собственная модель на большом объёме запросов — во всех этих случаях миграция даёт либо качество, либо экономию. Это меняет разговор с защитного на содержательный.
И последнее: назвать цену бездействия в единицах, понятных финансовой службе. Регулярный платёж зарубежному поставщику с сопутствующими сложностями, отсутствие возможности пройти проверку по локализации, невозможность масштабировать решение без роста внешних расходов — всё это существующие издержки, а не гипотетические риски.
Коротко
- Рисков три — правовой, инфраструктурный и платёжный, и закрываются они разными мерами.
- Векторный поиск и компьютерное зрение заменяются легко, языковая модель требует перенастройки, речь на русском часто становится лучше.
- Перед миграцией обязательно зафиксируйте текущее качество набором реальных задач — иначе результат будет предметом спора, а не измерения.
- Ломаются в первую очередь промпты, формат ответа, длина контекста и скорость.
- Изоляция внешних сервисов за своим интерфейсом — самая дешёвая мера, и делать её надо до того, как замена понадобится.