Внедрение ИИ в компании: план на 90 дней с проверкой результатов

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

Что такое внедрение ИИ?

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

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

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

Если бизнес-цель ещё не определена, начните с руководства по стратегии ИИ. Когда цель согласована, следующая задача — собрать доказательства того, что конкретный рабочий процесс работает.

Рекомендации в источниках проверены 28 октября 2026 года. Приведённые ниже сроки и критерии приёмки — предлагаемый порядок работы. Числа в расчётном примере условные и не отражают результаты реального внедрения.

Внедрение ИИ за 90 дней: план из семи шагов

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

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

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

1. Выберите процесс с понятным результатом

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

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

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

Составьте краткое описание процесса:

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

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

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

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

Примеры внедрения ИИ: начните с минимальной полезной задачи

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

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

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

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

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

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

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

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

Внедрение генеративного ИИ: доступ нельзя ограничить одним промптом

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

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

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

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

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

3. Сравните покупку, настройку и разработку по единым критериям

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

Как выбрать подход к внедрению искусственного интеллекта

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

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

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

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

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

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

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

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

4. Сравните пилотный проект ИИ с исходным процессом

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

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

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

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

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

Проводите пилотный проект последовательно, контролируя каждый этап:

1. 1

   Прогоните разрешённые архивные обращения

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

2. 2

   Обработайте текущие запросы, не влияя на результат

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

3. 3

   Подключите помощь ИИ для ограниченной группы

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

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

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

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

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

5. Оцените весь процесс и примите решение

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

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

В этом примере обращения с помощью ИИ требуют на 25% меньше трудозатрат: сокращение времени с 12 до 9 минут экономит 3 минуты на каждом таком обращении. Но для всего процесса снижение трудозатрат составляет 15%, поскольку остальные обращения по-прежнему обрабатываются вручную.

Расчёт выглядит так: 60 × 9 + 40 × 12 = 1,020 минут. По сравнению с исходными 1,200 минутами это высвобождает 180 минут, или 3 часа, на 100 подходящих обращений. Сам по себе расчёт не подтверждает денежную экономию, а небольшая разница в числе обращений, прошедших проверку, не доказывает улучшения качества.

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

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

National Institute of Standards and Technology в сборнике рекомендаций AI Risk Management Framework Playbook советует сравнивать поведение системы в эксплуатации с данными, полученными до запуска, и чётко распределять обязанности между людьми, которые проверяют её работу. При переходе к повседневному использованию сохраняйте единые определения показателей.

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

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

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

6. Расширяйте использование постепенно, сохраняя возможность отката

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

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

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

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

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

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

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

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

7. Передайте процесс ответственному за эксплуатацию

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

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

В комплект передачи процесса должны входить:

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

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

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

Внедрение ИИ не заканчивается запуском

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

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

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

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

Какие ожидания завышены и кому уже пора действовать?

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

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

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

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

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

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

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

С чего начать в понедельник

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

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

Чтобы получать практические руководства по применению ИИ в повседневной работе, подпишитесь на рассылку.