Extract each page into colocated _components/ sections to bring page.tsx files from 1008/891/769 LOC down to 57/23/21 LOC, well within the 500-line hard cap. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
87 lines
5.0 KiB
TypeScript
87 lines
5.0 KiB
TypeScript
import { CodeBlock, InfoBox } from '@/components/DevPortalLayout'
|
|
|
|
export function ByoehIntroSection() {
|
|
return (
|
|
<>
|
|
<h2 id="einfuehrung">1. Was ist die Namespace-Technologie?</h2>
|
|
<p>
|
|
Unsere <strong>Namespace-Technologie</strong> (intern BYOEH -- Bring Your Own Expectation Horizon)
|
|
ist eine Privacy-First-Architektur, die es Geschaeftskunden ermoeglicht, <strong>sensible Daten
|
|
anonym und verschluesselt</strong> von KI-Services in der Cloud verarbeiten zu lassen -- ohne dass
|
|
personenbezogene Informationen jemals den Client verlassen.
|
|
</p>
|
|
<blockquote>
|
|
<em>“Daten gehen pseudonymisiert und verschluesselt in die Cloud, werden dort
|
|
von KI verarbeitet, und kommen verarbeitet zurueck. Nur der Kunde kann die Ergebnisse
|
|
wieder den Originaldaten zuordnen -- denn nur sein System hat den Schluessel dafuer.”</em>
|
|
</blockquote>
|
|
<p>Die Architektur basiert auf vier Bausteinen:</p>
|
|
<ol>
|
|
<li><strong>Pseudonymisierung:</strong> Personenbezogene Daten werden durch zufaellige Tokens ersetzt. Nur der Kunde kennt die Zuordnung.</li>
|
|
<li><strong>Client-seitige Verschluesselung:</strong> Alle Daten werden <em>auf dem System des Kunden</em> verschluesselt, bevor sie die Infrastruktur verlassen.</li>
|
|
<li><strong>Namespace-Isolation:</strong> Jeder Kunde erhaelt einen eigenen, vollstaendig abgeschotteten Namespace.</li>
|
|
<li><strong>KI-Verarbeitung in der Cloud:</strong> Die KI arbeitet mit den pseudonymisierten Daten. Ergebnisse gehen zurueck an den Kunden zur lokalen Entschluesselung.</li>
|
|
</ol>
|
|
|
|
<InfoBox type="info" title="Kern-Designprinzip: Operator Blindness">
|
|
<strong>Breakpilot kann die Kundendaten nicht lesen.</strong> Der Server sieht nur
|
|
verschluesselte Blobs und einen Schluessel-Hash (nicht den Schluessel selbst). Die
|
|
Passphrase zum Entschluesseln existiert <em>ausschliesslich</em> auf dem System des Kunden.
|
|
</InfoBox>
|
|
|
|
<h2 id="anwendungsfaelle">2. Typische Anwendungsfaelle</h2>
|
|
<div className="not-prose my-6 overflow-x-auto">
|
|
<table className="min-w-full divide-y divide-gray-200 text-sm">
|
|
<thead className="bg-gray-50">
|
|
<tr>
|
|
<th className="px-4 py-3 text-left font-medium text-gray-500">Branche</th>
|
|
<th className="px-4 py-3 text-left font-medium text-gray-500">Anwendungsfall</th>
|
|
<th className="px-4 py-3 text-left font-medium text-gray-500">Sensible Daten</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody className="divide-y divide-gray-200">
|
|
<tr><td className="px-4 py-3 font-medium">Bildung</td><td className="px-4 py-3">KI-gestuetzte Klausurkorrektur</td><td className="px-4 py-3">Schuelernamen, Noten, Leistungsdaten</td></tr>
|
|
<tr><td className="px-4 py-3 font-medium">Gesundheitswesen</td><td className="px-4 py-3">Medizinische Befundanalyse</td><td className="px-4 py-3">Patientennamen, Diagnosen, Befunde</td></tr>
|
|
<tr><td className="px-4 py-3 font-medium">Recht</td><td className="px-4 py-3">Vertragsanalyse, Due Diligence</td><td className="px-4 py-3">Mandantendaten, Vertragsinhalte</td></tr>
|
|
<tr><td className="px-4 py-3 font-medium">Personalwesen</td><td className="px-4 py-3">Bewerbungsscreening, Zeugnisanalyse</td><td className="px-4 py-3">Bewerberdaten, Gehaltsinformationen</td></tr>
|
|
<tr><td className="px-4 py-3 font-medium">Finanzwesen</td><td className="px-4 py-3">Dokumentenpruefung, Compliance-Checks</td><td className="px-4 py-3">Kontodaten, Transaktionen, Identitaeten</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<h2 id="ablauf">3. Der komplette Ablauf im Ueberblick</h2>
|
|
<CodeBlock language="text" filename="Workflow: Vom Quelldokument zur KI-verarbeiteten Ausgabe">
|
|
{`SCHRITT 1: DOKUMENTE ERFASSEN & PSEUDONYMISIEREN
|
|
SDK empfaengt Dokumente (PDF, Bild, Text)
|
|
→ Personenbezogene Daten werden erkannt (Header, Namen, IDs)
|
|
→ PII wird durch zufaellige Tokens ersetzt (doc_token, UUID4)
|
|
→ Zuordnung "Token → Originalname" wird lokal gesichert
|
|
|
|
SCHRITT 2: CLIENT-SEITIGE VERSCHLUESSELUNG
|
|
Kunde konfiguriert eine Passphrase im SDK
|
|
→ SDK leitet daraus einen 256-Bit-Schluessel ab (PBKDF2, 100k Runden)
|
|
→ Dokumente werden mit AES-256-GCM verschluesselt
|
|
→ Nur der Hash des Schluessels wird an den Server gesendet
|
|
|
|
SCHRITT 3: IDENTITAETS-MAP SICHERN
|
|
→ Nur mit der Passphrase des Kunden rekonstruierbar
|
|
|
|
SCHRITT 4: UPLOAD IN DEN KUNDEN-NAMESPACE
|
|
→ Jeder Kunde hat eine eigene tenant_id
|
|
→ Daten werden in MinIO (Storage) + Qdrant (Vektoren) gespeichert
|
|
|
|
SCHRITT 5: KI-VERARBEITUNG IN DER CLOUD
|
|
→ RAG-System durchsucht Referenzdokumente des Kunden
|
|
→ KI generiert Ergebnisse basierend auf Kundenkontext
|
|
|
|
SCHRITT 6: ERGEBNISSE ZURUECK
|
|
→ SDK entschluesselt die Ergebnisse mit der Passphrase
|
|
|
|
SCHRITT 7: RE-IDENTIFIZIERUNG & FINALISIERUNG
|
|
→ Identitaets-Map wird entschluesselt
|
|
→ Tokens werden wieder den echten Datensaetzen zugeordnet`}
|
|
</CodeBlock>
|
|
</>
|
|
)
|
|
}
|