Страх понятный: сегодня зарубежный ИИ-сервис работает, завтра доступ ограничили — и час...
Страх понятный: сегодня зарубежный ИИ-сервис работает, завтра доступ ограничили — и часть бизнеса встала. Но вывод «тогда лучше вообще не внедрять ИИ» для меня звучит примерно как «не будем нанимать сильных сотрудников, потому что они могут уйти». Проблема не в самом ИИ. Проблема начинается, когда компания отдаёт одной модели весь процесс и больше не понимает, что происходит внутри. Я бы строил иначе: процесс должен принадлежать бизнесу, а не сервису. Это значит, что в компании остаются правила работы: откуда приходят данные, какие шаги выполняются, что считается хорошим результатом, кто и как его проверяет. Экспертность сотрудника нужно переносить из головы в регламенты, инструкции, чек-листы, эталоны и референсы. Тогда конкретная модель — важная, но заменяемая часть системы. Если завтра она становится недоступна, процесс не исчезает вместе с ней. Его можно временно продолжить руками, перевести на другой сервис или распределить между несколькими моделями. Да, слабую модель не получится механически поставить на место сильной и ждать того же качества. Придётся менять отдельные шаги, промпты и проверки. Иногда одну операцию, которую раньше выполняла одна модель, нужно разделить между двумя. Но это перенастройка системы, а не остановка бизнеса. Резерв я бы закладывал на нескольких уровнях: — альтернативный способ доступа к основному сервису; — китайские и отечественные решения для подходящих задач; — локальная модель там, где важны автономность и контроль данных; — понятный ручной маршрут для критических операций; — эталоны, референсы и объективные метрики, по которым можно сравнить основной и резервный варианты. Последний пункт особенно важен. Нельзя решить, подходит ли замена, по ответу «выглядит нормально». Если система пишет тексты — нужны примеры приемлемого результата. Если разбирает звонки — размеченная выборка. Если работает с данными — проверяемые расчёты и правила. Только так видно, где резерв действительно справляется, а где качество просело. У меня уже был бизнес, который сильно зависел от качества модели. Во времена ChatGPT 3.5 и появления GPT-4 мы строили стартап по оценке звонков. Система обрабатывала часовую Zoom-презентацию за 3–5 минут и достигала точности до 80%. Разница между моделями тогда напрямую влияла на результат. Но ценность была не в названии модели. Она была в описанном процессе: что искать в разговоре, по каким критериям оценивать, с чем сравнивать ответ и как проверять качество. Без этого более сильная модель просто быстрее производила бы убедительный текст. То же самое с аналитикой. Основную воспроизводимую логику можно вынести в SQL и Python, а ИИ использовать при проектировании и улучшении. Тогда каждый рабочий запуск не зависит от того, ответит ли сегодня конкретный чат. Есть ещё один риск, о котором говорят реже: заменить незаменимого сотрудника незаменимым ИИ-оператором. Если вся логика снова находится у одного человека — только теперь он единственный знает, как работает автоматизация, — bus factor никуда не делся. Зрелое внедрение делает обратное: вытаскивает экспертизу из головы, закрепляет её в процессе и позволяет следующему сотруднику освоить работу. ИИ здесь помогает быстрее собирать и исполнять систему, но не должен становиться её единственной опорой. Поэтому я не вижу смысла отказываться от ИИ из-за возможных блокировок. Я вижу смысл заранее проверить неприятный сценарий: если завтра основной сервис пропадёт, какие операции продолжатся, какие перейдут человеку и сколько времени займёт переключение? Если ответа нет, у бизнеса пока не система, а одна удобная кнопка.