Часть 4. Пока вы читали этот абзац, чей-то агент на Java уже отработал смену

Теория хороша, но ИИ в Java — это не прогноз, а работающая реальность. Финансовый сектор использует Java-ИИ для обнаружения мошенничества в реальном времени: системы на Spring Boot и Kafka анализируют транзакции и выявляют аномалии до того, как платёж будет авторизован. В здравоохранении Java-решения обеспечивают ИИ-диагностику и мониторинг пациентов — от поддержки решений в гинекологии до предиктивной аналитики на мобильных устройствах. В ритейле ИИ-модели, встроенные в Java-системы управления цепочками поставок, прогнозируют спрос и оптимизируют запасы: Ocado использует Java для интеллектуальных систем, обслуживающих всё — от веб-магазина до складов.

Uber — самый показательный пример. Внутренняя ИИ-платформа Michelangelo, запущенная в 2016 году, сегодня обучает 20 000 моделей в месяц, обслуживает 5 300 моделей в продакшене одновременно и достигает 30+ миллионов предсказаний в секунду. Онлайн-предсказание здесь полностью написано на Java — от расчёта времени прибытия до оптимизации маркетплейса и обнаружения мошенничества. С включением GPU-ускоренного инференса через NVIDIA Triton Inference Server трафик вырос в 10–100 раз: QPS отдельных сервисов подскочил с сотен до 10 000+. Команде пришлось глубоко заняться настройкой JVM: размером heap, паузами G1GC, конфигурацией потоков исполнителей, off-heap памятью и изоляцией CPU/GPU-ресурсов в контейнерах. Каждая итерация давала двузначное сокращение CPU — это тот случай, когда «скучная» работа с рантаймом даёт больше, чем смена фреймворка. Пока вы читали этот абзац, Michelangelo успел принять больше решений, чем человек принимает за всю жизнь.

Но самый чувствительный сценарий — open-source PoC банковского ассистента на LangChain4j, который позволяет клиенту через диалог проверить баланс, просмотреть транзакции и инициировать платёж. Это не чат-бот ради чат-бота: это LLM, встроенная в тот же Java-стек, который уже обрабатывает банковские операции. Архитектура строится на ReAct-агенте — цикле рассуждения и действия, где LLM решает, какой инструмент вызвать следующим. Клиент пишет «переведи 500 рублей маме», агент уточняет реквизиты, проверяет лимиты, формирует платёжное поручение и отправляет его в существующий бэкенд. Всё это — в одном процессе, без выхода за периметр.

И тут возникает вопрос, о котором не пишут в пресс-релизах: где физически работает модель? Если данные клиентов уходят в облако, это уже не технологическая деталь, а вопрос комплаенса. Банк не может отправить транзакцию в чужой API. Регулятор захочет узнать, где хранятся данные, кто имеет к ним доступ и что произойдёт, если сервис отключат. Именно поэтому растёт интерес к локальным моделям — запуску LLM внутри периметра банка, без внешних вызовов. LangChain4j поддерживает интеграцию с Ollama для разработки и vLLM для продакшена, что позволяет построить ассистента, который не отправляет ни одного байта клиентских данных наружу. Переключение между облачной моделью и локальной — это смена Bean-конфигурации: baseUrl, apiKey, modelName. Бизнес-логика остаётся нетронутой. Разработчик тестирует на ноутбуке с Ollama, а в продакшене тот же код работает с кластером vLLM на GPU.

По данным Bitkom, 77% немецких компаний называют защиту данных ключевым барьером для внедрения ИИ — и именно локальные модели решают эту проблему, полностью снимая вопросы о передаче данных третьим лицам. Для банка это не эксперимент, а условие, при котором ИИ-ассистент вообще может быть допущен к работе с реальными счетами.

И снова вспоминаются понедельники. Когда регулятор приходит с проверкой, недостаточно сказать что модель «работала в облаке». Нужно показать, где хранились данные, какие запросы уходили, какие ответы приходили. Локальная модель на Java-стеке даёт полный контроль: все вызовы логируются, все данные остаются внутри, а аудитор получает не расплывчатое «модель так решила», а конкретный трейс — какой шаг планировщика, какой инструмент, какой результат. Именно поэтому локальный инференс — это не техническое решение, а условие выживания в понедельник.