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