Страх понятный: сегодня зарубежный ИИ-сервис работает, завтра доступ ограничили — и часть бизнеса встала. Но вывод «тогда лучше вообще не внедрять ИИ» для меня звучит примерно как «не будем нанимать сильных сотрудников, потому что они могут уйти».

Проблема не в самом ИИ. Проблема начинается, когда компания отдаёт одной модели весь процесс и больше не понимает, что происходит внутри.

Я бы строил иначе: процесс должен принадлежать бизнесу, а не сервису.

Это значит, что в компании остаются правила работы: откуда приходят данные, какие шаги выполняются, что считается хорошим результатом, кто и как его проверяет. Экспертность сотрудника нужно переносить из головы в регламенты, инструкции, чек-листы, эталоны и референсы. Тогда конкретная модель — важная, но заменяемая часть системы.

Если завтра она становится недоступна, процесс не исчезает вместе с ней. Его можно временно продолжить руками, перевести на другой сервис или распределить между несколькими моделями. Да, слабую модель не получится механически поставить на место сильной и ждать того же качества. Придётся менять отдельные шаги, промпты и проверки. Иногда одну операцию, которую раньше выполняла одна модель, нужно разделить между двумя.

Но это перенастройка системы, а не остановка бизнеса.

Резерв я бы закладывал на нескольких уровнях:

— альтернативный способ доступа к основному сервису; — китайские и отечественные решения для подходящих задач; — локальная модель там, где важны автономность и контроль данных; — понятный ручной маршрут для критических операций; — эталоны, референсы и объективные метрики, по которым можно сравнить основной и резервный варианты.

Последний пункт особенно важен. Нельзя решить, подходит ли замена, по ответу «выглядит нормально».

Если система пишет тексты — нужны примеры приемлемого результата.

Если разбирает звонки — размеченная выборка.

Если работает с данными — проверяемые расчёты и правила. Только так видно, где резерв действительно справляется, а где качество просело.

У меня уже был бизнес, который сильно зависел от качества модели. Во времена ChatGPT 3.5 и появления GPT-4 мы строили стартап по оценке звонков. Система обрабатывала часовую Zoom-презентацию за 3–5 минут и достигала точности до 80%. Разница между моделями тогда напрямую влияла на результат.

Но ценность была не в названии модели. Она была в описанном процессе: что искать в разговоре, по каким критериям оценивать, с чем сравнивать ответ и как проверять качество. Без этого более сильная модель просто быстрее производила бы убедительный текст.

То же самое с аналитикой. Основную воспроизводимую логику можно вынести в SQL и Python, а ИИ использовать при проектировании и улучшении. Тогда каждый рабочий запуск не зависит от того, ответит ли сегодня конкретный чат.

Есть ещё один риск, о котором говорят реже: заменить незаменимого сотрудника незаменимым ИИ-оператором. Если вся логика снова находится у одного человека — только теперь он единственный знает, как работает автоматизация, — bus factor никуда не делся.

Зрелое внедрение делает обратное: вытаскивает экспертизу из головы, закрепляет её в процессе и позволяет следующему сотруднику освоить работу. ИИ здесь помогает быстрее собирать и исполнять систему, но не должен становиться её единственной опорой.

Поэтому я не вижу смысла отказываться от ИИ из-за возможных блокировок. Я вижу смысл заранее проверить неприятный сценарий: если завтра основной сервис пропадёт, какие операции продолжатся, какие перейдут человеку и сколько времени займёт переключение?

Если ответа нет, у бизнеса пока не система, а одна удобная кнопка.