---
title: "Ограничители для решений на моделях"
url: "https://kzsaleshub.com/framework/guardrails-fw/"
type: "framework"
category: "AI и данные"
language: "ru"
source: "KZSalesHub"
published: "2026-08-11"
last_updated: "2026-09-03"
---

# Ограничители для решений на моделях

**Суть.** Надёжность решения на модели создаётся не уговорами в промпте, а кодом вокруг неё: что можно на входе, что проверяется на выходе, какие действия требуют подтверждения и что записывается. Модель нельзя «попросить быть надёжной» — её поведение вероятностно по устройству.

## Четыре слоя

| Слой | Что проверяет | Пример |
| --- | --- | --- |
| Вход | Что попадает в запрос | Удаление персональных данных, ограничение длины, отсечение недопустимых тем |
| Выход | Формат и содержание ответа | Обязательные поля, ссылка на источник, отсутствие выдуманных реквизитов |
| Действия | Что модели разрешено делать | Черновик — можно, отправка клиенту — с подтверждением |
| Журнал | Что произошло и почему | Запрос, контекст, ответ, вызванные инструменты |

## Главное правило

Действия делятся на обратимые и необратимые. Обратимые — черновик, внутренняя пометка, предложение. Необратимые — отправка, изменение суммы, удаление. Самостоятельность расширяется только на обратимых; необратимые остаются с подтверждением человека дольше, чем кажется необходимым.

## Когда применять

Как только система на основе языковой модели становится доступна кому-то кроме команды разработки. Ограничители — это не защита от злоумышленника в первую очередь, а защита от обычного пользователя, который задаст вопрос за пределами замысла, и от самой модели, которая ответит уверенно и неверно.

## Четыре уровня

| Уровень | Что делает | Пример |
| --- | --- | --- |
| На входе | Отсекает запросы вне области применения | Вопрос про политику в системе подбора оборудования |
| В подсказке | Задаёт правила: отвечать только по найденному, признавать незнание | Требование указывать источник |
| На выходе | Проверяет ответ до показа пользователю | Есть ли ссылка на документ, нет ли персональных данных |
| На действии | Ограничивает то, что система может сделать | Запрет на отправку письма без подтверждения человеком |

Четвёртый уровень появляется вместе с агентами и оказывается самым важным: ошибка в тексте раздражает, ошибка в действии стоит денег.

## Правила проектирования

1. Список запрещённого бесконечен, список разрешённого конечен — описывать нужно второе.
2. Каждый ограничитель должен иметь проверочный случай в наборе оценки, иначе о его поломке никто не узнает.
3. Отказ должен быть полезным: не «не могу ответить», а «этого нет в базе, обратитесь туда-то».
4. Действия делятся на обратимые и необратимые; вторые всегда требуют подтверждения человеком.
5. Все срабатывания журналируются — это единственный способ понять, где ограничитель мешает работе.

## Где ломается

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

**Проверяют вход, не проверяют выход.** Именно на выходе появляются выдуманные цифры и ссылки.

**Ограничители мешают работать.** Слишком строгие правила приводят к тому, что помощником перестают пользоваться; баланс подбирается на реальных случаях.

- **Слишком строгие правила.** Система, которая отказывается отвечать на половину нормальных вопросов, перестаёт использоваться — и это провал, а не безопасность.
- **Ограничители только в подсказке.** Инструкции в тексте обходятся; критичные ограничения должны быть в коде.
- **Нет пересмотра.** Журнал отказов раз в месяц показывает, какие правила стали мешать; без пересмотра они накапливаются.
- **Проверка на выходе стоит дороже ответа.** Иногда это оправдано, иногда означает неверную архитектуру.

## Частые вопросы

**Не убьют ли ограничители пользу от системы**

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

**Нужны ли они во внутренней системе**

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

**Как понять, что ограничители работают**

По журналу: доля отказов, их причины и доля жалоб на ложные отказы. Если жалоб нет совсем — правила, скорее всего, слишком мягкие.

## Связанное

- [AI Agent Lifecycle](https://kzsaleshub.com/framework/ai-agent-lifecycle/)
- [Оценка качества ответов](https://kzsaleshub.com/framework/llm-evaluation/)
- [AI Governance Lifecycle](https://kzsaleshub.com/framework/ai-governance-lifecycle/)

Промпт — это просьба, ограничитель — правило. Надёжность появляется только там, где есть второе.

---
Источник: https://kzsaleshub.com/framework/guardrails-fw/