С чего начать внедрение AI в компании

Начните с процесса, а не с нейросети

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

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

Как выбрать первый сценарий

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

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

Зафиксируйте исходный процесс и базовый уровень

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

1. 01

   Соберите выборку

   Возьмите реальные обезличенные примеры разных типов: простые, типичные, неполные, противоречивые и потенциально опасные.

2. 02

   Опишите эталон

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

3. 03

   Запишите текущие действия

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

4. 04

   Назначьте владельца

   Один человек отвечает за правила процесса, а не только за технический запуск.

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

Определите данные, доступы и границы

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

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

Соберите пилот как управляемый контур

Даже небольшой пилот лучше строить из понятных этапов. На входе выполняется проверка формата и прав доступа. Затем система извлекает нужный контекст, формирует ответ в заданной структуре и применяет детерминированные проверки. После этого результат получает сотрудник. Его решение — принять, исправить или отклонить — сохраняется вместе с версией инструкции и источниками.

1. 01

   Приём

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

2. 02

   Контекст

   Передать только релевантные сведения с идентификаторами источников и датой актуальности.

3. 03

   Генерация

   Попросить структурированный результат, а не свободный текст, если следующий этап должен его обработать.

4. 04

   Проверки

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

5. 05

   Решение человека

   Показать исходные данные, предложение AI и основания в одном интерфейсе.

6. 06

   Журнал

   Сохранить результат, исправление, статус и технический контекст без секретов.

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

Проверяйте качество до обсуждения масштаба

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

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

Надёжный пилот отвечает не на вопрос «может ли модель сделать это один раз», а на вопрос «какие классы задач она выполняет приемлемо и что происходит за пределами этих классов».

Практический принцип Agentix Labs

План первого внедрения

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

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

Когда пилот готов к эксплуатации

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

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

Что подготовить к первой рабочей встрече

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

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

Этого достаточно, чтобы определить, нужен ли AI, предложить минимальную архитектуру и оценить объём пилота. Если задача пока описана только на уровне идеи, полезным первым этапом станет исследование процесса и данных, а не немедленная разработка.