По изискване
Регламентът за ИИ назовава атаките. Някой трябва да тества за тях.
Член 15 изисква високорисковите системи с ИИ да бъдат устойчиви на определени атаки — отравяне на данните, отравяне на модела, състезателни примери и атаки срещу поверителността. Той ги назовава. Не казва кой демонстрира тази устойчивост, нито как.
Какво изисква
Какво всъщност казва член 15
Член 15(1) изисква високорисковите системи с ИИ да бъдат проектирани и разработени така, че да постигат подходящо ниво на точност, устойчивост и киберсигурност и да се представят последователно в тези отношения през целия си жизнен цикъл. Задължението е на доставчика и е задължение за проектиране и разработка, а не еднократен тест накрая.
Член 15(5) е този, който се чете като обхват за тестване. Високорисковите системи с ИИ трябва да бъдат устойчиви на опити от страна на неоправомощени трети лица да променят тяхната употреба, резултати или производителност, като използват уязвимости на системата. След това текстът назовава класовете атаки, които има предвид: отравяне на данните, което манипулира данните за обучение; отравяне на модела, което компрометира предварително обучени компоненти; състезателни примери или заобикаляне на модела, които са входни данни, създадени да предизвикат грешка; и атаки срещу поверителността или дефекти на модела. Това е необичайно конкретен списък за регламент и е много далеч от обикновения тест за проникване на приложение.
Член 15(4) обхваща устойчивостта по-широко: системите трябва да бъдат възможно най-устойчиви на грешки, неизправности и несъответствия, включително такива, възникващи при взаимодействие с хора или други системи. За системите, които продължават да се обучават след внедряване, той изисква рискът от пристрастни резултати, които се връщат във входните данни, да бъде отстранен или намален, доколкото е възможно.
Чл. 15(1) – Точност, устойчивост и киберсигурност
Високорисковите системи с ИИ трябва да постигат подходящо ниво на точност, устойчивост и киберсигурност и да се представят последователно в тези отношения през целия си жизнен цикъл. Задължение за проектиране и разработка на доставчика, а не сертификат, получен веднъж.
Чл. 15(4) – Устойчивост на грешки и обратни връзки
Устойчивост на грешки, неизправности и несъответствия, включително произтичащи от взаимодействие с физически лица или други системи. Системите, които продължават да се обучават след внедряване, трябва да намаляват, доколкото е възможно, риска от пристрастни резултати, влияещи върху бъдещите входни данни.
Чл. 15(5) – Устойчивост на атаки
Устойчивост срещу неоправомощени трети лица, които променят употребата, резултатите или производителността на системата, като използват уязвимости. Текстът назовава отравяне на данните, отравяне на модела, състезателни примери или заобикаляне на модела и атаки срещу поверителността или дефекти на модела.
Чл. 50 – Задължения за прозрачност
Отделни от член 15 и вече приложими: оповестяване, когато хора взаимодействат пряко със система с ИИ, маркиране на синтетично съдържание и оповестяване при разпознаване на емоции, биометрично категоризиране и дийпфейкове.
Приложение III – Кои системи са високорискови
Биометрия, критична инфраструктура, образование, заетост, основни услуги, правоприлагане, миграция и убежище и правораздаване. Омнибусът за ИИ остави същността на Приложение III непроменена и не добави нови категории.
Глава V – Модели с общо предназначение
Отделен набор от задължения за доставчиците на модели с общо предназначение, приложим от 2 август 2025 г., с по-късна дата за съответствие за моделите, вече пуснати на пазара преди това.
Какво да се тества
Какво означава това за един обхват на тестване
Административната повърхност на ИИ
Проверяваме кой може да променя конфигурацията на промптите, да достъпва данните за вход в хранилища, да управлява модели или да задейства зареждане на данни. Неправомерният административен достъп може да позволи промяна на поведението на системата без манипулиране на входните данни.
Обучение и зареждане на данни
Проверяваме каква информация може да попадне в набора от данни, кой може да задейства ново обучение и дали зареден документ може да промени поведението на системата чрез вградени инструкции.
Злонамерени входни данни и заобикаляне на модела
Тестваме внедрената система със специално подготвени входни данни. Оценяваме реалното въздействие върху данните и действията, вместо да отчитаме само нежелан отговор от модела.
Поверителност на данните и модела
Дали потребителите на една клиентска организация могат да достъпват разговорите, документите, векторните представяния или генерираните файлове на друга. Проверяваме и дали моделът или свързаните услуги разкриват данни за обучение, системни инструкции или дефиниции на инструменти.
Какво получавате
Какво ще иска да види едно оценяване на съответствието и какво предоставяме ние
Констатации, съотнесени към назованите класове атаки
Доклад, който съотнася констатациите към атаките, назовани в член 15(5), за да може проверяващият да види, че всяка е била разгледана, а не изведена от общ тест на приложение.
Доказателства и път за възпроизвеждане за всяка констатация
С конкретна корекция, във вид, по който инженер може да действа и който проверяващ може да проследи.
Заявен обхват и заявени изключения
Твърдение за устойчивост без неговата граница не е твърдение за устойчивост. Изключеното е записано, както и какво означава то за увереността.
Повторен тест, потвърден писмено
Потвърждаващ какво е отстранено и закрито — частта, която превръща списък с констатации в доказуемо подобрение.
Чести капани
Къде това се обърква
Грешки, които струват време при одит, и как да ги избегнете.
Допускането, че тест за проникване на приложение покрива член 15
Не го покрива. Отравянето, заобикалянето и поверителността на модела не са в стандартна методология за уеб или API, а доклад, който никога не ги споменава, няма да се чете като доказателство за устойчивост по член 15.
Третиране на инжектирането на промпти като цялата работа
Инжектирането е в обхвата, но член 15(5) е за промяна на употребата, резултатите или производителността чрез използване на уязвимости — а на практика административната повърхност около модела е по-кратък път от самия модел.
Работа по стария срок
Омнибусът за ИИ, в сила от 27 юли 2026 г., премести високорисковите задължения по Приложение III на 2 декември 2027 г. Голяма част от публикуваните насоки все още показват първоначалната дата август 2026 г.
Очакването докладът от теста да е оценяване на съответствието
Той не е и никоя фирма за тестване не може да издаде такова. Докладът осигурява доказателства за процес, който се провежда от друга страна.
Кой решава какво се приема
PXLSec е независима фирма за офанзивна сигурност, а не одитор, оценител, сертифициращ орган или регулатор. Ние извършваме тестването и осигуряваме доказателствата; вашият одитор, оценител или компетентен орган решава какво приема. Тази страница е обща насока, а не правен съвет.
Често задавани въпроси
Често задавани въпроси
Прави ли ни тестът за проникване съответстващи на Регламента за ИИ?
Не. Съответствието е процес по оценяване на съответствието, а тестването осигурява част от необходимите доказателства. Ние предоставяме доказателства за сигурността на вашата система: какво може да направи нападател с нейните резултати, пътя на данните и административната ѝ повърхност, с доказателствата и корекциите. Който провежда вашето оценяване на съответствието, решава какво приема. Ние сме фирма за тестване, а не нотифициран орган, одитор или сертифициращ орган.
Високорискова ли е нашата система с ИИ?
Това е правна преценка за вашия случай на употреба, а не техническа, и зависи от Приложение III и от това дали системата е компонент за безопасност на регулиран продукт. Ние не правим тази преценка и не бива да я приемате от фирма за тестване. Ако сте високорискови, член 15 се прилага; ако не сте, атаките, които той назовава, пак са онези, които ще бъдат използвани срещу вас.
Срокът е отложен — нужно ли е да действаме сега?
Задълженията за високорисковите системи по Приложение III се прилагат от 2 декември 2027 г. Отлагането не премахва текущите рискове. Ако AI функционалността вече работи в продукционна среда, проверете защитата ѝ според реалния достъп до данни и действия.
Използваме модел на трета страна. В обхвата ли е?
Моделът, който извиквате, не е ваш, за да разрешите тестване срещу него, и всеки, който предлага да тества чужд хостван модел, не може законно да го достави. В обхвата е всичко, което сте изградили около него: конфигурацията на промптите, данните, които му подавате, инструментите, които позволявате на агент да извиква, изолацията между вашите клиентски организации и това кой може да променя което и да е от тях.
Тествате ли за пристрастност или съответствие на поведението?
Не, и предпочитаме да го кажем, отколкото да поемем работата. Оценката на пристрастност, токсичност и съответствие на поведението е друга дисциплина с други методи и други хора. Ние тестваме сигурност: дали някой може да промени употребата, резултатите или производителността на системата, като я експлоатира. Член 15 покрива както точността, така и киберсигурността; ние сме от страната на киберсигурността.
Можете ли да съотнесете констатациите към член 15 вместо нас?
Да. Когато изискване води ангажимента, определяме обхвата спрямо приложимата разпоредба и пишем доклада така, че да може да бъде предаден както е, с констатации, съотнесени към класовете атаки, които текстът назовава. Това съотнасяне извършваме ние като специалисти по тестване; преценката дали то удовлетворява вашето задължение — не е.
Услуги, които осигуряват това
Нека обсъдим обхвата на теста.
Кажете ни какво искате да защитите. Опитен специалист ще ви помогне да определите обхвата и следващите стъпки. Обикновено отговаряме в рамките на един работен ден.
Поверителност от първия разговор
Можем да подпишем вашето NDA, преди да споделите чувствителни детайли. За запитването ви се прилага политиката ни за поверителност.
Как защитаваме информацията ви · Политика за поверителност