Liest dies Inhalte von Studierenden oder Lehrenden oder führt es deren Modelle aus?

Nein. Olivares AI arbeitet read-first und out of band: Es nimmt Audit-Logs, OpenTelemetry und native Audit-Daten auf, um abzubilden, worauf Agenten zugreifen, und persistiert Beziehungen — niemals SQL-Statements, Payloads, Prompts oder PII. Es führt niemandes Modell aus, und die Control Plane ist selbstgehostet, sodass die Governance-Daten auf Ihrer Infrastruktur bleiben.

Kann es feststellen, welche Person ein gemeinsam genutztes Laborkonto verwendet hat?

Ehrlich gesagt nur so weit, wie die Signale es zulassen. Die Attribution ist belastbar, wenn eine Identität pro Agent oder pro Sitzung in den Zugriff propagiert wird. Sitzt ein gemeinsam genutztes Servicekonto hinter einem Connection-Pool, kollabiert die Attribution auf diese Identität — und das Produkt sagt das, statt einen Namen zu erfinden. Die Lösung besteht darin, die Identität zu propagieren, nicht sie zu fabrizieren.

Ist die air-gapped-Story für unsere Modelle real?

Der Air Gap betrifft die Olivares-Control-Plane — die Governance- und Beobachtungsebene —, die Sie offline selbst hosten können. Nur selbstgehostete Modelle (vLLM, Ollama) laufen vollständig offline; gehostete Modelle wie Claude tun das nicht. Wir behaupten nichts anderes.

AUP-Durchsetzung und Attribution für KI auf dem Campus

Die meisten Hochschulen haben nicht entschieden, KI einzuführen; sie war einfach da. Lehrende formulieren damit, Studierende programmieren damit, Forschungsgruppen verdrahten Agenten in gemeinsam genutzte Laborkonten und Fachbereichsdaten, und die zentrale IT erfährt es im Nachhinein. Die EDUCAUSE-Forschung (2025) beschreibt die Lücke klar: KI-Nutzung ist mittlerweile unter Lehrenden und Mitarbeitenden im Hochschulbereich weit verbreitet, während formelle KI-Governance und die Abdeckung durch Acceptable-Use-Policies hinterherhinkt. Eine Policy, die niemand sehen kann und die nichts durchsetzt, ist keine Kontrolle — sie ist ein PDF.

Diese Lücke ist nicht einzigartig für den Campus, aber der Campus verschärft sie. Konten werden bewusst gemeinsam genutzt. Forschungsintegrität hängt davon ab, zu wissen, was worauf zugegriffen hat. Und genau die Menschen, die Sie am meisten befähigen wollen — die Forschenden —, sind diejenigen, die eine schwerfällige Kontrolle in Schatten-Tooling treiben würde.

Das Problem, konkret

Drei Dinge sind in einem Campus-Netzwerk meist gleichzeitig wahr:

Eine Acceptable-Use-Policy existiert, wird aber nicht durchgesetzt. Es gibt eine Regel dazu, welche Systeme KI berühren darf und was sie tun darf. Nichts verwandelt diese Regel in eine Entscheidung in dem Moment, in dem ein Agent zu handeln versucht.
Gemeinsam genutzte Konten löschen die Attribution aus. Die Agenten eines Labors laufen als ein einziges Servicekonto hinter einem Connection-Pool. Das native Audit attribuiert den Zugriff diesem Credential zu — nicht der Person oder dem Agenten, die es tatsächlich getan haben.
Forschende müssen schnell vorankommen. Sie wollen heute einen neuen Agenten gegen realitätsnahe Daten ausprobieren, kein Ticket einreichen und warten. Wenn Governance ein Tor ist, an dem sie vorbeibetteln müssen, umgehen sie es.

Dies ist dieselbe Form, auf die der breitere Markt stößt. Von den Organisationen, die eine KI-bezogene Sicherheitsverletzung erlitten haben, fehlten etwa 97 % angemessene KI-Zugriffskontrollen (IBM Cost of a Data Breach 2025, Ponemon), und Gartner erwartet, dass bis Ende 2027 mehr als 40 % der Projekte mit agentischer KI eingestellt werden — Governance-Schulden sind ein großer Teil des Grundes. Die Campus-Variante lässt sich früh günstiger beheben, solange die Agenten wenige und der Wirkungsradius klein sind.

Wie Olivares AI hilft

Olivares AI ist eine offene, selbstgehostete Plattform, die KI-Agenten auf Ihrer Infrastruktur entdeckt, abbildet, was jeder einzelne lesen und schreiben kann, und es Ihnen ermöglicht, diesen Zugriff zu governen und zu auditieren. Sie ist read-first: Sie beobachtet und protokolliert out of band, bevor sie irgendetwas blockiert, und sie ist deny-closed, wo sie blockiert. Für einen Campus bedeutet das, dass Sie damit beginnen können, die Wahrheit zu sehen — und erst dann entscheiden, was Sie durchsetzen.

Acceptable-Use-Policy durchsetzen, deny-closed

Die Governance-Ebene verwandelt die AUP in eine Policy, die eine Entscheidung erzeugt. Ihre ABAC-Engine läuft nach der rollenbasierten Zugriffskontrolle und kann nur weiter einschränken: Sie verweigert, wenn eine Deny-Regel zutrifft, ansonsten bleibt die bestehende Entscheidung bestehen, und eine fehlerhafte Policy schlägt nach deny-closed statt nach deny-open fehl. So wird aus einer Regel wie „kein KI-Agent darf in das Notensystem schreiben” oder „Sandbox-Agenten dürfen das SIS nicht erreichen” eine durchgesetzte Verweigerung, kein Memo.

Seien Sie präzise darüber, was v1 abgleicht. Deny-Regeln greifen heute auf den Principal, die Berechtigung/das Verb und die Ressource zurück — die Attribute, die den Evaluator tatsächlich erreichen. Regeln, die sich nach der Sensibilität der Ressource verzweigen (z. B. „alles, was mit FERPA getaggt ist”), benötigen eine Ressourcen-Attribut-Schnittstelle, die ein dokumentierter Folgeschritt und noch nicht ausgeliefert ist. Wo Sie einen Menschen im Loop benötigen, protokolliert die Plattform eine Genehmigungsanfrage zuzüglich eines append-only-Entscheidungspfads, sodass „wer hat genehmigt, dass dieser Agent diesen Datensatz erreicht” später beantwortbar ist.

Siehe /docs/concepts/governance für das read-first-, deny-closed-Modell und dazu, wo die Aktuierung live versus on-demand ist.

Attribuieren, wer was getan hat — über gemeinsam genutzte Konten hinweg

Dies ist die tragende Fähigkeit für den Campus. Die Access Map protokolliert mit ehrlichen Konfidenzstufen, welcher Agent welche Ressource liest oder schreibt und ob dieser Zugriff erlaubt oder lediglich beobachtet ist. Identity-Governance (/product/identity) bindet einen Agenten an die kanonische Identität, die sein Credential vorweist, sodass ein Zugriff belastbar attribuiert werden kann.

Die Ehrlichkeitsregel zählt hier mehr als irgendwo sonst: Die Attribution ist nur dann belastbar, wenn eine Identität pro Agent oder pro Sitzung in den Zugriff propagiert wird. Wenn mehrere Agenten als ein gemeinsam genutztes Laborkonto hinter einem Pool laufen, kollabiert die Attribution auf diese eine Identität — und das Produkt sagt das und weist die gemeinsam genutzte Bindung als Governance-Finding aus, statt eine Person zu erraten. Eine Identität, die an mehr als einen Agenten gebunden ist, wird markiert, nicht übertüncht. Die Abhilfe ist operativ: Propagieren Sie die Identität pro Agent (zum Beispiel in den Application Name der Verbindung), und die Attribution schärft sich. Wir drucken keinen Namen, den die Signale nicht stützen können.

Governte Sandboxes für Forschende

Forschende erhalten eine isolierte, ephemere Ausführung von Agenten-Szenarien gegen gemockte Ressourcen — nicht gegen die Produktion. Der standardmäßige Sandbox-Runner ist konstruktionsbedingt isoliert: Er hält keinen Handle auf Ihren Store, Ihr Netzwerk oder Ihre Secrets, und ein Schritt, der eine Ressource anfordert, die das Szenario nicht gemockt hat, liefert einen deterministischen Mock-Miss-Marker zurück, statt etwas Reales zu erreichen. Läufe sind ephemer; jeder einzelne protokolliert den realen Runner und ob er isoliert war, sodass ein degradiertes Backend sichtbar und niemals verborgen ist. Stärkere Isolation auf OS-Ebene (ein gehärteter Container oder eine microVM) ist ein einsteckbares Backend, das der Self-Host-Betreiber verdrahtet.

Das gibt einem Labor einen sicheren Ort, um einen neuen Agenten auszuprobieren, bevor er jemals reale Daten berührt — und genau so halten Sie schnell agierende Forschende innerhalb der Governance, statt dass sie sie umgehen. Für Agenten, die reale Systeme tatsächlich governen, kann eine einwilligungsgebundene, defensive Red-Team-Batterie (Prompt Injection, Jailbreak, Exfiltration) die Widerstandsfähigkeit eines Agenten prüfen, bewertet gegen die OWASP Top 10 for Agentic Applications. Sie läuft nur gegen Agenten, die Ihnen gehören und die Sie autorisiert haben — sie ist eine Test-Suite, kein Offensiv-Werkzeug.

Nachweise für Forschungsintegrität und Audits

Evaluations bewerten Ausgaben von Kandidaten-Agenten gegen versionierte Golden Suites — nützlich, wenn eine Forschungsgruppe einen reproduzierbaren Nachweis benötigt, dass ein Agent ein Kriterium erfüllt hat, Lauf für Lauf. Der Judge ist ehrlich: Ist kein Scoring-Backend verdrahtet, wird ein Lauf als skipped protokolliert, niemals als stilles Bestehen, und Rohausgaben werden niemals persistiert — nur ein Einweg-Hash und ein bereinigtes Label. Siehe /product/evals.

Für die Institution aggregiert die Compliance-Ebene (/product/compliance), was die Plattform bereits beobachtet und auditiert, in ein versiegeltes, append-only-Nachweispaket, das an ein hash-verkettetes Ledger verankert ist. Eine Kontrolle mit hinterlegtem Nachweis wird als erfüllt markiert; eine ohne wird als Gap markiert, niemals als vorgetäuschtes Bestehen. Dies ist eine technische Zuordnung zu Frameworks wie dem EU AI Act und ISO/IEC 42001 — es ist keine Rechtsberatung, und das Produkt beansprucht keine Zertifizierung.

Was dies ist — und was nicht

Es ist eine offene, selbstgehostete Governance- und Beobachtungsebene für KI auf Ihrer Infrastruktur. Die Control Plane kann offline / air-gapped auf Ihrer eigenen Hardware laufen, sodass Attributions- und Policy-Daten den Campus niemals verlassen.
Es ist read-first und deny-closed. Es beobachtet und governt breit; es aktuiert nicht breit. Wo es eine Aktion ausführen kann, ist diese Oberfläche live, on-demand oder eine deklarierte Schnittstelle — und der Modul-Katalog markiert, welche.
Es ist pre-1.0. Der Katalog umfasst 23 Module mit etwa 20 verdrahteten; einige der oben genannten Fähigkeiten sind vorhanden, einige on-demand, einige sind dokumentierte Folgeschritte. Wir kennzeichnen, welche.
Es führt Ihre Modelle nicht aus, und es ist keine air-gapped-Inferenz. Der Air Gap ist die Control Plane. Nur selbstgehostete Modelle (vLLM, Ollama) laufen offline; gehostete Modelle wie Claude tun das nicht.
Es ist keine Zertifizierung. Keine SOC-2- / ISO- / EU-AI-Act-Zertifizierung — die Compliance-Zuordnung ist „auf diese Frameworks ausgerichtet” und erzeugt Nachweise, kein Siegel. Siehe /security für die Posture und /docs/concepts/governance für das Governance-Modell.

Die Adoption ist weit verbreitet; was hinterherhinkt, ist die Aufsicht (EDUCAUSE, 2025). Der ehrliche Ausgangspunkt ist, zu sehen, was Ihre KI bereits berührt, zu entscheiden, was sie tun darf, und es zu beweisen — in dieser Reihenfolge.