AWS опубликовала эталонный проект Amazon Quick для вопросов о соблюдении требований в большой коллекции договоров аренды. Полезная идея здесь — строгое разделение ролей: чат-модель выбирает заранее заданный инструмент и объясняет ответ, а отдельный движок правил определяет состав проверяемых записей и выносит каждое заключение. В публикации от 2 октября и репозитории образца описан учебный прототип, а не проверенный сервис юридического соответствия требованиям.

Для инженера или руководителя по соблюдению требований вопрос в том, подходит ли такое разграничение для проверяемого решения. В образце используются синтетические договоры аренды, вымышленные правила и ссылки на источники. Приведённые итоги показывают предполагаемый формат результата; они ничего не говорят о точности на реальных договорах или о требованиях закона.

Главное изменение

  • Что изменилось: образец AWS превращает ИИ в управляемый интерфейс к фиксированному набору инструментов проверки. Движок правил определяет результаты для перечисленной совокупности договоров аренды.
  • Почему это важно: правила с версиями и квитанция с доказательствами дают проверяющим возможность изучить оценку выбранных записей вне чата.
  • За чем следить: квитанция не подтверждает полноту перечня документов, качество извлечения данных или правильность юридических правил. Внедряющие решение должны проверить эти входные данные, указание пользователя и работу системы на собственных данных.

Сначала определяется совокупность, потом составляется запрос

Пользователь может спросить Quick, какие договоры аренды в Техасе нарушают правило о штрафе за просрочку на заданную дату. Quick направляет запрос в sweep_compliance — одну из шести именованных операций MCP. Операция использует указанную юрисдикцию и дату, чтобы выбрать совокупность записей и применимые правила с версиями. Модель не пишет SQL-запрос и не определяет, соответствует ли условие договора правилу. Движок применяет фиксированные операторы сравнения, а значения правил передаются ему как параметры. По словам AWS, при официальной массовой проверке модель не используется. AWS объясняет контракт операции здесь; в репозитории описана её реализация.

У остальных инструментов более узкие функции. simulate_rule_change позволяет в исследовательском режиме подсчитать предполагаемые значения, не записывая заключений. explore_clauses ранжирует отфильтрованную выборку по семантическому сходству и не отвечает на вопрос «сколько?». get_finding извлекает одну цепочку доказательств; list_rules показывает правила, действовавшие на выбранную дату; check_connection проверяет передачу данных. Это различие важно: выборка подходящих условий договора не является переписью всей совокупности.

При массовой проверке создаётся квитанция, учитывающая каждую просмотренную запись в одной из четырёх категорий: соответствует требованиям, нарушение, неоднозначный результат или прочитать не удалось. Перед сохранением движок проверяет, что сумма записей по категориям равна общему числу просмотренных записей. Quick может показать итоговые числа и небольшую выборку, а панель Quick Sight считывает полный набор результатов из того же хранилища Aurora. Каждое заключение содержит текст условия, извлечённые и ожидаемые значения, версию правила и ссылку на источник. Это свойства проекта AWS, а не заявление о том, что BIG CHANGE запускала его или независимо проверила результаты.

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

Что потребуется создать

В архитектуре образца чат-агент Quick подключён к серверу MCP в AWS Lambda. Amazon Cognito выдаёт токен сервиса, который проверяет API Gateway. Lambda читает и записывает данные в Aurora Serverless v2 через Data API службы RDS. Quick Sight обращается к той же базе данных через подключение VPC. AWS использует векторные представления Bedrock и языковую модель только для инструмента исследовательского поиска по условиям; официальная массовая проверка остаётся детерминированной.

В опубликованном примере используются синтетический набор из 50 000 договоров аренды, свод правил с версиями и приёмочный скрипт, который, по словам AWS, выполняет 28 проверок развёрнутого комплекса. В репозитории прямо указано, что код не готов к промышленной эксплуатации, юридические положения вымышлены, а реальные данные арендаторов требуют дополнительной проверки безопасности и независимой юридической оценки. Мы изучили документацию и описание репозитория, но не разворачивали комплекс, не запускали эти проверки и не тестировали маршрутизацию инструментов чат-агента.

Чтобы адаптировать образец, сначала определите авторитетный перечень записей и точное правило включения в него. Затем выясните, какие поля можно надёжно извлекать, какие сравнения по правилам действительно механические и кто утверждает каждую версию правил. Сохраняйте исходный текст, статус извлечения, версию правила, оператора, сравниваемые значения, дату и идентификатор результата, чтобы проверяющий мог восстановить ход проверки. Сверяйте квитанцию с перечнем документов вне ответа чата. Это проектные проверки, вытекающие из заявленных гарантий и ограничений образца, а не проверенные нами шаги.

По словам AWS, токен Cognito с учётными данными клиента идентифицирует приложение Quick, а не человека, задающего вопрос в чате. В образце для установления личности пользователя предлагается сопоставлять идентификатор и время массовой проверки с журналом аудита Quick; если хранилище результатов проверки само должно записывать личность пользователя, AWS рекомендует передавать и сохранять идентификатор конечного пользователя. Команде, которой нужно, чтобы каждое заключение само по себе служило аудиторской записью, следует определить это до развёртывания.

Доступ, ограничения и стоимость

В инструкции AWS предполагаются учётная запись AWS, настроенные учётные данные AWS CLI v2, Python и Node 24 для CDK, доступ к моделям в us-east-1 и среда Amazon Quick с коннектором MCP и Quick Sight. В публикации указана версия Python 3.12, а в связанном README — Python 3.9 или новее. Перед выбором локальной среды проверьте текущие требования репозитория. В инструкциях образца зафиксирован CDK CLI 2.261.0, но это зависимость данного образца, а не общее требование AWS.

Актуальное руководство Quick по MCP устанавливает для каждой операции фиксированный тайм-аут в 60 секунд, разрешает не более 100 инструментов на подключение к серверу и не передаёт пользовательские HTTP-заголовки. Для большой массовой проверки этот тайм-аут нужно проверить на рабочей нагрузке: корректное длительное задание базы данных всё равно нельзя выполнить как синхронную операцию Quick, если оно превышает ограничение коннектора. В руководстве сказано, что список инструментов пользовательского коннектора можно обновить с помощью Sync. В блоге AWS и README образца вместо этого предлагается удалить интеграцию и создать её заново после изменения инструментов. Следуйте текущей документации Quick для действующей версии коннектора и проверьте зарегистрированный список инструментов и маршрутизацию в своей среде.

Это система из нескольких сервисов, поэтому опубликованные материалы не дают обоснованной единой «цены одной проверки». На странице тарифов Quick отдельно указаны стоимость подписки и тарификация по часам работы агента; для некоторых возможностей также взимается плата за Quick Sight. Тарифы Aurora зависят от вычислительной ёмкости, хранилища и конфигурации ввода-вывода; в образце минимальная ёмкость 0,5 ACU остаётся включённой вместо приостановки до нуля. Для оценки рабочей нагрузки также нужны расчёты расходов на API Gateway, Lambda и любые исследовательские вызовы Bedrock. Репозиторий рекомендует удалить комплекс после оценки, чтобы избежать дальнейших расходов. Для этой статьи ресурсы AWS не создавались.

Контрольный список для принятия решения

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

  • Можете ли вы перечислить всю совокупность с помощью проверенного, неизменного условия и сверить её с авторитетным реестром?
  • Являются ли правила механическими сравнениями с утверждёнными версиями, датами вступления в силу и ссылками на источники? Какие случаи должны оставаться неоднозначными для проверки человеком?
  • Можно ли учитывать сбои извлечения и нечитаемые документы, а не молча исключать их?
  • Сохраняются ли для каждого заключения исходное условие, сравниваемые значения и версия правила, и можно ли получить полный набор доказательств вне чата?
  • Успеет ли массовая проверка завершиться в пределах тайм-аута операции Quick и как вы установите личность запросившего результат?
  • Рассчитала ли команда стоимость подписки, базы данных и сервисов для ожидаемого объёма, а затем проверила производительность и качество результата на разрешённых к использованию данных?

Если задача требует юридической интерпретации или суждения о размытом стандарте, детерминированная метка «соответствует/не соответствует» может скрыть именно тот вопрос, который должен решать человек. Если команде нужны репрезентативные примеры, семантический поиск проще. Если утверждённый движок правил и панель уже помогают подотчётным пользователям, диалоговый интерфейс необязателен. Эти альтернативы следуют из обсуждения AWS «неправильного выбора» и ограничений синтетического образца.

Источники и дополнительная литература