[ Replied to message id: 703 ]
Анонимизация данных продолжение: неочевидные грабли
Допустим, фильтр из прошлого поста поймал все персональные данные до единой. Даже тогда анонимизация способна всё сломать — и вот почему.
Вчера обсуждали с коллегами по ИИ анонимизацию и всплыла еще одна архитектурная тонкость. Надёжной анонимизации мало просто найти данные. Нужно ещё, чтобы:
1. Один и тот же субъект прослеживался через всю переписку.
2. Продолжение диалога использовало ту же нумерацию, что и прошлые сообщения.
3. Атрибуты субъекта были связаны именно с ним.
🤔 Что имеется в виду
Достим у нас есть договор:
Исполнитель: Поляков А. Е.
Заказчик: Иванов И. И.
Реквизиты:
Поляков Александр Евгеньевич — ИНН/КПП 7701.../7701...
Иванов Иван Иванович — ИНН/КПП 7702.../7702...
Наивная разметка выглядит так:
Исполнитель: [PERSON]
Заказчик: [PERSON]
Реквизиты:
[PERSON] — ИНН/КПП [ACCOUNT]/[ACCOUNT]
[PERSON] — ИНН/КПП [ACCOUNT]/[ACCOUNT]
И тут вопрос: где чей ИНН? На входе модель видит четыре одинаковых [PERSON] и четыре [ACCOUNT] — гарантии, что она не перепутает реквизиты, нет никакой.
Значит, разметка обязана передавать связи:
Исполнитель: , заказчик
Реквизиты:
Исполнитель:
Заказчик:
Реквизиты:
— ИНН/КПП /
— ИНН/КПП /
Теперь id=1 и id=3 — это один и тот же subj=1, а его ИНН намертво привязан к владельцу.
🚀 Как это собирать
Я бы выделил такие принципы к организации:
1. Кроме модели-разметчика нужен бекенд, который держит соответствие значений и их ID стабильным на всю сессию . Иначе в каждом новом сообщении Иванов станет «новым» человеком и нить потеряется. Сам этот справочник — тоже хранилище ПДн, его придётся защищать.
2. Связи субъект-атрибут модель-разметчик не выдаёт: она метит спаны, но не говорит, чей ИНН. Это отдельный слой — разрешение связей плюс привязка по структуре документа. Как будто под такую задачу нужно тренировать отдельную LLM — иначе всё будет очень медленно работать (задержка до секунды на обработку запроса еще допустима, дольше — перебор)
3. Контекст анонимайзера должен быть не меньше отправляемого текста. Не влезло — режем на куски, а на стыках рушится ровно то, ради чего всё затевалось: один человек в двух чанках рискует получить разные ID.
🤷♂️ Кажется проще вложиться в локальный инференс
Заметили закономерность? Каждый слой ради надёжности — это ещё немного локальной обвязки: кореференция, структурный парсинг, стабильные ID, большой контекст, живой справочник. Разработка и поддержка такой системы стоит дорого.
🎯 Отсюда вывод: собрать сложный обратимый анонимайзер часто дороже, чем поставить в офисе сервер под открытые китайские модели и гонять секретные задачи локально.
А для облачных запросов можно оставить логику проще — модель, которая только проверяет, не уходят ли за периметр персональные или иные чувствительные данные, блокирует отправку и предлагает нарушителю короткое обучение. Детектировать и остановить — задача куда легче, чем найти, обратимо заменить, связать и вернуть обратно.
Кто нибудь уже строил такое? Какой стек использовали?
----
Поляков считает — AI, код и кейсы
Анонимизация данных продолжение: неочевидные грабли
Допустим, фильтр из прошлого поста поймал все персональные данные до единой. Даже тогда анонимизация способна всё сломать — и вот почему.
Вчера обсуждали с коллегами по ИИ анонимизацию и всплыла еще одна архитектурная тонкость. Надёжной анонимизации мало просто найти данные. Нужно ещё, чтобы:
1. Один и тот же субъект прослеживался через всю переписку.
2. Продолжение диалога использовало ту же нумерацию, что и прошлые сообщения.
3. Атрибуты субъекта были связаны именно с ним.
🤔 Что имеется в виду
Достим у нас есть договор:
Исполнитель: Поляков А. Е.
Заказчик: Иванов И. И.
Реквизиты:
Поляков Александр Евгеньевич — ИНН/КПП 7701.../7701...
Иванов Иван Иванович — ИНН/КПП 7702.../7702...
Наивная разметка выглядит так:
Исполнитель: [PERSON]
Заказчик: [PERSON]
Реквизиты:
[PERSON] — ИНН/КПП [ACCOUNT]/[ACCOUNT]
[PERSON] — ИНН/КПП [ACCOUNT]/[ACCOUNT]
И тут вопрос: где чей ИНН? На входе модель видит четыре одинаковых [PERSON] и четыре [ACCOUNT] — гарантии, что она не перепутает реквизиты, нет никакой.
Значит, разметка обязана передавать связи:
Исполнитель: , заказчик
Реквизиты:
Исполнитель:
Заказчик:
Реквизиты:
— ИНН/КПП /
— ИНН/КПП /
Теперь id=1 и id=3 — это один и тот же subj=1, а его ИНН намертво привязан к владельцу.
🚀 Как это собирать
Я бы выделил такие принципы к организации:
1. Кроме модели-разметчика нужен бекенд, который держит соответствие значений и их ID стабильным на всю сессию . Иначе в каждом новом сообщении Иванов станет «новым» человеком и нить потеряется. Сам этот справочник — тоже хранилище ПДн, его придётся защищать.
2. Связи субъект-атрибут модель-разметчик не выдаёт: она метит спаны, но не говорит, чей ИНН. Это отдельный слой — разрешение связей плюс привязка по структуре документа. Как будто под такую задачу нужно тренировать отдельную LLM — иначе всё будет очень медленно работать (задержка до секунды на обработку запроса еще допустима, дольше — перебор)
3. Контекст анонимайзера должен быть не меньше отправляемого текста. Не влезло — режем на куски, а на стыках рушится ровно то, ради чего всё затевалось: один человек в двух чанках рискует получить разные ID.
🤷♂️ Кажется проще вложиться в локальный инференс
Заметили закономерность? Каждый слой ради надёжности — это ещё немного локальной обвязки: кореференция, структурный парсинг, стабильные ID, большой контекст, живой справочник. Разработка и поддержка такой системы стоит дорого.
🎯 Отсюда вывод: собрать сложный обратимый анонимайзер часто дороже, чем поставить в офисе сервер под открытые китайские модели и гонять секретные задачи локально.
А для облачных запросов можно оставить логику проще — модель, которая только проверяет, не уходят ли за периметр персональные или иные чувствительные данные, блокирует отправку и предлагает нарушителю короткое обучение. Детектировать и остановить — задача куда легче, чем найти, обратимо заменить, связать и вернуть обратно.
Кто нибудь уже строил такое? Какой стек использовали?
----
Поляков считает — AI, код и кейсы