Внедрение ИИ в бизнес-процессы: пилот через API

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

Кратко

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

Что такое внедрение ИИ в бизнес-процессы

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

Языковая модель через API получает инструкцию и данные, а затем возвращает текст или структурированный объект. В пилоте можно проверить:

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

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

Как выбрать первую задачу для пилота

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

Перед тестом зафиксируйте четыре элемента:

1. Входные данные. Что получает модель: письмо, заявка, договор, карточка товара или фрагмент базы знаний.
2. Ожидаемый результат. Свободный текст, список или JSON с конкретными полями.
3. Ограничения. Что модели запрещено додумывать и когда она должна вернуть «недостаточно данных».
4. Проверка. Кто принимает ответ и какие ошибки считаются критичными.

Если эти пункты нельзя сформулировать на одной странице, задача пока слишком широкая для первого пилота.

Как подготовить тестовые данные

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

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

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

Как вызвать модель через kosareva.cloud

У kosareva.cloud OpenAI-совместимый API, поэтому для пилота подойдут стандартный SDK и обычный HTTP-запрос. Актуальный идентификатор модели возьмите в каталоге и подставьте вместо MODEL_ID.

Пример на Python

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_KOSAREVA_CLOUD_KEY",
    base_url="https://api.kosareva.cloud/v1",
)

response = client.chat.completions.create(
    model="MODEL_ID",
    messages=[
        {
            "role": "system",
            "content": "Классифицируй обращение и не добавляй фактов от себя.",
        },
        {
            "role": "user",
            "content": "Заказ приехал, но в коробке нет кабеля.",
        },
    ],
    temperature=0,
)

print(response.choices[0].message.content)

Тот же запрос через cURL

curl https://api.kosareva.cloud/v1/chat/completions \
  -H "Authorization: Bearer YOUR_KOSAREVA_CLOUD_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_ID",
    "temperature": 0,
    "messages": [
      {
        "role": "system",
        "content": "Классифицируй обращение и не добавляй фактов от себя."
      },
      {
        "role": "user",
        "content": "Заказ приехал, но в коробке нет кабеля."
      }
    ]
  }'

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

Три промпта для пилотного проекта

Классификация обращений

Ты классифицируешь входящие обращения.

Допустимые категории:
- оплата;
- доставка;
- возврат;
- технический вопрос;
- другое.

Верни только JSON:
{
  "category": "",
  "reason": "",
  "needs_human": true
}

Не добавляй фактов, которых нет в обращении.
Если категории недостаточно для уверенного выбора,
укажи "другое" и установи needs_human в true.

Обращение:
[ВСТАВЬТЕ ОБЕЗЛИЧЕННЫЙ ТЕКСТ]

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

Извлечение данных из документа

Извлеки из текста только явно указанные сведения.

Верни JSON:
{
  "document_type": null,
  "date": null,
  "organization": null,
  "amount": null,
  "currency": null,
  "missing_fields": []
}

Не вычисляй и не угадывай значения. Если поле отсутствует,
оставь null и добавь его название в missing_fields.

Текст:
[ВСТАВЬТЕ ФРАГМЕНТ ДОКУМЕНТА БЕЗ КОНФИДЕНЦИАЛЬНЫХ ДАННЫХ]

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

Черновик ответа клиенту

Подготовь черновик ответа на обращение.

Правила:
- используй только сведения из обращения и справки;
- не придумывай сроки, цены и условия;
- если данных не хватает, задай один уточняющий вопрос;
- не обещай результат;
- объём — до 700 знаков.

Обращение:
[ТЕКСТ]

Справка:
[ПРОВЕРЕННАЯ ИНФОРМАЦИЯ КОМПАНИИ]

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

Как оценить результат без выдуманных показателей

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

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

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

Как перейти от теста к рабочему процессу

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

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

Если качество нестабильно, по очереди проверьте инструкцию, формат ответа, справочный контекст и выбранную модель. Меняйте по одному фактору и повторяйте один и тот же тестовый набор.

Чего не даст первый пилот

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

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

FAQ

Обязательно ли сразу автоматизировать весь процесс?

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

Можно ли полностью доверить модели ответы клиентам?

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

Как сравнивать несколько моделей?

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

Сколько стоит внедрение ИИ в бизнес-процессы?

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

Что делать, если модель не уверена в ответе?

Предусмотрите ответ «недостаточно данных» или поле передачи задачи сотруднику. Неоднозначный случай не должен автоматически переходить к следующему действию.

Вывод

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

Источники

• NIST — AI Risk Management Framework
• OWASP — LLM02:2025 Sensitive Information Disclosure
• OpenAI — Structured model outputs