Human-in-the-loop не е контрол. Това е дисциплина при проектирането.

Одобрението, което всъщност не беше

В Marrowfield Specialty Risk одитът на сортирането на щети тази пролет породи кратка, неловка размяна на реплики. Брокерът, около 150 служители на пазар под надзора на регулатор, бе използвал система с ИИ за маркиране от осемнайсет месеца. Мариела Окафор, ръководител на операции по щети, бе на тази позиция от дванайсет години. Служителите обработваха над 200 случая на ден; моделът маркираше около 8%. Одитът извади две числа: 96% одобрение по случаите, маркирани от ИИ, и средно време за преглед 23 секунди. Служителят по съответствие попита: „Какви прагове настройвахте?“ Отговорът: „Никакви. Просто одобрявам каквото ИИ ми изпрати.“

Marrowfield Specialty Risk е композитен образ, изграден от интервюта със специализирани брокери от средния пазар и литературата по съответствие на BoE/FCA и Акта за изкуствения интелект. Имената са анонимизирани; показателите илюстрират модели от цитираните проучвания.

Под надзора на регулатори на три континента тази размяна на реплики днес се чете като доказателство за липсващ контрол. Датата на прилагане на Акта за изкуствения интелект през август 2026 г. слага календар върху провала при проектирането, но провалът е по-стар от календара.

§1 — Пасивното одобрение е одитен театър, не контрол

Стандартният мисловен модел — „ИИ маркира, човек одобрява“ — е структурно неотличим от липсата на контрол. Интерфейс с един бутон, без входни данни, без разсъждения на модела, без оценка на увереност произвежда точно показателите, които Marrowfield извади на повърхността. Работният почерк съвпада с напълно автоматизиран процес, в който човек чака в готовност.

Надзорните данни потвърждават това на ниво съвкупност. Проучването на BoE/FCA AI in UK Financial Services 2024 установи, че „55% от всички случаи на употреба на ИИ имат някаква степен на автоматизирано вземане на решения, като 24% от тях са полуавтономни, т.е. макар да могат сами да вземат набор от решения, те са проектирани да включват човешки контрол за критичните или нееднозначните решения“ [9]. Изводът, в съзвучие с рамката на NIST AI 600-1 за риска от конфигурацията човек–ИИ: по-голямата част от съвкупността на автоматизираното решаване няма същинска точка на намеса.

Регулаторите предприеха стъпки да затворят пролуката. Позицията на ICO е недвусмислена: решението не остава извън Член 22 на UK GDPR „само защото човек го е ‘подпечатал’“ [2]. Същите насоки са по-остри за оперативните доказателства: преглеждащите, които „рутинно се съгласяват с изходите на системата с ИИ и не могат да докажат, че действително са ги преценили“, може да бъдат квалифицирани като изцяло автоматизирани по UK GDPR [3]. Актът за изкуствения интелект поставя успореден тест в Член 14, който изисква системите да са „проектирани и разработени по такъв начин … че да могат да бъдат ефективно контролирани от физически лица“ [1]. Думата ефективно носи тежестта и в двете правни традиции. Въпросът при проектирането вече не е „има ли там човек?“, а „проектиран ли е така, че човек да може да открие, отмени и прекъсне — и би ли го направил?“

§2 — HITL е система от прагове, не стъпка за преглед

Взет насериозно, human-in-the-loop е система: явни прагове на увереност, три маршрута на решение, наслагване с тегла по риск и политика за опашката. Моделът връща оценка на увереност в обхвата 0,0–1,0 и важат три прага — автоматично отхвърляне под долната граница, човешки преглед в средната зона, автоматично одобряване над горната. Консервативните отправни точки за регулирани работни процеси са около 0,3 / 0,95; умерените операции — близо до 0,5 / 0,9; нискорисковата класификация — на 0,7 / 0,95. Праговете са умишлено асиметрични: фалшивите положителни и фалшивите отрицателни носят различна цена, а системата от прагове кодира тази асиметрия, вместо да я погребе в едно-единствено число. NIST AI RMF 1.0 стига до същото — нейната функция MANAGE „включва редовно разпределяне на ресурси за риска към картографираните и измерените рискове“ [5], а праговете са механизмът на разпределяне, оразмерени според риска, а не според удобството.

Отгоре стои наслагване с тегла по риск. Увереността се умножава по оценка за тежестта на бизнес риска — размер на щетата, необратимост на решението, регулаторна експозиция — за да се получи матрица за маршрутизиране 3×3. Високорисков случай с ниска увереност ескалира към супервайзор; високорисков с висока увереност все пак се насочва към стандартен HITL преглед, а не към автоматично одобряване. Изборът между двустепенна и тристепенна система има значение: двустепенната система насочва всеки несигурен случай в една опашка, опашката прелива, служителите по подразбиране минават към масово одобряване — моделът, който породи 96-процентовата стойност на Marrowfield. Тристепенната система дава на автоматичното отхвърляне продуктивна роля. Маршрутизирането зависи от централизирана ИИ стратегия^EN със санкциониран технологичен набор, който произвежда последователен скоринг на увереността; разпиляването на инструменти ad hoc прави дисциплината на праговете невъзможна, защото оценките от различни модели не са съпоставими.

§3 — Резервните пътеки се проектират, не се подразбират

„Резервна пътека“ не е обработка на грешки. Това е явното разклонение, което системата поема, когато ИИ е несигурен, и то има нужда от пътека, от човек, от срок (SLA). Три проектни решения покриват полето.

Решение А — синхронно, с човек в процеса: ИИ спира на пауза и връща случая в опашка с прикачени входен запис, разсъждения и увереност, при срок 2 до 4 часа; подходящо за решения, близки до реалното време. Решение Б — асинхронно, опашка за пакетна обработка: ИИ връща предварителен отговор, после го показва в дневен или седмичен пакет с ретроактивен прозорец за отмяна; подходящо за работа без времеви натиск. Решение В — йерархично, с ескалация към експерт: маршрутизира според несигурността на ИИ плюс тежестта на риска към многостепенен пул от преглеждащи (стандартен → експерт → супервайзор) със срокове 4 ч / 24 ч / 72 ч; подходящо за регулирано решаване — насочвания за поемане на риск, медицинско сортиране, маркери за съответствие.

Всяка резервна пътека има нужда от поименен собственик и документиран срок (SLA). Британският DSIT AI Playbook го формулира оперативно — „ясно документирани процеси на преглед и ескалация … и съвет за преглед на ИИ или съвет на ниво програма“ [4] — а NIST AI RMF MANAGE носи същото указание от друг ъгъл, изисквайки наблюдение след внедряване с поименни канали за обратна връзка. Одитният антимодел е постоянен: всеобхватна опашка „човешки преглед“ без срок и без собственик, в която опашката расте, а препоръката на ИИ става де факто решение. В Marrowfield преработката възложи всяка резервна пътека: дребните щети под праг на същественост се обработват автоматично; случаите в средната лента вървят по Решение А при срок 4 часа; случаите в горната лента и под прага вървят по Решение В с поименни специалисти по поемане на риск. Опашките престанаха да бъдат един преливащ канал и станаха три производствени линии със собствени показатели и собственици.

§4 — Одитната следа на отмените е артефактът за съответствие

Това, което одиторите всъщност проверяват, е дневникът на отмените. Липсващ дневник или дневник без структурирана обосновка не минава теста, преди изобщо да бъде изслушана разказната защита. Минималният артефакт за всяко HITL решение е фиксирана схема: case_id, увереност на ИИ, препоръка на ИИ, ID на преглеждащия, продължителност на прегледа в секунди, решение на човека, обосновка на отмяната, времеви печат, policy_version. Без policy_version следата е неразчитаема година по-късно, защото праговете ще са се изместили. Член 14(4) на Акта за изкуствения интелект изисква преглеждащите да могат да „се намесват в работата … или да прекъсват системата“ [1] — а оперативното следствие е, че способността трябва да остави запис, иначе не се е случила. NIST AI 600-1 го поставя на ниво действие: „Наблюдавайте и документирайте случаите, в които човешки оператори или други системи отменят решенията на генеративния ИИ“ [6]. Дневникът е централното доказателство за същински преглед.

Отчетността стои нагоре по веригата спрямо дневника. AI Update на FCA задава принципа: „ясни линии на отчетност, установени по жизнения цикъл на ИИ“ [10]. Фирмите по британския режим SM&CR поставят набора от ИИ и операции при функцията „главен оперативен директор“; американските фирми водят комитети по ИИ на ниво борд; европейските фирми следват насоките на ЕБО и ЕЦБ за отчетността на висшето ръководство. Принципът е преносим през трите традиции, което прави изграждането на управление на ИИ от първия ден по-евтино от дооборудването впоследствие. ISO/IEC 42001:2023 рамкира по-широкия набор от контроли като „интегриран подход за управление на проекти по ИИ, от оценката на риска до ефективното третиране на тези рискове“ [8].

Одиторите търсят обратни сигнали. Продължителност на прегледа под 10 секунди се чете като формално подпечатване. Дял на одобрение над 98% се чете като липса на преглед. Празно поле за обосновка се чете като недокументирана същинност. Над 200 решения на ден на преглеждащ се чете като умора. Всяко е констатация само по себе си.

§5 — Как тримесечната настройка поддържа HITL честен?

Праговете не са „настрой и забрави“. Моделите се отклоняват, бизнес правилата се променят, появяват се гранични случаи. Тримесечният цикъл е най-евтината дисциплина, която пази проектираната HITL система от връщане към театър, и носи тежест през юрисдикциите: тестът за „ефективен“ контрол по Член 14 е невъзможен за изпълнение без него, а NIST AI RMF MANAGE очаква да са налице „планове за приоритизиране на риска и редовно наблюдение и подобрение“ [5].

Месец първи — измерете базата: обем на HITL на седмица, честота на отмените по зони на увереност, разпределение на времето до решение, честота на ескалация по степен. Месец втори — установете сигнали за отклонение: зони, в които отмените надхвърлят 20%, означават, че моделът е ненадежден и HITL зоната трябва да се разшири или моделът да се преобучи; зони под 2% може спокойно да се стеснят; случаите по Решение Б без преглед в рамките на прозореца означават, че пакетният процес е счупен. Месец трети — коригирайте и документирайте: актуализирайте дефинициите на праговете, увеличете policy_version с причината за промяната, уведомете операциите, нулирайте базата.

Цикълът предполага култура сред преглеждащите, която подкрепя отмяната. ICO е изрична: същинският преглед изисква „преглеждащите да имат правомощието да отменят изхода, генериран от системата с ИИ, и да са уверени, че няма да бъдат санкционирани за това“ [3]. Същото очакване стои в американските обществени поръчки по NIST AI RMF и в правилата на ЕС за отчетност по ЕБО и ЕЦБ — различни юрисдикции, идентичен оперативен тест. Където културата наказва отклонението, честотата на отмените се срива по културни, а не по технически причини, и данните, на които цикълът разчита, стават неразчитаеми. Британският DSIT Playbook посочва собствеността: съвет за преглед на ИИ или съвет на ниво програма владее цикъла [4]. Типичният отговор от средния пазар на „кой владее това“ е вътрешно повишение — вижте аргумента, че най-добрият ръководител по ИИ^EN вече е в сградата.

§6 — Кои пет антимодела се провалят при одит по Член 14?

Едни и същи пет режима на провал изникват при всеки одит.

Интерфейс за одобряване/отхвърляне с един бутон. Преглеждащият вижда само решението. Симптом: дялове на одобрение над 95%, прегледи под 10 секунди. Корекция: показвайте увереността, входния запис и заявените причини за несигурност. Член 14(4)(б) е изричен за пристрастието към автоматизацията — преглеждащите трябва да „остават наясно с възможната склонност автоматично да разчитат или прекомерно да разчитат на изхода, произведен от високорискова система с ИИ“ [1].

Един преглеждащ, без ротация. Един оперативен директор преглежда всеки HITL случай. Симптом: тесни места през уикенда, грешки от умора в края на деня, единична точка на отказ. Корекция: обучен пул от 3–5 преглеждащи по документиран график на ротация.

Праг, зададен веднъж, никога не настройван. Стойностите по подразбиране на доставчика стоят непроменени. Симптом: обемът на HITL е далеч от зоната; честотата на отмените е подозрително ниска или хронично над 20%. Корекция: тримесечният цикъл от §5.

Без улавяне на обосновката за отмяна. Преглеждащите могат да отменят, но полето за обосновка е по избор или празно. Симптом: същинността не може да бъде доказана. Корекция: структурирано улавяне — падащо меню с трите водещи причини плюс поле със свободен текст, и двете задължителни.

Резервна опашка без срок (SLA). Случаите се насочват към „човешки преглед“ без отговорност за изчистване в определен прозорец. Симптом: дължина на опашката, която расте от месец на месец, преглеждащи, които прескачат по-старите записи. Корекция: явен срок за всяка резервна пътека плюс табло за наблюдение на опашката с поименен собственик. Разпиляната собственост е структурният риск; проучването на BoE/FCA отбелязва, че отчетността „често е разделена, като повечето фирми съобщават за три или повече отговорни лица или органи“ [9], а Член 14 на Акта за изкуствения интелект възлага контрола на поименно „физическо лице“ [1].

§7 — Член 14 и календарът за август 2026 г.

Рамката за съответствие не е театър, специфичен за дадена юрисдикция. Множество регулатори се схождат към един и същ оперативен тест; Актът за изкуствения интелект прикача най-публичния краен срок. Член 113 определя датата на прилагане за високорисковите задължения — включително Член 14 — на 2 август 2026 г. [1]. От тази дата фирмите, които внедряват ИИ във високорискови обхвати по Приложение III (заетост, кредитен скоринг, критична инфраструктура, данни за правоприлагане), носят задължението.

Член 22 на UK GDPR вече е обвързващ, а неговият тест е „същинско човешко участие“ [3] — правомощие, компетентност, отчитане на входните данни и алтернативите, подкрепяща култура и липса на санкция за отмяна на модела. Където се прилага Член 22 — навсякъде, където решението има правен или подобно значим ефект — „подпечатването“ не минава теста [2]. Американската позиция не отсъства: закони на щатско ниво (Colorado AI Act, NYC AEDT, предложените правила ADMT на Калифорния) и секторно прилагане (FTC за автоматизираното решаване, NIST AI RMF като референция за обществените поръчки на федерално ниво) тласкат същата дисциплина. ISO/IEC 23894:2023 стандартизира основополагащия подход за управление на риска като „насоки за това как организациите … могат да управляват риска, конкретно свързан с ИИ“ [7] — най-чистата нерегулаторна опора за пазари, чиито специфични за ИИ закони още не са влезли в сила, и гръбнакът на всяка многоюрисдикционна оперативна политика.

Секторните регулатори подсилват извода: FCA е технологично неутрален [10], европейските еквиваленти по ЕБО и ЕЦБ се схождат върху отчетността на висшето ръководство, а проучването на BoE/FCA от 2024 г. показва, че отчетността в повечето анкетирани фирми е типично разпокъсана между три или повече отговорни страни [9].

Въпросите за проектирането в §§2–5 са въпросите за съответствие през трите правни традиции. Изграждането на HITL по този начин се плаща веднъж; дооборудването след провал на одита се плаща всяко тримесечие.

§8 — Как изглежда четириседмичният спринт за проектиране на HITL?

Преработката е ограничена в обхвата: спринт на ниво ръководител на операции, не програма.

Седмица 1 — измерете текущото състояние. Опишете всяка стъпка „човешки преглед“. Извадете дяловете на одобрение, разпределенията на продължителността на прегледа, състоянието на улавяне на отмените, дължините на опашките. Почерк на пасивно одобрение: висок дял на одобрение, ниска продължителност на прегледа, без структурирана обосновка за отмяна.

Седмица 2 — проектирайте маршрутите на решение. Задайте праговете на увереност за всеки работен процес, използвайки отправните точки от §2. Проектирайте резервните пътеки по §3. Дефинирайте одитната схема на отмените по §4. Документирайте policy_version v1.0 със стойностите на праговете, собствениците и сроковете.

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

Седмица 4 — първи преглед на настройката и готова за одит документация. Пуснете цикъла от §5 спрямо данните от седмица 3; очевидните сигнали за отклонение изникват дори при кратък прозорец. Сглобете пакета артефакти: дефиниции на праговете, табло за честотата на отмените, опис на пътеките за ескалация, карта на собствеността. Резултатът е позицията, спрямо която да тествате 50-те въпроса, които вземащите решения задават преди внедряване на ИИ^EN, който покрива В3.10, В5.4, В5.5 и В5.7.

Ценова лента: 20–40 часа време на ръководител на операции. Резултат: протокол за контрол, готов за Член 14, защитима по Член 22 позиция за „същински преглед“ и функция MANAGE, съгласувана с NIST RMF.

От одобрение към дисциплина

Четири седмици след преработката оперативната картина се е изместила. Обемът на HITL по работния процес за щети е спаднал със 70%, защото автоматичното отхвърляне върши реална работа в зоната под прага. Средното време за преглед на случаите, които все пак стигат до HITL, се е покачило до около четири минути — времето, което структурираният преглед действително отнема. Честотата на отмените се е стабилизирала на 14%, в здравословната зона 5–20%, като всеки отменен случай носи структурирана обосновка. Въпросът на служителя по съответствие сега има отговор с прикачени номера на версии.

Разликата между одитен театър и защитим пред одит контрол не е колко сериозно фирмата говори за човешки преглед. Тя е дали прегледът е проектирана система от прагове или одобряване с едно кликване. Едното минава Член 14. Другото — не.

За преглед на това къде стои HITL проектирането през регулираните работни процеси на организацията, easy-audit.ai го картографира за два часа структурирани въпроси.

Обобщение

HITL — designed oversight, not passive sign-off
│
├─ The failure · audit theatre
│   ├─ Passive sign-off — one-click approve, no reasoning shown
│   └─ Rubber-stamp test — >98% approve, <10s review fails it
│
├─ The system · thresholds & routes
│   ├─ Three routes — auto-reject / HITL review / auto-approve
│   ├─ Risk overlay — confidence × severity sets escalation
│   └─ Fallback paths — named owner, SLA, override audit log
│
└─ The discipline · stays honest
    ├─ Healthy band — 5–20% override; outside it, tune or retrain
    └─ Quarterly cycle — measure, spot drift, re-version, document