# Как на практике управлять рисками стороннего ИИ

> Управление рисками стороннего ИИ требует живого реестра, уровней риска, обязательных условий договора и контроля реальных изменений поставщика.

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

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

Мне встречались реестры поставщиков, где были только название компании, дата продления и зеленая ячейка статуса. Во время инцидента это почти бесполезно. Если поставщик раскрыл промпты или без предупреждения направил данные новому провайдеру модели, нужны конкретные ответы: какой процесс использовал сервис, какие данные пересекли границу, кто полагался на результат, что можно отключить и кто отвечает за реакцию? Стройте систему вокруг этих вопросов.

## Учитывайте сценарий использования, а не название поставщика

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

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

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

```json
{
  "use_id": "support-reply-draft",
  "vendor": "Example Vendor",
  "business_owner": "VP Support",
  "technical_owner": "Support Engineering",
  "purpose": "Draft replies for agent review",
  "data_classes": ["customer_ticket", "account_metadata"],
  "affected_people": ["customers", "support_agents"],
  "model_providers": ["declared_subprocessor"],
  "output_action": "human_approved_message",
  "kill_switch": "disable integration token",
  "tier": 2,
  "last_reviewed": "YYYY-MM-DD",
  "next_review": "YYYY-MM-DD"
}
```

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

Для теневого использования нужен безопасный канал раскрытия. Если сотрудники ждут наказания за объявление об инструменте ИИ, они скроют его до тех пор, пока закупки не найдут платеж, а служба безопасности не заметит трафик. Предложите короткую форму и временный ограниченный статус: только открытые или синтетические данные, никаких автоматических решений и внешней передачи до завершения проверки. Амнистия обнаруживает больше риска, чем строгая политика, которой никто не следует.

## Опишите поток данных и право принимать решения

Реестр приносит пользу, только когда показывает, что входит в систему, что выходит и как бизнес использует результат. Тип модели менее важен, чем последствия ошибочного, раскрытого или намеренно искаженного ответа. Большая языковая модель, которая предлагает теги для внутренних документов, может иметь низкое влияние. Та же базовая модель, рекомендуя клиентов для расследования, способна затронуть права, выручку и репутацию.

Нарисуйте одну простую схему для каждого существенного сценария: источник, поставщик, модель или субпроцессор, хранилище результата, проверяющий человек и итоговое действие. Отметьте, где сохраняются промпты, загруженные файлы, эмбеддинги, журналы и созданный контент. Включите кнопки обратной связи и обращения в поддержку, потому что поставщики нередко собирают их вне основного контура обработки. Если поставщик не может объяснить поток, надежно согласовать использование нельзя.

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

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

Полезная схема потока заканчивается обратимым бизнес-действием. Если результат напрямую меняет доступ, цену, трудоустройство, кредит, безопасность или юридический статус, считайте его значимым, даже когда финальную кнопку формально нажимает человек. Если сотрудник может проверить результат, сопоставить его с первичными данными и отменить действие без существенного ущерба, остаточный риск может быть ниже. Зафиксируйте это различие в реестре, а не держите в чьей-то памяти.

## Сначала определите уровень по возможному ущербу

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

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

1. Уровень 1 охватывает открытые или синтетические данные и результаты, которые не определяют существенное решение. Владелец может пройти короткую самопроверку и принять стандартные условия.
2. Уровень 2 охватывает внутренние данные или данные клиентов при содержательной проверке перед использованием. Специалисты по безопасности и приватности проверяют поток, хранение, условия обучения и контроль доступа.
3. Уровень 3 охватывает чувствительные данные, внешнюю генерацию, профилирование и результаты, которые существенно влияют на людей. Юристы, безопасность, приватность и ответственный руководитель должны согласовать сценарий вместе с тестированием и планом выхода.
4. Уровень 4 охватывает использование, способное причинить серьезный ущерб безопасности, правам, правовому положению или финансам, а также сценарии, за которыми компания не может следить. По умолчанию внедрение запрещено, пока руководитель, отвечающий за риск, не согласует документированное исключение.

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

Остаточный риск оценивают после проверки мер контроля. Шифрование может снизить риск раскрытия. Обученный проверяющий, который видит источники и выборочно проверяет ответы, может уменьшить вероятность ошибки. Обязанность поставщика сообщить об инциденте по договору может ускорить реакцию. Ни одна из этих мер не работает только потому, что в анкете стоит «да». В зависимости от уровня запросите настройки, результаты тестов, примеры журналов или живую демонстрацию.

Заранее определите, кто принимает риск на каждом уровне, до того как популярный продукт создаст давление. Менеджер продукта может согласовать уровень 1. За уровень 3 должна отвечать межфункциональная группа. Для уровня 4 нужен конкретный руководитель, который понимает возможный ущерб и подписывает ограниченное по времени исключение. Без этих границ владельцем риска случайно становится самый настойчивый покупатель.

## Сделайте прием заявки достаточно коротким

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

Направляйте заявки в одну видимую очередь и задайте срок обслуживания для каждого уровня. Быстрая обработка работает как мера контроля, потому что команды обходят непредсказуемый процесс. Уровень 1 может получить подтверждение в тот же день. Для уровня 3 могут потребоваться тесты, согласование условий и решение руководства. Опубликуйте эти ожидания, чтобы покупатель не обещал дату запуска до начала проверки.

Назначайте двух владельцев. Бизнес-владелец отвечает за цель, затронутых людей и допустимый сбой. Технический владелец отвечает за интеграции, учетные данные, журналы, настройки и отключение. Закупки могут координировать сбор доказательств и подписей, но не должны наследовать операционный риск. Служба безопасности не может решить, допустима ли предвзятая рекомендация в чужом бизнес-процессе.

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

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

## Закрепите операционные обязанности в договоре

Условия договора по ИИ должны превращать согласованный сценарий и меры контроля в обязательства поставщика. Типовое дополнение об обработке данных может охватывать персональные данные, но ничего не говорить об обучении модели, правах на результаты, доказательствах испытаний, тихой смене модели или праве покупателя отключить встроенную функцию.

Опишите услугу до переговоров о риске. Назовите функции ИИ, разрешенные цели, категории данных, территории при необходимости, группы пользователей и запрещенные способы применения. Если закон о приватности требует такого разграничения, укажите для каждого потока, выступает ли поставщик обработчиком, независимым контролером или в другой роли. Юрист должен адаптировать текст к применимому праву. Скопированное условие не исправит несовпадение с реальной схемой работы.

Договор должен охватывать как минимум такие обязанности:

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

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

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

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

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

## Проверяйте меры контроля в своих настройках

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

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

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

Измеряйте контроль, который важен для бизнес-действия. Считайте неподтвержденные утверждения, пропущенные проверяющими, вредные рекомендации, дошедшие до пользователя, запрещенные данные, принятые интерфейсом, и автоматические действия без согласования. Общая «точность» может скрыть тип отказа с наибольшей ценой. Для редких тяжелых последствий используйте сценарные тесты и готовность к инциденту, а не делайте вид, что малая выборка дает надежный процент.

Проверьте аварийное отключение до запуска. Владелец должен знать, как отозвать токен, выключить функцию, убрать право записи или перевести работу на ручной процесс. Убедитесь, что отключение не уничтожает доказательства для расследования. Если для выключателя нужен отсутствующий администратор поставщика или новые переговоры по договору, это не операционная мера контроля.

## Следите за изменениями, а не за годовщиной анкеты

Постоянный мониторинг должен искать события, меняющие риск, а не повторять закупочную проверку по календарю. NIST AI RMF 1.0 прямо говорит об этом в Manage 3.1: организациям следует регулярно отслеживать риски и пользу сторонних ресурсов, применять меры контроля и документировать их. Я согласен с идеей непрерывности, но слово «регулярно» требует событийных триггеров, иначе все сводится к ежегодному письму.

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

Задайте пороги до того, как график сдвинется. Резкий рост использования, новый источник чувствительных данных, снижение доли отмен проверяющими, необъяснимое изменение результатов или новый идентификатор модели могут запустить проверку. Ответом может стать расследование, ужесточение ограничений, откат или приостановка. Без порогов и владельцев панель показывает только то, что кто-то собирал данные.

Глубина мониторинга следует за уровнем. Для уровня 1 может хватить подтверждения владельца при продлении и автоматического поиска новых интеграций. Уровню 2 нужны периодические проверки конфигурации и разбор инцидентов. Уровню 3 нужны показатели качества и вреда, уведомления об изменениях, выборочная проверка и плановое межфункциональное обсуждение. Для уровня 4 требуется активный надзор, испытанный запасной процесс и решение руководителя с ограниченным сроком.

Не требуйте телеметрию, которую система не умеет отдавать. Зафиксируйте слепую зону и компенсируйте ее выборочной проверкой, сужением сценария, более сильным контролем человеком или снижением потолка согласования. Если вы не можете обнаружить сбой, способный причинить серьезный ущерб, сценарий может превышать ваши возможности по безопасной эксплуатации. Текст договора не создаст наблюдаемость после внедрения.

## Считайте изменения поставщика новыми решениями о риске

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

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

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

Уведомление по договору помогает этому процессу, но не заменяет самостоятельное обнаружение. В примечаниях к выпуску может не быть изменения настройки по умолчанию, а бизнес-администратор способен включить функцию без закупок. Сверяйте данные об учетных записях, интеграциях и конфигурации с реестром. Дайте администраторам простое правило: для включения генерации, оценки, профилирования или автоматического действия нужен согласованный идентификатор сценария.

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

## Подготовьте сдерживание сбоя до продления

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

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

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

Отрепетируйте отказ поставщика и событие с вредным результатом. Первый сценарий проверяет доступность и ручной запасной процесс. Второй проверяет, может ли команда остановить работу, найти затронутые решения, исправить их и связаться с людьми, которым причинен вред. Учение, которое заканчивается фразой «связаться с поставщиком», упускает большую часть ответственности покупателя.

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

## Дайте одному владельцу полную операционную картину

Управление сторонним ИИ работает, когда один ответственный руководитель видит реестр, исключения, просроченные доказательства, инциденты и будущие продления. Комитет может консультировать, но не способен владеть задачей без назначенного человека. В стартапе им может стать технический директор, руководитель безопасности или специалист по приватности. Роль важнее должности.

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

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

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

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

Основателям часто кажется, что труднее всего написать политику. На деле нужно распределить ответственность между инженерами, юристами, безопасностью и закупками, не построив медленную бюрократию. Team & AI Audit от oleg.is может показать этот операционный разрыв и определить, где ИИ меняет стоимость команды и требования к контролю. Система должна работать после ухода консультанта, поэтому требуйте записи, владельцев и повторяемые решения.

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