Марк Фетчес, технічний керівник Spinnaker Support – Серія інтерв’ю

Марк Фетчес є технічним керівником для Європи, Середнього Сходу та Африки в Spinnaker Support, де він консультує підприємства з питань технологічної стратегії, безпеки, хмарних технологій, штучного інтелекту та великомасштабних трансформаційних ініціатив. З більш ніж 30-річним досвідом консультування та лідерства в Accenture, Deloitte та PwC, Марк тісно співпрацював з виконавчими директорами та радами з питань модернізації складних корпоративних середовищ та узгодження технологічних рішень з довгостроковими бізнес-цілями. Розташований у Великій Британії, він спеціалізується на допомозі організаціям у подоланні проблем спадкової технології, операційних ризиків та цифрової трансформації з практичними, орієнтованими на бізнес рекомендаціями.

Spinnaker Support є провідним глобальним постачальником послуг третьої сторони з підтримки програмного забезпечення, керованих послуг та консультацій з безпеки для підприємств, які використовують Oracle (ORCL ), SAP, JD Edwards та інші критично важливі платформи.

Ви провели понад 20 років, консультуючи підприємства в Accenture, Deloitte та PwC, перш ніж стати технічним керівником у Spinnaker Support. Оглянувшись на цей шлях, які найбільші помилкові уявлення виконавчі директори мали щодо технологічних ризиків, і як змінився розгляд штучного інтелекту?

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

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

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

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

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

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

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

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

Я поставив би це досить просто. Галузь не бідна на дані про уразливості. Вона бідна на ясність.

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

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

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

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

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

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

Багато постачальників кібербезпеки стверджують, що штучний інтелект може автоматично пріоритезувати уразливості та передбачати загрози. Де ви бачите розрив між маркетинговим нарративом та тим, що штучний інтелект може дійсно доставити сьогодні в корпоративних середовищах?

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

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

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

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

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

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

Це дійсно розрив. Нарратив говорить про певність. Реальність скромніша і більш корисна, ніж гіп.

Spinnaker Support працює широко з розгортуваннями Oracle, SAP та JD Edwards. Що робить високо настроєні середовища ERP особливо важкими для інструментів безпеки, керованих штучним інтелектом, для розуміння та оцінки точно?

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

Я бачив, що це особливо вірно для високо настроєних активів Oracle, SAP та JD Edwards. На папері ви можете все ще дивитися на відому платформу. На практиці ви часто дивитесь на роки місцевих адаптацій, настроєного коду, успадкованих інтеграцій, структур дозволів, логіки звітів та обходів, створених для дуже конкретних операційних причин. Для інструменту безпеки, керованого штучним інтелектом, це може бути важко прочитати з будь-якою реальною певістю.

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

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

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

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

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

Так, абсолютно. І для мене це саме той випадок, де межі автоматичної пріоритезації стають дуже очевидними.

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

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

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

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

Таким чином, коли я говорю про людський досвід, я не говорю про інтуїцію в деякому невизначеному сенсі. Я говорю про місцеві знання. Пам’ять. Судження. Здатність бачити, коли мала технічна проблема прикріплена до чогось набагато більш суттєвого.

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

Як організації поспішають приймати штучний інтелект по всім операціям з безпеки, які найбільші ризики надмірної автоматизації управління уразливостями та оцінки вразливості?

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

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

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

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

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

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

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

Таким чином, моя точка зору полягає в тому, що автоматизація повинна абсолютно робити важку роботу. Але вона повинна підтримувати судження, а не замінювати його. Інакше ви закінчуєте процесом, який є ефективним, вимірюваним та масштабованим, але не обов’язково безпечнішим.

Ви працювали широко в сфері трансформації ІТ та корпоративної архітектури. Як керівники з безпеки повинні балансувати потребу швидко виправляти уразливості з операційними ризиками порушення критично важливих бізнес-систем?

Відмінне питання, оскільки це одна з тих областей, де проста відповідь зазвичай неправильна.

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

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

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

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

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

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

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

Підхід Spinnaker об’єднує аналіз, керований штучним інтелектом, з експертною валідациєю. Які конкретні завдання повинні виконувати штучний інтелект, а які рішення повинні залишатися твердо в руках досвідчених фахівців з безпеки?

Я думаю, що лінія поділу насправді досить проста.

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

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

Де я був би більш обережним, це коли ви переходите від аналізу до прийняття рішень.

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

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

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

Бо як тільки рішення мають наслідки, або оперативні, або фінансові, або репутаційні, ви не просто обробляєте інформацію. Ви приймаєте судження.

І в сфері безпеки, я вважаю, що це все ще повинно бути людиною з реальним інтелектом.

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

Це вимагає ширшого погляду, тому що число само по собі не говорить вам багато про те, наскільки ви дійсно в біді.

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

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

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

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

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

Інакше ви закінчуєте керуванням картиною ризику, а не ризиком самим. Панель покращується. Кількість квитків рухається. Звіт виглядає краще. Але ви не обов’язково безпечніші.

Я думаю, що частина причини цього полягає в тому, що числа комфортні. Вони виглядають об’єктивними. Вони дають людям щось помітне, щоб представити. Вони створюють відчуття, що проблема була зменшена до чогось вимірюваного та під контролем. Але реальна вразливість зазвичай набагато заплутаніша.

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

Таким чином, так. Використайте оцінки. Використайте кількість. Очевидно. Але не плутайте їх з розумінням.

Якщо ви хочете знати, де реальна вразливість, я вважаю, що вам потрібно дивитися на все середовище, а не тільки на число, прикріплене до нього.

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

Я думаю, що наступні три-п’ять років будуть досить визначальними.

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

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

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

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

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

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

Наступна річ – це керування, але не той вид, який просто для показу. Реальні рішення. Де можна використовувати штучний інтелект? Де людський огляд повинен залишатися на місці? Як виводи перевіряються? Які дані поза межами? Хто володіє наслідками, якщо система призведе до неправильної дії? Ці питання повинні бути відповіли зараз, а не пізніше.

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

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

Таким чином, так. За наступні кілька років я думаю, що штучний інтелект, кібербезпека та корпоративні платформи стануть ще тісніше пов’язані.

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

Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Spinnaker Support.