Какво може да научи Европа от практиката за безопасност

Досието за безопасност е жив аргумент от опасности и допускания до доказателства, остатъчен риск и решение. То предлага на AI екипите по-честна дисциплина...

Какво може да научи Европа от практиката за безопасност

Файл, който трябва да отговори, преди влакът да потегли

Европейските железопътни правила започват с един непривлекателен въпрос: какво се е променило. Промяната може да бъде техническа, оперативна или организационна. Тя може да включва оборудване, процедура, организация на персонала или интерфейс между организации. Общият метод за безопасност при оценка и анализ на риска изисква от предлагащия да оцени значимостта на тази промяна, да приложи процес за управление на риска, когато е необходимо, и да използва независим орган за оценка, който да провери дали процесът и резултатите от него са приложени правилно. Правилото не се интересува дали промяната е била обявена с увереност. То се интересува дали аргументът за продължаване на експлоатацията може да бъде проверен.

Този навик си струва да бъде пренесен в изкуствения интелект. Една система не става безопасна, защото нейният модел е умен, интерфейсът ѝ е спокоен или доставчикът ѝ е изготвил представителен доклад от изпитвания. Тя става защитима за определена употреба, когато дадена организация може да обясни какво твърди, кои опасности стоят зад твърдението, кои допускания правят твърдението възможно, какви доказателства подкрепят всяка връзка, кой е приел оставащия риск и какво би отворило отново решението. Резултатът обикновено се нарича обосновка за безопасност: структуриран аргумент, подкрепен от доказателства, ограничен от условия и поддържан при промени.

Обосновката за безопасност не е разказ за въображаема злополука. Тя е начин да се откажем да позволим на злополуката да носи всички доказателства. Тя задава трудните въпроси, докато проектирането, доставките и оперативната практика все още могат да се променят. Това я прави полезна за железопътния транспорт, авиацията, медицинските изделия, промишления контрол и критичната инфраструктура. Тя е полезна и за изкуствения интелект, където даден компонент може да бъде едновременно статистически впечатляващ и оперативно неподготвен. Един модел може да премине тест, докато системата около него няма безопасен отговор на несигурността, няма отговорен оператор и няма начин да се възстанови от лошо решение.

Това разграничение има значение в Европа, защото Законът за изкуствения интелект вече изисква системите с висок риск да работят с непрекъснат, документиран процес за управление на риска. Член 9 описва итеративно идентифициране, оценяване, оценка и третиране на рисковете през целия жизнен цикъл на системата, включително разумно предвидима злоупотреба и информация от мониторинга след пускане на пазара. Член 11 изисква техническа документация преди пускането на системата на пазара и посочва, че тя трябва да се поддържа актуална. Тези разпоредби не използват обосновката за безопасност като универсален етикет. Те обаче описват навиците, които правят една обосновка за безопасност достоверна.

Обосновката за безопасност прави пътя от твърдението за безопасност до решението за пускане достатъчно видим, за да бъде оспорен.

Обосновката за безопасност не е доклад от изпитвания

Докладът от тест отговаря на въпрос за даден тест. В него се записва какво е тествано, при какви условия, с какъв резултат и, ако работата е добра, с какви ограничения. Това е ценно. Оценката за безопасност задава различен въпрос: има ли достатъчно обоснован аргумент, че тази система е приемлива за тази цел, в този контекст, с тези хора, контроли и оставащи рискове. Резултатът от тест може да е едно от доказателствата в този аргумент. Той не може тихо да се превърне в целия аргумент само защото таблицата е оцветена в зелено.

Да предположим, че класификатор е тестван срещу обозначен набор от данни. Докладът може да ни каже как се е представил върху този набор, може би по клас, праг или работна точка. Той сам по себе си не ни казва дали входните данни в производствена среда имат същото значение, дали засегнатата група е представена, дали проверяващият може да разпознае слаб резултат, дали е възможно обжалване, дали доставчик може да промени модела без предизвестие, или дали организацията може да спре и да обърне последващо действие. Тези въпроси принадлежат на системата и нейната употреба, а не само на компонента.

Противоположната грешка също е често срещана. Голям файл за осигуряване на качеството може да съдържа стотици страници и пак да не изгради аргумент. Каталог от тестове, политики и бележки от срещи не е оценка за безопасност, ако нито едно твърдение не ги свързва. Доказателството има нужда от задача. Тест може да подкрепи твърдение за устойчивост. Описание на длъжност може да подкрепи твърдение за правомощия. Упражнение за връщане към предишно състояние може да подкрепи твърдение за възстановяване. Одитна следа може да подкрепи твърдение за проследимост. Без връзката между твърдение и доказателство файлът е архив на дейност, а не обяснение на безопасността.

Ето защо една оценка за безопасност може да е по-кратка от доклад за тест на едно място и по-голяма на друго. Тя се разраства около опасностите и решенията. Инструмент за изготвяне на текстове с ниски последствия може да се нуждае от скромен аргумент, който обхваща обхвата, обработката на данни, прегледа и корекцията. Система, свързана с решения в клиничната област, транспорта, финансите или обществените услуги, се нуждае от повече доказателства, защото повече хора зависят от резултата и защото пътят до обезщетение може да е труден. Размерът следва последствията и несигурността, а не модната дължина на моделната карта.

Аргументът трябва също да разграничава доказателства за компонента от доказателства за работата. Доказателствата за компонента се отнасят до модела, алгоритъма или сензора изолирано или в контролирана интеграция. Доказателствата за работата се отнасят до действителния работен процес: достъп, актуалност на данните, човешки преглед, опашки, разрешения за инструменти, обработка на инциденти и контрол на промените. Модел може да е стабилен, докато опашка се срива. Работен процес може да е добре проектиран, докато доставчик променя схемата на входните данни. Оценките за безопасност принуждават и двата погледа да са на една и съща страница, което е леко неудобно и затова здравословно.

Започнете с твърдение, което има граници

Всяка оценка за безопасност започва с твърдение на най-високо ниво. Твърдението трябва да е достатъчно тясно, за да бъде тествано, и достатъчно полезно, за да насочва решение. Изречението този ИИ е безопасен не е твърдение с граници. Безопасен за кого, за какво, при какви условия и с какви контроли. По-добро твърдение може да каже, че определена функция за подпомагане на решения е приемлива за определена група обучени оператори, при условие че системата се използва само за препоръки, че доказателствата и несигурността се показват, че човек с правомощия преглежда резултата и че са налични определени пътища за спиране и корекция.

Това изречение е по-малко продаваемо и много по-ценно. То определя целта, действащото лице, границата и условията. То също разкрива какво би направило твърдението невярно. Ако същата функция е свързана директно с автоматично решение, твърдението вече не я покрива. Ако предназначените потребители не са обучени или не могат да оспорят резултат, твърдението отслабва. Ако източник на данни се промени и не може да бъде проследен, доказателствата за твърдението може да изтекат. Едно добро твърдение на най-високо ниво носи със себе си собствения си списък от начини да бъде отворено отново.

Твърденията могат да бъдат разложени. Системата остава в рамките на предназначението си. Входните данни отговарят на посочените условия за качество и разрешения. Резултатът от модела се интерпретира по начин, който не създава опасен автоматизъм на доверие. Действията с висока степен на последствия получават преглед, съобразен с риска им. Операторите могат да пренебрегнат или отменят даден резултат. Организацията може да забележи значително отклонение. Промяна не се пуска, без да се проверят засегнатите допускания. Всяко подтвърждение изисква контроли и доказателства. Дървото не е илюстрация за презентация; то е пътят, по който рецензентът може да открие слабото звено.

Едно твърдение трябва също да посочва какво не се опитва да докаже. Случаят може да подкрепя безопасна употреба за една задача, без да доказва обща интелигентност, универсална справедливост или пригодност за всяка популация. Той може да подкрепя пускане при определена позиция на разгръщане, без да доказва, че незаписана конфигурация ще се държи по същия начин. Не-твърденията не са скромни украшения. Те предотвратяват разпространението на тесен резултат в организацията като много по-голямо обещание.

Съществува полезен европейски инстинкт зад тази точност. Регламент 402/2013 изисква от железопътния кандидат да реши дали дадена промяна е значителна, да избере принцип за приемане на риска и, където е уместно, да използва независима оценка. От кандидата не се изисква да докаже, че всяко възможно бъдещо състояние на железопътната система е безопасно. От кандидата се изисква да направи текущата промяна и нейните интерфейси достатъчно разбираеми за пропорционално решение. Екипите за изкуствен интелект могат да заимстват същата дисциплина. Назовете промяната, назовете оперативния контекст и направете границата видима.

Опасностите са условия, не заглавия

Опасността е условие, което може да доведе до вреда. Разграничението е по-полезно, отколкото изглежда на пръв поглед. Грешно решение за обезщетение е резултат. Опасност може да бъде непълен запис, съчетан със система, която представя неподкрепена препоръка като готова за одобрение. Забавеното предупреждение за поддръжка е резултат. Опасност може да бъде остарял поток от сензорни данни, който работният процес третира като актуален. Нарушаването на поверителността е резултат. Опасност може да бъде прекалено широко разрешение за извличане, съчетано с инструмент, който копира изходния материал в траен запис.

Описанието на опасностите по този начин премества вниманието нагоре по веригата. То прави възможни проектните и оперативните контроли. Ако опасността е неподкрепена препоръка, представена с прекомерен авторитет, контролът може да изисква доказателства от източника, да показва несигурността, да ограничава действието и да осигури път за преглед. Ако опасността е остарял вход, контролът може да проверява актуалността, да отбелязва състоянието на данните, да блокира действието или да го насочва към човек. Ако опасността е прекомерен достъп, контролът може да ограничи извличането, да раздели самоличностите, да редактира изхода и да записва решението за достъп. Контролът трябва да адресира условието, а не просто да обещава внимателност около резултата.

Анализът на опасностите трябва да включва предвидима злоупотреба, не само предназначението, записано в документ за поръчка. Актът за изкуствен интелект прави това изрично за системите с висок риск. Член 9 изисква оценка на рисковете, когато системата се използва по предназначение и при разумно предвидима злоупотреба. Злоупотребата не означава всяка абсурдна заявка. Тя означава употреби, които компетентен екип би могъл да предвиди от интерфейса, стимулите, инструкциите и околния работен процес. Ако най-бързият път в системата е да се приеме препоръка, без да се прочетат доказателствата ѝ, този път принадлежи на анализа, дори ако политиката казва, че прегледът е задължителен.

Опасностите се крият и в интерфейсите. Моделът може да даде ограничена препоръка, но интеграцията може да я превърне в неограничена инструкция. Доставчикът може да предостави крайна точка с версия, но внедряването може да кешира отговорите след изтичане на срока на валидност. Публичен орган може да запази отговорността за решението, но договорът може да направи доставчика единствената страна, която може да проверява следата. Границата на системата за обосновка на безопасността трябва да следва причинно-следствения път до последствието. Ако границата се очертае само около модела, това е удобен начин да се пропусне работата, която прави модела значим.

Не всяка опасност заслужава еднакво отношение. Някои могат да бъдат намалени чрез проектиране. Някои изискват процедурни контроли или човешка проверка. Някои могат да бъдат наблюдавани и приети с условия. Някои показват, че предложената употреба не е подходяща. Обосновката за безопасност трябва да покаже разсъжденията, а не да ги скрие зад универсален рисков резултат. Европейският железопътен метод позволява различни принципи за приемане на риска, включително кодекси за практика, сравнение с подобни части на системата и изрична оценка на риска. Изводът не е, че един метод печели навсякъде. Изводът е, че методът и съответствието му с промяната трябва да бъдат документирани.

Предположенията носят тежестта

Всяка обосновка за безопасност се опира на предположения. Операторът е обучен. Източникът е актуален. Прагът има значението, което екипът смята, че има. Човекът, който получава предупреждението, може да действа навреме. Външната услуга ще бъде налична или съществува резервен вариант. Резултатът ще остане препоръка, а не ще се превърне в де факто решение. Организацията ще забележи, ако актуализация на модела промени поведението. Много откази в безопасността не се дължат на това, че дадено предположение е неразумно. Те се дължат на това, че предположението е невидимо.

Едно предположение принадлежи към обосновката със собственик и начин да бъде проверено. Ако аргументът разчита на обучени проверяващи, обосновката трябва да посочи необходимата компетентност, как се установява тя и какво се случва при промяна на персонала. Ако аргументът разчита на източник, който остава в рамките на прозореца за актуалност, системата трябва да записва актуалността и да обвързва действието с нея, където е необходимо. Ако аргументът разчита на интеграция, която запазва поле, договорът за интерфейса и тест трябва да направят зависимостта видима. Предположение, което не може да бъде проверено, е риск с по-меко име.

Предположенията могат да се отнасят и до външния свят, не само до софтуера. Болницата може да зависи от клиничен път. Железопътният оператор може да зависи от интерфейс за сигнализация. Публичен орган може да зависи от законов процес и от човешко лице, вземащо решения, което запазва правомощията си. Производителят може да зависи от извършването на поддръжка в определен интервал. Обосновката за безопасност не контролира всяко външно условие. Но тя трябва да посочи кои условия предполага, кой ги притежава и как се разпознава промяната.

Когато предположенията се променят, обосновката не трябва тихо да се разтяга. Екип може да започне с употреба само за препоръки и след това да добави автоматично прехвърляне, защото препоръката често е била приемана. Моделът не се е променил, но правомощията и опасността са се променили. Доставчик на данни може да добави нова категория, която изглежда безобидна, докато не промени значението на правило надолу по веригата. Внедряването може да премине от обучени специалисти към общ екип за поддръжка. Това са промени в обосновката, дори ако номерът на версията на модела остава същият.

Предположенията са особено важни за вероятностните системи, защото стабилната средна стойност може да прикрие нестабилен ръб. Обосновката трябва да посочи къде се очаква системата да бъде несигурна, какви доказателства сигнализират за тази несигурност и кой човешки или технически контрол поема управлението. Целта не е да се преструваме, че несигурността може да бъде елиминирана. Целта е да спрем неизказаното очакване за сигурност да се превърне в оперативна политика.

Доказателството не е паспорт за всеки контекст. Неговите допускания определят докъде може да стигне.

Доказателството се нуждае от верига на съхранение

Доказателството в досието за безопасност е повече от резултат, вписан в таблица. То има идентичност, обхват, дата, метод, отговорно лице или екип и връзка с твърдението, което подкрепя. Тестът изисква дефинирани входни данни и конфигурация. Прегледът изисква въпрос и решение. Упражнението изисква очакван отговор и наблюдение. Дневникът изисква достатъчно контекст, за да бъде тълкуван без разчитане на памет. Изходният запис изисква следа за произход. Детайлите се различават по област, но принципът е стабилен: доказателството трябва да може да бъде проверено след срещата, на която е прозвучало убедително.

Актът за ИИ придава правна тежест на този принцип за системите с висок риск. Член 11 изисква техническата документация да е налична преди пускането на системата на пазара и да се поддържа актуална. Член 12 изисква автоматично записване на съответните събития през целия жизнен цикъл на системата, с възможности за регистриране, съразмерни с предвидената цел и полезни за идентифициране на риска, подпомагане на наблюдението след пускането на пазара и наблюдение на работата. Член 13 изисква информация, която позволява на внедрителите да разбират възможностите, ограниченията, предвидимите рискове, човешкия надзор и изискванията за входни данни. Досието за безопасност свързва тези записи, вместо да ги оставя в отделни чекмеджета за съответствие.

Доказателството трябва да запази своите условия. Резултат от изпълнение без неговата тестова съвкупност може да бъде погрешно разбран. Резултат за устойчивост без използваните смущения може да бъде надценен. Преглед на човешкия фактор без работния процес и времевия натиск, при които е извършен, може да се превърне в общ комплимент. Дневник на инциденти без версията, състоянието на данните и разрешенията, които са били в сила, може да доведе до привлекателна, но грешна основна причина. Колкото по-значимо е решението, толкова по-неприемливо е да се отдели резултатът от обстоятелствата, които са го направили верен.

Доказателството може да бъде качествено или количествено. Документирана експертна преценка може да бъде валидно доказателство, когато въпросът е подходящ, експертизата е идентифицирана и разсъждението е записано. Числова оценка може да бъде слабо доказателство, когато знаменателят, прагът или условията на теста са неясни. Няма морална йерархия, в която числото автоматично да превъзхожда внимателното наблюдение. Досието трябва да обяснява пригодността за целта и несигурността, а не да изразява преклонение пред десетичните знаци.

Проследимостта също прави несъгласието продуктивно. Рецензентът трябва да може да посочи кое твърдение не е подкрепено, кое допускане е твърде оптимистично или кой контрол не е бил упражнен. Тогава досието се превръща в обект за оспорване, а не в пакет за церемониално одобрение. Това е една от причините индустриите, свързани с безопасността, да инвестират в независима оценка и структурирани доклади за осигуряване на качеството. Целта не е несъгласието да е удобно. Целта е несъгласието да може да бъде локализирано.

Остатъчният риск е решение, а не остатък

Рискът не изчезва, защото са добавени контроли. Рискът, който остава след контролите, е остатъчен риск. Той трябва да бъде описан и приет от орган, който може да разбере доказателствата, да наложи условия и да спре употребата, когато условията не са изпълнени. Да се нарече даден риск приемлив не е същото като да се каже, че е малък. Това означава, че организацията е взела обосновано решение относно оставащата експозиция в определен контекст и не е скрила основанието за това решение.

Член 9 от Акта за ИИ използва точно този език за системите с висок риск. Съответният остатъчен риск, свързан с всяка опасност, както и общият остатъчен риск, трябва да бъдат оценени като приемливи. Регламентът също така изисква премахване или намаляване, когато това е технически осъществимо, както и мерки за смекчаване и контрол, когато рисковете не могат да бъдат премахнати. Това е полезен ред. Първо промени дизайна, когато е възможно. След това добави контроли. Накрая запиши какво остава. Предупредителният етикет не е извинение да се запази предотвратима опасност в архитектурата.

Остатъчният риск трябва да включва обратимост. Критериите за риск в Акта за ИИ отчитат дали даден резултат може да бъде коригиран или обърнат, и отбелязват, че неблагоприятните последици за здравето, безопасността или основните права не трябва да се третират като лесно коригируеми само защото съществува технически бутон за отмяна. Това е тихо, но важно разграничение. Чернова може да бъде коригирана. Изгубена полза, отказана услуга или публично обвинение може да са много по-трудни за поправяне. Досието трябва да предвижда по-строги контроли там, където засегнатото лице реалистично не може да се откаже или да отмени резултата.

Приемането трябва да има условия. Една система може да бъде приета за ограничен пилотен проект, обучен екип, посочен източник на данни и път за преглед. Тя не може да бъде приета за различно население, непроследен работен процес или интеграция, която премахва доказателства. Условията трябва да бъдат написани така, че операторът да може да прецени дали те все още са изпълнени. Ако условието е просто, че потребителите ще прилагат преценка, досието не е обяснило как системата подпомага преценката или какво се случва, когато натоварването затруднява преценката.

Решението за остатъчен риск също се нуждае от срок на валидност или тригер за преглед. Фиксирана календарна дата може да помогне, но събитията обикновено са по-информативни: промяна на модела, нов източник, съществен инцидент, сигнал за отклонение, промяна в потребителите, ново правно задължение или провал на упражняването на контрол. Решението не е талисман, поставен върху изданието. То е разрешение с график за поддръжка.

Човешкият надзор трябва да има власт

Човешкият надзор често се споменава, сякаш човек, стоящ някъде близо до резултата, прави системата безопасна. Актът за ИИ е по-взискателен. Член 14 гласи, че системите с висок риск трябва да бъдат проектирани така, че физическите лица да могат ефективно да ги наблюдават по време на употреба. Надзорът трябва да е съразмерен с риска, автономията и контекста. Хората, на които е възложен, трябва да разбират възможностите и ограниченията, да откриват аномалии, да разпознават пристрастието към автоматизация, да тълкуват резултатите, да решават да не използват или да отменят системата, и да се намесват или да спрат системата чрез безопасна процедура.

Това са изисквания към дизайна точно толкова, колкото и към персонала. Рецензентът не може да тълкува резултат, ако доказателствата са скрити. Рецензентът не може да оспори препоръка, ако интерфейсът представя приемането като единствения удобен път. Рецензентът не може да спре система, ако действието за спиране изисква разрешение, което никой не е предоставил. Рецензентът не може да осигури смислен контрол, докато се оценява единствено по производителност. Един аргумент за безопасност трябва следователно да третира човешката роля като контрол с входни данни, правомощия, натовареност, обучение и наблюдаемо поведение.

Правомощията са детайлът, който учтивите описания пропускат. Кой може да постави работния процес на пауза. Кой може да отмени действие. Кой може да заяви, че дадено допускане вече не е валидно. Кой може да се свърже с доставчика. Кой притежава записа. Кой решава дали остатъчният риск все още е приемлив. Ако никой няма правомощията, описанието за човек в контура е театър. Човекът може да види резултата, но виждането не е управление.

Добрият контрол също е селективен. Целта не е да се изпраща всяка тривиална чернова на комитет. Целта е да се постави човешката преценка там, където последствията, несигурността или възможността за оспорване го изискват. Някои случаи могат да се обработват чрез структурирани проверки. Някои изискват обучен специалист. Някои изискват две независими потвърждения съгласно приложимия закон. Някои трябва да бъдат отказани. Аргументът трябва да обясни подбора и да демонстрира, че избраният път е наличен в реалната експлоатация, а не само в наръчника с процедури.

Има един скромен вид уважение в това да се проектира по този начин. То приема, че хората се уморяват, че опашките растат, че интерфейсите оформят вниманието и че предупреждение, което се появява сто пъти, може да престане да бъде предупреждение. Инженерингът на безопасността е научил това чрез опит в транспорта и промишлеността. Екипите за изкуствен интелект не е нужно да повтарят всеки урок, провеждайки предотвратим експеримент върху обществеността.

Промяната продължава да навлиза в аргумента

Един аргумент за безопасност е жив, защото системата е жива. Версията на модела може да се промени, но също и подканата, индексът за извличане, таксономията, политиката, хардуерът, персоналът, интерфейсът, източникът на данни или доставчикът. Малка промяна може да обезсили допускане или да премести контрол. Произтичащият риск може да е по-висок, по-нисък или просто различен. Правилният отговор не е да се замрази системата завинаги. Той е промяната да стане видима, значимостта ѝ да се класифицира и да се реши кои части от аргумента трябва да бъдат преразгледани.

Железопътната практика предлага ясен модел. Регламент 402/2013 прилага своя общ метод, когато технически, оперативни или организационни промени засягат железопътната система. Предлагащият преценява значимостта на промяната и, когато е необходимо, използва принципи за приемане на риск и независима оценка. Регламентът също предупреждава, че съвкупността от промени от последния процес за оценка на риска може да има значение. Няколко малки промени могат да се натрупат до значителна. Управлението на изкуствения интелект се нуждае от същото подозрение към безобидно изглеждащите увеличения.

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

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

Наблюдението след пускането на пазара разширява обхвата на случая след пускането. Член 9 препраща към данните, събрани по член 72, а член 72 изисква документирана система за наблюдение на системите с висок риск през целия им жизнен цикъл. Наблюдението трябва да търси сигналите, които имат значение за твърдението: променени модели на грешки, необичайни откази, неочаквана употреба, резултати от обжалвания, липсващи доказателства, събития за сигурността и провали на човешкия контрол. Табло, което отчита само наличността, е приятен начин да се пропусне проблем със сигурността.

Независимата оценка е полезна неприятност

Хората, които са изградили дадена система, познават нейната елегантност, нейните преки пътища и натиска, под който е създадена. Това знание е необходимо. То не е достатъчно, за да се приеме рискът. Независимата оценка създава пространство някой да оспори аргумента, без да носи същите стимули за пускане. Независимостта не изисква враждебност или външно лого на всяка страница. Тя изисква компетентност, обхват, достъп до доказателства и правомощие да се запише несъгласие, което собственикът не може просто да изтрие.

Европейският железопътен метод прави това разделение конкретно. ERA описва орган за оценка, отговорен за проверка на правилното прилагане на процеса за оценка на риска и неговите резултати, с изисквания за компетентност, акредитация или признаване. Регламентът позволява независим и компетентен външен или вътрешен орган, при условие че отговаря на критериите. Дизайнът е пропорционален, а не театрален. Той признава, че увереността може да бъде вътрешна, когато независимостта е реална, и че значка не може да спаси оценител, който не вижда съответните доказателства.

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

Независимостта е също така защита срещу непрозрачността на доставчика. Докладът на доставчика може да подкрепи твърдение, но внедряващата страна трябва да знае какво е тествано, при каква конфигурация и какви ограничения остават. Ако критичен резултат не може да бъде възпроизведен, проверен или прехвърлен при прекратяване на договора, тази зависимост принадлежи към случая. Обществените поръчки трябва да изискват достъп до доказателства, идентичност на версията, уведомяване за инциденти, уведомяване за промени, експорт, връщане към предишна версия и практичен изход. Думата практичен върши тежка работа тук. Право, което не може да бъде упражнено под времеви натиск, не е кой знае какъв контрол.

Добрата оценка дава повече от печат за одобрение. Тя записва условия, открити констатации, пропуски в доказателствата, остатъчен риск и необходимото последващо действие. Понякога правилното решение е да се пусне с ограничения. Понякога е да се отложи. Понякога е да се отхвърли предложената употреба. Културата на безопасност не е тази, в която всеки случай минава. Тя е тази, в която решението следва аргумента.

Какво добавя Законът за ИИ към аргумента

Законът за ИИ не превръща всяко внедряване на ИИ в железопътен транспорт. Той установява европейски речник за управление на риска, техническа документация, регистриране, прозрачност, човешки надзор, точност, стабилност и киберсигурност за системите с висок риск. Случаят за безопасност може да помогне на организацията да обедини тези задължения в оперативно обяснение, вместо да третира всеки член като отделна задача за съответствие.

Член 8 обвързва съответствието с предвидената цел и общоприетото състояние на техниката и позволява необходимите изпитвания, докладване, информация и документация да бъдат интегрирани със съществуващите процедури за хармонизация на Съюза, когато даден продукт вече е обхванат от тях. Това е важно за инженерството на безопасността. Той признава, че дадена система може вече да има зрял процес на осигуряване и че дублирането на файлове е по-малко полезно от свързването им. Казусът трябва да покаже къде се намират доказателствата за ИИ в по-широкия аргумент за продукта или услугата.

Член 11 и приложение IV дават на техническото досие широки рамки. То включва предвидената цел, версии, интерфейси, хардуер, методи за разработка, архитектура, произход и характеристики на данните, човешки надзор, предварително определени промени, процедури за валидиране и изпитване, показатели, регистрационни файлове от изпитванията и мерки за киберсигурност. Това не е същото като казус за безопасност, но предоставя много от обектите, от които един казус за безопасност се нуждае. Екипът може да съпостави всеки обект с дадено твърдение и да разкрие какво все още няма собственик или доказателства.

Изискването за регистриране в член 12 е особено практично. Ако една високорискова система трябва технически да позволява автоматично записване на събития през целия си жизнен цикъл, решението за пускане на пазара трябва да постави въпроса какво системата действително може да реконструира. Кой вход, модел, конфигурация, доказателство, извикване на инструмент, човешка намеса и последващо действие могат да бъдат свързани. Кои регистрационни файлове са под контрола на доставчика и кои са на разполагащия. Как са защитени и колко дълго се съхраняват. Може ли засегнато лице или орган да разбере съответния път, без да получи изхвърляне на несвързани лични данни.

Член 15 добавя поглед върху жизнения цикъл на точността, стабилността и киберсигурността, включително устойчивост на грешки, неизправности и несъответствия и, когато е приложимо, резервни планове или планове за безопасно поведение при отказ. Казусът за безопасност дава на тези думи място, където да намерят конкретно приложение. Твърдението не е, че даден резултат е висок. Твърдението е, че системата работи последователно за предвидената си цел, че известните условия на отказ са ограничени и че работният процес има безопасен отговор, когато те настъпят. Доказателствата трябва да посочват условията, при които заключението е валидно.

Задълженията по акта се прилагат според системата, доставчика, разполагащия и употребата. Казусът за безопасност не трябва да създава впечатление, че общ шаблон урежда класификацията или правния съвет. Той трябва да записва решението за приложимост, неговата обосновка и точките, които биха го променили. Това е още едно предимство на изричните допускания. Когато даден факт се промени, организацията знае коя част от аргумента изисква внимание, вместо да преоткрива цялата правна карта в паника.

Авиацията третира ученето като част от осигуряването

Концептуалният документ на Агенцията за авиационна безопасност на Европейския съюз за изкуствения интелект, брой 2, е полезен, защото не описва безопасността на ИИ като единично свойство на модела. Документът прецизира насоките за приложения от ниво 1, които подобряват човешките способности, и задълбочава работата по осигуряване на ученето, обяснимостта на ИИ и оценката, основана на етика. Той също така разглежда системите от ниво 2, при които ИИ може автоматично да взема решения под човешки надзор, и подчертава съвместната работа между човек и ИИ и проектирането на безопасно взаимодействие.

Важната идея не е, че всяка организация трябва да копира авиационната терминология. Тя е, че осигуряването трябва да следва връзката между системата и човешката работа. Модел, който помага на обучен оператор, не е същият проблем за безопасността като модел, който взема решения, докато човек просто осъществява надзор. Способността на оператора да разбира, да се намесва и да се възстановява е част от системата. Същото важи и за границите около ученето, актуализациите и доказателствата. Документът на EASA дава на екипите за ИИ европейски пример за индустрия, която се опитва да направи тези взаимоотношения изрични преди внедряването.

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

Съвместната работа между човек и ИИ също променя значението на надзора. Човекът не е аварийна спирачка, прикрепена към машина, проектирана без водач. Екипът е социотехническа договореност с роли, очаквания, сигнали, правомощия и обучение. Безопасното взаимодействие може да изисква машината да обясни ограничение, да поиска потвърждение, да откаже действие или да направи несигурността видима. Може да изисква човекът да оспори машината и организацията да възнагради това оспорване. Доказателствата трябва да разглеждат самото взаимодействие, а не да се извеждат от едно изречение в политиката.

Отново, не е необходим измислен полет или инцидент, за да се илюстрира тезата. Документът с концепцията на публична агенция е достатъчен, за да покаже, че европейското мислене за безопасност се движи към обучението, човешкото взаимодействие и осигуряването на доверие като единен проблем на проектирането. Екипите за ИИ могат да четат материала като подкана да се запитат какво учи тяхната собствена система, какво може да види операторът и какви доказателства оцеляват при промяна.

Съставна контролна точка за пускане, обозначена като такава

Илюстративна съставна картина, а не описан реален случай: представете си публична служба, която обмисля инструмент с ИИ, помагащ на служителите да организират постъпващите материали по даден случай, преди човек да вземе решението. Инструментът няма право да решава допустимостта, да изпраща уведомление или да приключва случай. Предложеното твърдение за безопасност е тясно: обучени служители могат да използват инструмента, за да подготвят опашка за преглед, когато изходният запис е пълен, панелът с доказателства е видим, препоръката е ясно обозначена като препоръка и служителят може да я отмени, постави на пауза или премахне.

Първият клон на доклада посочва опасностите. Непълен запис би могъл да получи привидно последователен приоритет. Остарял политически документ би могъл да оформи препоръката. Опашката би могла да окаже натиск върху проверяващия да приеме подредбата без проверка. Грешка в правата за достъп би могла да изложи материалите на един човек в друг случай. Актуализация от доставчик би могла да промени значението на дадена категория. Това не са твърдения, че такова събитие се е случило. Те са условия, които екипът разумно може да предвиди от предложения дизайн.

Следващият клон посочва контролите. Пълнотата и актуалността на входните данни се проверяват, преди да се покаже препоръка. Доказателствата, използвани за предложението, са видими до случая. Действието остава чернова, докато обучен човек не го приеме или промени. Липсващ източник насочва елемента по различен път. Правата за достъп се тестват на границата на извличането на данни, а не само на потребителския интерфейс. Работният процес има контрол за пауза и ръчен маршрут. Промяна на версията работи в ограничен режим и може да бъде отменена. Докладът записва защо съществува всеки контрол и коя опасност адресира.

След това доказателствата трябва да проверят контролите. Тест с данни подава непълни и остарели записи и записва резултата. Преглед на използваемостта пита дали служителите могат да намерят доказателствата и да разберат препоръката при реалистично натоварване. Тест за достъп проверява дали даден случай не може да извлече материали извън своя обхват. Репетиция на пускането проверява дали пътищата за пауза и отмяна работят. Преглед на промяната потвърждава, че новата категория и политика не обезсилват логиката на опашката. Това са хипотетични тестове в тази съставна картина, а не доклади за тестове, извършени от посочена служба.

Решението е условно. Инструментът може да се използва за подготовка на опашката в рамките на посочения обхват. Той не може да се използва за вземане или съобщаване на същественото решение. Условието, че персоналът трябва да има правомощия да отмени решението, е възложено на роля. Условието, че свежестта на източника се записва, се наблюдава. Промяна в модела, политиката, договора за данни, потребителската група или последващото действие отваря отново случая. Ако организацията не може да докаже тези условия, вратата за пускане остава затворена. Историята е полезна именно защото никой не трябва да се преструва, че определен град, екип или вторник е съществувал.

Малък пример от нашия Trust Centre

В Dweve нашият публичен Trust Centre прави подобно разграничение в своя запис за оценка. Страницата с оценки представя метод, който идентифицира модела, точния пакет, конфигурацията, записаното състояние, доказателствата и решението на рецензента. Тя разделя идентичността на оценката от променящото се състояние на модела, разграничава подготвеното покритие от действителния резултат и описва повторното изпълнение като договор, който зависи от записания артефакт, графа на изпълнение, маршрутизирането, подредбата, състоянието, ограниченията, инструментите и доказателствата. Страницата също така посочва, че не е съществувал първи външен резултат от пускане към 1 август 2026 г., тъй като това пускане не се е случило.

Това е малък пример, а не доказателство, че е изготвен пълен случай за безопасност за всяка употреба на нашите системи. Неговата стойност е в границата. Методът не е резултат. Категорията не е резултат. Планираното пускане не е историческо изпълнение. Възпроизводимо записано състояние не е същото като жив свят, чиито доказателства и адаптивно състояние са се променили. Именно тези разграничения са необходими на случая за безопасност, когато той посочва къде се прилагат доказателствата и къде спират.

За европейска технологична компания публикуването на такива ограничения може да изглежда като оставяне на полезна маркетингова площ празна. Това е по-полезно, отколкото запълването ѝ с число, което никой не може да защити. Същата дисциплина важи за публичен орган, доставчик, изследователска група или вътрешен екип на платформа. Посочете кои доказателства съществуват, кои са подготвени, кои са защитени, кои не са събрани и кое бъдещо събитие би създало нов резултат. Читателят може тогава да прецени какво подкрепят доказателствата.

Нашият пример също така показва защо Trust Centre трябва да се чете като индекс на доказателствата, а не като обещание. Публичната страница посочва границите на идентичността, метода, записването, прегледа и пускането. Тя не премахва необходимостта от проверка на конкретно внедряване, цел или засегната група. Случаят за безопасност би добавил този местен контекст, опасностите на действителния работен процес и правомощията на лицето, което взема решението. Публичната прозрачност е отправна повърхност, а не универсален сертификат.

Какво може да докаже случаят за безопасност

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

Той може също така да покаже какво е несигурно. Един случай може да демонстрира силни доказателства за една група и ограничени доказателства за друга. Той може да покаже, че системата е устойчива на определен клас неправилно форматирани входни данни, но не и на неизвестен клас. Той може да покаже, че човек може да се намеси, когато персоналът и разрешенията са както е посочено. Той може да покаже, че съществува резервен вариант, но той все още не е изпробван в пълен оперативен мащаб. Един честен случай не скрива тези асиметрии. Той ги превръща в условия за употреба.

Един safety case може да подпомага и решенията за възлагане на поръчки и управлението. Купувачът може да сравни доказателствата, които доставчикът предлага, с доказателствата, от които работният процес се нуждае. Регулаторът може да види кои твърдения са подкрепени и кои записи липсват. Бордът може да разбере къде се намира остатъчният риск и кой го притежава. Операторът може да знае кой сигнал трябва да предизвика пауза. Засегнатите хора могат да имат по-ясен път да оспорят даден резултат. Казусът се превръща в карта на отговорността, а не просто в инженерен артефакт.

Той може да подпомогне промяната, без да се преструва, че промяната е безплатна. Като свързва твърдения, опасности, допускания, контроли и доказателства, организацията може да идентифицира най-малката смислена преоценка, когато даден компонент се промени. Това е по-ефективно от повтарянето на всеки тест на сляпо и по-безопасно от допускането, че не е необходима никаква преоценка. Пропорционалността работи само когато структурата е видима. В противен случай екипът или извършва ритуал, или си позволява съкращения.

Какво един safety case не може да докаже

Един safety case не може да докаже, че никога няма да настъпи вреда. Реалните системи срещат условия, които не са били предвидени, и хората реагират на стимули и натиск по начини, които никоя диаграма не може напълно да предвиди. Целта не е сигурност. Тя е дисциплинирана основа за работа, учене и спиране, когато тази основа вече не е валидна.

Той не може да докаже, че даден модел е общо интелигентен, общо справедлив или безопасен във всяка област. Доказателствата имат обхват. Тест върху един набор от данни не определя резултатите за друг. Успешният преглед в един работен процес не установява същия авторитет в различен. Добре проектираният маршрут за спиране не доказва, че всеки оператор ще го използва без обучение, време или организационна подкрепа. Казусът трябва да устои на изкушението да превърне локалното доказателство в глобално прилагателно.

Той не може да прехвърли отговорността към доставчик, одитор или сертификационен знак. Доказателствата може да са произведени от някой друг, но внедряващият все още има употреба, работен процес и хора, които зависят от резултата. Договорите могат да разпределят задължения и да осигурят достъп. Те не могат да направят организацията неосведомена за системата, която експлоатира. Нито сертификатът може да извини промяна, която измества системата извън оценения обхват.

Той не може да направи забранена или неподходяща употреба приемлива чрез добавяне на документи. Ако опасността не може да бъде контролирана до приемливо ниво, отговорът може да бъде промяна на предназначението или да не се внедрява. Safety cases често се описват като осигуряване на увереност, но най-ценният резултат може да бъде добре подкрепено „не“. Пълен файл все още може да подкрепи лошо решение, ако аргументът е слаб. Смисълът на файла е да направи решението по-добро, а не просто по-четимо, след като е взето.

И накрая, той не може да замени закона, професионалната преценка или демократичната отчетност. Той е инженерен и управленски инструмент. Той трябва да помогне на хората да разберат решението и неговите условия, а не да се преструва, че урежда въпроси, които принадлежат на съдилища, регулатори, клиницисти, публични длъжностни лица или на засегнатите хора.

Въпроси за европейска среща за пускане

Екипът не трябва да чака перфектен стандарт или папка от 400 страници, за да започне. Той може да зададе поредица от ясни въпроси. Какво точно твърдим, че тази система може да прави. Кой е засегнат, когато тя сгреши. Кои опасности са условия в системата и работния процес, а не неясни лоши резултати. Кои допускания трябва да останат верни. Какви доказателства подкрепят всяко твърдение и при каква конфигурация и каква съвкупност от хора. Какво остава несигурно. Кой приема остатъчния риск. Кой може да спре системата. Кое събитие би отворило отново аргумента.

Срещата трябва да остави място за по-неудобен въпрос: какво би ни накарало да откажем пускането. Ако единственият отговор е по-нисък резултат, екипът вероятно не е описал рисковете си. Отказ може да бъде предизвикан от липсващи доказателства, непроверено предположение, неуспешно упражнение за възстановяване, недостъпен рецензент, неограничена интеграция или промяна, която не може да бъде повторена. Назоваването на условията за отказ превръща безопасността от настроение в оперативен контрол.

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

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

И попитайте дали доказателствата могат да бъдат прочетени от хората, чието решение трябва да подкрепят. Технически файл, който никой не може да интерпретира, не е прозрачност. Политика, която никой не може да приложи, не е контрол. Табло, пълно със зелени клетки, което скрива знаменателя, не е успокоение. Европейската практика за безопасност е в най-добрата си форма, когато прави разсъжденията достъпни за човека с отговорност, а не само за човека, който е събрал документа.

Тихото предимство на честния аргумент

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

Европа вече има части от тази дисциплина в своите институции. Железопътният транспорт третира техническата, оперативната и организационната промяна като въпрос на риск и използва общи методи и независима оценка. Авиационните насоки обсъждат гарантиране на ученето, обяснимост и съвместна работа между човек и ИИ. Законът за ИИ съчетава управлението на риска през целия жизнен цикъл с документация, регистри, прозрачност, човешки надзор и производителност през целия жизнен цикъл. Това не са идентични рамки и не трябва да бъдат сведени до един единствен контролен списък. Те обаче споделят уважение към условията, доказателствата и отговорността.

Практическият урок е достатъчно прост, за да го вземете на понеделнишка среща. Започнете с твърдение, което има ръбове. Назовете рисковете, които биха могли да го опровергаят. Запишете предположенията, които му позволяват да стои. Поставете контролите там, където работата действително се случва. Приложете доказателства с идентичност и обхват. Оценявайте остатъчния риск, вместо да го криете. Дайте на човек реална власт да се намеси. Отворете отново аргумента, когато системата или контекстът се промени. Позволете на независимия рецензент да бъде неудобен. Публикувайте ограниченията със същата грижа като успехите.

Този подход няма да направи всяка ИИ система безопасна и няма да превърне несигурността в сигурност. Той ще направи небезопасната увереност по-трудна за поддържане. Той ще даде на операторите път за пауза, на рецензентите нещо конкретно, което да оспорят, и на засегнатите хора по-добро обяснение къде се намира отговорността. Той също така ще улесни подобряването на добрите системи, защото организацията ще може да види коя част от аргумента се е променила.

Следователно случаят за безопасност не е заключителен параграф след инженерната работа. Той е нишката, която свързва целта, дизайна, хората, доказателствата и промяната. Европа може да се поучи от случаите за безопасност, защото те предлагат гражданска версия на инженерната дисциплина: нито един лозунг не се приема без път, нито един път не се приема без доказателства и нито едно доказателство не може да пътува по-далеч от своите допускания.

Източници