Усі бачать проблему. Клієнт досі не може отримати рішення.

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

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

Почніть із рішення, потрібного клієнту

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

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

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

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

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

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

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

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

Призначайте відповідального за наступне рішення, а не лише відділ

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

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

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

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

Опишіть процес так, щоб його можна було реалізувати

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

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

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

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

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

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

Будуйте дашборд навколо рішень і дій

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

У прикладі з пошкодженою палетою покажіть: відправлення та замовлення; кількість пошкодженого товару; повноту матеріалів; стан вирішення проблеми з товаром; стан претензії; поточного відповідального; наступну дію; строк; причину затримки; час останнього оновлення кожного джерела.

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

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

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

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

Визначте, що можна автоматизувати, а де потрібне погодження

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

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

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

Перевірте складні ситуації до запуску

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

Завантажте матеріали щодо іншого відправлення: система має позначити невідповідність, а не продовжити процес.

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

Зімітуйте помилку запиту на заміну після погодження: справа має залишатися відкритою, а невиконана дія видимою.

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

Вимірюйте час очікування, а не лише кількість завершених справ

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

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

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

Почніть з одного типу інциденту та об’єднайте весь процес

Рішення Allmatics для логістики охоплюють відстеження, аналітику та інтеграцію з наявними транспортними системами й IoT-пристроями. У такому проєкті ми об’єднали б ці програмні компоненти навколо одного погодженого операційного результату: аналіз процесу, пов’язані дані, інтерфейс справи, правила роботи, дії в системах і перевірка виконання.

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

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

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

The post Пошкоджений вантаж: як побудувати процес від повідомлення до вирішення appeared first on Allmatics.

ПЗ працює. То навіщо щось змінювати?

У багатьох малих і середніх компаній схожа технологічна історія. Кілька розробників працюють у бізнесі роками. Вони знають старі системи, інтеграції, дивні скрипти, до яких ніхто не хоче торкатися, і обхідні рішення, що з часом стали частиною щоденної роботи. Саме тут модернізація застарілого ПЗ часто зупиняється: система працює, компанія заробляє, клієнти отримують послуги, тож немає очевидної кризи, яка змусила б щось змінювати. А потім хтось запитує: «А це можна автоматизувати?» І раптом ніхто не може впевнено сказати, чи це займе два тижні, шість місяців, чи «краще не чіпати це до завершення високого сезону».

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

Підтримка непомітно стає основною роботою

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

Логіка мотивації тут цілком зрозуміла. Якщо ініціатива спрацювала, дуже швидко вона стає новою нормою. Якщо ні — проблема залишається за тим, хто її запропонував. І справа не стільки у фіксованій зарплаті. Глибша причина — у тому, що саме компанія винагороджує, від чого захищає людей і на що реально дає їм час. Коли ініціатива означає більше роботи, більше невизначеності й більше особистого ризику, а головна вимога звучить як «нехай усе стабільно працює», підтримка майже завжди перемагає. Саме тому модернізація застарілого ПЗ часто відкладається навіть тоді, коли всі бачать, що процеси можна покращити.

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

Бізнес може не знати, що саме варто автоматизувати

Є ще одна проблема, яку легко не помітити: сама компанія може не бачити, де саме ховаються найцінніші можливості для автоматизації. Люди дивовижно швидко звикають до незручних процесів. Диспетчер щоранку вручну переносить дані з однієї системи в іншу. Менеджер у ритейлі перевіряє залишки вручну, бо «ми завжди так робили». Координатор у клініці перед кожною зміною звіряє дані між системами. Робота все одно виконується, тому неефективність процесу перестає виглядати як проблема.

Зсередини компанії така неефективність швидко стає буденністю. CEO може ніколи не бачити десять ручних кроків, які стоять за простим результатом. Розробник може не бачити операційне вузьке місце. Менеджер, який щодня живе з проблемою, може чудово розуміти, що саме дратує або забирає час, але не знати, що з цього технічно можна автоматизувати. Саме тому запитання «Яке ПЗ ви хочете, щоб ми для вас розробили?» часто є неправильним стартом.

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

У малих компаніях часто немає відповідального саме за технологічні покращення

Саме тут багато малих і середніх компаній застрягають. Бізнес-команда відповідає за операційну роботу. Розробники — за поточне ПЗ. Керівництво — за комерційні пріоритети. Але ніхто чітко не відповідає на запитання: «Що в цьому бізнесі можна робити краще, якщо використати технології інакше?» І це важливо, бо можливість для автоматизації майже ніколи не приходить у вигляді готової технічної вимоги. Зазвичай вона виглядає як втрачений час, повторна робота, повільні рішення, повторне введення даних або процес, до якого всі просто звикли.

Опитування OECD D4SME 2026 року серед понад 2 000 малих і середніх компаній показало, що підвищення ефективності та зростання — серед головних причин впровадження цифрових інструментів. Водночас брак часу, витрати на підтримку та дефіцит компетенцій і далі гальмують впровадження. У звіті також зазначено, що стратегічне, цільове й безпечне використання ШІ у бізнес-процесах залишається нерівномірним. Дані Eurostat про цифровізацію за 2026 рік показують ту саму ширшу картину: у 2025 році 71% малих і середніх компаній у ЄС досягли щонайменше базового рівня цифрової інтенсивності, але лише 9% — дуже високого.

Малим компаніям зазвичай не бракує ідей. Їм частіше бракує ресурсу й компетенцій, щоб перетворити операційну проблему на добре сформульовану технологічну ініціативу з чітким бізнес-обґрунтуванням, реалістичною архітектурою, відповідальним власником і безпечним планом впровадження. Саме тому модернізація застарілого ПЗ — це часто не про масштабне переписування системи, а про здатність побачити правильні зміни, визначити їхній пріоритет і послідовно реалізувати.

Фаундер не повинен бути архітектором ПЗ

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

Проблема починається тоді, коли технічні рекомендації так і залишаються технічними. «У нас технічний борг». «Нам потрібен рефакторинг». «Цей фреймворк застарів». Для нетехнічного CEO це легко може звучати як: «Дайте нам шість місяців і багато грошей, щоб після цього зовні майже нічого не змінилося». Технічне обґрунтування має перетворитися на бізнес-обґрунтування: цей процес щотижня забирає у команди години; ця інтеграція уповільнює запуск кожного нового клієнта; ця система критично залежить від однієї людини; цей ручний крок створює помилки, яких можна уникнути.

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

Знання про застарілу систему цінні, але вони не повинні ставати єдиною точкою відмови

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

Рекомендації IBM 2026 року щодо технічного боргу підкреслюють той самий ризик: коли досвідчені люди йдуть, разом із ними компанія втрачає значну частину накопичених знань, а прогалини в документації роблять наступні зміни ще складнішими. Модернізація застарілого ПЗ безпечніша, коли ці знання фіксуються, передаються й стають одним із вхідних даних для змін, а не залишаються лише в головах кількох людей. Мета не в тому, щоб прибрати людей, які знають стару систему. Мета — перестати робити їх єдиними людьми, які можуть безпечно її змінювати.

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

У 2026 році є дуже спокуслива відповідь на всі ці проблеми: «Тепер код може написати ШІ». Так, ШІ суттєво змінив розробку ПЗ. Дослідження JetBrains Developer Ecosystem 2026 показало, що 90% професійних розробників використовували AI-агентів для програмування у роботі щонайменше щотижня, а 68% — щодня. Тому цікаве запитання вже не в тому, чи користуються розробники ШІ.

Складніше питання — чи знає сам бізнес, що саме варто створювати, як нове рішення має вписатися в наявну систему, хто відповідатиме за результат і чи можна буде безпечно ним користуватися в реальній роботі. Звіт GitLab AI Accountability Report 2026 показав, що 80% опитаних розробників і технологічних замовників вважають: їхні компанії впроваджували AI-інструменти швидше, ніж правила їх використання та контролю. 92% повідомили про проблеми з контролем AI-згенерованого коду. ШІ може скоротити зусилля на реалізацію, але не скасовує потреби у попередньому аналізі, архітектурі, безпеці, тестуванні, відповідальності, документації та бізнес-рішеннях.

Краща модель модернізації застарілого ПЗ

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

Саме тут зовнішній інженерний партнер може дати реальну цінність — не як додаткові розробники, які просто чекають на задачі, а як ланка між бізнес-проблемою та технічною реалізацією. І правильне рішення може бути значно меншим за «цифрову трансформацію»: одна інтеграція, новий модуль, автоматизований процес, окремий шар даних, один крок із підтримкою ШІ або поступовий план модернізації.

Як Allmatics підходить до модернізації застарілого ПЗ

В Allmatics ми розглядаємо модернізацію застарілого ПЗ як один із можливих шляхів, а не як універсальну рекомендацію. Іноді правильне рішення — створити новий продукт із нуля: дослідити задачу, сформувати вимоги, спроєктувати архітектуру, розробити веб- або мобільне рішення, AI/ML, embedded- чи IoT-компоненти, інтеграції, провести тестування, запуск і далі розвивати продукт. Наш підхід Product Development охоплює весь шлях — від ідеї та архітектури до розробки, інтеграції, запуску й підтримки.

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

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

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

Починайте з роботи, а не з ПЗ

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

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

Справжня проблема — не старе ПЗ

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

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

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

The post Пастка підтримки: коли «все й так працює» стає причиною, що нічого не змінюється на краще appeared first on Allmatics.

Почніть з обмежень, які найдорожче змінювати пізніше

Мобільний стек легко обговорювати в теорії, адже будь-який із варіантів може дати переконливе демо. Реальні відмінності проявляються на складних сценаріях: мережа зникає, фонова задача призупиняється, оновлення firmware змінює поведінку пристрою, ОС змінює модель дозволів або нова системна AI-можливість доступна лише через нативний фреймворк.

Саме тому ми рекомендуємо спочатку описати продуктові обмеження, а вже потім обирати модель реалізації. Корисне питання звучить не «Який фреймворк кращий?», а «Які частини цього продукту найімовірніше вимагатимуть platform-specific engineering протягом його життєвого циклу?»

Зазвичай відповідь лежить у шести площинах: доступ до hardware і периферії; offline-режим та синхронізація; інтеграції з ОС і AI; продуктивність та складність UI; безпека або регульовані процеси; економіка команди й життєвого циклу.

1. Доступ до hardware може перетворити спільну кодову базу на нативний проєкт

Якщо застосунок переважно працює з HTTP API та стандартними можливостями пристрою, кросплатформна розробка дозволяє залишити значну частину продуктової логіки та UI в одній кодовій базі. Але connected products часто потребують більшого: Bluetooth Low Energy, NFC, USB, camera pipelines, обробки аудіо, фонових сервісів, локальної мережі, кастомних аксесуарів або vendor SDK.

Що критичніші ці можливості для основного сценарію, то важливіше перевірити реальний шлях нативної інтеграції ще до остаточного вибору фреймворку. Кросплатформний шар цілком може працювати добре, але команда має одразу закласти в оцінку нативні модулі, platform-specific debugging і відмінності життєвого циклу на iOS та Android.

Це не аргумент проти cross-platform. Це аргумент проти припущення, що «одна кодова база» автоматично означає «одна реалізація».

2. Для offline-first продуктів архітектуру потрібно визначити раніше, ніж UI-технологію

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

Ці рішення зазвичай важливіші за вибір UI-фреймворку. І native, і cross-platform стеки можуть підтримувати offline-first сценарії, але команді все одно потрібні чітка локальна модель даних і контракт синхронізації. Якщо цей шар не визначений, зміна фреймворку не вирішить базову проблему продукту.

Саме тут мобільна архітектура з’єднується з рештою системи. Застосунок не може самостійно визначати правила вирішення конфліктів, якщо cloud, device та backend-сервіси по-різному трактують, який шар є джерелом істини для даних.

Повний підхід до offline-first архітектури ми окремо розібрали в матеріалі «Offline-First – це архітектурне рішення».

3. AI на рівні ОС робить глибину інтеграції з платформою комерційно важливішою

У 2026 році мобільні операційні системи дедалі активніше впливають на поведінку застосунків. Платформа Apple надає Foundation Models як нативний Swift API, а App Intents з’єднує контент і дії застосунку з Apple Intelligence та Siri. Apple також прямо зазначає, що поведінка моделей може змінюватися разом з оновленнями ОС, тому командам потрібно повторно тестувати промпти та AI-поведінку на нових версіях системних моделей.

На Android адаптивна поведінка продовжує розширюватися на телефони, планшети, foldable-пристрої, desktop-style windows, автомобілі, телевізори та XR. У рекомендаціях Android для застосунків, що таргетують API level 36, акцент зроблено на responsive та adaptive layouts для великих екранів, а не на фіксованих припущеннях про формат смартфона.

Це не означає, що кожен застосунок має стати нативним. Але platform-specific capabilities потрібно враховувати ще під час architecture discovery. Якщо Siri actions, on-device models, adaptive multi-window behavior, connected displays або інші можливості ОС стратегічно важливі для продукту, вартість їх підключення через кросплатформну абстракцію варто перевірити заздалегідь.

Окремо про те, як on-device AI впливає на мобільну архітектуру, ми написали в матеріалі «On-Device AI у мобільних застосунках у 2026 році».

4. Продуктивність не зводиться до одного показника

Твердження «native швидший» і «cross-platform достатньо швидкий» однаково надто загальні. Продуктивність залежить від конкретного навантаження.

Для стандартного бізнес-застосунку реалізація кожного екрана двічі може не дати відчутної комерційної переваги. Але продукт із real-time audio, video, sensor streams, складною графікою, інтенсивною фоновою обробкою або чутливою до затримки комунікацією з пристроями має зовсім інший профіль.

Команді варто окремо оцінювати продуктивність UI та продуктивність системних інтеграцій. Плавний інтерфейс ще не доводить, що background execution, повторне підключення Bluetooth, media processing або local inference працюватимуть стабільно в production.

Тому architecture review має включати технічні спайки для найризикованіших сценаріїв. Спочатку прототипуйте саме той workflow, де ризик найвищий. Якщо стек чисто проходить цей сценарій, рішення щодо решти продукту стає значно обґрунтованішим.

5. Безпека й регульовані процеси змінюють вартість абстракції

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

Автентифікація, secure storage, робота з сертифікатами, дозволи пристрою, локальні бази даних, механізми оновлення та сторонні SDK збільшують поверхню атаки. У connected products мобільний застосунок також може бути проміжним шаром між фізичним пристроєм і cloud services, тому identity, authorization та data boundaries стають питаннями всієї системи, а не лише мобільного застосунку.

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

6. Економіку потрібно рахувати на весь життєвий цикл продукту, а не лише на швидкість MVP

Cross-platform може зменшити дублювання роботи, якщо поведінка продукту справді спільна для платформ. Native може скоротити кількість bridge-рішень і platform-specific сюрпризів, коли застосунок глибоко залежить від операційної системи. Hybrid/web підхід може бути ефективним для контентних або внутрішніх workflow, де нативні можливості мають другорядне значення.

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

Повніша lifecycle-модель має враховувати platform-specific modules, оновлення залежностей, зміни ОС, regression testing, релізи в app stores, performance debugging, accessibility, observability та ймовірність того, що стратегічні функції згодом вимагатимуть нативних API.

Найдешевший MVP не обов’язково буде найдешевшим продуктом у підтримці та розвитку.

Практична карта вибору

Обирайте native насамперед тоді, коли продукт залежить від глибокої інтеграції з hardware, чутливої до затримки обробки медіа або сенсорних даних, інтенсивної фонової роботи, platform-first AI capabilities або сильно platform-specific UX.

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

Обирайте hybrid/web насамперед тоді, коли продукт складається переважно з контенту, форм, dashboard або внутрішніх workflow, нативні можливості другорядні, а web delivery чи повторне використання web-компонентів має очевидну бізнес-цінність.

Для багатьох connected products реалістичною відповіддю буде змішана архітектура. Спільна продуктова логіка може співіснувати з нативними device-модулями. Кросплатформний UI може викликати нативні сервіси для Bluetooth або audio. Нативний застосунок може вбудовувати web-контент для низькоризикових адміністративних сценаріїв. Архітектурі не потрібна ідеологічна чистота.

Що змінює наш досвід із комплексними connected products

В Allmatics мобільна розробка часто є лише одним шаром більшого продукту, а не окремим app-проєктом. Кейс ReadU6 добре показує цей системний підхід: рішення поєднує web/mobile software, кастомний embedded-пристрій, IoT, AI/ML, NLP та обробку в реальному часі.

Це важливо, тому що мобільну архітектуру не можна оцінювати окремо від пристрою та AI-workflow. Коли продукт охоплює hardware, embedded software, мобільні інтерфейси, cloud services і machine-learning компоненти, саме межі між цими шарами визначають надійність і підтримуваність системи.

Висновок ширший за один кейс. Перед вибором мобільного фреймворку визначте, за що відповідає застосунок, за що відповідає пристрій, що має залишатися у cloud, що повинно працювати offline і які platform-specific capabilities стратегічно важливі. Після цього обирайте стек, у якому ці межі найпростіше реалізувати, протестувати й розвивати.

Рекомендація: обирайте архітектуру за найжорсткішим обмеженням

Якщо у вашому shortlist є Swift/Kotlin, React Native, Flutter або hybrid-підхід, не починайте з уподобань розробників чи загального порівняння вартості.

Почніть з найжорсткішого production constraint. Прототипуйте ризиковану інтеграцію. Опишіть offline-поведінку. Визначте platform-specific AI та системні API, які плануєте використовувати. Розподіліть відповідальність за безпеку й оновлення. Оцінюйте роботу на весь lifecycle, а не лише на етап MVP.

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

Якщо ви плануєте мобільний або connected product і вибір архітектури ще відкритий, Allmatics Product Discovery допоможе визначити межі між пристроєм, застосунком, cloud, інтеграціями та AI ще до початку розробки.

The post Native, Cross-Platform чи Hybrid? Обирайте за вимогами продукту, а не модою на фреймворки appeared first on Allmatics.

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

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

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

Інтернет навчив ШІ говорити. Фізичний світ складніший.

Цей дефіцит даних давно очевидний для дослідників робототехніки. Проєкт Google DeepMind Open X-Embodiment об’єднав дані від 22 типів роботів і понад 20 дослідницьких установ. Разом вони створили понад мільйон епізодів для навчання роботів на сотнях навичок і завдань. Суть не в тому, що мільйон демонстрацій розв’язав проблему робототехніки. Навпаки: навіть для збору такого обсягу корисних даних про фізичну взаємодію знадобилася співпраця в масштабі, який одній лабораторії було б важко відтворити.

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

Люди, які навчають роботів

MIT Technology Review розповів про Micro1 — компанію з Пало-Альто, яка залучає людей у понад 50 країнах для запису реальних дій, що використовуються в навчанні роботів. Один з учасників у Нігерії, студент-медик, записує побутові завдання вдома й заробляє близько $15 на годину. На відео — максимально буденні речі: складання одягу, готування, прибирання, переміщення предметів. Саме в цьому й суть. Те, що люди роблять майже не замислюючись, роботам досі потрібно показувати.

Та сама тенденція з’являється і на робочих місцях. The Guardian описав працівників фабрик в Індії, які носять камери на голові під час шиття, роботи з інструментами та виконання виробничих операцій. За даними видання, на деяких фабриках працівникам не доплачували за такі записи. У матеріалі також згадується індійська компанія EgoLab, яка називає Tesla одним зі своїх великих клієнтів. Окремо Tesla наймає у США операторів зі збору даних: вони одягають костюми для захоплення рухів і VR-обладнання та виконують рухи для навчання Optimus.

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

У м’язової пам’яті з’явилася ціна.

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

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

Демонстрації людей можуть бути лише початковою точкою

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

Але індустрія рухається не в цьому напрямку.

Практичніший підхід — використовувати людські демонстрації як стартові дані, а потім масштабувати їх за допомогою симуляцій і синтетичних даних. NVIDIA Isaac GR00T 1.7, наприклад, використовував близько 32 000 годин реальних демонстрацій і відео від першої особи. До цього NVIDIA додала приблизно 8 000 годин симульованих демонстрацій і прогонів.

Дослідники також перевіряють, наскільки мало людських даних може бути достатньо, щоб модель навчилася переносити навичку на інших роботів і в нові середовища. У 2026 році дослідження HumanEgo показало середній результат 92,5% успішних виконань у чотирьох тестових завданнях після використання 30 хвилин відео від першої особи на кожне завдання. Це результат у контрольованому дослідницькому середовищі, а не доказ того, що 30 хвилин відео можуть навчити комерційного гуманоїда будь-якої роботи. Але він показує ймовірний механізм масштабування: люди дають приклади, програмне забезпечення створює навколо них більше навчального досвіду, а модель вчиться застосовувати навичку ширше.

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

І саме тут прогнози починають звучати майже сюрреалістично.

Десять мільярдів роботів, один мільярд чи значно менше?

Ілон Маск озвучував найагресивніші публічні прогнози. У 2024 році він заявив, що до 2040 року у світі може бути щонайменше 10 мільярдів гуманоїдних роботів, а вартість одного становитиме близько $20 000–25 000. Він також неодноразово говорив, що Optimus потенційно може стати одним із найбільших бізнесів Tesla.

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

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

Goldman Sachs дає ще консервативнішу оцінку. У своєму прогнозі компанія оцінила, що ринок гуманоїдних роботів може сягнути $38 млрд до 2035 року, а лише за цей рік буде відвантажено близько 1,4 млн таких роботів.

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

Реальність 2026 року десь між демонстраційними прототипами й фантазіями про масовий ринок. Boston Dynamics ще не розгорнула Atlas у великих масштабах, а Hyundai планує вийти на виробничу потужність 30 000 гуманоїдних роботів на рік до 2028-го. Це серйозна виробнича амбіція, але до світу з мільярдами гуманоїдів усе ще кілька порядків.

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

Але це не означає, що нічого не відбувається.

BMW добре показує, як виглядає ця рання стадія. На заводі в Спартанбурзі гуманоїдні роботи Figure 02 брали участь у десятимісячному виробничому пілоті. За даними BMW, система була залучена до виробництва понад 30 000 BMW X3, перемістила більш як 90 000 компонентів, напрацювала близько 1 250 годин і зробила приблизно 1,2 млн кроків. Після цього BMW розширила тестування гуманоїдів на завод у Лейпцигу.

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

І це принципова різниця.

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

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

Що тоді буде з роботою?

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

Нинішні прогнози ринку праці не підтверджують такого простого висновку. Звіт World Economic Forum Future of Jobs 2025 прогнозує, що технологічні, демографічні та економічні зміни створять 170 млн робочих місць і витіснять 92 млн до 2030 року — тобто чистий приріст становитиме 78 млн ролей. International Labour Organization також застерігає від прирівнювання впливу ШІ до зникнення професій: її дослідження генеративного ШІ показує, що для багатьох професій трансформація ймовірніша за повну заміну.

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

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

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

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

Тому корисніше запитати не «Чи залишиться в людей цінність?», а «Які людські якості стануть рідкіснішими й дорожчими, коли саме виконання роботи подешевшає?»

Цінність зміщується від виконання до рішень

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

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

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

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

Тепер компанії записують, маркують і продають ці знання.

Можливо, саме наше покоління навчить машини фізичного світу

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

Ми працюємо з технологіями, які безпосередньо оточують цей зсув: AI/ML, embedded-системами, IoT, підключеними пристроями, хмарною інфраструктурою та ПЗ, що взаємодіє з фізичним світом. У таких проєктах, як ReadU6, AI та NLP є лише частиною ширшого продукту, до якого також входять кастомне embedded-обладнання, IoT, web/mobile-рішення та обробка даних у реальному часі. Цінність такого продукту не в тому, що він «AI-powered», а в тому, що інтелект має працювати як частина фізичної, підключеної системи.

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

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

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

Саме тому наступна хвиля ШІ може бути не стільки про те, щоб додати модель у кожен продукт. Складніше завдання — проєктувати системи, яким можна довіряти, коли ШІ отримує можливість діяти.

Командам, які створюють підключені продукти з ШІ, варто визначити ці межі ще на етапі Product Discovery, перш ніж вони перетворяться на жорсткі обмеження в продакшені.

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

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

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

Найдивніша частина роботичної революції

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

Першій хвилі ШІ ми віддали продукти нашого розуму: тексти, код, зображення, документи й розмови. Фізичному ШІ ми починаємо віддавати поведінку наших тіл.

У буквальному сенсі ми створюємо датасет самих себе.

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

Але одне питання після цього стає важко ігнорувати.

Що станеться, коли машини навчаться достатньо, просто спостерігаючи за нами?

The post Ми навчаємо гуманоїдних роботів, як нас замінити appeared first on Allmatics.

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

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

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

В Allmatics ми розглядаємо offline-first у connected-продуктах як проблему меж між компонентами системи, а не як окрему мобільну функцію. Застосунок може бути лише одним шаром між поведінкою пристрою, локальними даними, хмарними сервісами, інтеграціями та AI.

1. Починайте зі сценарію роботи, а не з кешу

Перше запитання – не «Яку локальну базу даних нам обрати?», а «Що користувач обов’язково має мати змогу зробити, коли мережа зникає?»

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

На етапі discovery корисно розділити дії на три групи:

• мають працювати offline;
• можуть працювати в обмеженому режимі;
• справді потребують живого з’єднання із сервером.

Оновлення автентифікації, live-платежі, серверна авторизація або інференс моделі можуть залишатися залежними від мережі. А от збереження вимірювання чи завершення польового чекліста – не обов’язково. Продукт має чітко показувати ці межі, а не ламатися непередбачувано.

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

2. Визначте, де живе «істина»

У класичному online-first застосунку інтерфейс часто запитує дані через API і вважає відповідь сервера авторитетною. Offline-first змінює цю модель.

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

Але «локальне джерело істини» не означає, що пристрій ухвалює всі бізнес-рішення. Backend усе одно може залишатися авторитетним для прав доступу, спільних записів, білінгу, розподілу запасів або стану, який змінюють кілька користувачів. Архітектурне завдання – чітко визначити власника кожного типу даних.

Для кожного важливого об’єкта даних команда має відповісти:

Хто може створити його offline? Чи можна редагувати його з кількох пристроїв? Які поля контролює сервер? Чи можна видалити його локально? Наскільки застарілою може бути локальна копія? Що відбувається, якщо сервер відхиляє зміну, яка чекала в черзі?

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

3. Записувати дані складніше, ніж читати

Читання закешованих даних без мережі відносно просте. Саме offline-запис показує справжню складність продуктової архітектури.

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

Поширені підходи: last-write-wins, злиття на рівні полів, пріоритет сервера, явне вирішення конфлікту користувачем або правила, специфічні для предметної області. Універсально правильного варіанту немає.

Подія сканування в логістиці може бути append-only і легко узгоджуватися. Редагування одного й того самого профілю клієнта з двох пристроїв – уже інша задача. А резервування того самого обмеженого запасу з двох offline-пристроїв – ще складніша.

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

4. «З’єднання відновлено» не означає «все синхронізовано»

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

Тому в якісних offline-продуктах синхронізація моделюється як окремий стан системи.

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

Документація Apple для SwiftData та Core Data показує ще один важливий момент: синхронізацію можна реалізувати через платформні сервіси на кшталт CloudKit, але команді все одно потрібно проєктувати сумісні моделі даних і враховувати, що фонова синхронізація працює за правилами системи, а не як звичайний синхронний API-виклик.

Тому фрази «ми використовуємо CloudKit» або «в нас є локальна база даних» самі по собі ще не означають, що продукт має offline-стратегію.

5. У connected-продуктах межі системи ще важливіші

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

Користувач може мати ідеальний інтернет, але пристрій поруч буде недоступним. Пристрій може продовжувати збирати дані, поки телефон без зв’язку. Мобільний застосунок може бути online, тоді як зовнішній API недоступний.

Тому архітектура connected-продукту має відповідати не лише на запитання «Чи працює застосунок offline?». Вона повинна визначати поведінку всієї системи, коли будь-яка ланка в цьому ланцюгу стає недоступною.

Саме звідси походить наш інженерний підхід в Allmatics: connected-продукти потрібно проєктувати як цілісні системи, а не як окремі mobile-, embedded-, cloud- та AI-проєкти. У кейсі ReadU6 для авіації реалізована система поєднує web/mobile застосунки, кастомний embedded-пристрій, AI/ML, NLP, IoT і обробку даних у реальному часі. Цей кейс важливий тут не тому, що у відкритому описі заявлена конкретна offline-first реалізація, а тому, що він добре показує: мобільну архітектуру не можна проєктувати окремо від решти продукту.

Той самий принцип працює в HealthTech. Кейс Allmatics із телемедицини поєднує мобільний і web-застосунки, API, AI, серверну інфраструктуру та інтеграцію з наявними healthcare-системами. Коли один workflow проходить через кілька систем, межі відмов і синхронізації стають продуктовими рішеннями.

6. Приймайте ці рішення під час Product Discovery

Найдешевше продумати offline-first до того, як модель даних, API-контракти та користувацькі сценарії вже «затверділи».

Під час Allmatics Product Discovery ми мапимо щонайменше шість речей:

1. Критичні offline-сценарії: що має продовжувати працювати без підключення.
2. Власність даних: який шар є авторитетним для кожного об’єкта та поля.
3. Локальне зберігання: що зберігається на пристрої, як довго і за якими правилами безпеки.
4. Стратегія синхронізації: pull, push, фонове оновлення, черги та повторні спроби.
5. Політика конфліктів: що робити, коли локальний і віддалений стани не збігаються.
6. UX-стани: як користувач бачить дані, що очікують синхронізації, уже синхронізовані, застарілі, відхилені або конфліктні.

Для connected-продуктів до цієї карти потрібно додати зв’язок із пристроями та сторонні інтеграції. У результаті ми отримуємо не просто специфікацію мобільного застосунку, а модель відмов і відновлення для всього продукту.

7. Тестуйте переходи між станами, а не лише offline-екран

QA для offline-first має концентруватися на переходах між станами, тому що саме там найчастіше виникають втрата даних і хибне відчуття, що «все спрацювало». Корисна тестова матриця включає: перехід offline до виконання дії, втрату зв’язку під час запису, повторне підключення з операціями в черзі, отримання конфліктного оновлення із сервера, повтор після відхиленої операції та перемикання між Wi-Fi і мобільною мережею під час активної синхронізації.

Локальне зберігання також змінює модель безпеки. Дані на пристрої можуть залишатися там значно довше, ніж тимчасова відповідь API, тому потрібні чіткі правила: що дозволено зберігати, як захищаються чутливі записи, що видаляється під час logout і що відбувається, якщо пристрій загубили або ним користуються кілька людей. Offline-можливості не повинні непомітно збільшувати обсяг чутливих даних, що залишаються на пристрої.

Observability також потребує такого самого підходу. Backend-dashboard, який показує успішні API-запити, не відображає всю картину, якщо дії можуть годинами залишатися в локальній черзі. Продуктовій команді потрібна достатня телеметрія, щоб відрізнити нормальний offline-стан від зламаного процесу синхронізації – і водночас не логувати чутливі payload без потреби.

Практичний тест – це не просто «Чи відкривається застосунок у режимі польоту?». Питання в тому, чи може продукт безпечно пройти через стани offline, очікування, повторного підключення, синхронізації та конфлікту, не втративши намір користувача і не приховуючи невизначеність. Така поведінка під час відмов і відновлення має бути частиною acceptance criteria ще до релізу.

Рішення, яке потрібно прийняти до початку розробки

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

Але якщо користувачі повинні продовжувати працювати в тунелях, на складах, у лікарнях, в авіаційному середовищі, на віддалених об’єктах або в нестабільних мобільних мережах, offline-поведінку не варто відкладати до моменту, коли QA знайде перший зламаний workflow.

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

Якщо ваш roadmap включає mobile, connected hardware, cloud-інтеграції або AI, Allmatics може допомогти промапити ці межі під час Product Discovery – до того, як вони перетворяться на окремі інженерні проблеми.

The post Offline-First архітектура мобільних застосунків: практичний гайд appeared first on Allmatics.

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

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

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

У 2026 році ця різниця стала особливо помітною. Gartner відносить physical AI до ключових технологічних трендів у ланцюгах постачання. Йдеться про поєднання моделей ШІ, IoT-сенсорів, робототехніки та систем автоматизації, які дають змогу в реальному часі збирати сигнали з фізичного середовища, аналізувати їх і запускати відповідні дії у виробництві, на складах і в транспорті.

Звіт MHI та Deloitte за 2026 рік показує масштаб інвестиційного запиту. Дослідження охопило понад 500 керівників у сфері ланцюгів постачання. 56% організацій планують збільшити витрати на інновації, 52% готуються інвестувати понад 1 мільйон доларів, а 17% понад 10 мільйонів. Проте сам факт купівлі техніки ще не створює результату. Потрібно, щоб пристрої, дані та операційні системи працювали як єдиний контур.

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

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

Надійніший корпус продовжує строк служби пристрою. Програмний шар продовжує життєвий цикл усього продукту.

Що входить у програмний шар для логістичного обладнання

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

• застосунок на самому пристрої або на edge-рівні;
• безпечну ідентифікацію пристрою та керування конфігураціями;
• телеметрію щодо використання, помилок, батареї, зв’язку й продуктивності;
• API або middleware для обміну даними з WMS, TMS, ERP, inventory-системами та платформами клієнта;
• хмарне або локальне середовище для зберігання й обробки даних;
• окремі дашборди для операційної команди, служби підтримки та product team;
• керування оновленнями, доступами, аудитом і вразливостями.

Не кожен продукт потребує всіх семи компонентів на старті. Для handheld scanner перша версія може складатися з Android-застосунку та вебпанелі. Для телематичного модуля у транспорті можуть знадобитися edge-обробка, event streaming, правила для роботи без стабільного інтернету та інтеграції із системами маршрутизації й технічного обслуговування.

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

У матеріалі Zebra про модернізацію складів, опублікованому в червні 2026 року, цей зв’язок сформульовано практично. Модернізація дає результат, коли захищені мобільні пристрої цілеспрямовано поєднують із програмними платформами, а нові workflow-функції додають без повної заміни WMS.

Чому вдосконалення самого пристрою має межу

Виробник не бачить, як продукт використовують після продажу

Пристрій може бути технічно надійним, але погано відповідати реальному workflow.

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

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

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

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

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

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

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

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

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

Зчитування не пов’язане з операційною системою

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

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

1. Перевіряє код.
2. Пов’язує його з користувачем, локацією, замовленням, активом або відправленням.
3. Застосовує потрібні бізнес-правила.
4. Оновлює операційну систему.
5. Повертає працівникові підтвердження або інструкцію.
6. Зберігає подію для аудиту.

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

Це особливо добре видно на переході до 2D-кодів. У GS1 2D Barcode Playbook 2026 прямо вказано, що сумісного сканера недостатньо. Middleware, ERP, WMS, inventory, fulfilment і аналітичні системи мають уміти приймати, зберігати та використовувати розширені атрибути: серійний номер, партію, дату виробництва, термін придатності або версію продукту. GS1 також рекомендує документувати й перевіряти наскрізний потік даних від сканера до backend-систем.

Зчитати код технічно нескладно. Перетворити його дані на керовану операцію значно важче.

Відмінність між продуктами легко скопіювати

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

Програмна платформа створює навколо пристрою складніший для копіювання контур:

• історію продуктивності;
• клієнтські workflow;
• готові інтеграційні шаблони;
• засоби керування парком пристроїв;
• аналітику;
• ролі адміністратора;
• API;
• інфраструктуру оновлень і підтримки.

Для клієнта це означає менше ручної роботи навколо обладнання. Для виробника з’являється основа для платних модулів аналітики, fleet management, розширеної підтримки, benchmarking або галузевих workflow.

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

Реальний кейс: аналітика для захищених сканерів

Allmatics працювала з британським виробником rugged mobile devices для логістики й складських операцій. Компанія хотіла додати веб і мобільну систему, яка збирала б та аналізувала дані про використання сканерів штрихкодів.

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

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

До MVP увійшли:

• Android-застосунок для сканування та збору даних;
• вебзастосунок для аналітики й керування користувачами;
• серверне середовище;
• Product Requirements Document;
• порівняння результатів незалежно від конкретної моделі пристрою.

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

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

Підтверджений результат цього кейсу доволі конкретний. Виробник додав до свого hardware offering повноцінний програмний компонент і дав клієнтам доступ до операційних даних, яких раніше не було. Discovery зайняло два тижні, перший MVP був готовий приблизно за три місяці. Деталі опубліковані в кейс-стаді Allmatics про barcode scanning analytics.

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

П’ять можливостей, які варто спроєктувати першими

Ідентифікація пристрою

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

Без надійної ідентифікації аналітика парку пристроїв швидко стає сумнівною.

Збір подій

Спочатку потрібно визначити, які події справді впливають на рішення.

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

Збирати все підряд дорого й не завжди корисно.

Інтеграційні контракти

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

API, webhooks, message queues, batch-файли та offline synchronization мають різні сценарії застосування. Вибір залежить від середовища клієнта, якості зв’язку й допустимого часу затримки.

Операційні дашборди

Кожен дашборд повинен відповідати на питання конкретної ролі.

Warehouse manager, support engineer і product owner потребують різних даних. Екран, де зібрано всі доступні метрики, зазвичай лише ускладнює пошук відповіді.

Керування життєвим циклом

Connected hardware потребує політик оновлення, доступів, логування, періоду підтримки та роботи з вразливостями.

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

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

Що купувати, що інтегрувати, а що створювати самостійно

Виробникові обладнання не потрібно розробляти кожен компонент з нуля.

Стандартні можливості на кшталт identity provider, infrastructure monitoring, mobile device management або cloud storage часто доцільніше придбати.

WMS, TMS, ERP та інші операційні системи клієнта слід інтегрувати, а не відтворювати.

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

Для виробника сканерів це можуть бути device telemetry, benchmarking, аналіз якості зчитування та workflow, адаптовані до конкретного обладнання. Для виробника сенсорів: edge-логіка, керування калібруванням, доменні правила сповіщень та спеціалізована аналітика.

Практичне запитання звучить так: чи помітить клієнт, якщо цю функцію замінити універсальним інструментом?

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

Ознаки того, що hardware-only модель уже стала обмеженням

До типових сигналів належать:

• клієнти регулярно просять дашборд, API або віддалене налаштування;
• підтримка не може діагностувати проблему без скриншотів і серійних номерів;
• product team майже не отримує даних із пристроїв після їх розгортання;
• кожен enterprise-клієнт потребує окремої інтеграції;
• покупці порівнюють пристрої переважно за ціною;
• версії firmware та застосунків складно відстежувати;
• дані є на пристрої, але операційна команда не може ними скористатися;
• компанія хоче recurring revenue, але не має повторюваної програмної цінності.

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

Пристрій лише відкриває систему

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

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

Gartner поєднує збір сигналів, аналіз і виконання дій в одному операційному контурі. MHI та Deloitte показують, що компанії збільшують інвестиції у взаємопов’язані технології. Zebra розглядає rugged devices і software platforms як частини однієї програми модернізації. GS1 окремо наголошує: можливості нового сканера залишаться невикористаними, якщо backend не здатен приймати та застосовувати збагачені дані.

Для виробника логістичного обладнання ключове питання полягає не в кількості функцій у наступній моделі.

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

Саме для цього потрібен програмний шар.

Плануєте додати програмний компонент до логістичного пристрою?

Allmatics допомагає логістичним і hardware-компаніям перевіряти продуктові ідеї, визначати архітектуру та створювати web, mobile, cloud і embedded-рішення навколо фізичних продуктів. У портфоліо компанії є системи керування пристроями, barcode scanning analytics, IoT та інші рішення для логістики.

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

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

The post Програмний шар для логістичного обладнання appeared first on Allmatics.

21 липня 2026 року Microsoft і Mistral оголосили про багатомільярдне розширення партнерства. Угода передбачає додаткові GPU-потужності в Європі, інтеграцію більшої кількості моделей Mistral у Microsoft Foundry та Copilot Studio, а також підтримку різних сценаріїв розгортання: від публічної хмари до повністю ізольованих середовищ.

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

Оголошення Microsoft і Mistral з’явилося на тлі подальших інвестицій Європейського Союзу в AI Factories та AI Gigafactories. Європа прагне розширити власні обчислювальні потужності, підтримати розвиток регіональних моделей і зменшити залежність від інфраструктури, яку контролюють за межами ЄС.

Це важливо.

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

Розташування серверів відповідає лише на одне питання. На всі інші відповідає архітектура програмного забезпечення.

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

Усі ці рішення закладаються в кодовій базі.

Архітектура суверенного ШІ не обмежується місцем зберігання даних

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

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

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

Тоді контроль має кілька рівнів:

• Контроль над даними: де зберігаються вихідні дані, prompts, журнали подій та embeddings.
• Контроль над моделями: які моделі можна використовувати, адаптувати, замінювати або розгортати у приватному середовищі.
• Контроль над застосунком: кому належать workflow, права доступу, інтерфейси та бізнес-логіка.
• Операційний контроль: чи продовжить система працювати під час проблем із мережею, збою провайдера або обмеження сервісу.
• Комерційний контроль: чи залишатиметься економіка продукту життєздатною після зміни обсягів використання, вартості токенів або ліцензійних умов.

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

Наприклад, AI-застосунок може працювати в європейському хмарному регіоні, але залежати від agent framework конкретного провайдера, закритого vector storage, пропрієтарних інструментів оцінювання та prompts, розкиданих по всьому застосунку. У такому разі майбутня міграція вимагатиме серйозного переписування системи.

Інфраструктура регіональна. Залежність залишається глибокою.

Де насправді ховається залежність від AI-провайдера

Більшість команд не створюють vendor lock-in навмисно. Він формується поступово.

Proof of concept починається з одного API-запиту. Тест працює. Потім команда додає retrieval, обробку документів, tools, memory, права доступу й адміністративну панель. Через шість місяців AI-провайдер уже вбудований майже в кожен рівень продукту.

Залежність зазвичай виникає у чотирьох місцях.

1. Логіка застосунку, прив’язана до конкретної моделі

Різні моделі по-різному працюють із prompts, tool calls, structured outputs, мультимодальними даними та контекстним вікном.

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

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

2. Пропрієтарна retrieval-інфраструктура

Retrieval-augmented generation зазвичай охоплює завантаження документів, chunking, embeddings, vector storage, metadata filters і ranking.

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

Це стає особливо болісно після обробки мільйонів записів.

3. Workflow усередині зовнішніх платформ

Low-code платформи для AI-агентів зручні для перевірки гіпотез. Проблеми починаються тоді, коли approval rules, exception handling, integrations та операційні знання залишаються всередині платформи, яку неможливо відтворити в іншому середовищі.

Модель можна замінити. Workflow — уже ні.

4. Журнали подій та дані оцінювання

Production AI потребує більшого, ніж звичайні application logs.

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

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

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

Програмний шар — саме та частина, якою бізнес може володіти

Моделі змінюватимуться. Ціни рухатимуться. На ринку з’являтимуться сильніші провайдери.

Довгострокову цінність має програмний шар навколо моделі.

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

Цей підхід визначав архітектуру кількох проєктів Allmatics.

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

За даними кейсу з AI-оптимізації контенту, новий workflow скоротив операційні витрати більш ніж утричі та прискорив виробництво контенту.

Ключове архітектурне рішення полягало в розділенні компонентів.

Основна платформа й надалі відповідала за бізнес-процес. AI-функціональність працювала через чітко визначений сервісний шар. Prompts, processing logic і майбутні зміни моделей можна було керовано оновлювати всередині цього сервісу без перебудови головного застосунку.

Такий підхід корисний далеко не лише для генерації контенту.

Окремий AI-шар може підтримувати:

• кількох постачальників моделей;
• приватні та хмарні моделі;
• вибір моделі залежно від завдання або чутливості даних;
• централізовані правила доступу;
• версіонування prompts;
• кешування та контроль витрат;
• fallback-сценарії;
• єдиний моніторинг.

Провайдер можна змінити, а бізнес-процес залишиться стабільним.

Модель — лише один із компонентів AI-продукту

Обробка документів добре показує цю різницю.

Компанія може сформулювати потребу як «використати AI для обробки документів». Насправді модель виконує лише частину роботи.

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

Саме такий продуктовий підхід Allmatics застосував під час розробки DocStreams — AI-платформи для обробки резюме.

Платформа перетворює неструктуровані PDF-резюме на стандартизовані структуровані документи. Її цінність створює повний workflow: обробка файлів, вилучення даних, правила форматування, валідація та експорт.

Нова OCR-модель може покращити якість розпізнавання. Але вона не замінить сам продукт.

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

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

Регульованим індустріям потрібен контроль на рівні workflow

Healthcare показує цю різницю особливо чітко.

Клінічний AI-асистент може використовувати сильну медичну модель, але сама модель не керує доступом до даних пацієнта, consent logic, ролями медичного персоналу, audit history, строками зберігання документів, інтеграціями або human approval.

Усе це має працювати у програмному шарі навколо моделі.

В одному з HealthTech-проєктів Allmatics команда створила AI-асистента на базі Google Med-PaLM 2 для приватних медичних провайдерів. Робота охоплювала повноцінне медичне середовище, а не окремий чат-інтерфейс.

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

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

Згідно з підтвердженим відгуком клієнта на Clutch, частка замовлень, які надсилали факсом, скоротилася приблизно з 90% до 20%, тоді як онлайн-реєстрація зросла до 80%.

Результат дала перебудова самого процесу навколо програмного забезпечення. Одна модель не могла б цього забезпечити.

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

Тому архітектура суверенного ШІ особливо важлива у healthcare, aviation, промислових системах, logistics та інших середовищах, де безперервність і відтворюваність рішень мають критичне значення.

Як виглядає архітектура без жорсткої прив’язки до одного провайдера

Універсальної архітектури для всіх AI-продуктів не існує. Розумний дизайн починається з конкретного навантаження, типу даних і рівня ризику.

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

Розміщуйте моделі за внутрішнім AI gateway

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

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

Запит до служби підтримки можна передати швидкій керованій моделі. Чутливий документ — приватній. Відповідь із низькою впевненістю можна спрямувати іншій моделі або на перевірку людині.

Застосунку не потрібно знати всі технічні деталі реалізації.

Зберігайте бізнес-логіку поза prompts

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

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

Prompt може просити модель повернути структуровану відповідь. Але backend усе одно повинен перевірити, чи відповідає результат схемі та бізнес-правилам.

Контролюйте data pipeline

Завантаження документів, preprocessing, metadata, правила зберігання та видалення потрібно проєктувати як повноцінні частини продукту.

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

Це також спрощує майбутню міграцію. Бізнес може повторно створити embeddings, змінити vector database або впровадити інший retrieval-підхід, не втрачаючи вихідні дані та metadata, потрібні для відновлення індексу.

Вбудовуйте observability у сам продукт

Production-команди повинні мати власну операційну історію.

Щонайменше потрібно відстежувати:

• користувача або систему, які ініціювали запит;
• модель і її версію;
• prompt або версію prompt;
• знайдений контекст;
• tool calls і зовнішні дії;
• latency та вартість;
• результати валідації;
• правки, внесені людиною.

Ця інформація допомагає engineering-командам порівнювати моделі та розбирати збої. Вона також дає product owners чесніше розуміння того, де AI створює цінність, а де додає ручної роботи.

Проєктуйте систему для кількох сценаріїв розгортання

Microsoft і Mistral прямо підтримують cloud, cloud-connected та повністю disconnected deployment. Такий діапазон відображає те, наскільки різними стали enterprise-навантаження.

Частині завдань потрібен хмарний масштаб. Інші вимагають локальної обробки через latency, конфіденційність або вимоги до безперервної роботи.

Портативний application layer дозволяє поєднати обидва підходи.

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

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

Суверенний ШІ не означає, що все потрібно переносити on-premises

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

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

Для багатьох звичайних навантажень керована cloud-модель залишається практичним вибором.

Якісна архітектура залишає цей вибір відкритим.

Вона дозволяє зберігати низькоризикові високонавантажені задачі у керованому середовищі, а вибрані workflow переносити у private cloud, локальну інфраструктуру або на edge-пристрої.

Allmatics працює із захищеною обробкою даних on-premises, private AI development та кастомними AI/ML-системами. Але стартовою точкою мають бути бізнесові обмеження, а не упередження на користь одного типу deployment.

Перед початком проєкту варто відповісти на кілька питань:

• Які дані не можуть залишати межі організації?
• Які workflow повинні працювати під час проблем з інтернетом або зовнішнім сервісом?
• Де потрібна передбачувана latency?
• Наскільки глибока кастомізація моделі потрібна?
• Як часто модель має оновлюватися?
• Які операційні ресурси вже є всередині компанії?

Для одного бізнесу sovereign architecture означатиме повністю ізольовану систему. Для іншого — provider-neutral застосунок, який працює одразу з кількома керованими сервісами.

Обидва підходи можуть бути виправданими.

Чи може ваша компанія реально перенести свій AI?

Простий architecture review допоможе зрозуміти, чи справді AI-продукт є портативним, чи лише здається таким.

Поставте собі п’ять запитань:

1. Чи можемо ми замінити основну модель без переписування ключового бізнесового workflow?
2. Чи знаємо ми, де зберігаються prompts, logs, embeddings та evaluation data?
3. Чи має AI-функціональність чітку сервісну межу й внутрішній API?
4. Чи можна перенести вибрані навантаження у приватне або локальне середовище?
5. Чи продовжать ключові частини продукту працювати, якщо зовнішній AI-сервіс стане недоступним?

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

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

Де тут Allmatics

Суверенний ШІ створює попит на інфраструктуру, моделі, правові механізми й security controls. Але водночас він створює велике завдання у сфері software engineering.

Хтось усе одно має побудувати застосунок, який з’єднає дані компанії, AI-моделі та операційні workflow.

Allmatics розробляє кастомні AI- та software-продукти для healthcare, HRTech, retail, logistics, aviation та інших індустрій із великими обсягами даних. Робота може охоплювати:

• AI architecture та product discovery;
• інтеграцію й orchestration моделей;
• кастомні web- і mobile-застосунки;
• private та hybrid AI deployment;
• pipelines для обробки документів;
• інтеграції з ERP, CRM, EHR та ATS;
• role-based access і workflow погодження;
• monitoring, audit logs та human review;
• модернізацію наявних платформ.

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

Для команд, які переводять AI-функціональність із пілота в production, корисним першим кроком часто стає architecture review. Він дозволяє побачити залежності від моделей, рух даних, інтеграційні ризики та компоненти, які варто залишити портативними або приватними.

Обговоріть із командою Allmatics AI/ML Development програмний шар, на якому тримається ваш AI-продукт.

Поширені запитання

Що таке архітектура суверенного ШІ?

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

Чи вимагає суверенний ШІ розгортання on-premises?

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

Як кастомне програмне забезпечення зменшує залежність від AI-провайдера?

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

The post Суверенний ШІ для бізнесу: архітектура без vendor lock-in appeared first on Allmatics.

Якщо ви керуєте рітейл-платформою, комерційним бекендом чи будь-чим, що стосується checkout, агентна комерція вже настала – навіть якщо людина досі підтверджує більшість замовлень. Реальне питання вужче. Чи можуть ваші системи передати рішення про покупку програмному забезпеченню, яке ви не контролюєте, перевірити, на що саме це ПЗ мало право, і все одно довіряти результату?

Від рекомендаційних систем до агентної комерції

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

Останні дані Adobe про трафік пояснюють, чому це перестало бути нішевою поведінкою. За даними TechCrunch, трафік з AI-джерел на роздрібні сайти США зріс на 393% рік до року в першому кварталі 2026-го. Цей трафік конвертувався на 42% краще за звичайний у березні 2026-го – повний розворот порівняно з березнем 2025-го, коли AI-трафік конвертувався на 38% гірше. Ці відвідувачі з AI-джерел також проводили на сайті на 48% більше часу і генерували на 37% більше доходу за відвідування. Такі відвідувачі, як правило, приходять на пізнішому етапі прийняття рішення, ніж покупці з традиційних каналів. Це все ще AI-асистоване дослідження товару, а не повністю делегована покупка. Але це показує, що значна частина шопінг-подорожі вже перемістилася в AI-інтерфейси, і рітейлери починають будувати свої системи під цю реальність, а не сприймати її як цікавинку в аналітичній панелі.

Salesforce офіційно підтвердив тренд

6 липня 2026 року Salesforce вивів Agentforce Commerce з пілотної стадії у загальну доступність. Цю дату варто сприймати радше як сигнал, ніж просто оновлення продукту. Shopper Agent тепер веде клієнта від пошуку товару до оформлення замовлення на власному сайті рітейлера. Buyer Agent обробляє B2B-замовлення через WhatsApp і SMS без потреби входити в портал. Merchant Agent виконує backoffice-роботу з каталогом і акціями звичайною мовою замість системи правил.

Крок з дистрибуції важливіший за сам перелік функцій. Salesforce підтвердив нативну інтеграцію з ChatGPT цього ж місяця. AI Mode у Google Search і застосунок Gemini приєднаються пізніше цього літа. Це означає, що AI-агент покупця, який працює в інтерфейсі, який рітейлеру не належить, може завершити покупку безпосередньо на сайті цього рітейлера. У Salesforce є причина діяти швидко. За власними даними компанії про святковий сезон продажів, рітейлери, які запустили власних shopper-агентів, наростили продажі на 59% швидше за тих, хто цього не зробив. AI-трафік конвертувався приблизно у вісім разів краще, ніж трафік із соцмереж. Коли платформа такого масштабу випускається так швидко, фраза “стежимо за розвитком подій” перестає бути адекватною відповіддю.

Дві сторони агентної комерції: покупки та операції рітейлу

Власний поділ продуктів Salesforce – гарна карта для орієнтування тут. Shopper Agent працює на клієнтській стороні: пошук, кошик, оформлення замовлення. Buyer Agent обробляє B2B-замовлення. Merchant Agent веде роботу з каталогом і акціями за лаштунками. Це дві різні задачі. Клієнтська агентна комерція – це коли агент покупця шукає й купує товар, досі з кроком підтвердження в більшості флоу сьогодні. Агентні операції рітейлу – це коли власні системи рітейлера автономно приймають рішення щодо ціноутворення, запасів і вмісту вітрини, взагалі без участі клієнта. На операційній стороні найбільше значення мають три патерни: динамічне ціноутворення, автономні рішення щодо запасів і персоналізація вітрини на рівні сесії.

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

Управління запасами – це там, де цифри стають конкретними, і це патерн з найбільш переконливими доказами реального впровадження. За даними Walmart, її система Self-Healing Inventory автоматично перенаправляє надлишкові запаси в магазини, де вони потрібні, перш ніж надлишок перетвориться на списання. Вона вже заощадила компанії понад $55 мільйонів. Зараз Walmart розширює цю систему за межі США – на Коста-Ріку, Мексику та Канаду.

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

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

Більшість омніканальних проєктів вирішували проблему координації: синхронізувати кошик між мобільним і десктопом, узгодити акцію в магазині з акцією на сайті. Це вирішили на рівні інтерфейсу. Бекенд-системи під ним – каса, ERP, управління складом, CRM – здебільшого лишалися окремими. Їм потрібно було лише виглядати узгоджено для людини-покупця. Ніхто не вимагав, щоб вони спілкувалися одна з одною в реальному часі.

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

Уніфікована комерція – типова архітектурна відповідь на цю проблему. Це спільний, оновлюваний у реальному часі операційний шар, який дає кожному каналу узгоджений погляд на товари, ціни, запаси, замовлення та дані клієнтів. Це не завжди вимагає заміни кожної бекенд-системи, але вимагає усунення конфліктних версій істини між ними. Саме це – передумова, яку найчастіше пропускають демонстрації постачальників рішень з агентної комерції. Бенчмарк Manhattan Associates за 2026 рік охопив понад 400 спеціалізованих рітейлерів у Північній Америці, EMEA та Латинській Америці. Лише 7% отримали статус лідера з уніфікованої комерції, тоді як 33% лишилися в базовій категорії. Лідери демонстрували майже вдвічі вищі темпи зростання, ніж найменш зрілі рітейлери. Саме цей розрив – реальна вузька ланка, а не вибір AI-моделі.

Що насправді стримує більшість рітейлерів від агентної комерції

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

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

Фрагментація даних – друга перешкода. Дані про клієнтів лежать у CRM. Запаси – в ERP. Поведінка на сайті – в аналітичній платформі. Дані про маржу – у таблиці, яку фінансовий відділ оновлює щомісяця. Дослідження Commercetools про готовність до агентної комерції показало, що 81% рітейлерів кажуть, що проблеми з якістю даних впливають на бізнес-рішення принаймні іноді: 45% – іноді, 36% – часто. Агент не може працювати з даними, які не пов’язані між собою. Об’єднання цих даних має відбутися до того, як будь-який агент піде в продакшн, а не після.

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

Комерційному агенту потрібно більше, ніж доступ до API

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

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

Це не абстрактна теорія. Agent Payments Protocol від Google вибудовує криптографічно перевірюваний ланцюжок між тим, що запросив покупець, що було схвалено і що врешті було списано. Intent Mandate фіксує запит на покупку та його межі. Cart Mandate записує точний перелік товарів і ціну. Payment Mandate передає це схвалення платіжній мережі. Залежно від флоу, покупець підтверджує в реальному часі або заздалегідь авторизує агента діяти пізніше в межах цих визначених лімітів. У будь-якому разі ланцюжок підписаних мандатів залишає слід аудиту: що було запитано, що агенту дозволили купити і що було сплачено. Agentic Commerce Protocol від OpenAI використовує споріднений підхід. OpenAI ніколи не стає стороною-продавцем за договором. Кожен делегований платіжний токен обмежений конкретною сумою і строком дії, прив’язаний до конкретного продавця – і все це до того, як запит побачить власний платіжний процесор рітейлера. Рітейлерам, які будують інфраструктуру для агентної комерції, потрібен такий самий обмежений і задокументований шар авторизації, а не просто відкритий API. Це стосується як тих, хто відкриває свій сайт для чужого агента покупок, так і тих, хто керує власними агентами ціноутворення й запасів.

Чого нас навчила побудова POS-платформи для рітейлу

Ми детально описали повну розробку платформи для взаємодії з клієнтами, підключеної до POS, у попередньому кейсі – для американського рітейл-стартапу з мережею дилерів і партнерів. Коротко: у клієнта не було уніфікованого шару даних, а повна заміна POS не розглядалась як варіант. Саме це обмеження визначило весь проєкт.

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

Ми побудували її на .NET, AngularJS, Google Cloud та Kubernetes. Цей стек підтримував мультитенантну архітектуру, здатну масштабуватися на мережі партнерів, не перетворюючи кожного нового клієнта на окремий інженерний проєкт. Ми також від самого початку, ще на етапі proof-of-concept, впровадили безпеку, узгоджену зі стандартом SOC 2, замість того, щоб додавати її пізніше.

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

Якщо передати той самий конекторний шар зовнішньому AI-агенту, а не лише власним дашбордам, з’являється новий перелік вимог. Машинозчитуваний каталог товарів, який агент справді може розпарсити. Ендпоінт запасів у реальному часі замість нічної синхронізації. Обмежені права для кожного агента замість одного спільного API-ключа. Ідемпотентний шлях оформлення замовлення. Визначений резервний сценарій на випадок затримки синхронізації POS. Журнал кожної дії, яку виконав агент, і причини цієї дії.

З чого почати, якщо ви не починаєте з нуля

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

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

Коли цей шар стабільний, оберіть найвигідніший і найменш ризикований варіант використання для першого агента: динамічне ціноутворення в одній категорії або поповнення запасів на основі попиту для товарів-бестселерів. Чітко обмежте його масштаб. Побудуйте механізм ручного втручання людини до запуску, а не після того, як інцидент змусить вас це зробити. Протестуйте його на контрольній групі протягом 60-90 днів і чесно оцініть результат перед розширенням.

За прогнозом Gartner, 40% корпоративних застосунків матимуть вбудованих вузькоспеціалізованих AI-агентів до кінця 2026 року – порівняно з менш ніж 5% у 2025-му. За оцінкою Bain, агентна комерція становитиме 15-25% загальних роздрібних продажів у США до 2030 року – ринок обсягом $300-500 мільярдів. Глобальна оцінка McKinsey сягає $3-5 трильйонів того ж року.

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

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

Наша робота у сферах Web/Mobile Development та AI/ML Development охоплює саме цей рівень. Це означає конекторну архітектуру, яка відкриває доступ до даних POS, запасів і клієнтів у реальному часі без примусової заміни платформи. Це також означає визначення меж повноважень агента – що система може лише пропонувати, а що їй дозволено виконувати самостійно. Ми детально описали повну розробку POS-платформи для рітейлу, якщо вам потрібні деталі архітектури, згаданої вище. Наш ширший погляд на інфраструктуру для рітейлу та e-commerce – гарна відправна точка, якщо ви на ранньому етапі планування.

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

Часті запитання

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

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

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

The post Агентна комерція у 2026 році: що потрібно рітейл-системам, перш ніж ШІ зможе купувати appeared first on Allmatics.

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

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

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

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

Чому cloud-first підходу вже недостатньо

Протягом багатьох років стандартна архітектура мобільного AI була простою.

Мобільний застосунок збирав вхідні дані. Backend передавав їх до моделі у хмарі. Застосунок чекав на відповідь і показував результат користувачу.

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

Однак тепер це вже не єдиний практичний варіант.

Актуальні рекомендації Android щодо AI чітко розділяють on-device, cloud і hybrid підходи. У документації серед переваг локального inference зазначаються робота без інтернету, локальна обробка даних і відсутність додаткової вартості за кожен виклик моделі для підтримуваних on-device рішень.

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

Apple рухається у схожому напрямку. На WWDC26 компанія розширила Foundation Models framework, щоб розробники могли працювати з on-device моделями Apple, Private Cloud Compute та зовнішніми постачальниками моделей через спільний інтерфейс.

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

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

Що змінилося для on-device AI у мобільних застосунках

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

У червні 2026 року Apple опублікувала подробиці про третє покоління Apple Foundation Models.

Лінійка включає дві on-device моделі. AFM 3 Core продовжує розвиток щільної моделі Apple приблизно на 3 мільярди параметрів. AFM 3 Core Advanced використовує розріджену архітектуру на 20 мільярдів параметрів і активує від 1 до 4 мільярдів параметрів залежно від запиту.

Apple також робить важливе уточнення: потужніша on-device модель орієнтована на найпродуктивніші пристрої з Apple silicon. Отже, командам і надалі потрібно враховувати можливості конкретного обладнання та доступність функцій на різних пристроях.

Android використовує інший платформний підхід.

Gemini Nano працює через системний сервіс Android AICore на сумісних пристроях. AICore використовує апаратні можливості пристрою для inference та керує розповсюдженням і оновленням моделей на системному рівні.

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

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

Це вже не дослідницькі демонстрації. Це платформні можливості, які продуктові команди можуть оцінювати ще на етапі discovery та проєктування архітектури.

AI-native не означає лише on-device

Термін «AI-native» часто використовують занадто вільно.

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

Практичніше розглядати цей термін з погляду архітектури.

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

Для мобільного продукту це означає, що команда повинна заздалегідь відповісти на кілька питань:

1. До яких даних може отримувати доступ AI-функція?
2. Які завдання повинні працювати без підключення до мережі?
3. Яку затримку відповіді готові прийняти користувачі?
4. Які пристрої потрібно підтримувати?
5. Що відбувається, коли локальний inference недоступний?
6. Які завдання потребують хмарних моделей або спільного контексту?
7. Як команда оцінюватиме якість результатів після релізу?
8. Як змінювати моделі або промпти, не порушуючи поведінку продукту?

Ці питання впливають на data layer, API, дозволи, користувацькі сценарії, телеметрію та fallback logic.

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

On-device AI покращує приватність, але не вирішує всі проблеми приватності

Приватність є одним із найсильніших аргументів на користь локального inference.

Коли завдання повністю виконується на пристрої, вхідні дані не потрібно передавати до віддаленого inference endpoint. Наприклад, документація Android описує, як Gemini Nano обробляє запити локально і як AICore ізолює окремі запити.

Однак сам факт локального inference ще не робить застосунок приватним.

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

Тому команда повинна бачити повну карту руху даних.

Для кожної AI-функції архітектура має чітко визначати:

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

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

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

Чому AI-агенти змінюють архітектуру мобільних продуктів

On-device inference є лише однією частиною поточних змін.

Друга частина пов’язана з agentic behavior.

Звичайна AI-функція генерує відповідь. Агент може використовувати інструменти та виконувати послідовність дій для досягнення поставленої мети.

Згідно з прогнозом Gartner за 2025 рік, до кінця 2026 року до 40% корпоративних застосунків можуть містити інтегрованих AI-агентів для конкретних завдань.

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

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

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

Також потрібно розділяти зворотні та незворотні дії.

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

На практиці багато мобільних продуктів з агентною логікою використовуватимуть гібридну оркестрацію.

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

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

Де команди помиляються з поділом між on-device і cloud

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

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

Пізніше команда вирішує, що частина функціональності повинна працювати локально.

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

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

Трапляється і протилежна помилка.

Команда може перенести забагато обробки на пристрій, оскільки локальний inference здається дешевшим або безпечнішим для приватності. Однак у власних рекомендаціях Android зазначає, що on-device моделі можуть бути менш потужними за хмарні альтернативи та вимагати сумісного обладнання.

Обмеження пристроїв також різняться.

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

Тому стратегія «запускаємо все локально» не є серйозним архітектурним підходом.

Так само як і «відправляємо все у хмару».

Корисніше ставити конкретніше питання: яке середовище виконання найкраще підходить саме для цього завдання?

Практичний фреймворк для on-device AI у мобільних застосунках

Більшість архітектурних дискусій стають простішими, якщо оцінювати кожну AI-функцію окремо.

1. Чи повинна функція працювати офлайн?

Якщо так, продукту потрібна локальна функціональність.

Це не завжди означає, що весь AI-workflow має повністю залишатися на пристрої. Невелика локальна модель може забезпечувати обмежений набір можливостей, тоді як хмарна модель виконуватиме складніші запити після відновлення з’єднання.

Головне — спроєктувати офлайн-поведінку заздалегідь.

Продукт не повинен вперше «дізнаватися», як він працює без інтернету, вже після того, як користувач втратив з’єднання.

2. Чи критична для функції мінімальна затримка?

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

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

Водночас команда повинна вимірювати реальну продуктивність на цільових пристроях. On-device не завжди означає миттєво.

Апаратне забезпечення досі має значення.

3. Чи обробляє функція чутливі дані?

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

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

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

4. Чи потрібен завданню широкий контекст або потужніша модель?

Деякі задачі очевидно краще виконувати у хмарі.

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

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

Хмара має чітку роль.

5. Як часто змінюватиметься модель або її поведінка?

Механізм оновлення має значення.

AICore в Android керує розповсюдженням Gemini Nano і майбутніми оновленнями на системному рівні. Інші локальні моделі можуть використовувати інші механізми доставки. Хмарні моделі, своєю чергою, можна змінювати незалежно від релізу мобільного застосунку.

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

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

6. Що відбувається, коли одна частина архітектури недоступна?

Гібридні системи потребують чітких fallback rules.

Що відбувається, якщо пристрій не підтримує локальну модель?

Що робити, якщо хмарний сервіс не відповідає?

Чи може користувач продовжувати роботу з обмеженою функціональністю? Чи потрібно поставити завдання в чергу? Чи функція має повністю стати недоступною?

Це не лише технічні, а й продуктові рішення.

Команда повинна прийняти їх ще до початку реалізації.

Інструменти розробки стають швидшими, але архітектура нікуди не зникає

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

У травні 2026 року Google представив можливість створювати native Android applications у Google AI Studio.

Розробники можуть генерувати Android-проєкти на Kotlin за допомогою промптів, використовувати вбудований Android Emulator, встановлювати збірки на фізичний пристрій і публікувати їх у внутрішній testing track Google Play.

Це може скоротити час на прототипування та початковий scaffolding.

Однак швидша генерація коду не усуває складні частини production development.

Команди все одно повинні приймати рішення щодо безпеки, архітектури даних, оцінювання моделей, дозволів, offline state, backend integration, observability, тестування та довгострокової підтримки.

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

Саме тому ранні технічні рішення стають ще важливішими.

Native і cross-platform тепер потрібно оцінювати по-новому

Дискусія між native та cross-platform підходами також змінюється, коли продукт використовує локальний AI.

Спільна кодова база досі може бути хорошим рішенням. Проте перед вибором платформної стратегії команда повинна оцінити реальне AI-навантаження.

Варто відповісти на такі питання:

• Чи залежить функціональність від platform-specific AI framework?
• Які пристрої підтримують необхідну модель?
• Чи потрібен застосунку прямий доступ до hardware acceleration?
• Чи використовуватимуть iOS та Android однакову модель?
• Чи потрібна різна fallback logic для різних платформ?
• Скільки native integration знадобиться cross-platform framework?

Універсальної відповіді немає.

Для одних продуктів добре працюватиме cross-platform застосунок з невеликими native AI-інтеграціями.

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

Рішення має випливати з вимог продукту.

Як Allmatics підходить до архітектури мобільного AI

В Allmatics ми розглядаємо розміщення моделі як архітектурне рішення, а не як технічну деталь окремої функції.

Наша робота у сферах Web and Mobile Development та AI/ML Development поєднує продуктові вимоги із системою, яка повинна їх підтримувати.

Під час discovery ми починаємо з практичних питань.

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

Після цього архітектура може визначити чіткі межі між обробкою на пристрої, хмарним inference, backend-сервісами та зовнішніми інструментами.

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

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

Цю роботу потрібно виконати до того, як основні потоки даних стануть складними та дорогими для змін.

Головна зміна відбувається на рівні архітектури

On-device AI стає потужнішим, але це не означає, що кожен мобільний застосунок повинен перенести весь AI-стек на телефон.

Набагато важливіша зміна відбувається на рівні архітектури.

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

Ця гнучкість дає переваги. Водночас вона створює більше архітектурних рішень.

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

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

Для on-device AI у мобільних застосунках у 2026 році головне питання вже не в тому, чи здатен смартфон запускати корисний AI.

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

The post On-Device AI у мобільних застосунках у 2026 році: архітектурний гайд appeared first on Allmatics.

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.