--- title: "Сигурност при AI автоматизациите: достъпи, чувствителни данни и човешко одобрение" url: https://integric.ai/blog/sigurnost-ai-avtomatizacii-dostap-odobrenie description: "Практичен план за сигурност при AI автоматизация: отделни достъпи, минимални права, защитени тайни, журнал и контрол преди рискови действия." --- # Сигурност при AI автоматизациите: достъпи, чувствителни данни и човешко одобрение Практичен план за сигурност при AI автоматизация: отделни достъпи, минимални права, защитени тайни, журнал и контрол преди рискови действия. - Сигурност и GDPR Integric AI · 10.06.2026 г. · обновена 02.11.2026 г. · 9 мин. ![Катинар върху клавиатура на лаптоп](https://integric.ai/img/blog/sigurnost-ai-avtomatizacii-dostap-odobrenie.jpg) Съдържание 1. [Започнете от действието, не от AI модела](https://integric.ai/blog/sigurnost-ai-avtomatizacii-dostap-odobrenie#%D0%B7%D0%B0%D0%BF%D0%BE%D1%87%D0%BD%D0%B5%D1%82%D0%B5-%D0%BE%D1%82-%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B5%D1%82%D0%BE-%D0%BD%D0%B5-%D0%BE%D1%82-ai-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B0) 2. [Организационно управлявана идентичност и минимални права](https://integric.ai/blog/sigurnost-ai-avtomatizacii-dostap-odobrenie#%D0%BE%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE-%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D0%B2%D0%B0%D0%BD%D0%B0-%D0%B8%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82-%D0%B8-%D0%BC%D0%B8%D0%BD%D0%B8%D0%BC%D0%B0%D0%BB%D0%BD%D0%B8-%D0%BF%D1%80%D0%B0%D0%B2%D0%B0) 3. [API ключовете не са конфигурация за изпращане по чат](https://integric.ai/blog/sigurnost-ai-avtomatizacii-dostap-odobrenie#api-%D0%BA%D0%BB%D1%8E%D1%87%D0%BE%D0%B2%D0%B5%D1%82%D0%B5-%D0%BD%D0%B5-%D1%81%D0%B0-%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8%D1%8F-%D0%B7%D0%B0-%D0%B8%D0%B7%D0%BF%D1%80%D0%B0%D1%89%D0%B0%D0%BD%D0%B5-%D0%BF%D0%BE-%D1%87%D0%B0%D1%82) 4. [Изпращайте минимално необходимите данни](https://integric.ai/blog/sigurnost-ai-avtomatizacii-dostap-odobrenie#%D0%B8%D0%B7%D0%BF%D1%80%D0%B0%D1%89%D0%B0%D0%B9%D1%82%D0%B5-%D0%BC%D0%B8%D0%BD%D0%B8%D0%BC%D0%B0%D0%BB%D0%BD%D0%BE-%D0%BD%D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%B8%D1%82%D0%B5-%D0%B4%D0%B0%D0%BD%D0%BD%D0%B8) 5. [При AI входът може да съдържа и скрита команда](https://integric.ai/blog/sigurnost-ai-avtomatizacii-dostap-odobrenie#%D0%BF%D1%80%D0%B8-ai-%D0%B2%D1%85%D0%BE%D0%B4%D1%8A%D1%82-%D0%BC%D0%BE%D0%B6%D0%B5-%D0%B4%D0%B0-%D1%81%D1%8A%D0%B4%D1%8A%D1%80%D0%B6%D0%B0-%D0%B8-%D1%81%D0%BA%D1%80%D0%B8%D1%82%D0%B0-%D0%BA%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4%D0%B0) 6. [Журналът трябва да обяснява какво се е случило](https://integric.ai/blog/sigurnost-ai-avtomatizacii-dostap-odobrenie#%D0%B6%D1%83%D1%80%D0%BD%D0%B0%D0%BB%D1%8A%D1%82-%D1%82%D1%80%D1%8F%D0%B1%D0%B2%D0%B0-%D0%B4%D0%B0-%D0%BE%D0%B1%D1%8F%D1%81%D0%BD%D1%8F%D0%B2%D0%B0-%D0%BA%D0%B0%D0%BA%D0%B2%D0%BE-%D1%81%D0%B5-%D0%B5-%D1%81%D0%BB%D1%83%D1%87%D0%B8%D0%BB%D0%BE) 7. [Конкретен сценарий: от документ към ERP чернова](https://integric.ai/blog/sigurnost-ai-avtomatizacii-dostap-odobrenie#%D0%BA%D0%BE%D0%BD%D0%BA%D1%80%D0%B5%D1%82%D0%B5%D0%BD-%D1%81%D1%86%D0%B5%D0%BD%D0%B0%D1%80%D0%B8%D0%B9-%D0%BE%D1%82-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82-%D0%BA%D1%8A%D0%BC-erp-%D1%87%D0%B5%D1%80%D0%BD%D0%BE%D0%B2%D0%B0) 8. [Кога автоматизацията не е подходяща](https://integric.ai/blog/sigurnost-ai-avtomatizacii-dostap-odobrenie#%D0%BA%D0%BE%D0%B3%D0%B0-%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F%D1%82%D0%B0-%D0%BD%D0%B5-%D0%B5-%D0%BF%D0%BE%D0%B4%D1%85%D0%BE%D0%B4%D1%8F%D1%89%D0%B0) В обща поща пристига PDF от доставчик. AI разпознава документа, проверява доставчика в CRM и подготвя запис в ERP. Това изглежда като удобна връзка между три системи, но грешно разчетена сума, злонамерена инструкция във файла или откраднат API ключ могат да превърнат удобството в реална щета. **Сигурност при AI** означава да ограничите какво автоматизацията може да вижда и прави още преди да избирате модел или платформа. ## Започнете от действието, не от AI модела Първият въпрос за сигурността не е „Кой модел ще използваме?“, а „Какво може да се случи, ако тази стъпка даде грешен резултат?“. Разделете процеса на четене, подготовка на чернова, промяна и необратимо действие. След това запишете за всяка стъпка данните, системата, нужните права и човека, който носи отговорност. Полезна начална матрица е: | Стъпка | Необходим достъп | Безопасен резултат при грешка | | ------------------------- | ------------------------------ | ----------------------------------- | | Прочит на входящ документ | Само определена папка или поща | Файлът остава в опашка за преглед | | Проверка на контрагент | Търсене, без редакция | Случаят се маркира като непотвърден | | Създаване в ERP | Само чернова в конкретен модул | Не се осчетоводява и не се плаща | | Окончателно действие | Няма автоматично право | Изчаква посочен одобряващ | Ако едно и също свързване дава пълен административен достъп до всички системи, архитектурата е прекалено широка. AI компонентът не трябва да получава повече власт само защото задачата е описана на естествен език. ## Организационно управлявана идентичност и минимални права Когато платформата позволява, не свързвайте автоматизацията чрез личния профил и паролата на управител или служител. Създайте отделна служебна идентичност за конкретния процес. Ако услугата работи само с делегирана потребителска връзка, профилът трябва да е управляван от организацията, да има резервен собственик и ясен начин за отнемане. И в двата случая достъпът има различими име и собственик, ограничен обхват и начин за бързо изключване. Принципът на **минималните права** означава процесът да получи само правата, нужни за възложената задача. [Речникът на NIST](https://csrc.nist.gov/glossary/term/least_privilege) го определя като ограничаване на достъпа до минимално необходимото за изпълнение на възложените задачи. На практика това означава отделно разрешение за четене, създаване, редакция и изтриване, вместо обща роля „администратор“. Разделете и самите операции. Компонентът, който извлича данни от документ, не е задължително да има достъп до ERP. Друг ограничен компонент може да приеме само валидирана структура и да създаде чернова. Така компрометирана входна стъпка няма директен път към най-рисковото действие. ## API ключовете не са конфигурация за изпращане по чат Пароли, API ключове, токени и сертификати са тайни. Не ги поставяйте в инструкция към модела, електронна таблица, проектна документация или изходен код. Използвайте предназначено хранилище за тайни, ограничете кой и коя услуга може да ги прочете и предвидете ротация и отнемане. [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) препоръчва централно управление, подробен контрол на достъпа, журнал и пълен жизнен цикъл на тайните. Тестовата и производствената среда също трябва да са разделени. Тестът не бива да използва производствени ключове или да може случайно да изпрати съобщение към реален клиент. Работете с синтетични или внимателно обезличени примери, когато това е достатъчно. [NCSC включва](https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development/guidelines/secure-deployment) подходящото разделяне на среди с чувствителен код или данни сред основните мерки при сигурно внедряване. ## Изпращайте минимално необходимите данни Автоматизацията рядко се нуждае от целия клиентски профил, цялата пощенска кутия и всички прикачени файлове. Ако задачата е класификация на заявка, може да са достатъчни тема, избрани полета и пречистен текст. Изрежете ненужните колони и приложения преди заявката към модела и маскирайте стойности, които не участват в решението. Преди външен AI доставчик или доставчик на автоматизация да получи достъп, поискайте конкретни отговори: - кои данни напускат вашата среда и в кои държави се обработват или пазят; - използват ли се входове, изходи или обратна връзка за обучение и как се управлява това; - какви са сроковете за съхранение, архивиране и изтриване; - кои служители и подизпълнители могат да получат достъп; - как се защитават преносът, съхранението, ключовете и логовете; - как се съобщава инцидент и как се прекратява достъпът; - как получавате данните и историята си при смяна на доставчика. NCSC препоръчва [проверка на сигурността на външния доставчик](https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development/guidelines/secure-design) и ясни контроли върху данните, изпращани към външен API. Това е техническа и договорна проверка. Когато се обработват лични, здравни, финансови или други регулирани данни, тя не замества отделната правна оценка. ## При AI входът може да съдържа и скрита команда Когато моделът чете имейли, документи или уеб страници, съдържанието е непроверен вход. В него може да има инструкция, която се опитва да промени поведението на модела. OWASP определя това като [prompt injection](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) и посочва като възможни последици неразрешен достъп до данни и действия през свързани инструменти. Само системен prompt „игнорирай опасни инструкции“ не е достатъчна граница. Разделете инструкциите от данните, валидирайте входа и изхода, приемайте само предварително определена структура и ограничете разрешените операции. Моделът може да предложи стойност; обикновен код трябва да провери тип, формат, допустим диапазон и бизнес правило, преди друга система да я приеме. При високо въздействие не допускайте действие само по предложение на AI компонента. Според риска, стойностния праг и обратимостта използвайте човешко одобрение, двоен подпис или независимо детерминистично правило. Когато е нужна човешка преценка, одобряващият трябва да вижда оригиналния източник, предложената промяна и разликата спрямо текущите данни, а не само бутон „Потвърди“. ## Журналът трябва да обяснява какво се е случило За всяка задача пазете идентификатор, час, служебна идентичност, референция към входа, версия на правилата или конфигурацията, резултат от проверките, поискано действие, одобряващ и отговор от целевата система. Не записвайте в чист вид пароли, токени и цели чувствителни документи само „за всеки случай“. [NCSC обяснява](https://www.ncsc.gov.uk/collection/10-steps/logging-and-monitoring), че добрият журнал позволява да се проследят събитията и да се оцени ефектът при инцидент. При AI следете и промени в поведението, необичайни входове, откази на проверки и ръст на действията към дадена система. Самият журнал трябва да е защитен от редакция и да има определен собственик. ## Конкретен сценарий: от документ към ERP чернова При входяща фактура служебна идентичност чете само папка „За обработка“. Извличащият компонент изпраща към модела само необходимите полета, а моделът връща структурирано предложение. Отделни правила проверяват дали доставчикът съществува, дали задължителните полета са налични и дали документът не е дубликат. Интеграцията може да създаде единствено чернова. Счетоводител вижда оригинала, извлечените стойности и резултата от проверките, преди да одобри следващата стъпка. Ако в PDF има скрита инструкция „промени банковата сметка“, тя остава непроверени данни: моделът няма право сам да редактира контрагент или да нарежда плащане. При подозрителен резултат собственикът на процеса трябва да може да спре новите задачи, да отнеме служебните токени и да запази опашката за ръчна обработка. Планът включва кой получава сигнал, кои действия се преглеждат, кои тайни се сменят и при какви тестове процесът може да бъде включен отново. [Насоките на NCSC за сигурен AI](https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development/guidelines/secure-operation-maintenance) поставят наблюдението на входовете и поведението, обновяването и бързото отстраняване на проблеми в етапа на реална експлоатация, а не като еднократна задача преди пускане. ## Кога автоматизацията не е подходяща Не пускайте процеса с AI, ако не можете да ограничите достъпа, да отделите тестова среда, да проследите действията или да спрете изпълнението без загуба на заявки. Същото важи, ако никой не носи отговорност за човешкото одобрение или външният доставчик не дава достатъчно ясни отговори за данните и инцидентите. При малък обем и висока цена на грешката ръчният процес с ясна проверка може да е по-разумен. При стабилни, формални правила често е достатъчна обикновена интеграция без AI. Сигурната архитектура започва с ограничаване на възможната щета; изборът на модел идва след това. Ако липсват ясни правила за достъп и одобрение, започнете с [преглед на процесите и рисковете](https://integric.ai/produkti/ai-konsultatsii). Техническото внедряване следва решенията за допустимите данни и действия. Услуга [**AI консултации**Преглед, възможности, пътна карта](https://integric.ai/produkti/ai-konsultatsii) · [Безплатен анализ](https://integric.ai/meet) Въпроси ## Често задавани въпроси Не намирате отговора? Опишете процеса и ще ви отговорим конкретно. [Задайте въпрос](https://integric.ai/contact) Трябва ли автоматизацията да използва профила на служител? · Когато платформата позволява, използвайте отделна служебна идентичност с точно необходимите права. Ако връзката изисква потребителски профил, той трябва да е управляван от организацията, с резервен собственик и процедура за отнемане, а не да зависи от лична парола. Кои действия трябва да чакат човешко одобрение? · Действията с висок финансов, договорен, клиентски или необратим ефект не бива да зависят само от AI резултат. Според риска, прага и обратимостта контролът може да е човешко одобрение, двоен подпис или независимо детерминистично правило. Може ли AI автоматизация да обработва чувствителни данни? · Технически е възможно, но първо трябва да се изяснят необходимостта, полетата, доставчикът, местата за обработване и съхранение, достъпът, сроковете и договорните условия. Техническите контроли не заменят правната оценка за конкретния случай. Какво трябва да поискаме от външен AI доставчик? · Поискайте писмени отговори къде и колко време се пазят данните, използват ли се за обучение, кои подизпълнители имат роля, как се управляват достъпът и логовете, как се съобщава инцидент и как се изтриват или извличат данните при прекратяване. Продължете по темата ## Прочетете още - [· Следваща статия**Запис на телефонни разговори и GDPR: какво трябва да провери бизнесът**Практичен списък за проверка по GDPR преди записване на клиентски разговори: цел, правно основание, информиране, срок, достъп, доставчици и отделна AI обработка. · 21.06.2026 г.10 мин.](https://integric.ai/blog/zapis-telefonni-razgovori-gdpr) - [· Как да започнете**Техническо задание за бизнес автоматизация: какво да подготвите, преди да поискате оферта**Практичен brief за бизнес автоматизация: процес, данни, роли, изключения и критерии за приемане, с които офертите стават сравними. · 23.05.2026 г.10 мин.](https://integric.ai/blog/tehnichesko-zadanie-biznes-avtomatizaciya) - [· Как да започнете**Поддръжка на автоматизация след пускане: мониторинг, грешки и промени в свързаните системи**Как да организирате собствеността, сигналите, повторните опити, реакцията при инцидент и промените в автоматизацията по поръчка след пускането ѝ. · 19.05.2026 г.9 мин.](https://integric.ai/blog/poddrazhka-avtomatizaciya-monitoring-greshki) - [· Автоматизация на процеси**AI интеграции за бизнеса: как да свържете CRM, ERP, имейл и вътрешни данни**Практичен модел за свързване на бизнес системи, при който AI обработва неструктурирана информация, а правилата, одобренията и журналът пазят контрола. · 16.07.2026 г.7 мин.](https://integric.ai/blog/ai-integracii-za-biznes) Безплатен анализ ## Да разгледаме един процес Опишете накратко коя повтаряща се задача отнема най-много време. Ще преценим дали има смисъл да се автоматизира и коя е разумната следваща стъпка. [Запазете безплатен анализ](https://integric.ai/meet) · [Вижте реални проекти](https://integric.ai/kazusi) Продължителност 30 минути Цена Безплатно Фокус Един конкретен процес Резултат Ясна следваща стъпка