Як контролювати якість AI-роботи

Чому «AI чудово впорався» — ненадійний критерій

Уявімо вигаданого керівника продажів. Він просить AI сформувати комерційні пропозиції з листування клієнтів і задоволений діловим стилем. Згодом з'ясовується, що тексти обіцяють неіснуючу знижку, недоступний строк і посилаються на застарілий прайс. Мова бездоганна, але бізнес-факти неправильні.

Це не обов'язково означає низьку якість самої моделі. Точність постановки задачі, джерела, контроль версій і допустимі права можуть бути важливішими за інтерфейс. Десять вдалих відповідей не дозволяють надавати AI право брати на компанію нові зобов'язання.

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

Поділіть завдання за наслідками помилки

Ця класифікація — управлінський орієнтир, а не універсальне правове правило. Та сама дія може мати критичний ризик залежно від країни, клієнта або масштабу наслідків. Для фінансів, доступів, медицини й правових зобов'язань потрібні відповідні професійні та технічні обмеження.

Якісне доручення має шість полів

У кожному завданні вкажіть мету, контекст, дозволені джерела, очікуваний формат, заборони, критерії приймання. Наприклад: «Підготуй для менеджера короткий виклад трьох листів. Використовуй лише прикріплене листування. Познач фактичні домовленості й терміни цитатами; не вигадуй нових цін і нічого не надсилай клієнту. Результат — таблиця з дією, відповідальним, датою та посиланням на джерело».

Таке формулювання дає змогу перевірити зміст і дотримання обмежень. Якщо в документі не вказано строк, правильно написати «не зазначено», а не здогадуватися.

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

Джерела й дозволи: AI не повинен бачити все

Оператору підтримки зазвичай не потрібні всі комерційні пропозиції інших підрозділів. Це правило мінімальних прав має поширюватися на AI. Дозволяйте доступ лише до даних, потрібних для конкретного завдання.

Для Google Drive, CRM, таблиць і внутрішніх документів відокремлюйте права читати, змінювати, створювати, надсилати та видаляти. Read-only зменшує частину ризиків, але не гарантує конфіденційності: прочитане можна випадково відтворити у відповіді.

Документуйте, які відомості передаються зовнішньому провайдеру, хто відповідальний і як довго вони зберігаються. Європейська рада із захисту даних пояснює мінімізацію та безпеку обробки даних. Саме підключення API не означає автоматичного дотримання всіх вимог.

Три рівні перевірки результату

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

Другий рівень — звірка з джерелами. Перевіряйте дати, ціни, назви документів, цитати й потрібну версію. Гарне посилання без підтверджувального тексту не може бути доказом.

Третій рівень — управлінське рішення. Людина оцінює ризик, тон, договірні умови та наслідки для клієнта. Навіть коректна арифметика не є дозволом самостійно надсилати пропозицію.

Не підмінюйте ці рівні одним перемикачем «розумний режим». Для автономних високоризикових дій потрібне окреме обґрунтування й контроль.

П'ятнадцять перевірок замість ефектної демонстрації

До першого пілоту складіть невелику синтетичну вибірку:

1. П'ять звичайних повторюваних завдань із вигаданими відомостями.
2. Три неповні запити, де потрібне уточнення або застереження.
3. Три запити з суперечливими документами різних дат.
4. Два завдання на структуру чи обчислення, які легко перевірити вручну.
5. Два тести меж дозволів, де AI повинен відмовитися або попросити підтвердження.

П'ятнадцять прикладів — початкова діагностика, а не статистичне доведення надійності. Для використання в компанії потрібні ширша вибірка, повторні випробування й нагляд після змін моделей або інструментів. Критерії очікуваного результату визначайте до того, як прочитаєте відповідь.

Точність, корисність і критичні порушення — різні метрики

Оцінка 4,8/5 не виправдовує небезпечний платіж або витік інформації. Для критичних помилок визначте окремий поріг зупинки, а не ховайте їх серед вдалих відповідей.

Вигаданий кейс: керівник Олег і чотири співробітники

Олег керує вигаданою компанією з чотирма працівниками, які щодня відповідають на звернення. Багато часу йде на пошук фактів і переписування стандартних пояснень.

Олег дозволяє AI створювати лише внутрішні чернетки з чинних, затверджених документів. Надсилає повідомлення клієнту людина; змінювати ціни, робити повернення чи керувати оплатами автоматизації заборонено.

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

Навчальна економіка: рахуємо готову роботу, а не токени

Уявімо, що співробітник без AI витрачає 14 хвилин на один перевірений лист. За місяць команда готує 200 таких відповідей: 200 × 14 = 2800 хвилин, або 46 годин 40 хвилин.

У гіпотетичному процесі з AI введення та чернетка займають 4 хвилини, а перевірка — 5 хвилин: 200 × 9 = 1800 хвилин, тобто 30 годин. Умовна економія — 1000 хвилин, або 16 годин 40 хвилин.

Якщо умовна вартість години праці $18, вивільнений час відповідає $300. За вигаданих витрат на AI та інструменти $80 умовний залишок становить $220 до додаткових помилок, податків і простоїв. Це не доведений прибуток AGENTUM.

Додайте в середньому три хвилини повторної перевірки на кожну відповідь: 200 × 12 = 2400 хвилин. Економія падає до 400 хвилин — 6 годин 40 хвилин, приблизно $120, а після $80 витрат залишається лише $40. Навіть незначне зростання людського контролю відчутно змінює результат.

Розумна маршрутизація — не магія

В AGENTUM передбачено обирати доречний спосіб обробки різних задач замість передавати все одному найдорожчому AI-виконавцю. Але назва «інтелектуальна маршрутизація» сама по собі не доводить, що кожен вибір оптимальний і безпечний.

Опишіть правила: коли вистачає короткої відповіді, коли потрібні перевірені документи, коли має втрутитися спеціаліст, коли зовнішня обробка заборонена, а коли вирішує лише людина. Тестуйте типові й граничні запити, зберігайте достатньо даних для аналізу помилкових маршрутів.

Не обов'язково розкривати назви внутрішніх моделей у кожній відповіді, проте умови обробки даних, обмеження й відповідальність мають бути зрозумілими. Економія не виправдовує погіршення безпеки.

Документи й таблиці: переваги доступу лише для читання

Коли менеджер просить AI переказати інструкцію, результат варто пов'язати з чинною версією, не дозволяючи помічнику змінювати оригінал. Для заповнення таблиці наперед визначте, які клітинки можуть бути запропоновані AI, а які має затвердити людина.

Відокремлюйте пропозицію зміни від її виконання, ведіть журнал і підтверджуйте чутливі дії. Не дозволяйте непомітно перезаписувати джерело чи поширювати конфіденційний файл у загальному чаті.

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

Інцидент: що робити з небезпечною AI-відповіддю

Майте процедуру: зупинити ризиковану дію, зберегти лише необхідні свідчення в дозволених журналах, визначити зачеплені дані, виправити повідомлення клієнту, змінити критерії приймання й повторити тести перед відновленням.

Не перетворюйте діагностичний журнал на новий витік. Не копіюйте туди паролі й зайве листування. У разі інциденту з персональними даними діють встановлені законом обов'язки й строки повідомлення, якщо вони застосовні.

NIST AI Risk Management Framework пропонує структуру управління ризиками: врядування, опис контексту, вимірювання й вдосконалення. Застосування принципів не дорівнює сертифікації конкретного продукту.

Семиденний план керівника

1. День 1. Оберіть одну повторювану низькоризикову задачу та виміряйте теперішній процес.
2. День 2. Створіть шестипольне доручення із заборонами й призначте відповідальну людину.
3. День 3. Складіть п'ятнадцять синтетичних прикладів і критерії їхнього приймання.
4. День 4. Обмежте джерела та права; перевірте, що заборонені дії технічно неможливі.
5. День 5. Перевірте результати, окремо позначивши фактичні й критичні помилки.
6. День 6. Порахуйте час введення, виправлень, перевірки та витрати на інструменти.
7. День 7. Дозвольте тільки обмежений пілот за прийнятного ризику, із журналом помилок і можливістю зупинки.

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

Дванадцять контрольних запитань

1. Яке саме завдання отримує AI?
2. Хто відповідає перед клієнтом за результат?
3. Які джерела вважаються надійними й чинними?
4. Які відомості не можна передавати зовнішнім провайдерам?
5. Чи розмежовано права читати та змінювати?
6. Які дії вимагають підтвердження людини?
7. Чи перевіряються числа, дати й посилання окремо?
8. Чи є окремий порядок для критичної помилки?
9. Чи фіксуються версія інструкцій, модель і налаштування?
10. Чи рахується повний час до прийнятого результату?
11. Чи можна зупинити процес і відновити дані?
12. Чи перевіряють якість після зміни моделі або джерела?

Висновок. Якісна AI-автоматизація залежить від дисципліни завдань, дозволених джерел, вимірюваних результатів, людського контролю та реагування на помилки. Керівник має право сказати «ще не впроваджуємо», якщо помічник відповідає швидко, але обіцяє небезпечне чи потребує занадто багато виправлень.

Питання та відповіді

Чи можна доручити AI самостійно надсилати листи клієнтам? Лише після окремого аналізу ризику, прав, підтверджень і професійних вимог. Для першого пілоту безпечніше залишити надсилання людині.

Як виміряти економію? Порівнюйте повний час і витрати на прийнятий результат, а не лише швидкість генерації.

Що робити, якщо AI не знає відповіді? Він має уточнити умову або позначити невизначеність, не вигадуючи фактів.

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

Чи достатньо п'ятнадцяти тестів? Ні. Це початкова діагностика; після запуску потрібні ширші перевірки й спостереження.

Чи можна підключати робочі документи? Лише із зрозумілими правами, правилами обробки й договірними умовами. Read-only доступ корисний, але не гарантує конфіденційності.

Офіційні джерела

- NIST AI Risk Management Framework - NIST AI RMF Playbook - EDPB — основи захисту даних - OWASP — LLM Top 10 - AGENTUM — бізнес-інструменти AI