Оперативният проблем: AI вече е вътре, но никой не вижда цялата картина
Екипът използва AI за протоколи от срещи, чернови на оферти, класификация на support заявки и първи screening на кандидати. Част от функциите са купени като отделни инструменти, други са включени в CRM, email или project management абонамента. Обикновено няма общ списък, няма owner и няма доказателство кой е проверил риска. Това е реалният compliance проблем за малката компания: не липса на още една обща политика, а невидима употреба.
AI Act стана широко приложим на 2 август 2026 г., но сроковете не са еднакви за всички изисквания. Забранените практики и AI literacy се прилагат от 2 февруари 2025 г. Article 50 transparency obligations се прилагат от 2 август 2026 г. След Digital Omnibus правилата за high-risk use cases в Annex III се прилагат от 2 декември 2027 г., а тези за AI в регулирани продукти от Annex I — от 2 август 2028 г.
Не превръщайте тези по-късни срокове в причина да отложите inventory-то. Без списък на use cases не можете да определите дали сте deployer или provider, дали има забранена практика, transparency duty, обработване на лични данни или потенциален high-risk сценарий. Следващият checklist е управленска отправна точка, не правно становище. При HR, биометрия, здраве, кредитиране, критична инфраструктура или спорна класификация включете квалифициран юрист и съответния орган.
Compliance започва с видимост: AI system + конкретен use case + owner + данни + засегнати хора + решение.
Първо определете ролята: deployer, provider или и двете
Deployer е организацията, която използва AI system под своя отговорност в професионална дейност. Служителите, които работят под контрола на компанията, обикновено не са отделни deployers. Provider е организацията, която разработва система или възлага разработката ѝ и я пуска на пазара или в употреба под свое име или търговска марка. Една SME може да е deployer за купен meeting assistant и provider за white-label chatbot, който предлага на клиентите като собствен продукт.
Ролята се определя за всеки use case, не веднъж за цялата компания. Запишете производителя, договора, брандирането, кой контролира системата, кой задава предназначението и кой вижда output-а. Ако променяте предназначението или поставяте системата под собствено име, не приемайте автоматично, че оставате само deployer.
Article 50 също разделя задълженията. Providers на директно интерактивни AI systems трябва да проектират информирането на хората, а providers на generative systems носят задължения за machine-readable marking. Deployers имат конкретни задължения при emotion recognition, biometric categorisation, deepfakes и AI-generated или manipulated текст по въпроси от обществен интерес без human review или editorial control. За собствен chatbot проверете и двете роли с доставчика, вместо да приемате, че една бележка в privacy policy решава всичко.
| Въпрос | Ако отговорът е „да“ | Следваща проверка |
|---|---|---|
| Използваме готов AI tool в ежедневната работа? | Вероятно сме deployer | Предназначение, данни, засегнати хора, instructions for use |
| Предлагаме системата под собствено име или марка? | Възможна provider роля | Договор, техническа документация, Article 50 и останалите provider duties |
| Променили сме предназначението или high-risk поведението? | Ролята може да се промени | Правна и техническа оценка преди launch |
| AI общува директно с хора или създава публично съдържание? | Има transparency trigger | Кой уведомява, маркира, преглежда и пази evidence |
| AI влияе върху наемане, кредит, достъп до услуга или друг чувствителен процес? | Възможен high-risk use case | Annex III triage и квалифициран review |
Седемстъпков checklist за SME deployer
1. Направете AI inventory по use case
Запишете tool-а и вградените AI функции, owner, доставчик, версия или план, цел, входни данни, output, засегнати хора, човешко решение и дата за review. Включете личните акаунти и browser extensions, но премахнете или управлявайте неразрешените, вместо просто да ги описвате.
2. Определете роля и приложими правила
За всеки ред маркирайте deployer, possible provider или needs review. Направете първоначален screen за prohibited practices, transparency, potential high-risk и други приложими режими. Не използвайте общ етикет „low risk“ без записана причина.
3. Проверете данните и доставчика
Опишете лични, поверителни и клиентски данни; правно основание, retention, training use, sub-processors, hosting, export и deletion. GDPR продължава да се прилага независимо от AI Act. Изисквайте договорни отговори и admin controls, не обещания от sales page.
4. Поставете human oversight там, където грешката има цена
Назовете кой преглежда output-а, по какъв критерий, кога може да override-не и кога спира системата. Плащане, отказ, публикуване, HR решение или промяна на core record не трябва да остава необратима автономна стъпка без обоснован контрол.
5. Изпълнете transparency duty
Проверете дали хората трябва да бъдат уведомени, дали content трябва да бъде маркиран и дали доставчикът предоставя необходимите machine-readable средства. Запазете текстовете, screenshots, версията на интерфейса и отговорността за актуализация.
6. Обучете хората според ролята им
Article 4 запазва задължението providers и deployers да подкрепят AI literacy, макар след Omnibus да няма нормативно зададено конкретно „достатъчно“ ниво. Обучението трябва да е различно за обикновен потребител, reviewer, system owner и технически администратор.
7. Поддържайте evidence trail и review cadence
Пазете inventory history, approvals, vendor evidence, training records, incidents, overrides и промени. Комисията не изисква специален AI literacy сертификат; вътрешен запис на обученията и инициативите може да бъде част от доказателствата. Преглеждайте критичните use cases на тримесечие и при всяка значима промяна.
Triage таблица: пет типични SME use cases
Таблицата е първоначален routing инструмент, не окончателна правна класификация. Един и същ продукт може да носи различен риск според контекста, хората, данните и решението, което подпомага. Когато use case е чувствителен, не го пускайте само защото доставчикът описва продукта като compliant.
| Use case | Първоначален сигнал | Минимален контрол | Решение |
|---|---|---|---|
| Public customer chatbot | Direct interaction; проверете кой е provider | Ясно уведомление, escalation към човек, logs и vendor evidence | Пуснете след transparency и data review |
| Meeting summary за вътрешна среща | Често limited/minimal risk, но може да има лични или поверителни данни | Approved account, participant notice според контекста, retention и human correction | Контролиран pilot |
| Ranking на кандидати за работа | Employment е чувствителна Annex III област; срокът за high-risk rules е по-късен, но рискът е реален сега | Правен review, bias testing, human decision, applicant information и audit trail | Не launch-вайте като автоматично решение |
| AI marketing image или deepfake | Article 50 labelling може да се приложи | Проверка на provider marking, видим label, brand/copyright/fact review | Публикувайте само след documented review |
| Извличане на полета от фактура | Оперативна помощ; финансовата грешка остава при бизнеса | Confidence threshold, sample testing, approval преди осчетоводяване или плащане | Подходящ ограничен pilot |
Не класифицирайте само продукта. Класифицирайте конкретното предназначение, данните, засегнатите хора и бизнес решението.
Как изглежда минималният AI register
Започнете в контролирана таблица или database, която е достъпна за operations, IT/security, privacy и съответния business owner. Не е нужен нов governance продукт. Нужни са едни и същи задължителни полета, промяна с owner и връзка към доказателствата.
Един ред описва един use case. Ако използвате един и същ модел за support triage и screening на кандидати, това са два реда, защото целта, данните, засегнатите хора и рискът са различни. Поле „ChatGPT“ без контекст не е inventory.
| Поле | Какво записвате | Evidence |
|---|---|---|
| System + use case | Име, функция, intended purpose и business process | URL, contract или screenshot на конфигурацията |
| Owner + role | Business owner, technical owner, deployer/provider triage | Approval и контакт за escalation |
| Data + people | Входни данни, лични данни, засегнати групи, recipients | Data map, DPIA/LIA когато е приложимо |
| Risk screen | Prohibited, transparency, potential high-risk, other regulation | Кратка причина и reviewer |
| Controls | Human review, access, logging, thresholds, fallback | Test results, SOP и screenshots |
| Training | Кои роли са обучени и за какво | Attendance, materials и дата |
| Lifecycle | Launch, last review, vendor/model change, next review, retirement | Change log и decision record |
30-дневен план: от shadow AI до контролиран портфейл
Не оставяйте спорните системи да работят по инерция. Използвайте три статуса: approved with controls, paused pending evidence и retired. По-добре е да спрете един use case за пет дни, отколкото да го оставите без owner, докато пишете обща политика за следващото тримесечие.
Свържете inventory-то с процесите, а не само с IT asset list. AI, който обобщава среща, може да изглежда като productivity tool, но ако summary-то автоматично променя CRM и задейства оферта, той участва в клиентския процес и контролът трябва да покрива целия workflow.
| Период | Работа | Definition of done |
|---|---|---|
| Дни 1–5 | Извадете AI functions от expense list, SSO/admin panel, browser extensions и интервюта с екипа | Списъкът включва sanctioned и shadow AI use cases |
| Дни 6–10 | Групирайте по цел, данни, засегнати хора и decision impact | Всеки ред има owner и първоначална роля |
| Дни 11–15 | Направете prohibited, transparency, high-risk и data screen | Неясните случаи са спрени или изпратени за specialist review |
| Дни 16–20 | Добавете human review, access, logging, fallback и transparency controls | За активните системи има документиран control owner |
| Дни 21–25 | Проведете ролево обучение с реални примери | Потребителите знаят allowed data, review и escalation |
| Дни 26–30 | Тествайте sample cases, затворете gaps и одобрете review cadence | Management sign-off, evidence folder и next-review dates |
Worked example: 25-членна B2B service компания
Представете си измислена, но реалистична компания с 25 души. Мениджърът смята, че има три AI инструмента: общ chatbot, meeting assistant и Canva. Петдневното inventory открива девет use cases, защото CRM има AI email drafts, ATS предлага candidate ranking, support inbox класифицира заявки, а двама служители използват лични browser extensions.
Екипът не купува governance platform. Създава register с девет реда и назначава operations lead за координатор. Candidate ranking се pause-ва за specialist review. Личните extensions се премахват, докато няма approved account и data controls. Meeting summaries остават в pilot с retention, списък на участниците и човешка корекция. Support classification остава активна, но не може да затваря ticket или да изпраща отговор без човек.
Public chatbot-ът получава ясно уведомление от началото на взаимодействието, human handoff и запис на vendor evidence. Marketing екипът добавя review за synthetic visuals и label, когато Article 50 го изисква. Всички потребители минават кратък common module; HR, marketing и reviewers получават отделни сценарии. След 30 дни компанията няма „сертификат за compliance“. Има нещо по-полезно за управлението: видими use cases, отговорни хора, спряна рискова употреба и проверими решения.
Примерът не доказва правна класификация или резултат за конкретна фирма. Той показва как малък екип може да превърне широк регламент в последователна оперативна работа.
Целта за първите 30 дни не е финална compliance декларация. Целта е да няма неизвестен AI use case без owner и следващо решение.
Какво да не правите
- Не копирайте generic AI policy и не я приемайте за inventory, risk assessment или обучение.
- Не разчитайте на vendor badge „EU AI Act compliant“ без да проверите вашата роля, конфигурация и предназначение.
- Не приемайте, че human-in-the-loop е достатъчен, ако човекът няма време, критерий, право на override или достъп до източника.
- Не смесвайте AI literacy с еднократна презентация. Обучете различните роли върху реалните системи, данни и incidents.
- Не чакайте high-risk срока, за да разберете, че HR или друг чувствителен процес използва AI.
- Не третирайте AI Act като заместител на GDPR, consumer protection, copyright, трудово или секторно право.
- Не пазете register като статичен файл. Vendor, model, use case и workflow се променят.
Следващото управленско решение
Ако нямате пълен AI inventory, не започвайте с въпроса „съвместими ли сме?“. Започнете с работна среща от 90 минути: systems map, деветте задължителни полета, owners и три статуса. До края трябва да знаете какво е активно, какво се pause-ва и кои случаи изискват специалист.
1→10 може да включи AI portfolio mapping в Systems Audit: свързваме use cases с процесите и данните, откриваме shadow AI, определяме controls и подреждаме 30-дневен implementation backlog. Правната квалификация остава при вашия юрист или компетентния орган; нашата роля е да превърнем решенията в работещи системи, owners и evidence.
Източници и допълнително четене
Функциите на продуктите се променят. Източниците по-долу са първични или официални и са прегледани при публикуването на ръководството.
- EUR-Lex: Regulation (EU) 2024/1689 — Artificial Intelligence Act
- European Commission: AI Act overview and application timeline
- European Commission: Guidelines on Article 50 transparency obligations
- European Commission: Article 50 transparency questions and answers
- European Commission: AI literacy questions and answers
- EDPB: Opinion on AI models and GDPR principles