Как защитить ИИ-базу от плохих документов: урок про 250 отравленных текстов

Когда компания подключает ИИ к внутренним документам, кажется, что главный риск - слабая модель. На практике часто опаснее другое: что именно попадает на вход. Если база знаний грязная, противоречивая или специально испорченная, агент будет уверенно опираться на плохой материал.

Исследование Anthropic с UK AI Security Institute и Alan Turing Institute показало неприятную вещь: в экспериментальной постановке малое число вредных документов может создать у модели уязвимость-триггер. В публикации Anthropic говорится, что речь шла о простых бэкдорах и низкорисковых тестовых сценариях, но практический вывод шире: безопасность начинается не после ответа модели, а до попадания документов в контур.

Для журнала это полезно не как страшилка про “сломали ИИ”, а как рабочий навык: перед тем как строить RAG, базу знаний или память агента, нужно настроить приемку документов.

Главное:

Защищать нужно не только ответ модели, но и вход в систему. Если агент читает документы, сначала должна быть приемка: источник, дата, владелец, статус актуальности и право использовать этот материал.

Почему это касается обычных проектов

Большинство рабочих ИИ-систем сегодня не обучает модель с нуля. Они дают ей документы: регламенты, инструкции, письма, базы знаний, заметки, карточки клиентов, стенограммы звонков. Модель читает их и отвечает. Это удобно, но появляется новое слабое место: в систему может попасть устаревшая инструкция, черновик, фейковая справка, случайная выгрузка или вредный текст.

Если агент работает с документами, он часто не знает, что один файл надежнее другого. Для него “policyfinal.pdf”, “policyold.docx” и “policynewfinalreallyfinal.md” могут выглядеть одинаково убедительно. Поэтому человеку нужна не просто папка с материалами, а контур доверия.

Приемка документов перед ИИ

Хорошая приемка начинается с простых вопросов. Кто владелец документа? Для какой задачи он нужен? Когда он обновлялся? Можно ли ему доверять? Есть ли более свежая версия? Должен ли агент видеть весь документ или только фрагмент?

После этого появляется технический слой: реестр документов, статусы, хеши, запрет на неизвестные источники, ручная проверка для чувствительных разделов, журнал изменений. Это звучит скучно, но именно скучная дисциплина защищает агентную систему лучше, чем надежда на “умную модель”.

Мы уже разбирали похожую логику в статье про личный ИИ-поиск по файлам: важно, чтобы ответ вел обратно к исходному месту. В статье про AgentMemory речь была о памяти агента. Здесь следующий слой: память должна не только хранить, но и фильтровать.

Что проверять перед загрузкой

В маленькой команде достаточно начать с пяти признаков.

Первый - источник. Документ должен быть получен из понятного места: официальный сайт, утвержденная папка, CRM, репозиторий, почта конкретного ответственного человека.

Второй - статус. Черновик, архив, утвержденная версия и экспериментальная заметка не должны лежать для агента в одном весе.

Третий - дата. Для правил, цен, юридических условий и API-документации старость часто равна ошибке.

Четвертый - область применения. Инструкция для одного клиента или страны не должна автоматически становиться общей политикой.

Пятый - проверяемость. Если агент отвечает по документу, человек должен видеть, на какой источник он опирается.

Рабочая карточка

Когда использовать: перед подключением ИИ к внутренней базе, папке документов, RAG, корпоративному поиску или памяти агента.

Что подать на вход: список источников, владельцев документов, статусы актуальности, правила доступа и критерии исключения.

Что сделать по шагам:

1. Разделить документы на актуальные, архивные, черновики и неизвестные.
2. Назначить владельца для каждого важного источника.
3. Исключить из индекса материалы без происхождения и даты.
4. Настроить ссылки из ответа агента обратно к документу.
5. Ввести карантин для новых файлов до проверки.
6. Раз в неделю проверять, какие документы чаще всего использует агент.

Как проверить качество: любой важный ответ можно объяснить ссылкой на источник, дату и владельца документа.

Когда не использовать: если задача разовая и документы не будут повторно использоваться. Тогда дешевле вручную дать агенту проверенный фрагмент.

Главный вывод простой: ИИ-база знаний должна быть не свалкой файлов, а редакцией документов. Модель может быть сильной, но если на входе мусор, устаревшие правила или вредные вставки, результат будет слабым. Сначала фильтр, потом агент.