11 червня 2026 року в Європейському Союзі відбулася подія без гучних заяв, але з дуже практичними наслідками. Держави-члени ЄС мали визначити органи нотифікації. Саме ці органи відповідають за те, хто зможе оцінювати під’єднані продукти відповідно до Акта про кіберстійкість, або Cyber Resilience Act, CRA.

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

Якщо у вашій продуктовій стратегії є пристрої з мікросхемами, сенсорами або механізмом оновлення вбудованого програмного забезпечення, це вже зона уваги CRA. Йдеться про промислові контролери, телематику для автопарків, пристрої для розумної роздрібної торгівлі, носимі пристрої, під’єднані компоненти та інші цифрові продукти, які потрапляють на ринок ЄС. Місце реєстрації компанії або країна виробництва не є визначальними. Важливо те, що продукт розміщується на ринку Європейського Союзу. Це випливає з огляду Європейської комісії щодо Cyber Resilience Act.

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

Дедлайни розтягнуті в часі, але це не привід відкладати підготовку

CRA не починає діяти в один день повністю. Саме тому багато продуктових команд недооцінюють терміновість підготовки: немає однієї дати, яка створює відчуття жорсткого дедлайну.

Насправді часову лінію варто розділити на три ключові етапи.

До 11 червня 2026 року держави-члени ЄС мали підготувати інфраструктуру для оцінювання відповідності. 11 вересня 2026 року — дата, яку кожна команда, що працює з вбудованими системами, має позначити окремо. З цього моменту виробники повинні повідомляти про активно використані вразливості протягом 24 годин після того, як їм стало про них відомо. Повідомлення має надходити до ENISA та відповідної національної CSIRT. Повне повідомлення подається протягом 72 годин, а фінальний звіт — протягом 14 днів. Про запуск цього “24-годинного годинника” для вразливостей також писав TechTimes.

11 грудня 2027 року починається повне застосування основних вимог регламенту щодо кібербезпеки. За невідповідність вимогам передбачені штрафи до 15 мільйонів євро або до 2,5% світового річного обороту компанії.

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

Чому більшість команд IoT і вбудованих систем не готові

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

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

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

Третя проблема — реагування на інциденти. І саме її команди часто недооцінюють. Повідомити про вразливість до ENISA протягом 24 годин можна лише тоді, коли вже є три речі: моніторинг, який здатен виявити використання вразливості; зрозумілий шлях ескалації, який не залежить від того, чи відповість один конкретний інженер на телефон; і заздалегідь підготовлені шаблони повідомлень. Багато команд, що працюють із вбудованими системами, ніколи не проводили такої перевірки на практиці, бо раніше цього ніхто від них прямо не вимагав.

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

Проблема вже випущених продуктів

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

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

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

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

Поверхня відповідності зростає разом із кількістю пристроїв

CRA з’являється в незручний момент для багатьох компаній. Корпоративний Інтернет речей виходить за межі пілотних проєктів і рухається до того, що аналітики називають автономними під’єднаними операціями. Це означає більше пристроїв, більше автономності й більше даних, які передаються між машинами з меншою участю людини. Про цей перехід ідеться у звіті IoT Analytics State of Enterprise IoT 2026.

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

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

Що означає “безпечне проєктування” на практиці

Для продуктових та інженерних керівників підготовка до CRA — це не косметичні зміни, а реальна архітектурна робота.

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

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

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

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

Реалістичний план підготовки на найближчі 18 місяців

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

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

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

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

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

Як до цього підходить Allmatics

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

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

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

Якщо у вашій продуктовій стратегії є під’єднане обладнання, яке виходить або планує виходити на ринок ЄС до грудня 2027 року, варто діяти наперед. Найкращий момент для оцінки продуктової ідеї з урахуванням CRA — до того, як наступна апаратна ревізія буде остаточно зафіксована. Не тоді, коли регулятори вже почнуть ставити запитання.

The post Акт ЄС про кіберстійкість для IoT: що змінилось у 2026 році appeared first on Allmatics.

На зустрічі все виглядає чудово.
Дашборд охайний.
Графіки точності зелені.
Модель працює.
Хтось каже: “Ну все, спрацювало”.

А потім у реальній роботі майже нічого не змінюється.

Диспетчер не будує маршрути по-новому.
Медсестра все одно перевіряє рекомендацію ще раз.
Менеджер не перебудовує процес через один прогноз системи.

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

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

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

У чому насправді помилка

Дуже часто команди перевіряють одне просте питання:
чи може модель дати достатньо точний результат?

Але в реальній роботі цього мало.

Команди думають про інше:

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

Ось чому хороший результат на тестах ще не означає, що рішення реально приживеться.

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

Тобто проблема була не в тому, що модель “дурна”.
Проблема була в тому, що вся система навколо неї не була готова.

Коли AI вже не окрема функція

Поки AI існує окремо від основного процесу, з ним легко захоплюватися.

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

Саме тому сильні команди не дивляться на AI як на окремий експеримент. Вони сприймають його як частину custom AI/ML development, тобто як частину повноцінної архітектури продукту.

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

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

Це повторюється постійно: довіра до AI з’являється не від “магії моделі”, а від того, наскільки добре все зшито докупи.

Логістика добре показує правду

У логістиці AI часто здається ідеальним рішенням. Даних багато: маршрути, сканування, часові мітки, сигнали із сенсорів.

Але там дуже швидко стає видно, чи система справді корисна.

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

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

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

У HealthTech все ще суворіше

У медицині простої точності замало.

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

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

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

У HRTech AI теж не замінює людину

У роботі з кандидатами AI найкраще проявляє себе не як “суддя”, а як швидкий помічник.

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

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

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

Що відрізняє корисну систему від красивої демки

Є кілька речей, які повторюються майже всюди.

По-перше, треба одразу думати про збої. Не після релізу, а до нього.
По-друге, людину треба вбудовувати в процес свідомо, а не “на всяк випадок”.
По-третє, міряти треба не тільки якість моделі, а реальний ефект: швидкість, кількість помилок, повторну роботу, рівень використання.

Саме такий підхід добре стикується з тим, як NIST описує AI Risk Management Framework: не як абстрактну теорію, а як рамку для створення надійних і зрозумілих AI-систем.

До чого ми врешті приходимо

AI стає справді цінним не тоді, коли красиво виглядає на слайді.

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

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

Ось тоді AI перестає бути красивою ідеєю.
І стає тим, на що справді можна спертися щодня.

The post AI в операціях: коли AI входить у щоденну роботу appeared first on Allmatics.