AI Native: взгляд изнутри инженерной системы Много лет мы проектировали информационные системы вокруг бизнес-задач и клиентских путей.
Есть пользовательский сценарий. Есть операция, которую клиент должен выполнить быстро и без ошибок.
А задача инженерной системы — сделать так, чтобы этот путь был устойчивым:
меньше хопов; меньше точек отказа; понятные SLA/SLO; контролируемая деградация;
целевая архитектура без лишней сложности.
То есть мы строили системы под детерминированные операции: нажал кнопку → получил результат.
Но с агентскими решениями картина меняется.
Когда мы уже понимаем, как устроена AI-платформа — где находятся guardrails, RAG, LLM, инструменты, политики безопасности, аудит и контуры интеграции — мы переходим к следующему уровню: проектированию бизнес-решений на базе агентов.
И вот тут начинается настоящий AI Native.
Пример — сервис «История операций».
В классической микросервисной архитектуре у нас есть лоадеры, мапперы, нормализаторы. Данные в итоге раскладываются в PostgreSQL по месячным партициям.
Такая архитектура хорошо решает свою задачу: показывать пользователю историю операций быстро и стабильно.
Например: 98% операций отображаются быстрее 1 секунды при MAU больше 5 млн. Для классического сценария это хороший результат.
Но теперь представим агента.
Пользователь пишет:
Я ездил в командировку в прошлом году. Найди все операции по авиабилетам для авансового отчета.
И тут система, которая была хорошо спроектирована для экрана истории операций, внезапно оказывается не очень готова к агентскому сценарию.
Почему?
Во-первых, нужно пройти данные за весь прошлый год.
Это уже не один короткий запрос к ближайшей партиции.
Во-вторых, нужно понять, какие операции относятся к авиабилетам.
А классическая история операций обычно умеет фильтровать по периоду, сумме, типу операции или мерчанту, но не всегда понимает смысл запроса: «авиабилеты для командировки».
В-третьих, если таких запросов станет много, мы упремся в таймауты, нагрузку, стоимость и деградацию основного клиентского сценария.
И тут часто начинаются костыли: «Давайте сделаем рядом аналитическую БД». «Давайте переложим туда историю». «Давайте отдельно обогатим операции». «Давайте потом как-нибудь догоним исторические данные».
Вот здесь и проходит тонкая грань.
AI Native — это не просто прикрутить LLM к существующей системе.
AI Native — это проектировать систему так, чтобы с ней мог работать не только человек через экран, но и агент через инструменты.
Это значит, что данные должны быть заранее подготовлены для будущего tooling:
- нормализованы;
- обогащены;
- доступны для поиска;
- безопасно отданы через API;
- пригодны для семантических запросов;
- отделены от критического online-path;
- наблюдаемы по стоимости, качеству и latency.
Раньше мы проектировали путь пользователя.
Теперь нужно проектировать еще и путь агента внутри системы.
Какие инструменты он может вызвать? Какие данные получить? Как проверить результат? Где остановиться? Как не положить production? Как не раскрыть лишнее? Как объяснить пользователю источник ответа?
Это уже не просто микросервисная архитектура.
Это новая инженерная плоскость.
И главный вывод для меня такой: AI Native начинается не с LLM. AI Native начинается с готовности вашей инженерной системы быть понятной, безопасной и полезной для агента. А это новые паттерны, новые деньги, новые требования к данным и новая ответственность архитекторов.
