Шаблоны политик и проверочные списки по кейсам¶

Эта страница превращает кейсы из книги в стартовые заготовки для реальной работы.

Здесь нет идеи "вот универсальная политика на все случаи жизни". Наоборот: смысл в том, чтобы показать, как слой политик начинает отличаться в зависимости от сценария.

Если тебе сначала нужен живой контекст, начни с практических кейсов. Если нужен список следующих улучшений книги, смотри дорожную карту для сообщества.

Как читать эти шаблоны¶

Смотри на них не как на готовый промышленный YAML, а как на каркас:

• что система считает рискованным;
• где проходит граница подтверждения;
• как отделяются читающие и пишущие действия;
• какие условия остановки и правила эскалации нужны;
• какие трассы и сигналы аудита стоит считать обязательными.

Шаблон 1. Агент разбора обращений поддержки¶

Что должна обеспечивать политика¶

Для разбора обращений поддержки тебе обычно нужно:

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

Пример каркаса политики¶

agent:
  name: support_triage
  allowed_models: ["gpt-5.4", "gpt-5-mini"]
  max_steps: 12
  stop_conditions:
    - enough_information_to_answer
    - requires_human_review
    - write_requires_approval

tools:
  read_customer_profile:
    mode: read
    tenant_scoped: true
    approval: none

  read_ticket_history:
    mode: read
    tenant_scoped: true
    approval: none

  create_ticket:
    mode: write
    approval: manager
    idempotency_key_required: true
    retry_on: ["retryable_failure"]

output:
  require_structured_decision: true
  require_escalation_reason: true

Проверочный список¶

• У читающих инструментов есть область арендатора?
• Агент умеет не только отвечать, но и честно эскалировать?
• create_ticket не вызывается без явной политики подтверждения?
• В трассе видно, почему был выбран путь записи?
• Есть ли условие остановки на недостаточную уверенность?

Шаблон 2. Внутренний агент знаний¶

Что должна обеспечивать политика¶

В сценарии агента знаний главный риск не в побочных эффектах, а в доступе и качестве опоры на источники.

Тебе обычно нужно:

• разграничить доступ по роли;
• ограничить поиск только допустимыми источниками;
• не давать агенту смешивать недоверенный контент с инструкциями;
• требовать ссылки на источники в ответе.

Пример каркаса политики¶

agent:
  name: internal_knowledge
  allowed_models: ["gpt-5.4", "gpt-5-mini"]
  max_steps: 8
  stop_conditions:
    - answer_ready
    - insufficient_grounding
    - access_denied

retrieval:
  role_scoped: true
  tenant_scoped: true
  max_documents: 8
  require_source_labels: true

output:
  require_sources: true
  deny_if_no_grounding: true
  deny_sensitive_snippets_without_access: true

Проверочный список¶

• Ролевые ограничения реально работают на пути поиска?
• Агент возвращает источники, а не только красивый текст?
• Есть ли политика на слабую привязку к источникам?
• Нельзя ли через поиск вытащить чужую зону знаний?
• Видно ли в трассах, какие документы были реально использованы?

Шаблон 3. Агент координации инцидентов¶

Что должна обеспечивать политика¶

В сценарии инцидента политика должна управлять не только доступом, но и дисциплиной оркестрации.

Обычно тебе нужно:

• держать единую трассу на весь запуск;
• фиксировать владение на передачах управления;
• ограничивать рискованное исправление;
• не давать шумному входу превращаться в лишние побочные эффекты.

Пример каркаса политики¶

agent:
  name: incident_coordinator
  allowed_models: ["gpt-5.4"]
  max_steps: 20
  orchestration:
    pattern: manager_with_controlled_handoffs
    require_handoff_reason: true
    require_current_owner: true

tools:
  create_incident_thread:
    mode: write
    approval: oncall_lead
    idempotency_key_required: true

  notify_team:
    mode: write
    approval: oncall_lead
    idempotency_key_required: true

  suggest_remediation:
    mode: advisory
    approval: none

  execute_remediation:
    mode: write
    approval: security_and_service_owner
    disabled_by_default: true

audit:
  require_trace_per_run: true
  require_handoff_log: true
  require_write_intent_log: true

Проверочный список¶

• У каждой передачи есть владелец и причина?
• Рискованное исправление выключено по умолчанию?
• Создание тикетов и уведомления защищены идемпотентностью?
• В трассе инцидента виден полный путь принятия решений?
• Шумное оповещение не может само по себе вызвать опасный путь записи?

Универсальный проверочный список для слоя политик¶

Независимо от кейса, полезно пройти по этим вопросам:

• Понимаешь ли ты, где в системе read, write и advisory действия?
• Есть ли у рискованных действий отдельная граница подтверждения?
• Видно ли в политике, где агент должен остановиться, а не продолжать рассуждение?
• Не живут ли ключевые правила только внутри инструкции?
• Может ли команда безопасности прочитать артефакты политики без знания всех деталей проектирования инструкций?

Если ответ "нет" на несколько пунктов подряд, значит слой политик у тебя еще слишком неявный.

Что делать дальше¶

• Практические кейсы
• Глава 3. Контур безопасности и границы доверия
• Глава 17. Слой политик и каталог возможностей