Доверие к ИИ: почему пользователи не верят ответам и что делать

Уверенный тон ответа ещё не делает его убедительным. Пользователь сравнивает обещание с личным опытом: распознал ли помощник вопрос, откуда взял факт, что произойдёт после нажатия и кто исправит ошибку. Отдельно настройте чат-бот поддержки, а качество до релиза проверьте через тестирование AI-чат-бота.

Контекст отношения аудитории даёт обзор ВЦИОМ «Доверие к ИИ». Характеристики надёжного ИИ перечислены в официальном FAQ NIST AI RMF.

Назовите систему своим именем

Пользователь оценивает систему по ситуации «первое знакомство с AI-консультантом», поэтому начните с наблюдаемого поведения.

• Опишите первое знакомство с AI-консультантом одним предложением без названия продукта.
• Зафиксируйте риск: бот выдаёт себя за сотрудника и раскрывается после ошибки.
• Сохраните подтверждение: текст представления и запись пользовательских реакций.
• Назначьте роль «редактор продукта» и дату повторной проверки.

Сбой выглядит так: бот выдаёт себя за сотрудника и раскрывается после ошибки.

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

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

Собирайте его по одинаковому правилу, чтобы сравнивать версии и не выбирать только удобные примеры.

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

Итог этапа — понятная роль без ложного человеческого образа.

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

Для ситуации «первое знакомство с AI-консультантом» проверьте два объяснения и запишите, где человек остановился, запросил помощь или отказался продолжать.

Такой эпизод полезнее общей оценки.

После правки повторите сценарий без подсказки модератора.

Участник должен сам прийти к результату «понятная роль без ложного человеческого образа» и назвать способ исправления ошибки.

Покажите границу компетенции

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

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

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

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

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

Итог этапа — предсказуемое поведение на пограничном вопросе.

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

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

Такой эпизод полезнее общей оценки.

После правки повторите сценарий без подсказки модератора.

Участник должен сам прийти к результату «предсказуемое поведение на пограничном вопросе» и назвать способ исправления ошибки.

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

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

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

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

Подтверждением служит адрес конкретной страницы и дата материала. Собирайте его по одинаковому правилу, чтобы сравнивать версии и не выбирать только удобные примеры.

Владелец решения — контент-редактор. Он меняет текст, интерфейс или маршрут обращения и проверяет, исчезла ли причина недоверия.

Итог этапа — проверяемая опора для ключевого ответа.

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

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

Такой эпизод полезнее общей оценки.

После правки повторите сценарий без подсказки модератора.

Участник должен сам прийти к результату «проверяемая опора для ключевого ответа» и назвать способ исправления ошибки.

Разделяйте факт и предположение

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

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

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

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

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

Итог этапа — явное различие между найденным и предположенным.

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

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

Такой эпизод полезнее общей оценки.

После правки повторите сценарий без подсказки модератора.

Участник должен сам прийти к результату «явное различие между найденным и предположенным» и назвать способ исправления ошибки.

Запрашивайте подтверждение действия

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

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

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

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

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

Итог этапа — осознанное подтверждение перед необратимым шагом.

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

Для ситуации «отправка, изменение записи, заказ или платёж» проверьте два объяснения и запишите, где человек остановился, запросил помощь или отказался продолжать.

Такой эпизод полезнее общей оценки.

После правки повторите сценарий без подсказки модератора.

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

Передавайте оператору весь контекст

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

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

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

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

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

Итог этапа — оператор видит вопрос и уже выполненные проверки.

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

Для ситуации «момент эскалации сложного обращения» проверьте два объяснения и запишите, где человек остановился, запросил помощь или отказался продолжать.

Такой эпизод полезнее общей оценки.

После правки повторите сценарий без подсказки модератора.

Участник должен сам прийти к результату «оператор видит вопрос и уже выполненные проверки» и назвать способ исправления ошибки.

Исправляйте ошибку видимо

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

• Опишите случай неверного или устаревшего ответа одним предложением без названия продукта.
• Зафиксируйте риск: неверная подсказка остаётся без отметки.
• Сохраните подтверждение: карточка исправления и связь с источником.
• Назначьте роль «владелец контента» и дату повторной проверки.

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

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

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

Итог этапа — пользователь получает корректировку по тому же каналу.

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

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

Такой эпизод полезнее общей оценки.

После правки повторите сценарий без подсказки модератора.

Участник должен сам прийти к результату «пользователь получает корректировку по тому же каналу» и назвать способ исправления ошибки.

Не просите лишних данных

Пользователь оценивает систему по ситуации «уточнение личности и обстоятельств», поэтому начните с наблюдаемого поведения.

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

• Опишите уточнение личности и обстоятельств одним предложением без названия продукта.
• Зафиксируйте риск: бот собирает сведения до объяснения цели.
• Сохраните подтверждение: минимальный сценарий формы и текст причины.
• Назначьте роль «специалист по приватности» и дату повторной проверки.

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

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

Итог этапа — каждый вопрос понятен и необходим.

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

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

Такой эпизод полезнее общей оценки.

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

Измеряйте поведение после ответа

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

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

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

Подтверждением служит повторный вопрос, переход к источнику и эскалация.

Собирайте его по одинаковому правилу, чтобы сравнивать версии и не выбирать только удобные примеры.

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

Итог этапа — набор метрик без подмены доверия кликом.

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

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

Такой эпизод полезнее общей оценки.

После правки повторите сценарий без подсказки модератора.

Участник должен сам прийти к результату «набор метрик без подмены доверия кликом» и назвать способ исправления ошибки.

Проводите тест с незнакомыми людьми

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

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

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

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

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

Итог этапа — человек объясняет роль и ограничение своими словами.

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

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

Такой эпизод полезнее общей оценки.

После правки повторите сценарий без подсказки модератора.

Участник должен сам прийти к результату «человек объясняет роль и ограничение своими словами» и назвать способ исправления ошибки.

Карта ответственности

Что изучить дальше

• тестирование AI-чат-бота
• чат-бот поддержки
• галлюцинации нейросетей
• база знаний компании
• prompt injection
• политика использования ИИ
• фактчекинг текстов

Чек-лист