Как собрать ИИ-сотрудника с нуля: 5 шагов

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

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

Шаг 1. Как описать роль и границы ИИ-сотрудника?

Сотрудник начинается с одного предложения: кто он и за что отвечает. Роль должна быть узкой. «Ассистент на все руки» звучит удобно, пока не доходит до работы: такой сотрудник плывёт по десяти задачам сразу и каждую делает поверхностно. Формулировка вроде «Ты копирайтер, пишешь посты для Telegram-канала по продукту X» даёт предсказуемый результат с первого прогона.

В описание роли входят четыре вещи:

• Кто он. Профессия, уровень, для кого работает.
• За что отвечает. Конкретные типы задач, которые он делает.
• Чего не делает. Границы, при которых он обязан вернуть задачу человеку.
• Как звучит. Тон и стиль, если сотрудник работает с текстом.

Есть простой тест на ширину роли. Попробуй описать формат готового результата одним предложением: «пост на 800-1200 знаков с крючком в первой строке и одним призывом в конце». Получилось - роль нарезана нормально. Если формат распадается на пять разных вариантов выхода, внутри сидят несколько сотрудников, и их надо разделить.

Границы решают больше, чем кажется на входе. Без них модель ведёт себя как новичок, которому в первый день выдали ключи от всех кабинетов: уверенно называет цифры, обещает клиенту скидку, ставит диагноз по трём симптомам. Пропиши прямо: «Если данных не хватает, задай вопрос вместо догадки. Цены, сроки и скидки клиенту не подтверждай, передавай такие запросы человеку». Отдельной строкой полезно перечислить темы-стопы, где сотрудник обязан молча остановиться: возвраты денег, претензии, юридические формулировки, всё, что касается персональных данных.

Роль удобно писать так, будто объясняешь задачу новому подрядчику по переписке, без возможности созвониться и договорить голосом. Всё, что ты обычно добираешь интонацией («ну ты понял, у нас так не пишут»), придётся выложить буквами. Признак готового описания простой: посторонний человек прочитал три абзаца и сделал работу похожим образом, не завалив тебя десятью уточнениями. Пока такого ощущения нет, описание сырое, и модель будет добирать недостающее собственными догадками, каждый раз новыми.

Чаще всего на этом шаге спотыкаются о слишком широкую роль. «Маркетолог» без уточнения будет метаться между стратегией, текстами и аналитикой, делая всё вполсилы. Разбей его на трёх узких сотрудников, и на выходе получишь трёх крепких вместо одного размытого. Разобраться, какая именно рутина заслуживает первого сотрудника, помогает разбор, с каких задач начинать автоматизацию, а перечень типовых участков собран в материале про то, какие задачи закрывает ИИ-ассистент в бизнесе.

Шаг 2. Какие инструменты дать ИИ-сотруднику?

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

Тип инструмента	Что даёт	Пример задачи
Поиск в вебе	Свежие факты, которых нет в модели	Собрать пятерых конкурентов и их цены
Работа с файлами	Чтение и запись документов	Разобрать бриф, оформить отчёт
Действие вовне	Отправка, публикация, запись в систему	Ответить в чат, создать задачу

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

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

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

Роль на чистом тексте тоже работает. Если задача решается словами и данными, которые ты сам вставляешь в запрос, никакие интеграции не нужны. Момент, когда пора подключать внешние сервисы, узнаётся по симптому: ты начинаешь вручную копировать одно и то же между окнами по десять раз в день. Тогда стоит посмотреть в сторону конструкторов сценариев - например, разобрать, как освоить n8n с нуля. Часть рутины вообще не требует модели: там, где данные обрабатываются по жёсткому правилу без всякого понимания смысла, дешевле короткий скрипт, и границу между этими случаями я разбирал в материале про то, что реально автоматизируется на Python. Механику того, как модель выбирает инструмент и принимает решение о действии, я разбирал отдельно в материале про то, что такое ИИ-агенты для бизнеса.

Шаг 3. Что писать в регламенте (системном промпте)?

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

Каркас, который закрывает большинство ролей:

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

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

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

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

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

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

Шаг 4. Как дать доступ к базе знаний?

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

Что кладёшь в этот документ:

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

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

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

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

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

Шаг 5. Как проверять результат ИИ-сотрудника?

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

Порядок проверки:

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

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

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

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

Финальная проверка на вкус, уместность и ответственность остаётся за человеком. ИИ-сотрудник снимает объём и черновую работу, а подпись под результатом ставишь ты, и это условие не снимается ни на каком уровне зрелости сборки.

Разбор: как собирается сотрудник первой линии поддержки

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

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

Инструменты. На старте ни одного. Владелец копирует вопрос в окно модели и получает черновик ответа, который отправляет сам. Такая ручная стадия нужна, чтобы увидеть реальные обращения до того, как вкладываться в интеграции.

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

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

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

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

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

Какую модель и интерфейс выбрать под сотрудника?

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

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

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

Собрать самому или заказать под ключ?

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

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

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

Как поддерживать сотрудника в рабочем состоянии

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

Версии регламента храни рядом и подписывай, что именно изменилось. Через полгода правил накопится столько, что часть из них перестанет быть очевидной даже тебе, и без пометки о причине легко удалить строку, которая когда-то закрыла неприятную дыру. Одна фраза в скобках («добавлено после того, как пообещал возврат за месяц») экономит потом целый круг разбирательств.

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

Что отвечать на типовые возражения

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

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

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

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

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

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

Ошибки, которые ломают сборку чаще всего

• Широкая роль. Сотрудник берётся за всё и делает каждую задачу поверхностно. Лечится разделением на несколько узких ролей.
• Регламент без примеров. Требования словами модель понимает хуже, чем один показанный образец готовой работы.
• Правка ответов вместо правки правил. Ты вылизываешь текущий ответ, а следующий приходит с той же ошибкой.
• База, которую никто не обновляет. Устаревшая цена звучит так же уверенно, как актуальная, и проскакивает мимо внимания.
• Лишние доступы на старте. Каждый неиспользуемый инструмент добавляет способов сделать не то.
• Отсутствие стоп-правил. Без списка тем, где сотрудник обязан остановиться, он однажды пообещает клиенту то, чего ты не готов исполнить.
• Проверка на удобных задачах. Гладкие примеры создают ложное ощущение готовности, а рвётся всё на пограничных случаях.

Как вырасти от одного сотрудника до отдела

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

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

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

С чего начать сегодня?

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

Готовые системные промпты, шаблоны ролей и разборы связок «роль - инструменты - база» лежат в закрытом канале ИИмперии, там же примеры регламентов, которые можно взять и адаптировать под своё дело.

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

Источники

• OpenAI: руководство по промпт-инжинирингу - как формулировать инструкции и примеры, чтобы модель работала предсказуемо.
• Anthropic: системные промпты и роль модели - про роль и границы сотрудника на уровне системной инструкции.
• Anthropic: обучение примерами в промпте - почему образцы готовой работы поднимают стабильность результата.