«Каждый видит ровно те данные, которые ему разрешены»: Amazon Quick научила AI-приложения читать управляемые датасеты вживую

Что именно добавили

Quick Apps и раньше умели подтягивать живые данные: коннекторы действий вроде Jira, Slack и Google Drive, документы Spaces, веб-поиск и вывод модели работали в момент просмотра, а не в момент сборки. Не хватало одного слоя — структурированных данных. Управляемые датасеты Quick Sight, включая таблицы SPICE и Direct Query, нельзя было запрашивать из приложения вживую: любые числа в приложении оказывались зафиксированы тогда, когда агент его собирал.

AWS описывает это как снимок, замороженный на момент публикации: для статичного отчёта годилось, но ломалось, как только приложение должно было показывать сегодняшнее состояние данных и учитывать, кому какие строки разрешено видеть. Новый режим Live Data in Apps снимает это ограничение — опубликованное Quick-приложение запрашивает управляемые датасеты Quick Sight вживую каждый раз, когда пользователь его открывает.

Как это работает

Логика устроена вокруг двух ролей: builder — тот, чей агент собирает приложение, и users — все, кто потом это приложение открывает; минимальная роль и для того, и для другого — Reader Pro (Professional). Builder описывает приложение обычным языком, агент сам находит подходящие курируемые датасеты, пишет нужный SQL ещё на этапе сборки и просит подтвердить каждый найденный датасет по имени — при двух датасетах согласие запрашивается отдельно на каждый.

После публикации приложение заново выполняет тот же SQL при каждом открытии, поэтому числа всегда актуальны, и — принципиальный момент — запрос выполняется как тот, кто его смотрит. Как следствие, каждый пользователь видит ровно те данные, которые ему разрешены: существующие правила построчной (RLS) и поколоночной (CLS) защиты применяются автоматически, новую модель прав осваивать не нужно, а согласие проверяется на стороне сервера при каждом запросе.

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

Для SPICE-датасетов свежесть данных определяется обновлением самого датасета, для Direct Query обновление не требуется.

Кому это нужно

AWS раскладывает выгоду по трём ролям. Владельцы бизнес-процессов собирают приложения поверх живых датасетов на естественном языке — без ручного обновления данных, управления снимками и кастомных API. Сотрудники-пользователи просто открывают приложение и видят свои числа на текущий момент, уже отфильтрованные по их правам. Администраторы данных и приложений сохраняют прежние правила RLS и CLS и получают ту же модель доступа, что была, — согласие проверяется на сервере при каждом запросе.

Пример из публикации — SaaS-компания AnyCompany, где региональному руководителю продаж нужно сводить данные о продлениях сделок с корпоративным контентом и выстраивать работу с клиентами. Обычно на такой сценарий уходил месяц работы, чтобы собрать правильные данные под каждого клиента; теперь тот же руководитель собирает приложение из датасета, к которому у него уже есть доступ, и делится им с коллегами, не дожидаясь IT.

Иллюстрация работы прав — два региональных менеджера с доступом к разным регионам видят в одном и том же приложении совершенно разные данные: менеджер AMER — только строки AMER, менеджер с доступом и к EMEA, и к AMER — оба набора.

Границы и оговорки

Публикация перечисляет ограничения прямо: действуют предохранители на объём запроса и результата — если данных больше, чем способен передать транспорт, приложение показывает понятное сообщение «сузьте запрос», а не отдаёт обрезанный или неполный набор данных. Датасеты SPICE и Direct Query из одного источника можно использовать в одном приложении, а Direct Query из разных источников — нельзя.

Переименование или удаление колонок требует пересборки запросов в приложении. У builder есть начальное ограничение на число строк при извлечении данных, и агенту нужно отдельно указать, что данные следует подтягивать при загрузке, через несколько постраничных вызовов. Если построчная защита самого builder возвращает пустой набор, приложение на таком датасете собрать не получится — нужно сначала получить доступ к строкам через владельца приложения или службу безопасности. Если агент не нашёл нужный датасет, AWS советует сузить поиск либо передать имя или идентификатор датасета.

Итог, который AWS подчёркивает отдельно: правота данных остаётся в одном месте — механизм запросов Quick Sight проверяет полномочия против личности каждого смотрящего, поэтому само приложение, фронтенд и прокси никогда не принимают решения о доступе.