Как Amazon автоматизировала ответы регуляторам с помощью генеративного ИИ на AWS — VogueTech

Что произошло

FinTech-команды Amazon перестроили процесс работы с регуляторными запросами и запустили на AWS масштабируемую систему на базе генеративного ИИ.

Ключевые элементы стека:

Amazon Bedrock — ядро решения: генеративные модели и Knowledge Bases.
Claude Sonnet 4.5 через Converse Stream API — для диалогов в реальном времени.
Claude 3.5 Haiku — для расширения и переформулировки запросов.
Amazon Bedrock Knowledge Bases + Amazon OpenSearch Serverless — хранение и поиск векторных представлений документов.
Amazon S3 — хранилище исходных документов.
AWS Lambda — оркестрация всех этапов: загрузка, обработка, чат.
Amazon API Gateway (WebSocket API) — канал для стриминга ответов в реальном времени.
Amazon DynamoDB — хранение истории диалогов и аудита.
Amazon Cognito — аутентификация пользователей.
OpenTelemetry (OTEL) + Langfuse (self-hosted) — сквозная наблюдаемость и аналитика.

Каждая FinTech-команда Amazon получила свой отдельный knowledge base, наполненный собственными документами и справочниками. Система не кэширует ответы LLM и промежуточные результаты, потому что регуляторные запросы сильно зависят от контекста и почти не повторяются.

Запуск этого стека — ответ на рост количества регуляторных запросов и усложнение бизнеса Amazon. Цель — обрабатывать больше запросов, быстрее и с прозрачным контролем качества ИИ-ответов.

Зачем это нужно

Почему Amazon делает это сейчас

У Amazon растёт частота и сложность запросов от регуляторов в разных юрисдикциях. Каждый запрос — это разные форматы документов, разные требования и сроки.

Раньше командам приходилось вручную:

искать нужные документы среди тысяч файлов (PDF, PPT, Word, CSV);
выдёргивать релевантные фрагменты;
сверять данные в разных внутренних системах;
собирать ответ в сжатые сроки.

По мере роста бизнеса такая схема перестала масштабироваться. Генеративный ИИ на Bedrock здесь не про «красивый чат-бот», а про очень конкретную задачу: быстро и контролируемо собирать сложные, формально выверенные ответы.

Что это даёт Amazon

Снятие проблемы «расползания знаний»
- Документы лежат в разных форматах и хранилищах.
- Knowledge Base на Bedrock, плюс векторный поиск в OpenSearch Serverless, превращают этот хаос в единое пространство, где можно искать по смыслу, а не только по ключевым словам.
Многошаговые диалоги вместо статичных запросов
- Регуляторный запрос редко закрывается одним письмом.
- Команды уточняют формулировки, добавляют данные, возвращаются к старым обсуждениям.
- DynamoDB хранит историю чатов по conversation ID, поэтому система «помнит» контекст и даёт согласованные ответы.
Управляемый риск ИИ: меньше «галлюцинаций» и ошибок
- Через OTEL и Langfuse команды видят, какие документы подтянулись, какой промпт ушёл в модель и как она отвечала.
- Можно отследить, когда ИИ ссылается на устаревшие регуляторные требования или придумывает факты, которых нет в документах.
Автоматический масштаб
- Вся архитектура — на serverless-сервисах AWS.
- Нет ручного управления кластерами под пики запросов.
- При росте числа регуляторных запросов система просто обрабатывает больше сессий параллельно.

Что получают команды внутри Amazon

Быструю загрузку пачек документов в knowledge base без ручной конвертации.
Чат, который понимает контекст прошлых сообщений и поднимает релевантные документы.
Автоматическую защиту от утечек PII и финансовых данных через Guardrails.
Прозрачную трассировку каждого ответа: от запроса до конкретного источника.

Минус для команд: придётся дисциплинированно вести документацию и следить за актуальностью базы. ИИ не исправит устаревшие документы — он их просто аккуратно и быстро найдёт.

Что меняет для рынка

Новый стандарт для регуляторных команд

Amazon фактически показывает целый референс-паттерн для финансовых и комплаенс-команд:

RAG на Bedrock Knowledge Bases + OpenSearch Serverless;
стриминговый чат с Claude Sonnet 4.5 через Converse Stream API;
query expansion через Claude 3.5 Haiku;
полная трассировка через OTEL и Langfuse.

Это не эксперимент «в лаборатории», а рабочая архитектура под реальные регуляторные дедлайны.

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

Последствия для конкурентов

Поставщики комплаенс-платформ и регуляторных решений вынуждены будут:
- добавлять RAG поверх своих архивов документов;
- внедрять трейсинг на уровне промптов и ответов;
- показывать заказчикам, откуда ИИ взял конкретный факт.
Вендоры без прозрачной наблюдаемости и защиты от «галлюцинаций» будут выглядеть сырыми.

Что меняется для инвесторов

Появляется понятная архитектура, которая снижает операционные риски в регуляторной сфере.
Это сигнал: генеративный ИИ можно использовать не только в маркетинге и поддержке, но и в зоне с максимальными рисками — в общении с регуляторами.
Компании, которые смогут показать похожий уровень контроля (логирование, guardrails, трейсинг), будут выглядеть более зрелыми.

Что меняется для пользователей внутри корпораций

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

Роль человека не исчезает: он по-прежнему принимает финальное решение и проверяет факты. Но сбор и первичная компоновка информации становятся быстрее.

Как это работает технически

1. Поток загрузки и индексации документов

Сценарий, когда команда загружает пачку документов (исторические ответы, регуляторные письма, внутренние политики) в knowledge base.

Шаги:

Загрузка документов
- Пользователь загружает файлы через клиентское приложение.
Получение pre-signed URL
- Клиентское приложение отправляет запрос в Amazon API Gateway.
- API Gateway вызывает AWS Lambda для ingestion, которая генерирует pre-signed URL для Amazon S3.
Загрузка в S3
- Клиент использует pre-signed URL и кладёт документ в S3.
Триггер обработки
- После успешной загрузки клиент вызывает API Gateway, который запускает документную Lambda.
- Lambda:
  - занимается конвертацией форматов при необходимости;
  - управляет параллельной обработкой большого числа документов.
- Изображения, таблицы и графики не нужно заранее обрабатывать.
- Amazon Bedrock Data Automation (BDA) внутри Knowledge Base умеет вытаскивать мультимодальный контент.
Индексация и векторное хранилище
- Amazon Bedrock Knowledge Base:
  - режет документ на фрагменты с помощью иерархического chunking;
  - строит эмбеддинги через Amazon Titan Text Embeddings;
  - складывает вектора в Amazon OpenSearch Serverless.

Иерархическое разбиение создаёт структуру «родитель–потомок», которая повторяет разделы финансовых документов. В поиск попадают маленькие куски, но при ответе система возвращает более крупные блоки, чтобы у ИИ был контекст.

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

2. Чат-приложение и стриминг ответов

Фронт для команд — это чат, который ведёт диалог в реальном времени, поднимает нужные документы и помнит историю.

Как устроен поток:

Старт сессии
- Пользователь открывает новый чат или возвращается к существующему.
- Аутентификация идёт через Amazon Cognito.
- Сессия получает уникальный conversation ID.
WebSocket-соединение
- Клиент открывает WebSocket к Amazon API Gateway.
- Это даёт двунаправленный канал для стриминга ответов.
Отправка сообщения
- Вопрос пользователя уходит по WebSocket.
- API Gateway прокидывает его в Chat Service Lambda.
Санитизация и классификация запроса
- Lambda очищает запрос, чтобы защититься от prompt injection.
- Отдельный вызов LLM классифицирует запрос как:
  - простой разговорный, или
  - knowledge intensive, требующий обращения к базе знаний.
Query expansion через Claude 3.5 Haiku
- Для сложных запросов Lambda вызывает Claude 3.5 Haiku.
- Haiku генерирует до пяти вариантов запроса.
- Это помогает, когда пользователи пишут с сокращениями и аббревиатурами.
Поиск в Knowledge Base
- Для каждого варианта запроса Lambda вызывает Amazon Bedrock Knowledge Bases Retrieve API.
- Retrieve API делает векторный поиск по OpenSearch Serverless.
- Возвращает самые релевантные фрагменты с метаданными и оценками релевантности.
- Вызовы идут параллельно (многопоточность).
- Переход от последовательной обработки к параллельной сократил задержку поиска с ~10 секунд до меньше 2 секунд.
Сбор контекста
- Lambda достаёт историю диалога из Amazon DynamoDB по conversation ID.
- Склеивает:
  - текущий вопрос,
  - релевантные фрагменты из Knowledge Base,
  - последние сообщения из истории.
Генерация ответа через Claude Sonnet 4.5
- Lambda вызывает Converse Stream API в Amazon Bedrock с Claude Sonnet 4.5.
- Применяется специальный промпт-генератор для ответов на основе собранного контекста.
- Включены Amazon Bedrock Guardrails:
  - фильтруют PII;
  - убирают чувствительные финансовые данные из входа и выхода.
- Если система обнаруживает попытку prompt injection, она отвечает:
  
  «Sorry, the model cannot answer that question».
Стриминг и сохранение истории
- Lambda стримит ответ в Markdown обратно по WebSocket.
- Вся сессия — вопросы и ответы — сохраняется в таблицу Conversational History в DynamoDB.
Наблюдаемость через OTEL и Langfuse
- Chat Service Lambda отправляет трассы в self-hosted Langfuse через OpenTelemetry SDK.
- Фиксируются:
  - задержки на каждом шаге;
  - использование токенов;
  - промпты и ответы моделей;
  - результаты поиска в Knowledge Base.

3. Многошаговые диалоги и аудит

Регуляторные кейсы редко укладываются в один вопрос. Нужна длинная, ветвящаяся переписка.

Архитектура поддерживает это так:

DynamoDB хранит сообщения в хронологическом порядке для каждого conversation ID.
Пользователь может вернуться к старой сессии и продолжить с того места, где остановился.
Система использует недавнюю историю как контекст при каждом новом запросе.
Все действия попадают в лог и трассируются через OTEL и Langfuse.

Для комплаенса это критично:

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

4. Наблюдаемость и контроль качества ИИ

Amazon делает ставку на прозрачность работы ИИ, а не только на скорость.

Как это реализовано:

Chat Service Lambda вручную инструментирована через OTEL Java SDK.
На каждом этапе создаются OTEL-spans с:
- временем выполнения;
- количеством токенов;
- метаданными промптов;
- решениями модели.
Данные публикуются в Langfuse почти в реальном времени.
Используется OTEL Generative AI semantic standard, поэтому трассы можно отправлять и в другие системы мониторинга, а не только в Langfuse.

Для инженеров и applied scientists это даёт:

видимость, как именно Converse Stream API, Knowledge Base и Claude Sonnet 4.5 взаимодействуют в рамках одного запроса;
возможность найти узкие места по латентности;
поле для экспериментов с промптами и стратегией поиска без потери управляемости.

Langfuse визуализирует полный путь: от query expansion и поиска по OpenSearch до финального ответа. В интерфейсе видны и цитаты источников, поэтому можно понять, на какие документы опирался ИИ.

Что это значит для вас

Если вы CDTO, CIO или отвечаете за ИИ-стратегию

Перед вами готовый референс-архитектурный паттерн для:
- юридических и регуляторных запросов;
- внутренних справочных систем;
- сложных процессов, где нужен аудит и объяснимость ИИ.
Вы можете взять тот же набор блоков AWS:
- Bedrock (Knowledge Bases, Converse Stream API, Guardrails),
- OpenSearch Serverless,
- Lambda + API Gateway (WebSocket),
- DynamoDB,
- Cognito,
- OTEL + Langfuse, и развернуть аналогичный стек под свои доменные документы.

Если вы руководите комплаенсом, юридическим или финансовым блоком

Это демонстрация, что генеративный ИИ можно безопасно использовать даже в зоне, где ошибка дорого стоит.
Ключевые элементы, без которых схема не работает:
- строгая сегрегация баз знаний по командам;
- явные guardrails на PII и финданные;
- полный лог и трассировка промптов и ответов.
Если ваш текущий ИИ-инструмент не даёт:
- ссылок на источники,
- истории диалогов с аудитом,
- защиты от prompt injection, — есть смысл пересмотреть требования к поставщикам.

Если вы инженер или архитектор

Статья по сути описывает рабочий blueprint RAG-системы на AWS:
- ingestion-пайплайн на Lambda + S3 + Bedrock Data Automation;
- векторное хранилище на OpenSearch Serverless;
- многошаговый чат на WebSocket API Gateway + Lambda + DynamoDB;
- query expansion через лёгкую модель (Claude 3.5 Haiku);
- генерация через более мощную модель (Claude Sonnet 4.5) со стримингом;
- observability через OTEL + Langfuse.
Плюс важная деталь: отказ от кэширования LLM-ответов. Для регуляторных кейсов это логично — запросы слишком уникальны, а риск повторного использования неподходящего ответа высок.

Если вы продукт-менеджер ИИ-систем

Хороший пример, как спроектировать продукт так, чтобы ИИ не «жил сам по себе», а был встроен в:
- процесс работы команд,
- требования комплаенса,
- инфраструктуру мониторинга.
Обратите внимание на разделение ролей моделей:
- Haiku — дешёвый и быстрый «расширитель» запросов;
- Sonnet 4.5 — основной «мозг» для ответов.

Выводы для тех, кто строит свои ИИ-решения

Amazon показала, как собрать из стандартных AWS-сервисов рабочий контур для сложных, чувствительных задач:

ingestion-пайплайн, который понимает PDF, PPT, Word, CSV, таблицы и графики через BDA;
RAG на Bedrock Knowledge Bases + OpenSearch Serverless с иерархическим chunking;
многошаговый чат со стримингом и хранением контекста в DynamoDB;
guardrails, которые режут PII и финансовые данные;
OTEL + Langfuse для сквозной наблюдаемости и контроля качества ИИ.

Если вы хотите перевести юридические, регуляторные или другие знанияёмкие процессы на генеративный ИИ, этот паттерн можно использовать как основу и адаптировать под свой домен, не жертвуя управляемостью и прозрачностью.