Сгенерировать аудио

AdventHealth внедряет ChatGPT for Healthcare, чтобы снизить административную нагрузку и ускорить клинические рабочие процессы во всей системе. Автоматизируя трудоемкую документацию и вспомогательные задачи, команды ухода возвращают себе часы каждую неделю и позволяют клиницистам больше сосредоточиться на пациентах. Результат — не только операционная эффективность, но и расширенная клиническая емкость, более быстрый доступ к помощи и измеримое улучшение опыта пациентов.

Под давлением необходимости делать больше меньшими ресурсами

AdventHealth — это сеть больниц, работающая в девяти штатах и ежегодно обслуживающая миллионы пациентов. Как и многие крупные системы здравоохранения, она сталкивается с низкой маржинальностью, растущим спросом и усложняющейся административной средой.

Значительная часть этого давления проявляется в повседневных рабочих процессах. Врачи-эксперты, рассматривающие случаи для управления использованием ресурсов, часто тратят около 10 минут на каждый случай — не на одну задачу, а на последовательность шагов: чтение медицинских карт, выделение релевантных деталей, проверку критериев и подготовку структурированных обоснований. На сотнях или тысячах случаев это время быстро накапливается.

Нагрузка выходит далеко за пределы клинических ролей. Команды в финансах, HR, IT и других функциях тратят значительное время на подготовку документов, сводку информации и материалов, которые необходимы, но отнимают много времени. В результате многие работают в том, что руководители называют «режимом постоянных операций», с ограниченной возможностью заниматься более ценной работой.

При этом интерес к AI уже формировался внутри организации. Сотрудники экспериментировали с чат-ботами, хотя формальные политики ограничивали их использование.

«У нас были люди, которые очень хотели начать, но было и очень много тех, кто оставался в стороне, — говорит Rob Purinton, Chief AI Officer в AdventHealth. — Они не были уверены, как эффективно использовать AI в своей повседневной работе».

Adoption — это результат

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

«Самая сложная часть AI в здравоохранении — заставить людей использовать его безопасно, последовательно и в масштабе, — говорит Purinton. — Мы рано приняли решение рассматривать adoption как сам продукт».

Это решение определило сам подход к внедрению. Вместо того чтобы позиционировать AI как автоматизацию, руководство представило его как способ уменьшить административную нагрузку и вернуть время клиницистам и сотрудникам.

«Мы не говорим об AI как об автоматизации. Мы говорим о возвращении времени, — говорит Purinton. — Если мы можем взять 10-минутный обзор и существенно сократить его — при сохранении качества — это емкость, которую мы можем вернуть нашим клиницистам».

AdventHealth также сделала adoption измеримым операционным показателем. Организация отслеживает количество сообщений на пользователя в рабочий день, исключая выходные и праздничные дни, чтобы создать стабильную базовую линию. Этот показатель контролируется и управляется как любой другой KPI, с регулярным рассмотрением целей и тенденций.

Чтобы масштабировать использование, система опиралась на доменные группы коллег по функциям, а не на крупные централизованные программы обучения. Например, финансовые команды работали с финансовыми командами, а HR — с HR, обмениваясь prompts, рабочими процессами и лучшими практиками, релевантными для своих функций.

Масштабное внедрение с OpenAI

По мере перехода от экспериментов к корпоративному развертыванию руководство ставило в приоритет инструменты, которые соответствуют требованиям здравоохранения к конфиденциальности, управлению и надежности.

«Мы выбрали OpenAI, потому что искали не демо, а корпоративную инфраструктуру, — говорит Purinton. — Возможности reasoning, структурированные выходные данные и механизмы governance дали нам уверенность в том, что это не просто ПО для повышения продуктивности. Это то, что мы могли ответственно масштабировать на уровне всей системы здравоохранения».

AdventHealth внедрила ChatGPT Enterprise, а затем ChatGPT for Healthcare, который обеспечил дополнительные защитные механизмы для регулируемых сред, включая защиту данных и поддержку соблюдения требований.

На решение также повлияли скорость инноваций и готовность к сотрудничеству.

«Нам действительно нравится быть ближе к границе того, что возможно, — говорит Purinton. — И мы видим, что OpenAI очень хорошо сотрудничает с нами, когда мы продумываем пилоты, развертывания и следующий шаг».

Перепроектирование рабочих процессов для клинических и операционных команд

Одним из самых ранних и наиболее измеримых сценариев использования стало управление использованием ресурсов.

С помощью ChatGPT for Healthcare врачи-эксперты могут генерировать структурированные сводки по медицинским картам пациентов, выделять релевантные клинические детали и готовить первоначальные обоснования. Окончательное решение по-прежнему остается за клиницистом, но время на сбор информации сокращается.

Организация измеряет эффект на основе системных данных, включая временные метки в электронных медицинских картах, а не на основе самооценок.

«Мы предпочитаем метрики, которые встроены прямо в процесс, — говорит Purinton. — Мы можем точно увидеть, на сколько минут улучшился показатель и является ли это изменение статистически значимым».

Помимо клинических процессов, похожие модели появились и в других подразделениях:

• Подготовка документов и планов начинается с первого черновика, а не с пустой страницы
• Политики и коммуникации преобразуются в структурированные, пригодные к использованию форматы
• Заметки и неструктурированная информация быстро сводятся в шаги к действию

Эти изменения сокращают циклы выполнения, уменьшают число итераций согласования и повышают согласованность результатов.

Измерение результатов через время и throughput

AdventHealth оценивает влияние AI по двум основным направлениям: adoption и производительность рабочих процессов.

В части adoption отслеживание ежедневного использования создало подотчетность и прозрачность того, как быстро AI становится частью повседневной работы.

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

В разных подразделениях команды отмечают:

• Сокращение времени, затрачиваемого на повторяющиеся задачи по документации и проверке
• Более быстрые сроки выполнения внутренних рабочих процессов
• Меньше циклов доработки благодаря более последовательным первым черновикам
• Рост емкости без увеличения штата

Организация часто называет эти преимущества «возвращенным временем», но руководство напрямую связывает это понятие с измеримыми результатами.

«Если вы берете задачу на 10 минут и делаете ее за две, и это происходит тысячу раз в неделю, это уже реальная емкость, — говорит Purinton. — Вопрос в том, как вы реинвестируете эту емкость».

Возвращение времени клиницистам и сотрудникам

Для AdventHealth ценность AI тесно связана с миссией оказания whole-person care. А это требует времени — времени для общения клиницистов с пациентами и семьями, а также времени для сотрудников, чтобы сосредоточиться на более ценной работе.

Один пример показывает эффект на уровне отдельного человека. Врач, который раньше по вечерам занимался документацией — часто это называют «pajama time», — смог завершать работу в обычные часы после изменений рабочих процессов с поддержкой AI.

«Он перестал брать работу домой, — говорит Purinton. — Он мог идти домой и быть рядом с семьей».

Такие истории укрепляют подход организации к AI как к инструменту снижения административной нагрузки, а не замены ролей.

Формирование основы для более широкого эффекта

На сегодняшний день основная часть измеримых результатов связана с сокращением времени, затрачиваемого на существующие задачи. AdventHealth рассматривает это как отправную точку.

Сейчас организация сосредоточена на расширении использования в таких областях, как доступ пациентов к помощи, clinical decision support и новые модели оказания медицинской помощи, сохраняя при этом прежний акцент на governance, измерениях и доверии.

По мнению руководства, главный урок заключается в том, что масштабирование AI зависит не столько от самой технологии, сколько от того, как ее внедряют и как люди начинают ею пользоваться.

«Adoption — это не “просто начните использовать продукт”. Это leadership change, — говорит Purinton. — Когда вы измеряете эффект, доказываете ценность и строите внедрение на доверии, именно тогда вы выходите за рамки пилотов».

Материал — перевод статьи с английского.

Оригинал: AdventHealth advances whole-person care with OpenAI

Сгенерировать аудио

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

Материал — перевод статьи с английского.

Оригинал: Hark raises $700M Series A for its secretive ‘universal’ AI interface

Сгенерировать аудио

Когда в декабре 2025 года вышел Claude Opus 4.6, коммерческая команда Anthropic вернулась после зимних праздников и обнаружила, что спрос вырос почти вертикально. К такому объему они не успели ни нанять людей, ни подготовиться.

Как рассказала Eleanor Dorfman, Head of Industries в Anthropic, которая руководит коммерческой и отраслевой командой продаж, на сцене SaaStr AI Annual 2026, даже если бы компания была готова увеличить sales-команду в 3x, 4x или 5x, так быстро набрать людей все равно невозможно — и при этом сохранить положительный customer experience.

Поэтому в январе 2026 года они перестроили весь sales org вокруг AI с нуля.

Спустя четыре месяца результат оказался таким: 54% новых enterprise-логотипов в 2026 году пришли через self-serve funnel. Настоящие enterprise-логотипы. Настоящий ACV. Настоящие terms of service. Настоящий invoicing. Все — self-served.

Ниже — как они это сделали и какие четыре инвестиции любой B2B + AI sales-лид может повторить уже сегодня.

Четыре ограничения, которые нельзя было снять

У команды Eleanor было четыре ограничения, которые и определили задачу:

Спрос, который нельзя было замедлить. Он уже был в воронке.

Численность, которую нельзя было быстро увеличить. Anthropic не собиралась снижать планку найма, чтобы просто набрать больше людей.

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

Поддерживающие функции, которые должны были масштабироваться вместе с продажами. Legal, deal desk, RevOps, billing, compliance. Продажи не живут в вакууме.

Пятое, негласное ограничение: нельзя было выжечь AE. Уже были поздние вечера в Европе, где люди гонялись за approvals через часовые пояса. Это нужно было остановить, а не усугубить.

Ставка была такой: не покупать новый стек, а провести Claude через уже существующий. Сделать Claude связующим звеном между Clay, LeanData, Salesforce, Gong, Ironclad, Slack, Jira, Intercom Fin, Snowflake, BigQuery и G Suite. А затем нарастить логику в промежутках между ними.

Инвестиция #1: сломать ортодоксию PLG против SLG

15 лет в B2B жила почти религиозная вера: product-led growth и sales-led growth — это разные команды, которые ведут разные motion. Self-service якобы для SMB. Enterprise-планы якобы должны продавать люди.

Eleanor в январе это отбросила.

В январе 2026 года они запустили enterprise self-service MVP. В феврале перевели его в production. Воронка работает так:

• Каждый лид обогащается данными и квалифицируется через Clay + Claude.
• Открываются две параллельные воронки: self-serve или sales-assisted.
• В self-serve-воронке продукт Intercom Fin ведет покупателя по пути. Anthropic тесно работала с командой Fin, чтобы переоборудовать свой флагманский support-продукт в рабочий sales-инструмент.
• Покупатель попадает на enterprise-план с реальным ACV, terms of service, invoicing, provisioning и enrollment на обучение. Полностью self-serve.
• Если лид подходит для sales-воронки, он идет в BDR, проходит квалификацию еще раз и маршрутизируется к AE.

54% новых enterprise-логотипов в 2026 году пришли через self-serve.

Больше половины новых enterprise-логотипов Anthropic пришли без AE-led journey — на реальных enterprise-условиях и с реальным enterprise ACV.

Если вы до сих пор считаете self-service утешительным призом для покупателей, которые «не заслужили» человека, вы оставляете на столе большую часть своего motion в 2026 году.

Инвестиция #2: сделать Claude связующим тканем, а не седьмым инструментом

Шесть основных инструментов Anthropic, которые определяют путь от лида до сделки:

Claude не стал просто «седьмым инструментом», прикрученным сверху. Claude — это то, что заставляет эти шесть систем разговаривать друг с другом. Вот как выглядит обычный вторник AE в Anthropic:

Утро. Каждый customer-facing rep начинает день в Claude. Skill «morning brief» вытягивает контекст из Gmail, Gong, Slack, Google Docs, календаря, Salesforce, Intercom и Greenhouse, а затем расставляет приоритеты на день. Три действия, которые нужно сделать. Эти письма, на которые нужно ответить. Эти Slack-сообщения, которые нужно обработать. Эти сделки под риском. Eleanor получает свой brief в Slack в 7:00 по ET. Она говорит, что искренне не понимает, как раньше без этого работала.

Перед звонком. Skill «call prep» заменяет 30 минут поиска в LinkedIn, раскопок в Slack и копания в Salesforce. Rep вводит /call prep и получает персонализированную one-pager: кто будет на звонке, что для них важно, исторический контекст, какие discovery-вопросы задать, конкурентный ландшафт, что компания публично говорила о своих потребностях.

Во время подготовки предложения. Вместо того чтобы открывать девять вкладок с deal desk guidance, чистить транскрипты Gong и вручную проверять precedent, AE обращается к Claude. Claude знает продукт, roadmap, где Anthropic выигрывала и почему, кто stakeholders и как устроены переговоры. Claude черновиком собирает предложение, проверяет его на соответствие policy и загружает в Ironclad.

Прогнозирование. Здесь все еще идет отладка. Eleanor говорила об этом прямо: на старте каждого forecast call они все еще тратят минимум 10 минут на обсуждение того, как именно нужно forecast’ить. Слишком быстро меняется сама среда. Но сами прогнозы уже в основном делает Claude, а менеджеры их проверяют. Reps используют Skills, чтобы убедиться, что Salesforce обновлен, следующие шаги корректны, а account plans актуальны. Затем Claude сопоставляет consumption data с историческими паттернами для этой когорты и продуктового микса. Forecast calls превращаются в обсуждение того, где AE нужна помощь, а не в упражнение по чистке данных.

Еженедельный coaching. Claude выдает шесть coaching-моментов в неделю, динамически подстраиваясь под то, что важно именно в этом месяце, а не в прошлом квартале. Когда продуктовые запуски и конкурентные движения происходят каждый час, статическая методология становится мертвым грузом. Именно такой динамический coaching-loop помогает сохранять культуру обучения, одновременно принимая новых людей.

Инвестиция #3: сделать Slack входной точкой для всех поддерживающих функций

Продажи не закрывают сделки в одиночку. Deal desk, legal, RevOps, billing, compliance, customer support и customer success должны работать с той же скоростью.

До этой инвестиции поддерживающие функции в Anthropic жили на DMs и институциональной памяти. AE буквально проходили мимо deal desk, чтобы лично выбивать approvals. Представители с Восточного побережья и из Европы засиживались допоздна, добиваясь согласований от support-функций на Западном побережье. Система была тяжелой и неудобной.

Исправление выглядело так:

• Slack становится единой входной точкой для любой поддерживающей функции.
• AE (или Co-work, все чаще) отправляют тикет в Slack. Slack ticket in, Jira ticket out.
• Claude проводит triage. Если вопрос совпадает с precedent и policy, Claude решает его inline.
• Если нужна эскалация, Claude прикладывает полный контекст: customer contacts, историю сделки из Salesforce, сводки звонков Gong, релевантные email-цепочки и назначает задачу человеку.
• AE получает уведомление, может выставить ожидания клиенту и дальше держать процесс под контролем.

Именно это стало прорывом для legal, deal desk, vendor onboarding, security questionnaires и всех остальных compliance-этапов, которые тихо убивают скорость сделки.

Фраза Eleanor звучит так: «Руководители продаж быстро превращаются из стратегов сделок в системных мыслителей». Если вы не проектируете эластичность поддерживающих функций одновременно с эластичностью AE, вы задохнетесь под собственным спросом.

Инвестиция #4: зафиксировать лучших reps как Skills

Четвертая инвестиция — самая интересная. Anthropic взяла паттерны, по которым работали ее лучшие reps, и закодировала их как Skills внутри Claude. Skill — это сочетание MCP connectors и инструкций, которое любой rep может вызвать через /-shortcut.

Каждого нового rep’а сразу помещают в territory вместе с sales plug-in, который объединяет эти Skills. Больше нет шестинедельной кривой онбординга. Boot camp, territory, plug-in, go.

Пять Skills, которые компания выдает каждому rep:

1. Morning Briefing. Уже описан выше. Самый высокоэффективный Skill в стеке. Цитата Eleanor: «Я человек, который может потеряться по дороге домой на метро, и мне совершенно непонятно, как я раньше ориентировалась в своем дне или неделе без того, чтобы Claude каждое утро говорил мне, что важно».

2. Call Prep. Вводишь /call prep и получаешь персонализированный briefing к следующей встрече: кто будет на звонке, что для них важно, исторический контекст, discovery-вопросы, конкурентное позиционирование, что компания публично говорит о своих потребностях. Подготовка за пять минут к любому звонку, даже если они идут один за другим.

3. Customer Follow-Up. Это то, из-за чего Eleanor раньше не спала ночью, — и теперь проблема решена. Skill извлекает action items из email, звонков Gong, заметок Salesforce и Slack-цепочек. Черновиком пишет ответы. Кладет их в ваш почтовый клиент. Отправляет сводку того, что нужно доставить. Если вы реально не проверили и не нажали send, это снова появится в morning brief на следующий день. Внутренний SLA: в течение 24 часов делать follow-up по каждому customer и каждому action item. Skill делает это реальностью.

4. Competitive Intel. Статическая battle card, которую product marketing обновляет раз в квартал, бесполезна в B2B + AI. Конкурентный ландшафт меняется каждый час. Поэтому Claude по запросу генерирует интерактивную battle card, настроенную под конкретного customer, над которым работает rep, и с матрицей, ограниченной этой сделкой. Всегда актуально. Всегда персонализировано.

5. Create an Asset. Это любимый Skill Eleanor и тот, который раньше требовал либо сделки из top-five, либо друга из design team. Теперь по любой сделке, для любого stakeholder и на любой стадии AE может попросить Claude создать кастомные материалы: прототип, one-pager, landing page, интерактивный HTML-файл, ROI calculator. Некоторые reps загружают целые транскрипты звонков Gong в Claude Code и просят собрать адаптированный прототип на основе того, что сказал клиент. Claude знает бренд, поэтому на выходе получаются материалы в фирменном стиле, а не AI-slop.

Что B2B + AI sales-лидерам стоит сделать завтра утром

Четыре шага, с которых можно начать уже сегодня:

1. Включите Claude (или предпочитаемый AI) там, где он уже встроен. У большинства B2B sales-инструментов уже есть AI-функции. У большинства команд тумблер включен, но никто не спросил, что именно он делает. Будьте осознанны: как каждая AI-функция связана с остальным customer journey?

2. Проведите AI через тот sales cycle, который у вас уже есть. Не сносите и не заменяйте все целиком. Ваш цикл работает. Используйте AI как ускоритель между этапами. Где теряется контекст между Salesforce и Slack? Вот там и находится leverage. Sales-motion ушли от детерминированных workflows к вероятностным — и это возможность, а не угроза.

3. Сделайте Slack или Teams входной точкой хотя бы для одной support-функции. Выберите ту, которая сильнее всего тормозит ваших AE. У Anthropic это были deal desk и legal. У вас это может быть vendor onboarding или security questionnaires. Slack ticket in, ticket out, Claude triages. Посмотрите, как ваши cycle times начнут падать.

4. Зафиксируйте, что делают ваши лучшие reps. Выпустите это как Skill. Реальное преимущество — это когнитивное облегчение от осознания, что паттерны топ-исполнителей теперь стали базой для каждого rep. Больше не нужно надеяться, что новички сами догадаются. Нужно сделать так, чтобы их первый день выглядел как обычный вторник вашего лучшего rep.

Anthropic не заменила свой стек. Она добавила AI к тому, что уже было

Anthropic не заменяла Salesforce. Не заменяла Gong. Не заменяла Ironclad. Не заменяла Clay, LeanData, Slack или Jira.

Они инвестировали в то, что у них уже было, и провели Claude через швы между системами.

В этом и есть playbook. Большинство B2B + AI-компаний в 2026 году будут оценивать AI-native sales platforms и пытаться выкинуть свой стек. Выиграют те команды, которые сделают то же, что Anthropic: сохранят инструменты, закодируют лучшие практики и позволят AI стать связующей тканью между всем, что уже построено.

54% новых enterprise-логотипов, приходящих через self-serve, AE, которые просыпаются с персональным brief вместо inbox, forecast calls, которые превращаются в обсуждения вместо чистки данных, support-функции, отвечающие в Slack вместо цепочек писем спустя три дня. Именно так выглядит AI-native B2B sales org в 2026 году. И почти ни для чего из этого не понадобилось новое software.

SaaStr.AI: Ask Us Anything

The 21+ AI Agents We Actually Use

Plus, the latest on how to deploy AI agents.

Материал — перевод статьи с английского.

Оригинал: How Anthropic Rebuilt Its Sales Org From Scratch When Demand Went Vertical: 54% of New Enterprise Logos Now Come Self-Serve

Сгенерировать аудио

OPLOG — технологическая fulfillment-компания, работающая на базе AI и робототехники, — ежемесячно обрабатывает миллионы товаров в Türkiye, Великобритании и Германии для крупных брендов и глобальных маркетплейсов. В customer-agnostic модели fulfillment несколько брендов используют одну и ту же складскую инфраструктуру, сотрудников и автономных роботов, и именно здесь OPLOG столкнулась с проблемой, знакомой многим B2B-компаниям: бизнес-данные были разрознены по системам, из-за чего инсайты запаздывали, а ручная отчетность отнимала часы продуктивного времени каждый день.

Чтобы решить эту проблему, OPLOG построила production-ready систему business intelligence (BI) на базе AI-агентов, развернутых в Amazon Bedrock AgentCore. Решение автономно обрабатывает бизнес-транзакции и в реальном времени дает аналитику по управлению sales pipeline, контролю качества данных и исследованию потенциальных клиентов. Результаты показывают измеримый эффект: сокращение sales cycles на 35%, улучшение полноты данных в CRM на 91% и сокращение времени на ручные исследования на 98%.

В этом материале мы показываем, как OPLOG разработала три AI-агента с помощью Strands Agents SDK, развернула их в Amazon Bedrock AgentCore и интегрировала Amazon Bedrock с Claude Sonnet от Anthropic и Amazon Bedrock Knowledge Bases для Retrieval Augmented Generation (RAG). Мы разбираем архитектуру, подход к реализации и бизнес-результаты, демонстрирующие, как AI-агенты могут трансформировать BI-операции.

Бизнес- и data-задачи OPLOG

Быстрый рост OPLOG создал операционную сложность, с которой традиционные BI-системы не справлялись. Данные компании были распределены между несколькими независимыми системами: в Hubspot CRM хранилась информация о sales pipeline, системы коммуникации содержали переписку с клиентами, Microsoft Teams использовался для контекста общения, а в хранилищах Databricks находились операционные метрики. Каждая система работала отдельно, создавая data silos и не позволяя получить целостный BI.

Фрагментация создавала конкретные операционные боли. Сотрудникам приходилось собирать отчеты из разных систем, синтезировать информацию и готовить обновления. Из-за этого инсайты приходили слишком поздно — еженедельные отчеты упускали 60% возможностей, потому что сделки к моменту завершения анализа уже продвигались дальше или зависали. Качество данных в CRM ухудшалось, поскольку sales representatives, перегруженные ручным вводом, вносили информацию непоследовательно. Команды operations обнаруживали проблемы через несколько часов после их возникновения, что вынуждало реагировать постфактум, а не предупреждать инциденты заранее.

OPLOG подсчитала значительные операционные издержки от фрагментированного BI — упущенные возможности из-за запаздывающих инсайтов, накладные расходы на ручную отчетность, которые съедали продуктивное время, непоследовательное качество данных, влияющее на решения, и реактивные операции, приводящие к неэффективным ответам. Компании требовалось решение, которое могло бы автономно обрабатывать данные во всех системах, выдавать аналитику в реальном времени, убирать ручную отчетность, поддерживать качество данных и помогать принимать проактивные решения.

Обзор решения

OPLOG разработала три AI-агента, каждый из которых отвечает за отдельную BI-область. Агентам не нужно взаимодействовать друг с другом; каждый обрабатывает данные из своих источников и выдает целевую аналитику:

• Deal Analyzer Agent — работает по расписанию, синхронизированному с бизнес-процессами, и анализирует сделки в Hubspot с недавней активностью. Он проверяет сделки на соответствие методологии OPLOG, выявляет пропущенные поля и сообщает о статусе заполнения в Microsoft Teams. Агент обеспечивает качество данных в sales pipeline и соблюдение методологии через автоматическую ежедневную отчетность.
• Sales Coach Agent — реагирует на события Hubspot webhook при смене стадий сделки, проверяет обязательные поля в зависимости от бизнес-модели OPLOG (только B2C, только B2B или B2B и B2C) и автоматически создает задачи по недостающей информации. Агент в реальном времени поддерживает стандарты качества данных и помогает не допускать продвижения сделок с неполными данными.
• Lead Insight Agent — запускается, когда в Hubspot добавляются новые маркетинговые лиды, и анализирует цифровое присутствие лида в шести социальных средах (Instagram, LinkedIn, Facebook, YouTube, Twitter, TikTok). Он применяет методологию квалификации OPLOG для оценки соответствия Ideal Customer Profile (ICP), формирует подробные профили с определением fit и отправляет исследовательские отчеты в Microsoft Teams, сокращая ручное изучение потенциальных клиентов и концентрируя усилия продаж на более перспективных возможностях.

Архитектура использует Amazon Bedrock AgentCore как среду развертывания агентов. OPLOG разрабатывала агентов с помощью Strands Agents SDK, который предоставляет фреймворк для описания поведения агента, пользовательских инструментов и точек интеграции. Каждый агент использует Amazon Bedrock с Claude Sonnet от Anthropic для inference — анализа данных, рассуждений по бизнес-правилам и генерации инсайтов. Amazon Bedrock Knowledge Bases реализует RAG, позволяя агентам получать релевантный контекст из sales playbooks, продуктовых каталогов и документов по методологии, хранящихся в Amazon Simple Storage Service (Amazon S3).

AWS Lambda обрабатывает интеграции с внешними системами, соединяя агентов с Hubspot, Microsoft Teams и внешними источниками данных. Amazon EventBridge запускает Deal Analyzer Agent по расписанию, а webhooks Hubspot в реальном времени активируют Sales Coach и Lead Insight Agents. AgentCore Observability обеспечивает полный мониторинг, отслеживая вызовы агентов, метрики производительности и затраты через Amazon CloudWatch. OPLOG платит только за выполнение агентов и не управляет инфраструктурой. AgentCore Runtime автоматически масштабируется от нуля до тысяч сессий в зависимости от нагрузки, а обновления разворачиваются без простоя.

В следующих разделах подробно описано, как OPLOG реализовала каждого агента для решения конкретных BI-задач. Deal Analyzer Agent обеспечивает плановую отчетность по pipeline, Sales Coach Agent поддерживает качество данных в реальном времени, а Lead Insight Agent автоматизирует исследование лидов. Хотя у каждого агента своя задача, все они построены на общей технической основе Amazon Bedrock, Amazon Bedrock Knowledge Bases и Strands Agents SDK и развернуты в Amazon Bedrock AgentCore.

Deal Analyzer Agent: ежедневная отчетность по качеству pipeline

Руководители продаж OPLOG сталкивались с ежедневной задачей: проверять десятки сделок, чтобы понять, в каких не хватает информации. Ручная проверка занимала часы и часто выявляла проблемы только тогда, когда сделки уже зависали. Deal Analyzer Agent решает эту задачу за счет автоматического анализа по расписанию и отправки подробных отчетов в Microsoft Teams, где сразу видно, какие сделки требуют внимания.

Следующая схема иллюстрирует архитектуру агента:

EventBridge запускает Lambda по расписанию, согласованному с бизнес-процессами. Lambda вызывает AgentCore Runtime, который исполняет агента для анализа сделок Hubspot с недавней активностью. Агент проверяет их на соответствие методологии OPLOG Way и отправляет форматированные отчеты в Microsoft Teams.

OPLOG построила агента на Strands Agents SDK с тремя специализированными инструментами. Инструмент hubspot_properties() получает данные о сделке и метаданные из API Hubspot через Lambda. Инструмент deal_enrichment() выполняет логику проверки, анализируя сделки по методологии OPLOG Way с правилами, зависящими от бизнес-модели. Инструмент send_teams() форматирует результаты в структурированные отчеты и доставляет их через webhooks. См. следующий код:

from strands_agents import Agent, tool
class DealAnalyzerAgent(Agent):
    @tool
def hubspot_properties(self, deal_id: str) -> dict:
 """Получить данные сделки и метаданные из Hubspot"""
pass
@tool
def deal_enrichment(self, deal_data: dict) -> dict:
 """Проанализировать сделку по методологии OPLOG Way"""
pass
@tool
def send_teams(self, report: dict) -> bool:
 """Сформировать и доставить отчет в Microsoft Teams"""
pass

Логика проверки учитывает сложность customer-agnostic модели fulfillment OPLOG. Разные сделки требуют разной проверки в зависимости от того, относятся ли они только к B2C, только к B2B или одновременно к B2B и B2C. Для B2C-сделок агент проверяет B2C-специфичные поля плюс обязательные поля. Для B2B-сделок он проверяет B2B-специфичные поля. Для комбинированных сделок проверяются оба набора полей. Логика условий действует на всем протяжении: проверка объема требует как минимум одного типа inventory volume для B2C-сделок, но требует и outbound volumes, и inventory volumes для B2B-сделок.

Агент использует Amazon Bedrock с Claude Sonnet от Anthropic, чтобы интерпретировать бизнес-правила и различать намеренно нулевые значения и отсутствующие поля — это тонкое решение, которое требует рассуждений, а не простых проверок на null. Amazon Bedrock Knowledge Bases хранит методологию OPLOG Way в Amazon S3 с использованием стандартных embedding models и vector databases. При проверке сделок агент делает запрос к knowledge base на естественном языке, а Claude применяет извлеченный контекст, чтобы определить правильные правила валидации для каждой стадии сделки и каждой бизнес-модели.

Отчеты, отправляемые в Microsoft Teams, включают статус заполнения сделки, детали по пропущенным полям, ранжирование по приоритету и практические рекомендации. Руководители продаж начинают день с четким пониманием того, какие сделки требуют внимания. Реализация убрала значительное количество ручной ежедневной проверки и улучшила точность прохождения стадий на 91%. AgentCore Observability отслеживает время обработки и успешность доставки отчетов через CloudWatch.

Sales Coach Agent: проверка в реальном времени и автоматизация задач

Sales Coach Agent работает иначе, чем Deal Analyzer Agent: вместо отчетности о проблемах он поддерживает качество данных в реальном времени. Когда sales representatives переводят сделки между стадиями, агент немедленно проверяет обязательные поля и создает задачи по недостающей информации. Это помогает не допускать продвижения сделок с неполными данными и поддерживает чистоту pipeline.

Следующая схема иллюстрирует архитектуру агента:Архитектура использует webhooks Hubspot, чтобы запускать Lambda в момент смены стадии сделки. Lambda вызывает AgentCore Runtime, который проверяет сделку и при необходимости создает задачи — все это в течение 10 секунд. Такой webhook-based подход дает sales representatives немедленную обратную связь, когда они пытаются продвинуть сделку. Агент использует два инструмента, созданных с помощью Strands Agents SDK. Инструмент analyze_deal_properties() получает данные сделки из Hubspot и проверяет обязательные поля в зависимости от операционной модели и новой стадии. Инструмент assign_task() создает приоритетные задачи с подробными инструкциями, связывает их со сделкой и назначает владельцу сделки.

См. следующий код:

from strands_agents import Agent, tool
class SalesCoachAgent(Agent):
    @tool
def analyze_deal_properties(self, deal_id: str) -> dict:
 """Проверить обязательные поля в зависимости от operating model"""
pass
@tool
def assign_task(self, deal_id: str, task_description: str) -> bool:
 """Создать и назначить задачу по валидации владельцу сделки"""
pass

Логика проверки повторяет правила бизнес-модели из Deal Analyzer Agent, но работает с одной сделкой в реальном времени, а не в пакетном режиме. Агент использует ту же knowledge base Amazon Bedrock, где хранится методология OPLOG Way, и делает запросы, чтобы определить, какие поля обязательны для конкретной комбинации стадии и бизнес-модели. Claude Sonnet интерпретирует эти правила и проводит критически важное различие между намеренно нулевыми значениями и отсутствующими полями.

Описание задач конкретно и прикладно. Вместо общих сообщений вроде «заполните недостающие поля» задачи указывают, какие именно поля нужно заполнить, почему они обязательны для текущей стадии и как это сделать. Такая ясность помогает sales representatives быстро решать проблемы без обращения к документации или менеджерам.

Реализация улучшила качество сделок на 91% и достигла более 96% полноты заполнения полей. Среднее время реакции составляет менее 10 секунд от смены стадии до создания задачи, а показатели успеха создания задач превышают 99,2%, при точности валидации выше 97%, что отслеживается через CloudWatch.

Lead Insight Agent: автоматическое исследование потенциальных клиентов

Раньше sales representatives OPLOG тратили много времени на изучение каждого нового лида — вручную искали LinkedIn, проверяли сайт компании, изучали присутствие в соцсетях и пытались понять бизнес-модель. Lead Insight Agent автоматизирует этот процесс целиком, помогая получать подробные профили в течение 2–5 минут после добавления нового контакта в Hubspot.

Следующая схема иллюстрирует архитектуру агента:

Архитектура использует webhooks Hubspot, чтобы запускать Lambda, когда добавляются новые контакты. Lambda вызывает AgentCore Runtime с данными контакта, а агент параллельно ищет в шести социальных средах: Instagram, LinkedIn, Facebook, YouTube, Twitter и TikTok. После анализа цифрового присутствия он отправляет подробный отчет в Microsoft Teams.

Для поиска в соцсетях агент использует AgentCore Browser. AgentCore Browser выполняет навигацию по вебу, рендеринг JavaScript и извлечение контента, избавляя от необходимости строить собственную инфраструктуру web scraping. Агент передает поисковые запросы и шаблоны URL, например site:linkedin.com/in/ [name] [company] для LinkedIn, а AgentCore Browser возвращает структурированный контент из каждой среды. Решение поддерживается AWS, справляется с anti-bot protections и автоматически масштабируется вместе с вызовами агента.

Помимо сбора данных, ценность этого агента — в аналитике. Amazon Bedrock с Claude Sonnet от Anthropic анализирует извлеченный контент, чтобы выявлять релевантные профили, суммировать цифровое присутствие и формировать персонализированные рекомендации по подходу. Агент применяет методологию квалификации OPLOG для оценки ICP fit, определяя, соответствует ли лид целевым характеристикам клиента OPLOG по бизнес-модели, отрасли и digital footprint.

Такая оценка ICP меняет работу sales teams. Вместо того чтобы относиться ко всем лидам одинаково, они могут приоритизировать наиболее перспективные возможности. В отчеты входят данные о присутствии в соцсетях по шести средам, анализ контента с тем, чем делится и что обсуждает prospect, выводы о бизнес-модели на основе digital footprint, определение ICP fit с объяснением и рекомендации по следующему шагу для персонализированного outreach.

Реализация сократила время на исследование лида на 98%, при этом предоставляя более полную аналитику, чем ручной поиск. Агент достигает более 92% успеха в обнаружении соцсетей и более 88% доступности сайтов. Sales teams отмечают более высокую вовлеченность на первом контакте, поскольку получают релевантный контекст до начала общения. AgentCore Observability отслеживает время анализа, покрытие и успешность доставки в Teams, которая превышает 99,5%, через CloudWatch.

Бизнес-эффект и технические результаты

Показатели продаж существенно улучшились. Средняя длительность сделок сократилась на 35%. Конверсия лидов выросла на 28%. Полнота данных в CRM улучшилась до 102%. Время на ежедневную отчетность сократилось на 92%. Производительность sales representatives выросла на 40%.

Рост операционной эффективности был не менее заметным. Время обнаружения проблем снизилось на 81%. Время реакции на устранение улучшилось на 83%. Соблюдение процессов выросло на 52%. Скорость принятия решений ускорилась на 70%.

Технические метрики показывают надежность production-grade уровня. Система обеспечивает near real-time производительность при доступности 99,9%. Система обрабатывает тысячи ежедневных бизнес-событий по всем агентам. Экономическая эффективность достигается за счет serverless-архитектуры, которая масштабируется вместе с нагрузкой, при этом инфраструктурные затраты существенно ниже, чем у традиционных систем.

Улучшение операционной эффективности дало измеримый ROI, значительно превышающий инфраструктурные расходы на систему AI-агентов.

Заключение

Реализация OPLOG показывает, как AI-агенты, развернутые в Amazon Bedrock AgentCore, могут трансформировать BI-операции. Система автономно обрабатывает тысячи ежедневных бизнес-транзакций, обеспечивая на 35% более быстрые sales cycles, на 92% меньше времени на отчетность и uptime на уровне 99,9%. Экономичность serverless-архитектуры — с существенным снижением затрат по сравнению с традиционной инфраструктурой — делает продвинутый AI-driven BI доступным и масштабируемым.

«Мы верили, что AI способен полностью изменить коммерческие операции. С Amazon Bedrock AgentCore в качестве основы мы не просто ускоряем sales cycles — мы заново определяем, как fulfillment-компании конкурируют в масштабе», — говорит Halit Develioğlu, Founder & CEO, OPLOG.

Успех решения объясняется несколькими архитектурными решениями: использование Amazon Bedrock AgentCore для развертывания агентов снимает нагрузку по управлению инфраструктурой; внедрение RAG через Amazon Bedrock Knowledge Bases отделяет бизнес-логику от кода агентов, позволяя обновлять систему без redeployment; использование Claude Sonnet от Anthropic для inference дает возможности рассуждения, необходимые для сложной интерпретации бизнес-правил; а интеграция EventBridge для планирования и event-driven триггеров обеспечивает как автоматическое, так и实时енное выполнение агентов.

OPLOG продолжает расширять систему, добавляя новых агентов, multimodal-возможности для обработки изображений и документов, а также custom fine-tuning для оптимизации поведения агентов под конкретные бизнес-контексты. В дорожной карте компании — дополнительные operational и commercial AI-возможности, которые сейчас находятся в разработке.

Организации, которые хотят построить похожие решения на базе AI-агентов, могут начать с Amazon Bedrock AgentCore, изучив developer guide, поэкспериментировав со Strands Agents SDK для прототипирования агента под конкретный бизнес-процесс и развернув его в serverless runtime AgentCore. Модель оплаты за выполнение означает, что команды могут начать с малого и масштабироваться по мере подтверждения результатов.

Чтобы узнать больше об Amazon Bedrock AgentCore, изучите Amazon Bedrock AgentCore Developer Guide. Информацию о создании AI-агентов с помощью Strands Agents SDK см. в документации Strands. Чтобы изучить реализации Amazon Bedrock Knowledge Bases для RAG, обратитесь к Amazon Bedrock Knowledge Bases User Guide.

Материал — перевод статьи с английского.

Оригинал: Build AI agents for business intelligence with Amazon Bedrock AgentCore

Сгенерировать аудио

По мере масштабирования инфраструктуры AWS операционные процессы неизбежно усложняются. SRE и DevOps Engineers тратят много времени на переключение между AWS Management Console, документацией по CLI и несколькими панелями сервисов. Они вручную переводят бизнес-вопросы в корректный синтаксис API, связывают вызовы между сервисами и заново собирают одни и те же шаблоны интеграции для каждого нового сценария. Со временем эта трение накапливается. Расследование инцидентов требует сопоставления Amazon CloudWatch Logs, состояний экземпляров Amazon Elastic Compute Cloud (Amazon EC2) и политик AWS Identity and Access Management (IAM) в разных интерфейсах. Планирование емкости означает ручные запросы к нескольким сервисам и сбор результатов. Аудиты безопасности требуют последовательностей вызовов API, которые долго писать с нуля.

В этой статье показано, как использовать Amazon Bedrock AgentCore Runtime с поддержкой Model Context Protocol (MCP), чтобы подключить Amazon Quick к сервисам AWS через AWS API MCP Server и создать разговорного AI-ассистента, который переводит естественный язык в команды AWS Command Line Interface (AWS CLI) без переключения между инструментами в критические моменты.

Обзор решения

С Amazon Bedrock AgentCore Runtime и поддержкой MCP естественные запросы напрямую преобразуются в вызовы AWS API. Можно спросить: «Покажи все запущенные экземпляры EC2 в us-east-1», — и получить немедленный и точный результат без переключения между инструментами и без необходимости запоминать синтаксис API. Запросы выполняются безопасно в рамках уже существующих разрешений IAM, а для соответствия требованиям доступен полный журнал аудита Amazon CloudWatch. Вместо того чтобы заново строить логику подключения для каждого рабочего процесса, можно стандартизировать взаимодействие AI-агентов с сервисами AWS через одну повторно используемую интеграцию. На следующей схеме показано, как Amazon Bedrock AgentCore Runtime соединяет Amazon Quick с сервисами AWS через AWS API MCP Server.

Как это работает в повседневных операциях:

1. Вы задаете вопрос на естественном языке: «Покажи запущенные экземпляры EC2 в us-east-1».
2. Пользовательский агент Amazon Quick интерпретирует ваше намерение.
3. Amazon Cognito аутентифицирует запрос: Quick получает JWT-токен из вашего пользовательского пула Amazon Cognito, используя поток client credentials OAuth 2.0 с настроенными Client ID и Client Secret.
4. Агент подключается к AWS API MCP Server: аутентифицированный запрос достигает Amazon Bedrock AgentCore Runtime, который проверяет JWT-токен по конфигурации вашего поставщика удостоверений Cognito.
5. AgentCore Runtime авторизует и маршрутизирует запрос: после проверки токена Cognito AgentCore Runtime безопасно вызывает AWS API MCP Server, работающий в контейнеризованной среде.
6. MCP server преобразует ваш запрос: ваш запрос на естественном языке конвертируется в соответствующую команду AWS CLI.
7. Сервисы AWS выполняют команду: используя настроенную IAM execution role, команда запускается с минимально необходимыми привилегиями для сервисов AWS.
8. Результаты возвращаются в удобочитаемом формате: синтаксис CLI не нужен. Вы получаете структурированный и читаемый ответ прямо в интерфейсе Quick.

Требования

Для прохождения этого материала вам понадобятся следующие условия.

Требования к учетной записи и доступу:

• Учетная запись AWS с административным доступом
• Подписка Amazon Quick Enterprise (минимум Professional tier)
• Доступ к AWS Marketplace — AWS API MCP Server
• Разрешения IAM на создание:
• пулов пользователей Amazon Cognito
• ролей и политик IAM
• агентов Amazon Bedrock AgentCore Runtime
• групп журналов Amazon CloudWatch Log groups

Необходимые программные средства и инструменты:

• Установленный и настроенный AWS CLI (нужен для шага с URL-encoding в walkthrough)

Необходимые знания и опыт:

• Базовое понимание ролей и политик IAM (указано выше)
• Знакомство с потоками аутентификации OAuth 2.0
• Понимание концепций JWT (JSON Web Token)

Дополнительная информация:

• Оценка времени выполнения: 30–45 минут
• Оценочная ежемесячная стоимость: для одного Enterprise-пользователя, выполняющего примерно 500 запросов в месяц, стоимость составляет около $292 в месяц. Основные статьи затрат — подписка Amazon Quick Enterprise ($40/пользователь в месяц) и инфраструктурный сбор ($250/аккаунт в месяц).

Развертывание решения

Ручное развертывание

Чтобы реализовать решение, выполните следующие шаги:

1. Настройте пользовательский пул Amazon Cognito — для аутентификации.
2. Создайте роли IAM — для авторизации.
3. Создайте агента Amazon Bedrock AgentCore Runtime.
4. Настройте Integrations в Amazon Quick для AWS API MCP Server.
5. Создайте пользовательского чат-агента в Amazon Quick.

Визуальные макеты на некоторых скриншотах в этой статье могут отличаться от тех, что отображаются в вашем AWS Management Console.

Настройка пользовательского пула Amazon Cognito

Amazon Cognito обеспечивает аутентификацию и авторизацию вашего приложения. В этом решении вы настраиваете пользовательский пул Cognito для генерации JWT-токенов, которые аутентифицируют запросы к Amazon Bedrock AgentCore Runtime. При JWT-аутентификации с Amazon Cognito вы настраиваете авторизатор в операции CreateAgentRuntime, указывая URL обнаружения для конкретного провайдера идентификации (IdP) и разрешенных клиентов. Существующий код агента изменять не нужно. Вы добавляете конфигурацию авторизатора в развертывание runtime. Когда вызывающая сущность или пользователь обращается к агенту, они передают токен доступа, специфичный для IdP, как bearer token в заголовке Authorization. AgentCore Runtime использует AgentCore Identity, чтобы автоматически проверить этот токен относительно настроенного авторизатора, и отклоняет неавторизованные запросы.

Создайте пользовательский пул Amazon Cognito для JWT-аутентификации с уникальным именем приложения и типом приложения Machine-to-machine application, как показано на следующем скриншоте. Укажите имя приложения, а затем выберите create user directory.

Когда вы создаете пользовательский пул Cognito с приложением типа machine-to-machine, Amazon Cognito автоматически создает ресурсный сервер для вашего приложения. Resource server определяет пользовательские области OAuth 2.0, которые задают разрешения, запрашиваемые приложением.

В меню только что созданного user pool перейдите в Branding и выберите Domain. Выберите созданный Resource server и нажмите edit. Добавьте write scope в пользовательскую область и обновите описания для read и write.

Области read и write управляют доступом к AWS API MCP Server:

• Read scope — разрешает приложению запрашивать ресурсы AWS, например выводить список экземпляров EC2 или описывать корзины Amazon Simple Storage Service (Amazon S3).
• Write scope — разрешает приложению изменять ресурсы AWS, например создавать ресурсы или обновлять конфигурации.

Эти области сопоставляются с разрешениями IAM, которые MCP server использует при выполнении команд AWS CLI от имени аутентифицированных запросов.

Создание ролей IAM

Чтобы запускать агенты или инструменты в Amazon Bedrock AgentCore Runtime, нужна IAM execution role. Инструкции по созданию роли IAM см. в IAM role creation.

Создайте необходимую trust policy и execution role для Amazon Bedrock AgentCore Runtime. Подробнее см. в IAM Permissions for AgentCore Runtime. Замените YOUR_ACCOUNR_ID ниже на ваш идентификатор аккаунта AWS.

Ниже приведен код trust policy для AgentCore Runtime:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "AssumeRolePolicy",
 "Effect": "Allow",
 "Principal": {
 "Service": "bedrock-agentcore.amazonaws.com"
 },
 "Action": "sts:AssumeRole",
 "Condition": {
 "StringEquals": {
 "aws:SourceAccount": "YOUR_ACCOUNT_ID"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:bedrock-agentcore:*:YOUR_ACCOUNT_ID:*"
 }
 }
 }
 ]
}

Ниже приведен код для execution role AgentCore Runtime:

Следующая политика IAM предоставляет execution role разрешения, необходимые для загрузки контейнерного образа AWS API MCP Server и записи runtime-журналов. Контейнерный образ размещен в AWS-managed public репозитории Amazon Elastic Container Registry (Amazon ECR). Вам не нужно самостоятельно собирать или сопровождать образ.

Чтобы найти последний URI контейнера, перейдите в AWS Marketplace – AWS API MCP Server.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "ECRImageAccess",
 "Effect": "Allow",
 "Action": [
 "ecr:BatchGetImage",
                "ecr:GetDownloadUrlForLayer"
            ],
            "Resource": [
                "arn:aws:ecr:us-east-1:709825985650:repository/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogStreams",
                "logs:CreateLogGroup"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:YOUR_ACCOUNT_ID:log-group:/aws/bedrock-agentcore/runtimes/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:YOUR_ACCOUNT_ID:log-group:*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:YOUR_ACCOUNT_ID:log-group:/aws/bedrock-agentcore/runtimes/*:log-stream:*"
            ]
        },
        {
            "Sid": "ECRTokenAccess",
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "xray:PutTraceSegments",
                "xray:PutTelemetryRecords",
                "xray:GetSamplingRules",
                "xray:GetSamplingTargets"
            ],
            "Resource": [ "*" ]
        },
        {
            "Effect": "Allow",
            "Resource": "*",
            "Action": "cloudwatch:PutMetricData",
            "Condition": {
                "StringEquals": {
                    "cloudwatch:namespace": "bedrock-agentcore"
                }
            }
        },
        {
            "Sid": "GetAgentAccessToken",
            "Effect": "Allow",
            "Action": [
                "bedrock-agentcore:GetWorkloadAccessToken",
                "bedrock-agentcore:GetWorkloadAccessTokenForJWT",
                "bedrock-agentcore:GetWorkloadAccessTokenForUserId"
            ],
            "Resource": [
              "arn:aws:bedrock-agentcore:us-east-1:YOUR_ACCOUNT_ID:workload-identity-directory/default",
              "arn:aws:bedrock-agentcore:us-east-1:YOUR_ACCOUNT_ID:workload-identity-directory/default/workload-identity/*"
 ]
 }
 ]
}

Назначьте роли конкретные разрешения, определяющие, какие действия она может выполнять от вашего имени. В этом примере используется ограниченная политика только для чтения, которая разрешает s3:ListBucket и s3:GetObject для всех buckets. Это намеренно широко задано только для обнаружения и изучения.

Примечание: Использование wildcard-ресурса (arn:aws:s3:::*) предоставляет доступ ко всем корзинам S3 в вашем аккаунте. Это приемлемо для начальной настройки и тестирования, но нарушает принцип минимально необходимых привилегий в production. Перед развертыванием в production замените wildcard на конкретные ARN корзин:

"Resource": [
"arn:aws:s3:::your-specific-bucket",
"arn:aws:s3:::your-specific-bucket/*"
]

Пример роли:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeImages"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:Region": "us-east-1"
 }
 }
 }
 ]
}

Создание агента Amazon Bedrock AgentCore Runtime

В Amazon AgentCore выберите в меню runtime, затем host/agent tool. Укажите уникальное имя для runtime-агента. Для Agent Source выберите вариант ECR container и введите URI образа из AWS Marketplace.

На той же странице в разделе permissions выберите существующую роль, созданную на предыдущем шаге.

В разделе inbound auth на той же странице выберите протокол MCP и JWT token для типа входной аутентификации. Для конфигурации схемы JWT используйте существующую конфигурацию identity provider — Cognito identity pool, созданный на первом шаге.

Получите URL обнаружения из сведений о вашем пользовательском пуле Cognito. Найдите Token signing key URL, который имеет следующий формат:https://cognito-idp.$REGION.amazonaws.com/$POOL_ID/.well-known/jwks.json

Замените jwks.json на openid-configuration. Итоговый URL должен выглядеть примерно так:

https://cognito-idp.us-east-1.amazonaws.com/us-east-1_ev5CwXjma/.well-known/openid-configuration

Добавьте разрешенных клиентов в конфигурацию. Перейдите в раздел App Client в вашем пользовательском пуле Cognito, выбрав App Client в левой панели. Скопируйте client ID из сведений App client information и добавьте его в раздел allowed clients.

Настройте дополнительные параметры развертывания AgentCore Runtime. В разделе Advanced configurations оставьте режим сети по умолчанию Public для этого walkthrough. Это позволит runtime быть доступным через интернет на этапе начальной настройки и тестирования.

Для production-развертываний выберите опцию VPC, чтобы ограничить сетевой доступ частной контролируемой средой. Это рекомендуемый подход для рабочих нагрузок, которые обрабатывают чувствительные данные или требуют сетевой изоляции. Затем добавьте переменные окружения, как показано в следующем разделе, и нажмите Create agent.

• AUTH_TYPE: «no-auth»
• AWS_API_MCP_HOST: «0.0.0.0»
• AWS_API_MCP_PORT: «8000»
• AWS_API_MCP_STATELESS_HTTP: «true»
• AWS_API_MCP_TRANSPORT: «streamable-http»
• AWS_API_MCP_ALLOWED_HOSTS = «*»
• AWS_API_MCP_ALLOWED_ORIGINS = «*»

Понимание аутентификации AWS API в AgentCore

AUTH_TYPE установлен в no-auth, потому что сам MCP server не выполняет аутентификацию. Это сделано намеренно и безопасно при развертывании через Amazon Bedrock AgentCore Runtime. AgentCore Runtime выступает в роли границы безопасности. До того как запрос попадет в контейнер MCP server, AgentCore Runtime выполняет проверку JWT-токена. Он проверяет криптографические подписи с помощью публичных ключей из AgentCore Identity, валидирует claims токена (issuer, audience, expiration) и отклоняет запросы, которые не предоставляют действительный bearer token OAuth 2.0. Иными словами, MCP server доверяет тому, что AgentCore Runtime уже аутентифицировал вызывающую сторону. Это тот же подход, который применяется к внутренним микросервисам за API Gateway. Сам сервис не выполняет повторную аутентификацию, потому что это уже сделал gateway.

Примечание: Не используйте AUTH_TYPE: no-auth, если вы запускаете этот MCP server вне AgentCore Runtime, например напрямую на EC2 instance или как отдельный контейнер. В этом случае сервер будет доступен без слоя аутентификации.

Wildcard-значения для AWS_API_MCP_ALLOWED_HOSTS и AWS_API_MCP_ALLOWED_ORIGINS (*) в этом руководстве выбраны намеренно широко. В production замените их на конкретные hostname и origins, которые требуются вашей нагрузке, чтобы обеспечить сетевой доступ по принципу минимально необходимых привилегий.

Создание пользовательского чат-агента в Amazon Quick

Теперь, когда AWS API MCP server работает в Amazon Bedrock AgentCore Runtime, создадим пользовательского чат-агента в Amazon Quick, который можно использовать для выполнения команд AWS CLI через взаимодействие на естественном языке.

Перейдите в консоль Amazon Quick и откройте настройки интеграций. В левой панели навигации выберите Integrations, затем Actions. Добавьте интеграцию протокола MCP, чтобы подключить Amazon Quick к вашему MCP server, размещенному в Amazon Bedrock AgentCore Runtime.

Чтобы настроить параметры интеграции, введите метаданные integration. Укажите описательное Name для интеграции и добавьте понятное Description, объясняющее ее назначение.

Для настройки endpoint получите ARN вашего Amazon Bedrock AgentCore Runtime. Перейдите в раздел Tools Details вашего агента. Скопируйте Runtime ARN из раздела Runtime.

Пример формата ARN:

arn:aws:bedrock-agentcore:us-east-1:123456789123:runtime/demoagent-LmNop08QoR

URL конечной точки должен иметь следующий формат; замените Region на ваш регион AWS и выполните шаги по созданию URL-encoded ARN.

https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{url-encoded-arn}/invocations?qualifier=DEFAULT

Чтобы создать URL-encoded ARN, выполните следующую команду в терминале:

echo "YOUR_ARN" | sed 's/:/%3A/g; s/\//%2F/g'

[System.Uri]::EscapeDataString("YOUR_ARN")

Примечание: bash-команда требует Linux, macOS или Windows с установленным WSL (Windows Subsystem for Linux). Командлет Windows PowerShell работает нативно в Windows без дополнительных зависимостей. Затем оставьте включенной опцию enable auto-publishing. Чтобы обеспечить защищенную связь между Amazon Quick и MCP server, настройте service authentication с использованием учетных данных вашего пользовательского пула Amazon Cognito.

Примечание: Amazon Cognito — это полностью управляемый AWS сервис идентификации, который обрабатывает аутентификацию и авторизацию приложений. Client secret приложений хранится в зашифрованном виде at rest и in transit. Ваши учетные данные не передаются в открытом виде. Cognito также поддерживает ротацию client secret по запросу, так что можно поддерживать до двух активных секретов на app client для ротации без простоя.

Когда появится страница настроек аутентификации, выберите Service Authentication в качестве метода аутентификации.

Чтобы найти Client ID и Client Secret:

1. Откройте Amazon Cognito console.
2. Выберите User Pools, затем ваш user pool.
3. В левой панели навигации выберите App clients (в разделе Applications).
4. Выберите свой app client. App client ID отображается прямо на этой странице.
5. Выберите Show client secret, чтобы раскрыть App client secret.

Примечание: Относитесь к Client Secret как к паролю. Для production-развертываний храните его безопасно с помощью AWS Secrets Manager. Не встраивайте его в клиентский код и системы контроля версий.

Для Token URL соберите его на основе домена вашего user pool:

1. В левой панели user pool прокрутите до раздела Branding.
2. Выберите Domain. Здесь отображается домен Cognito в формате: https://your-domain.auth.region.amazoncognito.com
3. Добавьте /oauth2/token к этому домену, чтобы получить полный endpoint токена: https://your-domain.auth.region.amazoncognito.com/oauth2/token

После ввода Client ID, Client Secret и Token URL выберите Create and Continue.

Примечание: В Amazon Quick ваши учетные данные шифруются с помощью AWS Key Management Service (AWS KMS). По умолчанию Quick использует service-managed AWS KMS key для шифрования учетных данных источников данных и OAuth-токенов. Для организаций с более строгими требованиями комплаенса администраторы аккаунта могут настроить customer managed keys, чтобы полностью контролировать жизненный цикл ключей шифрования, включая возможность мгновенно отзывать доступ и вести аудируемый журнал доступа к учетным данным.

Затем задайте параметры общего доступа для этого действия. Выберите, делиться ли этим действием с другими членами команды, и настройте соответствующие права доступа. Нажмите Done и убедитесь, что действие появилось в разделе Actions.

Теперь создадим разговорного агента, который переводит естественный язык в команды AWS CLI. Перейдите к созданию агента в консоли Amazon Quick, в левой панели выберите Custom Agents, затем Create Chat Agent.

Настройте агента с описательным prompt:

Prompt: Создайте разговорного агента, который позволяет пользователям выполнять команды AWS CLI с помощью естественного языка. Переводите запросы пользователей в соответствующие вызовы AWS API через коннектор aws-api-mcp.

Amazon Quick автоматически обнаруживает и выбирает MCP connector на основе вашего prompt. Проверьте, что к вашему агенту привязана правильная интеграция. Выберите Launch Agent, чтобы сделать его доступным для тестирования.

Автоматизированное развертывание

Для автоматизированного развертывания следуйте инструкциям в GitHub, чтобы развернуть AWS API MCP server в Amazon Bedrock Runtime. Кроме того, чтобы развернуть Cognito user pool и app client, следуйте инструкциям AWS documentation в разделе Appendix в материале Set up Cognito user pool for authentication.

Наконец, для настройки интеграции между Amazon Quick и AWS API MCP server выполните шаги, описанные в разделе Create Custom Chat Agent in Amazon Quick.

Тестирование решения

Чтобы проверить работу пользовательского чат-агента, откройте чат-интерфейс только что созданного custom chat agent и протестируйте команды на естественном языке:

Prompt: Покажи запущенные экземпляры EC2 в регионе us-east-1.

Очистка ресурсов

Чтобы избежать постоянных расходов, удалите ресурсы, созданные в рамках этого решения.

1. Удалите ресурсы Amazon Quick. Уберите включенные функции Amazon Quick, включая пользовательского чат-агента, Spaces и Flows.
2. Удалите MCP integration. Удалите созданное действие Amazon Quick MCP.
3. Очистите ресурсы Amazon Bedrock. Удалите агент Amazon Bedrock AgentCore и связанную с ним IAM execution role.
4. Удалите пользовательский пул Amazon Cognito. Наконец, удалите пользовательский пул Amazon Cognito, созданный для аутентификации.

Заключение

В этой статье вы узнали, как подключить Amazon Quick к сервисам AWS с помощью Amazon Bedrock AgentCore Runtime и AWS API MCP Server. Когда вы стандартизируете взаимодействие AI-агентов с вашей инфраструктурой через MCP, вам не придется заново строить пользовательские шаблоны интеграции для каждого нового сценария.

Дальше этот подход можно расширить для автоматизации типовых операционных запросов. Вы также можете создавать специализированных агентов для задач безопасности, оптимизации затрат или планирования емкости и интегрировать их в процессы управления инцидентами с помощью Amazon Quick Flows и Amazon Quick Automate. В результате вы получаете более последовательный, безопасный и эффективный способ управления инфраструктурой AWS в масштабе.

Материал — перевод статьи с английского.

Оригинал: Integrating AWS API MCP Server with Amazon Quick using Amazon Bedrock AgentCore Runtime

Сгенерировать аудио

Инициатива входит в более широкую кампанию ЕС по наращиванию внутреннего технологического сектора и устранению давнего дефицита позднего финансирования для стартапов. Но фрагментированные рынки капитала и бюрократия по-прежнему могут поставить под угрозу этот план.

Европейский союз активизировал усилия по развитию собственного технологического сектора и снижению зависимости от компаний из США, продвигая на этой неделе планы по созданию фонда объемом €5 млрд ($5,8 млрд), который поможет стартапам масштабироваться в Европе, а не искать капитал или покупателей за рубежом.

Аналитики приветствовали инициативу, но заявили, что ее успех будет зависеть от того, сможет ли она стимулировать более широкие частные инвестиции в европейские технологические компании.

Европейская комиссия на этой неделе выбрала шведскую инвестиционную фирму EQT — одного из крупнейших в Европе инвесторов на частных рынках с активами на $311 млрд — для управления фондом; первые инвестиции ожидаются этой осенью. Фонд поддерживают Еврокомиссия и частные инвесторы, включая Allianz, CriteriaCaixa и Novo Holdings.

Эта работа — часть более широкого курса на укрепление технологического сектора ЕС после отчета Драги о конкурентоспособности за 2024 год. Среди других инициатив — предложения EU Inc, направленные на сокращение бюрократии для стартапов, а также пакет Tech Sovereignty Package, который должен выйти 27 мая и, как ожидается, включит меры поддержки отечественных технологических компаний.

Этот курс отражает обеспокоенность тем, что Европе сложно создавать и удерживать глобально конкурентоспособные технологические компании. По данным Европейской комиссии, лишь около 8% мировых scale-up-компаний базируются в ЕС, тогда как в Северной Америке — примерно 60%. Многие перспективные стартапы при этом поглощаются более крупными компаниями из США еще до того, как достигают масштаба, необходимого для глобальной конкуренции; показательный пример — покупка DeepMind Google в 2014 году.

«Европа создает инновации в области deep-tech мирового уровня и располагает сильным потоком стартапов на ранней стадии, но постоянно не может превратить этот поток в глобально конкурентоспособные компании в масштабе», — сказал Ричард Стивенс, заместитель вице-президента подразделения IDC4EU European Government Consulting в IDC.

Стартапы в ЕС сталкиваются с целым рядом барьеров, включая фрагментированные рынки капитала между государствами-членами. Из-за этого сложно собирать более крупные раунды финансирования в диапазоне от $58 млн до $347 млн, которые технологическим компаниям нужны, чтобы конкурировать с соперниками из США и Китая, сказал Стивенс. Еще один фактор — различия в регулировании между странами ЕС.

«Совокупный эффект таков, что многие из самых перспективных технологических компаний Европы либо переезжают в США, чтобы получить доступ к более глубоким рынкам капитала, либо поглощаются неевропейскими игроками, прежде чем достигают своего полного стратегического потенциала», — сказал Стивенс.

По словам старшего аналитика Forrester Дарио Маисто, который специализируется на облачных технологиях и цифровом суверенитете, европейские технологические стартапы страдают от «плохой культуры частного финансирования предпринимательства» в ЕС. По его словам, государственные механизмы финансирования часто вознаграждают административное соответствие требованиям, а не коммерчески жизнеспособный бизнес.

Стивенс сказал, что цель в €5 млрд сделает Scaleup Europe Fund крупнейшим в Европе специализированным инструментом инвестиций в scale-up-компании, а назначение EQT управляющим фонда подает важный сигнал.

«Решение ЕС структурировать это на коммерческих условиях, с управлением по рыночным стандартам и конкурентной процедурой отбора, отражает сознательный отход от традиционных грантовых инструментов к модели, рассчитанной на мобилизацию частного капитала в масштабе. Это значимо», — сказал он.

По мнению аналитиков, сумма €5 млрд должна рассматриваться лишь как отправная точка: для того чтобы европейский технологический сектор сравнялся с США — где ежегодно размещаются венчурный и growth capital на сотни миллиардов долларов, — и с Китаем, который опирается на поддерживаемые государством инвестиции, потребуется значительно больше капитала.

«Показатель €5 млрд — это капля в море, — сказал Маисто, — но если фонд будет реализован хорошо, он поможет построить более устойчивую экосистему scale-up-компаний». При этом он предупредил, что ЕС пытается решать структурные проблемы в основном через финансирование, хотя бюрократические процессы по-прежнему могут подорвать его усилия.

Стивенс сказал, что ценность фонда будет измеряться тем, сможет ли он удержать «закрепленные на континенте» европейские компании с высоким потенциалом и привлечь соинвестиции со стороны институциональных и корпоративных инвесторов.

Он также указал на потенциал «самоусиливающегося эффекта экосистемы» в таких секторах, как AI, квантовые вычисления, чистая энергетика, биотехнологии и космические технологии — областях, где у Европы уже есть сильные технологические компетенции и где IDC ожидает уверенный рост в ближайшие пять лет.

«Фонд в €5 млрд не сможет в одиночку закрыть разрыв с США и Китаем, но если он простимулирует более широкие структурные изменения в том, как в Европе распределяется капитал, и привлечет импульс со стороны инвестиционного сообщества вокруг него, он может стать по-настоящему преобразующим», — сказал Стивенс.

Материал — перевод статьи с английского.

Оригинал: EU moves forward on $5.8B scale-up fund to keep startups from leaving

Сгенерировать аудио

OpenAI готовится к выходу на биржу спустя день после того, как Илон Маск проиграл иск, который угрожал структуре, руководству и финансам компании, сообщили источники The Wall Street Journal.

Как утверждается, глава OpenAI Сэм Альтман надеется, что компания будет готова стать публичной к сентябрю. Создатель ChatGPT работает с банками Goldman Sachs и Morgan Stanley, которые специализируются на технологических IPO, а конфиденциальную подачу документов для размещения в регулирующие органы компания может сделать в ближайшие дни или недели, пишет WSJ.

Новости о возможном IPO OpenAI, которое, по всем признакам, должно стать блокбастером, появляются на фоне ожидания раскрытия публичных документов по IPO SpaceX, которые, как сообщается, могут появиться уже в среду. Производитель ракет SpaceX, разумеется, теперь один из главных конкурентов OpenAI после того, как он поглотил модельную компанию Илона Маска xAI.

Теперь, когда Маск не смог пронзить OpenAI, сооснователем которой он был, иском, похоже, следующая битва Маска и Альтмана развернется в мире финансов. Какое IPO окажется крупнее?

OpenAI на запрос о комментарии сразу не ответила.

Подача документов SpaceX для IPO полна ставок на AI, мечтаний о Starship и самого Илона Маска в центре

17 часов назад

xAI сожгла $6,4 млрд за прошлый год — документы SpaceX по IPO показывают, почему расходы далеки от завершения

18 часов назад

Илон Маск говорил, что Сэм Альтман «украл» некоммерческую организацию, но суд показал, что у него были схожие цели

2 дня назад

Последнее в разделе Startups

Этот молодой стартап бросает вызов парфюмерной индустрии, которая почти полвека не менялась

3 минуты назад

Maka Kids переосмысливает экранное время детей с помощью стримингового приложения, оптимизированного для благополучия, а не вовлеченности

2 часа назад

In Brief

Стартап Fresha из сферы бьюти-бронирования достиг оценки $1 млрд при поддержке KKR

5 часов назад

Материал — перевод статьи с английского.

Оригинал: OpenAI barrels toward IPO that may happen in September

Сгенерировать аудио

Одна из распространенных функций, которые компании создают в эпоху ИИ, — это подключение сервисов вроде электронной почты, календаря, документов и заметок, чтобы формировать ежедневную сводку в текстовом или аудиоформате. Spotify тоже поддается этому тренду и выпускает для этой задачи новое отдельное desktop-приложение Studio by Spotify Labs.

Сегодня компания добавила возможность исследовать тему, создавая о ней подкаст. Spotify также добавляет в этот инструмент для генерации подкастов личный контекст. И, поскольку в 2026 году компании не могут удержаться от добавления агентов в свои приложения, в новом Studio есть агент, который может просматривать веб и извлекать личную информацию, чтобы создавать персональный подкаст.

Например, инструмент может создать ежедневный брифинг или подкаст на основе вашей электронной почты и расписания. Пользователи также могут задать многошаговый запрос вроде: «Создай ежедневный аудиобрief для моего автопутешествия по Италии. Проведи меня по моему дню, используя календарь и бронирования. Порекомендуй запоминающееся место для ужина рядом с тем местом, где я буду. И закончи рекомендацией подкаста, который я бы с удовольствием послушал в дороге», — чтобы сгенерировать подкаст.

Все такие подкасты, созданные ИИ, сохраняются в библиотеке Spotify для личного использования и синхронизируются между устройствами. Они не доступны публично.

Аудиокомпания предупредила, что это ранняя предварительная версия приложения, и ИИ может ошибаться и постоянно выдавать ненадежный контент.

0 seconds of 36 seconds Volume 90%

Нажмите Shift + ? для списка сочетаний клавиш

00:00

00:36

00:36

Компания выпускает это приложение в режиме research preview более чем в 20 рынках. Она также сообщила, что приложение будет доступно избранным пользователям в возрасте от 18 лет.

Инструмент будет конкурировать с NotebookLM от Google, который несколько лет назад начал популяризировать генерацию подкастов на основе выбранных исходных материалов. И в истинно гугловском стиле компания также выпустила отдельную функцию для создания ежедневного подкаста на основе ленты Discover. С тех пор формат создания подкаста для изучения темы или получения ежедневных брифингов был подхвачен такими компаниями, как Adobe и ElevenLabs, а также приложениями Hero и Huxe.

Запуск desktop-приложения Spotify следует за недавним дебютом командной строки для пользователей кодинговых инструментов вроде Claude Code или Codex, позволяющей создавать персональные подкасты и сохранять их в библиотеку Spotify. С новым приложением Studio и функцией персональных подкастов воспользоваться этим предложением теперь могут и не разработчики.

Запуск — еще один пример того, как Spotify хочет участвовать во всем, что связано с аудио. Благодаря desktop-приложению Spotify в будущем может предложить больше интеграций для создания подкастов. Кроме того, компания может использовать новое приложение для захвата системного аудио и превратить его в заметочник в стиле Granola. Хотя это лишь предположение, мы уже видели, как стартапы вроде Rewind и Cluely превращались в инструменты для заметок на встречах, так что это может стать еще одной областью интереса для компании в дальнейшем.

Когда вы покупаете по ссылкам в наших материалах, мы можем получить небольшую комиссию. Это не влияет на нашу редакционную независимость.

Ivan освещает глобальные потребительские технологические тренды для TechCrunch. Он находится в Индии и ранее работал в изданиях Huffington Post и The Next Web.

Материал — перевод статьи с английского.

Оригинал: Spotify takes on Google’s NotebookLM with its new app

Сгенерировать аудио

Сначала Iris позиционировался как «AI butler», но теперь компания описывает его как программу, которая наблюдает за тем, что происходит на рабочем столе пользователя, и автоматически учится выполнять задачи вместо него, рассказал сооснователь стартапа.

Материал — перевод статьи с английского.

Оригинал: IrisGo, a startup backed by Andrew Ng, looks to become the AI desktop buddy you never knew you needed

Сгенерировать аудио

Облачные среды, созданные для развертывания приложений, теперь должны поддерживать управляемые, воспроизводимые AI-системы уровня исполнения.

Последние несколько лет обсуждение enterprise AI было пронизано оптимизмом: больше моделей, больше пилотов, быстрее автоматизация. Казалось, что достаточно выбрать правильную AI-платформу — и прогресс последует.

Реальность оказалась куда менее благосклонной.

Большинство IT-лидеров убедились, что production AI значительно сложнее, чем предполагали ранние эксперименты. Настоящая работа начинается не тогда, когда модель хорошо работает в изоляции, а тогда, когда ей приходится функционировать в средах, которые защищены, наблюдаемы и устойчивы в эксплуатации.

Недавнее исследование, проведенное моей компанией вместе с enterprise cloud-архитекторами и лицами, принимающими IT-решения, подтверждает то, что многие инженерные команды давно понимают интуитивно: экспериментировать легко. Надежно, повторяемо и на масштабе переводить AI в эксплуатацию — вот что сложно.

Как только AI начинает влиять на реальные рабочие процессы, рекомендовать решения или запускать действия, сама модель быстро становится наименее интересной частью системы. Давление смещается на все, что ее окружает.

Agentic AI масштабируется быстрее, чем среда вокруг него

Данные оставляют мало пространства для споров: AI уже перешел в операционную плоскость. Почти три четверти респондентов сообщают, что активно обучают machine learning-модели, а 76% запускают GPU-нагрузки в production. Более 70% инвестируют в AI reasoning, оптимизацию решений и AI assistants, предназначенных для выполнения задач.

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

При этом многие из этих систем разворачиваются в облачных средах, которые появились задолго до agentic AI. Почти все организации сообщают, что их machine learning pipeline требует переноса более 25% данных — ранний сигнал того, что существующая инфраструктура изначально не была рассчитана на воспроизводимые операции с моделями, стандартизированные feature pipeline или единообразное применение политик.

На практике agentic AI накладывается на платформы, оптимизированные для развертывания приложений, а не для управляемого execution-level intelligence. Именно это архитектурное несоответствие и становится источником трения.

Пробелы в governance становятся видны под давлением исполнения

Пробелы в governance легко не заметить на этапе экспериментов. В средах исполнения они проявляются немедленно.

Почти все организации хранят и обрабатывают personally identifiable information, а большинство работает в рамках регуляторных режимов вроде HIPAA или GDPR. Одновременно примерно половина использует публичные AI-инструменты, тогда как менее четверти сообщают о корпоративных, управляемых AI-развертываниях, построенных на общей framework.

Это создает структурное напряжение. AI-системы влияют на production-решения внутри сред, где governance по определению непоследовательна. Данные проходят через модели без единых audit controls. Применение политик различается между cloud accounts, командами и регионами.

Это не сбой инструментария. Это сбой проектирования системы.

Когда agentic AI напрямую участвует в execution paths, он наследует регуляторные и операционные обязательства enterprise. Если базовая cloud-архитектура не была спроектирована с учетом AI-native governance, командам приходится встраивать controls постфактум в системы, которые никогда не предназначались для такой нагрузки.

Сложность multicloud усиливает проблему

Очень немногие предприятия работают в одном облаке. Многие управляют от шести до 20 cloud accounts у разных провайдеров, а практики infrastructure-as-code различаются по платформам, при этом команды используют AWS CloudFormation и HashiCorp Terraform параллельно.

Devops-организации и без того несут значительную операционную нагрузку, особенно в части мониторинга и надежности распределенных систем. Добавление agentic AI привносит новые stateful-компоненты, зависимости от данных и требования к жизненному циклу. Переобучение моделей, обновление feature store и inference endpoints теперь должны согласовываться с identity, logging и compliance controls в разных средах.

Трение, с которым сталкиваются команды, редко возникает из-за какой-то одной AI-системы. Оно появляется на стыке agentic workloads и cloud-estates, которые годами собирались по частям в ходе модернизации. Чем более фрагментирована среда, тем сложнее обеспечить единообразное governance на уровне AI.

Дело не только в build vs. buy, но и в архитектурном соответствии

Большая часть отрасли по-прежнему рассматривает внедрение agentic AI как выбор между build и buy. Опрос показывает сильную зависимость от вендоров и сервис-провайдеров, что объясняется дефицитом навыков и сжатыми сроками. Но такая рамка упускает главное.

Решающий вопрос — архитектурное соответствие.

Сторонние платформы могут ускорить поставку. Внутренние команды привносят глубокое понимание систем и данных. Успех определяется тем, насколько AI-инициативы интегрируются в окружающую cloud-среду.

Когда сторонние возможности внедряются без согласования с внутренними стандартами, фрагментация ускоряется. А когда AI-системы разрабатываются в отрыве от основных governance frameworks, архитектурный дрейф незаметно накапливается со временем.

В ответ многие организации приходят к другой модели. Вместо того чтобы изолировать AI-проекты в силосах, они встраивают внешнюю AI-экспертизу прямо во внутренние среды поставки. Модели создаются и тестируются с учетом production-grade governance с первого дня. Инфраструктура, compliance и observability рассматриваются как обязательные требования первого порядка, а не как последующая доработка.

Этот подход признает, что немногие предприятия могут полностью укомплектовать все AI-компетенции внутри компании, и одновременно сохраняет архитектурную целостность, необходимую для устойчивого масштабирования.

AI уровня исполнения требует среды уровня исполнения

Agentic AI окончательно перешел в режим исполнения. Предприятия обучают модели, запускают GPU workloads и встраивают интеллектуальные системы непосредственно в операционные рабочие процессы. При этом многие по-прежнему модернизируют pipeline, устраняют пробелы в безопасности и добиваются единообразного governance в все более распределенных cloud estate.

Трение, с которым сталкиваются организации, редко носит алгоритмический характер. Оно архитектурное.

Облачные среды, созданные для развертывания приложений, теперь просят поддерживать управляемые, воспроизводимые AI-системы уровня исполнения. Такой переход не происходит сам по себе. Он требует намеренного проектирования среды.

Модели открывают потенциал. Архитектура определяет, переживет ли этот потенциал столкновение с production. По мере того как AI продолжает влиять на реальные решения и реальные рабочие процессы, успешное масштабирование будет определяться не новизной модели, а надежностью окружающей платформы.

—

New Tech Forum предоставляет площадку для технологических лидеров — включая вендоров и других внешних авторов — чтобы подробно обсуждать новые enterprise-технологии. Отбор материалов субъективен и основан на нашем выборе технологий, которые, по нашему мнению, важны и наиболее интересны читателям InfoWorld. InfoWorld не принимает рекламные материалы к публикации и оставляет за собой право редактировать весь предоставленный контент. Все запросы направляйте на doug_dineley@foundryco.com.

Материал — перевод статьи с английского.

Оригинал: AI at scale: What engineering teams are confronting