Захисні механізми корпоративного ШІ можуть бути важливішими за передові моделі

Забудьте про гонитву за передовими моделями ШІ. Клієнти вимагають від підприємств запроваджувати більше захисних механізмів для ШІ, який уже використовують, а досвід застосування PCI DSS може стати корисним прикладом.

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

Подальші кроки ще обговорюють, але регулятори вже діють. Закон Європейського Союзу про штучний інтелект поетапно запроваджує зобов’язання щодо безпеки, зокрема відповідальність покупців. У Сполучених Штатах рамкова система NIST з управління ризиками ШІ стає стандартом належної обачності. У всьому світі OWASP Top 10 для застосунків на основі великих мовних моделей став поширеним орієнтиром під час перевірок безпеки, а сертифікація ISO/IEC 42001 з’являється в документах із закупівель.

Отже, відповідальність лежить не лише на розробниках моделей. Зобов’язання щодо безпеки та пов’язані з нею ризики стосуються також підприємств, які використовують уже випущені моделі, особливо в сценаріях із високим рівнем ризику. Неправильні відповіді в анкеті клієнта з питань безпеки або в пропозиції у відповідь на запит надання пропозицій (RFP) можуть загальмувати укладення угоди між компаніями.

PCI DSS показує шлях

На щастя, ми вже бачили подібний сценарій. Двадцять років тому безпека вебзастосунків здебільшого залежала від періодичних перевірок коду, статичного аналізу та дисциплінованості розробників. Згодом вимога 6.6 стандарту PCI DSS, опублікована у 2006 році й запроваджена з 2008 року, зобов’язала організації, що працюють із даними власників платіжних карток, або перевіряти весь код застосунків на вразливості, або встановлювати автоматизовані технічні засоби контролю. Пізніше можливість обмежитися перевіркою коду скасували, і технічні засоби контролю стали обов’язковими.

Однак PCI DSS спочатку не був законом. Він виник як договірний стандарт, що змінив ринок, і, ймовірно, зробив це швидше, ніж змогло б законодавство, адже договори укладають швидше, ніж ухвалюють державні закони.

Так само зараз організації відчувають тиск, який спонукає запроваджувати захисні механізми для розгорнутого ШІ. Ідеться не про вимоги регуляторів, а про вимоги клієнтів і партнерів, що містяться в анкетах із питань безпеки, умовах запитів на надання пропозицій (RFP) та вимогах страхових полісів.

Розв’яжіть операційну проблему — і вимоги відповідності буде виконано

На цей тиск буває складно відповісти, адже управління ШІ — це не лише політика. Воно також передбачає постійне отримання технічних доказів.

Багато підприємств, із якими я спілкуюся, використовують у робочому середовищі пів дюжини моделей або більше й часто поєднують їх у ланцюжки чи оркеструють так, щоб результат роботи однієї моделі ставав вхідними даними для іншої. Уявіть, як за таких умов продемонструвати системне дотримання будь-якої політики — наприклад, не допускати появи персональних даних (PII) у результатах роботи моделі. Ручний аудит багатьох моделей, кожну з яких налаштовано окремо, забирає час розробників. До того ж більшість організацій не можуть належно впоратися з несанкціонованим і високоризиковим використанням ШІ: наприклад, коли працівники вставляють конфіденційні дані в споживчі інструменти ШІ або постачальники SaaS непомітно вмикають нові функції ШІ. Водночас уся відповідальність лежить на підприємстві.

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

Перенесіть безпеку на шлях інференсу

Ця дія і є точкою застосування засобів контролю — саме такі точки фахівці з безпеки застосунків створюють для трафіку застосунків уже 20 років. Особливо коли інференс проходить через спільну інфраструктуру, шлях інференсу стає ідеальною точкою контролю для різних моделей і навіть для несанкціонованого використання ШІ. Трафік інференсу ШІ потрібно передавати, перевіряти, автентифікувати й контролювати так само, як будь-яку іншу важливу взаємодію із застосунком, зважаючи на джерело трафіку та його призначення. На відміну від ручного аудиту, управління трафіком інференсу можна масштабувати.

З чого почати

З огляду на напрям розвитку регулювання організаціям уже зараз потрібно розпочати три роботи:

1. Визначте зону своєї відповідальності: від API SaaS і розміщених кінцевих точок до тіньового ШІ.
2. Відокремте політику безпеки та її застосування від моделей і перенесіть їх на шлях інференсу.
3. Забезпечте створення журналів аудиту поза контролем моделей і агентів, які, як було доведено, намагаються змінювати записи про власні дії.

Вимоги до належного моніторингу та застосування засобів контролю ще визначаються, але ваші команди з операційної діяльності та безпеки підприємства знають, що справді можна забезпечити, скільки коштують засоби контролю з погляду затримок і складності та коли доброзичливе правило може призвести до небажаного результату. Залучіть їх уже зараз. Ризики для безпеки та зобов’язання, пов’язані з використанням ШІ, реальні, і ваші клієнти та керівники, безсумнівно, більше переймаються тими, з якими стикаються сьогодні, ніж загрозами від передових моделей майбутнього.