В обща поща пристига PDF от доставчик. AI разпознава документа, проверява доставчика в CRM и подготвя запис в ERP. Това изглежда като удобна връзка между три системи, но грешно разчетена сума, злонамерена инструкция във файла или откраднат API ключ могат да превърнат удобството в реална щета. Сигурност при AI означава да ограничите какво автоматизацията може да вижда и прави още преди да избирате модел или платформа.
Започнете от действието, не от AI модела
Първият въпрос за сигурността не е „Кой модел ще използваме?“, а „Какво може да се случи, ако тази стъпка даде грешен резултат?“. Разделете процеса на четене, подготовка на чернова, промяна и необратимо действие. След това запишете за всяка стъпка данните, системата, нужните права и човека, който носи отговорност.
Полезна начална матрица е:
| Стъпка | Необходим достъп | Безопасен резултат при грешка |
|---|---|---|
| Прочит на входящ документ | Само определена папка или поща | Файлът остава в опашка за преглед |
| Проверка на контрагент | Търсене, без редакция | Случаят се маркира като непотвърден |
| Създаване в ERP | Само чернова в конкретен модул | Не се осчетоводява и не се плаща |
| Окончателно действие | Няма автоматично право | Изчаква посочен одобряващ |
Ако едно и също свързване дава пълен административен достъп до всички системи, архитектурата е прекалено широка. AI компонентът не трябва да получава повече власт само защото задачата е описана на естествен език.
Организационно управлявана идентичност и минимални права
Когато платформата позволява, не свързвайте автоматизацията чрез личния профил и паролата на управител или служител. Създайте отделна служебна идентичност за конкретния процес. Ако услугата работи само с делегирана потребителска връзка, профилът трябва да е управляван от организацията, да има резервен собственик и ясен начин за отнемане. И в двата случая достъпът има различими име и собственик, ограничен обхват и начин за бързо изключване.
Принципът на минималните права означава процесът да получи само правата, нужни за възложената задача. Речникът на NIST го определя като ограничаване на достъпа до минимално необходимото за изпълнение на възложените задачи. На практика това означава отделно разрешение за четене, създаване, редакция и изтриване, вместо обща роля „администратор“.
Разделете и самите операции. Компонентът, който извлича данни от документ, не е задължително да има достъп до ERP. Друг ограничен компонент може да приеме само валидирана структура и да създаде чернова. Така компрометирана входна стъпка няма директен път към най-рисковото действие.
API ключовете не са конфигурация за изпращане по чат
Пароли, API ключове, токени и сертификати са тайни. Не ги поставяйте в инструкция към модела, електронна таблица, проектна документация или изходен код. Използвайте предназначено хранилище за тайни, ограничете кой и коя услуга може да ги прочете и предвидете ротация и отнемане. OWASP Secrets Management Cheat Sheet препоръчва централно управление, подробен контрол на достъпа, журнал и пълен жизнен цикъл на тайните.
Тестовата и производствената среда също трябва да са разделени. Тестът не бива да използва производствени ключове или да може случайно да изпрати съобщение към реален клиент. Работете с синтетични или внимателно обезличени примери, когато това е достатъчно. NCSC включва подходящото разделяне на среди с чувствителен код или данни сред основните мерки при сигурно внедряване.
Изпращайте минимално необходимите данни
Автоматизацията рядко се нуждае от целия клиентски профил, цялата пощенска кутия и всички прикачени файлове. Ако задачата е класификация на заявка, може да са достатъчни тема, избрани полета и пречистен текст. Изрежете ненужните колони и приложения преди заявката към модела и маскирайте стойности, които не участват в решението.
Преди външен AI доставчик или доставчик на автоматизация да получи достъп, поискайте конкретни отговори:
- кои данни напускат вашата среда и в кои държави се обработват или пазят;
- използват ли се входове, изходи или обратна връзка за обучение и как се управлява това;
- какви са сроковете за съхранение, архивиране и изтриване;
- кои служители и подизпълнители могат да получат достъп;
- как се защитават преносът, съхранението, ключовете и логовете;
- как се съобщава инцидент и как се прекратява достъпът;
- как получавате данните и историята си при смяна на доставчика.
NCSC препоръчва проверка на сигурността на външния доставчик и ясни контроли върху данните, изпращани към външен API. Това е техническа и договорна проверка. Когато се обработват лични, здравни, финансови или други регулирани данни, тя не замества отделната правна оценка.
При AI входът може да съдържа и скрита команда
Когато моделът чете имейли, документи или уеб страници, съдържанието е непроверен вход. В него може да има инструкция, която се опитва да промени поведението на модела. OWASP определя това като prompt injection и посочва като възможни последици неразрешен достъп до данни и действия през свързани инструменти.
Само системен prompt „игнорирай опасни инструкции“ не е достатъчна граница. Разделете инструкциите от данните, валидирайте входа и изхода, приемайте само предварително определена структура и ограничете разрешените операции. Моделът може да предложи стойност; обикновен код трябва да провери тип, формат, допустим диапазон и бизнес правило, преди друга система да я приеме.
При високо въздействие не допускайте действие само по предложение на AI компонента. Според риска, стойностния праг и обратимостта използвайте човешко одобрение, двоен подпис или независимо детерминистично правило. Когато е нужна човешка преценка, одобряващият трябва да вижда оригиналния източник, предложената промяна и разликата спрямо текущите данни, а не само бутон „Потвърди“.
Журналът трябва да обяснява какво се е случило
За всяка задача пазете идентификатор, час, служебна идентичност, референция към входа, версия на правилата или конфигурацията, резултат от проверките, поискано действие, одобряващ и отговор от целевата система. Не записвайте в чист вид пароли, токени и цели чувствителни документи само „за всеки случай“.
NCSC обяснява, че добрият журнал позволява да се проследят събитията и да се оцени ефектът при инцидент. При AI следете и промени в поведението, необичайни входове, откази на проверки и ръст на действията към дадена система. Самият журнал трябва да е защитен от редакция и да има определен собственик.
Конкретен сценарий: от документ към ERP чернова
При входяща фактура служебна идентичност чете само папка „За обработка“. Извличащият компонент изпраща към модела само необходимите полета, а моделът връща структурирано предложение. Отделни правила проверяват дали доставчикът съществува, дали задължителните полета са налични и дали документът не е дубликат.
Интеграцията може да създаде единствено чернова. Счетоводител вижда оригинала, извлечените стойности и резултата от проверките, преди да одобри следващата стъпка. Ако в PDF има скрита инструкция „промени банковата сметка“, тя остава непроверени данни: моделът няма право сам да редактира контрагент или да нарежда плащане.
При подозрителен резултат собственикът на процеса трябва да може да спре новите задачи, да отнеме служебните токени и да запази опашката за ръчна обработка. Планът включва кой получава сигнал, кои действия се преглеждат, кои тайни се сменят и при какви тестове процесът може да бъде включен отново. Насоките на NCSC за сигурен AI поставят наблюдението на входовете и поведението, обновяването и бързото отстраняване на проблеми в етапа на реална експлоатация, а не като еднократна задача преди пускане.
Кога автоматизацията не е подходяща
Не пускайте процеса с AI, ако не можете да ограничите достъпа, да отделите тестова среда, да проследите действията или да спрете изпълнението без загуба на заявки. Същото важи, ако никой не носи отговорност за човешкото одобрение или външният доставчик не дава достатъчно ясни отговори за данните и инцидентите.
При малък обем и висока цена на грешката ръчният процес с ясна проверка може да е по-разумен. При стабилни, формални правила често е достатъчна обикновена интеграция без AI. Сигурната архитектура започва с ограничаване на възможната щета; изборът на модел идва след това.
Ако липсват ясни правила за достъп и одобрение, започнете с преглед на процесите и рисковете. Техническото внедряване следва решенията за допустимите данни и действия.
