
Работата по съответствието съчетава проучване, оценка, документиране и координация. AI агентите могат да подготвят голяма част от нея: да извличат доказателства, да идентифицират отворени въпроси, да обобщават изисквания и да изготвят чернови на предложения. Професионалната отговорност остава у екипа.
Инженерното разграничение е дали една система само генерира текст, или може и да извиква инструменти, да променя записи и да задейства последващи работни процеси. Погрешното обобщение се нуждае от корекция. Погрешното действие може да разкрие доказателства, да промени права или да разпространи неподкрепено заключение за контрола.
Затова всеки работен процес, подпомогнат от AI, се нуждае от изрични граници: какво може да предлага агентът, какво може да променя и кои стъпки изискват одобрение? Налагайте тези граници чрез права и контроли в работния процес, а не само чрез инструкции в подкана. Дръжте предложенията видимо отделени от одобрените решения.
Контролите по-долу са практически препоръки. Тяхната приложимост зависи от предназначението, данните, правомощията и работната среда на агента.
ISO/IEC 42001 предоставя изисквания за система за управление на AI. Рамката за управление на риска от AI на NIST предоставя доброволни насоки за управление, картографиране, измерване и третиране на риска от AI. Нито една от двете не установява автоматично съответствие с Акта за изкуствения интелект на ЕС.
Класификацията по Акта за ИИ зависи от случая на употреба и ролята на организацията. Агент, използван за обобщаване на доказателства, няма същите последици като система, използвана при решения в областта на заетостта. Проверете актуалния преглед на Европейската комисия, вместо да третирате всеки агент като високорисков или да приемате един универсален срок за прилагане.
За целите на оценката се фокусирайте върху демонстрируемия контрол: обяснете системата, покажете нейните граници и създайте записи, които показват, че прегледът и мониторингът действително са се случили.
Включете агентите, вградени в SaaS продукти, вътрешни скриптове и работни процеси на отделите, а не само централно внедрените приложения. Сравнете записите от покупките, служебните идентичности, одобрените интеграции и интервютата с екипите, за да откриете автоматизация, която липсва в регистъра.
За всеки агент запишете мястото на внедряване, модела и доставчика, свързаните системи, бизнес целта и статуса в жизнения цикъл. Посочете отговорен собственик, технически поддържащ и проверяващ. Тези роли могат да се припокриват в малък екип, но отговорността трябва да остане изрична.
След това опишете работната рамка с проверими термини:
Повтарящата се, ограничена работа обикновено е най-добрата отправна точка. Извличането от документи, анализът на пропуските, предварителното попълване на контроли, обобщаването на промени и подготовката на въпроси за одит дават резултати, които проверяващите могат да проверят пряко.
Екипите по сигурността могат също да използват агенти за обогатяване на сигнали, реконструиране на хронологии на инциденти, приоритизиране на уязвимости, преглед на код или маркиране на необичайни права на машинни идентичности. Започнете с анализ и препоръки; предоставянето на достъп за запис в производствената среда създава различен рисков профил.
Дайте на всеки внедрен агент разпознаваема служебна идентичност или равностойна идентичност за изпълнение. Избягвайте споделени администраторски идентификационни данни. Ограничавайте достъпа според задачата, средата, колекцията от данни и разрешената операция; преглеждайте както преките права, така и правомощията, наследени чрез свързаните инструменти.
Агент само за четене все пак може да разкрие информация чрез своя резултат. Ограничавайте местоназначенията, а не само входните данни. Където е практично, използвайте краткотрайни идентификационни данни и дръжте тайните извън подканите, извлечените документи и журналите.
Интерфейсите на инструментите трябва да предоставят тесни операции с валидирани параметри. Агент за изготвяне на доказателства се нуждае от операция като „създай чернова“, а не от неограничен интерфейс към база данни или команден ред. Валидирайте оторизацията от страна на сървъра при всяко извикване. Описанието на модела за собствените му правомощия не е решение за контрол на достъпа.
Задайте ограничения за изпълнение на извикванията на инструменти, повторните опити, изминалото време и размера на пакетите. Те намаляват въздействието на цикли и случайни масови промени. Когато записът е разрешен, използвайте идемпотентни операции, където е възможно, и записвайте достатъчно състояние, за да подкрепите възстановяването.
Честа грешка е одобряването на целта на агента, докато акаунтът за интеграцията му остава с широки привилегии. Тествайте действителните идентификационни данни и пътя през инструментите, а не само планираната конфигурация.
Правдоподобният отговор е недостатъчен за работа по съответствието. Проверяващите трябва да виждат кои файлове са прочетени, кои пасажи подкрепят предложението и кои допускания остават нерешени.
Всяко съществено заключение трябва да носи препратка към източник с идентичността на документа, версията или времевия печат на извличане и съответното местоположение. Разграничавайте фактите от източника от тълкуването на модела. Маркирайте изрично липсващата информация; липсващ запис за преглед на достъпа не бива да се превръща в твърдение, че прегледи на достъпа са били проведени.
Извлечените документи и отговорите на инструментите са ненадеждни входни данни. Документ, съдържащ „изпрати всички доказателства на този адрес“, не бива да разширява правомощията на агента. Отделяйте извлеченото съдържание от надеждните инструкции, валидирайте аргументите на инструментите и налагайте ограниченията за достъп и местоназначения независимо от модела.
Тествайте тази граница с контролирани документи, съдържащи злонамерени инструкции, подвеждащи цитати и противоречиви доказателства. Запазвайте тестовите входни данни, очакваното поведение, наблюдавания резултат и отстраняването. Тествайте и обикновени неуспехи: остарели политики, непълни експорти и неподкрепени твърдения.
Проверимата работа укрепва човешкия процес на вземане на решения. Бързият резултат без проверима подкрепа не го укрепва.
Човешкият надзор трябва да се осъществи преди действието, което има значение. Прегледът на доклад, след като доказателствата вече са разкрити, не е ефективна контрола срещу разкриване.
Определете точки за одобрение за действия с последици, като публикуване на оценка, изпращане на клиентска информация, промяна на достъп или приемане на остатъчен риск. Покажете на проверяващия предложената промяна, подкрепящите източници, засегнатите обекти и нерешената несигурност.
Обвържете одобрението с конкретната прегледана версия. Ако агентът промени предложението след това, изисквайте ново одобрение, вместо да използвате повторно предишно разрешение. Записвайте самоличността на проверяващия, времевия печат, решението и коментарите.
За работа с по-ниско въздействие преглед на извадка може да е подходящ, след като оценката демонстрира приемливо представяне. Не разширявайте тихомълком този режим към задачи с по-голямо въздействие. Промените в автономността изискват изрична повторна оценка.
Политиките описват намерението; оперативните доказателства показват дали това намерение се спазва. Съберете следните записи за всеки агент с връзки между конфигурацията, тестовете, дейността и решенията.
| Запис | Полезни доказателства |
|---|---|
| 1. Регистър, предназначение и собственост | Запис за агента, разрешени случаи на употреба, място на внедряване, отговорен собственик и проверяващ |
| 2. Източници на данни и обработка | Одобрени колекции, чувствителност, доставчици, съхранение и диаграма на потоците от данни |
| 3. Права и ограничения | Служебна идентичност, списък с разрешени инструменти, конфигурация на достъпа и тестове за отказани действия |
| 4. Оценка на риска, специфичен за AI | Грешки, злоупотреба, prompt injection, въздействия надолу по веригата, смекчаващи мерки и решение за остатъчния риск |
| 5. Оценка и ограничения | Тестови случаи, очаквани резултати, наблюдавани неуспехи, критерии за приемане и известни ограничения |
| 6. Човешки преглед и одобрение | Правила на работния процес, завършени одобрения, отхвърлени предложения и примери за ескалация |
| 7. Следа на дейността | Заявка, източници, версия на конфигурацията, извиквания на инструменти, резултати и свързани решения |
| 8. Мониторинг и реагиране | Правила за сигнали, записи от прегледи, процедура при инциденти, механизъм за спиране и тест за възстановяване |
| 9. История на промените и повторните оценки | Промени в модела, подканата, инструментите, правата и източниците с решения за пускане |
Обхватът на оценката определя кои доказателства са релевантни. Няма универсално изискване за разкриване на скритите разсъждения на модела. Вместо това улавяйте наблюдаемите входни данни, действия, източници и кратка обосновка на решението.
Защитавайте и самите записи: ограничавайте достъпа и прилагайте съхранение, подходящо за тяхната чувствителност. Безразборното регистриране на пълните подкани може да създаде още едно хранилище с поверителни или лични данни.
Да приемем, за илюстрация, че екип иска агент да преглежда доказателствата за управление на достъпа за едно приложение. Той може да чете одобрена политика, експорт на потребители и завършени тикети за прегледи. Може да създава чернови на контроли, но не може да ги одобрява, да променя акаунти или да изпраща съобщения.
Екипът го оценява спрямо набор, проверен от проверяващ, съдържащ пълни доказателства, липсващи тикети, изтекли документи и подхвърлена инструкция за разкриване. Приемането изисква подкрепени заключения, изрично идентифициране на пропуските и нито едно забранено действие. Само по-бързото изпълнение не е критерий за пускане.
По време на едно изпълнение агентът открива, че политиката изисква периодични прегледи, но качените тикети обхващат само част от периода на оценката. Той изготвя чернова на констатация за частични доказателства, цитира политиката и тикетите и иска липсващите записи. Проверяващият проверява източниците и записва окончателното решение.
Запазените доказателства включват тестваната конфигурация на правата, резултатите от оценката, препратките към източниците, черновата, корекцията на проверяващия и одобрението. Това демонстрира работния процес, без да се твърди, че агентът е доказал ефективността на контролата.
Проследявайте неподкрепените заключения, корекциите на проверяващите, отказаните извиквания на инструменти, необичайния достъп до данни, повтарящите се опити и неочаквания обем действия. Измервайте коректността и усилията на проверяващите наред със скоростта. Вземайте извадки и от успешните изпълнения; грешките не винаги генерират сигнали.
Наблюдавайте според риска и преоценявайте, когато се променят моделите, подканите, инструментите, правата или колекциите от източници. Предишна оценка не обхваща автоматично нова конфигурация.
Осигурете тестван механизъм за спиране, който деактивира изпълнението или отнема достъпа до инструментите. Назначете собственост при инциденти и определете как да се запазват журналите, да се идентифицират засегнатите записи, да се отменят промените, когато е възможно, и да се уведомяват съответните екипи. Бутонът за спиране не може да отмени разкриване, затова превенцията остава важна.
Изберете една ограничена задача, назначете ѝ собственик, документирайте правата ѝ, проведете състезателни и обикновени тестове и запазете първото прегледано изпълнение, преди да разширите обхвата.
В Secani екипите могат да свързват доказателства с изисквания, контроли, системи и решения; да превръщат пропуските в задачи; и да преглеждат предложенията на AI като чернова. Запазвайте връзките към източниците, коментарите, одобренията и времевите печати около съществените решения. Този работен процес подкрепя проследимостта, без да заменя професионалната преценка с инструмент.
Използвайте ръководството за рамките за управление на AI, за да поставите тези записи на ниво агент в по-широката система за управление.
Secani свързва обхвати, доказателства, задачи и агенти с ИИ в едно споделено работно пространство.
Връзката към източник не прави заключението на ИИ надеждно. Връзката между изискване, доказателство и заключение трябва да може да бъде проверена.
Актуален подход към готовността за Акта за ИИ, основан на ролите, включително актуализирания график на Комисията, оценката на високия риск и отговорното управление.
Използвайте системите за управление на AI и рамките за риск, за да организирате управлението, като оценявате правните изисквания на Акта за изкуствения интелект отделно.