GDPR Минимизација на податоци: API во реално време
Ажурирано за 2026 година
GDPR Член 5(1)(c) вели: собирајте само она што ви треба. Ова е правилото за минимизација на податоци. Повеќето тимови го кршат преку дизајнот на формата, не со лоши намери. Полиња за слободен текст повлекуваат имиња, адреси и идентификациски броеви кои никој не ги планирал.
Почистувањето на базата на податоци подоцна не го решава тоа. Прекршувањето се случило кога ги собирале податоците. Запирањето на изворот е единственото вистинско решение. Проверка на API во реално време при поднесување на форма го спречува прекумерното собирање пред да почне.
Погледнете го нашиот преглед за усогласеност и безбедносни практики за тоа kako ја поддржуваме GDPR Член 5.
Зошто формите прекумерно собираат
Полињата за слободен текст во веб-апликациите собираат лични податоци кои никој не ги планирал:
- Полиња "причина" во билети за поддршка пополнети со медицински истории и броеви на осигурување
- Делови "други коментари" во анкети кои содржат цели имиња и телефонски броеви
- Колони "белешки" на ЧР со години на неструктурирани лични детали
- Полиња "белешки" за нарачки кои содржат идентификациски броеви на клиенти внесени за помош со проблеми
Правилото за минимизација бара овие лични податоци никогаш да не влезат во вашите системи. Ретроактивното чистење го лечи симптомот. Откривањето во реално време ја отстранува причината.
Зошто ретроактивното чистење не е доволно
Тимовите кои ги чистат складираните лични податоци се соочуваат со четири проблеми.
Комплетност. Совпаѓањето на обрасци ги наоѓа очигледните лични податоци како е-пошта адреси и идентификациски броеви. Ги пропушта референциите засновани на контекст. "Мојата сестра Софија имала ист проблем" содржи ime кое повеќето скенирања го прескокнуваат.
Правно времење. Прекршувањето се случува при собирањето. Чистењето на податоците месеци подоцна не го решава. Ако регулатор го прегледа периодот кога податоците биле чувани, прекршувањето веќе е на запис.
Нецелосно бришење. Базите на податоци прават резервни копии. Системите пишуваат дневници. Аналитичките алатки извезуваат податоци. Дури и откако го бришете од главната база на податоци, копиите можат да останат во резервните датотеки и ревизорските дневници.
Изложеност при прекршување. Меѓу собирањето и чистењето, дополнителните лични податоци седат во вашите системи. Прекршување за тоа времe ги ставува прекумерно собраните податоци во опсег.
Запирањето на собирањето на изворот ги решава сите четири. Податоците кои никогаш не влезат не можат да бидат прекршени, не бараат бришење и не се сметаат за прекршување.
Обрасци за откривање за валидација на форми
Постојат три начини да се додаде откривање на лични податоци во реално време на форма.
Страна на клиентот (Chrome Extension). Додатокот ги следи настаните на лепење во полињата на прелистувачот. Кога корисникот лепи текст со лични податоци, тој веднаш ги означува ентитетите. Корисникот ги отстранува пред поднесување. Не е потребен API-повик - откривањето работи локално. Погледнете го речникот за дефиниции на типови на ентитети.
Страна на серверот (интеграција на API). Формата поднесува до вашиот сервер. Пред запишувањето во базата на податоци, вашиот код го повикува API за откривање. API враќа типови на ентитети со резултати на доверба. Совпаѓањата со висока доверба го блокираат поднесувањето со јасна порака. Совпаѓањата со средна доверба поттикнуваат чекор за преглед. Податоците се чисти пред да се складираат.
Хибриден (препорачан). Означувањето на страната на клиентот им дава на корисниците брза повратна информација. Проверките на страната на серверот обезбедуваат гаранција за усогласеност. Ако корисникот ги игнорира предупредувањата на клиентот, проверката на серверот сепак ги фаќа личните податоци. Ништо не стигнува до базата на податоци непроверено. Погледнете го нашиот FAQ за чести прашања за праговите на откривање.
Пример: Здравствен портал за пациенти
Порталот за пациенти им овозможува на пациентите да ги опишат симптомите во поле за слободен текст пред резервирање. Полето редовно добива записи кои вклучуваат имиња на другите пациенти, идентификациски броеви и домашни адреси. Ништо од ова не припаѓа во системот за закажување.
Пред откривање во реално време:
- Лични податоци во полето за симптоми: околу 12% од поднесувањата
- Метод на чистење: неделен серијски процес
- Статус на усогласеност: реактивен - прекршувањето на Член 5(1)(c) се случило при собирањето
По интеграција на API при поднесување:
- API открива лични податоци со висока доверба пред каков и да е запис во базата на податоци
- Пациентот гледа: "Вашата порака изгледа дека содржи лични информации. Ве молиме отстранете ги пред поднесување."
- Пациентот ги ревидира и повторно поднесува
- Базата на податоци добива само опис на симптоми
Во овој сценарио, личните податоци во полето паднаа од приближно 12% на под 1% од поднесувањата. Усогласеноста сега се демонстрира преку дневниците за откривање на страната на серверот наместо ретроспективни циклуси на чистење.
Ревизорски записи на точката на собирање
Регулаторите реактивните тимови ги третираат поинаку од оние со воспоставени контроли. GDPR Член 25 - заштита по дизајн и по default - ги наградува второво.
Откривањето на точката на собирање создава корисни ревизорски записи:
- Дневник за откривање. Секое скенирање на форма се зачувува со типови на ентитети пронајдени, резултати на доверба, преземена акција и исход.
- Месечни извештаи. Резимеа ги покажуваат стапките на откривање по поле и тип на ентитет, и kako корисниците реагираат.
- Записи за конфигурација. Поставки за праг, покриени полиња и типови на ентитети кои се следат - ова покажува јасна, управувана политика.
Овие записи помагаат при преглед од регулатори. Исто така поддржуваат внатрешна ревизија и записи за обработка. Погледнете ги нашите студии на случај за примери на контроли на точката на собирање во пракса.
ВИ алатки и минимизација на податоци
Агентите за поддршка честопати лепат е-пошти на клиенти во алатки за подготвување со ВИ. Тие е-пошти можат да содржат имиња, адреси и броеви на сметки. Испраќањето на тоа до ВИ модел може да надминува она што е потребно.
MCP Серверот додава чекор за откривање пред текстот да стигне до моделот. Имињата на клиентите стануваат [CUSTOMER]. Специфичните детали се чистат. ВИ подготвува одговор користејќи го исчистениот текст. Агентот додава назад само она што одговорот го бара.
Ова го исполнува правилото за минимизација на податоци при употреба на ВИ. Моделот добива само она што е потребно - а тоа обично воопшто не се лични податоци. Погледнете ентитети за целосниот список на типови на ентитети кои ги откриваме.