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

Кои ИСО стандарти дават реална стойност

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

ISO 27001 – управление на информационната сигурност

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

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

ISO 9001 – качество, проследимост и контрол на процесите

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

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

ISO 22301 – непрекъсваемост на бизнеса

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

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

ISO 27701 – управление на личните данни

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

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

Внедряване на ключови ИСО стандарти без формален подход

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

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

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

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

Сертификацията е етап, не крайна цел

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

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

Връзката между ИСО, GDPR, NIS2 и DORA

ИСО стандартите не отменят регулаторните задължения, но дават дисциплина за тяхното изпълнение. ISO 27001 подкрепя мерките по GDPR и подготовката за изискванията на NIS2 чрез управление на риска, контрол на достъпа, регистриране на събития и реакция при инциденти. ISO 22301 добавя проверима готовност за продължаване на критичните операции.

За финансови субекти и техни доставчици DORA поставя още по-ясен акцент върху управлението на ИКТ риска, тестването на устойчивостта и контрола върху трети страни. ISO 27001 не е автоматично доказателство за пълно съответствие с DORA, но значително улеснява изграждането на необходимата основа. Същият принцип важи и при EU AI Act: при използване на системи с изкуствен интелект са нужни допълнителни оценки и специфични контроли, извън общата система за информационна сигурност.

Как външният партньор прави системата работеща

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

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

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

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

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

Какво се прилага към октомври 2026 г.

EU AI Act се въвежда поетапно. От 2 февруари 2025 г. са приложими забраните за определени практики и изискването за достатъчно AI грамотност на служителите, които работят със системи с изкуствен интелект. От 2 август 2025 г. важат част от задълженията за доставчиците на модели с общо предназначение. Основната част от правилата, включително за високорисковите AI системи, започна да се прилага от 2 август 2026 г., като за определени високорискови системи, свързани с регулирани продукти, е предвиден по-късен срок.

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

Съответствие с EU AI Act започва с правилна класификация

Регламентът следва рисков подход. Не всяка система изисква едно и също ниво на контрол. Най-напред трябва да се установи дали конкретният инструмент действително попада в обхвата на AI Act и каква е ролята на вашата организация – доставчик, внедрител, вносител, дистрибутор или упълномощен представител. В повечето български предприятия организацията е внедрител, тоест използва решение, предоставено от външен доставчик.

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

Високорисковите случаи изискват значително повече дисциплина. Такива могат да бъдат системи за подбор и оценяване на служители, достъп до образование, кредитна оценка, оценка на застрахователен риск, определени решения в здравеопазването, критична инфраструктура или биометрична идентификация. Не е достатъчно доставчикът да твърди, че продуктът е „AI Act ready“. Организацията трябва да провери дали конкретната употреба, данните, настройките и процесът на човешки надзор са съвместими с приложимите изисквания.

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

Първата управленска задача: регистър на AI системите

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

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

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

Контролите, които трябва да работят на практика

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

Ефективната рамка обикновено включва следните елементи:

• определен собственик на AI системата и ясно разпределение на отговорностите между бизнес, IT, DPO и информационна сигурност;
• процедури за проверка на входните данни, откриване на отклонения и контрол на версиите на модела или доставчика;
• човешка проверка с реални правомощия за спиране, корекция или отмяна на автоматизиран резултат;
• дневници на събития, които позволяват да се проследи как е достигнат даден изход и кой е действал по него;
• процес за инциденти, жалби, периодична преоценка и своевременно информиране на доставчика при установен проблем.

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

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

Връзката с GDPR, NIS2 и вътрешните политики

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

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

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

Как да подготвите организацията без излишна бюрокрация

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

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

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

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

На 17 януари 2025 г. DORA започна да се прилага пряко в Европейския съюз. За засегнатите организации това означава, че DORA изисквания за финансови компании вече не са проект за бъдеща подготовка, а оперативен ангажимент към управлението, IT екипа, риска, вътрешния контрол и външните доставчици. Регламентът не се изчерпва с внедряване на нова система за сигурност. Той изисква доказуем модел, с който организацията предотвратява, открива, управлява и възстановява дейността си след ИКТ инцидент.

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

Кои организации попадат в обхвата на DORA

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

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

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

DORA изисквания за финансови компании: пет управленски области

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

1. Управление на ИКТ риска

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

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

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

2. Управление и докладване на ИКТ инциденти

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

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

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

3. Непрекъсваемост, архивиране и възстановяване

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

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

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

4. Тестване на цифровата оперативна устойчивост

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

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

5. Риск от външни ИКТ доставчици

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

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

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

Как да започне подготовката без формален подход

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

Практическият план обикновено следва пет последователни действия:

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

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

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

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

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

Оценката на въздействието върху защитата на данните, позната като DPIA от Data Protection Impact Assessment, не е формален документ, който се изготвя при поискване от надзорен орган. Тя е процес за предварително управление на риска. Целта е организацията да установи дали планираното обработване може да засегне сериозно хората, чиито данни използва, и да приложи мерки, преди рискът да се превърне в инцидент, жалба или санкция.

Кога се прави оценка на въздействието по GDPR

Съгласно чл. 35 от GDPR DPIA се извършва, когато даден вид обработване, особено при използване на нови технологии, е вероятно да създаде висок риск за правата и свободите на физическите лица. Решаващ е не размерът на организацията, а естеството, обхватът, контекстът и целите на обработването.

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

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

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

Сигнали, че рискът вероятно е висок

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

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

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

Случаи от ежедневната работа на бизнеса

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

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

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

Как се изготвя DPIA, която има практическа стойност

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

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

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

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

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

DPIA не е еднократен документ

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

Това е особено актуално при организации, които едновременно покриват GDPR, ISO 27001, NIS2 или секторни изисквания. Единна карта на активите, потоците от данни, рисковете и контролните мерки намалява дублирането между регистри, политики, оценки и одитни доказателства. Технологичната защита и документацията трябва да работят като една система, а не като отделни инициативи.

Какво следва при висок остатъчен риск

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

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

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

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

ISO/IEC 42001 е международен стандарт за система за управление на изкуствения интелект. Той е приложим както за организации, които разработват AI системи, така и за такива, които ги купуват, конфигурират или използват в ежедневната си работа. За малкия и средния бизнес това е практичен начин да се въведат ясни правила преди AI инструментите да се превърнат в неконтролиран канал за данни и решения.

Какъв проблем решава ISO 42001

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

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

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

Внедряване на ISO 42001 започва с реалната употреба

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

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

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

Оценка на риска, която води до действия

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

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

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

Контролите, които имат значение на практика

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

За повечето организации основните контроли включват регистър на AI системите, правила за допустими данни, процедура за одобряване на нова употреба и определени отговорници. Необходими са и изисквания към доставчиците: къде се обработват данните, използват ли се за обучение на модели, какви са сроковете за съхранение, има ли договорни гаранции за конфиденциалност и как се уведомява при инцидент.

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

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

Роли, документация и доказуемост

ISO 42001 изисква ръководството да поеме видима отговорност. Това не означава управителят да одобрява всеки отделен prompt. Означава да определи политика, допустим риск, ресурси и лица с конкретни правомощия.

В практиката е полезно да има собственик на AI управлението, който координира IT, информационна сигурност, DPO, правен екип и ръководители на бизнес процеси. При малки и средни предприятия тези роли често се съчетават. Тогава външен експертен партньор може да осигури методика, независим поглед и капацитет за документация, без организацията да изгражда голям специализиран екип.

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

Обучението не е формалност

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

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

От проект към работеща система

Внедряването обикновено преминава през анализ на пропуските спрямо ISO 42001, определяне на обхват, регистър и оценка на риска, въвеждане на контроли, обучение и проверка на ефективността. Времето зависи от броя на AI приложенията, чувствителността на данните и зрелостта на съществуващите ISO 27001, GDPR и NIS2 процеси.

Организация с ясна система за информационна сигурност ще надгради по-бързо, защото вече разполага с управление на риска, контрол на доставчици и реакция при инциденти. Ако такива процеси липсват, ISO 42001 може да бъде добър повод те да се изградят интегрирано, вместо да се създава изолирана AI документация.

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

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