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

Впровадження ШІ у державний сервіс на 23+ млн користувачів — це шлях постійних продуктових відкриттів та викликів. У цій доповіді я поділюся реальним досвідом того, як екосистема «Дія» переходить від класичної Цифрової держави (де юзер сам шукає потрібні послуги) до Агентної (де ШІ проактивно виконує намір користувача). Про що поговоримо: - Product Discovery та зміна парадигми: Перехід від Digital State до Agentic State. Чому звичні інтерфейси досягли своєї межі, та як ми валідували потребу в проактивних AI-рішеннях. - AI у Підтримці як перший великий крок: Як ми автоматизували 90% звернень без втрати якості (CSAT). М'який AI UX: чому люди не вміють користуватися промптами і як ми допомагаємо їм гібридними інтерфейсами. - Кейс Upskill та трансформація команди: Ми не звільнили жодного оператора. Як ми створили внутрішні AI-тули для команди, а вчорашні оператори стали AI-тренерами. - Deep Dive у Дія.AI на Порталі: Запуск першої у світі агентивної послуги на державному рівні. Як працює наша RAG-архітектура, як ми захищаємо персональні дані (PII) від потрапляння в LLM та відбиваємо спроби джейлбрейків.

Більшість компаній починають AI-трансформацію з технології, а не з бізнес-задачі, і отримують вічні пілоти замість результатів. Поділюся принципами, які сформувались через побудову та реалізацію 20+ AI-стратегій і 50+ рішень для компаній від рітейлу до фарми в США, Європі та Україні. Які помилки коштують найдорожче, що насправді визначає ROI, і чому одні проєкти масштабуються, а інші назавжди залишаються на слайдах. Для кого буде корисно: • CEO, власники бізнесу та керівники, які впроваджують або планують AI. • Технічні лідери та ML-інженери, які будують AI-рішення і хочуть, щоб робота давала бізнес-результат.

Опис доповіді: - Передумови впровадження. Чому ми вирішили додати асистента до звичного пошуку. - Ринкові тренди. Як розвивається Agentic Commerce і чому це важливо зараз. - Реалізація. Як ми технічно будували та впроваджували AI-агента в структуру Prom. - МВП та результати експерименту. Що показали перші тести та як користувачі взаємодіяли з асистентом. - Ключові інсайти та висновки. Головні думки, які ми винесли під час розробки та запуску. - Що робимо далі. Плани щодо розвитку AI-інструментів на маркетплейсі.

Що відбувається, коли велика мовна модель стає точкою входу до державних сервісів, які працюють під реальним навантаженням і в умовах інформаційної війни? У такій архітектурі будь-який запит може бути не лише некоректним, а й навмисно маніпулятивним — і стандартні AI-safety рішення виявляються значно менш надійними, ніж у лабораторних бенчмарках. У цій доповіді я розповім, як ми будували власний guardrail-модуль для Дія.AI після того, як зіткнулися з обмеженнями готових фільтрів і високою вартістю підходу LLM-as-a-Judge. Замість перевірки кожного запиту великою моделлю ми спроєктували каскадну архітектуру безпеки: швидкі ML-класифікатори відсікають більшість трафіку, а LLM підключається лише там, де справді потрібен глибокий аналіз контексту. Це доповідь не про ідеальні моделі, а про компроміси, обмеження і практичні рішення, які доводиться приймати, коли AI-система працює не в ноутбуці, а в національному сервісі.

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

Під час виступу ми розберемо чому простого RAG уже недостатньо для організації з різними джерелами даних і як еволюціонують сучасні AI-системи: від класичного RAG до Deep Search, гібридного пошуку та Knowledge Graph як шару корпоративної пам’яті. Подивимось як поєднати неструктуровані документи, табличні дані, бази даних, внутрішні wiki, чати й бізнес-сутності в єдину систему, де AI знаходить релевантні джерела, будує маршрут пошуку, пояснює зв’язки між фактами та видає більш точні й перевірювані відповіді.

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

Давайте чесно: в більшості команд performance-оптимізацією починають займатись лише тоді, коли вже «горить». І зазвичай це роблять одна-дві людини. Не тому що іншим не цікаво — просто справжня оптимізація потребує багато часу, контексту і експертизи. У Temabit ми вирішили поексперементувати з іншим підходом: делегувати частину задач оптимізації агентам. Я розповім, що з цього вийшло: як ми навчилися формулювати задачі оптимізації так, щоб агенти давали корисні результати, як перевіряємо їхні пропозиції, і чому оптимізацію виявилось значно складніше делегувати, ніж написання коду — але й користі від цього більше Реальні кейси, чесні висновки без прикрас. І головне питання: наскільки реально довірити агентам performance вашого продукту?

Розробка AI зараз впливає на всіх — тож давайте зануримось у неї разом. Усі хочуть, щоб AI-агенти замінили звичні інтерфейси. У цій доповіді я розповім про еволюцію нашого мультиінструментального AI-агента, створеного на Node.js поверх Google Vertex AI. Я поділюся нашим шляхом вибору правильних моделей та масштабування розробки за допомогою CI/CD, TDD і моніторингу продуктивності. Але виникає питання: чи взагалі можливо досягти стабільних результатів у AI-проєктах, де моделі можуть галюцинувати та повертати різні відповіді? Цікаво, що з часом ми вирішили відмовитися від MCP-серверів і валідації схем через Zod — технологій, які часто вважають «стандартом» для таких задач. Хочете дізнатися, чому ми відійшли від них? Приходьте на мою доповідь, щоб отримати ці інсайти та поставити свої запитання наживо.