ИИ как помощник комиссии: от облачного агента к офлайн-расследованию происшествий

Как мы прошли путь от первых облачных экспериментов к рабочему контуру «маскировщик → ИИ-агент → демаскировка», а затем создали тестовую офлайн-систему расследования и готовимся к следующему шагу — защищённому корпоративному ИИ-контуру Fire.

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

С чего всё начиналось

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

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

Я специально подчёркиваю: это не было медицинским заключением и не должно им быть. Окончательная оценка медицинского снимка — задача врача. Но для нас тот эпизод стал важным техническим сигналом: модель способна замечать детали на изображении, которые неспециалист может пропустить. Значит, в расследовании она потенциально может работать не только с текстом, но и со схемами, фотографиями и другими материалами.

Первый рабочий вариант: облачный агент

Когда появились более устойчивые пользовательские агенты, мы начали настраивать их непосредственно под нашу корпоративную методику. Делали варианты в GPT, Gemini и Perplexity; на раннем этапе пробовали и Grok. В агент загружалась методика, далее — объяснительные, первоначальное описание, отдельные документы и другие материалы.

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

Но у первого варианта был очевидный дефект: мы фактически отдавали внешнему сервису реальные материалы расследования. Для происшествий это особенно чувствительно: в материалах могут быть ФИО, должности, медицинские сведения, объяснительные, фотографии и внутренняя информация предприятия.

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

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

Методика стала строже — и это изменило требования к ИИ

Параллельно развивалась сама корпоративная методика внутреннего расследования. Для меня это важный момент: ИИ нельзя давать право «самому придумать, как расследовать». Сначала должна быть методика, и уже под неё строится цифровой инструмент.

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

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

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

Именно эта последовательность позже стала каркасом нашего локального приложения.

См. Prompt 2–6: хронология и критические факторы → вопросы и противоречия → барьеры → дерево причин → мероприятия.

Второй вариант: маскируем вручную

Следующий этап был гораздо безопаснее, хотя и довольно неудобен. Перед загрузкой материалов в облачного агента мы вручную заменяли фамилии и другие чувствительные значения: «Работник 1», «Работник 2», «Руководитель 1», «Подразделение 1» и так далее.

С точки зрения конфиденциальности это уже был шаг вперёд. Агент видел логику происшествия, но не видел реальных ФИО. После завершения анализа приходилось вручную возвращать обозначения обратно — часто через поиск Ctrl+F.

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

Третий вариант: локальный маскировщик и отдельная проблема аудио

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

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

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

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

Связка этого этапа: локальная транскрибация → локальный маскировщик → облачный агент. Для анализа материалов см. Prompt 1–6.

Четвёртый вариант: офлайн-система уже создана — теперь мы её тестируем

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

Задача была такой: сделать единое рабочее место комиссии, куда можно загрузить методическое пособие, первоначальную информацию, объяснительные, Word и PDF, аудиозаписи, фотографии и схемы; локально расшифровать речь и документы; пройти по этапам методики и получить редактируемый первый проект Word-отчёта.

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

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

См. Prompt 8 — мастер-промпт для вайб-кодинга локального рабочего места комиссии.

Что уже умеет тестовая офлайн-версия

В тестовой офлайн-версии весь цикл уже собран вокруг методики, а не вокруг обычного чата с ИИ.

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

В раздел материалов можно загрузить DOCX и текстовые PDF. Сканы и фотографии можно распознать локально; схемы и изображения сохраняются в деле, а модель может предложить описание видимых деталей. Аудио и видео расшифровываются локально. Можно также записать опрос непосредственно с микрофона и затем получить транскрипт.

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

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

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

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

См. Prompt 2 — хронология; Prompt 3 — противоречия и недостающие данные; Prompt 4 — барьеры; Prompt 5 — дерево причин; Prompt 6 — мероприятия; Prompt 7 — проект итогового отчёта.

Что делает локальный ИИ — и чего он делать не должен

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

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

Поэтому в приложении заложен принцип: ИИ предлагает — комиссия принимает, отклоняет или редактирует. Причина не становится подтверждённой автоматически. Ответственные и сроки не назначаются моделью. Проект Word — это именно первый рабочий драфт, а не документ «бери и подписывай».

Это особенно важно потому, что внутренний отчёт не заменяет документы, предусмотренные законодательством и установленными процедурами. Ответственность за расследование остаётся у комиссии.

См. Prompt 9 — контроль качества, конфиденциальности и границ автоматизации перед использованием результата.

Конфиденциальность стала частью архитектуры, а не отдельной инструкцией

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

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

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

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

Что используем сегодня

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

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

Рабочий контур: маскировщик → настроенный ИИ-агент расследования → демаскировка.

Тестовый контур: полностью локальное рабочее место комиссии → проверка и дальнейшие итерации.

Следующий шаг — защищённый корпоративный Fire

Параллельно IT-служба Группы развивает в корпоративной среде Collab внутренний ИИ Fire. Для нас это логичный следующий этап: перенести методическую логику помощника комиссии в защищённый серверный корпоративный контур, где не нужно выбирать между мощностью крупной модели и требованиями к конфиденциальности.

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

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

Смотри видео: полный цикл работы локального расследования

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

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

Где здесь экономия времени

Расследование происшествия всё равно требует людей: осмотреть место, опросить участников, получить документы, обсудить факты, принять решения. Автоматизировать смысл комиссии нельзя.

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

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

Что получилось на выходе

За несколько лет путь получился показательный: открытый облачный агент → ручная маскировка → локальный маскировщик и демаскировка → локальная транскрибация → тестовая офлайн-система → следующий шаг в защищённый корпоративный Fire.

При этом рабочий инструмент сегодняшнего дня — не экспериментальная офлайн-версия, а проверенный контур с маскировкой: исходные материалы остаются у нас, в агент уходит обезличенная версия, а восстановление выполняется локально. Офлайн-систему мы сейчас тестируем и последовательно доводим.

Самое важное изменение — даже не техническое. Мы перестали задавать ИИ вопрос «кто виноват?» и стали задавать другой: «каких данных не хватает, какие барьеры не сработали, почему они не сработали и какие меры действительно снизят риск повторения?»

Именно в этой роли ИИ полезен в расследовании: не судья и не председатель комиссии, а быстрый второй аналитик, который помогает людям глубже работать с фактами.

И ещё одно: про естественный интеллект забывать нельзя

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

Поэтому для меня правильный путь — быть не просто пользователями готовых кнопок, а создателями новых решений: понимать методику, задавать архитектуру, проверять результат, исправлять ошибки и самим становиться сильнее вместе с инструментом.

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

Промпты к статье

Рабочий контур с маскировкой → тестовая офлайн-система → следующий шаг в защищённый корпоративный Fire

Текущий статус: в реальной работе используется контур «локальный маскировщик → настроенный облачный агент → локальная демаскировка». Полностью офлайн-система уже разработана, но находится на этапе испытаний и улучшений. Fire рассматривается как следующий защищённый корпоративный этап.

Prompt 1. Текущий рабочий агент: только обезличенные материалы

Связь со статьёй: разделы «Третий вариант» и «Что используем сегодня». Это действующий рабочий контур после локальной маскировки.

Ты — аналитический помощник комиссии по внутреннему расследованию происшествия в области ОТ и ПБ.

КОНТУР РАБОТЫ:
Исходные документы сначала локально маскируются. Ты получаешь только обезличенные копии. После твоей работы результат локально демаскируется с помощью отдельного ключа и пароля, которых у тебя нет.

ВАЖНО:
- работай только с заранее обезличенными материалами;
- не пытайся восстановить ФИО, подразделения, адреса или другие скрытые значения;
- не используй интернет и внешние факты, если они отдельно не предоставлены;
- не определяй виновных;
- не называй гипотезу установленным фактом;
- не заменяй решение комиссии.

Цель: помочь комиссии структурировать материалы и проверить полноту расследования.

Для каждого вывода разделяй:
FACT — прямо подтверждено материалом;
ASSUMPTION — обоснованное предположение;
CONFLICT — противоречие между материалами;
GAP — недостающая информация;
QUESTION — вопрос, который необходимо закрыть;
HYPOTHESIS — возможная причина, требующая подтверждения.

Порядок:
1. Составь реестр полученных материалов.
2. Извлеки только подтверждаемые факты с указанием источника.
3. Составь предварительную хронологию.
4. Покажи противоречия и пробелы.
5. Сформируй дополнительные вопросы комиссии.
6. После подтверждения хронологии предложи анализ барьеров.
7. Причины формируй только как гипотезы до решения комиссии.
8. Мероприятия связывай только с подтверждёнными причинами.

Во всех таблицах указывай источник: номер материала, документ/файл и короткую цитату или точное место, на котором основан вывод.

Prompt 2. Хронология событий и критические факторы

Связь со статьёй: раздел о хронологии в рабочем агенте и тестовой офлайн-системе.

Я передаю проверенные тексты материалов происшествия.

Сформируй ПРОЕКТ шкалы хронологии.

Правила:
1. Не добавляй событий, которых нет в материалах.
2. Если время точное — укажи его как точное.
3. Если время приблизительное — пометь «ориентировочно».
4. Если два источника дают разное время или последовательность — не выбирай один вариант молча; покажи CONFLICT.
5. Для каждой строки укажи: дату/время; событие или условие; источник; статус FACT / ASSUMPTION / CONFLICT; почему это важно.
6. Отдельно предложи перечень критических факторов: событий/условий, без которых нежелательное событие или тяжесть последствий, вероятно, были бы иными.
7. Критические факторы не считать утверждёнными до решения комиссии.

В конце выдай:
A. проект хронологии;
B. список противоречий;
C. список недостающих данных;
D. проект критических факторов для обсуждения комиссией.

Prompt 3. Противоречия, пробелы и план дополнительных опросов

Связь со статьёй: разделы о планировании, сборе материалов и роли ИИ как второго аналитика.

На основании материалов и проекта хронологии подготовь рабочий лист комиссии.

Нужно:
1. Найти противоречия между объяснительными, документами, временем и техническими данными.
2. Не трактовать различие формулировок как ложь без доказательств.
3. Для каждого противоречия указать: источник A; источник B; в чём именно различие; что необходимо проверить.
4. Сформировать вопросы для дополнительного опроса.
5. Вопросы должны быть открытыми и нейтральными, без подсказывания ответа.
6. Отдельно сформировать перечень документов, измерений, экспертиз, фото или схем, которые могут закрыть пробел.
7. Отметить, какие вопросы являются критичными для установления обстоятельств, защитных барьеров, причин и тяжести последствий.

Не делай вывод о недостоверности показаний только по наличию противоречия.

Prompt 4. Барьерная логика и «галстук-бабочка»

Связь со статьёй: раздел о барьерной логике и переходе к причинам.

Используй подтверждённую комиссией хронологию и критические факторы.

Сформируй ПРОЕКТ барьерного анализа.

1. Источник(и) опасности.
2. Нежелательное событие.
3. Последствия.
4. Превентивные барьеры: какой барьер должен был предотвратить событие/контакт; существовал ли он; был ли доступен; применялся ли; сработал ли; источник подтверждения.
5. Реагирующие барьеры: какой барьер должен был предотвратить последствия или снизить тяжесть; существовал ли он; сработал ли; источник подтверждения.
6. Для каждого отсутствующего или неэффективного барьера сформулируй вопрос «Почему?».

Не называй отсутствие барьера коренной причиной автоматически.
Не придумывай барьеры, которых нет в методике, документах или технологической логике без пометки HYPOTHESIS.

Вывод — таблица для обсуждения комиссией, а не утверждённое заключение.

Prompt 5. Дерево причин и коренные причины

Связь со статьёй: раздел «Методика стала строже» и блок причин.

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

Построй ПРОЕКТ дерева причин.

Отправная точка: «Нежелательное событие + последствия».
Первые две ветви:
A. Почему произошло нежелательное событие?
B. Почему наступили такие последствия / почему их тяжесть была такой?

Дальше:
1. Для каждого узла задавай «Почему?» столько раз, сколько необходимо для выхода на системную причину.
2. Каждую причину свяжи с родительским вопросом.
3. Каждый критический фактор должен найти отражение в дереве либо быть отдельно объяснён как исключённый.
4. Действие/ошибка человека не принимать за коренную причину. Продолжать анализ: почему действие было возможным или считалось допустимым.
5. Коренную причину предлагать только если она описывает конкретный недостаток процесса/системы; поддаётся устранению; находится в зоне управляемости предприятия/Группы; позволяет предложить конкретную меру.
6. Запрещены общие формулировки без расшифровки: «низкая культура», «личная неосторожность», «плохая организация», «недостатки обучения».

Для каждого узла:
- формулировка;
- тип: непосредственная / промежуточная / кандидат в коренную;
- подтверждающие источники;
- связанные критические факторы;
- статус FACT / HYPOTHESIS / CONFIRMED_BY_COMMISSION.

Не подтверждай коренную причину вместо комиссии.

Prompt 6. Корректирующие и предупреждающие мероприятия

Связь со статьёй: раздел о мероприятиях и экономии времени на подготовке первого драфта.

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

Для каждой причины предложи 2–4 варианта мероприятий.

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

Не заполняй ФИО ответственного и конкретный срок без решения комиссии.
Не предлагай мероприятие вида «провести внеплановый инструктаж» как универсальное решение, если оно не устраняет установленную причину.
Отдельно отметь мероприятия, которые только усиливают контроль, но не устраняют коренную причину.

Prompt 7. Проект итогового отчёта по методике

Связь со статьёй: раздел о формировании Word и принципе «первый драфт, а не документ на подпись».

Подготовь ПРОЕКТ текста внутреннего отчёта на основании только утверждённых комиссией элементов.

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

Не включай в итог как факт неподтверждённые гипотезы, спорные версии без пометки и выводы без источника.

Структура:
1. Краткая информация и обстоятельства.
2. Материалы и методы сбора информации.
3. Хронология.
4. Критические факторы.
5. Защитные барьеры.
6. Анализ причин.
7. Коренные причины.
8. Корректирующие и предупреждающие мероприятия.
9. Приложения / реестр материалов.

Где возможно, рядом с существенным выводом сохраняй ссылку на материал-основание.
В верхней части документа пометь: «ПРОЕКТ. Требует проверки и согласования комиссией».
Не формулируй заключение о виновности.

Prompt 8. Мастер-промпт для тестовой офлайн-системы

Связь со статьёй: раздел «Офлайн-система уже создана — теперь мы её тестируем».

Я не программист. Помоги создать ТЕСТОВОЕ локальное приложение для внутреннего расследования происшествий по корпоративной методике. Цель этапа — пилот и проверка качества, а не автоматический ввод в промышленную эксплуатацию.

Работай пошагово. На каждом шаге:
1. объясни, что делаем и зачем;
2. дай одно действие или один готовый файл/патч;
3. дождись моего результата или скриншота;
4. проверь его;
5. только после этого переходи дальше.

ЦЕЛЕВАЯ АРХИТЕКТУРА
- Windows 10/11;
- локальный backend на 127.0.0.1 и браузерный интерфейс;
- после однократной подготовки моделей работа с материалами дела без внешнего интернета;
- предусмотреть работу на производительном рабочем компьютере; для слабой машины предложить облегчённую модель, но не скрывать снижение качества/скорости;
- локальное хранение дел;
- архив дела с контрольными суммами;
- история версий;
- никакой обязательной отправки материалов во внешние API.

МАТЕРИАЛЫ
- DOCX: абзацы, таблицы, колонтитулы;
- PDF с текстом;
- PDF-сканы / изображения — локальное распознавание;
- схемы / фотографии — хранить оригинал и предлагать описание только как черновик;
- аудио / видео — локальная транскрибация;
- запись с микрофона;
- ручной ввод и редактирование;
- обязательная отметка «сверено с оригиналом» до использования текста в ИИ-анализе.

ЛОКАЛЬНЫЕ МОДЕЛИ
- LLM через локальный движок (например Ollama);
- многоязычная модель речи Whisper;
- при необходимости локальная vision-модель;
- приложение не должно скрыто скачивать модели во время расследования.

МЕТОДИКА / ЭТАПЫ
1. Первичная информация.
2. План комиссии.
3. Сбор материалов.
4. Хронология и критические факторы.
5. Барьеры и причины.
6. Мероприятия.
7. Отчёт.

ПРАВИЛА ИИ
- ИИ только предлагает.
- Каждый вывод хранит источник и цитату.
- Различать FACT / ASSUMPTION / CONFLICT / GAP / HYPOTHESIS.
- Причины — гипотезы до подтверждения комиссии.
- Ответственные и сроки модель не назначает сама.
- Комиссия должна иметь возможность принять, отклонить или отредактировать каждое предложение.
- Финальный Word — редактируемый проект.
- В отчёт включать дерево причин, барьеры, реестр и приложения.

БЕЗОПАСНОСТЬ
- без CDN и внешней телеметрии;
- сетевые обращения расследования только loopback;
- показывать пользователю, что локальная работа не равна автоматическому обезличиванию;
- не хранить секреты в открытом клиентском коде;
- предусмотреть удаление дела, резервную копию и перенос.

Начни с архитектуры каталогов, формата данных дела и модели угроз. Код не пиши до моего подтверждения.

ПИЛОТНЫЙ СТАТУС
- явно маркируй версию как «ТЕСТОВАЯ / ПИЛОТ»;
- добавь набор контрольных учебных кейсов;
- для каждого кейса сравни результат ИИ с выводами человека/комиссии;
- веди журнал найденных дефектов и итераций;
- не называй систему готовой к промышленной эксплуатации до завершения испытаний.

Prompt 9. Аудит пилотной офлайн-системы

Связь со статьёй: разделы о границах автоматизации, конфиденциальности и текущем тестовом статусе.

Проведи аудит готового приложения и проекта расследования перед передачей комиссии.

ПРОВЕРЬ ТЕХНИЧЕСКИ
1. Есть ли внешние сетевые обращения во время работы с делом.
2. Используются ли CDN, внешние шрифты, облачный speech-to-text, внешние API.
3. Где хранятся исходники, расшифровки, локальные модели и резервные копии.
4. Что происходит при удалении дела.
5. Не попадают ли исходные документы в журналы диагностики.
6. Не выгружается ли содержимое дела при ошибке.

ПРОВЕРЬ МЕТОДИЧЕСКИ
7. Все ли существенные выводы имеют источник.
8. Отделены ли факты от гипотез.
9. Все ли критические факторы отражены в анализе причин.
10. Не названы ли действия человека коренной причиной без анализа системных условий.
11. Связаны ли мероприятия с конкретными причинами/барьерами.
12. Не назначены ли моделью ответственные и сроки без решения комиссии.
13. Не заявляется ли проект отчёта как утверждённый документ.

ПРОВЕРЬ КОНФИДЕНЦИАЛЬНОСТЬ
14. Какие персональные/медицинские данные находятся в локальном деле.
15. Требуется ли дополнительная маскировка для демонстрации, публикации или передачи.
16. Не содержат ли имена файлов и скриншоты лишние ФИО.

Итог выдай таблицей:
Проверка | Статус | Найденный риск | Что исправить | Кто должен подтвердить.

Не исправляй содержательные выводы расследования автоматически.

ПРОВЕРЬ СТАТУС ЗРЕЛОСТИ
17. Есть ли набор контрольных кейсов и результаты сравнения.
18. Какие функции уже стабильны, а какие остаются экспериментальными.
19. Какие ошибки/ограничения должны быть устранены до промышленного использования.
20. Не создаёт ли интерфейс ложного впечатления, что вывод ИИ является решением комиссии.

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

• Prompt 1 — рабочий сегодня контур: только заранее обезличенные материалы; ключ демаскировки агенту не передаётся.
• Prompt 2–7 — методические рабочие блоки, которые можно использовать и в текущем агенте, и в локальном/серверном будущем контуре.
• Prompt 8 — создание и дальнейшая доработка тестовой полностью офлайн-системы.
• Prompt 9 — аудит пилота перед расширением применения.

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