Просите ИИ сделать риск-аудит проекта.
В ответ получаете аккуратный список:
— учитывайте сроки;
— продумайте ресурсы;
— следите за качеством;
— согласуйте действия;
— заранее планируйте этапы.
Звучит разумно.
Спорить сложно.
Но пользы мало.
Потому что это не риск-аудит.
Это общий набор правильных советов, которые подходят почти к любому проекту.
А риск-аудит нужен не для того, чтобы модель красиво напомнила очевидное.
Он нужен, чтобы понять:
где проект может сломаться;
каких данных не хватает;
какие допущения никто не проверил;
что может потребовать переделки;
какой риск окажется самым дорогим.
Задача не в том, чтобы получить “список возможных проблем”.
Задача — увидеть слабые места до того, как они станут реальной ошибкой.
Почему ИИ пишет красивую воду?
Чаще всего причина в самом запросе:
“Сделай риск-аудит проекта.”
Для модели это слишком общая команда.
Она понимает: нужно написать про риски.
И пишет.
Но без конкретного фокуса она не знает, что именно искать:
риск срыва сроков;
риск нехватки данных;
риск неверного допущения;
риск переделки;
риск зависимости от другого человека;
риск слабой логики проекта;
риск неправильного порядка действий.
Поэтому модель выбирает безопасный путь — общие рекомендации.
Формально ответ по теме.
Практически — с ним сложно что-то сделать.
Риск-аудит — это не “подумай о рисках”
Есть большая разница между обзором рисков и диагностикой.
Обзор говорит:
“Могут быть проблемы со сроками, ресурсами и качеством.”
Диагностика говорит:
“Вот здесь не хватает данных.
Вот это допущение не проверено.
Вот этот этап зависит от решения, которого ещё нет.
Вот тут возможна дорогая переделка.”
Чувствуете разницу?
Первое звучит правильно.
Второе помогает действовать.
Именно это нужно просить у ИИ.
Не просто “найди риски”, а:
покажи, где задача может сломаться и что нужно проверить до запуска.
Пример разницы
Слабый запрос:
“Сделай риск-аудит проекта.”
Модель, скорее всего, напишет что-то общее:
— могут быть проблемы со сроками;
— важно распределить ответственность;
— нужно контролировать качество;
— стоит предусмотреть план Б.
Всё верно.
Но это можно сказать почти о любом проекте.
Сильнее:
“Найди слабые места проекта: где не хватает данных, какие допущения не проверены, что может потребовать переделки, где самый высокий риск и на каком этапе он проявится.
Ответ дай в таблице: риск — причина — стадия проявления — последствия — что проверить до запуска.”
Вот здесь модель получает не просьбу “поговорить про риски”.
Она получает задачу провести диагностику.
Что нужно искать в нормальном риск-аудите?
Хороший риск-аудит должен смотреть не только на очевидные проблемы.
Важно проверить несколько слоёв.
Данные: чего не хватает для уверенного решения.
Например, нет цифр, сроков, вводных, ответственных, подтверждений.
Допущения: что считается очевидным, но на самом деле не проверено.
Например: “команда успеет”, “аудитория поймёт”, “подрядчик сделает”, “сроков достаточно”.
Слабые места: где может сломаться логика проекта.
Например, один этап зависит от другого, но связь не учтена.
Последствия: что будет, если риск сработает.
Иногда риск маленький, но последствия дорогие.
Проверка: что нужно уточнить до запуска.
Именно этот блок превращает аудит из теории в инструмент.
Почему это важно делать до плана?
Есть соблазн сразу просить ИИ:
“Составь план проекта.”
Но если слабые места не найдены, план может выглядеть красиво и всё равно быть хрупким.
Это как построить маршрут и не проверить, что половина дорог перекрыта.
На карте всё прекрасно.
Траектория есть.
Доехать сложно.
Поэтому порядок лучше такой:
сначала диагностика;
потом структура;
потом план.
Если пропустить диагностику, модель может собрать логичный, но наивный план.
А потом в реальности выяснится, что не хватило данных, сроков, людей, подтверждений или просто здравой проверки.
Простая формула для запроса
Чтобы риск-аудит не превратился в воду, задайте модели пять опор:
Данные: чего не хватает.
Допущения: что не проверено.
Слабые места: где может сломаться логика.
Последствия: что будет, если риск сработает.
Проверка: что уточнить до запуска.
Можно прямо так и написать:
“Не давай общий список рисков. Проведи диагностику: найди недостающие данные, непроверенные допущения, слабые места, возможные последствия и вопросы, которые нужно уточнить до запуска.”
Так ИИ начинает работать точнее.
Вывод
Если риск-аудит от ИИ получился красивой водой, проблема не в том, что модель “не умеет”.
Скорее всего, ей дали слишком общую задачу.
Не так:
“Сделай риск-аудит проекта.”
А так:
“Найди слабые места, непроверенные допущения, недостающие данные и риски, которые могут потребовать переделки. Покажи, что нужно проверить до запуска.”
ИИ не должен успокаивать красивой логикой.
Он должен показать, где проект требует проверки.