Иван Крутько

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

В работе с ИИ компании нередко проходят три стадии: сначала «говорят и верят», потом «внедряют и надеются» и только затем начинают «делать и измерять». По ощущениям, многие из них пока остаются на первых двух этапах. По данным ноябрьского отчета McKinsey «The state of AI in 2025», 62% опрошенных сообщили, что их компании как минимум экспериментируют с ИИ-агентами, а о масштабировании хотя бы в одной бизнес-функции заявили только 23%. При этом Gartner в июне 2025 года спрогнозировал, что больше 40% проектов в области агентного ИИ свернут к концу 2027 года из-за растущих затрат, неясной бизнес-ценности или слабого контроля рисков.

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

Какая задача подходит

Задача готова к хакатону, если выполняются пять условий.

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

Сформулировать задачу помогает простая схема: «помочь (кому) выполнить (конкретное действие), используя (доступные данные). Считаем, что получилось, если (проверяемый результат)».

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

А вот за эти три типа задач в исходном виде на хакатоне лучше не браться:

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

Что подготовить до старта

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

Описание задачи должно объяснить участникам: какую бизнес-проблему нужно решить, что сейчас не работает или отсутствует и почему это важно; что прототип должен уметь к финалу; кто им будет пользоваться; по каким признакам заказчик поймет, что все сделано хорошо; что участники получат для работы, в общих словах, например, «набор документов и тестовый доступ к системе». Сами файлы и доступы выдают уже после отбора.

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

Какими должны быть данные

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

Что обязательно нужно сохранить:

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

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

Инфраструктура и безопасность

По инфраструктуре заказчику вместе с ИТ-службой стоит выяснить:

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

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

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

Зачем заказчику все это

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

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

Автор – Иван Крутько, директор управления SMB и Digital «Софтлайн Решения» (ГК Softline)