ChatGPT, готовый сервис или разработка: как выбрать ИИ для бизнеса

Черновик письма раз в неделю удобно готовить в чате с нейросетью. Сотрудник описывает ситуацию, читает ответ, исправляет неточности и отправляет письмо. Отдельная система здесь вряд ли оправданна.

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

Я начинаю выбор с последовательности действий: откуда берутся данные, что с ними делает сотрудник и куда должен попасть проверенный результат. Иногда достаточно сохранить удачный запрос к модели. Иногда выгоднее настроить существующую CRM, убрать лишнее согласование или написать обычную программу без ИИ. Собственная разработка имеет смысл, когда полезный процесс нельзя организовать доступными средствами.

Шесть критериев для сравнения вариантов

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

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

Для сравнения вариантов рядом с каждым своим требованием отмечайте: функция есть и проверена, её можно настроить или её нет. Формулировка «есть интеграция с CRM» слишком общая. Нужно убедиться, что сервис получает нужные поля и записывает результат туда, где сотрудники будут с ним работать.

Где заканчивается польза отдельного запроса

Предположим, сотрудник выгружает сведения из 1С, находит клиента в amoCRM, переносит информацию в чат, а затем копирует ответ обратно. Модель ускоряет обработку текста, но ручные переносы сохраняются. Вместе с ними остаются затраты времени и риск перепутать запись или пропустить часть данных. В таком процессе нужно выяснить, можно ли связать системы готовыми средствами и какая работа после этого останется у человека.

Поиск рекламодателей: сначала получить нужные сведения

В проекте поиска рекламодателей для международного рекламного агентства отдел продаж уже пробовал ChatGPT и другие языковые модели, или LLM. Прямой поиск давал слабый результат. О перспективных рекламодателях нередко узнавали после того, как конкуренты заключили с ними контракты.

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

Я выяснил требования, сделал прототип, затем самостоятельно разработал и запустил систему. Она получает профильную аналитику через API и интерфейсы источников. API позволяет программам обмениваться данными без ручного копирования. Собственные алгоритмы обрабатывают и структурируют сведения, после чего система определяет юридические лица. Затем веб-поиск и языковые модели помогают найти контакты, условия сотрудничества и партнёрские программы.

Подходящие лиды попадают в Google-таблицу с контактами и пояснениями для обращения. Для выбранного типа рекламодателей продажи регулярно получают подготовленную подборку. Это полезный результат предварительного поиска, который не означает охвата всего рынка или гарантированных сделок.

Ответ клиенту: контроль нужен до отправки

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

Например, психолог заказал мне Telegram-бота для самопомощи по своей методике. Методика принадлежит заказчику. Я выбрал языковую модель, подготовил инструкции с учётом контекста и текущей задачи, разработал контроль состояния диалога. Он помогает возвращать разговор к методике при отклонениях, в том числе вызванных ошибками модели, и управлять приоритетом обсуждаемых проблем. Также я реализовал автоматический выбор глубины рассуждения и кэширование, то есть повторное использование сохранённых данных, для снижения расходов на токены.

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

Для массовой обработки документов контроль будет другим: допустимые значения, наличие обязательных полей, согласованность данных и расчётов. Неоднозначные случаи следует передавать сотруднику. Ошибочная категория внутренней заметки и неверное сообщение клиенту имеют разные последствия, поэтому одинаковая проверка для них не подходит.

Сначала определите, куда можно передавать данные

До пробы на рабочих материалах выясните, разрешено ли обрабатывать их в выбранном сервисе. Удаление ФИО и реквизитов само по себе не делает документ безопасным для отправки: в нём могут оставаться другие персональные данные или коммерческая тайна.

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

Когда я руководил развитием корпоративного продукта в «Газпром нефти», требования к безопасности, данным и импортозамещению влияли на выбор технического решения. В подобных задачах разумно начать с инструментов, уже одобренных в компании. Если они подходят для процесса, отдельная разработка ради конфиденциальности может не понадобиться.

GigaChat или YandexGPT в российском облаке, корпоративный сервис и модель на собственных серверах нужно сравнивать по условиям обработки, доступам и устройству всей системы. Российское размещение само по себе не обеспечивает соблюдения 152-ФЗ. Локальная модель тоже не гарантирует изоляции: нужно проверить остальные компоненты и подключения. Допустимость обработки определяет оператор данных с участием правовых специалистов и службы информационной безопасности, а инженер реализует согласованные требования.

После этого можно сравнивать качество на своих материалах. Для документов такой подход подробнее разобран в статье об обработке счетов, актов и УПД.

Недельная проба покажет, чего не хватает

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

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

По итогам недели записи обычно позволяют разделить затруднения по причинам:

• Много переносов между системами. Укажите источник и место назначения данных. Проверьте готовые коннекторы на этих действиях. Недостающая операция станет конкретным требованием к интеграции.
• Ответы приходится исправлять. Разделите формальные и смысловые ошибки. Формат даты или несходящийся итог можно проверять правилами. Для неоднозначного вывода нужно определить, кто и при каких условиях принимает решение.
• Поток не удаётся обработать вовремя. Найдите задержку: подготовка, ручной запуск, ожидание ответа или проверка. Запуск по расписанию не поможет, если сотрудники не успевают проверять результаты.
• Часть материалов нельзя передавать сервису. Уточните, есть ли разрешённый корпоративный инструмент. Если его нет, согласуйте требования к обработке с ответственными за данные, правовые вопросы и информационную безопасность. Обходить запрет ради эксперимента не нужно.

После пробы дополните сравнение вариантов из первой таблицы. Теперь вместо общего пожелания «автоматизировать с ИИ» можно записать: нужен импорт из конкретного источника, проверка определённого поля или передача спорного результата сотруднику.

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

Неделя даёт исходные требования. Она не подтверждает, что решение выдержит пиковую нагрузку и правильно обработает все редкие случаи.

Правила работы нужны и без собственной системы

Для обычного чата достаточно более простого порядка, чем для автоматического клиентского сервиса, но несколько вопросов всё равно нужно решить.

Там, где продукт это поддерживает, используйте управляемые компанией учётные записи. Заранее определите, кто выдаёт и отзывает доступ, что происходит с рабочей историей после увольнения и какие настройки доступны администратору.

Сотрудникам нужны примеры разрешённых и запрещённых данных на знакомых договорах, письмах и выгрузках. Общий запрет на передачу «конфиденциальной информации» оставляет слишком много места для догадок. Также должно быть понятно, кто проверяет факты, расчёты и соответствие задаче перед использованием ответа в отчёте или отправкой клиенту.

Программа сотрудника требует технической проверки

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

В одной из компаний группы, где я работал, сотрудники создавали полезные инструменты с ChatGPT и Claude. Прототипы оставались сырыми: безопасность была недостаточно проработана, порядка поддержки, тиражирования и выдачи доступа коллегам не было. Автор, который не является разработчиком, мог не заметить ключи в коде, зависимость от личной учётной записи или опасные настройки.

Я разработал и согласовал процесс подготовки и выпуска таких программ. Сотрудник выполняет доступную ему базовую подготовку по регламенту и передаёт заявку с кодом в корпоративном репозитории GitLab. Технический ответственный проверяет код, дорабатывает программу и отвечает за её техническую готовность. Специалист DevOps, отвечающий за развёртывание, выпускает подготовленное решение через автоматизированные проверки в тестовую и рабочую среды.

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

За какую работу платят при интеграции ИИ

Если готовые средства не закрывают требования, объём разработки определяется действиями до обращения к модели и после её ответа. Само подключение ИИ часто занимает лишь часть проекта.

Получение данных и правила обработки

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

Далее нужно получить данные и связать записи об одних и тех же объектах. Например, название компании в двух системах может различаться. Для сопоставления могут совместно использоваться правила и модель, а неоднозначные связи требуют проверки.

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

Затем распределяю операции между моделью и обычным кодом. Расчёты и однозначные действия обычно надёжнее выполнять по заданным правилам. Модель полезна для интерпретации неоднородной информации, хотя даже свободный текст не всегда требует LLM. Выбор зависит от качества, стоимости и последствий ошибки. Примеры такого разделения есть в статье «Когда нужен ИИ, а когда достаточно правил».

Проверка результата и работа продукта

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

Согласованные требования к данным определяют размещение, права пользователей и защиту подключений. Собственные серверы потребуют вычислительных ресурсов и сопровождения. Внешний сервис нужно оценить по условиям и доступным настройкам.

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

Передача и дальнейшая поддержка

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

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

Что достаточно подготовить для следующего шага

Выберите один процесс и несколько характерных примеров. Для обсуждения полезно показать:

• что приходит на вход и из какого источника;
• какой результат нужен и куда он должен попасть;
• какую ошибку нельзя допустить;
• какие ограничения действуют для данных и доступа;
• кто принимает результат и разбирает исключения.

Если уже провели пробу, приложите журнал ручных вмешательств. Подробное ТЗ и другие материалы тоже пригодятся, но составлять их специально до первого разговора необязательно.

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