Первые правила ИИ в небольшой компании должны отвечать на вопросы этой недели: можно ли вставить письмо клиента в инструмент? Допустимо ли отправить предложенный ответ? Кто проверяет коммерческое предложение? Что делать при выдуманном факте? Длинный документ, который нельзя применить на рабочем месте, не поможет.
Начните с задач и данных
Перечислите три-четыре применения, которые уже встречаются: черновик ответа, резюме встречи, поиск внутренней инструкции или сортировка запросов. Для каждого укажите нужные данные, утверждённый инструмент и аккаунт, а также результат, который проверяет человек. Разделите данные на несколько понятных классов: открытые, обычные внутренние, клиентские или коммерчески чувствительные и закрытые. Названия согласуйте с существующей политикой компании; цель — сделать следующее действие очевидным.
Например, маркетолог готовит черновик страницы на основе открытого описания товара. Сотруднику поддержки, отвечающему на жалобу конкретного клиента, нужен утверждённый рабочий инструмент и действующая политика. Личный аккаунт ИИ не должен становиться неформальным архивом клиентских записей. Для задачи передавайте минимум данных и соблюдайте правила хранения организации.
Человек принимает значимое решение
Отделите подготовку от обязательства. ИИ может предложить формулировку, извлечь поля или найти источник. До отправки сотрудник сверяет факты о клиенте, цены, даты, утверждения о правилах и чувствительные рекомендации с авторитетной записью. Изменение аккаунта, возврат, обещание срока доставки или публикация утверждения остаются за ролью, которая уже имеет соответствующее право.
Нужен и короткий путь для сообщения об ошибке. Сотрудник должен знать, кому сказать об утечке данных, вредной инструкции, выдуманном источнике или действии за пределами полномочий. Сообщение должно приводить к исправлению процесса, а не только к совету «быть внимательнее».
Одностраничное рабочее правило
На каждую задачу заведите строку с пятью полями: допустимые входные данные, разрешённый инструмент, возможный результат ИИ, обязательная человеческая проверка и владелец эскалации. Добавьте три примера: простой разрешённый черновик, случай для проверки и случай для остановки. Разместите правила рядом с работой — например, в справке поддержки или CRM — и назначьте владельца обновления.
Обучайте на недавних обезличенных примерах, а не абстрактных советах по промптам. Попросите каждого найти неподтверждённое утверждение, отсутствующий факт и действие, на которое у модели нет права. Через две недели разберите вопросы и исправления. Перепишите правило там, где обычная работа показала его неясность.
Исследование OECD 2026 года (откроется в новой вкладке) отмечает рост применения ИИ в МСП при неравномерной целевой и безопасной интеграции; выборка более 2000 компаний из 12 стран не является репрезентативной. Опрос U.S. Chamber (откроется в новой вкладке) показывает опасения сотрудников малого бизнеса в США по поводу данных, применимости и навыков. Эти данные обосновывают практическую инструкцию, но предложенное правило — редакционная рамка Methodfield для конкретной команды, не универсальный сертификат соответствия. Руководство об ответственности за ИИ рассматривает действующую систему; здесь речь о повседневной работе сотрудников.
Рабочий артефакт: одностраничный реестр задач ИИ
Держите реестр рядом с работой. Для каждой разрешённой задачи достаточно строки; владелец обновляет её при смене инструмента, данных или границы решения.
| Поле | Пример полезного ответа |
|---|---|
| Задача и ввод | Черновик описания товара по открытым фактам каталога |
| Инструмент | Названный рабочий аккаунт, не личный вход |
| Ограничение данных | Без записи о клиенте и закрытого прайса в этой задаче |
| Проверка | Владелец товара сверяет характеристики до публикации |
| Ошибка | Остановить отправку, сохранить черновик и сообщить владельцу |
Укажите дату пересмотра и простой способ спросить о задаче, которой нет в реестре. Молчание плохо управляет практикой: сотрудникам всё равно нужно завершать работу, и они могут взять доступный инструмент.