Сорок чотири відсотки старших керівників у сфері технологій та безпеки не мають чіткої відповіді на питання, хто несе відповідальність, коли інструмент, створений штучним інтелектом, спричиняє інцидент у виробництві. Більшість не змогли сказати, чи був такий інцидент минулого року, оскільки моніторинг не дозволяє це відстежити.
Керівники, які зосереджуються на тому, що відбувається після випуску інструментів, отримують приріст продуктивності, обіцяний ШІ, без розростання кількості інструментів, яке тихо з’їдає ці переваги. Управління робить це можливим.
Ми опитали 307 старших керівників у сфері технологій та безпеки (CTO, CIO та CISO) щодо їхнього підходу до управління в епоху кодування за допомогою ШІ. Результати показують, що відповідальність не встигає за можливостями.
Розробка прискорюється. Безпека не встигає.
Напрямок розвитку визначено: більше людей створюють більше програмного забезпечення, швидше і з меншою участю традиційних інженерів. Дев’яносто відсотків опитаних керівників повідомляють про зростаючий тиск щодо впровадження розробки на основі ШІ, і більшість називають це чистим виграшем у продуктивності. Організаційні структури, які визначають, хто за що відповідає, не рухалися в тому ж темпі.
Занадто багато компаній мають недостатньо відповідальності за додатки, створені ШІ
Коли ми запитали керівників, що станеться, якщо внутрішній інструмент, створений ШІ, спричинить інцидент у виробництві, 32% респондентів відповіли, що відповідальність несе керівництво інженерного відділу або CTO, 23% – команда або особа, яка його створила, а 34% – що це залежить від ситуації. Десять відсотків взагалі не визначили це. Сукупно, 44% старших керівників у сфері технологій та безпеки працюють без чіткого стандарту відповідальності.
«Коли будь-хто може випустити інструмент за півдня, ніхто не бере на себе зобов’язань щодо його підтримки», – сказав один CITO, опитаний нами, коментуючи невидимий характер збоїв ШІ. «Проблеми залишаються невидимими, доки щось не зламається». Результатом є зростаючий інвентар виробничих інструментів без чіткого власника чи нагляду за безпекою. Більшість керівників у нашому опитуванні не змогли впевнено сказати, чи був у них інцидент у виробництві через інструмент, створений ШІ, минулого року, просто тому, що моніторинг не дозволяє це підтвердити.
Нові розробники працюють поза межами традиційного управління
Проблема власності завжди існувала для внутрішніх інструментів. Приємно створювати власні, але болісно керувати доступом та автентифікацією. Самостійно зібране рішення для унікальної проблеми працює, доки не перестане працювати – а до того часу розробник може давно зникнути разом з API-ключем або обліковими даними. ШІ підвищує ці ризики до максимуму, надаючи можливість більшій кількості членів команди створювати швидше та менш безпечно.
Стандартною відповіддю на прогалину в управлінні є додатковий процес, але заходи, як-от додаткові цикли перевірки, чіткіші політики та краще навчання для розробників, мали сенс, коли розробка була централізованою, а обсяг нових інструментів був керованим. Вони погано відповідають середовищу, де робочий внутрішній інструмент може пройти шлях від запиту до виробництва протягом дня.
Сімдесят вісім відсотків опитаних керівників описують своє поточне управління як таке, що підтримується вручну або є нерівномірним між командами. Більшість організацій застосовують управління для кожного інструменту, окремими розробниками – і опитані керівники в значній мірі погоджуються, що це неправильна модель (лише 7% підтримали такий підхід).
Політики, які покладаються на окремих розробників для правильного налаштування безпеки, завжди будуть більш схильними до людських помилок. Нереалістично очікувати, що це нове когорта розробників буде все робити правильно, щоразу, і ми не можемо вимагати від ІТ-відділів або інженерних команд відповідальності за потік нового коду.
Стандарти безпеки слід встановлювати один раз і застосовувати до кожної програми, а не переписувати щоразу
Коли ми запитали керівників, де повинна бути основна відповідальність за безпеку та контроль доступу, 55% вказали на централізовану платформу під додатком: таку, що застосовується незалежно від того, як додаток був створений або хто його створив. Безпека та контроль доступу до даних були визначені як майже універсальний пріоритет управління.
Коли П’єр-Ів Каллош керував трансформацією ШІ в Pernod Ricard, він з самого початку розумів вплив управління на рівні платформи. Коли він працював над першими проєктами ШІ компанії, він ставився до управління як до необхідної конструктивної обмеження, яке потрібно вирішити, а не обговорювати після факту. Розробляючи в рамках керованої платформи, «той факт, що існував цей рівень безпеки, який гарантував, що ви ніколи не видалите виробничу базу даних, надав усім велику впевненість», – сказав П’єр-Ів. «Ми отримали дозвіл діяти надзвичайно швидко і робити речі швидко та напівбрудно в цьому середовищі».
У Retool, незалежно від того, чи створює команда інструмент за допомогою запиту, імпортує існуючий додаток, чи створює за допомогою помічника з кодування ШІ з MCP, він потрапляє всередину керованої платформи з дозволами, моделлю ресурсів та елементами контролю розгортання, яким організація вже довіряє. Відповідальність не повинна узгоджуватися для кожного інструменту окремо, оскільки платформа забезпечує її за замовчуванням.
Оскільки все більше неінженерів розробляють виробниче програмне забезпечення, розробка буде випереджати володіння та відповідальність, якщо рівень управління не перейде від окремих додатків до платформи під ними.
Подробиці можна знайти на сайті: venturebeat.com