Три приховані ризики у вашому стеку AI і що з ними робити

Три приховані ризики у вашому стеку AI і що з ними робити

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

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

Темпи впровадження ШІ випереджають темпи управління. Дані Wiz показують, що 75% організацій зараз використовують моделі штучного інтелекту, які розміщуються самостійно. Подібна кількість розгорнула виділені стеки AI/ML. У хмарних середовищах OpenAI все ще домінує в усьому світі, але нові платформи, такі як DeepSeek, набирають обертів. Коли DeepSeek-R1 був запущений на початку цього року, його використання зросло втричі всього за два тижні, що є ознакою того, як швидко змінюються переваги та платформи.

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

Shadow AI: невидима загроза


Різні команди у вашому бізнесі, швидше за все, створюють інструменти штучного інтелекту без залучення служби безпеки чи ІТ-команд. Іноді несвідомо, іноді, щоб уникнути тертя. Незалежно від того, чи йдеться про маркетинг, який використовує чат-бот на базі LLM, чи про розробників, які тестують моделі з відкритим вихідним кодом, шаблон незмінний. Інструменти розгортаються, конфіденційні дані обробляються, і ніхто з служби безпеки не дізнається про це, доки щось не піде не так. У суворо регульованих галузях це може призвести до порушення резидентності даних або недотримання місцевих законів, зокрема PDPA Сінгапуру, Закону Австралії про конфіденційність, APPI Японії та PIPA Південної Кореї. Ці закони встановлюють суворі умови щодо того, як дані збираються, передаються та обробляються, особливо коли задіяний штучний інтелект, і недотримання цих вимог може призвести до штрафних санкцій, шкоди репутації та операційного ризику.

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

Протокол моделі контексту (MCP): новий кордон API


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

Для підприємств в APJ, які покладаються на інтеграцію сторонніх розробників або працюють у гібридних хмарних середовищах, MCP може стати невидимою точкою входу для зловмисників. Як і будь-який рівень інтеграції, до нього слід ставитися ретельно: розуміти, які плагіни використовуються, хто має доступ і чи надходять вони з надійних джерел. Ризики, які здаються абстрактними на папері, можуть швидко перерости у виробництво, якщо немає засобів контролю.

Витік секретів: зростаючий вектор атаки


У швидкому розвитку штучного інтелекту ярлики є звичайним явищем. Розробники можуть жорстко закодувати облікові дані, забути змінити ключі API або залишити секрети в загальнодоступних сховищах. Під час сканування GitHub Wiz виявив, що чотири з п’яти секретів, які найбільше розкриваються, пов’язані зі службами штучного інтелекту, включаючи ключі доступу для OpenAI, AWS Bedrock та інших ресурсоємних кінцевих точок.

Ці ключі є цінними цілями. У разі виявлення їх можна використовувати для доступу до конфіденційних даних, активації дорогих хмарних ресурсів або запуску бічних атак у вашій інфраструктурі. Для організацій, які мають справу з транскордонними потоками даних або вимогами відповідності до конкретних країн, наслідки можуть бути значними. А зі зростанням вартості обчислень ШІ зростає фінансовий стимул для зловмисників використовувати вкрадений доступ.

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

Як безпека може наздогнати


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

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

Безпека має сприяти, а не блокувати. Коли групи безпеки можуть бачити, що працює, розуміти, як це пов’язано, і вбудовувати управління в робочі процеси штучного інтелекту з самого початку, саме тоді організації можуть вільно та безпечно впроваджувати інновації.