Хто відповідає за помилки штучного інтелекту? Про що змовчала фантастика

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

Вісімдесят років фантастика описувала машини, які будують, рахують і розмовляють. Більшість із цього з’явилася: комп’ютер, що відповідає на запитання, асистент, що пише код, агент, що за ніч виконує робочий процес. Щодо можливостей жанр мав рацію, а про відповідальність переважно мовчав. У 2026 році можливості коштують дешево, тож відповідальність — саме та частина, яку власник бізнесу мусить спроєктувати.

Закони Азімова (1942)

У 1942 році, в оповіданні «Runaround», Айзек Азімов написав три закони для роботів. Класичні історії, що з’явилися потім, будуються на тому, як закон стикається із ситуацією, якої не передбачав. Робот виконує букву, пропускає мету, і ніхто не визначив, хто відповідає за те, що станеться далі. Закони були. Відповідального власника не було.

HAL (1968)

HAL, комп’ютер із фільму «2001: Космічна одіссея» (1968), розмовляє, планує і керує космічним кораблем. У нього немає власника, який би за нього розписався. Коли його судження розходяться з інтересами екіпажу, немає аудиторського сліду, який хтось читає, немає погодженої умови зупинки й немає маршруту ескалації. Єдиний людський нагляд, що лишається, — член екіпажу, який відключає його вручну. Можливості з’явилися першими; відповідальність так і не з’явилася.

Люди, які створюють, впроваджують і ведуть систему, — кожен за те, що контролював. Розробник відповідає за те, як створено модель і програмне забезпечення. Організація, що впроваджує AI, відповідає перед своїми клієнтами за те, що вбудувала AI у свій продукт. Оператор відповідає за те, як систему ведуть. Кінцевий користувач відповідає за дії на основі результату, який міг перевірити.

Це не юридична консультація. Відповідальність за AI залежить від юрисдикції, договору й обставин, а претензія може ґрунтуватися на договорі, недбалості чи відповідальності за продукцію; перш ніж на це покладатися, зверніться до юриста. Публічні рамки вказують у той самий бік: Принципи OECD щодо AI вимагають відповідальності від учасників AI відповідно до їхньої ролі, NIST AI Risk Management Framework просить організації покласти відповідальність за ризики AI на конкретні команди й людей, а EU AI Act розподіляє обов’язки між постачальниками (providers) і тими, хто розгортає системи (deployers).

Прогалини з’являються там, де ролі перетинаються. Компанія, яка створює власний AI-інструмент і використовує його з клієнтами, одночасно є розробником, організацією, що впроваджує, і оператором, і кожна команда вважає, що ризик несе інша. Тож хто відповідає, коли AI помиляється в такому випадку? Той, кого назвали заздалегідь, — або ніхто.

Дешева частина

AI-платформа може видати робочий прототип за вечір. Ми самі користуємося цими інструментами — в нашій інженерії та всередині Vendo AI, нашого власного продукту для продажів. Результат однаково треба перевіряти: звіт Veracode 2026 GenAI Code Security Report зафіксував 56% проходження перевірок безпеки на понад 100 моделях, а в опитуванні Stack Overflow Developer Survey довіра розробників до точності результатів AI впала з 40% до 29%. Це не робить інструменти поганими. Це робить їх інструментами.

Дорога частина

Після прототипу бізнесу потрібна система, яка працює далі: архітектура, що витримує зростання, правильно оброблені дані, безпека, яку перевіряють, а не припускають, і названа людина, яка відповідає, коли щось ламається о другій ночі. Для власника продукту управління AI (AI governance) зводиться до чотирьох рішень, записаних до запуску:

• →Названий власник: одна людина, а не комітет, яка може зупинити систему і відповідає за результат.
• →Аудиторський слід: що система отримала, що видала і хто це схвалив — для простежуваності та пояснюваності.
• →Умови зупинки: де AI не має діяти самостійно — платежі, автоматизовані рішення щодо людей або все, що виходить за межі задокументованого призначення.
• →Шлях ескалації: кого викликають, як швидко і що бачить користувач, поки справу перебирає людина.

Жодне з них не є пунктом, який юрист додає наприкінці. Кожне змінює архітектуру, інтерфейс, документацію й поточні витрати, тож кожне належить до продуктової логіки від самого початку. «Людина в контурі» (human in the loop) має сенс лише тоді, коли ця людина має повноваження, інформацію і час, щоб скасувати рішення машини.

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

Leadership Gate — це місце, де відповідальність стає рішенням. У нього один власник, CEO, і завершується він обґрунтуванням: продовжити, переформатувати чи відмовити. Ми відмовляємо, коли продуктова логіка не витримує перевірки, коли комерційна модель не здатна втримати ведення продукту або коли ми не могли б узяти на себе відповідальність за результат. Уся послідовність описана в розділі як працює наш процес.

До власного AI ми застосовуємо ті самі правила. Кейс Vendo AI показує підзвітний AI-продукт у продакшені: кожне джерело сигналів — окремий модуль, що вмикається за згодою і має власну аналітику, а розмову можна в реальному часі передати людині. На цьому сайті Vendo AI збирає контекст і допомагає організувати дзвінок; він не ухвалює комерційних рішень і не видає комерційних пропозицій.

Поставте їх своїй команді, будь-якому постачальнику та будь-якому AI-конструктору, які ви порівнюєте. Відповіді мають бути письмовими.

• →Хто названий власник цієї системи в продакшені?
• →Які рішення AI може ухвалювати сам, а які потребують схвалення людини?
• →Що логується, як довго зберігається і хто це читає, коли щось іде не так?
• →Які умови зупиняють систему і кого викликають, коли це стається?
• →Якщо ви обираєте між AI-конструктором і командою: хто відповідає за систему після запуску?

Якщо на перше запитання ніхто не може відповісти, прототип — це місце, де проєкт закінчується, хай як швидко його зробили. Якщо продукт, створений за допомогою AI, уже працює, має користувачів, але його зростання зупинилося, Existing Product Review — маршрут, у якому ми переглядаємо код, бізнес-логіку й ринок і вирішуємо, чи інвестувати.

Фантастика передбачила машини. Правила для людей навколо них завжди були найважчою частиною.