Перейти к содержимому

Для высшего образования и научных исследований

Обеспечение соблюдения AUP и атрибуция для ИИ в кампусе

Использование ИИ сегодня повсеместно в кампусе, тогда как политика допустимого использования и управление отстают. Olivares AI помогает университетам и лабораториям обеспечивать соблюдение этой политики, устанавливать атрибуцию доступа в общих учётных записях и формировать доказательства — не мешая при этом исследованиям.

Большинство университетов не принимали решения о внедрении ИИ — он пришёл сам. Преподаватели составляют с ним тексты, студенты пишут с ним код, исследовательские группы подключают агентов к общим лабораторным учётным записям и данным факультетов, а центральный IT узнаёт об этом постфактум. Исследование EDUCAUSE (2025) описывает этот разрыв прямо: использование ИИ сегодня широко распространено среди преподавателей и сотрудников вузов, тогда как формальное управление ИИ и охват политикой допустимого использования отстают. Политика, которую никто не видит и которую ничто не обеспечивает, — это не средство контроля, а PDF-файл.

Этот разрыв характерен не только для кампуса, но в кампусе он проявляется острее. Учётные записи являются общими по своей природе. Целостность исследований зависит от понимания того, что к чему обращалось. А те, кому вы больше всего хотите дать возможности, — исследователи — это именно те, кого жёсткий контроль вытолкнул бы к теневым инструментам.

Проблема — конкретно

В сети кампуса обычно одновременно верны три вещи:

  • Политика допустимого использования существует, но не обеспечивается. Есть правило о том, к каким системам ИИ может обращаться и что он может делать. Ничто не превращает это правило в решение в тот момент, когда агент пытается действовать.
  • Общие учётные записи стирают атрибуцию. Агенты лаборатории работают под одной сервисной учётной записью за пулом соединений. Нативный аудит относит доступ к этим учётным данным — а не к человеку или агенту, который действительно его осуществил.
  • Исследователям нужно двигаться быстро. Они хотят опробовать нового агента на почти реальных данных уже сегодня, а не подавать заявку и ждать. Если управление — это шлагбаум, который приходится выпрашивать, они находят обходные пути.

Это та же картина, с которой сталкивается рынок в целом. Из организаций, переживших связанную с ИИ утечку, около 97% не имели надлежащих средств контроля доступа к ИИ (IBM Cost of a Data Breach 2025, Ponemon), а Gartner ожидает, что более 40% проектов агентного ИИ будут свёрнуты к концу 2027 года — и долг по управлению является значимой частью причин. Версию этой проблемы на уровне кампуса дешевле устранить заранее, пока агентов немного, а радиус поражения мал.

Чем помогает Olivares AI

Olivares AI — это открытая, локально развёртываемая платформа, которая обнаруживает ИИ-агентов в вашей инфраструктуре, составляет карту того, что каждый из них может читать и записывать, и позволяет управлять этим доступом и проводить его аудит. Она работает по принципу read-first: она наблюдает и записывает вне основного канала, прежде чем что-либо ограничивать, и она deny-closed там, где ограничивает. Для кампуса это означает, что вы можете начать с того, чтобы увидеть истинную картину, — и только потом решить, что именно обеспечивать.

Обеспечивайте соблюдение политики допустимого использования по принципу deny-closed

Слой управления превращает AUP в политику, которая выдаёт решение. Её ABAC-движок работает после доступа на основе ролей и может только дополнительно ограничивать: он отказывает, когда срабатывает правило запрета, иначе действует существующее решение, а некорректно сформированная политика срабатывает на запрет, а не на разрешение. Так правило «ни один ИИ-агент не может записывать в систему оценок» или «агенты песочницы не могут обращаться к SIS» становится реализованным запретом, а не служебной запиской.

Уточним, на что именно реагирует v1. Правила запрета сегодня опираются на принципал, разрешение/операцию и ресурс — атрибуты, которые действительно доходят до вычислителя. Правила, которые ветвятся по чувствительности ресурса (например, «всё, что помечено FERPA»), требуют интерфейса атрибутов ресурса, который является задокументированным дальнейшим шагом и пока не реализован. Там, где вам нужен человек в контуре, платформа фиксирует запрос на одобрение плюс журнал решений, доступный только для добавления, поэтому на вопрос «кто одобрил обращение этого агента к тому набору данных» можно ответить позже.

См. /docs/concepts/governance для описания модели read-first, deny-closed и того, где исполнение действий работает в реальном времени, а где — по запросу.

Атрибуция действий в общих учётных записях

Это ключевая для кампуса возможность. Карта доступа фиксирует с честными уровнями уверенности, какой агент читает или записывает какой ресурс и является ли этот доступ разрешённым или лишь наблюдаемым. Управление идентичностью (/product/identity) привязывает агента к канонической идентичности, которую предъявляют его учётные данные, чтобы доступ можно было надёжно атрибутировать.

Правило честности здесь важнее, чем где-либо: атрибуция надёжна только тогда, когда в доступ передаётся идентичность на уровне отдельного агента или сессии. Когда несколько агентов работают под одной общей лабораторной учётной записью за пулом, атрибуция сводится к этой единственной идентичности — и продукт сообщает об этом, отображая общую привязку как замечание управления, а не угадывая человека. Идентичность, привязанная более чем к одному агенту, помечается, а не замалчивается. Решение — операционное: передавайте идентичность на уровне отдельного агента (например, в имя приложения в соединении), и атрибуция станет точнее. Мы не выведем имя, которое не подтверждается сигналами.

Управляемые песочницы для исследователей

Исследователи получают изолированное эфемерное выполнение агентских сценариев на имитированных (mocked) ресурсах — не на боевых. Стандартный исполнитель песочницы изолирован по своей конструкции: он не держит дескриптора к вашему хранилищу, сети или секретам, а шаг, который запрашивает ресурс, не имитированный сценарием, возвращает детерминированный маркер mock-miss, а не обращается к чему-либо реальному. Запуски эфемерны; каждый из них фиксирует реального исполнителя и то, был ли он изолирован, поэтому деградировавший бэкенд виден, а не скрыт. Более сильная изоляция на уровне ОС (упрочнённый контейнер или microVM) — это подключаемый бэкенд, который оператор локального развёртывания настраивает сам.

Это даёт лаборатории безопасное место, чтобы опробовать нового агента до того, как он вообще коснётся реальных данных, — именно так вы удерживаете быстро движущихся исследователей внутри управления, а не подталкиваете их к обходным путям. Для агентов, которые действительно управляют реальными системами, набор защитных тестов red-team, требующих согласия на запуск (внедрение промптов, jailbreak, эксфильтрация), может проверить устойчивость агента с оценкой по OWASP Top 10 for Agentic Applications. Он запускается только против агентов, которыми вы владеете и которые вы авторизовали, — это набор тестов, а не наступательный инструмент.

Доказательства для целостности исследований и аудитов

Оценки (evaluations) сопоставляют выходные данные агентов-кандидатов с версионированными эталонными наборами — это полезно, когда исследовательской группе нужна воспроизводимая запись о том, что агент соответствовал критерию, от запуска к запуску. Судья честен: если не подключён ни один бэкенд оценки, запуск фиксируется как пропущенный (skipped), а не как тихое прохождение, а сырые выходные данные никогда не сохраняются — только односторонний хеш и очищенная метка. См. /product/evals.

Для учреждения слой соответствия (/product/compliance) агрегирует то, что платформа уже наблюдает и аудирует, в запечатанный пакет доказательств, доступный только для добавления и привязанный к реестру с цепочкой хешей. Контроль, подкреплённый доказательствами, помечается как выполненный; контроль без них помечается как пробел (gap), но никогда как фальшивое прохождение. Это техническое сопоставление с такими фреймворками, как EU AI Act и ISO/IEC 42001, — это не юридическая консультация, и продукт не заявляет о сертификации.

Что это такое — и чем не является

  • Это открытый, локально развёртываемый слой управления и наблюдения для ИИ в вашей инфраструктуре. Control plane может работать офлайн / air-gapped на вашем собственном оборудовании, поэтому данные атрибуции и политик никогда не покидают кампус.
  • Это read-first и deny-closed. Система широко наблюдает и управляет; она не широко исполняет действия. Там, где она может выполнить действие, эта поверхность работает в реальном времени, по запросу или является объявленным интерфейсом — и каталог модулей отмечает, что именно.
  • Это пре-1.0. В каталоге 23 модуля, из которых примерно 20 подключены; часть описанных выше возможностей присутствует, часть доступна по запросу, часть является задокументированными дальнейшими шагами. Мы отмечаем, что именно.
  • Она не запускает ваши модели и не является air-gapped инференцией. Изоляция (air gap) относится к control plane. Офлайн работают только локально развёрнутые (self-hosted) модели (vLLM, Ollama); размещённые модели вроде Claude — нет.
  • Это не сертификация. Нет сертификации SOC 2 / ISO / EU AI Act — сопоставление с требованиями соответствия «разработано с учётом» этих фреймворков и производит доказательства, а не печать. См. /security для описания позиции и /docs/concepts/governance для модели управления.

Внедрение повсеместно; отстаёт именно надзор (EDUCAUSE, 2025). Честная отправная точка — увидеть, к чему ваш ИИ уже обращается, решить, что ему позволено делать, и доказать это — именно в таком порядке.

Вопросы

Читает ли система контент студентов или преподавателей, запускает ли их модели?

Нет. Olivares AI работает по принципу read-first и вне основного канала: она принимает журналы аудита, OpenTelemetry и нативный аудит, чтобы составить карту того, к чему обращаются агенты, и сохраняет связи — но никогда SQL-запросы, полезную нагрузку, промпты или PII. Она не запускает ничьи модели, а control plane можно развернуть локально, поэтому данные управления остаются в вашей инфраструктуре.

Может ли она определить, какой именно человек воспользовался общей лабораторной учётной записью?

Честно говоря, лишь в той мере, в какой это позволяют сигналы. Атрибуция надёжна, когда в доступ передаётся идентичность на уровне отдельного агента или сессии. Когда за пулом соединений стоит общая сервисная учётная запись, атрибуция сводится к этой идентичности — и продукт прямо об этом сообщает, а не придумывает имя. Решение — передавать идентичность, а не фабриковать её.

Действительно ли работает сценарий air-gapped для наших моделей?

Изоляция (air gap) применяется к control plane Olivares — слою управления и наблюдения, — который вы можете развернуть локально без подключения к сети. Полностью офлайн работают только локально развёрнутые (self-hosted) модели (vLLM, Ollama); размещённые модели вроде Claude — нет. Мы не утверждаем обратного.

Попробуйте на собственной инфраструктуре

Olivares AI — это open-core (AGPL-3.0) и self-hosted. Разверните его и посмотрите, что смогут сделать ваши агенты.