Какие данные передавать LLM: проектируем минимальный контекст

Ассистент должен объяснить клиенту статус доставки. Разработчик передаёт модели всю карточку заказа, потому что так проще: адрес, телефон, внутренние комментарии, стоимость закупки и историю платежей. Для ответа нужны номер, этап и ожидаемая дата. Отдельное представление данных для AI-вызова помогает заранее ограничить, что покидает бизнес-систему.

Определите данные, необходимые для ответа

Для каждого поля исходной карточки задайте вопрос: какое решение модели меняется от его наличия? Статус и дата доставки влияют на ответ. Внутренняя маржа не нужна. Телефон может понадобиться оператору для звонка, но для текстовой справки о статусе его можно исключить. Разные задачи получают разные представления одной сущности.

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

Используйте явную проекцию полей

Соберите новый объект из разрешённых полей вместо удаления нескольких известных опасных. Когда API добавит поле internal_notes, оно не попадёт в контекст автоматически. Для вложенных объектов тоже задайте допустимые поля: копирование всего customer вернёт адреса и контакты через другую ветку.

Псевдоним заказа можно связать с настоящим ID на стороне приложения. Если модель должна только написать текст, ей достаточно понятной метки. Если дальше нужен инструмент, сохраните серверную связь метки с объектом и всё равно проверяйте полномочия при вызове. Псевдонимизация не заменяет управление доступом.

Проверьте состав фактического запроса

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

def delivery_context(order):
    return {"order_label": order["public_number"], "status": order["status"],
            "delivery_date": order.get("delivery_date")}
order = {"public_number": "A-17", "status": "in_transit", "delivery_date": "2026-10-30",
         "customer": {"phone": "synthetic-phone"}, "internal_margin": 31,
         "internal_notes": "synthetic confidential note"}
context = delivery_context(order)
assert set(context) == {"order_label", "status", "delivery_date"}
assert "customer" not in context and "internal_notes" not in context
print(context)

Разберите исключения отдельно

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

Редактирование текста полезно для свободных комментариев, но не заменяет выбор полей. Регулярное выражение может убрать телефон и пропустить другие сведения о человеке. Для задачи, которой комментарий не нужен, надёжнее вообще не добавлять его в запрос. Для нужного комментария потребуется отдельная проверка и обработка.

После изменения исходного API прогоняйте фикстуру с дополнительными полями и вложенными объектами. После изменения диалоговой логики смотрите, не сохраняется ли полный результат инструмента в истории. Правильно собранный текущий запрос может повторно отправить чувствительные сведения из предыдущего хода.

Зафиксируйте версии представлений: delivery_status_v1, return_review_v1. Это позволит объяснить, какой состав данных использовала конкретная операция. В отчёте безопасности появится проверяемое свойство: для справки о доставке передаются только согласованные поля, а расширение состава проходит отдельное изменение и приёмку.

Продолжить проект на практике

Проекция полей — один из слоёв защиты контекста. В платном курсе LLM Security PRO вы разберёте предотвращение утечек через redaction и ограничение полномочий инструментов. Затем соберёте red-team набор и автоматические проверки: изменение приложения можно будет оценивать на заранее подготовленных сценариях раскрытия данных.

Откройте программу курса и выберите следующий этап своего проекта.

По теме: Prompt injection: как проверить защиту AI-агента.