AUT-0422· Знання та ШІ
Перевірка відповіді ШІ перед відправленням клієнту
Відповідальний перевіряє чернетку відповіді ШІ та її джерела до того, як повідомлення піде клієнту.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Працівник може надіслати чернетку ШІ з помилковою обіцянкою або твердженням без перевіреного джерела.
02 / Результат
Кожна зовнішня відповідь має зафіксовані джерела, перевіряльника та рішення щодо конкретної редакції: погоджено, виправити або відхилити.
03 / Процес
ТригерПрацівник створив чернетку відповіді клієнту за допомогою ШІ, а внутрішня політика вимагає перевірки перед відправленням.
Зберегти посилання на звернення, чернетку, використаний контекст і доступні джерела; не копіювати зайві персональні дані.
Перевірити, що джерела відкриваються й стосуються звернення; відсутні або суперечливі підтвердження показати рецензенту.
Призначити перевіряльника за темою й позначити ризикові твердження, обіцянки, ціни або дії, що потребують окремого погодження.
Перевіряльник звіряє факти й політику, а потім погоджує точну редакцію, вносить виправлення або відхиляє чернетку з причиною.
Надіслати клієнту лише погоджену редакцію через чинний канал; після редагування вимагати нового рішення для зміненого тексту.
Зафіксувати рішення, тип виправлення, скаргу чи ескалацію для подальшого контролю якості; окремо погоджувати використання цих даних для оцінювання моделі.
04 / Реалізація1 варіант
Приклад · Погодження редакції відповіді перед відправленням
Чернетка ШІ відповіла на питання про повернення замовлення. Оператор звірив її з чинними умовами й конкретним замовленням, виправив один строк і погодив збережену редакцію; повідомлення пішло тільки після цього рішення.
Спосіб реалізації
- Гіпотеза PlanFix: окрема задача з посиланням на звернення, текстом-версією, джерелами, автором чернетки, перевіряльником і переходами «на перевірці / виправити / погоджено / відхилено».
- Канал CRM або helpdesk має надсилати лише погоджену редакцію і повертати ідентифікатор зовнішнього повідомлення; якщо цього немає, передбачити ручну відправку після погодження.
Що потрібно для реалізації
- Чинний канал підтримки дозволяє втримати повідомлення до погодження та надіслати саме погоджену редакцію.
- Затверджено категорії ризику, джерела істини, повноваження перевіряльників і порядок ескалації.
- У записі можна пов’язати рішення з редакцією відповіді та джерелами, не відкриваючи їх зайвим учасникам.
- Визначено джерела істини, категорії ризику та відповідального за перевірку.
- Надсилання не відбувається автоматично до підтвердження потрібної редакції людиною.
Обмеження
- Позначка погодження не доводить, що всі твердження правильні; перевіряльник має звірити джерела й контекст.
- Самооцінка впевненості моделі не є достатньою підставою для пропуску людської перевірки.
- Якщо канал не підтримує блокування або збереження погодженої редакції, контроль може бути лише організаційним.
- Журнал виправлень і помилок потребує обмеженого доступу та визначеного строку зберігання; не використовувати його автоматично для навчання моделі.
- Схвалення не є гарантією точності; рішення спирається на перевірені джерела й людський контекст.
- Лог виправлень не передається в навчальний набір без окремого процесу згоди, очищення й оцінки.
Що потрібно уточнити (2)
- Чи потрібно блокувати й передавати погоджену відповідь через окремий канал підтримки?
Укажіть CRM або helpdesk, ідентифікатор звернення, канал надсилання, межі редакції та спосіб перевірити доставку.
- Чи потрібне погодження кількох фахівців для окремих категорій відповідей?
Визначте теми, послідовність перевірки, резервних погоджувачів і правила для прострочених запитів.