AWS ADOP: ИИ-агенты в разработке, детерминированный код — в продакшне

У каждого руководителя отдела дата-инжиниринга, который смотрит на бюджет платформы на 2027 год, есть один и тот же неудобный вопрос: какую часть истории об агентном ИИ действительно стоит помещать в runtime, а какую — оставить в IDE. AWS только что опубликовал однозначный ответ, и он оказался именно тем, который позволяет финансовому директору спать спокойно. Архитектурное решение внутри ADOP стоит изучить, даже если вы никогда не будете его разворачивать, — оно переосмысляет, что вообще допустимо называть «агентной платформой данных».

Проблема

Подключение нового регулируемого источника данных по-прежнему занимает несколько недель в большинстве компаний на стадии series-B и в корпоративном сегменте. Один человек пишет PySpark. Другой пишет проверки Great Expectations. Третий обновляет семантический слой. Юристы ревьюят документацию по линейке данных спустя два спринта. К тому моменту, когда Gold-таблица наконец появляется, бизнес-вопрос, породивший запрос, уже утратил актуальность.

Очевидное решение, которое каждый вендор продавал на протяжении всего 2025 года, — поместить LLM-агента в runtime. Пусть агент инспектирует источник, генерирует трансформацию, выполняет её, учится на ошибках и повторяет попытку. Это хорошо продаётся на демо. Но в регулируемой среде оно проваливает три теста: предсказуемость затрат, воспроизводимость аудита и неудобная реальность — модель, которая ведёт себя по-разному во вторник и в понедельник, — это не то, о чём хочет слышать банковский инспектор.

Agentic Data Operations Platform, как сообщает Amazon Web Services (AWS), — это референсная архитектура на Amazon Bedrock, призванная сжать этот временной промежуток с недель до часов. Интересно здесь не само заявление о сжатии сроков — его делает каждый агентный питч. Интересно то, где живут агенты. В стандартном паттерне ADOP агенты работают только в среде разработки. Они генерируют детерминированный PySpark, SQL, Airflow DAG, IAM-политики и правила авторизации Cedar. CI/CD продвигает эти артефакты в продакшн. Продакшн выполняет их без вызова модели.

Это философия проектирования, а не функция. Она утверждает: модель — это ускоритель на этапе сборки, а не зависимость в runtime. И это почти точно соответствует тому, как зрелые инженерные организации уже думают о кодогенерации: старший инженер использует Copilot для черновика функции, ревьюит его, деплоит проверенную версию — и модель не находится нигде рядом с production request path.

Доступные варианты

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

Паттерн первый: модель в цикле на этапе runtime. Агенты наблюдают за продакшн-данными, принимают решения о трансформациях на лету и выполняют их. Именно это продаёт большинство агентных стартапов. Это максимизирует гибкость и максимизирует вариативность затрат. Каждый прогон пайплайна — это счёт за токены. Каждая смена версии модели — риск регрессии. Для ad-tech-компании, быстро работающей с нерегулируемыми данными, — допустимо. Для всех, кто касается PHI или KYC-данных, — кошмар соответствия требованиям, ожидающий первого аудита.

Паттерн второй: агенты в dev, детерминированные артефакты в prod. Это стандартный паттерн ADOP. Суб-агенты, порождённые через функцию Dynamic Workflow в Claude Code, обрабатывают генерацию метаданных, дедукцию онтологий, проверку качества, ETL и оркестрацию через Airflow или AWS Step Functions. Результат проверяется, продвигается в продакшн и запускается без обращения к модели. Счёт за токены ограничен частотой подключения новых источников, а не объёмом трафика. Аудиторы получают статичный код для проверки, а не трейсы модели.

Паттерн третий: управляемые платформы агентов в runtime. Amazon Bedrock AgentCore позиционируется как масштабируемый runtime для агентов, и ADOP при необходимости можно перевести на него. Это питч «мы запустим ваших агентов в масштабе», и он существует в противоречии с паттерном два. AWS здесь честен: оба паттерна допустимы, они оптимизированы под разное. AgentCore оптимизирован для гибкости. ADOP оптимизирован для предсказуемости затрат и позиции при аудите.

Паттерн четвёртый: ручная сборка с dbt и оркестрацией. Статус-кво. Хорошо организованный dbt-проект с надлежащим тестированием, семантическим слоем и дисциплинированным code review уже обеспечивает большую часть консистентности, которую декларирует ADOP. Разница — в скорости подключения источников и в признании того факта, что старшие дата-инженеры будут тратить значительную часть времени на сантехнику, а не на моделирование.

Вопрос «делать самим или покупать» здесь необычен, потому что ADOP — это не продукт, который вы покупаете. Это референсная архитектура, которую вы клонируете с GitHub и адаптируете. Реальная вендорная привязка — это Amazon Bedrock и Claude Code как поверхность для написания кода, плюс вычисления, на которые вы в итоге опираетесь (Spark на EMR, Glue или что-то вроде Databricks, если вы уже там). Vendor lock-in смещается от агентного runtime к провайдеру модели и CLI-инструментарию. Это принципиально иная переговорная позиция через восемнадцать месяцев.

Что реально стоит делать дата-командам

Моя позиция: если вы работаете с регулируемыми пайплайнами, паттерн ADOP — правильный вариант по умолчанию, даже если вы никогда не трогаете конкретную реализацию AWS. Возьмите архитектурную идею. Поместите агентов в dev, деплойте детерминированный код, держите продакшн скучным. Одна только токеномика это оправдывает. Пайплайн, вызывающий модель при каждом запуске, имеет стоимость, масштабируемую с трафиком. Пайплайн, сгенерированный однажды и однажды проверенный, имеет стоимость, масштабируемую с объёмом подключений, — что примерно на два порядка меньше для большинства предприятий.

Стоит назвать и последствия для состава команды. Этот паттерн требует меньше prompt-инженеров и больше platform-инженеров, понимающих CI/CD, policy-as-code и умеющих ревьюить сгенерированный PySpark на корректность. Рынок найма «AI-инженеров» перегрет последние восемнадцать месяцев. Рынок сильного platform-инженера, который умеет читать Cedar-политики и писать Airflow DAG, — напряжённый, но не безумный. Этот паттерн благоприятствует команде, которую вы реально можете нанять.

Финансовый директор или руководитель платформы, читающий борд-дек этой недели, должен задать конкретный вопрос: какая доля запланированных на 2026 год расходов на ИИ-инфраструктуру приходится на runtime-инференс в дата-пайплайнах, а какая — на кодогенерацию на этапе сборки? Если ответ сильно склоняется к runtime, кто-то должен защитить это перед паттерном ADOP с конкретными доводами, а не интуицией. «Модель должна быть в цикле» — это не довод. «У нас неструктурированные входные данные, меняющие форму каждый день, и статичный код не может с ними справиться» — это довод.

Для команд, уже работающих на Snowflake или Databricks, ADOP не принуждает к миграции. Он поддерживает любой сервис с CLI или Model Context Protocol интерфейсом — что является честным способом сказать: архитектурный контракт переносим. Направьте сгенерированные артефакты на любое хранилище, которое вы уже используете.

Подводные камни и граничные случаи

Несколько вещей, на которые стоит обратить внимание. Decision Engine, описываемый как закодированная версия корпоративного архитектора на базе ИИ, ровно настолько хорош, насколько хороши стандарты, которые вы в него загружаете. Организации, которые никогда не записывали свои принципы архитектуры данных, обнаружат, что их кодификация и есть настоящая работа, а не оркестрация агентов. Это шестимесячное упражнение, замаскированное под однонедельную настройку.

Каждое решение агента трейсируется через механизм под названием AgentTrace, который публикует данные в CloudWatch или в OpenTelemetry sink. Хорошо. Но трейсы процесса сборки — это не то же самое, что продакшн-наблюдаемость, и команды не должны их путать. Вам всё равно нужен реальный мониторинг пайплайна для детерминированных артефактов после их деплоя.

История с соответствием требованиям ограничена. ADOP применяет один регуляторный промпт на фреймворк управления при подключении, и AWS прямо указывает, что клиенты сами несут ответственность за определение собственного соответствия. Эта формулировка важна. Сгенерированная Cedar-политика — это отправная точка для проверки вашим юристом, а не замена самой проверки. Если ваша compliance-функция не укомплектована для проверки policy-as-code, добавление агента, который генерирует их быстрее и больше, не поможет.

Наконец, зависимость от Claude Code реальна. Kiro, Cursor и Codex поддерживаются как кодовые поверхности, но паттерн суб-агентов Dynamic Workflow является функцией Claude Code. Если ваша организация стандартизировалась на другом coding assistant, ожидайте работы по адаптации.

Ключевые выводы

• Основная идея ADOP — архитектурная: агенты в разработке, детерминированные артефакты в продакшне. Это привязывает стоимость токенов к объёму подключений, а не к объёму трафика.
• Паттерн благоприятствует командам, способным нанять platform-инженеров, а не командам, делающим ставку на дефицитных prompt-инженеров.
• Для регулируемых нагрузок в здравоохранении и финансовых услугах статичный сгенерированный код несравнимо проще аудировать, чем модель, которая может вести себя иначе на следующей неделе.
• Vendor lock-in смещается от агентного runtime к провайдеру модели и CLI-инструментарию. Учитывайте это при следующем продлении контракта на Bedrock или Claude.
• Настоящая работа — кодифицировать архитектурные стандарты, чтобы Decision Engine было что применять. Команды без задокументированных стандартов обнаружат их на горьком опыте.

Команды, оценивающие агентные платформы данных в ближайшие девяносто дней, должны теперь задавать себе более острый вопрос: помещает ли вендорный питч модель в request path — и если да, что конкретно оправдывает этот профиль затрат по сравнению с альтернативой только на этапе сборки? Если ответ — демо, а не защищаемая характеристика нагрузки, паттерн ADOP побеждает по unit-экономике ещё до начала разговора о соответствии требованиям.