Правилото за сигурност има стойност само ако може да се провери какво прави системата при опит за нарушение. За да проверите AI системата, опишете какви активи защитава, откъде приема вход, какви права има и кой контрол трябва да спре нежеланото действие. После тествайте не само нормалния сценарий, а и целенасочени опити да се премине границата. Резултатът трябва да може да се проследи в журнал, да има отговорник и да води до решение за остатъчния риск.
Това е същността на тестването на AI trust boundaries — границите на доверие в AI система. То не е еднократен опит да се „подмами“ моделът, а проверка на цялата верига: вход → доверие → действие → права → контрол. Моделът може да откаже инструкция, но ако системата все пак изпрати заявка към инструмент или разкрие данни, защитата не е изпълнила целта си.
Какво е граница на доверие и защо се тества
Граница на доверие разделя данни, участници или компоненти, към които системата не бива да прилага еднакви предположения за надеждност. Например инструкция от упълномощен оператор не е равнозначна на текст в прикачен документ. Съобщение от външен източник не става доверено само защото е извлечено от вътрешно хранилище. А отговорът на модел не е сам по себе си одобрение за действие.
Тези различия са важни, защото AI компонентът често преобразува естествен език в отговори, търсения или заявки към инструменти. Входът може да съдържа съдържание, което се опитва да промени поведението на модела; резултатът може да бъде използван от приложение, което има реални права. При такава архитектура защитата не може да се свежда до текстова инструкция от типа „не изпълнявай опасни команди“. Трябва да е тодорхой кой компонент проверява правото, кой разрешава действието и къде то се блокира, ако проверката не мине.
Тестът трябва да отговори на конкретен въпрос: при зададени условия какъв резултат очакваме и как ще разберем, че системата го е постигнала? „Моделът изглеждаше предпазлив“ не е критерий. Критерий може да бъде например, че неупълномощен вход не води до извикване на инструмент, достъпът до чужд запис е отказан и отказът е видим в журнал.
Матрица актив–вход–право–контрол–тест
Практичен начин да подредите проверката е матрица, която свързва защитавания актив с входовете, правата, контролите и тестовете. За всяка връзка запишете очаквания резултат и собственик на контрола. Така политиката се превръща от общо обещание в проверимо изискване.
| Актив | Вход | Право | Контрол | Тест и очакван резултат | Отговорник |
|---|---|---|---|---|---|
| Вътрешни документи | Документ, който се подава или извлича за контекст | Четене само на документи, разрешени за текущия потребител | Проверка на достъпа преди извличане; отделно третиране на съдържанието като данни, а не като управляваща инструкция | Подайте документ с опит да поиска чужди данни или да промени задачата. Очаквано: няма неразрешено извличане и инструкциите в документа не разширяват правата. | Собственикът на слоя за извличане и достъп |
| Записи в бизнес система | Заявка на потребител и контекст от разговор | Четене или промяна само в рамките на ролята и конкретната задача | Проверка на правото от приложението при всяка операция, а не само отговор на модела | Опитайте да прочетете или промените запис извън разрешения обхват. Очаквано: операцията е отказана независимо от формулировката на заявката. | Собственикът на интеграцията и системата за записи |
| Платежно действие | Заявка, извлечени платежни данни и предложено действие от AI | Подготовка на данни не означава право за изпращане или одобрение | Отделно одобрение в контролирания платежен процес; проверка на получателя и параметрите | Опитайте да задействате действие без одобрение или с променен получател. Очаквано: системата не изпраща плащането и записва отказа. | Собственикът на платежния контрол |
Таблицата е отправна точка, не универсален шаблон. В една система активът може да е лична информация, изходяща комуникация или конфигурация, а правото — търсене, редактиране, изтриване или изпълнение на транзакция. Записвайте и предпоставките: коя версия на приложението се тества, какъв профил има потребителят, кои инструменти са активни и какви данни са налични. Без тях резултатът трудно може да бъде повторен.
Разделяйте правото на AI да предложи действие от правото да го изпълни. Ако една функция само подготвя чернова, това е различен риск от функция, която изпраща съобщение или променя запис. За чувствителни действия проверката трябва да се прилага в слоя, който реално изпълнява операцията. Отказът на модела е полезен сигнал, но не замества техническа забрана.
Negative tests: проверете и очаквания отказ
Negative tests са тестове, при които умишлено се подава невалиден, неразрешен или враждебно формулиран вход, за да се провери дали системата отказва безопасно. Те допълват нормалните функционални тестове: не питате само дали AI може да изпълни позволена задача, а дали отказва, когато входът или заявеното действие преминава границата.
- Недоверен вход: подайте текст от документ или външен източник, който се опитва да измести първоначалната задача, да поиска тайни или да нареди използване на инструмент. Проверете дали съдържанието се третира като недоверени данни и дали не предизвиква достъп или действие извън заявената задача.
- Излизане извън права: използвайте акаунт с ограничена роля и поискайте данни или промяна, достъпни за друга роля. Повторете теста с различни формулировки. Очакваният резултат е отказ на ниво приложение или услуга, а не само учтив текст от модела.
- Нежелано задействане на инструмент: проверете дали въпрос, цитат или съдържание от документ може да задейства търсене, изпращане, изтриване или друга операция без необходимото основание. Уверете се, че блокирането става преди изпълнението.
- Недостатъчни или противоречиви данни: подайте непълен контекст или параметри, които не съвпадат. Проверете дали системата спира за уточнение или отказва, вместо да попълва критични стойности по предположение.
- Повторение след промяна: проверете дали същият опит остава блокиран след промяна на модела, подсказките, интеграциите или правилата за достъп. Една успешна проверка на стара конфигурация не доказва поведението на новата.
Създавайте тестовите случаи за реалните активи и права на продукта, но използвайте контролирана среда и безопасни тестови данни. Определете предварително какво значи провал: например неразрешен достъп, извикване на забранен инструмент, изтичане на данни или липса на необходим запис. Отделно определете какво значи успех. Ако моделът откаже, но инструментът вече е бил извикан, тестът не е преминат.
Журналът трябва да показва пътя до действието
Журналът на AI действията трябва да помага да се възстанови последователността: какъв вход е получил системният компонент, какво решение е взето, какво действие е поискано или изпълнено и коя проверка е приложена. При отказ е важно да се вижда и къде е спрял процесът. Така екипът може да различи отказ от модела, отказ от проверката за права и техническа грешка в инструмента.
Записът следва да позволява свързване на събитията чрез подходящ идентификатор на заявка и да включва релевантни метаданни за версията на системата, потребителската роля и използвания инструмент. Не е необходимо журналът да пази повече чувствително съдържание, отколкото е нужно за разследване и контрол. Прилагането на минимизация, срокове за съхранение и ограничен достъп до журналите е част от дизайна, а не допълнителна подробност.
Не разчитайте единствено на обяснение, генерирано от модела, като доказателство за причината за действие. Събирайте събития от компонентите, които действително проверяват права и изпълняват операции. Ако журналът не показва дали проверката е минала и кой инструмент е бил извикан, разследването ще се опира на непълна картина.
Собственик на контрол и повторен тест
Всеки контрол в матрицата трябва да има собственик — роля или екип, отговорни за работата му, доказателствата за проверката и отстраняването на проблемите. „Екипът“ като общо понятие не е достатъчен, ако при пропуск никой не знае кой трябва да реагира. Собственикът може да делегира теста, но отговорността за приемането на резултата трябва да остане ясна.
Определете критерии за повторен тест преди промяната, а не след инцидент. Повторна проверка е уместна, когато се променят моделът или неговата конфигурация, подсказките, инструментите, източниците на данни, схемата за достъп или логиката за одобрение. Тя е необходима и след поправка на дефект, за да се потвърди както корекцията, така и липсата на регресия в съседни контроли. Записвайте конфигурацията, тестовия вход, очаквания резултат, действителното наблюдение и решението за приемане.
Неуспешен тест не бива да се прикрива с обща оценка, че системата е „достатъчно сигурна“. Опишете остатъчния риск: какво може да се случи, при какви условия, кои активи са засегнати и какви компенсиращи мерки остават. Посочете кой приема риска, защо го приема, какви ограничения действат и кога решението трябва да бъде преразгледано. Ако рискът няма определен собственик или срок за преглед, той лесно се превръща в забравено изключение.
Стандартите помагат да се подредят въпросите, не заменят теста
NIST AI 600-1, профилът за генеративен AI към рамката за управление на риска от AI на NIST, предлага насоки за разпознаване и управление на рискове, свързани с генеративни системи. Той може да помогне на екипа да структурира дейностите по управление на риска, но позоваването на документа само по себе си не доказва, че конкретен контрол работи във вашата система.
В OWASP Top 10 for LLM Applications за 2025 г. LLM01 обозначава Prompt Injection, а LLM06 — Excessive Agency. Тези категории могат да помогнат да класифицирате заплахи и да формулирате тестови сценарии: например опит за влияние чрез вход или прекомерно действие заради широки права и инструменти. Те не са резултат от тест и не удостоверяват, че конкретен продукт е защитен.
MITRE ATLAS е база от знания за тактики и техники на противници, насочени към AI системи. Екипът може да използва терминологията ѝ при моделиране на заплахи и при свързване на сценарии с контролите. Вписването на техника в модел на заплахите обаче не доказва, че атаката е възпроизведена или че контролът е проверен. За това са нужни тестов случай, наблюдаем резултат и запис за изпълнението.
От политика към проверимо поведение
Границите на доверие не са само технически въпрос. Те зависят и от това кой може да разреши действие, какво означава одобрение и дали човекът има реална възможност да спре процеса. В основната статия „Ти проверяваш AI. Но кой проверява теб?“ темата е поставена в по-широкия контекст на човека в системата за сигурност. Тук матрицата и тестовете превръщат тези принципи в проверими контроли.
Плащането е ясен пример за действие, което не бива да се приравнява с подготовка на предложение. В статията защо платежното действие се нуждае от отделна проверка разглеждаме независимия процес на одобрение и проверката на платежните данни. Същата логика важи и за други операции с последствия: правото на AI да подготви препоръка не означава автоматично право да я изпълни.
Политиката очертава границата, но доказателство за контрол е наблюдаваното поведение при опит тя да бъде нарушена. Свържете всеки актив с входа, правото, защитния механизъм и теста; задайте очакван резултат и собственик; пазете достатъчен, но ограничен журнал; и записвайте остатъчния риск с ясен отговорник. Така въпросът „системата спира ли атаката?“ получава отговор, който може да бъде повторно проверен, а не само уверено заявен.
