Генеративный ии: критерии профпригодности для бизнеса

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

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

Универсального проходного балла нет — и это хорошая новость

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

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

Я бы раскладывала его как CJM, но без дизайнерской мистики:

1. Триггер. В какой момент сотрудник или клиент открывает ИИ-инструмент. Он пришёл ускорить рутинную операцию, найти ответ, оформить заявку, принять решение.

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

3. Обработка. Какие источники подключены, какие действия агент вправе выполнить, где он должен остановиться и запросить подтверждение.

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

5. Контроль. Как пользователь видит основание ответа, исправляет его, отменяет действие и сообщает о сбое.

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

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

Генеративный ИИ проходит испытание не на вопросе «умный ли он», а на вопросе «можно ли после его ответа безопасно продолжить рабочий процесс».

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

Риск определяет интерфейс, пороги и роль человека

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

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

NIST рассматривает управление рисками ИИ как непрерывную работу на всём жизненном цикле. Его рамка строится вокруг четырёх функций: Govern, Map, Measure и Manage. Для продуктовой практики это можно перевести без потери смысла.

Govern — назначить владельца. У конкретного сценария должен быть человек, который отвечает не за «ИИ вообще», а за результат в продукте. Например, руководитель поддержки отвечает за качество ответов клиентам, владелец CRM — за действия агента в карточке сделки, служба безопасности — за политику работы с данными. Без владельца обратная связь распадается: ошибки видят все, исправляет никто.

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

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

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

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

Безопасность — это не фильтр токсичных слов

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

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

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

RAG — поиск по корпоративной базе с добавлением найденного контекста в запрос — полезен для релевантности и опоры на документы. Но он не является иммунитетом от prompt injection. То же касается дообучения, системного промпта и контент-фильтров. Каждый механизм закрывает часть поверхности риска, но не отменяет тестирования атакующих сценариев и ограничений на действия агента.

Для живого продукта я бы проверяла как минимум четыре уровня защиты:

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

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

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

Как калибровать качество без магических процентов

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

Для внутреннего низкорискового инструмента с проверкой человеком в качестве отправной точки могут использоваться 90% и выше по безопасности и соблюдению требований, а также 75% и выше по ключевым бизнес-задачам. Для внешнего клиентского агента среднего риска примерный уровень строже: 95% и выше по безопасности, 85% и выше по ключевым задачам.

Есть и понятная логика блокирующих условий. Для среднерискового клиентского агента выпуск стоит останавливать, если показатели безопасности и обработки персональных данных опускаются ниже 95%, а фактическая точность ключевой задачи или заземлённость на базе знаний — ниже 80%. Это не готовая цифра для каждой компании, а способ правильно поставить вопрос: какой сбой мы готовы терпеть, а какой должен немедленно закрыть релиз?

Калибровка работает, когда метрика привязана к операции. «Точность 85%» сама по себе ничего не говорит. Нужно расшифровать, что именно считается верным результатом.

Для ИИ-помощника в поддержке набор может выглядеть так:

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

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

3. Маршрутизация. Агент корректно определяет, когда ответить самому, когда запросить недостающие данные, а когда передать кейс оператору.

4. Безопасность. Сервис не раскрывает лишние сведения, не выполняет запретные действия и устойчив к попыткам обойти инструкции.

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

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

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

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

После релиза начинается настоящая проверка

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

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

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

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

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

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

AI Act: смотреть на роль компании, а не на громкость бренда модели

Регуляторный ландшафт тоже входит в оценку профпригодности, особенно если сервис работает на рынке ЕС или использует модели, выводимые туда. AI Act вступил в силу 1 августа 2024 года. С 2 августа 2025 года начали применяться обязательства для поставщиков моделей ИИ общего назначения, или GPAI: техническая документация, информация для последующих интеграторов, политика соблюдения авторских прав и публичное достаточно подробное резюме обучающих данных.

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

Порог вычислений модели — например, ориентиры в 10²³ или 10²⁵ FLOP, которые фигурируют в европейских разъяснениях для GPAI, — не помогает выбрать чат-бота для отдела продаж. Это регуляторный ориентир, не показатель полезности, точности или удобства конкретного продукта.

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