Що ми перевіряємо перед запуском ШІ-агента

Кожен ШІ-агент, якого ми запускаємо, отримує доступ до чогось, що варто захищати, — календаря, CRM, іноді медичної картки пацієнта. У галузі багато говорять про те, що ШІ-агенти вміють робити, і дуже мало — про те, що вони бачать і що станеться, якщо цим доступом зловживуть, якщо дані витечуть або якщо доступ із першого дня просто ширший, ніж потрібно.

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

Три перевірки перед запуском.

Перша — доступ. Ми точно визначаємо, що агент може читати й записувати, а потім обмежуємо це до мінімуму, який йому справді потрібен: жоден агент не отримує постійного доступу до всієї бази даних, якщо він використовує лише три поля. Надмірні права доступу — один із найпоширеніших висновків перевірок агентів, які ми проводимо, зокрема й перевірок наших власних агентів.

Друга — зловживання. Ми проганяємо агента через ті самі спроби промпт-ін’єкцій і джейлбрейку, які застосував би зловмисник: приховані інструкції всередині повідомлення, спроби змусити його викликати інструменти, яких він не повинен викликати, спроби витягти його системний промпт або контекст. Усе, що спрацьовує, ми виправляємо до запуску, а не після того, як це виявить клієнт.

Третя — управління. Ми перевіряємо впровадження на відповідність стандартам, які стають реальною планкою в цій сфері, — ISO/IEC 42001, NIST AI RMF і вимогам EU AI Act до використання з вищим рівнем ризику. Не тому, що поставлена галочка добре виглядає, а тому, що регулятор або служба безпеки корпоративного клієнта рано чи пізно запитає, а «ми про це не думали» — не та відповідь, яку ми готові дати.

Нічого з цього не є нашою унікальною практикою — це має бути стандартом для кожного, хто запускає агента з реальним доступом. Цим часто нехтують, бо це сповільнює демо. Ми вважаємо, що альтернатива гірша.