Оперативният проблем: AI вече е вътре, но никой не вижда цялата картина
Екипът използва AI за протоколи от срещи, чернови на оферти, класификация на support заявки и първи screening на кандидати. Част от функциите са купени като отделни инструменти, други са включени в CRM, имейл или управление на проекти абонамента. Обикновено няма общ списък, няма отговорник и няма доказателство кой е проверил риска. Това е реалният compliance проблем за малката компания: не липса на още една обща политика, а невидима употреба.
AI Act стана широко приложим на 2 август 2026 г., но сроковете не са еднакви за всички изисквания. Забранените практики и AI literacy се прилагат от 2 февруари 2025 г. Article 50 transparency obligations се прилагат от 2 август 2026 г. След Digital Omnibus правилата за high-risk случаи на употреба в Annex III се прилагат от 2 декември 2027 г., а тези за AI в регулирани продукти от Annex I — от 2 август 2028 г.
Не превръщайте тези по-късни срокове в причина да отложите inventory-то. Без списък на случаи на употреба не можете да определите дали сте deployer или provider, дали има забранена практика, transparency duty, обработване на лични данни или потенциален high-risk сценарий. Следващият контролен списък е управленска отправна точка, не правно становище. При HR, биометрия, здраве, кредитиране, критична инфраструктура или спорна класификация включете квалифициран юрист и съответния орган.
Compliance започва с видимост: AI system + конкретен случай на употреба + отговорник + данни + засегнати хора + решение.
Първо определете ролята: deployer, provider или и двете
Deployer е организацията, която използва AI system под своя отговорност в професионална дейност. Служителите, които работят под контрола на компанията, обикновено не са отделни deployers. Provider е организацията, която разработва система или възлага разработката ѝ и я пуска на пазара или в употреба под свое име или търговска марка. Една SME може да е deployer за купен meeting assistant и provider за white-label chatbot, който предлага на клиентите като собствен продукт.
Ролята се определя за всеки случай на употреба, не веднъж за цялата компания. Запишете производителя, договора, брандирането, кой контролира системата, кой задава предназначението и кой вижда output-а. Ако променяте предназначението или поставяте системата под собствено име, не приемайте автоматично, че оставате само deployer.
Article 50 също разделя задълженията. Providers на директно интерактивни AI systems трябва да проектират информирането на хората, а providers на generative systems носят задължения за machine-readable marking. Deployers имат конкретни задължения при emotion recognition, biometric categorisation, deepfakes и AI-generated или manipulated текст по въпроси от обществен интерес без human преглед или editorial control. За собствен chatbot проверете и двете роли с доставчика, вместо да приемате, че една бележка в privacy policy решава всичко.
| Въпрос | Ако отговорът е „да“ | Следваща проверка |
|---|---|---|
| Използваме готов AI инструмент в ежедневната работа? | Вероятно сме deployer | Предназначение, данни, засегнати хора, instructions for use |
| Предлагаме системата под собствено име или марка? | Възможна provider роля | Договор, техническа документация, Article 50 и останалите provider duties |
| Променили сме предназначението или high-risk поведението? | Ролята може да се промени | Правна и техническа оценка преди пускане |
| AI общува директно с хора или създава публично съдържание? | Има transparency тригер | Кой уведомява, маркира, преглежда и пази evidence |
| AI влияе върху наемане, кредит, достъп до услуга или друг чувствителен процес? | Възможен high-risk случай на употреба | Annex III triage и квалифициран преглед |
Седемстъпков контролен списък за SME deployer
1. Направете AI inventory по случай на употреба
Запишете инструмента и вградените AI функции, отговорник, доставчик, версия или план, цел, входни данни, output, засегнати хора, човешко решение и дата за преглед. Включете личните акаунти и browser extensions, но премахнете или управлявайте неразрешените, вместо просто да ги описвате.
2. Определете роля и приложими правила
За всеки ред маркирайте deployer, possible provider или needs преглед. Направете първоначален screen за prohibited practices, transparency, potential high-risk и други приложими режими. Не използвайте общ етикет „low risk“ без записана причина.
3. Проверете данните и доставчика
Опишете лични, поверителни и клиентски данни; правно основание, срок на съхранение, training use, sub-processors, hosting, експорт и 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 да няма нормативно зададено конкретно „достатъчно“ ниво. Обучението трябва да е различно за обикновен потребител, проверяващ, system отговорник и технически администратор.
7. Поддържайте evidence trail и преглед cadence
Пазете inventory history, одобрения, vendor evidence, training records, incidents, overrides и промени. Комисията не изисква специален AI literacy сертификат; вътрешен запис на обученията и инициативите може да бъде част от доказателствата. Преглеждайте критичните случаи на употреба на тримесечие и при всяка значима промяна.
Triage таблица: пет типични SME случаи на употреба
Таблицата е първоначален routing инструмент, не окончателна правна класификация. Един и същ продукт може да носи различен риск според контекста, хората, данните и решението, което подпомага. Когато случай на употреба е чувствителен, не го пускайте само защото доставчикът описва продукта като compliant.
| Use case | Първоначален сигнал | Минимален контрол | Решение |
|---|---|---|---|
| Public customer chatbot | Direct interaction; проверете кой е provider | Ясно уведомление, escalation към човек, журнали и vendor evidence | Пуснете след transparency и data преглед |
| Meeting summary за вътрешна среща | Често limited/minimal risk, но може да има лични или поверителни данни | Approved account, participant notice според контекста, срок на съхранение и human correction | Контролиран pilot |
| Ranking на кандидати за работа | Employment е чувствителна Annex III област; срокът за high-risk rules е по-късен, но рискът е реален сега | Правен преглед, bias testing, human decision, applicant information и следа за одит | Не пускане-вайте като автоматично решение |
| AI marketing image или deepfake | Article 50 labelling може да се приложи | Проверка на provider marking, видим label, brand/copyright/fact преглед | Публикувайте само след documented преглед |
| Извличане на полета от фактура | Оперативна помощ; финансовата грешка остава при бизнеса | Confidence threshold, sample testing, одобрение преди осчетоводяване или плащане | Подходящ ограничен pilot |
Не класифицирайте само продукта. Класифицирайте конкретното предназначение, данните, засегнатите хора и бизнес решението.
Как изглежда минималният AI register
Започнете в контролирана таблица или регистър, която е достъпна за операции, IT/security, privacy и съответния отговорник от бизнеса. Не е нужен нов governance продукт. Нужни са едни и същи задължителни полета, промяна с отговорник и връзка към доказателствата.
Един ред описва един случай на употреба. Ако използвате един и същ модел за 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 | Одобрение и контакт за escalation |
| Data + people | Входни данни, лични данни, засегнати групи, recipients | Data map, DPIA/LIA когато е приложимо |
| Risk screen | Prohibited, transparency, potential high-risk, other regulation | Кратка причина и проверяващ |
| 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. По-добре е да спрете един случай на употреба за пет дни, отколкото да го оставите без отговорник, докато пишете обща политика за следващото тримесечие.
Свържете inventory-то с процесите, а не само с IT asset list. AI, който обобщава среща, може да изглежда като productivity инструмент, но ако summary-то автоматично променя CRM и задейства оферта, той участва в клиентския процес и контролът трябва да покрива целия работен процес.
| Период | Работа | Definition of done |
|---|---|---|
| Дни 1–5 | Извадете AI functions от expense list, SSO/admin panel, browser extensions и интервюта с екипа | Списъкът включва sanctioned и shadow AI случаи на употреба |
| Дни 6–10 | Групирайте по цел, данни, засегнати хора и decision impact | Всеки ред има отговорник и първоначална роля |
| Дни 11–15 | Направете prohibited, transparency, high-risk и data screen | Неясните случаи са спрени или изпратени за specialist преглед |
| Дни 16–20 | Добавете human преглед, access, logging, резервен вариант и transparency controls | За активните системи има документиран control отговорник |
| Дни 21–25 | Проведете ролево обучение с реални примери | Потребителите знаят allowed data, преглед и escalation |
| Дни 26–30 | Тествайте sample cases, затворете gaps и одобрете преглед cadence | Management sign-off, evidence folder и next-review dates |
Примерен разбор: 25-членна B2B service компания
Представете си измислена, но реалистична компания с 25 души. Мениджърът смята, че има три AI инструмента: общ chatbot, meeting assistant и Canva. Петдневното inventory открива девет случаи на употреба, защото CRM има AI имейл чернови, ATS предлага candidate ranking, support inbox класифицира заявки, а двама служители използват лични browser extensions.
Екипът не купува governance platform. Създава register с девет реда и назначава операции потенциален клиент за координатор. Candidate ranking се pause-ва за specialist преглед. Личните extensions се премахват, докато няма approved account и data controls. Meeting summaries остават в pilot с срок на съхранение, списък на участниците и човешка корекция. Support classification остава активна, но не може да затваря ticket или да изпраща отговор без човек.
Public chatbot-ът получава ясно уведомление от началото на взаимодействието, human handoff и запис на vendor evidence. Marketing екипът добавя преглед за synthetic visuals и label, когато Article 50 го изисква. Всички потребители минават кратък common module; HR, marketing и reviewers получават отделни сценарии. След 30 дни компанията няма „сертификат за compliance“. Има нещо по-полезно за управлението: видими случаи на употреба, отговорни хора, спряна рискова употреба и проверими решения.
Примерът не доказва правна класификация или резултат за конкретна фирма. Той показва как малък екип може да превърне широк регламент в последователна оперативна работа.
Целта за първите 30 дни не е финална compliance декларация. Целта е да няма неизвестен AI случай на употреба без отговорник и следващо решение.
Какво да не правите
- Не копирайте 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, случай на употреба и работен процес се променят.
Следващото управленско решение
Ако нямате пълен AI inventory, не започвайте с въпроса „съвместими ли сме?“. Започнете с работна среща от 90 минути: systems map, деветте задължителни полета, отговорници и три статуса. До края трябва да знаете какво е активно, какво се pause-ва и кои случаи изискват специалист.
1→10 може да включи AI portfolio mapping в Systems Audit: свързваме случаи на употреба с процесите и данните, откриваме shadow AI, определяме controls и подреждаме 30-дневен implementation backlog. Правната квалификация остава при вашия юрист или компетентния орган; нашата роля е да превърнем решенията в работещи системи, отговорници и 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