Анонимизация договоров и медкарт перед LLM без потери смысла

Где возникает риск

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

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

Особенно вредят пустые пропуски. Когда в документе остаются сплошные "[УДАЛЕНО]" или длинные пустые куски, модель теряет связи между сущностями. Она уже не понимает, где одна сторона договора, а где другая, какой эпизод лечения относится к какому обследованию и что произошло раньше. Лучше заменять данные не пустотой, а понятными метками: "Пациент_1", "Организация_2", "Дата_3". Так структура текста сохраняется.

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

Глубина маскирования зависит от задачи. Если модель делает краткое резюме для внутреннего юриста, можно сохранить роли сторон, относительные даты и диапазоны сумм. Если задача - клиническая классификация или поиск кодов МКБ, обычно оставляют возраст, пол, жалобы, результаты анализов и ход лечения, но убирают прямые идентификаторы и слишком точные привязки ко времени и месту.

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

Какие поля искать в договорах

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

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

Сначала ищут прямые идентификаторы сторон:

• ФИО физлиц и подписантов
• ИИН, БИН и другие регистрационные номера
• юридические и фактические адреса
• телефоны, email, имена контактных лиц
• банковские реквизиты: IBAN, БИК, номера счетов, наименование банка

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

Если договор отправляют в LLM для проверки рисков или извлечения условий, такие поля лучше заменять нейтральными метками. Например: "Договор № [DOC_ID]", "Доверенность № [POA_ID]", "Покупатель [COMPANY_1]". Так модель сохраняет структуру текста и не теряет логику документа.

Где данные часто прячутся

Больше всего пропусков бывает в блоке подписи. Там стоят полные ФИО, должность, основание полномочий, телефон, email и иногда даже образец подписи. На печати могут быть БИН, полное название компании и адрес.

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

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

Какие поля искать в медкартах

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

Сначала убирают прямые идентификаторы:

• ФИО пациента и родственников
• ИИН
• адрес проживания или регистрации
• телефон, e-mail, контакты доверенных лиц
• номер полиса или данные страховки

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

С датами нужна аккуратность. Для LLM часто важна не сама календарная точка, а порядок событий и интервалы. Поэтому вместо "12.03.2025" и "19.03.2025" лучше оставить "день 1" и "день 8" или "через 7 дней после госпитализации". Тогда модель понимает ход лечения, но не получает лишнюю привязку к конкретному человеку.

Отдельная проблема - квази-идентификаторы. По одному полю они не раскрывают личность, но в связке делают пациента узнаваемым. Возраст 47 лет, редкий диагноз, беременность 31 неделя, перевод из конкретного отделения и необычная реакция на препарат - уже вполне узнаваемый набор.

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

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

Что оставить, чтобы смысл не потерялся

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

Имена и названия лучше заменять ролями. В договоре вместо "ТОО Альфа" и "Иванов И.И." оставьте "[заказчик_1]", "[поставщик_1]", "[представитель_заказчика]". В медкарте вместо ФИО пациента и врачей подойдут метки вроде "[пациент_1]", "[врач_кардиолог_1]", "[отделение_неврологии]". Так логика документа сохраняется.

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

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

Некоторые данные почти всегда нужно оставлять как есть:

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

Даже мелкая правка таких фрагментов меняет смысл. Если заменить "5 мг" на "[дозировка]", модель не поймет риск передозировки. Если скрыть "п. 4.3" и "п. 7.2", она не свяжет обязанность, срок и ответственность.

Хорошее правило такое: скрывайте личность, но не скрывайте логику. В договоре должно остаться понятно, кто кому что должен и в какой срок. В медкарте - кто лечил пациента, на каком этапе, по каким данным и с каким результатом. Тогда LLM анализирует текст, а не гадает, что вы вырезали.

Как настроить анонимизацию по шагам

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

Рабочая схема обычно выглядит так:

1. Сначала зафиксируйте задачу. Если модель ищет просрочку оплаты, ей нужны суммы, сроки, роли сторон и порядок событий. Если модель делает сводку по выписке, ей нужны диагноз, жалобы, назначения и последовательность дат.
2. Соберите два списка полей: прямые и косвенные идентификаторы. К первым относятся ФИО, ИИН, номер телефона, адрес, номер полиса, номер договора. Ко вторым - редкая должность, название филиала, точная дата госпитализации, номер палаты, необычная комбинация диагноза и возраста.
3. Заменяйте данные по шаблону, а не пустыми кусками. Лучше писать [КЛИЕНТ_1], [ВРАЧ_1], [ДОГОВОР_7], [ДАТА_1], [ОРГАНИЗАЦИЯ_2]. Если одна и та же сущность встречается пять раз, метка должна оставаться одной и той же.
4. Проверьте правила на небольшой выборке. Возьмите 10-20 документов разного типа: короткий договор, договор с приложением, выписку, консультацию, лабораторный результат. После замены задайте модели обычный рабочий запрос и сравните ответ с оригиналом.
5. Покажите результат человеку из предметной области. Юрист быстро увидит, что после замены стало непонятно, кто платит штраф и в какой срок. Врач заметит, что обезличивание стерло различие между текущим диагнозом и анамнезом.

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

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

Пример с договором поставки

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

Названия компаний лучше заменить ролями: "Поставщик" и "Покупатель". Так текст остается читаемым, а логика обязательств не ломается. Если в документе участвуют несколько юрлиц, одной роли мало. Тогда пишут "Поставщик_1", "Поставщик_2", "Покупатель". Иначе модель перепутает, кто отгружает товар, а кто платит.

Исходная фраза может выглядеть так: "ТОО 'Альфа Снаб' обязуется поставить товар АО 'ГородСтрой' в течение 15 календарных дней с даты заявки". После замены лучше оставить ее так: "Поставщик обязуется поставить товар Покупателю в течение 15 календарных дней с даты заявки". Смысл тот же, а лишних реквизитов уже нет.

При этом не трогайте цифры, которые влияют на вывод. Если в договоре указано "оплата в течение 7 банковских дней", не заменяйте это на "в течение недели". Если штраф составляет "0,1% за каждый день просрочки, но не более 10% от суммы просроченного платежа", сохраните формулировку без округления. Для юриста разница между 7 и 10 днями или между 0,1% и 1% меняет весь результат.

Отдельно проверьте ссылки внутри договора. После замены названий текст иногда становится короче, и редактор ломает нумерацию или переносы. Модель должна ясно понимать, что пункт 4.2 ссылается на пункт 7.3, а приложение №2 связано именно со спецификацией, а не с графиком поставки.

Перед отправкой такого договора полезно быстро проверить четыре вещи:

• роли сторон различаются и не смешиваются
• суммы, сроки оплаты, неустойка и лимиты сохранены точно
• пункты, подпункты и приложения читаются без двусмысленности
• реквизиты, адреса, счета и ФИО скрыты, если они не нужны для задачи

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

Пример с выпиской из медкарты

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

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

Пациент: Иванов Петр Сергеевич, 14.03.1986
ИИН: 860314300123
Номер медкарты: 4519-22
Телефон: +7 701 123 45 67
Жалобы: температура до 38.4, сухой кашель 3 дня, слабость.
02.05.2026 осмотр терапевта. Аллергии нет.
ОАК: лейкоциты 12.4 x10^9/л, CRP 28 мг/л.
Диагноз: внебольничная пневмония справа.
Назначено: амоксициллин 500 мг 3 раза в день 7 дней, парацетамол 500 мг при температуре выше 38.

После анонимизации текст может выглядеть так:

Пациент: [ФИО скрыто], дата рождения: [скрыто]
ИИН: [скрыто]
Номер медкарты: [скрыто]
Телефон: [скрыто]
Жалобы: температура до 38.4, сухой кашель 3 дня, слабость.
02.05.2026 осмотр терапевта. Аллергии нет.
ОАК: лейкоциты 12.4 x10^9/л, CRP 28 мг/л.
Диагноз: внебольничная пневмония справа.
Назначено: амоксициллин 500 мг 3 раза в день 7 дней, парацетамол 500 мг при температуре выше 38.

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

Частая ошибка - удалить все числа подряд. Тогда пропадают дозы, длительность курса и лабораторные значения. Другая ошибка - вычищать короткие фразы вроде "аллергии нет", "беременность отрицает", "антибиотики не принимал". Они кажутся второстепенными, но именно они меняют трактовку случая.

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

Ошибки, которые ломают смысл

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

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

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

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

Числа тоже лучше трогать очень осторожно. Если сумма, срок, дозировка, температура, уровень глюкозы или размер образования влияют на вывод, нельзя заменять их случайными значениями. Порог в 10 дней, 3 миллиона тенге или 38,5 градуса может изменить весь ответ модели.

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

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

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

Для LLM лучше не стирать документ, а заменять чувствительные поля на устойчивые и разные метки: [пациент_1], [врач_кардиолог], [дата_1], [сумма_1]. Так приватность сохраняется, а смысл не разваливается.

Быстрая проверка перед отправкой в LLM

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

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

Удобный чек-лист такой:

• роли не должны "плавать" по тексту. Если в начале был "Заказчик_1", он не должен стать "Покупателем_2" на третьей странице. В медкарте тот же принцип действует для пациента, врача, родственника и страхователя
• хронология должна читаться. Если вы убрали точные даты, все равно должно быть понятно, что было сначала: жалоба, осмотр, анализ, назначение, повторный прием. В договоре должен сохраняться порядок этапов, оплаты и поставки
• числа нужно сверить отдельно. Суммы, дозы, сроки, проценты, единицы измерения и номера пунктов чаще всего теряются при замене
• стоит оценить риск повторного узнавания по набору фактов. Даже без ФИО человека иногда выдают редкий диагноз, возраст, точная дата госпитализации, город, должность и название компании в одном абзаце
• текст полезно показать тому, кто понимает предмет. Юрист сразу увидит, что пропал предмет договора или сломалась логика обязательств. Врач заметит, что исчезла связь между симптомом, анализом и назначением

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

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

Что делать дальше

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

Такой старт быстро показывает, где маскирование сохраняет смысл, а где уже ломает его. На небольшом объеме проще увидеть, что замена "Пациент А" еще работает, а замена дат, дозировок или ролей сторон уже портит ответ модели.

Полезно завести короткий рабочий цикл:

• выбрать один шаблон документа и 20-30 реальных примеров
• описать правила замен в явном виде и присвоить им версию
• вести журнал спорных случаев, где команда не сразу решила, что скрывать, а что оставлять
• собирать примеры, где модель ошиблась уже после обезличивания
• раз в неделю пересматривать правила по этим ошибкам, а не по ощущениям

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

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

Если данные должны оставаться в Казахстане, имеет смысл сравнить свой процесс не только по качеству, но и по режиму работы с данными. Например, AI Router дает OpenAI-совместимый API-шлюз, хранение данных внутри страны, маскирование PII и аудит-логи. Для команды это удобная точка проверки: сохраняется ли нужный режим работы с данными и не теряется ли контроль над обработкой.

Отдельно стоит проверить интеграцию. Если ваш стек уже работает через SDK OpenAI-формата, заранее выясните, можно ли подключить совместимый шлюз без переделки кода, просто сменив base_url на api.airouter.kz. Это экономит время на пилоте и помогает тестировать правила обезличивания без лишних согласований между юристами, безопасниками и разработчиками.