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

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

1. Выберите одну задачу и один ожидаемый результат

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

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

2. Опишите доступ отдельно от поручения

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

Разделите два вопроса: «Мы попросили не отправлять письмо?» и «У системы вообще есть техническая возможность его отправить?» Если отправка не входит в пилот, сначала проведите его без инструмента отправки. Если нужное ограничение не проверено, так и запишите.

3. Проверьте обычный запрос, затем выход за пределы задачи

Сначала получите ответ на исходное тестовое письмо. Затем отдельно попросите выполнить действие вне согласованной задачи — например, найти ещё один файл или отправить черновик на другой адрес. Делайте это только на тестовых ресурсах, без реальных адресатов.

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

Разбор подготовлен для проекта «Кай · ИИ для бизнеса»: https://t.me/kaiforbiz . В канале рассматриваем инструменты, экономику и риски внедрения ИИ со ссылками на источники.

4. Определите, что увидит человек перед действием

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

В первом пилоте можно оставить только подготовку черновиков. Это уже позволяет оценить качество результата и объём ручной проверки, прежде чем давать системе больше возможностей.

5. Проверьте остановку

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

Если этот шаг пока нельзя проверить, зафиксируйте ограничение. Не заменяйте отсутствующую проверку предположением, что отключение обязательно сработает.

Как записать результат без сложной аналитики

Для одной проверки достаточно следующих полей:

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

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

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

Исходная тема редакционного разбора: https://t.me/kaiforbiz/91