Най-важното
- Класифицирайте данните и разрешените AI сценарии.
- Проверете договорите, retention и използването на данни от доставчика.
- Прилагайте least privilege и permission-aware retrieval.
- Логвайте необходимото, без да създавате второ хранилище за чувствителни данни.
Първо решете какви данни могат да се използват
Разделете информацията поне на публична, вътрешна, поверителна и строго ограничена. За всяка категория определете допустими инструменти, цели, потребители и нужда от одобрение.
Политиката трябва да дава работеща алтернатива. Ако служителите нямат одобрен инструмент, чувствителните процеси лесно се преместват в неконтролирани лични акаунти.
Проверете доставчика и договорния модел
- Използват ли се входовете и изходите за обучение?
- Къде се обработват и съхраняват данните?
- Какъв е срокът за съхранение и може ли да бъде ограничен?
- Как се управляват subprocessors и инциденти?
- Има ли enterprise identity, audit logs и администраторски контроли?
- Как се изтриват и експортират данните при прекратяване?
Минимални права за хора и приложения
AI приложението не трябва да получава по-широк достъп от необходимото. Използвайте SSO, role-based access, отделни service identities и краткотрайни credentials.
Когато потребител търси във фирмена база, резултатите трябва да отразяват неговите права в източника. Един общ индекс без permission filtering може да превърне AI в канал за изтичане между отдели.
Защита на входа и изхода
DLP и redaction могат да откриват лични данни, финансови идентификатори, тайни и други забранени стойности преди изпращане. Изходът също трябва да бъде проверяван според контекста и получателя.
Тези контроли не са безпогрешни. Комбинирайте ги с ограничаване на източниците, ясни правила и човешко одобрение при чувствителни задачи.
RAG не отменя правилата за сигурност
RAG позволява моделът да използва фирмено знание без обучение върху него, но създава нови компоненти: ingestion, индекс, embeddings, cache и логове. Всеки от тях трябва да има собственост, encryption, retention и access policy.
Retrieved content се третира като недоверен вход. Документ може да съдържа злонамерени инструкции, затова tool permissions и policy layer не трябва да зависят само от prompt.
Logging без прекомерно събиране
Нужни са следи за потребител, източници, версии, решения, tool calls и одобрения. Но пълният prompt и всеки документ не трябва автоматично да се пазят завинаги.
Прилагайте минимизация, redaction, отделни access роли и срокове за съхранение. Operational telemetry и чувствителното съдържание имат различни цели и достъп.
Управление през целия жизнен цикъл
- Регистър на AI use cases, owners, модели и доставчици.
- Оценка на данни, риск и въздействие преди пускане.
- Evaluation за качество, leakage, abuse и prompt injection.
- Versioning и одобрение на промени.
- Monitoring, incident response, rollback и kill switch.
- Периодичен review на достъпа, данните и бизнес необходимостта.
Често задавани въпроси
Може ли служител да поставя фирмени данни в публичен AI инструмент?
Само ако политиката и договорните условия изрично го позволяват за съответната категория данни. По подразбиране поверителна информация не трябва да се изпраща към неодобрен инструмент.
RAG по-сигурен ли е от fine-tuning?
RAG често дава по-добър контрол върху източници и актуализация, но сигурността зависи от permissions, индекса, логовете, retention и цялата архитектура.
Достатъчно ли е доставчикът да обещае, че не обучава върху данните?
Не. Трябва да се проверят съхранение, местоположение, subprocessors, identity, audit, deletion, incident process и техническите настройки.
Кое е първото практическо действие?
Направете инвентар на AI употребата и данните, класифицирайте сценариите и осигурете одобрена безопасна алтернатива за служителите.