Марія БровінськаШІ
10 грудня 2025, 19:08
2025-12-10
З 30% до 62% користувачів ШІ: як Райффайзен Банк побудував культуру ШІ за 18 місяців і заощадив сотні тисяч доларів
Рік тому ШІ в Райффайзен Банку був радше темою для внутрішніх обговорень, ніж реальним інструментом. Сьогодні підхід банку до технологій кардинально змінився: команди щодня працюють з інструментами ШІ, а внутрішні ініціативи із впровадження технологій дали змогу значно пришвидшити ключові процеси та відкрити нові сценарії ефективності для співробітників фінансової установи.
Григорій Таций, технічний директор Райффайзен Банку Україна, розповів dev.ua про трансформацію, яка змінила не лише швидкість розробки, а й саме визначення того, що означає бути розробником.
Рік тому ШІ в Райффайзен Банку був радше темою для внутрішніх обговорень, ніж реальним інструментом. Сьогодні підхід банку до технологій кардинально змінився: команди щодня працюють з інструментами ШІ, а внутрішні ініціативи із впровадження технологій дали змогу значно пришвидшити ключові процеси та відкрити нові сценарії ефективності для співробітників фінансової установи.
Григорій Таций, технічний директор Райффайзен Банку Україна, розповів dev.ua про трансформацію, яка змінила не лише швидкість розробки, а й саме визначення того, що означає бути розробником.
Зміст
Коротко кажучи: що ШІ дав Райфу
Коли до Григорія прийшов студент-стажер і за тиждень створив повноцінний сервіс KYB для верифікації бізнес-клієнтів — завдання, яке у старшого розробника на повний робочий день зайняло б два спринти, — сервісний центр Райфу зрозумів, що галузь переживає справді фундаментальні зміни. Він просто добре працював із Claude Code», — каже Таций.
За 18 місяців ІТ-фахівці Rife досягли 50% збільшення продуктивності розробки, заощадили $178 000 на одному проєкті та скоротили час створення POC із тижнів до чотирьох годин. «Але найважливіше не в інструментах. Коли я вивчав галузеві дані DX, Dora та Antropic, які проаналізували понад 135 000 розробників у 435 компаніях, я побачив цікаву закономірність: традиційні корпоративні компанії зі структурованим впровадженням показують вищі результати впровадження ШІ, ніж технологічні гіганти. Це вселило в мене впевненість, що ми рухаємося в правильному напрямку», — каже Григорій.
Штучний інтелект щороку змінюватиметься радикальніше, ніж усе програмне забезпечення змінювалося за попередні двадцять років. Команди, які навчаться працювати в цьому середовищі, отримають перевагу, яку не можна купити. Її можна лише побудувати — систематично, чесно та разом.
Швидкість більше не є конкурентною перевагою для розробників, а гігієнічним мінімумом. У цій новій реальності штучний інтелект не замінює інженерів. Він робить інженерів тими, ким вони мали бути з самого початку: людьми, які створюють системи, приймають технічні рішення та несуть відповідальність за результат.
Розробник перестає бути людиною, яка пише код рядок за рядком.
«Він стає оператором складних інтелектуальних систем. Архітектором, наставником для десятків цифрового „мотлоху“, що працює під його контролем. Людиною, яка формує логіку, а не синтаксис», — каже Таций.
Історія впровадження ШІ в Райфі, за його словами, не є швидкою перемогою. «Це 18 місяців експериментів, невдач, змін курсу та систематичної роботи над культурою, яка перетворила скептиків на активних користувачів», — пояснює Таций. Нижче наведено його висновки та ідеї, які СTO зробила й отримала під час впровадження ШІ.
Холодний старт: як одне питання в Парижі змінило все
У вересні 2023 року Григорій виступив на конференції McKinsey в Парижі, де розповідав про технологічні ініціативи Райфа. Після презентації один з учасників поставив питання, яке здивувало СTO: «Ви вже пишете тести зі штучним інтелектом, використовуючи GitHub Copilot?»
«Тоді я вперше почув про Copilot. Повернувшись до банку, ми запустили швидкий пілотний проєкт на 50 ліцензій. І ось перший холодний душ: Copilot на той час був ще сирим, генерував багато „поганого“ коду, і лише 30% розробників насправді ним користувалися. Решта повернулися до свого звичного робочого процесу, і я їх розумів — інструмент був радше перешкодою, ніж допомогою», — каже Григорій.
Він визнає: тоді банк міг би на цьому зупинитися, вирішивши, що «ШІ ще не готовий для підприємства». «Але щось мені підказувало, що справа не в технології в цілому, а в конкретній реалізації», — зазначає СTO. Тому на початку 2025 року в Райфі було проведено ще один пілотний проєкт — цього разу з Cursor.
У пілотному проєкті взяли участь 20 розробників, середня оцінка інструменту після оцінювання розробниками склала 8,3 з 10. «Для рутинних завдань інструмент працював у 10 разів швидше. Віталій, наш бекенд-розробник, сказав: „Політика Rego, над якою мій колега працював дві години з ChatGPT, зайняла у мене 20 хвилин із Cursor“. Микита, DevOps-інженер, рефакторував весь проєкт за одні вихідні — він зізнався, що ніколи б не переписав його вручну за такий час», — каже Григорій.
Перший урок був зрозумілим: не всі інструменти штучного інтелекту однакові. Потрібно тестувати, вимірювати, порівнювати. І лише потім масштабувати.
Випадки, які переконали скептиків
У великих організаціях на кожну нову ідею є десяток причин, чому вона «не спрацює». Підприємництво любить конкретні докази. Тож Райф почав їх збирати систематично.
Випадок 1: з'єднувач за день замість місяців
У банку була команда, яка рефакторувала старий стек IBM. Потрібно було перейти з Oracle DB на PostgreSQL для шини даних — це 18 000 євро економії на рік та узгодженість технологій замість зоопарку. Але було два болючі моменти: відсутність ODBC-конектора для платформи AIX для PostgreSQL та відсутність глибокої експертизи в СУБД у команди.
Сервісний центр Райффайзен Банку, Григорій Таций
Це могла б бути історія на кілька місяців. Але інженер, який ніколи раніше цього не робив, використовуючи GitHub Copilot, отримав робочий конектор і скрипт для міграції даних з Oracle до PostgreSQL за день. Ще кілька днів знадобилося для комплексного тестування. Два інженери плюс Copilot — і все пішло у продакшн згідно з нашим процесом SDLC, включаючи безпеку, архітектуру та рецензування.
Я побачив перший приголомшливий ефект: те, що традиційно займало тижні, тепер виконується за дні або навіть години
Випадок 2: аналітика дзвінків та економія 178 000 доларів США
Відділ стягнення боргів звернувся до СТО Райфа із запитом: нам потрібен інструмент для аналізу дзвінків колекторів. «Ми дуже дбаємо про наших клієнтів і хочемо бути впевненими, що наші спеціалісти дотримуються стандартів спілкування з клієнтами», — каже Григорій.
ІТ-хлопці зібрали перший прототип за чотири години. Вони витратили три години на вибір моделі для транскрипції — почали з OpenAI Whisper (точність ≈65% — недостатньо), перейшли на AWS Transcribe (~84% — прийнятно), а пізніше замінили його на Google Gemini 2.5, що дало стрибок точності до 93%. Ще годину знадобилося на написання фронтенду та бекенду для наших запитів.
Сервісний центр Райффайзен Банку, Григорій Таций
Щоб не здавалося, що ШІ може творити дива, скажу чесно: щоб довести продукт до продакшену за всіма правилами розробки компанії, нам знадобилося два старших менеджери, власник продукту, аналітик і три місяці. Бо писати код швидко, а от домовлятися про інтеграції, укладати контракти та робити це за банківськими стандартами — це ще один виклик.
Однак, проєкт окупився ще до його запуску в виробництво: найдешевший постачальник, який би погодився розробити таку систему E2E, коштував би нам $220 000. Нам це коштувало $42 000 — економія $178 000.
Коли Григорій порівняв ці цифри з галузевими показниками, він побачив, що це не було аномалією. Згідно з публічними дослідженнями, компанії, які використовують розробку за допомогою штучного інтелекту, заощаджують в середньому 3,6 години на тиждень на одного розробника, а ті, хто використовує її щодня, заощаджують 4,1 години. Цифри команди Raiffeisen були в тому ж діапазоні, але вони застосували ці години економії до конкретних бізнес-кейсів з вимірюваною рентабельністю інвестицій.
Випадок 3: студент і нова реальність старшинства
Третім поворотним моментом став прихід студента на стажування до банку — без досвіду роботи у фінтех і навіть без досвіду розвитку підприємств. Це була людина, яка просто мала базові знання з розробки.
Сервісний центр Райффайзен Банку, Григорій Таций
Ми сказали: ось у чому наш біль — нам потрібно зробити KYB (Know Your Business), нам потрібен сервіс, який аналізує вебсайт клієнта за десятками параметрів, дає оцінку, створює звіт по клієнту. Нам потрібно зробити це на Java + Kafka з купою NFR. Завдання оцінив у два спринти розробки старшим розробником, включаючи аналіз. Якщо хочете приєднатися до нашої команди — давайте.
За кілька днів, використовуючи Claude Code, студент зібрав повністю робочий прототип на Python: із моделями штучного інтелекту для аналізу, інтерфейсу, базової логіки. Ми зробили огляд, виявили, що якість і розуміння коду на високому рівні, і сказали: чудово, рефакторинг на Java з нашими стандартами та ласкаво просимо до команди.
Тож у банку ми усвідомили, що з новими інструментами змінюється саме визначення навичок. Люди, які можуть мислити продуктово та працювати з моделями, стають новою категорією працівників.
Це підтверджують дані, які СTO бачив у публічних звітах: молодші інженери є найактивнішими користувачами штучного інтелекту — 41,3% з них використовують ці інструменти щодня, що є найбільшим показником серед усіх рівнів старшинства. І вони демонструють результати. Час до досягнення 10-го особистих результатів для нових співробітників RIF, які використовують штучний інтелект, скоротився з 86 днів у першому кварталі 2024 року до 39 днів у третьому кварталі 2025 року.
Випадок 4: аналітик, який став розробником
Дмитро з відділу аналітики настільки зацікавився продуктом аналізу дзвінків, що був готовий самостійно розробити частину сервісу. Тому банк вирішив провести експеримент: чи може людина без жодних знань програмування розробити хоча б частину функціоналу?
Сервісний центр Райффайзен Банку, Григорій Таций
Ми доручили Дмитру написати фронтенд для аналітичного сервісу відповідно до нашої бібліотеки дизайну. Коротка відповідь: ні, одразу не може, бо ШІ — це все ще множник, і якщо помножити 0 на будь-яке число, це все одно буде 0.
Але Дмитро був наполегливим. Не розуміючи, що йому пише ШІ, він просто почав вчитися писати на Node.js за допомогою ШІ. І за 4 місяці у нас вже був робочий фронт для нашого сервісу аналізу дзвінків.
Раніше ми б сказали: ну, це щонайменше півроку на навчання, враховуючи, що у нього є основна робота, ще місяць на наставництво. А тут людина просто цим займається. І для мене це було знаком: ШІ — це не про заміну розробників, а про те, що межі професій розмиваються.
Григорій нагадує нам, що в дослідженні Anthropic, заснованому на результатах опитування 132 інженерів, було зафіксовано ту саму тенденцію: бекенд-розробники створюють складні інтерфейси, до розробки залучені нетехнічні спеціалісти. Один з їхніх інженерів описав свою трансформацію так: «перейшов на 70%+ до рецензентів/редакторів коду, а не до авторів нового коду». Це точно описує те, що СTO зараз бачить у Райфі.
Другий урок: штучний інтелект — це мультиплікатор, але для ефективної роботи йому потрібна база знань та критичне мислення.
У Rife штучний інтелект дав нам змогу швидко створити чотири продукти, які вже використовуються:
Платформа OCR — ми починали з моделей, похідних від Qwen2, але після виходу Gemini Nano Banano перейшли на неї. Виявилося, що Gemini не тільки добре генерує зображення, але й чудово їх аналізує. Це стало критично важливим, коли ми побачили реальні умови: вантажник фотографує накладну на темному складі старим телефоном. Прості PDF-файли обробляються добре, але саме з такими низькоякісними фотографіями Gemini справляється набагато краще, ніж попередні рішення.
Аналітика дзвінків (сервіс оцінювання) — працює у продакшені, аналізує тисячі дзвінків і надає об’єктивну оцінку якості обслуговування.
За лаштунками аналіз проблем під час виконання, автоматичне документування ШІ та генерація конфігурації YAML значно пришвидшили процеси DevOps.
MCP-сервери для внутрішніх завдань — майже кожен відділ може створити для себе мікроінструмент.
Масштабування: чому купівля ліцензій — це лише 10% роботи
Маючи ці конкретні докази, Григорій вирішив масштабувати досвід банку в галузі штучного інтелекту. До середини 2025 року кількість ліцензій GitHub Copilot зросла до 300, а загальний річний бюджет розробників на розвиток штучного інтелекту досяг 80 000 євро. А потім команда зіткнулася з неочікуваною проблемою: ліцензії були, але використання не було.
Перші два місяці після масштабування виглядали добре на папері — 300 виданих ліцензій, каже Григорій. «Але коли ми подивилися на реальне використання, ми побачили неприємну картину:
30% розробників активно використовують
40% мають ліцензію, але користуються Copilot кілька разів на місяць
30% взагалі не отримують ліцензії
«Метриками для оцінки були використання преміумзапитів, прийняті лінії, мережевий трафік до кінцевих точок», — пояснює він.
Команда зрозуміла, чому це сталося.
«Ми роздали інструмент, але не пояснили: як його ефективно використовувати, які завдання він вирішує найкраще, як його інтегрувати в робочий процес, чому взагалі варто витрачати час на його вивчення. Звучить банально, але в умовах підприємства це критична помилка. Люди зайняті, у них є дедлайни, і якщо новий інструмент не дає швидкої цінності, вони повертаються до звичного робочого процесу», — зазначає СTO Райфу.
Тоді експерти знайшли тимчасове рішення: підхід FinOps до залучення. «Як сильна FinOps-організація, ми вирішили застосувати той самий підхід до ліцензій на ШІ, що й до хмарних ресурсів. Правило просте: якщо Copilot не використовувався навіть раз протягом місяця, ми анулюємо ліцензію. Не назавжди, не як покарання, а просто рахуємо гроші. Але найголовніше, ми змінили метрику успіху. Раніше це було „скільки ліцензій було розподілено“ (охоплення). Тепер це „скільки людей насправді користуються ним щодня“ (залученість)», — пояснює Григорій.
Чому це важливо? Згідно з публічними дослідженнями, загальний рівень впровадження штучного інтелекту в компаніях досяг 91% — але це лише «доступ». Реальне щоденне використання набагато нижче. Райф вирішив зосередитися на якості, а не на красивих цифрах у звітах.
Розмірковуючи над тим, як просувати людей через воронку продажів, банк визначив чотири групи співробітників і розробив стратегію для кожної з них:
Некористувачі (зовсім не використовують)
Чому: вони не бачать цінності, вони скептики, «Мене це влаштовує»
Що ми робимо: кавові розмови з реальними кейсами, запрошуємо на демонстрацію, показуємо конкретну економію часу
Власники ліцензій, але неактивні (мають ліцензію, але майже нею користуються)
Чому: спробував, не зрозумів як, розчарувався
Що ми робимо: персональні адаптації, семінари для початківців, система друзів з активними користувачами
Випадкові користувачі (нечасті користувачі)
Чому: використовується для простих завдань, не знаючи про можливості
Що ми робимо: розширені семінари, демонстрація складних сценаріїв, обмін шаблонами підказок, управління контекстом, управління знаннями моделей
Чому: побачили реальну цінність, інтегровану в робочий процес
Що ми робимо: ми просимо їх поділитися своїм досвідом, ми робимо їх амбасадорами, ми збираємо відгуки для покращень
Дані показують, чому це критично важливо: ті, хто використовує це щодня, заощаджують 4,1 години на тиждень, створюють на 60% більше запитів на зняття. І тепер мета ІТ-команд — просувати людей по цій воронці продажів.
Якщо говорити про ефективність такого підходу, варто зазначити, що наразі банк видав 220 ліцензій для 400 спеціалістів, які використовують IDE у своїй роботі.
83 особи в когорті 2 (мають ліцензію, майже ніколи нею не користуються)
137 осіб у когортах 3 та 4 (ти, хто користується послугами епізодичного та щоденного використання)
180 у когорті 1 (зовсім не використовували)
Через зміну робочого процесу в ІТ-командах, підхід до визначення оцінок також змінився.
«Якщо ми змінюємо робочий процес, логічно змінити й очікування від різних рівнів старшинства», — пояснює Григорій. Сьогодні вимоги до молодших, середніх і старших працівників банку трансформувалися.
Оцінка
Це було до появи штучного інтелекту
Що сталося зі штучним інтелектом?
Молодший
пише простий код під керівництвом
за допомогою ШІ можна закривати реальні завдання вже через тиждень після адаптації. Важливо не «знати синтаксис напам’ять», а розуміти, що потрібно робити та як перевірити результат.
Середній
самостійно пише складний код
Знає, як перевіряти код, згенерований штучним інтелектом, доводити його до якості продакшену та критично оцінювати рішення. Стає «рецензентом коду, який розуміє ШІ».
Старший
знає все, розв’язує найскладніші проблеми
правильно ставить завдання моделі (інженерія запитань/контексту), бачить архітектуру, розуміє обмеження ШІ та приймає рішення, де ШІ допоможе, а де потрібна людська оцінка.
«Критично важливо: весь код, згенерований ШІ, проходить обов’язкову перевірку старшими інженерами. ШІ пришвидшує написання, але фінансову якість (рівень, на якому система бездоганно поводиться в усьому, що пов’язано з грошима) забезпечують люди. Це не „ШІ пише і йде в продукт“ — це „ШІ пише, люди перевіряють логіку/архітектуру/безпеку/продуктивність“. Така багаторівнева перевірка дозволяє нам отримати швидкість ШІ без шкоди для якості», — коментує Таций.
Антропні дані підтверджують це: старші інженери менше стурбовані атрофією навичок, оскільки вони «знають, якою має бути або як має виглядати відповідь». Вони використовують ШІ як інструмент, а не як милицю. Молодші інженери більш схильні сліпо довіряти результатам ШІ.
Урок третій: залученість важливіша за охоплення. 60% активних користувачів краще, ніж 100% ліцензій без реального використання. А для досягнення залученості потрібно більше, ніж просто роздати інструменти — потрібна система адаптації, підтримки й постійного навчання.
Щобільше, Anthropic у своєму дослідженні описує трансформацію так: інженери бачать себе такими, що «беруть на себе відповідальність за роботу 1, 5 або 100 Claude».
На практиці це означає наступне:
менше часу на написання коду рядок за рядком;
більше часу для архітектурних рішень та перевірки коду;
зосередитися на перевірці того, що генерує ШІ;
робота зі штучним інтелектом як молодший розробник — постановка завдань, перевірка результату, навчання
Роль розробника, зазначає Таций, не зникає — вона розвивається — від детального програмування до стратегічного управління агентами штучного інтелекту, які розв’язують технічні проблеми під вашим керівництвом.
Підготовка команди: чому навчання є критично важливим
Щоб підвищити залученість співробітників до використання штучного інтелекту, банк започаткував регулярний захід — «Кавові розмови з технічним директором». Це не робочі зустрічі, а вечірні сесії поза робочим часом, де збиралися зацікавлені люди, демонструвалися інструменти та ділилися реальними кейсами. «Ми запросили найактивніших користувачів, які продемонстрували, як вони використовують штучний інтелект», — каже Таций.
Банк також започаткував внутрішні семінари з підвищення кваліфікації:
Як вибрати модель
Як писати підказки
Як працювати з контекстом
Як будувати трубопроводи
Як тестувати моделі
Як НЕ використовувати MCP (це окрема історія про отримані уроки)
«Це працює. Я дослідив публічні звіти про вплив структурованого навчання та підтримки, і цифри вражають. Збільшення впровадження GenAI на 25% дає: зменшення прогалин у знаннях на 16%, підвищення впевненості у змінах на 10,6%, покращення залученості на 7,4%, прискорення реалізації на 6,5%», — зазначає СTO Райфа.
«Наразі команда банку зі штучного інтелекту розробляє цілий курс — внутрішній трек — який навчить будь-якого співробітника працювати зі штучним інтелектом, незалежно від його професії», — каже Григорій.
Урок четвертий: Структуроване навчання та підтримка — це не просто приємні речі, але критично важливі для успіху. Різниця між «розповсюдженням ліцензій» та «систематичним впровадженням» полягає в покращенні різних показників на 6–16% (від швидкості надання послуг до зменшення прогалин у знаннях). Найбільший вплив має на впевненість команди й заповнення прогалин у знаннях.
Технологічний стек: що працює для ШІ, а що ні
Технічний стек в ІТ-команді Райфа був сформований за допомогою серії експериментів, каже Таций. Зрештою, фахівці визначили набір інструментів, які працювали, а також назвали ті, які «не працювали».
Що працює
Що не спрацювало
GitHub Copilot (220 ліцензій, 62% впровадження) — ключовий інструмент для щоденної розробки. Розробники генерують код для рутинних завдань у 10 разів швидше, особливо для універсального коду.
n8n — платформа автоматизації виявилася дорогою через високі вимоги до безпеки. Теоретично звучить добре, але реальність вимог безпеки підприємства зробила її нерентабельною.
Claude Code — для складніших завдань, що потребують міркувань. Це інструмент, який дав змогу студенту-стажеру створити сервіс KYB за тиждень. Він дає розробникам змогу вирішувати завдання, в яких вони взагалі не мали досвіду.
ElevenLabs — непогані голосові агенти для контакт-центру, але їх важко швидко налаштувати для банківських завдань. Досягнення справжньої людяності в мовленні все ще потребує часу, і команда Raiffeisen не могла дозволити собі тривалу кастомізацію.
Microsoft Copilo t — чат-боти та RAG-рішення для внутрішніх баз знань. Виявилося ідеальним базовим рішенням завдяки прямій інтеграції з Teams та легкому створенню RAG-чатів з нашими джерелами даних. Але тут є важливе застереження: оперативне впровадження даних є великою проблемою. Отримати доступ до «чужих» даних простіше, ніж здається, тому тестування, безпека та контроль є першочерговими.
Google Gemini 2.5 — транскрипція дзвінків з точністю 93%. Ми протестували різні моделі: OpenAI Whisper показав точність ~65% (недостатньо), AWS Transcribe — ~84% (прийнятно), а Gemini 2.5 дав якісний стрибок до 93%. За допомогою додаткової обробки фахівці легко досягли 99% і водночас знизили вартість рішення вдвічі. Потім вони додали пакетні запити — що ще більше знизило вартість (але з необхідністю відступів для «галюцинацій»).
Григорій пишається тим, що штучний інтелект не залишився іграшкою лише для однієї команди. Різні відділи почали знаходити власні варіанти використання та впроваджувати рішення.
Команда CloudOps створила робочий процес агента Claude CLI для перевірки модулів Terraform. Замість того щоб перевіряти кожен модуль окремо, штучний інтелект агрегує проблеми та показує «погляд із вертольота» на практики організації — повторювані антишаблони, відсутні стандарти, можливості для уніфікації. Результат: перевірка якості коду Terraform на високому рівні без витрат на старшого інженера.
Вони також автоматизували тестування відновлення резервних копій RDS для PostgreSQL, MySQL, Oracle, MS SQL Server. Функція Lambda + шари, специфічні для движка + модуль Terraform. Це скоротило цикли розробки.
Команда з інфраструктури перенесла реєстр NiFi до інфраструктури як код з Terragrunt. Використовуючи штучний інтелект для аналізу шаблонів та оптимізації, вони змінили тип екземпляра з c6a.large на t3a.medium — це заощадило 50% коштів без погіршення продуктивності. Прискорило впровадження на 35%.
Ще однією їхньою роботою є модуль Terraform для автоматизації бази даних OCI. Штучний інтелект допоміг із генерацією коду, політиками IAM та оптимізацією конфігурації. Результат: зниження витрат на 30%, впровадження інфраструктури з кількох тижнів до кількох днів.
Команда ESB (корпоративна сервісна шина) використовувала штучний інтелект для міграції з Oracle на PostgreSQL (я розповідав вам про це на початку — економія €18 тис.). Але вони пішли далі: оптимізували інфраструктуру ActiveMQ за допомогою штучного інтелекту. Час розгортання зменшився з 1 дня до 16 хвилин (у 30 разів швидше покращення). Оптимізація Terraform + плейбук Ansible + оптимізація витрат на AWS.
Команда Data Lake створила власний MCP-сервер з RAG для інтеграції з Alation, AWS Glue та Athena. Це проміжне програмне забезпечення між агентами LLM (Claude, GitHub Copilot) та репозиторієм метаданих. Тепер ШІ може генерувати SQL-запити для Data Lake, коду Apache Spark, орієнтуватися в схемах за допомогою підказок природною мовою. Також виконує SQL-трансляцію з вихідних баз даних DWH (Sybase IQ, Oracle ADW) на SQL, сумісний з Athena.
Команда веброзробників використовувала Claude Code для відеоідентифікації клієнтів — складний мікрофронтенд в UFO (нашій бек-офісній системі) без документації, без можливості налагодження локально. Claude Code допоміг розробити макети для локального середовища та розблокувати інтерфейс користувача для всіх чотирьох кроків процесу. Це також скоротило час на підтримку модульних тестів.
Це лише частина історії, каже СTO. За його словами, майже кожна команда знайшла свої власні варіанти використання та почала експериментувати.
Внесок із відкритим кодом
У Rife ми не лише використовуємо інструменти штучного інтелекту, але й ділимося своїм досвідом зі спільнотою розробників. «Ми відкрили вихідний код нашого робочого процесу APM для модульних тестів — це набір практик та автоматизації, які допомагають нам підтримувати якість коду, активно використовуючи генерацію ШІ», — з гордістю каже Таций.
Він пояснює важливість цього кроку: коли штучний інтелект швидко генерує код, тестування стає критичним вузьким місцем. Робочий процес, розроблений командою Raiffeisen, дозволяє автоматично генерувати модульні тести з належним покриттям та валідацією. «Ми переконалися в цінності цього підходу внутрішньо та вирішили, що інші корпоративні команди, які стикаються з тими ж проблемами, можуть отримати від нього користь», — каже Григорій.
За його словами, частиною філософії є те, що банк не повинен бути чорною скринькою.
«Ми можемо і повинні зробити свій внесок в екосистему, особливо коли йдеться про найкращі практики впровадження штучного інтелекту в умовах жорсткого регулювання», — переконаний СTO.
Григорій зазначає, що дотримується основних галузевих рекомендацій: уникати прив’язки до одного постачальника та підтримувати багатопостачальний підхід. Він пояснює: ринок штучного інтелекту змінюється надто швидко, щоб покладатися на одного постачальника. Дані досліджень показують, що інструменти на основі штучного інтелекту, такі як Cursor, демонструють вищу пропускну здатність PR порівняно з традиційними рішеннями, але через кілька місяців картина може змінитися.
Проблеми, про які потрібно чесно поговорити
Не все було ідеально в роботі команди Raiffeisen з інструментами штучного інтелекту. У СTO описано низку проблем, з якими розробникам довелося зіткнутися під час пошуку правильних рішень.
Якість коду
Згідно з публічними дослідженнями, вплив на показник збоїв змін демонструє «неоднозначні результати» — приблизно стільки ж організацій покращує якість, скільки й погіршує. Більшість змін відбуваються в межах ±1-2%. «Ми бачимо те саме: якість залежить від того, наскільки ретельно розробник перевіряє результати роботи ШІ», — каже Григорій.
Атрофія навичок
Григорій зазначає, що свідоме використання ШІ, зберігаючи при цьому здатність критично оцінювати результат, стає дедалі складнішим, оскільки результати часто виглядають дуже круто, на перший погляд. Антропні інженери висловлюють те саме занепокоєння: «Коли отримання результату таке просте та швидке, стає все важче й важче насправді витратити час на вивчення чогось».
Тіньовий ШІ
Райф виявив, що розробники використовують інструменти штучного інтелекту, які купують за власну кишеню. Згідно з даними, які я бачив, 44% організацій мають з цим труднощі.
«Тут я хочу окремо згадати нашу команду безпеки — вони стали справжніми партнерами в цій трансформації. Замість того щоб просто блокувати Shadow AI (що було б найпростішим рішенням), вони значно інвестували в систему DLP (запобігання втраті даних), щоб захистити себе від ризиків, але водночас не придушувати інновації. Ми розробили прийнятні політики використання, які чітко визначають, які типи даних можна використовувати з якими інструментами штучного інтелекту, а DLP автоматично контролює дотримання цих правил», — каже Григорій.
Культурний парадокс інтерв’ю
Банк виявив цікаву проблему: кандидати часто приховують під час співбесід, що активно використовують інструменти штучного інтелекту. Вони бояться, що це виглядатиме так, ніби вони «самі не вміють програмувати».
«У нас протилежний підхід: використання штучного інтелекту — це перевага, а не недолік. Коли кандидат каже під час співбесіди: „Я пишу за допомогою GitHub Copilot та Claude Code“, для нас це сигнал: людина знає сучасний робочий процес, не боїться нових технологій та розуміє, як бути більш продуктивною», — каже Таций.
Але галузь ще не встигла реорганізуватися, додає він. Багато компаній досі оцінюють «чи може людина написати алгоритм на дошці без штучного інтелекту» замість «чи може людина ефективно вирішувати бізнес-завдання за допомогою штучного інтелекту». Це створює культурний розрив між тим, як насправді працюють розробники Rife, і тим, як цінуються банківські ІТ-фахівці на ринку.
«Моя порада кандидатам: не приховуйте своїх навичок роботи зі штучним інтелектом. Шукайте компанії, які їх цінують. А компаніям: переглядайте свої співбесіди. Не питайте „чи знаєте ви синтаксис напам’ять“, а „як ви використовуєте штучний інтелект для розв’язання складних проблем“», — каже Григорій.
Негайна ін'єкція
Це велика проблема, особливо в MS Copilot. Отримати доступ до «чужих» даних простіше, ніж здається.
Вузькі місця поза межами ШІ
Ось що цікаво: коли Григорій розглядає розподіл часу розробників, економія від штучного інтелекту переважає час, втрачений у дні з великою кількістю зустрічей та перерв. Згідно з даними з наших систем, які я проаналізував, найбільшими вузькими місцями є:
Дні, насичені зустрічами
Частота переривань (часті перерви в роботі)
Суперечки між архітекторами
Час очікування збірки та тестування
Проблеми з налаштуванням середовища розробки (проблеми з налаштуванням середовища розробки)
Інциденти (інциденти та пожежогасіння)
Консультація щодо контексту (необхідність постійно доносити свій контекст до колег)
Штучний інтелект, за словами Тації, заощаджує розробникам 3–4 години на тиждень, але зустрічі та переривання роботи з'їдають набагато більше. Це означає, що продуктивність у великих масштабах вимагає комплексного підходу — не лише ШІ, а й оптимізації всього робочого процесу.
Що далі: виведення ШІ за межі коду
Родина Райфів лише на початку своєї подорожі, і в них багато планів на майбутнє.
Навесні 2026 року Райф запустить повноцінний внутрішній курс зі штучного інтелекту «Від нуля до героя». За словами Григорія, це не просто посібник з «користування GitHub Copilot», а комплексна програма, яка дозволить вам навчитися:
Як вибирати між різними моделями ШІ для різних завдань
Швидка інженерія від базового до експертного рівня
Робота з контекстом та структурованими результатами
Етика використання ШІ та політика прийнятного використання
Практичні семінари з реальними банківськими кейсами
Важливо: курс не лише для розробників, оскільки штучний інтелект змінює роботу далеко за межі коду. Григорій нагадує нам: згідно з публічними дослідженнями, 60% дизайнерів та продакт-менеджерів у технологічних компаніях вже щодня використовують штучний інтелект. Менеджери-інженери, які активно використовують штучний інтелект, створюють вдвічі більше пул-реквестів — вони самі пишуть код для прототипів та простих функцій.
Він бачить цю тенденцію і в Райфа. Аналітики пишуть SQL та Python замість того, щоб чекати на розробників. Менеджери продуктів створюють прототипи інтерфейсів. Дизайнери генерують код компонентів за допомогою Figma. DevOps автоматизують завдання інфраструктури за лічені години, а не за дні.
«Розширення визначення розробника не означає, що кожен стає розробником. Це означає, що технічний бар'єр знижується, і люди можуть зосередитися на вирішенні проблем, а не на синтаксисі», — підсумовує Таций.
8 порад для технічних директорів, які планують впроваджувати штучний інтелект у бізнесі
Підсумовуючи 18-місячний досвід роботи банку, СTO Райфа радить колегам з інших компаній дотримуватися певних канонів.
Тестуйте перед масштабуванням. Не всі інструменти штучного інтелекту однакові. Запускайте пілотні проєкти, вимірюйте результати, слухайте розробників. Ми витратили шість місяців на експерименти перед масштабуванням, вибираючи інструменти та постачальників, з якими ми будемо працювати далі — і це окупилося.
Зосередьтеся на залученні, а не на охопленні. 200 ліцензій із 30% впровадження гірше, ніж 100 ліцензій з 60% активного використання. Структуроване навчання та підтримка покращують ключові показники:
Зменшення прогалин у знаннях
Зростання впевненості у змінах
Покращення залученості
Прискорення доставки
Створюйте культуру через кейси. Підприємство любить конкретні докази. Збирайте їх систематично, вимірюйте рентабельність інвестицій, діліться успіхами.
Будьте чесними щодо труднощів. Атрофія навичок, якість коду, тіньовий ШІ — це реальні проблеми. Визнайте їх і працюйте над ними.
Мисліть цілісно. Штучний інтелект — це не чарівна куля. Вузькі місця поза ШІ (зустрічі, перевірки коду, час очікування на безперервну інтеграцію) часто поглинають більше часу. Продуктивність у великих масштабах вимагає оптимізації всього робочого процесу.
Уникайте прив’язки до одного постачальника. Ринок змінюється надто швидко. Дотримуйтесь багатопостачального підходу та будьте готові до експериментів.
Поділіться своїм досвідом зі спільнотою. Команда Raiffeisen зробила свій робочий процес APM відкритим для модульних тестів, оскільки побачила, що багато команд стикаються з однаковими проблемами. Підприємства можуть і повинні робити свій внесок в екосистему, особливо коли йдеться про штучний інтелект у суворо регульованому середовищі.
Не обмежуйте себе однією командою. Найбільша цінність виникає, коли ШІ використовується не лише розробниками, а й командами CloudOps, інфраструктури, даних та вебу. Кожна команда знаходить свої унікальні варіанти використання — від перевірки коду Terraform до користувацьких MCP-серверів для Data Lake.
Банк перейшов у хмару: що далі? Архітектор хмарних рішень Райфу про виклики та рішення, які спростять управління хмарною інфраструктурою після міграції
Штучний інтелект проти шахраїв: кіберексперти Raifu створили інструмент на основі штучного інтелекту, який виявляє шахрайські дії з грошима до їх скоєння. Як працює система боротьби з шахрайством Raifu
«Чи є у мене талант, якщо комп’ютер може імітувати мене?». Штучний інтелект пише книги авторам Amazon Kindle. The Verge поспілкувався з авторами та виявив багато цікавого
Письменники-романісти використовують штучний інтелект для створення своїх творів. Видання про технології The Verge поспілкувалося з письменницею Дженніфер Лепп, яка випускає нову книгу кожні дев’ять тижнів, й дізналося про те, як працює штучний інтелект для написання романів. Наводимо адаптований переклад статті.
Хочете повідомити важливу новину? Пишіть у Telegram-бот
Головні події та корисні посилання в нашому Telegram-каналі
