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

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

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

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

Откриването на личен акаунт е само началото

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

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

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

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

Как да установим дали информацията е напуснала устройството?

Най-важната стъпка е да се реконструира конкретното действие, а не да се правят заключения само въз основа на използваната услуга.

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

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

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

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

Проверка на съдържанието и рискът от разкриване

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

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

При данни за клиентска сметка например трябва да се провери дали са били изпратени само номер и име, или и допълнителна информация, която позволява измама или неоторизиран достъп. Ако в заявката са включени пароли, ключове или токени за достъп, приоритетът може да бъде незабавното им отнемане или подмяна.

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

Защо служителят е използвал личен акаунт?

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

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

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

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

Предупреждение, редактиране или блокиране

Организациите могат да използват няколко нива на контрол според чувствителността на данните и риска от конкретното действие.

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

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

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

Практичен контролен списък при засечен личен ChatGPT на служебно устройство

1. Установяване на събитието и запазване на доказателствата

• Идентифицирайте служителя, устройството, времето на събитието и използваната услуга.

• Запазете относимите журнали от системите за защита на крайните устройства, управление на устройствата, браузъра, прокси и DLP.

• Установете дали става дума само за достъп до услугата, за въведена заявка или за действително изпратено съдържание.

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

2. Определяне на потенциалното разкриване

• Проверете дали заявката е изпратена, блокирана или редактирана.

• Установете какви категории данни са включени – клиентски, лични, финансови, договорни или технически.

• Проверете за качени файлове, споделени връзки и допълнителни данни, които могат да променят оценката на риска.

• Потърсете предишни сходни събития, за да определите дали случаят е единичен или повтарящ се.

• Не приемайте без доказателства, че данните са използвани за обучение на модел или са станали публични.

3. Ограничаване на риска и реакция

• При изпратени пароли, токени или ключове за достъп оценете необходимостта от незабавното им отнемане или подмяна.

• Уведомете отговорника по информационна сигурност и собственика на засегнатите данни; включете длъжностното лице по защита на данните, когато е приложимо.

• Оценете дали са необходими допълнителни действия спрямо клиенти, партньори или компетентни органи съгласно приложимите изисквания.

• Документирайте установените факти, неизвестните обстоятелства, предприетите мерки и остатъчния риск.

4. Предотвратяване на повторение

• Проверете дали корпоративният ИИ инструмент е достъпен и подходящ за задачите на служителя.

• Изяснете правилата за използване на лични акаунти и за въвеждане на поверителни данни във външни услуги.

• Настройте предупреждения, редактиране или блокиране според чувствителността на информацията и риска.

• Тествайте правилата с реалистични примери и следете за пропуски и фалшиви положителни резултати.

• Определете отговорник и срок за коригиращите действия, а след това проверете дали те са изпълнени.

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

От реакция при инцидент към работещ контрол

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

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

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