Как проверять AI-черновик в аналитической работе

Когда нужен этот чеклист

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

Этот чеклист нужен перед тем, как переносить AI-вывод в задачу, материал, решение, API-контракт или план разработки.

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

AI помогает сформулировать гипотезу. Ответственность за проверку остается у человека и команды.

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

Рабочий результат проверки: не “AI написал лучше”, а понятный список:

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

Промпт для проверки черновика

Этот промпт помогает использовать AI как ревьюера собственного черновика, а не как источник истины. Вставляйте только обезличенный контекст: без персональных данных, секретов, внутренних ссылок, реальных идентификаторов и закрытых коммерческих деталей.

Помоги проверить черновик аналитического вывода.

Контекст:
[кратко опиши задачу, систему или интеграцию без секретов и персональных данных]

Черновик:
[вставь текст, который нужно проверить]

Проверь результат по следующим правилам:
1. Раздели утверждения на факты, гипотезы и решения.
2. Для каждого важного факта укажи, какой первичный источник нужен для проверки.
3. Найди места, где вывод звучит уверенно, но не подтвержден контекстом.
4. Отдельно отметь риски для данных, безопасности, API-контракта, ошибок и эксплуатации.
5. Перепиши спорные формулировки в проверяемые утверждения.
6. Составь список вопросов, которые нужно задать человеку, команде или владельцу системы.

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

После такого прогона полезен не “красивый финальный текст”, а список мест, где AI-черновик нужно сверить с документацией, тестовым контуром, кодом, владельцем процесса или командным решением.

Короткий процесс проверки

Если времени мало, достаточно 15-20 минут и пяти шагов.

1. Уберите из черновика все, что нельзя показывать AI-инструменту: персональные данные, внутренние ссылки, реальные идентификаторы, секреты, приватные логи и коммерческие детали.
2. Разбейте ответ на отдельные утверждения. Одно предложение: один факт, гипотеза, рекомендация или вопрос.
3. Для каждого утверждения поставьте статус: можно использовать, нужно проверить, нельзя использовать без решения.
4. Для всего, что нужно проверить, укажите источник: документация, API-контракт, тестовый контур, код, владелец процесса, инженерное ревью или decision record.
5. Перенесите в рабочий артефакт только проверенные выводы. Гипотезы оставьте как вопросы или задачи проверки.

Такой процесс защищает от главной ошибки: принять аккуратную формулировку за готовый анализ.

1. Проверить входной контекст

Перед запросом к AI нужно решить, какие данные вообще можно использовать.

Нельзя отправлять без отдельного разрешения:

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

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

2. Разделить тип результата

AI-ответы бывают разными по уровню риска.

Низкий риск:

• структура заметки;
• список вопросов;
• варианты формулировок;
• черновик плана встречи;
• упрощенное объяснение для обсуждения.

Средний риск:

• классификация требований;
• список возможных ошибок;
• предложение критериев приемки;
• черновой API-чеклист;
• гипотезы о причинах сбоя.

Высокий риск:

• трактовка регламентов;
• правила безопасности;
• требования к сертификатам, подписям и токенам;
• конкретные форматы сообщений;
• выводы о совместимости;
• production-рекомендации.

Чем выше риск, тем жестче проверка.

3. Проверить источники

Для каждого важного вывода нужно понимать, откуда он взят:

• официальная документация;
• контракт API;
• результат тестового запроса;
• код или конфигурация системы;
• решение команды;
• экспертное подтверждение;
• предположение AI.

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

Удобно фиксировать проверку в маленькой таблице:

4. Превратить ответ в проверяемые утверждения

AI часто пишет уверенно и обобщенно. Для работы команды это нужно переводить в проверяемый формат.

Вместо:

• “сервис должен поддерживать повторные запросы”;
• “ошибки нужно логировать”;
• “данные должны быть безопасными”.

Лучше:

• “повторный запрос с тем же идентификатором не создает дубль операции”;
• “в лог пишется код ошибки и correlation id, но не пишутся персональные данные”;
• “секреты хранятся вне репозитория, а публичные примеры обезличены”.

Проверяемое утверждение можно положить в задачу, критерий приемки или decision record.

5. Отделить черновик от решения

В рабочих заметках полезно явно маркировать статус:

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

Так команда не перепутает хорошую формулировку с подтвержденным фактом.

6. Проверить последствия

Перед использованием AI-вывода спросите:

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

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

Пример разбора AI-черновика

Допустим, AI после чтения обезличенного описания интеграции написал:

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

Такой ответ звучит уверенно, но в нем сразу несколько непроверенных решений.

Разбор:

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

Проверяемая версия:

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

Из такого разбора появляются рабочие действия:

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

Тревожные признаки

Ответ нельзя переносить в работу без дополнительной проверки, если:

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

Как использовать

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

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