Brane AIF Handbuch

Dieses Handbuch richtet sich an Administratorinnen und Administratoren, die eine Brane-AIF-Appliance in Betrieb nehmen und betreiben. Es führt von der Inbetriebnahme über Konfiguration und täglichen Betrieb bis zu Sicherheit, Datenschutz und Compliance.

1. Inbetriebnahme

Ihre Brane AIF Appliance ist fertig konfiguriert und sofort einsatzbereit. Drei Schritte genügen.

1

Anschließen

Verbinden Sie die Appliance mit Strom (mitgeliefertes Netzteil) und Netzwerk (Ethernet-Kabel in Ihren Switch oder Router).

2

Einschalten

Drücken Sie den Power-Button. Die Appliance startet in ca. 90 Sekunden — alle Services starten automatisch.

3

Browser öffnen

Öffnen Sie http://brane-aif.local in Ihrem Browser. Alternativ: Scannen Sie den QR-Code auf der Rückseite der Appliance.

Netzwerk-Anforderungen

Netzwerk-Voraussetzungen

Damit Ihre Appliance beim Eintreffen sofort startklar ist, klären Sie die folgenden Netzwerk-Punkte vorab mit Ihrer IT. Genau diese Angaben fragt das Onboarding-Formular ab — Sie können sie also in Ruhe vorbereiten. Was noch offen ist, lassen Sie einfach frei.

Konnektivität

Zwei Betriebsmodelle stehen zur Wahl:

IP-Adresse & DNS

Im Auslieferungszustand bezieht die Appliance ihre Adresse per DHCP. Für den Produktivbetrieb empfehlen wir eine statische Konfiguration:

Firewall & Ports

Brane AIF kommt mit minimalen Anforderungen aus — in der Regel müssen keine eingehenden Ports geöffnet werden.

TLS & Zertifikate

Wählen Sie, wie die Verbindung verschlüsselt wird — die Schritt-für-Schritt-Anleitung steht in Kapitel 9:

• Cloudflare Tunnel — empfohlen, kein offener Port, automatisches HTTPS
• Eigenes Zertifikat — aus Ihrer internen PKI
• Selbstsigniert — nur für interne Tests

Cloud-API-Key (optional)

Nur wenn Sie Cloud-Modelle nutzen möchten: Halten Sie einen API-Key bereit — am einfachsten einen OpenRouter-Key (ein Schlüssel für alle Anbieter, siehe API Keys einrichten). Im Modus „Nur lokal“ ist kein Key nötig.

2. Setup Wizard

Beim ersten Zugriff startet automatisch der Setup Wizard. Er führt Sie in 6 Schritten durch die Konfiguration. Alle Einstellungen können später im Admin-Dashboard geändert werden.

Step 1: Unternehmen

• Firmenname — Erscheint auf der Login-Seite, im Chat und im System-Prompt
• Firmenlogo — laden Sie Ihr Logo (PNG oder SVG) nach dem Setup im Admin-Bereich hoch
• Sprache — Deutsch, English oder Français
• Modus — Enterprise (mit Login, empfohlen) oder Stateless (ohne Login, für Tests)

Step 2: Administrator

• Admin E-Mail — Ihre Anmelde-Adresse (kann nicht geändert werden)
• Passwort — Mindestens 8 Zeichen
• SSO — Optional hier oder später konfigurieren (siehe Abschnitt 4)

Step 3: KI-Konfiguration

Das Herzstück: Welche KI-Modelle und wie wird geroutet.

Lokales Modell

Ihr vorinstalliertes On-Premise-Modell wird automatisch erkannt. Falls nicht: Klicken Sie den Refresh-Button oder geben Sie den Modellnamen manuell ein.

Cloud-Modell (optional)

Ergänzend zum lokalen Modell können Sie ein Cloud-Modell konfigurieren. Wählen Sie Ihren Provider und das gewünschte Modell:

Routing-Strategie

Bestimmt, wie Anfragen zwischen lokalem und Cloud-Modell verteilt werden:

• Nur lokal (Local Only) — Kein Cloud-Zugriff. Keine API Keys nötig. Maximale Datensouveränität.
• Lokal bevorzugt (Local Preferred) — Cloud nur für komplexe Aufgaben. Beste Balance aus Sicherheit und Qualität.
• Cloud bevorzugt (Cloud Preferred) — Cloud für Qualität, lokal bei sensiblen Daten. Guardian schützt PII automatisch. Einen „Nur Cloud“-Modus bietet die Oberfläche bewusst nicht an — ohne lokalen Fallback gäbe es keine Souveränitätsgarantie. (Ein historischer, per API gesetzter Wert cloud-only wird noch akzeptiert; auch dann erzwingt der Guardian bei PII, Fehlern oder Unsicherheit die lokale Verarbeitung.)

PII-Policy

Was passiert mit persönlichen Daten (Namen, E-Mails, IBANs) bei Cloud-Anfragen?

Step 4: Abteilungen

• Schnellstart-Vorlagen — Allgemein, Fertigung, Finanz, Gesundheit, Recht (fügt typische Abteilungen auf einmal hinzu)
• Manuell hinzufügen — Beliebige Abteilungsnamen
• Optional: Sie können Abteilungen auch später im Admin-Panel einrichten

Step 5: Netzwerk

• Domain — z.B. ai.ihre-firma.de (optional)
• Zertifikat — Cloudflare Tunnel (empfohlen), eigenes Zertifikat oder selbstsigniert (Kapitel 9)

Step 6: Zusammenfassung

Alle Einstellungen prüfen. API Keys werden maskiert angezeigt. Mit „Complete Setup“ abschließen — Sie werden zur Login-Seite weitergeleitet.

3. API Keys einrichten

API Keys verbinden Ihre Appliance mit Cloud-Modellen. Ohne API Keys funktioniert Brane AIF vollständig lokal — Cloud-Anbindung ist optional.

Empfohlen: OpenRouter (1 Key = alle Modelle)

Der einfachste Weg zur Cloud-Anbindung ist OpenRouter — ein universelles Gateway, das mit einem einzigen API-Key Zugang zu allen großen Anbietern bietet (OpenAI, Anthropic, Google, Mistral, xAI, u.v.m.).

Die OpenRouter-Konfiguration von Brane AIF (Security-First)

Wir setzen automatisch strenge Datenschutz-Defaults:

Standard-Modell

Die Box wird mit einem kuratierten Katalog geprüfter Modelle ausgeliefert; das Standard-Modell ist openrouter:anthropic/claude-sonnet-4.5. Auf einer Box mit EU-Residency wird der Katalog auf Endpoints gefiltert, die die Datenregion (EU) erfüllen — Modelle ohne konformen EU-Endpoint werden nicht angeboten. Auf EU-Residency-Boxen wird openrouter/auto bewusst nicht angeboten, da der Auto-Router das EU-Endpoint-Pinning nicht respektiert.

EU-Endpoint (optional)

EU-In-Region-Routing ist für freigeschaltete Enterprise-Kunden verfügbar. Nach entsprechender Aktivierung laufen Anfragen über eu.openrouter.ai und werden ausschließlich an Endpoints geroutet, die die Datenregion EU erfüllen. Aktivierbar über Setting cloudResidency: "eu". Das Pinning greift nur auf dem OpenRouter-Pfad — bei direkten Provider-Keys hat die Einstellung keine Wirkung.

OpenRouter einrichten (3 Schritte)

1. Besuchen Sie openrouter.ai und erstellen Sie einen Account
2. Gehen Sie zu Settings → Keys und klicken Sie „Create Key“
3. Key kopieren und in Brane AIF eintragen: Setup Wizard oder Admin-Dashboard → KI → Cloud

Alternative: Direkte Provider-Keys

Wenn Sie direkten Zugang zu einzelnen Anbietern bevorzugen (z.B. für bestehende Unternehmensverträge), können Sie individuelle API-Keys pro Provider hinterlegen.

Unterstützte Provider

OpenAI

sk-...

Key erstellen →

Anthropic

sk-ant-...

Key erstellen →

Google

AI...

Key erstellen →

Mistral

...

Key erstellen →

xAI / Grok

xai-...

Key erstellen →

OpenRouter

sk-or-...

Key erstellen →

Perplexity

pplx-...

Key erstellen →

API Key erstellen

Am Beispiel von OpenAI (bei allen Providern ähnlich):

1. Besuchen Sie platform.openai.com/api-keys
2. Klicken Sie „Create new secret key“
3. Name vergeben (z.B. „Brane AIF“)
4. Key sofort kopieren — wird nur einmal angezeigt
5. In Brane AIF eintragen: Setup Wizard (Step 3) oder Admin-Dashboard → Einstellungen

Zentrale Schlüsselverwaltung

API-Keys werden ausschließlich zentral vom Administrator hinterlegt (Setup Wizard oder Admin-Dashboard) und gelten für alle Nutzer; persönliche Nutzer-Keys gibt es nicht.

Empfehlung: Starten Sie mit einem globalen OpenRouter-Key (Preset „Einfach“).

Sicherheit

• Alle Keys werden mit AES-256-GCM verschlüsselt auf der Appliance gespeichert
• Der Schlüssel existiert nur auf Ihrer Hardware
• API-Keys werden nicht an AI-Z übermittelt. Bei Nutzung externer KI-Modelle werden ausschließlich die gemäß Routing-, Perimeter- und Schutzrichtlinie freigegebenen Inhalte übertragen
• Keys können jederzeit gelöscht werden

4. SSO konfigurieren

Single Sign-On: Mitarbeiter melden sich mit bestehenden Unternehmens-Credentials an. Kann im Setup Wizard oder nachträglich im Admin-Dashboard aktiviert werden.

Unterstützte Provider

Azure AD / Entra ID Okta Generic OIDC

Azure AD / Microsoft Entra ID

Ideal für Microsoft 365 Umgebungen.

Einrichtung

1. Azure Portal → Azure Active Directory → App Registrations → New registration
2. Name: „Brane AIF“
3. Redirect URI (Web): https://IHRE-DOMAIN/supabase/auth/v1/callback
4. Unter Certificates & secrets → New client secret
5. Werte in Brane AIF eintragen:

• Tenant ID: UUID Ihres Azure AD Tenants (Azure Portal → Overview)
• Client ID: Application (Client) ID der App Registration
• Client Secret: Secret Value (nicht die Secret ID)

Okta

1. Okta Developer Console → Applications → Create App Integration
2. OIDC → Web Application
3. Sign-in redirect: https://IHRE-DOMAIN/supabase/auth/v1/callback

• Issuer URL: https://your-domain.okta.com/oauth2/default
• Client ID: z.B. 0oaxxxxxxxxxxxxxxx
• Client Secret: Aus der Okta App-Konfiguration

Generic OIDC (Keycloak, Auth0 etc.)

1. Confidential Client erstellen in Ihrem IDP
2. Redirect URI: https://IHRE-DOMAIN/supabase/auth/v1/callback
3. Scopes: openid, email, profile

• Issuer URL: z.B. https://idp.firma.de/realms/main
• Client ID: Vom IDP generiert
• Client Secret: Confidential Client Secret

Auto-Create Users

Wenn aktiviert: Nutzer werden bei der ersten SSO-Anmeldung automatisch angelegt.

Login für Ihre Mitarbeiter

Nach SSO-Konfiguration erscheint auf der Login-Seite ein zusätzlicher Button („Mit Microsoft anmelden“, „Mit Okta anmelden“ etc.). Der klassische E-Mail/Passwort-Login bleibt verfügbar.

5. Nutzerverwaltung & Rollen

Nutzer hinzufügen

Mit SSO: Nutzer melden sich direkt an (Auto-Create) oder werden vom Admin freigeschaltet.

Ohne SSO: Mitarbeiter klicken auf der Login-Seite auf „Noch keinen Zugang? Hier anfragen“ und registrieren sich mit E-Mail und Passwort. Der Administrator gibt den Zugang im Dashboard frei.

Rollen-System

Brane AIF unterstützt vier Rollen mit abgestuften Rechten:

Admin-Dashboard

Unter /admin/users können Sie:

• Nutzer anlegen, deaktivieren oder löschen
• Zugangsanfragen genehmigen oder ablehnen
• Rolle aus Dropdown zuweisen: User / Dept Admin / Viewer / Admin
• Abteilung pro Nutzer zuweisen
• Übersicht aller Nutzer und letzter Login

Limits

6. Abteilungen

Abteilungen sind eine schlanke Möglichkeit, Ihre Nutzer zu gruppieren — skalierbar und ohne komplizierte Einzel-Regler. Eine Abteilung bündelt Mitglieder, verwaltet ihre Abteilungs-Admins und kann bei Bedarf als reine On-Premise-Gruppe geführt werden. Das eigentliche Schutzverhalten (Routing, PII, Firmenregeln) steuern Sie zentral über den Perimeter (Kapitel 13) — nicht pro Abteilung, damit die Datengrenze an einer Stelle nachvollziehbar bleibt.

Abteilung anlegen

Unter /admin/departments legen Sie Abteilungen an und verwalten sie:

1. Name eingeben (z. B. „HR“, „Engineering“, „Legal“)
2. Optional eine kurze Beschreibung
3. Optional den Schalter „Nur lokal“ (local_only) aktivieren

Der einzige Policy-Schalter: „Nur lokal“

Ist „Nur lokal“ aktiv, bleiben alle Anfragen der Abteilungsmitglieder ausschließlich auf der Box — kein Cloud-Modell, unabhängig von der globalen Routing-Einstellung. Das ist bewusst der einzige Regler auf Abteilungsebene: eine Airgap-Gruppe für besonders sensible Bereiche. Im Admin-Dashboard ist „Nur lokal“ der einzige Abteilungs-Regler — alle übrigen Datengrenze-Hebel konfigurieren Sie zentral im Perimeter (Kapitel 13).

Mitglieder & Abteilungs-Admins

Auf der Abteilungsseite sehen und verwalten Sie die Mitglieder direkt (hinzufügen / entfernen). Wer eine Abteilung eigenständig betreuen soll, bekommt in der Benutzerverwaltung (Kapitel 5) die Rolle Dept Admin — Rollen werden dort vergeben, nicht doppelt in der Abteilungsansicht. Löschen einer Abteilung ist blockiert, solange ihr noch Mitglieder zugeordnet sind.

7. Datenspeicherung

Konform zu DSGVO Art. 5(1)(e) (Speicherbegrenzung). Stellen Sie ein, wie lange Chat-Daten aufbewahrt werden.

Drei Modi

Ephemeral-Modus — der stärkste Datenschutz

Im Ephemeral-Modus werden keine Nachrichteninhalte gespeichert — weder in der Datenbank noch im Audit Log; das Audit Log verzeichnet lediglich die Routing-Entscheidung ohne Inhalte. Der Nutzer sieht einen Hinweis im Chat: „Dieser Chat wird nicht gespeichert“. Beim Schliessen des Browsers ist die Konversation weg.

Rechtlich: Der Ephemeral-Modus unterstützt die Grundsätze der Datenminimierung und Speicherbegrenzung (Art. 5 Abs. 1 lit. c und e DSGVO). Ob und wie lange Inhalte aufbewahrt werden müssen, hängt vom jeweiligen Verarbeitungszweck, dem Inhalt und den für den Geschäftsprozess geltenden Richtlinien ab.

Empfehlungen für die Wahl des Modus

Der Retention-Modus gilt global für die gesamte Box — der einzige Schalter pro Abteilung ist „Nur lokal“ (Kapitel 6). Als organisatorische Orientierung, welcher Modus zu welchen Inhalten passt:

• HR-lastige Nutzung: Ephemeral (Gehaltsgespräche, Bewerbungen — verschwinden sofort)
• Engineering-lastige Nutzung: 90 Tage (Code-Reviews, technische Fragen — kurze History)
• Legal-lastige Nutzung: Unbegrenzt (Vertragsprüfungen — revisionssicher)

8. Täglicher Betrieb

8.1 Admin-Dashboard

Unter /admin sehen Sie auf einen Blick:

• Systemstatus — Operational / Degraded / Error + Uptime
• Registrierte Nutzer — Anzahl aktiver Accounts
• Datenbank-Status — Online/Offline
• Lokales LLM — Bereit/Offline + Modellname
• Guardian Policy — Routing-Modus und PII-Policy

8.2 Einstellungen ändern

Alle Setup-Wizard-Einstellungen können nachträglich im Admin-Dashboard unter /admin/settings geändert werden:

• Routing-Modus & PII-Policy wechseln
• Lokales oder Cloud-Modell ändern
• API Keys hinzufügen oder entfernen
• SSO aktivieren/deaktivieren

9. HTTPS & Zertifikate

Ohne gültiges Zertifikat zeigt jeder Browser eine Warnung — und Mitarbeitende, die gelernt haben, Warnungen wegzuklicken, sind das Gegenteil von Sicherheit. Dieses Kapitel führt durch die drei Wege, die die Appliance unterstützt.

Alles dafür liegt an einer Stelle: Admin-Dashboard → Zertifikate. Oben auf der Karte steht das aktuell installierte Zertifikat mit Aussteller, Ablaufdatum und verbleibenden Tagen.

Welcher Weg passt?

Weg 1: Cloudflare Tunnel

1. In dash.cloudflare.com → Zero Trust → Networks → Tunnels einen Tunnel anlegen und das Token kopieren.
2. Admin → Zertifikate → „Cloudflare Tunnel" wählen, Token einfügen, speichern.

Danach ist HTTPS aktiv, ohne dass in Ihrer Firewall ein eingehender Port geöffnet werden muss.

Weg 2: Eigenes Zertifikat

a) Sie haben bereits ein Zertifikat

Laden Sie die vollständige Kette hoch: Ihr Server-Zertifikat (Leaf) und alle Zwischenzertifikate — nicht das Root — zusammen mit dem passenden privaten Schlüssel. Der Schlüssel muss unverschlüsselt sein, also ohne Passphrase.

Admin → Zertifikate → Eigenes Zertifikat → Dateien wählen → hochladen.

Die Appliance prüft, bevor sie etwas aktiviert: Lässt sich jeder Block lesen? Passt der Schlüssel zum Leaf? Anschließend sortiert sie die Kette Leaf-zuerst. Ein nicht zusammenpassendes Paar wird abgelehnt statt eingebaut — genau die Verwechslung, die sonst erst beim Neustart des Reverse Proxy auffällt.

b) Sie brauchen erst eines von Ihrer CA

1. Domain (CN) eintragen und speichern — der Name, unter dem die Box aufgerufen wird, z. B. ki.ihre-firma.de.
2. „Signieranfrage erzeugen" klicken. Der private Schlüssel entsteht dabei auf der Appliance und verlässt sie nie.
3. Die erzeugte Anfrage (CSR) an Ihre interne PKI oder eine öffentliche CA geben.
4. Das signierte Zertifikat samt Zwischenzertifikaten über „Signiertes Zertifikat hochladen" einspielen.

Was in der Anfrage steht: RSA 2048, Subject /CN=<Ihre Domain>/O=<Ihr Firmenname>/C=DE — und als SAN alle Namen, unter denen die Box erreichbar ist (die konfigurierte Domain, brane-aif.local, localhost). Browser prüfen den SAN, nicht den CN; deshalb gehört jeder tatsächlich genutzte Name hinein.

Weg 3: Selbstsigniert

Domain eintragen, „Erzeugen". Sofort einsatzbereit, für Labor und Test gedacht. Jeder Browser wird warnen — das lässt sich nicht abstellen, weil dem Zertifikat schlicht die Vertrauenskette fehlt.

HTTPS erzwingen, ohne sich auszusperren

Ist ein gültiges Zertifikat installiert, können Sie die Weiterleitung von HTTP auf HTTPS aktivieren. Der Schalter schaltet nicht sofort scharf: Sie haben fünf Minuten, die Umstellung aus einer HTTPS-Sitzung heraus zu bestätigen. Bleibt die Bestätigung aus, nimmt die Appliance die Änderung von selbst zurück. Solange kein Zertifikat installiert ist, es abgelaufen ist oder kein HTTPS-Listener antwortet, bleibt der Schalter gesperrt.

Erneuern

Zertifikate laufen ab, und ein abgelaufenes sieht für den Browser aus wie gar keines. Die Karte zeigt die verbleibenden Tage; spielen Sie die neue Kette auf demselben Weg ein wie die alte. Setzen Sie sich einen Kalendereintrag 30 Tage vor Ablauf — bei internen PKIs mit kurzen Laufzeiten entsprechend früher.

Wenn der Browser trotzdem warnt

10. Backup & Updates

Backup erstellen

Sichern Sie regelmäßig mit dem mitgelieferten Backup-Werkzeug auf ein externes Medium.

Updates

Updates werden von AI-Z verwaltet: Wir liefern geprüfte Images und installieren sie remote — bei Air-Gapped-Boxen erfolgt die Installation vor Ort. Über den neuen Fleet-Update-Kanal sind Update-Artefakte Ed25519-signiert und werden auf der Box vor der Installation verifiziert; der Rollout dieses Kanals auf Bestandsboxen läuft. Vor jedem Update erhalten Sie eine Vorankündigung sowie kundenlesbare Release Notes. Nach der Installation startet die Appliance automatisch neu (Downtime: unter 1 Minute).

Alle Daten, Einstellungen und API Keys bleiben beim Update erhalten.

11. Sicherheitsarchitektur

Sechs ineinandergreifende Sicherheitsschichten schützen Ihre Daten — automatisch, ohne manuellen Eingriff.

Architektur

Ihr Browser | Reverse Proxy — HTTPS & Zertifikate ───── :443 | Web-App — Chat-Interface & Admin ────── :3000 | | Guardian Core Datenbank PII · Routing · Audit PostgreSQL + RLS + Vektor-Suche | vLLM — Lokale KI-Verarbeitung | GPU-Inferenz

Guardian Core — Automatische Datenklassifikation

Jede Benutzernachricht durchläuft den Guardian, bevor sie verarbeitet wird. Er entscheidet in Echtzeit: Lokal verarbeiten, Cloud mit Anonymisierung, oder blockieren.

Phase 1: Hard Constraints (< 1 ms)

• Bild-Inhalte werden lokal ausgelesen und wie Text geprüft — sensible Funde erzwingen lokale Verarbeitung
• Chat bereits sensitiv? → LOKAL (Conversation Lock)
• Modus = „Nur lokal“? → LOKAL
• Kein Cloud-API-Key? → LOKAL

Phase 2: PII Detection (< 200 ms)

• Regex-Scan + ML-Scan (NER-Modell, lokal) + LLM-Scan (kontextbasiert) — zusammen decken sie 23 PII-Kategorien ab

Phase 3: Routing-Entscheidung

• Kein PII gefunden? → Cloud erlaubt
• PII + Policy „Block“? → LOKAL erzwungen
• PII + Policy „Anonymize“? → Cloud mit Anonymisierung
• Unsicherheit? → LOKAL (Fail-Safe)

Erkannte PII-Kategorien (23 Typen in 7 Gruppen)

Smart Redaction — Pseudonymisierung

Wenn Daten an einen Cloud-Anbieter gesendet werden, sieht dieser im Regelfall nur typisierte Tokens statt Originaldaten — ohne Garantie einer hundertprozentigen Erkennung.

EINGABE (Benutzer):
  "Bitte kontaktiere Max Müller unter max@firma.de, IBAN DE89 3704 0044 0532 0130 01"

NACH ANONYMISIERUNG (was die Cloud sieht):
  "Bitte kontaktiere <PERSON_1> unter <EMAIL_1>, IBAN <IBAN_1>"

NACH REHYDRATION (was der Benutzer sieht):
  "Ich habe Max Müller unter max@firma.de kontaktiert."

In-Memory-Mapping — verschlüsselt gespeichert

Die Zuordnung Token ↔ Originalwert lebt im Arbeitsspeicher. Für Konsistenz über Gesprächsrunden wird sie zusätzlich AES-256-GCM-verschlüsselt abgelegt und beim Löschen des Chats bzw. durch den Retention-Job entfernt.

Cross-Message-Konsistenz

Innerhalb einer Konversation erhält derselbe PII-Wert immer dasselbe Token. max@firma.de → immer <EMAIL_1>.

Rehydration < 5 ms

Bidirektionale O(1)-Lookups. Kein ML-Modell involviert. Fuzzy Matching für KI-veränderte Token-Formate.

Overlap-Schutz

max.mueller@gmail.com wird nicht gleichzeitig als PERSON und EMAIL erkannt — die genaueste Kategorie gewinnt.

Verschlüsselung

Datenisolation

Physische Isolation

Alle Daten auf lokaler Infrastruktur. KI-Inferenz läuft lokal. System funktioniert vollständig ohne Internet (Air-Gap-fähig). Keine Chatinhalte verlassen die Box zu Auswertungszwecken — auch das Tracing (Langfuse) läuft vollständig auf der Box. Zwei dokumentierte Ausnahmen: Ist die Appliance am Fleet-Management angemeldet, meldet sie in regelmäßigen Abständen technische Betriebsdaten an AI-Z (Dienststatus, Auslastung, Speicher- und Plattenbelegung, Versionsstand) — keine Prompts, keine Chatinhalte, keine personenbezogenen Daten. Und das optionale Produkt-Feedback-Relay an AI-Z — nur nach ausdrücklicher Aktivierung mit dokumentierter Einwilligung, PII-bereinigt auf der Box und mit pseudonymisierter Nutzer-ID.

Logische Isolation

Row Level Security: Jeder Nutzer sieht nur eigene Daten. RBAC: Strikte Trennung Admin/User/System. Mandantenfähig; Nutzer- und Stream-Kapazität richtet sich nach der Lizenzstufe (siehe FAQ).

Audit & Nachvollziehbarkeit

Jede Routing-Entscheidung dokumentiert (Lokal/Cloud, Begründung, Flags). Audit Logs sind immutable — nachträglich nicht änderbar. Kein PII in den Logs.

Recht auf Löschung

Löscht der Administrator einen Account, werden alle Chats, Nachrichten und Datei-Anhänge unwiderruflich entfernt; Audit-Log-Einträge werden pseudonymisiert (Personenbezug entfernt, Ereignis bleibt für die Revisionskette erhalten). Zentrale RAG-Dokumente samt Vektoren sind ein Firmen-Asset und werden separat pro Dokument oder über die Admin-Datenlöschung entfernt.

12. Admin-Regler & Policy Tester

Der Administrator steuert das gesamte Schutzverhalten über vier aufeinander aufbauende Regler; die Erkennungs-Empfindlichkeit ist fest auf Maximum verdrahtet und lässt sich bewusst nicht herunterregeln. Kein Code, kein Terminal — alles über das Admin-Dashboard.

Entscheidungshierarchie

Routing-Strategie             "Darf Cloud überhaupt genutzt werden?"
└─ AI Interaction Firewall    "Ist dieser Inhalt sensibel?"
   ├─ Enterprise Policy       "Welche Sonderregeln hat die Firma?"
   └─ PII Cloud Policy        "Was tun, wenn sensibel? (Block vs. Anonymize)"

Enterprise Policy — Firmenspezifische Regeln

Die Enterprise Policy ist der mächtigste Regler. Statt vordefinierter Kategorien beschreibt die Firma in natürlicher Sprache, was für sie sensibel ist. Die KI interpretiert diese Regeln kontextuell bei jeder Nachricht.

Finanzdienstleister

"Finanzdaten (Umsatz, Kosten, Margen, Forecasts) sowie Kundennamen und Portfoliodaten dürfen unter keinen Umständen die Box verlassen. Regulatorische Anfragen (BaFin, MaRisk) sind immer lokal zu verarbeiten."

Automobilzulieferer

"Alle Informationen zu Projekt Aurora, Bauteilnummern (Format: XX-YYYY-ZZZ), Werkzeugdaten und OEM-Korrespondenz sind vertraulich. Allgemeine technische Fragen dürfen Cloud nutzen."

Personaldienstleister

"Bewerberdaten, Gehaltsinfos, Mitarbeiterbewertungen und interne Organigramme sind immer sensibel. Allgemeine HR-Fragen zu Arbeitsrecht dürfen Cloud nutzen."

Forschungseinrichtung

"Unveröffentlichte Forschungsergebnisse, Patentanmeldungen und Fördermittelanträge sind streng vertraulich. Literaturrecherche ist unproblematisch."

Integrierter Policy Tester

Der Admin muss nicht raten, ob seine Richtlinie funktioniert. Direkt im Dashboard befindet sich ein Policy Tester, der die echte Guardian-Pipeline ausführt.

Schritt 1: Richtlinie schreiben & speichern — Enterprise Policy: „Finanzdaten dürfen nie die Box verlassen“ · PII-Policy: Anonymize

Schritt 2: Beispiel-Nachricht eingeben & testen — z. B. „Unser Umsatz betrug 4,2 Mio EUR im Q3“

Schritt 3: Sofort-Ergebnis ablesen — LOKAL VERARBEITET · Grund: Enterprise Policy (Finanzdaten) · Flags: sensitive_context · Settings: Cloud bevorzugt, High, Anonymize

Empfohlener Einrichtungs-Workflow

1. Routing Strategy wählen — für die meisten Unternehmen: Cloud bevorzugt
2. Enterprise Policy formulieren — firmenspezifische Vertraulichkeitsregeln in eigenen Worten
3. Policy Tester nutzen — 5–10 typische Nachrichten testen (sensible + harmlose)
4. PII Cloud Policy festlegen — Anonymize für maximale Cloud-Nutzung bei vollem Schutz
5. System für Mitarbeiter freischalten

Websuche: On-Box oder extern

Ist die Websuche aktiviert, wählen Sie unter Admin → KI & Cloud → Websuche das Such-Backend. Die On-Box-Suche (SearXNG) läuft als souveräne Metasuche direkt auf der Appliance — Anfragen gehen ohne Konto- und Nutzerkontext an die Suchmaschinen. Alternativ steht Exa als externer semantischer Suchdienst (USA) bereit; dabei werden erkannte personenbezogene Daten aus der Anfrage entfernt, bevor sie die Box verlässt. In beiden Fällen kennzeichnet der Assistent websuche-gestützte Aussagen mit nummerierten Quellenverweisen [1], [2] …, die der angezeigten Quellenliste entsprechen; der Tiefgang-Modus recherchiert tiefer — mehr Quellen und ausführlichere Inhalte pro Suche.

13. Perimeter — Datengrenze im Überblick

Der Perimeter (unter /admin/perimeter) beantwortet auf einem Bildschirm die Frage, die jeder Auditor und jeder Betriebsrat zuerst stellt: „Was verlässt diese Box — zu wem, unter welchen Bedingungen?“ Er bündelt die Datengrenze-Regler, die früher über mehrere Reiter verstreut waren, an einem Ort — steuerbar und nachweisbar.

Klartext-Zusammenfassung

Oben steht die aktuelle Haltung in ganzen Sätzen, live aus den echten Einstellungen erzeugt (nicht handgeschrieben, kann also nie von der Wirklichkeit abweichen). Zum Beispiel: „Persönliche Daten werden vor der Cloud tokenisiert · Alle Erkenner sind aktiv · Bei Unsicherheit bleibt alles lokal · Ausgehender Verkehr nur zu voreingestellten Anbieter-Hosts.“ Ändern Sie unten einen Regler, formuliert sich der Satz sofort neu.

Die drei Hebel-Karten

Der Umgang mit sensiblen Daten in der Antwort (Output-DLP) folgt automatisch der PII-Policy: „Anonymisieren“ → redigieren, „Blocken“ → blocken. Ein separater Regler — oder ein „Aus“ — existiert bewusst nicht.

Fest verdrahtet — Vertrauen durch Garantien

Unter den Reglern steht ein Streifen mit dem, was nicht abschaltbar ist: alle PII-Erkenner laufen immer, bei Ausfall oder Zweifel der PII-Erkennung wird lokal verarbeitet (Fail-safe-to-LOCAL; zwei dokumentierte Ausnahmen: der Prompt-Injection-Klassifikator ist in der Standard-Stufe fail-open, und der Ausfall des mehrsprachigen GLiNER-Boosters reduziert die Abdeckung, ohne lokale Verarbeitung zu erzwingen), und der Cognitive Judge lässt sich nicht deaktivieren. Eine harte Ablehnung („Aus Sicherheitsgründen nicht verarbeitet“) erfolgt nur bei einem Block-Urteil mit hoher Konfidenz — in unklaren Fällen antwortet die Box normal, verarbeitet aber grundsätzlich lokal, sodass unklare Fälle auf der Box bleiben. Das Prinzip des ganzen Bildschirms: die Richtlinie steuern, den Mechanismus sperren.

Perimeter-Nachweis (Export)

Ein Klick erzeugt ein datiertes, druckbares Dokument (Deutsch + Englisch) mit genau denselben Sätzen wie die Zusammenfassung, einer vollständigen Regler-Tabelle und den fest verdrahteten Garantien — für Auditoren und den Betriebsrat. Keine Geheimnisse (keine Schlüssel, keine Tokens) landen im Dokument.

14. Cloud-Anbieter & Datenrichtlinien

Wenn Sie einen API Key hinterlegen, kommuniziert die Box direkt mit dem Cloud-Anbieter. Hier ist, was die Anbieter vertraglich zusichern — und wo die Grenzen liegen.

OpenAI (GPT-4o, GPT-5, o3, etc.)

Anthropic (Claude Opus 4.6, Sonnet, Haiku)

Google (Gemini 2.5 Pro, Flash, etc.)

Vergleich auf einen Blick

Warum "Policy by Hardware" überlegen ist

Vertragliche Zusicherung (Cloud-only)

• Anbieter versprechen, Daten nicht zu verwenden
• Daten werden dennoch für Abuse-Monitoring gespeichert
• Gerichtliche Anordnungen können Speicherung erzwingen
• Bei einem Datenleck sind PII betroffen

Technische Durchsetzung (Brane AIF)

• Erkannte PII wird durch die Anonymisierung geschützt; im Modus „Nur lokal“ verlässt grundsätzlich nichts die Box
• Abuse-Monitoring enthält nur Tokens ohne Personenbezug
• Gerichtliche Anordnungen betreffen nur Platzhalter
• Compliance-Nachweis liegt vollständig beim Kunden

15. Compliance & DSGVO

DSGVO-Mapping

Prototypen- und Geheimschutz (aufgebaut in Richtung VDA ISA / TISAX)

Über Unternehmensregeln mit Schlüsselbegriffen erzwingt das System lokale Verarbeitung für definierte vertrauliche Themen. Vollständig Air-Gapped betreibbar — kein Internet nötig. Ein TISAX-Label oder -Assessment liegt für das Produkt selbst nicht vor; die Mechanismen unterstützen Sie beim eigenen Assessment.

EU AI Act — was die Box mitbringt

Der KI-Hinweis nach Art. 50 Abs. 1 ist technisch erzwungen (nicht abschaltbar, nur der Wortlaut ist konfigurierbar). KI-Antworten tragen im UI eine Modell-Angabe (Lokal vs. Cloud), Routing-Entscheidungen sind nachvollziehbar und auditierbar. Die maschinenlesbare Kennzeichnung generierter Inhalte (Art. 50 Abs. 2, Frist für Bestandssysteme 02.12.2026) ist noch nicht implementiert und in Umsetzung geplant.

Ihre Pflichten als Betreiber (EU AI Act Art. 26)

AI-Z ist Anbieter von Brane AIF; Ihr Unternehmen ist beim Einsatz Betreiber — beide Rollen tragen eigene Pflichten. Als Betreiber gehören dazu insbesondere: Einsatz gemäß der Gebrauchsanweisung, Benennung einer menschlichen Aufsicht (in der Box unter Admin → Legal hinterlegbar), Aufbewahrung der automatisch erzeugten Logs (mindestens 6 Monate), Information von Mitarbeitenden und ggf. Betriebsrat vor dem Einsatz sowie die Prüfung, ob Ihr konkreter Einsatzzweck eine Hochrisiko-Einstufung auslöst. Die Box liefert dafür fertige Vorlagen mit: Admin → Compliance → Dokumente enthält die Gebrauchsanweisung mit Betreiber-Pflichtenliste, DSFA-, FRIA- und Mitarbeiterinformations-Vorlagen sowie das Betriebsrats-Paket — jeweils mit dem Konfigurations-Snapshot Ihrer Installation.

Kurzauskunft für Prüfer

Die Fragen, die in einer Datenschutz- oder Sicherheitsprüfung zuerst kommen — mit der Stelle, die ins Detail geht.

Sicherheits-Checkliste nach Einrichtung

16. Grenzen & Kapazität

Jedes System hat Grenzen. Dieses Kapitel benennt die, die im Betrieb sichtbar werden — weil eine dokumentierte Grenze planbar ist und eine unbekannte nicht.

Gleichzeitige Nutzung

Die Lizenzstufe legt zwei Dinge fest: die Zahl der Sitzplätze und die parallele Verarbeitungsbreite des lokalen Modells (siehe FAQ). Diese Breite ist nicht die Gesamtkapazität der Appliance. Drei Teilsysteme haben eigene, voneinander unabhängige Grenzen:

Anmeldung und Datei-Auswertung laufen nicht über das lokale Modell — ihre Grenzen liegen niedriger als die Stream-Zahl der Lizenz und lassen sich nicht durch eine höhere Lizenzstufe allein anheben.

Lange Unterhaltungen werden langsamer

Damit die Box sich an ein Gespräch erinnert, verarbeitet sie bei jeder Antwort den bisherigen Verlauf erneut. Die Antwortzeit wächst deshalb mit der Länge der Unterhaltung — spürbar ab etwa dem vierten bis fünften Austausch in einem langen Chat.

Hinzu kommt eine bewusste Schutzentscheidung: Die Datenschutzprüfung liest pro Anfrage bis zu 50.000 Zeichen. Wird das überschritten, prüft das System den geprüften Anfang und verarbeitet die Anfrage vorsorglich lokal — denn „nichts gefunden" wäre dann keine Aussage über den ganzen Text. Schutz geht vor Geschwindigkeit.

Was hilft: Für ein neues Thema eine neue Unterhaltung beginnen. Das ist kein Workaround, sondern die vorgesehene Arbeitsweise — Projekte und Verlauf machen alte Unterhaltungen jederzeit wiederauffindbar.

Erkennung: Reichweite und Rest-Risiko

Alle PII-Kategorien sind immer aktiv, und mehrere Erkenner laufen parallel (Kapitel 11). Trotzdem gilt:

• Keine Erkennung ist vollständig. In einer internen Vollprüfung über 162 Einzelfälle aus allen Kategorien gingen 3 Fälle unnötig an einen Cloud-Anbieter. Betroffen waren durchgehend beiläufige Einzelangaben ohne feste Form — Beruf, Uhrzeit, Dauer einer Behandlung — nicht Kontonummern, Ausweisnummern oder Gesundheitsakten, die eine erkennbare Struktur haben.
• Vorsicht kostet Tempo. Häufiger als eine Lücke ist der umgekehrte Fall: Ein Marken- oder Organisationsname genügt, um eine sachlich unbedenkliche Nachricht lokal zu verarbeiten. Das ist gewollt — im Zweifel lokal — und der Grund, warum manche harmlose Frage länger braucht als erwartet.
• Die Bewertung ist nicht deterministisch. Dieselbe Formulierung kann bei erneuter Prüfung anders eingestuft werden, weil Sprachmodelle beteiligt sind. Die Abweichung geht in die sichere Richtung: im Zweifel lokal.

Die beiden dokumentierten Ausnahmen vom Grundsatz „bei Ausfall lokal verarbeiten" stehen in Kapitel 13 unter „Fest verdrahtet".

Was die Appliance nach außen meldet

Im Local-Only-Betrieb verlässt kein Inhalt das Haus. Ist die Appliance am Fleet-Management angemeldet, meldet sie technische Betriebsdaten an AI-Z — Dienststatus, Auslastung, Speicher- und Plattenbelegung, Versionsstand. Keine Prompts, keine Chatinhalte, keine personenbezogenen Daten. Kapitel 11 beschreibt das im Detail, einschließlich des optionalen Produkt-Feedback-Relays.

17. Individualisierung & Branding

Jede Brane AIF Appliance kann vollständig an Ihre Organisation angepasst werden. Wir begleiten Sie von der Planung über die Inbetriebnahme bis zum laufenden Betrieb.

Unternehmens-Branding

Ihr Firmenlogo auf der Login-Seite, im Chat-Header und im Setup Wizard. Individuelles Farbschema passend zu Ihrem Corporate Design. Eigene Domain (z.B. ki.ihre-firma.de) mit verwalteten TLS-Zertifikaten.

Maßgeschneiderte KI-Konfiguration

Vorkonfigurierte Routing-Strategie und PII-Policies, zugeschnitten auf Ihre Branche. Enterprise Policy von unserem Team vorformuliert, basierend auf Ihren Compliance-Anforderungen. Modellauswahl optimiert für Ihre Anwendungsfälle (Geschwindigkeit vs. Qualität vs. Mehrsprachigkeit).

SSO & Verzeichnisintegration

Wir konfigurieren Azure AD, Okta oder Ihren OIDC-Provider von A bis Z. Gruppenbasierte Zugriffskontrolle, automatische Benutzerbereitstellung und Rollenmapping. Test und Validierung des kompletten Authentifizierungsablaufs vor Go-Live.

Netzwerk & Infrastruktur

Installation vor Ort oder remote in Ihrem Rechenzentrum oder Serverraum. Netzwerkkonfiguration inklusive Cloudflare Tunnel, Custom DNS und Firewall-Regeln. Integration in Ihren Monitoring-Stack (SNMP, Prometheus, Grafana).

Schulung & Onboarding

Admin-Schulung: Routing-Konfiguration, PII-Policies, Nutzerverwaltung, Audit Logs. Endanwender-Workshops: Effektives Prompting, Dokumenten-Upload, Projekt-Workspaces. Dedizierter Ansprechpartner während der Rollout-Phase.

Wissensdatenbank & RAG

Wir helfen beim Aufbau Ihrer Wissensdatenbank: Dokumenten-Import, Vektor-Indexierung und Retrieval-Tuning. Anbindung interner Wikis, SharePoint oder Dateifreigaben, damit die KI Fragen zu Ihren Unternehmensdaten beantworten kann — alles lokal verarbeitet.

Laufender Support & SLA

Monatliche Gesundheitschecks und proaktives Monitoring. Priority-Support mit garantierten Reaktionszeiten. Regelmäßige Sicherheitsupdates und Modell-Upgrades. Vierteljährliche Business Reviews mit Nutzungsanalysen und Optimierungsempfehlungen.

18. Troubleshooting

Appliance nicht im Browser erreichbar

• Computer und Appliance im gleichen Netzwerk?
• Ethernet-Kabel eingesteckt? LED am Port aktiv?
• Versuchen Sie die IP-Adresse direkt (Router → Verbundene Geräte → „brane-aif“)
• Appliance min. 90 Sekunden laufen lassen nach dem Einschalten

Setup Wizard erscheint nicht

Der Wizard zeigt sich nur beim allerersten Zugriff. Falls die Appliance bereits eingerichtet wurde, landen Sie direkt auf der Login-Seite.

Lokales Modell „Offline“

Das lokale Modell braucht 1–3 Minuten zum Laden nach dem Start. Warten Sie und aktualisieren Sie die Seite. Falls das Problem bestehen bleibt: Kontaktieren Sie den Support.

SSO-Login funktioniert nicht

• Redirect URI korrekt? Muss exakt https://IHRE-DOMAIN/supabase/auth/v1/callback sein
• Client Secret noch gültig? (Azure Secrets laufen nach 6/12/24 Monaten ab)
• Nutzer in der IDP-Anwendung zugewiesen?

Langsame Antworten

Bei vielen gleichzeitigen Nutzern steigen die Antwortzeiten. Anmeldung, Datei-Auswertung und Chat haben jeweils eigene Kapazitätsgrenzen — werden sie überschritten, können einzelne Anfragen fehlschlagen statt sich nur zu verzögern. Lange Unterhaltungen verstärken den Effekt, weil bei jeder Antwort der bisherige Verlauf erneut verarbeitet wird; eine neue Unterhaltung zu beginnen ist die schnellste Abhilfe. Bei anhaltenden Verzögerungen oder Fehlern unter Last: Kontaktieren Sie uns — wir prüfen Auslegung und Hardware für Ihre Nutzerzahl.

19. IDE- & Entwickler-Integration

KI-Erweiterungen in der IDE sprechen standardmäßig mit Cloud-Diensten. Da Brane AIF eine OpenAI-kompatible API bereitstellt, lassen sich gängige Entwicklerwerkzeuge auf die lokale Box umleiten — der Code bleibt im Haus.

Empfohlen: IDE-Chat (Cline / Roo Code / Continue)

1. Erweiterung Cline (oder Roo Code / Continue) in VS Code installieren.
2. Als Provider „OpenAI Compatible“ wählen.
3. Endpoint-URL und API-Key eintragen, Modell wählen.

Der IDE-Chat läuft damit vollständig über die Box. Agentisches Coding (Dateien lesen, editieren, Aufgaben lösen) erfordert Tool-Calling (tools/tool_calls) — das unterstützt das Gateway noch nicht, es steht auf der Roadmap.

GitHub Copilot (nur Chat)

Über Manage Language Models → OpenAI Compatible lässt sich der Chat-Modus auf Brane umleiten.

Claude Code

Die Box stellt ausschließlich das OpenAI-kompatible Gateway bereit — ein Anthropic-nativer Endpoint ist nicht verfügbar. Werkzeuge, die die OpenAI-API sprechen, können angebunden werden.

Weitere Clients

Aider, opencode sowie eigene Anwendungen und SDKs funktionieren mit derselben Endpoint-URL und demselben API-Key.

Verfügbare Modelle abfragen

Welche Modelle die Box anbietet, listet der Endpoint GET /api/v1/models auf — OpenAI-kompatibel und mit demselben API-Key (Bearer-Token) wie der Chat. Nützlich, damit Werkzeuge die Modellauswahl automatisch befüllen.

curl https://api-brane.firma.de/api/v1/models \
  -H "Authorization: Bearer <API-KEY>"

20. FAQ

Brauche ich zwingend Cloud-Modelle?

Nein. Im Modus „Nur lokal“ läuft alles auf Ihrer Hardware. Keine Internetverbindung, keine API Keys. Chat und Dokumenten-Upload stehen voll zur Verfügung; die Wissensdatenbank (RAG) ist eine optionale Zusatzfunktion.

Kann ich das KI-Modell später wechseln?

Cloud-Modelle wechseln Sie jederzeit ohne Neustart über Admin-Dashboard → Einstellungen. Ein Wechsel des lokalen Modells wird von AI-Z eingespielt und erfordert einen kurzen Neustart der Inferenz.

Wie viele Nutzer gleichzeitig?

Die Lizenzstufe legt die Sitzplätze und die parallele Verarbeitungsbreite des lokalen Modells fest: Starter (5 Nutzer, 8 parallele Streams), Professional (25 Nutzer, 32 Streams), Business (100 Nutzer, 128 Streams), Enterprise (unbegrenzte Nutzer, 512 Streams). Diese Werte beschreiben die Modellkapazität, nicht die Gesamtlast der Appliance — Anmeldung und Datei-Auswertung haben eigene, niedrigere Grenzen (siehe „Langsame Antworten“ in Kapitel 18). Für eine belastbare Auslegung auf Ihre Nutzerzahl sprechen Sie uns an. Jeder Nutzer hat vollständig isolierte Daten.

Kann ich SSO nachträglich aktivieren?

Ja. SSO kann jederzeit im Admin-Dashboard aktiviert, geändert oder deaktiviert werden. Bestehende Nutzerkonten bleiben erhalten.

Was passiert bei einem Update?

Updates werden von AI-Z als geprüfte Images geliefert und remote installiert — bei Air-Gapped-Boxen vor Ort (im Fleet-Update-Kanal signiert und auf der Box verifiziert; Rollout auf Bestandsboxen läuft). Sie erhalten vorab eine Ankündigung und Release Notes. Alle Daten, Einstellungen und API Keys bleiben erhalten. Downtime: unter 1 Minute.

Ist Brane AIF DSGVO-konform?

Brane AIF ist auf DSGVO-konformen Betrieb ausgelegt: Im Local-Only-Modus verlassen keine Daten Ihre Infrastruktur, in Hybrid-Modi wird erkannte PII automatisch anonymisiert oder blockiert, und Audit-Logs dokumentieren Routing-Entscheidungen als Metadaten. Die DSGVO-Konformität des Gesamteinsatzes verantworten Sie als Betreiber — die Box liefert die technischen Maßnahmen und die Compliance-Dokumentenbibliothek (DSFA-Vorlage, VVT, TOMs, AVV) dafür mit.

Wie sichere ich meine Daten?

Backups erstellen Sie mit dem mitgelieferten Backup-Werkzeug; wir empfehlen regelmäßige Sicherungen auf externe Medien. Details im Abschnitt „Backup & Updates“.

Mehrere Cloud-Provider gleichzeitig?

Ja. Sie können Keys für alle 7 Provider hinterlegen. Das Standard-Modell bestimmt den vorrangigen Provider. Alle Keys werden zentral vom Administrator verwaltet.

Braucht die Appliance Internet?

Nur für Cloud-Modelle, Cloudflare Tunnel und Updates. Im Local-Only-Betrieb: Kein Internet nötig. Die Appliance funktioniert vollständig offline.

Fragen?

Unser Team hilft Ihnen gerne weiter.

Support kontaktieren