name: ai-data-perimeter description: "Use when обезличивание, утечка в модель, 152-ФЗ, периметр." version: 1.0.0 author: AI_Lab_SCRUM Co license: MIT platforms: [linux, macos, windows] metadata: hermes: tags: [security, anonymization, 152-fz, privacy, ai-governance] category: engineering

related_skills: [docx, om-documentation-review, grounded-citations]

Периметр данных при работе с ИИ

When to Use

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

Исходная логика, на которой держится всё остальное: суду неважен канал (флешка, почта, чат-бот) — важен факт пересечения периметра; пересекло — отвечает компания. Поэтому вопрос не «какая модель безопаснее», а «какие данные в неё кладут».

Правило 0 — «у нас соблюдается» проверяется по файлам, не по памяти

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

Слой	Что читать	Признак, что меры нет
Организационный	приказ, регламент, лист ознакомления, журнал применения	всё лежит незаполненными шаблонами, ни одной записи
Технический	`profiles/<profile>/SOUL.md`, `skills/`, `hooks/`, `config.yaml`	правила в SOUL нет; нужный скилл не установлен; `hooks/` пуст

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

Проверять установленность, а не наличие в сборке: ls profiles/<p>/skills/ против dist/<сборка>/skills/. Скилл, лежащий только в сборке, в работе не участвует.

Обратное направление проверять так же: скилл, лежащий только в профиле (у разработчика), до получателей не доедет, и ссылка на него из SOUL.md сборки окажется битой. Правило, которое цитируется в SOUL.md, должно физически лежать в сборке — иначе порядок работы такой: сначала скилл в сборку, потом правило в SOUL.

Правило 1 — декларация в промпте ≠ контроль

Правило, записанное в SKILL.md или SOUL.md, срабатывает по триггеру в description и зависит от того, вспомнит ли модель применить его в нужный момент. Принуждение — это перехват исходящего запроса. Пока его нет, честная формулировка: «правило записано и инструментовано, механизма принуждения нет». Не называть это «соблюдается».

Перехват в Hermes делается плагином, а не каталогом hooks/. Пустой hooks/ (это наблюдатели) не доказывает, что принуждения не бывает — проверять надо зарегистрированные middleware: ctx.register_middleware("llm_request", fn) в плагине (hermes_cli/plugins.py), применяется к kwargs провайдера в agent/turn_api_request.py через apply_llm_request_middleware (hermes_cli/middleware.py). Точки: tool_request (до чтения файла), llm_request (до отправки), llm_execution (обёртка вызова, обратная подстановка). Устройство и порядок внедрения — references/hermes-intercept.md.

Правило 2 — агент сам является каналом утечки

Любое чтение файла инструментом (read_file, DOCX/PDF-парсер, OCR, vision_analyze) отправляет его в модель целиком, до всякой проверки. Порядок работы с документом заказчика:

Решить, откуда берётся обезличенная копия: её даёт пользователь или агент делает копию и читает только её.
Читать/разбирать только копию. Оригинал не открывать «чтобы посмотреть объект».
Таблицу соответствия токенов и реальных значений не читать никогда — она и есть закрываемые данные.

Один канон процедуры, а не три редакции

Одна и та же процедура расползается по трём местам: файл anonymization.md в каталоге references/ скилла docx вместе со скриптом scan_open_pii.py, отдельный скилл ailab/anonymization-check и этот скилл. Три редакции одного правила разъезжаются и начинают противоречить друг другу.

Держать иерархию:

Место	Роль
этот скилл (`ai-data-perimeter`)	канон: правила периметра, аудит «соблюдается ли», порядок чтения документа, чек-лист и нормы в `references/`
файл `anonymization.md` в `references/` скилла `docx` + `scan_open_pii.py`	исполнение под каноном: техника правки DOCX-пакета и проверка полноты
отдельный скилл-обёртка того же правила	либо тонкая ссылка на канон, либо убрать

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

Проверка полноты обезличивания

Скилл docx несёт процедуру (файл anonymization.md в его каталоге references/) и скрипт:

python skills/productivity/docx/scripts/scan_open_pii.py "<файл.docx>" --summary
# --header — готовая строка для шапки отчёта, --json — машинный вывод

Агент читает --summary (счётчики), человек — полный отчёт. Полный прогон печатает сами находки: наименование организации, фамилию подписанта, телефон, индекс — то есть ровно то, что прячут. Их попадание в контекст агента отправляет эти данные в модель и подрывает правило изнутри.
Признавать оба способа маркировки: [АДРЕС-003] и «________». Чекер, знающий один, на файле, размеченном другим способом, объявит «маркеров нет» и остановится.
Ноль находок = «шаблоны не сработали», не «документ чист». Заказчик, названный описательно, ни под один шаблон не попадает. Так и формулировать.
Сканируется весь пакет: тело, ячейки таблиц, все headerN/footerN.xml, docProps/core.xml, app.xml, картинки отдельно.
Разделять находки, которые обязан оценить человек: ресурсоснабжающие организации и сетевые операторы стоят в любом городском ТЗ и объект не идентифицируют; заказчик, управляющая организация, адрес, кадастровый номер — идентифицируют.

Питфоллы

grep -i не сворачивает регистр кириллицы в Windows-шелле: поиск «ооо» не найдёт «ООО», счётчик молча выйдет нулевым. Сворачивать регистр в Python (text.lower()), шаблоны писать под нужный регистр явно.
Содержимое ТЗ и договоров лежит в ячейках таблиц, а не в абзацах: проверка только по абзацам даёт пустой результат, который читается как «всё чисто».
Метаданные DOCX — главный пропускаемый канал: dc:creator и cp:lastModifiedBy часто содержат почту и полное имя автора, <Manager> в app.xml — ещё одну почту. В теле документа их не видно.
Колонтитулы — отдельная часть на каждую секцию: правка document.xml оставляет название компании на всех страницах.
Скриншоты: реквизиты и заголовки остаются по углам и в EXIF.
«Локальная модель = безопасно» неверно: без отключённого внешнего доступа и без HTTPS при раздаче по сети данные всё равно уходят или ходят открытым текстом.
Вторичный источник не равен факту: собранные в папку методички, карточки и посты канала — чужие материалы, они не доказывают, что процесс есть у нас. Цифры (штрафы, проценты утечек) перепроверять по действующей редакции нормы; нормы в методичке обычно отсутствуют вовсе.

Как оформляется результат

Сначала вывод, потом обоснование. Таблица вместо абзаца, строка вместо таблицы.
Организационные меры «под подпись» не предлагать. В этой компании директор и владелец такие бумаги не подписывают, поэтому регламент, приказ и лист ознакомления как основной механизм нереалистичны. Опора — на технический контроль (перехват, маска, журнал) и пилот на одной задаче; бумаги возвращать в план только если владелец сам о них попросит.
Слайд про собственный продукт — со статусом и остаточными рисками. В надзаголовке «релиз N, в разработке», внизу честная строка о том, чего механизм не делает. Слайд без этого обещает больше, чем есть, и разваливается на первом вопросе «а оно точно не уйдёт?».
В выжимке по папке: инвентарь (что за файлы и чьи они) → ядро правил → рабочие инструменты → нормы → статус «что проверено / что нет».
Раздел статуса — отдельной таблицей «что проверял → факт», без «проверено» без доказательства.
Полезный артефакт помимо текста: каркас презентации по разделам выжимки. Колоду по этим материалам собирать средствами скилла powerpoint (в нём тёмная брендовая тема и каркас сборки — файл templates/brand_deck_build.py внутри скилла powerpoint) — не рисовать слайды с нуля и не тащить светлую тему.

Справочник

references/perimeter-rules.md — светофор данных, четыре контура, чек-лист обезличивания, ответственность и сроки инцидентов, штрафы, минимальный пакет документов, дорожная карта внедрения.
templates/soul-perimeter-block.md — готовый блок «Периметр данных» для вставки в SOUL.md: то, что действует до первого чтения файла, со ссылкой на этот скилл как канон. Вставлять и в сборку, и в рабочий профиль.
references/hermes-intercept.md — как сделать принуждение на исходящем запросе: три точки middleware, policy.yaml с ролями по типам документов, режим «маска + журнал», порядок внедрения и остаточные риски.