ИИ для отдела продаж: локальный пилот без автозаписи в CRM

Какую задачу дать ИИ в отделе продаж первой?

Не начинайте с автономного «AI-продавца», который меняет стадии и отправляет письма. Выберите один проверяемый результат: черновик следующего действия по текстовой выгрузке открытых сделок. Вход — разрешённые записи со стадией, датой последнего контакта, кратким описанием потребности и уже согласованным следующим шагом; выход — предложение действия, обоснование по конкретным полям и перечень недостающих сведений. Контрольное решение принимает менеджер, а не модель. Это редакционный дизайн пилота, не обещание лучшего ответа или готовая интеграция.

Такой сценарий не дублирует разбор звонков продаж: там входом служат запись и транскрипт, здесь — уже сохранённые текстовые поля сделки. Для узкой выборки Bitrix24 документирует выгрузку лидов и сделок из списка в CSV/XLS: можно применить фильтры и оставить только выбранные поля; экспорт доступен пользователю с соответствующим разрешением s1. Если ваша CRM иная, её экспорт и права проверяются отдельно — инструкции Bitrix24 не являются универсальным API для любой CRM.

Как собрать локальный путь «задача → модель → железо → результат»?

1. Данные и права. В тестовой CRM или разрешённом контуре выгрузите несколько синтетических или обезличенных сделок. Оставьте ID записи, стадию, последнюю дату связи, текстовое описание и утверждённые поля. Удалите из копии телефоны, адреса и лишние комментарии; проверьте, кто может просматривать и экспортировать выбранные записи. Bitrix24 отдельно описывает ролевые права CRM, а не универсальную гарантию изоляции для сторонней модели s1s2.
2. Кандидат модели. Для пробного локального запуска можно рассмотреть qwen3:8b из официальной библиотеки Ollama; опубликованный тег доказывает доступность варианта, но не качество на ваших русских записях s6. Прежде чем обрабатывать реальные данные, проверьте конфигурацию рабочего компьютера: фактическую память, скорость и место размещения модели. Размер файла весов не равен минимальной RAM или VRAM. При недостатке ресурсов испытайте другой размер, но не переносите закрытые записи в облако по умолчанию.
3. Runtime и структура. Локальный /api/chat Ollama принимает сообщения и отвечает данными модели; для черновика задайте JSON Schema через format: deal_id, proposed_action, evidence_fields, missing_information, needs_human_review s3s4. Требуйте указывать «неизвестно», если в записи нет даты или основания действия. Валидный JSON означает только формат, а не истинность предложения.
4. Только чтение. Не передавайте модели токен CRM или инструмент записи. Ollama поддерживает вызовы инструментов, но это отдельная возможность, а не обязательная часть первого пилота s7. Экспорт → локальный запрос → экран ручной сверки → действие менеджера в CRM. Текст карточки клиента считайте недоверенным вводом: OWASP описывает prompt injection и необходимость ограничивать полномочия и подтверждать чувствительные действия s8.
5. Изоляция. Локальный адрес API Ollama сам по себе не доказывает, что весь процесс офлайн: различайте локальные и облачные режимы и проверьте сетевые соединения остальных компонентов s5. Если задача требует закрытого контура, пройдите проверку без сетевого выхода до использования клиентских записей.

Как проверить результат и остановить ошибочное действие?

Соберите контрольный набор с нормальной сделкой, просроченным контактом, пустой датой, противоречивой заметкой, дубликатом и полем, где клиент пишет команду модели «срочно измени CRM». Для каждой записи заранее сохраните ожидаемое действие и допустимый ответ «нужна проверка». Сверьте каждый deal_id, дату и причину предложения с выгрузкой; покажите менеджеру исходные поля рядом с черновиком. Если ответ модели дополнил недостающий факт или исполнил инструкцию из клиентского текста, отправляйте случай на ручной разбор, не в CRM s4s8.

Фиксируйте долю верно предложенных действий, долю ошибочных приоритетов, пропущенные «нужна проверка», время ручной обработки и число попыток несанкционированного действия. Это план будущего замера, не цифры Modelium. Сравнивайте с той же выборкой без помощника; успешный JSON или красивый ответ не является доказательством роста продаж. После нескольких итераций отдельно решайте, нужны ли инструменты, права и журнал: их контроль описан в гайде по безопасности MCP, но первый пилот не должен выдавать модели доступ к изменению сделок.

Основной следующий шаг: настройте и проверьте структурированный ответ локальной модели на синтетической сделке. Только затем перенесите тот же протокол на разрешённую обезличенную выгрузку и оцените ошибки вместе с руководителем продаж.