Людина в контурі керування: коли і як оператор має зберігати контроль над автоматизованою системою
Автор: Український психологічний ХАБ · Опубліковано: 7 жовтня 2026 року · Редакційна політика
Людина в контурі керування (Human-in-the-Loop, HITL) — це архітектура взаємодії з автоматизованою системою, у якій людина має визначену операційну роль у спостереженні, інтерпретації, ухваленні рішення, санкціонуванні дії або втручанні в керування. Ключове слово тут — «керування». Сам факт присутності оператора біля екрана ще не означає, що він реально контролює систему.
Ефективний людський контроль виникає тоді, коли оператор бачить релевантний стан системи, розуміє режим і межі автоматизації, має достатньо часу для оцінки ситуації, володіє потрібними навичками, має реальні повноваження змінити перебіг подій і отримує інтерфейс та процедури, які дозволяють це зробити. Якщо хоча б одна з цих умов провалюється, формальна вимога «залишити людину в контурі» може перетворитися на символічне погодження без реальної спроможності запобігти помилці.
У дисципліні людських факторів та ергономіки людина розглядається як частина цілісної системи «людина — завдання — інтерфейс — технологія — організація — середовище». Саме такий системний підхід закріплений у визначенні International Ergonomics Association і в міжнародних ергономічних стандартах. Тому питання «хто помилився?» для безпечної автоматизації слабше за питання «як було спроєктовано розподіл функцій, інформації, повноважень, часу й відповідальності?».
Що означає «людина в контурі керування»
У human factors вислів «людина в контурі керування» працює як парасолькове позначення способу організації взаємодії людини з автоматизацією. Конкретний зміст задає домен: у промисловому керуванні оператор може стежити за процесом і втручатися у відхилення; в авіації екіпаж керує траєкторією через поєднання ручного і автоматизованого керування; в умовно автоматизованому транспорті водій має відновити ситуаційну обізнаність і прийняти керування; у цифровій системі людина може санкціонувати критичну дію, відхилити рекомендацію або зупинити автоматичний процес.
В українських текстах трапляються форми «людина в контурі», «людина в контурі керування» та «людина в циклі керування». Англійський термін Human-in-the-Loop і скорочення HITL особливо поширені у технічній літературі та матеріалах про штучний інтелект. Для цієї статті канонічним є формулювання «людина в контурі керування», оскільки воно точно передає операційний зміст: людина включена до ланцюга спостереження, рішення та впливу на систему.
Цей термін описує архітектуру взаємодії, а не одну універсальну психологічну змінну. Емпірична база формується з досліджень автоматизації, ситуаційної обізнаності, розподілу функцій, надійності людини, довіри до автоматизації, навантаження, передачі керування та дизайну людино-машинного інтерфейсу. У класичній моделі Parasuraman, Sheridan і Wickens автоматизація розглядається не як єдиний перемикач «увімкнено/вимкнено», а як різні рівні підтримки для різних функцій системи.
Контур керування — це розподіл функцій, а не проста межа між людиною і машиною
Найкорисніше питання для проєктування звучить так: яка функція зараз виконується людиною, яка — автоматизацією, які дані переходять між ними і хто має право змінити рішення. Модель Parasuraman, Sheridan і Wickens поділяє автоматизовану діяльність щонайменше на чотири великі класи: отримання інформації, аналіз інформації, вибір рішення або дії та реалізацію дії. Кожен клас може мати власний рівень автоматизації.
1. Отримання інформації
Система може збирати дані з сенсорів, фільтрувати потоки, виділяти події та формувати сигнали. Роль людини полягає не в дублюванні кожного сенсора, а в доступі до інформації, достатньої для оцінки того, що відбувається, включно з якістю даних, станом каналів і важливими винятками. Автоматизація, яка приховує невизначеність або відмову сенсора, позбавляє оператора матеріалу для контролю.
2. Аналіз і формування картини ситуації
Автоматизація може об’єднувати дані, оцінювати стан, прогнозувати розвиток подій і виявляти аномалії. Людина потребує представлення, яке дозволяє перевірити висновок у потрібному для завдання обсязі. Для безпеки важлива не максимальна кількість даних, а можливість швидко відновити причинно-наслідкову картину: що сталося, який режим активний, які припущення використовує система і що зміниться далі.
3. Вибір рішення або дії
Система може рекомендувати один варіант, ранжувати альтернативи або самостійно обирати дію за заданими правилами. Людський контроль на цьому рівні може набувати форми вибору, підтвердження, відхилення, вето або ескалації. Якість такого контролю залежить від того, чи має людина підстави оцінити рекомендацію. Механічне натискання «підтвердити» після сотень правильних автоматичних рішень створює видимість нагляду, але слабку здатність виявити рідкісну небезпечну помилку.
4. Реалізація дії
Автоматизація може виконувати команду, регулювати процес або керувати фізичною системою. Людина може запускати дію, задавати межі, змінювати параметри, переривати виконання або переводити систему в інший режим. Тут критичні властивості інтерфейсу: зрозуміла індикація активного режиму, передбачувана реакція на команду, підтвердження фактичного стану після дії та безпечна поведінка в разі відмови.
Рівень автоматизації сам по собі не визначає безпеку
Ідея єдиної шкали від ручного керування до повної автоматизації зручна для опису, але проєктне рішення потребує більшої деталізації. Одна й та сама система може автоматично збирати інформацію, частково підтримувати аналіз, залишати остаточне рішення людині й автоматично виконувати затверджену команду. Інша система може діяти автономно в штатному режимі, але передавати людині виняткові ситуації. Тому «рівень автоматизації» слід розкладати на функції та сценарії.
Дослідження Raja Parasuraman про проєктування автоматизації для людини прямо пов’язує вибір типу й рівня автоматизації з наслідками для розумового навантаження, ситуаційної обізнаності, самозаспокоєності та деградації навичок. Додатково враховуються надійність автоматизації, тяжкість наслідків помилкового рішення та інтеграція системи. Отже, універсального правила «чим більше автоматизації, тим краще» немає: оптимальний розподіл функцій залежить від задачі, ризику й того, як змінюється спроможність людини діяти.
Це узгоджується із системною логікою ISO 6385:2016: проєктування робочих систем має збалансовано враховувати людські, соціальні та технічні вимоги впродовж життєвого циклу системи. Для інтерактивних систем ISO 9241-210:2019 вимагає людиноцентричного процесу проєктування протягом життєвого циклу. У контексті контуру керування це означає, що роль оператора визначають на етапі архітектури системи, перевіряють у реальних сценаріях і переглядають після змін автоматизації.
Які ролі може мати людина в автоматизованій системі
Безпосереднє керування
Людина безпосередньо формує керувальні дії, а автоматизація підтримує виконання: стабілізує, фільтрує, попереджає або обмежує небезпечні команди. Такий режим зберігає постійний потік зворотного зв’язку між дією людини й поведінкою системи, але може створювати високе навантаження там, де машина краще виконує швидкі повторювані операції.
Супервізорне керування
Класичне поняття supervisory control описане Thomas Sheridan: людина періодично задає цілі, обмеження та процедури, стежить за станом системи, а комп’ютер автоматично виконує інструкції. Це один із центральних режимів сучасної автоматизації. Людина керує не кожним рухом системи, а структурою завдання, межами автономності та винятками.
Підтвердження, вето та ескалація
У деяких системах автоматизація готує рішення, але виконання потребує людського підтвердження. В інших випадках система починає дію автоматично, а людина має коротке вікно для вето. Ще один варіант — автоматичне виконання штатних випадків із передачею невизначених або небезпечних випадків операторові. Ці механізми мають різний психологічний профіль: підтвердження вимагає уважної перевірки, вето — швидкого виявлення проблеми, ескалація — правильної класифікації винятку.
Моніторинг із готовністю втрутитися
Найскладніший режим виникає тоді, коли автоматизація працює довго й надійно, а людина повинна залишатися готовою до рідкісного втручання. Саме тут формується центральний парадокс автоматизації: чим менше людина практично керує системою в нормальних умовах, тим складніше їй може бути повернутися до активного керування в момент відмови або незвичної ситуації.
Коли людський контроль є реальним
Реальний контроль можна описати як поєднання семи спроможностей. Вони взаємозалежні: право на втручання без інформації мало корисне; інформація без часу не дає можливості діяти; час і інформація без навичок не гарантують правильного рішення.
Спостережуваність
Оператор бачить стан системи, активний режим, важливі зміни, межі робочої області, а також сигнали про деградацію або невизначеність. Інтерфейс відповідає на практичні запитання: що система робить зараз, чому вона це робить, що вона робитиме далі і які умови можуть змінити її поведінку.
Зрозумілість
Представлення інформації відповідає завданню оператора і його робочій моделі системи. Зрозумілість не означає показувати всі внутрішні деталі алгоритму. Вона означає дати саме ту інформацію, яка потрібна для прогнозу, перевірки, вибору дії й відновлення контролю.
Час на виявлення, діагностику й дію
Контур має фізичний і когнітивний часовий бюджет. Людині потрібно помітити проблему, зрозуміти її, обрати дію, виконати її й перевірити результат. Якщо система передає керування за секунду до незворотної події, формальна можливість «втрутитися» може не мати операційного змісту.
Повноваження
Оператор має технічне і процедурне право змінити режим, скасувати, відхилити, уповільнити, зупинити або перевести систему у безпечніший стан. Відповідальність без відповідного обсягу повноважень створює системну суперечність: від людини очікують результату, але архітектура позбавляє її дієвих засобів.
Компетентність і збереження навичок
Людина має знати нормальну та деградовану поведінку системи, межі автоматизації, процедури втручання і ручні або резервні режими. Навичка, яка потрібна лише під час рідкісної аварійної ситуації, потребує окремого тренування, тому що повсякденна автоматизація сама по собі не підтримує її.
Зворотний зв’язок після втручання
Після команди оператор має бачити, що система її прийняла, який стан фактично змінився і чи досягнуто потрібного ефекту. Це принцип замкненого контуру: дія без підтвердження результату залишає людину з припущенням замість знання.
Безпечний резерв
Система має визначену поведінку на випадок, коли оператор не відповів, відповів запізно або не може відновити керування. У деяких системах це автоматичний перехід до безпечного стану; в інших — утримання параметрів, зниження швидкості, обмеження функцій або ескалація іншому рівню контролю. Конкретний механізм задається доменом і аналізом небезпек.
Коли оператор має зберігати контроль
Рішення про участь людини має бути ризик-орієнтованим і функціональним. Людина особливо цінна там, де система стикається з неоднозначною ситуацією, неповними даними, конфліктом цілей, нетиповим контекстом або наслідками, які потребують відповідального судження. Чим вища ціна незворотної помилки, тим сильнішим має бути обґрунтування того, хто санкціонує дію, хто може її зупинити і як контролюється стан.
Водночас вимога людського погодження кожної операції може погіршити систему, якщо події розгортаються швидше за людську реакцію, якщо потік рішень перевищує можливості уваги або якщо оператор отримує лише формальну кнопку «підтвердити» без інформації для перевірки. У швидких захисних функціях автоматизація може реагувати краще за людину на рівні окремої події, тоді як людський контроль переноситься на встановлення меж, моніторинг стану, перевірку конфігурації, зміну режимів і аналіз винятків.
Практичний критерій простий: людину варто ставити в точку рішення тоді, коли вона має достатню інформацію, компетентність і час, щоб підвищити якість або безпеку системи. Якщо цих умов немає, потрібно перепроєктувати контур — змінити момент ескалації, додати прогноз, збільшити часовий запас, зменшити потік сигналів, підтримати діагностику або перенести людський вплив на інший рівень.
Парадокс автоматизації: чому рідкісне втручання стає найважчим
Класична праця Lisanne Bainbridge «Ironies of Automation» сформулювала проблему, яка залишається актуальною: автоматизація часто забирає в людини рутинні операції, але залишає їй саме складні винятки та аварійні ситуації. У результаті оператор повинен виконати найважчу частину роботи в момент, коли він найменше практикував ручне керування і може мати неповну картину того, як система прийшла до поточного стану.
Експериментальна робота Endsley і Kiris про out-of-the-loop performance problem показала зв’язок автоматизованого режиму зі зниженням ситуаційної обізнаності та погіршенням виконання після відмови автоматизації. Автори пов’язували це, зокрема, з переходом від активної до пасивної обробки інформації, зміною зворотного зв’язку, проблемами пильності та втратою навичок. Рівень фактичного контролю оператора модерує цей ефект.
Це не означає, що автоматизація за своєю природою робить людину слабшою. Наслідок залежить від дизайну: які задачі залишаються людині, чи отримує вона змістовний зворотний зв’язок, чи тренується ручне втручання, чи система підтримує ситуаційну обізнаність і чи передача керування відбувається завчасно. Саме тому вихід людини з активного контуру — окрема системна проблема, а не синонім високого рівня автоматизації.
Передача керування: найкритичніший момент контуру
Передача керування — це перехід, у якому змінюється не лише той, хто фізично впливає на систему. Змінюються джерела інформації, модель ситуації, відповідальність за вибір дії та темп обробки подій. Успішне повернення людини в активний контур потребує часу на орієнтацію.
Систематичний огляд Tan і Zhang охопив 34 емпіричні дослідження ситуаційної обізнаності під час повернення керування в умовно автоматизованих автомобілях. Автори виділили 23 чинники, пов’язані із системою і задачею, ситуацією, індивідуальними особливостями та неводійською діяльністю. Висновок важливий для ширшого human factors: якість takeover не зводиться до однієї цифри часу реакції; вона залежить від того, яку картину ситуації людина встигла відновити і яку інформацію отримала від інтерфейсу.
Тому універсального «безпечного часу на перехоплення» не існує. Потрібний запас визначають динаміка конкретної системи, тяжкість сценарію, складність діагностики, стан оператора, характер паралельних завдань, якість попередження та інтерфейсу. Час слід випробовувати в реалістичних сценаріях, включно з несподіваними відмовами, комбінованими подіями та неправильними очікуваннями оператора.
Що має повідомляти інтерфейс автоматизованої системи
Інтерфейс є частиною контуру керування, а не декоративним шаром між людиною і автоматизацією. Через нього оператор будує модель поточного стану й вирішує, чи потрібне втручання. Саме тому взаємодія людини з комп’ютером і human factors сходяться в одній точці: інформація має бути організована відповідно до завдання, а не відповідно до внутрішньої структури програмного забезпечення.
Для супервізорного контролю операторові потрібні щонайменше: активний режим; фактичний стан системи; задана ціль; розбіжність між заданим і фактичним; важливі обмеження; ознаки деградації; запланований наступний крок; повідомлення про автоматичний перехід режиму; доступні дії людини; підтвердження того, що команда виконана. У safety-critical системах до цього додаються пріоритети сигналів, часові межі й наслідки бездіяльності.
Авіаційна практика дає особливо зрілий приклад. FAA у матеріалах з human factors розглядає дизайн і оцінку систем, процедур, операцій та роботи пілота як одну систему. У рекомендаціях для автоматизованих польотних систем підкреслюються складність, деградація навичок, взаємозалежність компонентів і потреба готувати екіпаж до неочікуваного; це узагальнено у звіті Flight Deck Automation Working Group.
Актуальні правила й настанови EASA вимагають навчати екіпажі розпізнавати системні й людські обмеження автоматизації, підтримувати усвідомлення режиму, справлятися з automation surprise та надмірною залежністю від автоматизації, а також своєчасно втручатися. Це професійна регуляторна практика конкретного домену, але її системна логіка переносима: автоматизація має бути спроєктована так, щоб людина могла зрозуміти стан, передбачити поведінку й повернути керування.
Як проєктувати контур людського контролю
Починати із задачі та небезпек
Спочатку описують, що система повинна досягати, які стани є небажаними, які події можуть привести до шкоди і які функції потрібні для контролю ризику. Лише після цього визначають, що виконує автоматизація, що виконує людина і які переходи між ними можливі. Автоматизація, створена навколо технічної можливості, а потім доповнена «людським контролером», часто отримує слабкий контур саме тому, що роль людини визначено запізно.
Розподіляти функції разом із інформацією та повноваженнями
Функцію неможливо передати операторові окремо від даних, інтерфейсу, часу і права на дію. Якщо людина має схвалити рішення, їй потрібні критерії для перевірки. Якщо має перехопити керування, їй потрібен стан системи до передачі. Якщо має скасувати дію, система повинна технічно приймати скасування в межах потрібного часового вікна.
Проєктувати штатні й деградовані режими разом
Випробування лише нормальної роботи створює хибну картину. Контур керування перевіряють у сценаріях втрати сенсора, конфліктних даних, затримки, часткової відмови, неочікуваного переходу режиму, хибного сигналу, перевантаження повідомленнями та помилкової дії оператора. Безпечна система має передбачувано поводитися не тільки тоді, коли все працює.
Зменшувати ціну перемикання
Повернення людини в активний контур має бути підтримане інтерфейсом. Коротке повідомлення «візьміть керування» недостатнє, якщо оператор не знає причини, стану, траєкторії розвитку подій і доступних варіантів. Корисна передача включає орієнтувальну інформацію, пріоритет, часовий горизонт і явне підтвердження моменту, коли влада над системою фактично перейшла.
Підтримувати практику і компетентність
Якщо ручне або резервне керування потрібне лише зрідка, його треба підтримувати тренуванням. Авіаційні регулятори саме тому включають керування автоматизацією, monitoring and intervention, mode awareness, surprise і відновлення контролю до навчальних програм. У кожному домені тренування має відповідати реальним відмовам і часовим обмеженням системи, а не зводитися до знання інструкції.
Зберігати трасованість
Після події має бути можливо відновити, які дані бачила людина, який режим був активний, що рекомендувала або робила автоматизація, які команди подав оператор і як система на них відповіла. Логи потрібні не для автоматичного пошуку винного, а для аналізу системи, перевірки припущень, навчання й удосконалення дизайну.
«Кнопка зупинки» ще не створює людський контроль
Аварійна зупинка може бути критично важливим захисним механізмом, але вона покриває лише одну частину контуру — можливість перервати дію. Щоб скористатися нею вчасно, людина повинна виявити проблему, зрозуміти її значення, знати наслідки зупинки і мати фізично доступний канал впливу. Якщо оператор дізнається про небезпеку надто пізно, кнопка не компенсує слабку спостережуваність.
Так само формальне підтвердження кожного рішення не гарантує контролю. При високій частоті правильних рекомендацій люди схильні скорочувати глибину перевірки, а характерна системна помилка може пройти через рутинне погодження. Окремий механізм цієї проблеми — автоматизаційне упередження — має власний психологічний зміст і не замінює ширшу тему архітектури контуру керування.
Довіра до автоматизації і контроль
Людський контроль залежить від того, як оператор оцінює надійність автоматизації. Надмірна довіра сприяє пропуску помилок і несвоєчасному втручанню; недостатня довіра веде до зайвого ручного втручання, відмови від корисної автоматизації та додаткового навантаження. Систематичний огляд Papadimitriou та співавторів у транспортній автоматизації пов’язує узгодженість довіри, ситуаційну обізнаність, передачу керування, досвід і навчання з безпекою в автомобільному, авіаційному, морському та залізничному транспорті.
Для загальної автоматизації мета полягає в тому, щоб поведінка оператора відповідала реальним можливостям і межам системи. Для штучного інтелекту Український психологічний ХАБ окремо розглядає довіру до ШІ, калібрування довіри до ШІ та пояснюваність ШІ і довіру. Ці сторінки належать до AI-specific контексту; тут довіра розглядається лише як один із механізмів ефективного людського контролю автоматизації.
Як перевірити, чи людина справді залишається в контурі
Аудит людського контролю варто будувати як перевірку реальної спроможності, а не наявності посади оператора. Для кожного критичного сценарію команда повинна отримати конкретні відповіді на такі запитання.
Чи може оператор своєчасно виявити, що автоматизація помиляється, вийшла за межі робочої області або працює в деградованому режимі? Які саме сигнали це показують і чи перевірені вони в умовах високого навантаження?
Чи може оператор відрізнити нормальну незвичну поведінку від небезпечної? Чи відображає інтерфейс активний режим, джерела даних, обмеження та майбутній намір системи настільки, наскільки це потрібно для задачі?
Скільки часу фактично залишається між моментом, коли проблема може бути виявлена, і моментом незворотної шкоди? Скільки з цього часу займає орієнтація, рішення, моторна дія й реакція системи?
Які дії реально доступні операторові: скасувати команду, змінити режим, обмежити автоматизацію, перейти на ручне керування, зупинити процес, ескалувати іншому операторові? Чи працюють вони під час тих самих відмов, які викликали проблему?
Чи практикує оператор рідкісні аварійні або ручні сценарії? Чи перевіряється здатність відновити контроль після тривалого періоду пасивного моніторингу, а не лише знання процедури?
Чи має система безпечний план на випадок, коли людина не відповідає? Конструкція, яка перекладає аварійний стан на оператора без резерву, робить людину останньою лінією захисту, але не створює стійкості.
Чи відповідають відповідальність, повноваження й інформація одне одному? Якщо людина юридично або організаційно відповідає за результат, але не може знати про проблему чи змінити дію, розподіл ролей потребує перепроєктування.
Як оцінювати ефективність людського контролю
Одна метрика не доводить, що контур працює. Час реакції важливий, але швидка неправильна дія може бути гіршою за повільнішу правильну. Кількість втручань теж неоднозначна: низька частота може означати надійну автоматизацію або пропущені помилки; висока — уважний контроль або погано налаштовану систему.
Оцінювання зазвичай поєднує кілька рівнів: здатність виявити відхилення; правильність діагностики; ситуаційну обізнаність; час до рішення; якість і своєчасність втручання; помилкові втручання; успішність відновлення безпечного стану; розумове навантаження; усвідомлення режиму; збереження ручних навичок; поведінку після довгого періоду автоматизації; командну координацію там, де контроль розподілений між кількома людьми.
Тестувати потрібно не лише середній сценарій. Для safety-critical систем особливу цінність мають крайові випадки, неоднозначні сигнали, рідкісні комбінації відмов, раптові переходи режимів, хибні попередження, затримки та ситуації, у яких автоматизація поводиться правдоподібно, але неправильно. Саме вони показують, чи оператор отримує реальний контроль у момент, коли система виходить за межі штатної поведінки.
Приклади з реальних класів систем
Авіація
Сучасне повітряне судно поєднує автоматичне керування, навігацію, захисні функції, попередження та ручне втручання. Пілот може бути безпосереднім контролером, супервізором автоматизації або учасником переходу між режимами. Авіаційний досвід показує ціну mode awareness, якісного моніторингу, тренування неочікуваних подій і зрозумілого зворотного зв’язку. Саме тому авіація є одним із ключових джерел доказів для загальної теорії людського контролю автоматизації.
Умовно автоматизоване водіння
Автомобіль може довго виконувати динамічне керування, тоді як людина займається іншою діяльністю, а потім запросити повернення контролю. Такий сценарій концентрує проблему out-of-the-loop: водієві потрібно швидко відновити ситуаційну обізнаність. Систематичний огляд Tan і Zhang показує, що на цей процес впливає ціла конфігурація факторів, тому безпечний takeover — це задача дизайну системи й інтерфейсу, а не проста перевірка швидкості людської реакції.
Промислові та диспетчерські системи
У процесному керуванні оператор часто стежить за стабільною автоматичною системою, але відповідає за рідкісні відхилення. Тут особливо помітна «іронія автоматизації»: нормальна робота дає мало практики для ручного управління, тоді як аварійна ситуація вимагає глибокого розуміння процесу. Дизайн має підтримувати діагностику, тренування, пріоритезацію сигналів і безпечний перехід між режимами.
Високоризикові системи штучного інтелекту
У ШІ поняття human oversight отримало окреме нормативне значення. Стаття 14 Регламенту ЄС про штучний інтелект вимагає, щоб визначені високоризикові системи були спроєктовані з належними засобами людино-машинної взаємодії для ефективного нагляду людини під час використання; заходи нагляду мають бути пропорційними ризику, автономності й контексту. Це регуляторний приклад, а не універсальне визначення HITL для всіх технологій.
Окремо в машинному навчанні Human-in-the-Loop може означати участь людини у розмітці даних, навчанні, перевірці виходів або зворотному зв’язку моделі. Це інший рівень циклу. У цій статті головним є операційний контур: хто під час використання системи бачить її стан, ухвалює або переглядає рішення та має засоби вплинути на небезпечний перебіг подій.
Змістовний людський контроль: ширше за натискання кнопки
У дискусіях про автономні системи розвивається поняття meaningful human control — змістовного людського контролю. Воно починалося як нормативна концепція відповідальності й згодом отримало прикладні спроби операціоналізації. Важлива ідея полягає в тому, що контроль може існувати не лише в момент прямої ручної дії, а й через архітектуру цілей, правил, повноважень, меж автономності, моніторингу й відповідальності.
У міждисциплінарній роботі Santoni de Sio та співавторів для автоматизованого водіння розрізняються умови tracking і tracing: поведінка системи має відстежувати релевантні людські причини та цілі, а небезпечні події мають бути пов’язані з людськими акторами, які мали відповідні спроможності й відповідальність. Новіша рамка Calvert розширює цю логіку на автономні системи загалом і розрізняє близький до операції та віддалений рівні контролю — від безпосередніх операторів до дизайнерів, організацій і регуляторів.
Науковий статус цієї рамки відрізняється від статусу експериментально перевірених ефектів out-of-the-loop або стандартизованих ергономічних вимог. Meaningful human control є теоретико-прикладною і нормативною моделлю, що активно операціоналізується. Її користь для F08 полягає у точному нагадуванні: людина може формально бути «в контурі», але залишатися без змістовного впливу, якщо система не дає їй інформації, часу, повноважень або зв’язку між відповідальністю і реальною спроможністю діяти.
Поширені помилки в трактуванні
«Людина в контурі» означає, що людина ухвалює кожне рішення
Це лише один із варіантів. Людина може встановлювати цілі й обмеження, санкціонувати тільки критичні дії, контролювати винятки, мати право вето або втручатися після сигналу. Архітектуру визначають ризик, темп процесу й порівняльні можливості людини та автоматизації.
Якщо оператор може втрутитися, система автоматично безпечна
Можливість втручання має сенс лише разом зі спостережуваністю, часом, компетентністю, інтерфейсом і повноваженнями. Safety case має довести, що людина здатна виявити небезпечний стан і змінити його в конкретному сценарії.
Людська помилка пояснює аварію
У системному human factors помилка оператора є подією, яку треба пояснити через конструкцію задачі, інтерфейс, режими автоматизації, сигнали, процедури, навчання, організаційні умови та технічні відмови. Такий підхід дає проєктні рішення, тоді як ярлик «людський фактор» сам по собі нічого не виправляє.
Найкращий контроль — максимальна кількість попереджень
Надлишковий потік сигналів може погіршити пріоритезацію та зробити критичне повідомлення менш помітним. Сигнал має відповідати реальній потребі в дії, мати зрозумілий пріоритет і з’являтися тоді, коли оператор ще може виконати потрібну реакцію.
Пояснення автоматизації завжди вирішує проблему
Пояснення корисне лише тоді, коли воно підтримує конкретне завдання: перевірку стану, прогноз поведінки, діагностику або вибір втручання. Велика кількість технічних деталей може збільшити навантаження й уповільнити дію. Потрібна інформація визначається роллю оператора.
Поширені запитання
Що таке Human-in-the-Loop простими словами?
Це спосіб побудови автоматизованої системи, у якому людина залишається частиною керування: спостерігає, оцінює, підтверджує, змінює або зупиняє дії системи у визначених точках. Ефективність залежить від того, чи може вона реально вплинути на результат.
Чим Human-in-the-Loop відрізняється від Human-on-the-Loop?
У професійному вжитку Human-on-the-Loop зазвичай означає супервізорний нагляд: система виконує дії автономніше, а людина спостерігає й втручається за потреби. Терміни використовуються по-різному в різних галузях, тому точніше описувати конкретні функції, повноваження й момент втручання, ніж покладатися лише на ярлик.
Чи достатньо аварійної кнопки, щоб вважати людину в контурі?
Аварійна кнопка забезпечує один канал впливу. Повний контур потребує ще своєчасного виявлення проблеми, розуміння стану, достатнього часу, доступності дії та підтвердження результату. За відсутності цих умов зупинка може бути технічно доступною, але операційно запізнілою.
Чи повинен оператор перевіряти кожне автоматичне рішення?
Ні. Частоту й рівень перевірки визначають ризик, швидкість процесу, надійність автоматизації, можливість виявлення помилки та порівняльні можливості людини. У багатьох системах безпечнішим є контроль меж, винятків і критичних переходів, а не ритуальне погодження кожної штатної операції.
Скільки часу потрібно людині, щоб повернути керування?
Єдиного нормативного числа для всіх систем немає. Потрібний час залежить від динаміки подій, складності ситуації, інформації на інтерфейсі, попередньої залученості людини та необхідної дії. Часовий бюджет визначають і перевіряють для конкретного домену й сценарію.
Чи завжди більше автоматизації означає менше помилок?
Автоматизація може усунути одні класи помилок і створити інші: неправильне розуміння режиму, надмірну залежність, втрату ситуаційної обізнаності, деградацію навичок або складніший takeover. Її безпеку оцінюють на рівні всієї людино-технічної системи.
Як Human-in-the-Loop пов’язаний з автоматизаційним упередженням?
Автоматизаційне упередження описує схильність надмірно покладатися на автоматизовану рекомендацію або пропускати суперечливі дані. Human-in-the-Loop описує архітектуру участі людини. Добре спроєктований контур має враховувати це упередження, але сам факт людського підтвердження не усуває його.
Чи вимагає закон людського нагляду за ШІ?
Для визначених високоризикових систем ЄС Регламент про штучний інтелект встановлює вимоги до ефективного людського нагляду, пропорційного ризику, автономності й контексту використання. Це конкретний нормативний режим. В інших юрисдикціях і класах систем вимоги можуть бути іншими.
Хто відповідає за систему, якщо автоматизація діє сама?
Human factors розглядає відповідальність як частину ширшої соціотехнічної архітектури: оператор, розробник, організація, власник процесу й регулятор можуть мати різні ролі. Безпечний дизайн робить ці ролі явними й узгоджує відповідальність із інформацією, компетентністю та реальними повноваженнями.
Висновок
Людина в контурі керування — це не декоративна присутність і не універсальна вимога ручного схвалення. Це спроєктована архітектура контролю, у якій визначено, що робить автоматизація, що робить людина, яку інформацію вона отримує, скільки часу має, які повноваження може застосувати, як відбувається передача керування і що станеться, якщо втручання не відбулося.
Найсильніша система не перекладає ризик на «уважного оператора». Вона підтримує спостережуваність, ситуаційну обізнаність, зрозуміле усвідомлення режиму, практику втручання, достатній часовий запас, замкнений зворотний зв’язок і безпечну поведінку в разі відмови. Саме за цих умов людський контроль стає операційною властивістю системи, а не формальним написом у процедурі.
Пов’язані статті
Джерела
Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779. https://doi.org/10.1016/0005-1098(83)90046-8
Calvert, S. C. (2025). Principles and Framework for the Operationalisation of Meaningful Human Control Over Autonomous Systems. Science and Engineering Ethics, 31, 27. https://doi.org/10.1007/s11948-025-00554-z
Endsley, M. R., & Kiris, E. O. (1995). The Out-of-the-Loop Performance Problem and Level of Control in Automation. Human Factors, 37(2), 381–394. https://doi.org/10.1518/001872095779064555
European Union. (2024; consolidated text current in 2026). Regulation (EU) 2024/1689 — Article 14: Human oversight.
European Union Aviation Safety Agency. (2026). Easy Access Rules for Air Operations — CRM training: automation, monitoring and intervention.
Federal Aviation Administration. (2013). Operational Use of Flight Path Management System: Final Report of the Flight Deck Automation Working Group.
Federal Aviation Administration. (2026). Human Factors in Aviation Safety.
International Ergonomics Association. What Is Ergonomics (HFE)?
International Organization for Standardization. (2016). ISO 6385:2016 — Ergonomics principles in the design of work systems.
International Organization for Standardization. (2019). ISO 9241-210:2019 — Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems.
Papadimitriou, E., Schneider, C., Aguinaga Tello, J., Damen, W., Lomba Vrouenraets, M., & ten Broeke, A. (2020). Transport safety and human factors in the era of automation: What can transport modes learn from each other? Accident Analysis & Prevention, 144, 105656. https://doi.org/10.1016/j.aap.2020.105656
Parasuraman, R. (2000). Designing automation for human use: empirical studies and quantitative models. Ergonomics, 43(7), 931–951. https://doi.org/10.1080/001401300409125
Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics — Part A: Systems and Humans, 30(3), 286–297. https://doi.org/10.1109/3468.844354
Santoni de Sio, F., Mecacci, G., Calvert, S., Heikoop, D., Hagenzieker, M., & van Arem, B. (2022). Realising Meaningful Human Control Over Automated Driving Systems: A Multidisciplinary Approach. Minds and Machines. https://doi.org/10.1007/s11023-022-09608-8
Sheridan, T. B. (1999). Human supervisory control of aircraft, rail and highway vehicles. Transactions of the Institute of Measurement and Control, 21(4–5), 191–201. https://doi.org/10.1177/014233129902100407
Tan, X., & Zhang, Y. (2025). Driver Situation Awareness for Regaining Control from Conditionally Automated Vehicles: A Systematic Review of Empirical Studies. Human Factors, 67(4), 367–403. https://doi.org/10.1177/00187208241272071
