Минимизация на данните по GDPR: API в реално време
Актуализирано за 2026 г.
Член 5(1)(c) от GDPR гласи: събирайте само необходимото. Това е правилото за минимизация на данните. Повечето екипи го нарушават чрез дизайна на формулярите, не чрез лоши намерения. Полетата за свободен текст събират имена, адреси и идентификационни номера, за които никой не е планирал.
Почистването на базата данни по-късно не го поправя. Нарушението се е случило, когато сте събрали данните. Спирането им при източника е единственото истинско решение. Проверката чрез API в реално време при изпращане на формуляр спира свръхсъбирането преди да е започнало.
Вижте нашия преглед на съответствието и практики за сигурност за това как поддържаме GDPR член 5.
Защо формулярите събират излишно
Полетата за свободен текст в уеб приложенията събират лични данни, за които никой не е планирал:
- Полетата "причина" в тикетите за поддръжка, попълнени с медицински истории и застрахователни номера
- Разделите "други коментари" в анкети, съдържащи пълни имена и телефонни номера
- Колоните "бележки" в HR системите с години неструктурирани лични данни
- Полетата "бележки" към поръчки, съдържащи клиентски идентификационни номера, въведени за помощ при проблеми
Правилото за минимизация изисква тези лични данни никога да не влизат в системите ви. Ретроспективното почистване лекува симптома. Засичането в реално време премахва причината.
Защо ретроспективното почистване е недостатъчно
Екипите, почистващи съхранени лични данни, се сблъскват с четири проблема.
Пълнота. Съпоставянето на шаблони открива очевидни лични данни като имейл адреси и идентификационни номера. Пропуска базирани на контекст препратки. "Сестра ми Соня имаше същия проблем" съдържа име, което повечето сканирания пропускат.
Правен момент. Нарушението се случва при събирането. Почистването на данните месеци по-късно не го поправя. Ако регулатор прегледа периода, в който данните са били съхранявани, нарушението вече е в документите.
Непълно изтриване. Базите данни правят резервни копия. Системите записват журнали. Аналитичните инструменти експортират данни. Дори след изтриване от основната база данни, копия могат да останат в резервни файлове и одитни журнали.
Излагане при нарушение. Между събирането и почистването, допълнителните лични данни стоят в системите ви. Нарушение в този прозорец поставя свръхсъбраните данни в обхвата.
Спирането на събирането при източника решава всичките четири. Данните, които никога не влизат, не могат да бъдат нарушени, не се нуждаят от изтриване и не се считат за нарушение.
Шаблони за засичане при валидиране на формуляри
Има три начина за добавяне на засичане на лични данни в реално време към формуляр.
От страна на клиента (Chrome Extension). Разширението наблюдава събитията на поставяне в полетата на браузъра. Когато потребител постави текст с лични данни, то маркира субектите незабавно. Потребителят ги премахва преди изпращане. Не е необходимо API обаждане - засичането работи локално. Вижте речника за определения на типовете субекти.
От страна на сървъра (интеграция с API). Формулярът изпраща до вашия сървър. Преди записа в базата данни, кодът ви извиква API за засичане. API връща типовете субекти с оценки на доверие. Съвпаденията с висока достоверност блокират изпращането с ясно съобщение. Съвпаденията със средна достоверност задействат стъпка за преглед. Данните са чисти преди да бъдат съхранени.
Хибриден (препоръчителен). Маркирането от страна на клиента дава на потребителите бърза обратна връзка. Проверките от страна на сървъра предоставят гаранцията за съответствие. Ако потребителят игнорира предупреждението от клиента, проверката от сървъра все още улавя личните данни. Нищо не достига до базата данни непроверено. Вижте нашия FAQ за чести въпроси относно праговете за засичане.
Пример: Портал за пациенти в здравеопазването
Порталът за пациенти позволява на пациентите да опишат симптомите си в поле за свободен текст преди записване. Полето редовно получава записи, включващи имена на други пациенти, идентификационни номера и домашни адреси. Нищо от това не принадлежи в системата за записване.
Преди засичане в реално време:
- Лични данни в полето за симптоми: около 12% от изпращанията
- Метод за почистване: седмичен пакетен процес
- Статус на съответствие: реактивен - нарушението по член 5(1)(c) се е случило при събирането
След интеграция с API при изпращане:
- API открива лични данни с висока достоверност преди всякакво записване в базата данни
- Пациентът вижда: "Изглежда, че съобщението ви съдържа лична информация. Моля, премахнете я преди изпращане."
- Пациентът преработва и изпраща отново
- Базата данни получава само описанието на симптомите
В този сценарий личните данни в полето са намалели от около 12% до под 1% от изпращанията. Съответствието сега се демонстрира чрез журнали за засичане от страна на сървъра, а не чрез ретроспективни почиствания.
Одитни записи в точката на събиране
Регулаторите третират реактивните екипи различно от тези с въведени контроли. GDPR член 25 - защита по замисъл и по подразбиране - награждава последните.
Засичането в точката на събиране създава полезни одитни записи:
- Журнал за засичане. Всяко сканиране на формуляр се записва с намерените типове субекти, оценки на доверие, предприетото действие и резултата.
- Месечни отчети. Резюметата показват нивото на засичане по поле и тип субект, и как потребителите реагират.
- Записи за конфигурация. Настройки за прагове, покрити полета и наблюдавани типове субекти - това показва ясна, управлявана политика.
Тези записи помагат при прегледи от регулатори. Те също поддържат вътрешния одит и записите за дейностите по обработване. Вижте нашите казуси за примери на контроли в точката на събиране на практика.
ИИ инструменти и минимизация на данните
Агентите за поддръжка често поставят клиентски имейли в инструменти за изготвяне с ИИ. Тези имейли могат да съдържат имена, адреси и номера на сметки. Изпращането на това до ИИ модел може да надхвърли необходимото.
MCP сървърът добавя стъпка за засичане преди текстът да достигне до модела. Клиентските имена стават [CUSTOMER]. Конкретните детайли се почистват. ИИ изготвя отговор, използвайки почистения текст. Агентът добавя обратно само необходимото за отговора.
Това отговаря на правилото за минимизация на данните при използване на ИИ. Моделът получава само необходимото - което обикновено изобщо не е лична информация. Вижте субектите за пълния списък от типове субекти, които засичаме.