- 1Подготовьте сведения о фактических задачах, данных и действиях систем. Для первой встречи не обязательно заранее создавать большой комплект новых документов.
- 2Первичная оценка показывает риски и пробелы по согласованному объёму. Она не является гарантией полного соответствия и не заменяет специальные испытания.
- 3Полезный результат связывает риск с процессом, подтверждениями, ответственным и следующим действием. Приоритет выбирают по последствиям и возможности вмешаться.
Правовые выводы проверены и актуализированы 3 октября 2026 года. Примеры условные; рекомендации по организации работы отделены от обязательных требований.
Определите вопрос, на который должна ответить диагностика
Сформулируйте повод для проверки: подключение нового сервиса, уже работающие инструменты сотрудников, подготовка к сделке или жалоба клиента. От него зависит выбор процессов и глубина исследования. Общее желание «проверить весь ИИ» лучше перевести в несколько конкретных вопросов.
Уточните, какое решение компания планирует принять после встречи. Продолжать ли использование? Какие функции временно ограничить? Какие документы заказать? Это помогает отличить первичное исследование от полного аудита, технического тестирования или разработки правил.
Если проблема срочная, опишите факты и уже принятые меры. Не ждите завершения плановой диагностики, чтобы сообщить о продолжающемся инциденте ответственным внутри компании. Порядок необходимых действий определяется отдельно по обстоятельствам.
Соберите список инструментов и рабочих сценариев
Для каждого инструмента укажите подразделение, задачу, пользователя и способ подключения. Добавьте встроенные помощники, плагины, API и личные аккаунты, которые используются для работы. Формальный перечень закупленных лицензий может не отражать большую часть фактического применения.
Полезнее записать «помощник составляет ответ клиенту по истории обращения», чем «используем языковую модель». Первое описание показывает данные, адресата и возможные последствия. Если точная техническая версия неизвестна, отметьте пробел и назначьте того, кто сможет его уточнить.
Выберите несколько реальных маршрутов для обсуждения. Не нужно выгружать всю переписку и клиентские документы в общий файл подготовки. Сначала описывают процесс; состав и безопасный способ предоставления дополнительных материалов согласуют отдельно.
Покажите путь данных и действий
Опишите, откуда поступает информация, что передаётся модели, где сохраняется результат и кто его использует. Включите историю разговора, вложения, журналы и доступ внешних исполнителей. Если сведений о компоненте нет, это самостоятельный вопрос для проверки.
Для персональных данных важно установить цель и необходимый объём обработки по статье 5 Закона № 152-ФЗ, а не просто отметить их наличие. Поэтому в карте нужны категории сведений и назначение операции. Передавать консультанту реальные данные без необходимости не следует.
Отдельно укажите полномочия системы: создаёт ли она черновик, меняет ли запись, отправляет ли сообщение или инициирует операцию. Риск зависит от того, что происходит после генерации. Одна и та же модель в разных процессах может требовать разных ограничений.
Подготовьте договоры, условия и настройки
Соберите относящиеся к выбранному сервису договор, тариф, условия использования и сведения о настройках. Укажите редакцию и продукт: веб-чат и API одного поставщика могут иметь разные условия. Если решения о подключении принимались в переписке, найдите их и ответственных участников.
Для первичного анализа могут быть полезны правила сотрудников, документы по данным, техническое задание и описание приёмки. Предоставляйте имеющиеся материалы. Создавать формальную политику накануне встречи только ради заполнения списка не нужно: это скроет исходное состояние.
Пометьте, что является действующим документом, проектом или информацией поставщика, ещё не подтверждённой договором. Запись на рекламной странице и согласованное обязательство не равнозначны. Проверяющему важно видеть происхождение вывода, а не только итоговую таблицу.
Пригласите людей, которые знают процесс
Одного сотрудника юридического отдела иногда недостаточно, чтобы понять отправку данных или действие модели. Для выбранного сценария найдите владельца бизнеса, специалиста IT и представителя информационной безопасности. HR подключают, если речь о работниках или правилах их работы.
Необязательно проводить большую встречу со всеми участниками. Можно собрать ответы заранее и назначить короткие уточнения. Важно, чтобы вопросы не оставались без владельца: кто знает настройки, кто управляет поставщиком и кто способен изменить рабочий маршрут.
Попросите показать процесс на допустимом тестовом примере. Демонстрация часто выявляет расхождения с документами: автоматическую отправку вложений, общий аккаунт или сохранение полной истории. Такие факты полезнее предположений о том, как продукт должен работать.
Согласуйте состав результата и его ограничения
Для первичной диагностики можно согласовать реестр инструментов, схему данных, начальную матрицу рисков, перечень необходимых документов и план действий. Это предлагаемый состав, который уточняется под задачу. Он не является универсальной обязательной формой проверки.
В матрице разделите подтверждённую проблему, условный риск и вопрос с недостаточными сведениями. Например, отсутствие информации о месте обработки — пробел, а не доказательство конкретного нарушения. Укажите, какое подтверждение позволит принять решение.
Отдельно договоритесь, выполняются ли испытания качества и оценка управления. ГОСТ Р 72664-2026 касается модели качества ИИ, а ГОСТ Р ИСО/МЭК 42001-2024 — системы менеджмента. Короткая первичная встреча не подтверждает соответствие всем требованиям этих стандартов.
Переведите выводы в последовательность действий
Приоритет связывают с последствиями, вероятностью и доступными мерами. Некоторые вопросы требуют ограничения функции; другие — получения документа или дополнительного исследования. Не стоит обозначать все найденные пробелы одинаково критичными: такой список затрудняет решение.
Для следующего шага укажите владельца, ожидаемый результат и подтверждение выполнения. Формулировку «исправить договор» замените конкретным условием, которое требуется согласовать. После изменения настройки проверьте рабочий маршрут, а не только наличие отметки в плане.
Хорошая подготовка позволяет закончить диагностику понятным решением: что компания уже знает об использовании ИИ, что остаётся проверить и какие меры нужны первыми. Дальнейший объём работ и сроки согласуют по этим фактам, без заранее обещанного результата для любого проекта.