Масштабируемая AI-система требует прочного фундамента: данные, инженерия, платформы, операционные модели и управление сходятся и работают как единое целое. Так тему сессии MIT Technology Review EmTech Future формулирует описание сессии, спонсором которой выступает Vanguard.
Сессия разбирает, что нужно для такого фундамента в жёстко регулируемой среде, и как ответственный, надёжный подход превращает новые возможности, включая агентные системы, в долгосрочную ценность для инвесторов. Спикер: Jing Wang, Principal, Center for AI and Insights, Vanguard.
Исходный материал - анонс сессии, а не отчёт с метриками, архитектурой и кейсами. Поэтому ниже рамка разобрана по частям: что проверять по каждому компоненту, какие вопросы задавать до промышленной эксплуатации и где границы самой рамки. Читайте её как структуру для аудита готовности, а не как доказанный бенчмарк.
Что стоит за масштабируемым AI: главный тезис сессии EmTech Future
Тезис простой: масштаб даёт система вокруг модели. Самая сильная модель не компенсирует слабые данные, инженерию, платформы, операционную модель и управление. Если один слой отстаёт, остальные не закрывают разрыв.
Почему «просто модель» не масштабируется
Пилот обычно проверяет качество ответа на ограниченном наборе задач. Промышленная эксплуатация проверяет другое: выдержит ли система нагрузку, сохранится ли качество через месяц, кто отвечает за сбой, можно ли воспроизвести результат и объяснить его проверяющему.
Пять компонентов рамки закрывают разные точки отказа. Данные отвечают на вопрос, на чём училась и работает система. Инженерия обеспечивает воспроизводимость, тесты и мониторинг. Платформы дают общий доступ к моделям, данным и логам. Операционная модель закрепляет владельца и процесс изменений. Управление задаёт правила, контроль и доказательства для аудита.
Типичный разрыв между пилотом и продом выглядит так: в ноутбуке данные лежат в CSV, в проде их надо обновлять и версионировать; в демо промпт правит один разработчик, в проде изменение проходит согласование; в тесте ошибку видит автор, в проде она уходит клиенту. Модель здесь не главная причина. Причины организационные и инженерные.
Отсюда практический вывод: перед масштабированием команде нужны ответы по каждому из пяти слоёв. Ещё один бенчмарк здесь не поможет. Ниже - вопросы, которые стоит поднять на защите пилота.
Кто такая Jing Wang и почему рамке стоит доверять, с оговорками
Jing Wang руководит Center for AI and Insights (CAI) в Vanguard и развивает направления AI, машинного обучения, генеративного AI и поведенческих наук. Её команда ведёт инновации, исследования и поставку решений на уровне всего предприятия, помогая переводить новые технологии в доверенные решения с измеримой бизнес-ценностью. До этой должности она занимала руководящие роли в подразделениях Vanguard Financial Services, Workplace Solutions, International и Corporate Services. Эти сведения приведены в анонсе сессии.
Оговорки важны для честного чтения. Материал спонсирован Vanguard, спикер работает в Vanguard, а сам текст - анонс, не отчёт. В нём нет цифр, описания стека и кейсов. Рамка полезна как способ организовать разговор между бизнесом, инженерией, рисками и комплаенсом. Доказательства эффективности придётся собирать внутри своей организации.
Данные как фундамент: что должно быть готово до масштабирования
Данные первыми ломают масштабирование, потому что их качество и права часто остаются неявными. Пилотная команда может годами работать на выгрузке, никто не помнит, откуда взялись поля, а после запуска выясняется, что часть записей нельзя использовать.
До промышленной эксплуатации стоит зафиксировать несколько вещей.
- Происхождение данных: откуда пришли, кто владелец, на каком основании используются, какие ограничения на передачу и хранение.
- Качество и разметка: кто проверяет полноту, дубли, ошибки, устаревшие значения; как оформляются исправления.
- Версионирование: какая версия данных связана с конкретной версией модели, промпта и результата.
- Доступ: кто видит сырые данные, кто обезличенные, кто агрегаты; как выдаются и отзываются права.
- Хранение и удаление: сколько данные живут, что происходит при запросе на удаление, как это отражается в резервных копиях.
В регулируемой среде добавляется прослеживаемость (data lineage): по каждому полю нужно показать путь от источника до решения. Документация и аудит данных становятся частью продукта, потому что проверяющий спросит не только «какая модель», но и «на каких данных получен ответ».
Практический вопрос к команде: если завтра изменится поставщик данных или потребуется удалить записи клиента, сколько систем придётся обойти? Ответ показывает зрелость фундамента.
Инженерия и архитектура AI-системы: от ноутбука к промышленной эксплуатации
Инженерия превращает эксперимент в процесс. Минимальный набор практик выглядит буднично, но именно он отделяет пилот от системы.
- Воспроизводимость: фиксируются версии модели, параметры, промпты, датасеты и окружение. Повторный запуск даёт сопоставимый результат.
- CI/CD для моделей и промптов: изменения проходят проверку, тестовую среду и контролируемый выпуск.
- Регрессионные тесты качества: наборы задач с эталонными ответами или правилами проверки. Тест ловит деградацию после смены модели или промпта.
- Мониторинг: качество ответов, доля отказов, задержки, стоимость запроса, дрейф входных данных.
- Обработка ошибок: таймауты, недоступность провайдера, пустые ответы, превышение лимитов. Система должна деградировать предсказуемо.
Архитектура AI-системы делится на слои: данные, модели, оркестрация, интерфейсы, контроль. Политики и проверки лучше держать в отдельном слое, а не размазывать по коду приложения. Тогда правило «не отправлять чувствительные данные во внешний API» можно проверить в одном месте.
Критерий зрелости простой: можно ли заменить модель, не переписывая продукт? Если ответ «нет», система привязана к поставщику и версии. Это допустимо для эксперимента, рискованно для промышленной эксплуатации.
Выбор между API и локальным развёртыванием решается требованиями, а не модой. Внешний API быстрее запустить и проще масштабировать по нагрузке. Локальная модель даёт контроль над данными и окружением, но требует оборудования, эксплуатации и собственной экспертизы. Для регулируемой среды решающими становятся требования к хранению данных, аудиту и допустимости передачи информации третьей стороне.
AI-платформы для бизнеса и ML-платформы: что именно покупать и что строить
Платформенный слой нужен, чтобы команды не собирали заново доступ к моделям, логирование и контроль затрат. Здесь легко купить слишком много и получить набор инструментов, который никто не обслуживает.
Различайте три платформенные зоны.
- ML-платформы и MLOps: обучение, реестр моделей, деплой, мониторинг, управление версиями.
- Платформа для генеративного AI и агентов: оркестрация, RAG, управление промптами, шлюз к моделям, политики вызова инструментов.
- Платформа данных: каталог, качество, права доступа, lineage, хранение.
Практические вопросы по платформе: будет ли единая точка логирования и аудита; можно ли ограничить модели и инструменты по подразделениям; как считаются затраты на запросы; есть ли изоляция тестовой и промышленной сред; кто отвечает за обновления.
Шлюз к моделям решает несколько задач сразу: единая аутентификация, учёт стоимости, ограничения по типам данных, журнал запросов и быстрая замена поставщика. Без такого слоя каждая команда строит свой обход, а комплаенс получает зоопарк интеграций.
Ограничение рамки: в анонсе сессии нет описания стека Vanguard. Не приписывайте компании конкретные инструменты. Речь о категориях платформенных решений, которые команда выбирает под свои требования.
Операционная модель AI: кто владеет системой после запуска
Операционная модель отвечает на скучные вопросы, без которых система умирает через месяц после презентации. Кто владелец AI-продукта? Кто отвечает за данные? Кто утверждает смену модели? Кто принимает инцидент в субботу?
Роли стоит развести. Владелец продукта отвечает за пользу и приоритеты. Инженерная команда за работоспособность и изменения. Владелец данных за качество, доступ и сроки хранения. Риски и комплаенс за рамки допустимого. Без явного владельца решения зависают между подразделениями.
Отдельно фиксируется процесс изменений: кто может править промпт, какие правки требуют проверки, как откатывается неудачный выпуск. Промпт в промышленной системе - такой же артефакт, как код. У него есть версия, автор, тесты и журнал изменений.
Пример структуры, а не универсальный шаблон: Center for AI and Insights Vanguard ведёт инновации, исследования и поставку решений на уровне предприятия. Такая структура помогает собрать экспертизу и общие стандарты. Для другой компании рабочая модель может выглядеть иначе: центральная платформа плюс продуктовые команды, федерация с общими правилами или выделенный AI-офис.
Операционная модель часто становится главной причиной, по которой пилот не доходит до прода. Модель работает, а решения об изменениях, бюджете и ответственности не приняты. Полезный разбор ролей и структуры команд есть в материале об AI-native организации.
Управление AI governance и ответственный AI: как встроить контроль в систему
Governance не сводится к документу, который лежит в wiki. Он работает, когда правила встроены в платформу и процесс: что можно отправить в модель, какие действия требуют подтверждения, что логируется, кто видит инцидент.
Практические элементы управления:
- Политика использования AI: допустимые сценарии, запрещённые данные, требования к проверке человеком.
- Классификация рисков: чем выше влияние на клиента, деньги или регуляторные обязательства, тем строже проверка.
- Документация модели и сценария: назначение, ограничения, данные, известные слабые места, владелец.
- Человеческий надзор: где человек утверждает действие, где проверяет выборку, где только получает уведомление.
- Логирование и аудит: кто, когда и с каким результатом вызвал модель или агента.
- Инциденты: как фиксируются, кто разбирает, какие сроки реакции.
Контроль на уровне шлюза к моделям дешевле, чем ручная проверка каждого запроса. Policy as code позволяет автоматически блокировать запрещённые данные, ограничивать инструменты агента и сохранять доказательства. Ручной тормоз в виде согласования каждой мелочи быстро приводит к обходным путям.
Формулировка сессии связывает ответственный и надёжный подход с долгосрочной ценностью для инвесторов. Логика простая: доверие к системе снижает риск дорогих инцидентов и позволяет масштабировать сценарий без постоянного ручного сопровождения. Это тезис сессии, а не измеренный результат.
Переход от строительства к управлению AI-системами разобран в статье про governor shift: там есть принципы вместо жёстких правил, порог уверенности и управление по исключениям.
Жёстко регулируемая среда: что меняется для AI-команд
В финансах, страховании, здравоохранении и госсекторе AI-система должна не только выдавать ответ, но и доказывать, как он получен. Сессия отдельно подчёркивает жёстко регулируемую среду, потому что там требования к доказательствам влияют на архитектуру.
Что меняется на практике:
- Прослеживаемость решения: связь ответа с версией модели, промпта, данными и политикой.
- Хранение логов: достаточный срок и защита от изменения, чтобы проверка могла восстановить картину.
- Контроль доступа: разграничение ролей, журнал действий администраторов, защита чувствительных данных.
- Проверка поставщиков: какие данные получает внешняя модель, где они хранятся, какие условия возврата и удаления.
- Документирование изменений: кто утвердил новую версию, какие тесты прошла, какие риски пересмотрены.
Архитектурные следствия: аудит на уровне платформы, ограничение внешних API, изолированные или локальные развёртывания там, где передача данных нарушает требования. Vanguard в этом контексте показателен как финансовая компания, но анонс не описывает её конкретные практики. Детали зависят от отрасли, юрисдикции и регулятора.
Агентные системы: почему к ним предъявляются повышенные требования
Агент отличается от чат-бота тем, что выполняет действия: вызывает инструменты, меняет записи, отправляет запросы. Ошибка чат-бота стоит неверного ответа. Ошибка агента может стоить операции, платежа или утечки данных.
Отсюда дополнительные требования:
- Ограничение полномочий: агент получает только те инструменты и данные, которые нужны для задачи.
- Подтверждение действий: опасные операции проходят через человека или отдельную политику.
- Журналирование: видно, какой шаг агент выполнил, с каким аргументом и результатом.
- Изоляция: тестовый агент не имеет доступа к промышленным системам.
- Контроль стоимости и циклов: ограничение числа шагов, таймауты, бюджет на вызовы.
Без операционной модели и governance агент превращается в риск с красивой демонстрацией. С ними появляется управляемый сценарий, где ценность можно измерить.
Подход, в котором агент предлагает, человек утверждает, а исполнитель применяет только допущенные действия, разобран в материале про Agent-Ops 0.4.0. Он полезен как пример разделения ролей и фиксации допуска.
От пилота к промышленной эксплуатации: чек-лист вопросов для команды
Соберите ответы по пяти компонентам. Это способ увидеть разрывы до прода, без экзамена с оценкой.
Данные
- Известно ли происхождение каждого набора данных и права на его использование?
- Есть ли версия данных, связанная с версией модели и результатом?
- Описаны ли правила хранения, удаления и доступа к чувствительным данным?
Инженерия
- Можно ли воспроизвести результат пилота на тех же версиях модели, промпта и данных?
- Есть ли регрессионные тесты качества и мониторинг дрейфа?
- Проверены ли сбои провайдера, таймауты и деградация?
- Посчитана ли стоимость инференса при целевой нагрузке?
Платформы
- Есть ли единая точка доступа к моделям, логам и учёту затрат?
- Разделены ли тестовая и промышленная среды?
- Можно ли заменить модель или поставщика без переписывания продукта?
Операционная модель
- Указан ли владелец системы и владелец данных?
- Описан ли процесс изменения промпта и модели?
- Кто разбирает инциденты и в какие сроки?
Управление
- Классифицированы ли риски сценария?
- Встроены ли политики и аудит в платформу?
- Где требуется человеческий надзор и как он документируется?
Разрыв между пилотом и рабочей системой часто связан с безопасностью агентов и готовностью команды сопровождать продукт. Практические вопросы по этому переходу собраны в разборе AI Stage на TechCrunch Disrupt 2026.
Ответы зависят от отрасли и масштаба. В одном случае достаточно внешнего API и лёгкого шлюза. В другом нужны локальные модели, изолированный контур и отдельная команда эксплуатации. Единого рецепта нет, но набор вопросов один.
Что взять из рамки Vanguard и MIT Technology Review и чего в ней нет
Рамка из пяти компонентов полезна как структура аудита. Она помогает собрать бизнес, инженерию, данные, риски и комплаенс за одним столом и задать конкретные вопросы: где живут данные, кто владеет системой, как проверяется качество, что логируется, кто утверждает изменения.
Границы тоже понятны. Материал - анонс сессии, он спонсирован Vanguard, спикер работает в Vanguard. В нём нет метрик, кейсов и архитектуры. Утверждение о долгосрочной ценности агентных систем сформулировано как тема сессии, а не как доказанный результат.
Практический вывод: возьмите пять компонентов как чек-лист и проверьте свой пилот. Если по каждому пункту есть владелец, процесс и доказательство, масштабирование обсуждаемо. Если хотя бы один слой держится на героизме одного инженера, система пока не готова к промышленной эксплуатации.