Поверителността е това, което остава, след като системата се е научила да забравя.

Правото на изтриване не е бутон с надпис „изтрий“. В съвременните системи то е дисциплиниран въпрос за копия, производни данни, доказателства, изключения и...

Поверителността е това, което остава, след като системата се е научила да забравя.

Забравянето не е противоположното на помненето

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

В това се състои практическото достойнство на правото на изтриване. Често го наричат правото да бъдеш забравен, което е ярка фраза, но несъвършена. Човешкото забравяне е случайно, частично и пълно с неудобни завръщания. Законният процес на изтриване трябва да бъде преднамерен. Той трябва да може да различи запис, който трябва да бъде премахнат, от запис, който трябва да бъде запазен, защото законът го изисква, оспорвано твърдение, което трябва да остане налично за правна защита, и технически остатък, който може да бъде изолиран до планираното му изтичане. Той трябва също така да устои на един полезен корпоративен инстинкт: третирането на изтриването като състояние на екрана, а не като свойство на системите.

Общият регламент за защита на данните не обещава, че всяка свързана с дадено лице позиция ще изчезне при поискване. Член 17 определя основанията, на които администраторът трябва да изтрие личните данни без ненужно забавяне, включително когато данните вече не са необходими за целите, за които са били събрани или обработвани, когато е оттеглено съгласието и няма друго правно основание, и когато обработването е било незаконосъобразно. Същият член поставя граници. Изтриването не се прилага, когато обработването е необходимо, например, за свободата на изразяване и информацията, за изпълнение на правно задължение, за задачи от обществен интерес при определени обстоятелства, за целите на общественото здраве, за архивиране, за научни или статистически цели при спазване на подходящи гаранции или за установяването, упражняването или защитата на правни претенции. Това не е вратичка в обещание. Това е действителната форма на правото.

Така че въпросът към собственика на система не е: „Можем ли да изтрием данни?“ Почти всяка система може да изтрие нещо. Въпросът е дали организацията може да обясни, за конкретно искане и конкретна цел на обработване, кои данни притежава, какво се е случило с тези данни, какво е задължена или има право да запази, кои получатели надолу по веригата трябва да бъдат уведомени и как може да бъде проверено извършеното действие. Разликата звучи процедурна. На практика тя е архитектурна. Продукт, който знае само как да добавя информация, ще открие, че изтриването е много по-скъпа функция.

Това е особено остро за системите с изкуствен интелект, но не се ограничава до тях. Търсенето, анализите, поддръжката на клиенти, идентичността, мониторингът на сигурността и управлението на документи произвеждат производни данни. Моделът просто дава на проблема нови имена: токени, градиенти, вграждания, индекси за извличане, подкани и изходи. Нито един от тези етикети не разтваря основния въпрос дали дадено физическо лице остава идентифицируемо. Нито техническият термин тихо отговаря на правния въпрос. Едно вграждане не е автоматично анонимно, защото е трудно за четене. Един лог не е автоматично необходим, защото е полезен. Един резервен архив не е автоматично освободен, защото е неудобен.

Поверителността след забравянето следователно не е празна страница. Тя е остатъчното състояние, което остава, след като организацията е взела законосъобразно, пропорционално и проверимо решение за това, което вече не трябва да се обработва. Качеството на това остатъчно състояние казва на хората много повече за една система, отколкото наличието на бутон за изтриване някога би казало.

Правото има условия, и точно това го прави по-силно

Европейското законодателство за защита на данните понякога се описва така, сякаш предоставя на индивида универсален червен бутон. Тази картина е достатъчно спретната за презентация и достатъчно грешна, за да създаде проблеми. Член 17 е обвързан с целта, правното основание и обстоятелствата на обработването. Той съдържа право, задължения за администраторите и изключения, които защитават други права и обществени интереси. Отговорният подход започва с установяване на самоличността на заявителя, когато това е необходимо, с разбиране на данните и целта на обработването и с преценка дали се прилага основание по член 17 и изключение. Отговорът може да бъде изтриване. Може да бъде мотивиран отказ, изцяло или частично. Може да бъде ограничаване на обработването, докато се разреши спор. Може също да бъде искане, което сочи към система, която организацията не контролира.

Това не е причина да се превръща искането на субект на данни в малка писта с препятствия. GDPR изисква от администраторите да улесняват упражняването на правата. Член 12 изисква информацията и комуникацията относно действията, предприети по дадено искане, да бъдат кратки, прозрачни, разбираеми и лесно достъпни. Той обикновено изисква информация за предприетите действия без ненужно забавяне и във всички случаи в срок от един месец от получаването. Срокът може да бъде удължен с още два месеца, когато е необходимо, предвид сложността и броя на исканията, но администраторът трябва да уведоми лицето за удължаването и причините за него в рамките на първия месец. Система, която не може да идентифицира собствените си потоци от данни до третия месец, не е открила процесуална защита. Тя е открила проблем с управлението.

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

Съдът на Европейския съюз помогна да се види още едно разграничение. Неговите решения относно дереферирането се отнасят до представянето на връзки от търсачките, а не до нареждане за изтриване на основната публикация от уебсайта източник. В делото Google Spain Съдът постанови, че операторът на търсачка може да носи отговорност за обработването на лични данни, които се появяват на уеб страници, публикувани от трети страни, и че субектът на данни може при определени обстоятелства да поиска премахване на връзки от списъка с резултати, показан след търсене по името на лицето. В по-късни дела Съдът разгледа въпроси, включително чувствителни данни, териториалния обхват на дереферирането и неточна информация. Тези дела не превръщат всеки нежелан факт в искане за изтриване. Те показват защо една система трябва да посочи слоя, който е засегнат: публикация източник, индекс, списък с резултати, кеш, извлечение или друго копие.

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

It is tempting to resent the conditions because they prevent a simple promise. But they make the promise meaningful. A right that ignores legal duties, other fundamental rights and the practical distinction between systems would collapse into a ritual. The European approach asks for an accountable decision, not a theatrical one. That takes more work. It also makes a refusal challengeable and an erasure credible.

Erasure begins by locating the processing surfaces. The diagram is a systems map, not a claim that every surface has the same legal treatment.

A record can disappear from the screen and remain in the system

The easiest deletion failure is familiar to anyone who has built an application: remove an item from the product interface, leave the underlying data in a store, and assume the job is done because ordinary users can no longer see it. Sometimes a soft delete is exactly the right operational design. It may preserve a short undo period, make replication safe or avoid breaking a relationship that has to be resolved. But soft deletion is not erasure merely because the interface has become quieter. Its use must be connected to a defined purpose, a retention period, access controls and a later action that actually changes the data state.

Hard deletion has its own limits. Deleting a row may leave a search index until the next indexing cycle. An object store may have versioning. A content delivery cache may carry a response until expiry or invalidation. A message queue may contain an event that has not yet been processed. A data warehouse may have ingested a snapshot. A service may have transferred the data to a processor, a subprocessor or a recipient. The practical lesson is not that deletion is impossible. It is that an organisation needs an inventory with enough fidelity to distinguish these surfaces and a policy that says what occurs on each one.

There is a further distinction between content and evidence. A customer-service ticket may contain a person’s message. A system may need a record that a ticket existed, was resolved and was deleted under an approved rule. Keeping the entire message forever to prove that it was deleted is a small bureaucratic masterpiece, but not a privacy control. A better design retains only the minimum evidence needed for accountability, separated from the content that no longer has a purpose. That evidence might be a request identifier, decision type, completion time, applicable retention category and the systems reached. The design depends on the organisation. The principle does not: proof should not recreate the unnecessary personal data.

Backups deserve the same plain language. A backup may be necessary for availability, security or disaster recovery. It is still processing. The practical question is whether the backup is separately accessible, how long it remains recoverable, who can restore it, whether it is included in the normal erasure flow, and how a restored environment is prevented from silently reintroducing data that have since been removed from the live system. A reasonable policy may rely on the backup’s defined rotation period rather than modifying every historical backup block individually. But a policy needs to say so, protect access in the meantime and ensure that restoration follows the current data state where possible. ‘It is in backup’ describes a problem. It is not an answer to it.

Дневниците са подобни. Дневниците за сигурност и оперативните дневници могат да бъдат от съществено значение. Те може да са единственият източник на информация за достъп, неуспешен опит за удостоверяване или промяна в производствената среда. Те могат също така да съхраняват идентификатори, адреси, тела на заявки или фрагменти от съдържание, които никога не са били необходими за диагностика. Добрият дизайн на регистрирането свежда до минимум събирането, редактира или псевдонимизира, където е уместно, отделя чувствителните данни от метаданните на събитието, ограничава достъпа и прилага графици за съхранение. Опитът да се открие всяко чувствително поле при искане за изтриване е възможен, но е лош заместител на решението, взето по време на проектирането, какво дневникът никога не е трябвало да съдържа.

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

Производните данни не са вратичка за бягство

Съвременните системи често трансформират лични данни, преди да ги използват. Те извличат дата от документ, класифицират съобщение, изчисляват резултат, правят извод за език, създават индекс за търсене, изготвят обобщение, свързват два акаунта или превръщат текст и изображения във вектори за търсене по сходство. Тези трансформации могат да бъдат полезни. Те могат също така да създадат усещане у организацията, че е излязла извън обхвата на личните данни. Това не е задължително да е така.

ОРЗД е технологично неутрален. Неговите съображения обясняват, че псевдонимизирани данни, които биха могли да бъдат приписани на физическо лице чрез допълнителна информация, следва да се считат за информация за идентифицируемо физическо лице. Те също така обясняват, че при определянето на идентифицируемостта трябва да се вземат предвид всички средства, за които е разумно вероятно да бъдат използвани от администратора или от друго лице, като се отчитат фактори като разходи, време, налични технологии и технологично развитие. Въпросът не е дали дадено представяне прилича на име в електронна таблица. Въпросът е дали то се отнася до идентифицирано или идентифицируемо лице в конкретния контекст.

Едно вграждане прави тази точка полезно неудобна. В система за извличане на информация даден документ може да бъде разделен на части и представен като числови вектори, така че заявка да може да намери семантично сходен материал. Векторът не е четим параграф. Той обаче може да бъде свързан с изходен документ, клиент, потребител, контрол на достъпа, поле с метаданни или ключ за извличане. Той може да позволи на системата да избере личен материал в отговор на заявка. Организацията не може да го нарече анонимен само защото човек не може да реконструира изречение, като гледа списък с координати. Тя трябва да оцени представянето, свързаните данни, средствата за свързване и целта на обработката.

Същото се отнася и за извлечен резултат. Резултат за риск, категория на предпочитанията или индикатор за допустимост може да съдържа по-малко сурови данни от изходните данни и въпреки това да има сериозни последици за лицето. Той може да бъде лични данни, ако се отнася до идентифицирано или идентифицируемо лице. Изтриването на източника, докато се запазва резултат, който продължава да влияе върху решение, не е чисто решение. То може просто да премести лицето в по-непрозрачна форма. Системата се нуждае от правило за производните данни: кои се изтриват заедно с източника, кои се преизчисляват, кои вече не могат да се използват, кои трябва да се съхраняват съгласно отделно задължение и кой решава.

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

Тази несигурност не е причина всяко производно да се описва като окончателно опасно. Тя е причина да се поддържа проследимост. Екипът трябва да знае кои набори от входни данни са използвани за хранилище на характеристики, индекс, обучение на модел или отчетна таблица; кои версии на дадено производно са създадени; кои системи ги използват; и каква реакция трябва да предизвика промяна в източника. Проследимостта превръща неудобния въпрос в ограничена инженерна задача. Без нея всяко искане за права се превръща в археологическа експедиция из имена на задания, хранилища и нечий спомен за миграция отпреди две зими.

Машинното обучение добавя труден въпрос, а не магическо освобождаване

Машинното обучение прави изтриването трудно, защото обучението не е операция по архивиране. Един пример за обучение може да повлияе на параметрите чрез дълга поредица от актуализации, заедно с много други примери. Разгърнат модел може да е бил копиран в няколко среди. По-късен модел може да е бил дообучен от по-ранен. Екипът може да използва данни за оценка, подсказки, корпуси за извличане и регистрационни файлове с обратна връзка, които следват различни жизнени цикли. Ако данните на дадено лице са попаднали в такава система, организацията не може отговорно да отговори с вдигане на рамене относно математиката. Тя също така не може честно да обещае, че изтриването от една база данни премахва всяко възможно влияние върху всеки параметър.

Първата стъпка е да се разделят системите. Корпусът за извличане не е обучен модел. Ако даден документ се използва като източник за извличане, изтриването може да включва премахване или деактивиране на документа, неговите части, метаданни и индексни записи, след което проверка, че извличането вече не го достига. Регистърът на подсказки не е хранилище за вграждания. Наборът за дообучаване не е одитен запис за сигурност. Контролна точка на модел не е актуален изходен запис. Правилният отговор може да е различен за всяка повърхност, но отговор не може да бъде проектиран, докато повърхностите не бъдат назовани.

За обучителните данни законният и техническият анализ може да изисква решение дали повторното обучение, замяната, ограничаването, запазването или друга мярка е подходяща. Изследванията върху „разучаването“ на модели са от значение, защото проучват методи за намаляване на влиянието на конкретни данни без повторно обучение на модела от нулата. Те не са общо доказателство, че системата е забравила. Методите имат допускания, класове модели, условия за данни и ограничения на проверката. Организацията не трябва да представя експериментална техника като универсално прилагане на член 17. Нито пък трябва да чака съвършена техника, преди да проектира по-добър контрол върху данните.

По-добрият контрол започва нагоре по веригата. Свеждайте до минимум събираните данни. Отделяйте личните данни от обучителния материал там, където предвидената цел позволява. Определете срок на съхранение, преди натрупването да направи въпроса емоционално скъп. Водете версионирани записи на наборите от данни и обученията. Правете изрични условията за съгласие или други законови основания, когато те са релевантната база. Не позволявайте архивът на производствените подсказки тихо да се превърне в корпус за разработване на модели. Дръжте данните за оценка и поддръжка различими от обучителните данни. Колкото по-малко системата разчита на неизвестен произход, толкова по-точно може да отговори на въпрос за изтриване.

Има граница и на думата „влияние“. Човек може да се притеснява, че даден текст някога е бил част от тренировъчен набор. Технически екип може да успее да установи, че изходният запис е премахнат от текущия корпус, но не може да докаже, във философски смисъл, че нито един фрагмент от влиянието не остава в някой параметър на исторически модел. Законът за защита на личните данни не става по-лесен, когато организация замени конкретното описание с метафизика. Задължението е да се оценят обработването, основанията и мерките съгласно закона. Организацията трябва да обясни обхвата на заключението си, системите, които покрива, и оставащото ограничение. Прецизността е по-милосърдна от прекомерното обещание.

За внедрителите на ИИ практическият товар често принадлежи колкото на доставките, толкова и на инженерството. Доставчикът трябва да може да обясни какво прави с подканите, качените файлове, телеметрията и незадължителната обратна връзка; кои от тях се използват за обучение или подобряване на услугата; какви контроли за съхранение съществуват; как клиентът може да получи информацията, необходима за отговор на искания за права; и какво се случва в споделена среда в сравнение с отделна. Договор, който просто казва „съобразен с GDPR“, не е предоставил информацията, необходима за изпълнение на процес по изтриване. Той е предоставил прилагателно.

Търсачките преподават полезен урок за слоевете

Практиката на Съда на ЕС относно дереферирането е полезна тук именно защото е по-тясна от популярната фраза „правото да бъдеш забравен“. Делата се отнасят до това дали и при какви условия търсачката трябва да премахва връзки от резултатите при търсене по име. Те не създават просто право да се променя историята в нейния източник. Това разграничение показва, че въпросите за поверителността често се отнасят до това как информацията се предоставя, свързва и усилва, а не само до това дали даден запис някога е съществувал.

В делото Google Spain Съдът разглежда връзки в списъка с резултати на търсачката към страници, публикувани от трета страна. Решението изясни, че дейността на търсачката може да представлява обработване на лични данни и че при определени условия операторът може да бъде задължен да премахне връзки от резултатите, показани след търсене по име на дадено лице. Решението не е било заповед към вестника, публикувал първоначалните обяви. Собственикът на система, който гледа вътрешна база от знания, може да се поучи от това: индексите за търсене, визуализациите и класирането на резултатите са слоеве на обработване със собствени последици.

Делото GC и други разглежда искания за премахване на връзки към уеб страници, съдържащи чувствителни лични данни. Съдът се занима с извършваното балансиране и задълженията, които могат да възникнат за оператора на търсачка. Делото Google срещу CNIL се отнася до териториалния обхват и постановява, при обстоятелствата по това дело, че правото на ЕС не изисква дерефериране във всички версии на търсачката по света, като същевременно изисква ефективни мерки за предотвратяване или сериозно обезкуражаване на достъпа от държавите членки до връзки, премахнати от версиите на ЕС. Делото TU и RE се отнася до искане относно твърдяно неточна информация и изяснява елементи от тежестта на доказване и третирането на визуализации на изображения. Тези съдебни решения са правни решения, специфични за конкретните факти, а не контролен списък за внедряване. Заедно те изтъкват системен момент: връзката, списъкът с резултати, визуализацията на изображението и оригиналната страница не е задължително да имат едно и също средство за защита.

Този момент се пренася добре. Корпоративен портал може законно да съхранява изходен запис за ограничена цел, докато достъпът чрез широк повърхностен резултат от търсене е прекомерен. Система за техническа поддръжка може да се нуждае от защитен одитен запис, докато нейната визуализация при автоматично довършване не трябва да показва данните на бивш клиент на голяма група. Документ може да бъде премахнат от корпус за извличане, докато обобщение, генерирано от модел, остава в различно хранилище. Правилният отговор не е да се обяви всеки слой за идентичен. Той е да се разбере как слоят променя излагането, целта и риска.

Документът предупреждава и срещу един популярен опростен подход: да се приема, че видимостта е единственият проблем на поверителността. Един запис може да е технически скрит и въпреки това да бъде обработван, запитван, профилиран, прехвърлян или възстановяван. Обратно, една организация може да има нужда от внимателно ограничен запис, за да докаже, че е реагирала коректно, да защити правно претенция или да изпълни законово задължение. Поверителността не е състезание за създаване на възможно най-малко данни при всякакви обстоятелства. Тя е дисциплина на цел, необходимост, пропорционалност и контрол.

Ето защо инвентаризацията за изтриване трябва да включва пътищата за извличане и представяне. Попитайте кои индекси съдържат записа, кои кешове го обслужват, кои експорти го включват, кои API го връщат, кои производни полета се използват за класиране или препоръчване и кои пътища за възстановяване от резервно копие могат да го върнат към живот. Списъкът няма да е елегантен. Той ще е по-полезен от елегантността.

Демонстрацията е различна от твърдението

Когато една система твърди, че може да изтрива данни, има два отделни въпроса. Първият е дали дизайнът има легитимен, документиран път за това. Вторият е дали организацията може да докаже, че пътят е бил следван за конкретно искане, без да запазва повече лични материали, отколкото изисква самата демонстрация. Първият е продуктова способност. Вторият е отчетност.

Един полезен запис за изтриване е умишлено скромен. Той не трябва да възпроизвежда цялото искане, документи или история на акаунта на дадено лице в нова база данни за съответствие. Може да записва референтен номер на искането, резултата от проверката на самоличността, когато е приложимо, категорията на искането, приложимите системи, решението и правната обосновка на подходящо ниво, датите на действията, изключенията или основанията за съхранение, уведомяването на получателите, когато се изисква, и статуса на асинхронното изтриване или изтичането на резервните копия. Точните полета зависят от администратора и контекста. Важното е, че по-късно проверяващият може да види пътя, без да възстановява чувствителното съдържание от фрагменти.

Проверката трябва да съответства на повърхността на данните. Запис в активна приложна система може да бъде проверен, като се потвърди, че оторизирано търсене вече не го връща. Система за извличане може да бъде тествана с оригиналния идентификатор и съответните модели на заявки, като се избягват широки опити за възстановяване на лично съдържание. Индекс може да докладва своето състояние на изтриване. Опашка може да покаже завършване. Процес за архивиране може да покаже, че възстановимият образ е защитен съгласно правилото си за съхранение и че възстановяването прилага актуален регистър на изтриванията или еквивалентен контрол. Проверката не трябва да доказва метафизично отрицание. Тя трябва да предостави доказателства, съразмерни на направеното твърдение.

Тук има скрит капан. Екип може да изгради впечатляващ таблоуърд с всички зелени светлини и без стабилна връзка с реалната работа. Смислен таблоуърд назовава повърхността на данните, действието, състоянието, собственика, доказателствата и следващата проверка. Той прави възможно разграничаването между „искането е прието“, „активният запис е изтрит“, „уведомяването на получателя е в процес на изпращане“, „резервното копие очаква изтичане“ и „запазено по законово задължение“. Тези състояния имат различни значения. Ако бъдат слети в „изтрито“, несигурността се превръща в дизайн на потребителския интерфейс.

Доказуемото изтриване зависи и от управлението на промените. Изходната система може да бъде заменена, процесор добавен, форматът на индекса променен, нова аналитична дестинация въведена или политиката за съхранение на доставчик на ИИ преразгледана. Ако процедурата за изтриване не бъде актуализирана с тези промени, тя постепенно започва да описва система, която вече не съществува. Резултатът е познат от всяка оперативна дисциплина: красив наръчник и реална услуга, които се движат в противоположни посоки. Редовното тестване на малка извадка от пътя, включително и на неудобната система, обикновено е по-показателно от поръчването на голям документ за осигуряване на качество, който никой не може да изпълни.

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

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

Съхранението е другата половина на изтриването

Много проблеми с изтриването започват много преди подаване на искане. Те започват, когато една система изобщо няма решение за съхранение. Данните пристигат, защото може да станат полезни. Логовете стават постоянни, защото съхранението е евтино. Експортът се пази, защото бъдещ одит може да го поиска. Обучителните данни се трупат, защото по-късен модел може да има полза. Всяко решение изглежда безвредно поотделно. Заедно те превръщат организацията в собственик на голям, слабо разбран архив и правят всяко искане за изтриване по-скъпо, по-несигурно и по-оспоримо.

Принципът за ограничаване на съхранението по GDPR гласи, че личните данни следва да се съхраняват във вид, който позволява идентифициране на субектите на данни, за период не по-дълъг от необходимия за целите, за които се обработват, при допускане на по-дълго съхранение за архивиране в обществен интерес, за научни или исторически изследвания или за статистически цели, когато са приложими подходящи гаранции. Принципът не предписва един календар за всяка организация. Той изисква преценка, обвързана с целта. Графикът за съхранение затова трябва да посочва категориите данни, целта, правното основание, обичайния срок, събитието, което го задейства, изключението, действието по унищожаване, собственика и точката на преглед. „Колкото е необходимо“ е принцип. Той става оперативно правило едва когато някой може да каже необходимо за какво, до кога и решено от кого.

Тази структура е полезна за ИИ, защото предотвратява един широк етикет, като обучителни данни, да скрива няколко различни неща. Суров принос, почистен набор от данни, набор от характеристики, версия на модел, история на подканите, набор за оценка и лог за мониторинг може да имат различни цели и съображения за съхранение. Комбинирането им в един неопределен срок влошава както иновациите, така и отчетността. Разделянето им не гарантира правен отговор, но го прави възможен.

Решенията за съхранение също печелят от условие за отказ. Какво би ни накарало да спрем да съхраняваме това? Приключен договор, разрешен спор, изтичане на законен срок, приключено разследване по сигурността, заменена версия на модел, изтичане на прозореца за възстановяване или решение да не преследваме изследователска цел могат да бъдат реални задействания. Смисълът не е да автоматизираме часовник за изтриване на всичко. Смисълът е да избегнем система, в която единственото условие за пазене на данни е, че никой още не е бил задължен да ги обясни.

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

Това не означава, че всяка организация трябва да централизира всяко решение за изтриване. Местните екипи често разбират по-добре своите процеси. Означава, че местните правила се нуждаят от общи понятия, видима отговорност и път за ескалация. В противен случай архивът на единия екип е нарушение за другия, а искането на дадено лице преминава през лабиринт от учтиво наименувани услуги.

Какво може да каже честен доставчик на ИИ

Честният доставчик на ИИ не твърди, че всички клиентски данни изчезват, когато пристигне искане. Нито пък се крие зад трудността на моделите. Той описва границата на услугата. Какво се обработва за изводи. Какво се запазва за администриране на акаунта, сигурност, поддръжка, фактуриране или предотвратяване на злоупотреби. Дали подканите и резултатите се съхраняват. Дали се използват за обучение, оценка или подобряване на услугата. Кои обработващи страни и региони участват. Как клиентите могат да конфигурират запазването. Каква документация съществува за искания на субекти на данни. Кои действия са незабавни, кои са асинхронни и кои зависят от отделна правна оценка.

За купувачите въпросите при възлагане на поръчка са практични. Можем ли да получим ясна карта на потока от данни? Можем ли да идентифицираме ролите на администратор и обработващ за съответната обработка? Можем ли да експортираме или изтрием материали по използваем начин? Включени ли са индексите за извличане и производните хранилища в документирания жизнен цикъл? Какво се случва с архивите? Как се съобщават промените в подизпълнителите? Може ли доставчикът да ни помогне да отговорим на искане в приложимия срок? Дали използването за обучение и подобряване на услугата е по избор, по подразбиране, изключено по договор или описано само на страница, която може да се промени след покупката? Какви технически записи са налични, за да докажат действие?

Отговорите ще варират. Голяма споделена услуга не винаги може да предложи същия контрол като специална среда. Запис от регистъра за сигурност не винаги може да бъде изтрит в същия момент като профила на акаунта. Законодателно изискван архив не може да се третира като потребителско предпочитание. Тези разлики не са непременно недостатъци. Мълчанието за тях е. Правилният отговор на купувача е да съпостави документираното поведение на услугата с целта, задълженията и риска на организацията. Даден продукт може да е неподходящ за силно чувствителна задача, дори когато е напълно подходящ за инструмент за чернова с нисък риск.

В Dweve нашият Trust Centre възприема същия тесен възглед за доказателствата. Публична страница може да опише контролите и границите на документацията, но не може да сертифицира всяко клиентско внедряване или да реши законовото основание за обработката на клиента. Тази граница има значение. Платформата може да поддържа контроли за запазване, записи и проверими работни потоци. Организацията, която я използва, все пак носи отговорност за своята цел, своите решения за данните и решението да отговори на конкретно лице. Добрият продуктов текст трябва да прави тази отговорност по-ясна, а не тихо да я поема.

Най-ценното изявление на доставчика често е ограничение. „Този запис ще остане в защитени архиви до края на посочения период на ротация.“ „Тази услуга не използва указаното клиентско съдържание за обучение съгласно тези условия.“ „Този индекс се премахва асинхронно и статусът може да се провери тук.“ „Не можем да направим това твърдение за интеграция на трета страна.“ Тези изречения може да изглеждат по-малко вълшебни от универсално обещание за поверителност. Те позволяват на купувача да проектира реален процес.

Въпроси, които си струва да зададете, преди да пристигне искането

Една организация не трябва да измисля пробив в сигурността, човек в тежко състояние или героичен инцидент късно през нощта, за да тества дизайна на своето изтриване. Може да използва ясно обозначена хипотетична заявка по време на нормално работно време. Да предположим, че дадено лице поиска изтриване на материал, съхраняван в система, ориентирана към клиенти. Кой екип получава заявката? Как се проверява самоличността, без да се събира прекомерно нова информация? Кои цели са от значение? Кои системи съдържат изходни данни, производни данни, индекси, регистрационни файлове, кешове, експортирани файлове и резервни копия? Кои обработващи данни лица се нуждаят от инструкция или уведомление? Кое изключение или задължение за съхранение, ако има такова, се прилага? Кой може да реши? Кой може да изпълни? Как организацията ще обясни резултата?

След това задайте неудобните технически въпроси. Може ли оператор да намери актуалната инвентаризация на данните без бивш инженер? Може ли индексът за търсене да бъде проверен независимо от изходната си таблица? Появява ли се отново изтрит идентификатор след възстановяване? Използват ли пакетните задания стари моментни снимки? Може ли хранилището за вграждания да бъде свързано със своите документи и клиент? Улавя ли наблюдаващият конвейер съдържанието на подканите по подразбиране? Управляват ли се експортираните файлове от същите правила за съхранение като техния източник? Създава ли записът на доказателствата нова купчина чувствително съдържание? Това не са крайни случаи, добавени, за да изглежда дадена политика сериозна. Те са обичайни последици от системи, които правят копия, за да работят.

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

Нищо от това не замества правен съвет в конкретен случай. Изискванията на GDPR, националното законодателство, секторните задължения, договорите и фактите около обработването имат значение. Но организациите не се нуждаят от правен спор, за да започнат да изграждат условията за разбираем отговор. Те трябва да познават системите си достатъчно добре, за да спрат да предлагат просто обещание за сложна реалност.

Неприкосновеността на личния живот е качеството на остатъка

Амбицията зад изтриването не е да направи миналото нереално. Тя е да даде на хората смислен контрол там, където данните вече не е необходимо да бъдат обработвани, където съгласието е оттеглено, където обработването е неправомерно или където се прилага друго основание по член 17. Тя изисква от администраторите да третират личните данни като нещо, съхранявано за цел, а не като суровина с неограничено право на ползване. Тя изисква от тях да обясняват изключенията, вместо да ги използват като димна завеса. Тя изисква от системите да носят достатъчно проследимост, за да може забравянето да бъде съзнателно.

За цифровите услуги тихият тест е какво остава. След като запис бъде премахнат от екрана на продукта, какво все още е активно? След като документ напусне корпуса за извличане, кое производно представяне все още го избира? След като акаунт бъде изтрит, кой регистрационен файл се съхранява, за каква цел и за колко време? След като резервно копие бъде възстановено, какво предотвратява завръщането на оттеглен запис? След като модел се промени, каква история на данните може да бъде проверена? След като заявка бъде приключена, може ли организацията да покаже работата си, без да изгражда друг скрит профил?

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

Източници